조용한 개발 노트

29편에서는 Spring Boot Security Auto-Configuration을 통해 왜 기본적으로 “막혀 있는 상태”가 출발점인지를 살펴봤다.이번 글에서는 그 보안의 연장선, 운영에서 사고를 가장 자주 만드는 영역인 Actuator 보안 설계를 다룬다.Actuator는 운영에 필수지만, 동시에 노출되는 순간 가장 위험한 인터페이스가 된다.1) Actuator는 “관리 API”이지 “일반 API”가 아니다Actuator Endpoint는 일반 비즈니스 API와 성격이 다르다.사용자를 위한 API ❌운영 시스템을 위한 API ⭕이 차이를 무시하고 동일한 접근 정책을 적용하면, 보안 사고는 시간문제다.Actuator는 사람보다 시스템이 먼저 소비하는 인터페이스다.2) 기본 노출 정책이 보수적인 이유Sp..

28편에서는 컨테이너 환경에서 Spring Boot의 실행 전제와 책임 경계를 살펴봤다.이번 글에서는 그 실행 결과물에 반드시 따라붙는 주제, 보안(Security)을 다룬다.Spring Boot 프로젝트를 처음 만들면 많은 사람들이 이렇게 말한다. “아무것도 안 했는데 왜 다 막혀 있지?” 이 글의 목표는 이 질문에 구조적으로 답하는 것이다.1) Spring Boot Security의 기본 전제Spring Boot Security Auto-Configuration의 출발점은 매우 단순하다. “보안이 없는 상태보다, 기본적으로 막혀 있는 상태가 더 안전하다.” 그래서 Spring Security가 classpath에 존재하면, Spring Boot는 기본 보안 설정을 자동으로 활성화한다.이 기본값은 “사..

27편에서는 Spring Boot의 Packaging 전략을 통해 왜 fat jar와 layered jar가 기본 선택이 되었는지를 살펴봤다.이번 글에서는 그 패키징 결과물이 컨테이너 환경에서 어떻게 실행되고, 왜 로컬과 다른 동작을 보이는지를 정리한다.“같은 JAR인데 왜 쿠버네티스에서는 다르게 느릴까?” “JVM 옵션을 왜 다시 봐야 할까?” 같은 질문에 구조적으로 답하는 것이 목표다.1) 컨테이너는 가상 머신이 아니다컨테이너 환경을 처음 접하면 VM과 비슷하다고 느끼기 쉽다.하지만 실행 모델은 전혀 다르다.VM: OS를 포함한 독립 환경컨테이너: 호스트 커널을 공유하는 프로세스 격리이 차이 때문에, JVM은 컨테이너 안에서 리소스를 “오해”할 가능성이 있다.Spring Boot가 컨테이너 친화적인 ..

26편에서는 TestConfiguration과 테스트 전용 설정 전략을 통해 테스트와 프로덕션 구조의 경계를 정리했다.이번 글에서는 애플리케이션이 “완성된 코드”를 넘어 어떤 형태로 배포되는가를 결정하는 Spring Boot Packaging 전략을 다룬다.“왜 Spring Boot는 fat jar를 기본으로 쓸까?” “이 구조는 컨테이너 시대에도 여전히 합리적일까?” 같은 질문에 답하는 것이 목표다.1) Packaging은 빌드 문제가 아니라 실행 모델이다많은 경우 패키징은 단순히 “빌드 산출물의 형태”로만 인식된다.하지만 Spring Boot에서 패키징은 실행 모델과 직결된다. “이 애플리케이션은 어떤 단위로 실행되고, 무엇을 포함한 상태로 배포되는가?” Spring Boot는 이 질문에 대해 매우 ..

25편에서는 Spring Boot Test의 전체 설계 철학과 @SpringBootTest vs Slice Test의 책임 경계를 정리했다.이번 글에서는 테스트를 작성하다 보면 반드시 마주치는 질문을 다룬다. “테스트를 위해 설정을 어디까지 바꿔도 괜찮을까?” 이 질문에 대한 기준이 없으면, 테스트는 점점 늘어나지만 구조는 빠르게 망가진다.1) TestConfiguration은 “편의 기능”이 아니다Spring Boot에서 테스트 전용 설정을 추가할 때 가장 먼저 떠올리는 도구가 @TestConfiguration이다.하지만 이 어노테이션은 “아무 설정이나 넣어도 되는 공간”이 아니다. TestConfiguration은 프로덕션 설정을 대체하기 위한 수단이 아니라, 테스트 환경을 설명하기 위한 도구다. 2..

