조용한 개발 노트

45편에서는 애플리케이션 종료를 어떻게 설계해야 하는지를 다뤘다.이번 글에서는 실행과 종료의 경계에 위치한 주제, ApplicationEvent를 “운영 신호”로 사용하는 방법을 정리한다.ApplicationEvent는 잘 쓰면 운영 가시성을 높이는 도구가 되지만, 잘못 쓰면 구조를 망가뜨리는 트리거가 된다.1) ApplicationEvent의 본질은 “알림”이다ApplicationEvent는 Spring 내부에서 발생한 사실을 외부로 알리는 메커니즘이다.중요한 점은 이것이다. 이벤트는 “무언가를 하라”는 명령이 아니라, “무언가가 일어났다”는 신호다. 이 차이를 무시하는 순간, 이벤트는 제어 흐름의 일부가 되어버린다.2) Spring Boot가 제공하는 주요 라이프사이클 이벤트Spring Boot는 실..

44편에서는 Spring Boot Starter를 직접 만들 때의 기준을 통해 확장의 책임이 어디까지 커지는지를 살펴봤다.이번 글에서는 그 확장의 반대편, 애플리케이션의 “끝”을 다룬다.실행은 잘 설계하면서도, 종료는 거의 설계하지 않는 경우가 많다. 하지만 운영에서 사고가 나는 지점은 대부분 이 “끝”에서 시작된다.1) 애플리케이션 종료는 예외 상황이 아니다많은 코드가 애플리케이션 종료를 “비정상 상황”으로 취급한다.하지만 현대의 운영 환경에서는 종료는 매우 일상적인 이벤트다.배포로 인한 재시작오토스케일링노드 교체즉, 애플리케이션은 언제든지 종료될 수 있다는 전제 위에서 설계되어야 한다.2) Spring Boot는 언제 “종료 신호”를 받는가Spring Boot 애플리케이션은 외부에서 종료 신호를 받으..

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

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는 객체 생성과 의존성 해소만을 책임진다.그 외의 기능은 의도적으로 포함하지 않는다.이 설계는 “가볍고, 단순하며, 핵심만 가진 컨테이너”를 만들..

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의 본래 목적은 흐름을 제어하는 것이 아..

3편에서는 @SpringBootApplication이 Spring Boot 애플리케이션의 진입점이라는 것을 살펴봤다.이제 남은 질문은 이것이다.main()에서 실행 버튼을 누르면 실제로 무슨 일이 일어날까?ApplicationContext는 언제 만들어질까?우리가 작성한 코드는 언제부터 안전하게 실행할 수 있을까?이 모든 흐름은 SpringApplication.run() 내부에서 시작된다.1) main()은 단순한 시작 버튼이다Spring Boot 애플리케이션의 main() 메서드는 생각보다 하는 일이 많지 않다.public static void main(String[] args) { SpringApplication.run(Application.class, args);} 이 코드는 “애플리케이션을..