조용한 개발 노트

이 글은 Spring Framework 공식 문서(Testing)를 기반으로, Spring 테스트의 핵심 인프라인 TestContext Framework가 ApplicationContext를 어떻게 생성하고, 어떻게 재사용하며, 왜 테스트 성능에 결정적인 영향을 미치는지를 정리합니다.1편에서 테스트의 철학과 전략을 다뤘다면, 이번 편은 Spring 테스트가 실제로 어떻게 동작하는지를 이해하는 출발점입니다.들어가며Spring 테스트를 작성하다 보면 이런 현상을 경험하게 됩니다.테스트 하나 추가했을 뿐인데 전체 테스트가 느려졌다같은 설정인데 어떤 테스트는 빠르고, 어떤 테스트는 느리다@SpringBootTest가 왜 이렇게 무거운지 모르겠다이 문제의 대부분은 ApplicationContext의 생성과 재사용..

40편에서는 ApplicationContext 초기화 비용을 줄이기 위한 실무 전략을 단계별로 정리했습니다.이번 글에서는 그 전략을 설계 패턴으로 승격시키는 핵심 도구,@Conditional을 중심으로 대규모 서비스에서 Bean을 언제, 왜, 어떻게 생성할지를 체계화하는 방법을 살펴보겠습니다.1. 조건부 Bean이 왜 중요한가대규모 서비스에서는 다음 조건들이 동시에 존재합니다.환경(dev / stage / prod)기능 on/off (Feature Toggle)외부 시스템 연결 여부이때 모든 Bean을 무조건 생성하면,초기화 비용 증가불필요한 의존성 로딩기동 실패 가능성 증가로 이어집니다.조건부 Bean의 목표는 명확합니다.“필요한 순간에, 필요한 Bean만 생성한다”2. @Profile vs @Cond..

39편에서는 대규모 서비스에서 Bean 구성 전략을 어떻게 가져가야 하는지를 설계 관점에서 정리했습니다.이번 글에서는 그 전략을 실제로 체감 성능으로 연결하기 위해,ApplicationContext 초기화 과정에서 시간은 어디서 쓰이고, 무엇을 줄일 수 있는가를 단계별로 살펴보겠습니다.1. Spring Boot 기동이 느려지는 이유Spring Boot 애플리케이션의 기동 시간은 단일 작업이 아니라환경 설정 로딩자동 구성(Auto Configuration)Bean 스캔 및 생성의존성 주입초기화 콜백 실행의 누적 결과입니다.대규모 서비스에서는“작은 비용들이 쌓여 큰 지연이 된다”는 점을 항상 염두에 둬야 합니다.2. ApplicationContext 초기화 흐름 한 번에 보기ApplicationContext..

38편에서는 Servlet과 Reactive를 함께 사용하는 혼합 아키텍처 전략을 살펴봤습니다.이번 글에서는 그 아키텍처를 실제로 떠받치는Spring Bean 구성 전략을 대규모 서비스 관점에서 정리해보겠습니다.이 글의 핵심 질문은 다음입니다.“Bean은 많아질수록 왜 느려지고, 왜 복잡해질까?”1. 소규모와 대규모 서비스의 Bean 차이소규모 서비스에서는Bean 수가 적고의존 관계가 단순하며초기화 비용이 문제 되지 않습니다하지만 대규모 서비스에서는:Bean 수 수백~수천 개복잡한 의존 그래프초기화 순서 문제가 동시에 발생합니다.이때부터 Bean 구성은“기능 구현”이 아니라 “시스템 설계”의 영역이 됩니다.2. 모든 Bean을 한 번에 만들면 안 되는 이유Spring의 기본 전략은싱글톤 Bean을 App..

1편에서는 Spring Framework가 어떤 문제를 해결하려고 등장했는지, 그리고 그 핵심 철학이 IoC(Inversion of Control)라는 점을 살펴봤습니다.이번 글에서는 그 IoC를 실제로 구현하는 존재, IoC 컨테이너의 정체를 본격적으로 파헤쳐보려고 합니다.우리가 흔히 사용하는 @Service, @Component, @Autowired 같은 기능들은 모두 이 컨테이너 위에서만 의미를 가집니다.1. IoC 컨테이너란 무엇인가IoC 컨테이너는 한 문장으로 정리하면 다음과 같습니다.애플리케이션에 필요한 객체를 생성하고, 의존성을 연결하며, 생명주기를 관리하는 존재 Spring에서 이 역할을 수행하는 것이 바로 ApplicationContext입니다.즉, Spring 애플리케이션은 단순히 ma..

Spring을 사용하면서 우리는 자연스럽게 이런 문장들을 말합니다.“이건 스프링이 알아서 해줘요”“DI라서 테스트하기 좋아요”“설정은 Boot가 자동으로 해주잖아요”하지만 정작 Spring이 왜 이런 구조를 가지게 되었는지, 그리고 어떤 문제를 해결하려고 만들어졌는지를 정확히 설명하기는 쉽지 않습니다.이 시리즈의 첫 글에서는 코드를 거의 다루지 않고, Spring Framework가 등장하게 된 배경과 핵심 철학부터 정리해보려고 합니다.1. Spring 이전의 Java 서버 개발은 무엇이 문제였을까Spring이 등장하기 전, 엔터프라이즈 Java 개발의 중심에는 EJB(Enterprise JavaBeans)가 있었습니다. EJB는 “대규모 엔터프라이즈 애플리케이션”을 목표로 설계되었지만, 실제 개발자 경..

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);} 이 메서드는 단순히 ..

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은 런타임에 즉석에서 만들어지는 기능이 아니다. ..