24편에서는 Startup 성능과 Lazy Initialization을 통해 언제 빠르게 시작하는 것이 좋은 선택인지를 다뤘다.이번 글에서는 그 다음 단계, 개발자가 가장 자주 만지고 가장 자주 불평하는 영역, Spring Boot Test를 다룬다.“왜 테스트가 이렇게 느리지?” “@SpringBootTest 말고 뭐가 다른 거야?” 같은 질문에 구조적으로 답할 수 있게 되는 것이 목표다.1) Spring Boot Test의 출발점은 “신뢰 가능한 기본값”이다Spring Boot Test의 기본 철학은 단순하다. “실제 애플리케이션과 최대한 비슷한 환경에서 테스트하자.” 그래서 기본 테스트 어노테이션이 @SpringBootTest다.이는 “가장 무거운 선택”이 아니라, 가장 안전한 출발점이다.테스트가 ..

23편에서는 Logging을 통해 애플리케이션이 실행된 이후의 상태를 어떻게 설명할 것인가를 다뤘다.이번 글에서는 그보다 더 앞선 시점, 애플리케이션이 “얼마나 빨리 준비 상태가 되는가”를 결정하는 Startup 성능을 다룬다.특히 Spring Boot에서 자주 언급되는 Lazy Initialization을 “써도 되는 도구”와 “위험한 지름길”의 경계로 정리해본다.1) Startup 성능이 중요한 순간모든 애플리케이션이 빠른 Startup을 요구하는 것은 아니다.하지만 다음과 같은 환경에서는 Startup 시간이 곧 운영 품질로 이어진다.컨테이너 기반 배포 (Kubernetes)오토스케일링 환경잦은 배포와 롤링 업데이트이 환경에서 Startup이 느리면, 서비스는 다음과 같은 문제를 겪는다.트래픽을 받..

22편에서는 ApplicationContextInitializer를 통해 Bean 이전 단계에 개입하는 책임 경계를 정리했다.이번 글에서는 애플리케이션이 실행된 이후, 가장 오래 남고 가장 많이 참조되는 산출물, 바로 로그(logging)를 다룬다.로그는 단순한 출력이 아니다. 잘 설계되면 시스템을 설명하고, 잘못 설계되면 문제를 숨긴다.1) Spring Boot Logging의 기본 철학Spring Boot는 로깅을 “라이브러리 선택의 문제”로 보지 않는다.대신 다음 질문에 답하려고 한다. “애플리케이션은 어떤 형태로 자신의 상태를 외부에 설명해야 하는가?” 그래서 Spring Boot는 별도 설정 없이도 즉시 사용 가능한 로깅 기본값을 제공한다.이 기본값의 목적은 “최적화”가 아니라 일관성 있는 출발..

21편에서는 ApplicationContext와 BeanFactory의 책임 차이를 통해 Spring Boot가 다루는 “실행 환경”의 범위를 정리했다.이번 글에서는 그보다 더 이른 시점, 아직 Bean조차 만들어지기 전 단계에 개입하는 방법인 ApplicationContextInitializer를 다룬다.이 기능은 강력한 만큼, 잘못 쓰면 구조를 망치기 쉬운 영역이다. “언제 써야 하고, 언제 쓰면 안 되는지”를 기준으로 정리해보자.1) ApplicationContextInitializer는 언제 호출될까Spring Boot 애플리케이션은 SpringApplication.run() 과정에서 여러 단계를 거친다.ApplicationContextInitializer는 ApplicationContext가 생..

Part 3는 Spring Boot의 내부 기능 설명을 넘어, Spring Boot를 둘러싼 실행·확장·책임의 경계를 다룬다.그 첫 주제는 Spring을 오래 써도 명확히 짚고 넘어가지 않는 개념, ApplicationContext와 BeanFactory의 차이다.“둘 다 Bean 컨테이너 아니야?”라는 질문에 구조적으로 답할 수 있게 되는 것이 목표다.1) BeanFactory는 “최소 컨테이너”다BeanFactory는 Spring의 가장 기본적인 컨테이너 인터페이스다.역할은 단순하다.Bean 정의를 보관하고요청 시 Bean을 생성한다즉, BeanFactory는 객체 생성과 의존성 해소만을 책임진다.그 외의 기능은 의도적으로 포함하지 않는다.이 설계는 “가볍고, 단순하며, 핵심만 가진 컨테이너”를 만들..