[2회차] Spring ApplicationContext 는 왜 테스트 성능에 영향을 줄까?

[github-actions[bot]]

🚀 발표 주제

Spring ApplicationContext 는 왜 테스트 성능에 영향을 줄까?

📅 발표일

2026-06-08

🙋 발표자

러키

🗂️ 카테고리

🌱 Spring

📚 발표 자료

[러키] Spring ApplicationContext 는 왜 테스트 성능에 영향을 줄까?.pdf

🎥 발표 영상

업로드 예정

---

🎯 핵심 개념 요약

ApplicationContext의 역할과 생성 비용

• ApplicationContext는 애플리케이션 구성을 제공하는 중앙 인터페이스로, Bean 접근, 리소스 로딩, 이벤트 발행 등의 역할을 수행합니다.
• ApplicationContext가 생성될 때는 Classpath 스캔 및 BeanDefinition 등록, Bean 생성 및 의존성 주입, 그리고 `@Transactional' 등을 위한 프록시를 생성하는 BeanPostProcessor 실행 과정을 거칩니다. 수많은 객체를 탐색하고 관계를 맺어주는 이 과정은 매우 큰 비용을 동반합니다.
• @DirtiesContext는 테스트 실행 중 Spring ApplicationContext가 수정되거나 손상되었음(더러워졌음)을 나타내는 어노테이션입니다. 이 어노테이션이 붙은 컨텍스트는 테스트 프레임워크의 캐시에서 제거되고 종료되며, 후속 테스트를 위해 기본 Spring 컨테이너가 매번 새로 재구축됩니다.
• Context Caching: 컨텍스트 생성 비용을 줄이기 위해 Spring에서 제공하는 기능입니다. 동일한 테스트 스위트 내에서 설정 클래스, Active Profile, Property 설정, MockBean/SpyBean 구성이 동일하고 @DirtiesContext를 사용하지 않는다면, 기존에 로드된 컨텍스트를 캐시하여 후속 테스트에서 재사용합니다.

🔗 미션과의 연결

학습테스트에 존재하던 @DirtiesContext을 사용했을 때, 테스트 실행 속도에 어떤 영향을 끼치는지 알아보자!

📚 참고 자료

스프링 공식문서

---

🙋‍♀️ 질문

1. Spring ApplicationContext가 부팅되면서 빈을 등록하고 생성하는 전체적인 순서에 대해 간단히 설명해 주세요.
2. 클래스에 @Transactional이 붙어 있다면, ApplicationContext는 최종적으로 어떤 객체를 빈으로 등록하게 될까요?
3. Spring Context Caching은 왜 필요하며, 어떤 조건 속에서 발생하나요?

[Soojin6943]

1. Spring ApplicationContext가 부팅되면서 빈을 등록하고 생성하는 전체적인 순서에 대해 간단히 설명해 주세요.

1. 컨포넌트 스캔을 통해 @component 계열의 클래스 찾기 & BeanDefinition 등록
2. 빈 생성 및 의존성 주입
3. 초기화 및 후처리
   • BeanPostProcessor 동작
   • 필요 시 프록시 생성

2. 클래스에 @transactional이 붙어 있다면, ApplicationContext는 최종적으로 어떤 객체를 빈으로 등록하게 될까요?

원본 객체가 아닌 프록시를 생성하여 프록시 객체를 반환합니다

3. Spring Context Caching은 왜 필요하며, 어떤 조건 속에서 발생하나요?

• 스프링 컨텍스트를 생성하는 비용은 비싸고, 무겁기 때문에 테스트 시 성능 저하 유발
• 테스트 컨텍스트 설정(캐시 키)이 동일할 때 캐시 재사용
  • @SpringBootTest
  • @ContextConfiguration
  • @activeprofiles
  • @TestPropertySource
  • @MockBean
  • Context Customizer 정보

[2Jaeheon]

문제1: Spring ApplicationContext가 부팅되면서 빈을 등록하고 생성하는 전체적인 순서에 대해 간단히 설명해 주세요.

1. 설정 정보 읽기
2. BeanDefinition도입
3. BeanFactoryPostProcessor 실행
4. BeanPostProcessor 준비
5. Signleton bean 생성 및 의존성 주입
6. BeanPostProcessor 적용

---

문제2: 클래스에 @transactional이 붙어 있다면, ApplicationContext는 최종적으로 어떤 객체를 빈으로 등록하게 될까요?

proxy mode 기준으로는, 트랜잭션 처리를 위해 실제 대상 객체를 감싼 프록시 객체가 빈으로 노출될 수 있습니다.
따라서 외부에서 빈을 주입받아 호출하면 실제 객체를 직접 호출하는 것이 아니라, 프록시를 통해 호출하게 됩니다.
다만 설정에 따라 JDK dynamic proxy 또는 CGLIB proxy가 사용될 수 있습니다.

---

문제3: Spring Context Caching은 왜 필요하며, 어떤 조건 속에서 발생하나요?

ApplicationContext 생성 비용이 크기 때문에, 같은 설정을 사용하는 테스트끼리는 컨텍스트를 재사용해 테스트 실행 시간을 줄이기 위해 필요합니다.
캐싱은 같은 테스트 스위트 안에서, 컨텍스트 캐시 키를 구성하는 설정들이 동일할 때 발생합니다.₩
반대로 설정 클래스, active profile, property, mock/spy bean 구성 등이 달라지거나 @DirtiesContext로 컨텍스트가 더러워졌다고 표시되면 기존 컨텍스트를 재사용하지 못할 수 있습니다.

[MODUGGAGI]

Spring ApplicationContext가 부팅되면서 빈을 등록하고 생성하는 전체적인 순서에 대해 간단히 설명해 주세요.

1. 컴포넌트 스캔
   2.@Component이 붙은 클래스 탐색
2. Bean Definition 정보 저장 (빈의 이름, 클래스, 싱글톤 여부 등등)
3. Bean Definition 정보를 통해 스프링 빈 생성
4. 의존성 주입
5. BeanPostProcessor를 통해 빈을 후처리하면서 @transactional, @async 등등의 어노테이션이 붙어있다면 프록시 객체를 스프링 빈으로 만든다.
6. 이렇게 만들어진 스프링 빈을 스프링 컨테이너에 등록한다.

클래스에 @transactional이 붙어 있다면, ApplicationContext는 최종적으로 어떤 객체를 빈으로 등록하게 될까요?

• 기존 스프링 빈에 트랜잭션 처리를 추가해준 프록시 객체가 스프링 빈으로 등록된다.
• 스프링은 현재 디폴트로 프록시 객체를 CGLIB방식으로 랩핑해준다. (jdk 동적 프록시 방식을 사용하려면 추가 설정을 해야 한다.)
• Jdk 동적 프록시는 인터페이스가 존재하는 클래스, CGLIB는 구체 클래스들만 있는 경우에 대해서 프록시 객체를 생성해준다.
  • jdk 동적 클래스는 인터페이스의 구현을 하는 방식, CGLIB는 바이트 코드 조작을 통한 상속의 방식으로 프록시 객체 생성

Spring Context Caching은 왜 필요하며, 어떤 조건 속에서 발생하나요?

• Spring의 Application Context를 띄우는 것은 많은 비용이 필요하기 때문에 동일한 컨텍스트를 재사용하는 것이 테스트 실행 시간을 줄이며 비용 효율적으로 테스트를 할 수 있게 해준다.
• 같은 의존성을 주입해서 사용하는 Application Context가 존재한다면 스프링이 자동으로 컨텍스트 캐싱을 사용해서 재사용을 할 수 있게 해줍니다.

[wontop02]

Spring ApplicationContext가 부팅되면서 빈을 등록하고 생성하는 전체적인 순서에 대해 간단히 설명해 주세요.

1. Spring Container가 컴포넌트 스캔을 통해 @ Component 계열 클래스를 탐색한다. 이를 바탕으로 빈의 이름, 클래스 타입, 스코프, 생성자 매개변수 등을 담은 BeanDefinition을 생성하고, 이를 BeanDefinitionRegistry에 Map 형태로 등록한다.
2. 등록된 BeanDefinition 정보를 바탕으로 스프링이 실제 자바 객체를 생성하고, 의존 관계를 주입한다.
3. 빈 객체 생성이 완료되면 BeanPostProcessor가 작동한다. 빈에 @ Transaction 등이 있는지 검사하고, 예를 들어 @ Transaction이 있다면 프록시 객체를 생성해 프록시를 빈으로 등록한다.

클래스에 @transactional이 붙어 있다면, ApplicationContext는 최종적으로 어떤 객체를 빈으로 등록하게 될까요?

• 원본 클래스를 상속받아 트랜잭션을 추가한 프록시 객체를 빈으로 등록한다.

Spring Context Caching은 왜 필요하며, 어떤 조건 속에서 발생하나요?

• Spring의 Context를 매번 다시 생성하면 시간이 오래 걸리기 때문이다.
• 동일한 고유 Context 구성을 선언하는 모든 후속 테스트에서 기존에 캐시된 Context를 재사용한다.
  • 동일한 설정 클래스 (@ SpringBootTest, @ ContextConfiguration)
  • 동일한 Active Profile (@ ActiveProfiles)
  • 동일한 Property 설정 (@ SpringBootTest(properties), @ TestPropertySource)
  • 동일한 MockBean / SpyBean 구성
  • @ DritiesContext

[Jihyun3478]

Q1. Spring ApplicationContext가 부팅되면서 빈을 등록하고 생성하는 전체적인 순서에 대해 간단히 설명해 주세요.

1. BeanDefinition 등록 (스캔 → 설계도만 등록, 인스턴스 아직 없음)
2. BeanFactoryPostProcessor 실행 (BeanDefinition 수정)
3. 싱글톤 빈 인스턴스화 -> refresh() 시점에 전부 미리 생성 (Eager Initialization)
4. 의존성 주입
5. BeanPostProcessor 실행 (AOP 프록시 생성)
6. 초기화 콜백 (@PostConstruct 등)

---

Q2. 클래스에 @transactional이 붙어 있다면, ApplicationContext는 최종적으로 어떤 객체를 빈으로 등록하게 될까요?

최종적으로 프록시 객체가 빈으로 등록됩니다. 프록시가 메서드 호출을 가로채 트랜잭션을 열고 닫습니다. 단, 같은 클래스 내부에서 호출하면 프록시를 거치지 않아 트랜잭션이 무시되는 Self-invocation 문제가 발생할 수 있습니다.

---

Q3. Spring Context Caching은 왜 필요하며, 어떤 조건 속에서 발생하나요?

Spring Context Caching은 Context 생성 비용이 크기 때문에 필요합니다. 빈 구성이 동일하면 재사용하고, @MockBean/@ActiveProfiles/@TestPropertySource 등이 달라지면 새 Context를 띄웁니다.