조용한 개발 노트

42편에서는 Spring Boot의 암묵적 기본값을 명시적으로 드러내는 방법을 다뤘다.이번 글에서는 설정 흐름의 가장 깊은 지점, EnvironmentPostProcessor와 ApplicationContextInitializer의 차이를 정리한다.두 개념은 비슷해 보이지만, 잘못 쓰면 설정을 강하게 만들고, 잘 쓰면 설정 흐름을 명확하게 만든다.1) 둘 다 “아주 이른 시점”에 개입한다공통점부터 짚어보자.EnvironmentPostProcessor와 ApplicationContextInitializer는 모두 Bean 생성 이전에 동작한다.즉, 이 시점에서는:Bean ❌의존성 주입 ❌@ConfigurationProperties 바인딩 ❌이 공통점 때문에 두 개념은 자주 혼동된다.하지만 책임은 전혀 다르..

37편에서는 Spring Boot에서 성능 문제를 접근하는 올바른 순서를 정리했다.이번 글에서는 그 흐름을 한 단계 더 좁혀, Auto-Configuration이 성능에 어떤 영향을 주는지를 살펴본다.“Spring Boot는 느리다”라는 말의 상당수는 실제로는 자동 설정이 만드는 간접 비용을 이해하지 못해서 나온다.1) Auto-Configuration은 공짜가 아니다Auto-Configuration은 개발 속도를 극적으로 높여준다.하지만 그 대가로, 다음과 같은 비용이 항상 발생한다.Classpath 스캔 비용조건(@Conditional) 평가 비용불필요한 Bean 정의 등록대부분의 애플리케이션에서는 이 비용이 문제가 되지 않는다.문제가 되는 시점은 애플리케이션 규모와 역할이 커질 때다.2) Start..

35편에서는 PropertySource 우선순위를 언제 직접 만져야 하는지, 그리고 그 선택이 얼마나 무거운 책임인지 살펴봤다.이번 글에서는 그보다 더 앞선 지점, Spring Boot 실행의 진짜 시작점인 SpringApplication 자체를 커스터마이징하는 전략을 다룬다.이 주제는 자주 쓰이지 않지만, 한 번 쓰기 시작하면 애플리케이션의 성격 자체를 바꾸는 힘을 가진다.1) SpringApplication은 단순한 헬퍼가 아니다많은 코드에서 SpringApplication.run()은 거의 의식 없이 호출된다.public static void main(String[] args) { SpringApplication.run(Application.class, args);} 하지만 SpringApp..

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

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

15편에서는 Metrics & Monitoring을 통해 운영 판단에 필요한 관측 기준을 정리했다.이번 글에서는 그 판단의 출발점이 되는 설정(Configuration)을 어떻게 다뤄야 하는지, 특히 @ConfigurationProperties를 중심으로 “제대로 쓰는 기준”을 정리한다.설정은 단순한 값 모음이 아니다. 잘 설계하면 구조를 안정시키고, 잘못 설계하면 장애의 시작점이 된다.1) @Value는 편하지만, 구조를 남기지 않는다Spring을 처음 쓰면 설정 값을 이렇게 읽기 시작한다.@Value("${external.api.timeout}")private long timeout; 이 방식은 간단하고 빠르다. 하지만 프로젝트가 커질수록 문제가 드러난다.설정 값이 여기저기 흩어진다어떤 설정이 한 ..

11편에서는 ApplicationEvent와 Listener를 통해 Spring Boot 실행 흐름을 “관찰”하는 관점을 정리했다.이번 글에서는 그 관찰 대상 자체, 즉 Spring Boot 애플리케이션이 실제로 시작되는 전 과정을 단계별로 해부해본다.목표는 단순하다. “이 시점에 이 코드를 넣어도 되는가?” 이 질문에 스스로 답할 수 있다면, Startup 단계는 더 이상 감으로 다루는 영역이 아니다.1) 모든 시작은 SpringApplication.run()이다Spring Boot 애플리케이션의 시작점은 항상 같다.public static void main(String[] args) { SpringApplication.run(Application.class, args);} 이 메서드는 단순히 ..

10편에서는 Spring Boot를 “프레임워크처럼 의존하는 대상”이 아니라 이해한 뒤 활용해야 할 실행 환경으로 바라보는 관점을 정리했다.Part 2는 그 관점을 바탕으로, Spring Boot 애플리케이션의 실행과 운영을 더 깊게 이해하는 단계다.그 첫 주제는 실행 흐름과 항상 함께 등장하지만, 기준 없이 쓰이면 구조를 망치기 쉬운 기능, ApplicationEvent와 Listener다.1) ApplicationEvent는 “알림”이지 “제어 수단”이 아니다Spring Boot에는 애플리케이션 실행 과정에서 발생하는 여러 이벤트가 존재한다.이를 흔히 이렇게 오해한다.“이 시점에 이 코드가 실행되게 하고 싶다 → 이벤트 쓰자”하지만 ApplicationEvent의 본래 목적은 흐름을 제어하는 것이 아..

5편에서는 Spring Boot의 Auto-Configuration이 미리 정의된 설정 후보 목록을 조건에 따라 선별해 ApplicationContext에 Import하는 구조라는 것을 살펴봤다.구조를 이해했다면, 다음 단계는 자연스럽다.왜 이 Bean이 생겼는지 알고 싶다왜 어떤 자동 설정은 적용되지 않았는지 확인하고 싶다문제가 생겼을 때, 어디서부터 추적해야 할지 알고 싶다이번 글에서는 Spring Boot가 제공하는 Auto-Configuration 디버깅 도구를 중심으로, 자동 설정을 실제로 추적하는 방법을 정리한다.1) “왜 이 Bean이 생겼지?”라는 질문의 정체실무에서 가장 자주 듣는 질문 중 하나는 이것이다.“이 Bean은 내가 만든 적이 없는데, 왜 생겼지?”대부분의 경우 답은 하나다.A..

4편에서는 SpringApplication.run()을 기준으로 Spring Boot 애플리케이션이 Environment → ApplicationContext → Bean 생성 순서로 초기화된다는 것을 살펴봤다.이제 자연스럽게 다음 질문이 나온다.Auto-Configuration은 도대체 어디에 정의돼 있을까?수많은 자동 설정 클래스는 언제, 어떤 기준으로 로딩될까?왜 어떤 설정은 적용되고, 어떤 설정은 빠질까?이번 글에서는 Spring Boot의 핵심 기능인 Auto-Configuration이 실제로 로딩되는 흐름을 내부 동작 기준으로 정리한다.1) Auto-Configuration은 “마법”이 아니라 “목록”에서 시작된다Auto-Configuration은 런타임에 즉석에서 만들어지는 기능이 아니다. ..