실행 시점 (Request 요청이 들어올 떄)
— 요청이 들어왔을 때 내부에서 자연스럽게 흐르는 과정
Spring Framework를 사용하다 보면
대부분의 개발자는 “요청이 들어오면 그냥 잘 처리된다”라고 느낍니다.하지만 실행 시점(Runtime)을 기준으로 내부 흐름을 따라가 보면,
Spring은 아무 일도 즉흥적으로 하지 않고,
구동 시점에 준비된 구조를 정해진 순서대로 흘려보낼 뿐이라는 점이 드러납니다.
1️⃣ 실행 시점의 전제
실행 시점에 애플리케이션은 이미 다음 상태에 있습니다.
- ApplicationContext 초기화 완료
- 모든 Singleton Bean 생성 완료
- AOP 대상 Bean은 Proxy로 등록 완료
- DispatcherServlet 초기화 완료
즉, 실행 시점에는
새로운 구조를 만드는 단계가 아니라,
이미 만들어진 구조를 사용하는 단계입니다.
2️⃣ 요청 인입과 실행의 시작
클라이언트로부터 HTTP 요청이 들어오면
가장 먼저 요청을 받는 것은 Spring이 아니라 Servlet Container(Tomcat)입니다.
Tomcat은 요청을 수신하면서 Thread Pool에서 하나의 Thread를 할당하고,
이 Thread에게 요청 전체 처리를 맡깁니다.
이 시점부터 요청이 끝날 때까지
Controller, Service, Repository 전부 같은 Thread 위에서 실행됩니다.
Spring은 Thread를 생성하거나 관리하지 않고,이미 할당된 Thread 위에서 동작합니다.
3️⃣ DispatcherServlet으로의 진입
Tomcat은 요청을 등록된 Front Controller인 DispatcherServlet으로 전달합니다.
DispatcherServlet은 실행 시점에 직접 비즈니스 로직을 처리하지 않습니다.
대신 다음 역할만 수행합니다.
- 요청을 분석합니다
- 어떤 Controller가 처리할지 결정합니다
- 적절한 컴포넌트에게 처리를 위임합니다
이것이 Spring MVC의 핵심 철학입니다.
4️⃣ Controller 호출과 Proxy의 존재
DispatcherServlet이 선택한 Controller는 이미 IoC Container에 등록된 Bean입니다.
그리고 이 Bean은 대부분 원본 객체가 아니라 Proxy 객체입니다.
이 Proxy는 실행 시점에 새로 만들어지는 것이 아니라,
구동 시점에 이미 생성되어 등록된 객체입니다.
실행 시점에서는 단지 그 Proxy의 메서드를 호출할 뿐입니다.
5️⃣ 실행 시점에서 Proxy가 동작하는 방식
Proxy는 항상 개입하지 않습니다.
단순히 메서드 호출을 감시하다가, 필요한 경우에만 개입합니다.
예를 들어 @Transactional이 붙은 메서드라면,
Proxy는 메서드 호출 직전에 다음 작업을 수행합니다.
- 트랜잭션을 시작합니다
- 실제 대상 객체의 메서드를 호출합니다
- 정상 종료 시 커밋하거나 예외 시 롤백합니다
중요한 점은,
트랜잭션은 DispatcherServlet 시점이 아니라
메서드 호출 시점에 시작된다는 점입니다.
6️⃣ Service 계층에서도 동일한 흐름
Controller가 Service를 호출할 때도 흐름은 동일합니다.
Service 역시 Bean이며, AOP 대상이라면 Proxy로 등록되어 있습니다.
따라서 실행 시점의 흐름은
Proxy → 실제 객체 → 결과 반환
이라는 구조가 계층마다 반복됩니다.
마무리
구동 시점과 실행 시점을 분리해서 보면
Spring Framework는 훨씬 명확해집니다.
- 구동 시점은 구조를 만드는 단계입니다
- 실행 시점은 구조를 사용하는 단계입니다
- 실행 시점에는 새로운 마법이 일어나지 않습니다
- 모든 동작은 이미 준비된 흐름 위에서 발생합니다
