> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/2-5.-spring-core-2-jvm-web-mvc-bean.md). # 2-5. Spring Core #2 : JVM / Web MVC / Bean Spring framework의 core - JVM / Web MVC / Bean에 대하여 ### 📌 Spring Cores ### 1. 컴파일 개념과 ClassLoader 및 Spring Bean의 목적 구조적 차이점 * 자바 컴파일 및 로드 과정: 개발자가 작성한 `.java` 소스 파일은 자바 컴파일러(`javac`)에 의해 JVM이 해석하고 실행할 수 있는 바이너리 형태의 `.class` 바이트 코드로 변환된다. 이 변환된 `.class` 파일을 JVM 실행 중에 메모리로 읽어 들여 적재하는 주체가 바로 클래스로더(ClassLoader)다. * ClassLoader의 역할: 클래스로더는 단순히 객체를 인스턴스화하는 것이 아니라, `new` 키워드로 객체를 생성할 수 있도록 클래스의 메타정보를 생성하고 JVM의 메타스페이스(Metaspace) 영역에 등록하여 사용 가능하도록 준비하는 핵심 과정을 수행한다. 클래스로더가 파일 적재를 완료하면 타입을 명세하는 `Class` 메타 객체가 비로소 생성된다. * Spring Bean의 생성 및 관리: 스프링 빈은 클래스로더를 통해 이미 타입 로드가 완료된 메타 정보를 바탕으로 구동된다. 스프링의 `ApplicationContext`가 시작되고 초기화되는 시점에 `BeanDefinition` 설정과 빈 리플렉션(Bean Reflection) 과정을 거쳐 실제 메모리에 살아 움직이는 객체(Bean Instance)를 동적으로 생성하고 생명 주기를 관리한다. * 클래스로더와 스프링 빈의 명확한 비교 구분: * ClassLoader: 목적은 클래스를 JVM에 적재하여 사용 가능한 상태로 만드는 것이며, 산출물은 클래스의 메타정보인 `Class` 객체다. 구동 시점은 JVM 실행 중 처음 해당 클래스가 참조되는 순간이다. * Spring IoC Container: 목적은 적재된 클래스를 가지고 실제 객체(Bean)를 생성하고 DI 및 생명 주기를 관리하는 것이며, 산출물은 실제 살아있는 싱글톤 등의 객체(Bean Instance)다. 구동 시점은 `ApplicationContext`가 시작 및 초기화되는 시점이다. ### 2. Host OS, JVM, WAS(Tomcat) 및 웹 애플리케이션의 물리적 실행 주체와 계층 구조 * JVM의 실행 주체: JVM의 실질적인 실행 주체는 호스트 운영체제(Host OS)다. JVM 자체가 OS 위에서 하나의 독립적인 프로세스로 실행되는 가상의 실행 기계이기 때문이다. * 프로세스 내부의 서블릿 컨테이너 구동: 호스트 OS 위에서 구동되는 자바 프로세스(JVM) 내부에서 웹 애플리케이션 서버인 WAS(Tomcat, Jetty, WebLogic 등)가 실행된다. 이 WAS 인프라 내부에서 실질적인 웹 애플리케이션 스레드와 서블릿 컨테이너 환경이 완벽하게 구축된다. * 인프라 아키텍처 계층 구조: 전체적인 실행 아키텍처는 \[운영체제(OS)] -> \[java 프로세스(JVM)] -> \[WAS (Tomcat 등)] -> \[웹 애플리케이션]의 수직적 계층 구조를 형성하며 유기적으로 맞물려 구동된다. ### 3. Web MVC Servlet Container 내부 스레드 생성과 스레드 풀(Thread Pool) 제어 구조 * 톰캣(Tomcat)의 HTTP 요청 접수 구조: 외부 클라이언트로부터 HTTP 요청 패킷이 인입되면, WAS의 엔트리 포인트인 톰캣 내부의 커넥터(Connector)가 이를 최초로 수신한다. * 스레드 풀 기반의 동적 할당 프로세스: 커넥터가 요청을 접수하면 WAS 내부의 스레드 풀(Thread Pool) 구조인 `Executor`에게 작업을 위임한다. 스레드 풀은 미리 생성하여 유휴 상태로 보유하고 있던 스레드 중 하나를 꺼내어 해당 요청 작업을 처리하도록 동적으로 배정한다. * 요청 처리 전담 스레드의 구동: 할당된 전담 스레드는 서블릿 컨테이너의 내부 실행 흐름을 타고 `HttpServletRequest` 및 `HttpServletResponse` 객체를 생성하여 최종 웹 애플리케이션 레이어로 진입하는 실행 엔진 역할을 수행한다. ### 4. DispatcherServlet의 웹 요청 처리 컴포넌트 간 상세 핵심 흐름 (Lifecycle) * HTTP 요청이 서블릿 컨테이너로 진입하면, 스프링 웹 기술의 중심점인 `DispatcherServlet`이 프론트 컨트롤러(Front Controller)로서 모든 요청을 전면에서 총괄 접수한다. * HandlerMapping을 통한 컨트롤러 탐색: `DispatcherServlet`은 인입된 URL 및 HTTP 메서드 정보를 바탕으로 `HandlerMapping` 컴포넌트를 호출한다. `HandlerMapping`은 매핑 정보를 전수 조사하여 해당 요청을 처리할 수 있는 적절한 타깃 컨트롤러(Handler)의 위치와 함께, 중간에 실행될 인터셉터 목록을 포함한 `HandlerExecutionChain`을 찾아 반환한다. * HandlerAdapter를 통한 동적 실행 매커니즘: 컨트롤러의 형태가 다양할 수 있으므로 `DispatcherServlet`은 인터페이스 기반의 완충재인 `HandlerAdapter`를 호출한다. `HandlerAdapter`는 찾아낸 컨트롤러의 메서드 시그니처와 파라미터를 분석하여 리플렉션 기반으로 비즈니스 컨트롤러 객체를 동적으로 실행(Invoke)한다. * 비즈니스 로직 수행 및 데이터 반환: 실행된 컨트롤러는 하부의 서비스 및 데이터 액세스 레이어를 거쳐 실질적인 비즈니스 로직을 수행한 뒤, 처리 결과 데이터와 뷰 정보를 담은 객체 또는 REST 형태의 원본 페이로드를 `HandlerAdapter`를 거쳐 `DispatcherServlet`에 최종 전달한다. ### 5. Servlet Container Filter와 Spring Container Interceptor의 경계 분리 및 구동 시점 * 필터(Filter)의 소속 및 동작 특성: 필터는 자바 표준 웹 기술인 서블릿 컨테이너(Servlet Container)의 핵심 구성요소다. 스프링 컨텍스트와 완전히 무관한 서블릿 컨테이너 레이어에 소속되어 있기 때문에, 요청이 스프링 핵심 엔진인 `DispatcherServlet`에 도달하기 전과 모든 처리가 끝난 후 응답이 나가는 최외곽 시점에 동작한다. 주로 웹 요청/응답 객체 자체를 가공하거나 글로벌한 인코딩, 보안 검증에 활용된다. * 인터셉터(Interceptor)의 소속 및 동작 특성: 인터셉터는 스프링 컨테이너(Spring Container)가 직접 관리하는 구성요소다. 서블릿 컨테이너를 통과하여 `DispatcherServlet`이 요청을 접수한 이후, 실질적인 비즈니스 컨트롤러(Handler)가 실행되기 직전(`preHandle`)과 실행이 끝난 직후(`postHandle`), 그리고 뷰 렌더링이나 응답 직렬화가 완전히 완료된 시점(`afterCompletion`)으로 세분화되어 동작한다. 스프링 빈 컨텍스트 내부에 존재하므로 스프링 AOP, 공통 트랜잭션 상태 제어 및 사용자 권한 상세 체크 등에 정밀하게 접근할 수 있다. * 전체적인 물리적 요청/응답 실행 라이프사이클 체인 흐름: Client -> Filter -> DispatcherServlet -> Interceptor (preHandle) -> Controller -> Interceptor (postHandle) -> Interceptor (afterCompletion) -> Filter -> Client ### 6. REST API 관점에서의 @ResponseBody와 ResponseEntity 처리 메커니즘 차이점 * @ResponseBody 직렬화 파이프라인: 컨트롤러 메서드 또는 클래스 상단에 `@ResponseBody`가 선언되어 있으면, 스프링 웹 엔진은 뷰 이름(View Name)을 찾는 정적 렌더링 과정을 전면 생략한다. 대신 리턴된 자바 객체 형태의 응답값을 JSON 등의 문자열 형태로 변환하기 위해 `HandlerAdapter` 하부의 `ReturnValueHandler` 메커니즘을 가동한다. * 이 과정에서 구체적으로 `HttpMessageConverter` 인터페이스의 구현체인 `MappingJackson2HttpMessageConverter` 등이 동작하여 객체를 JSON 스트림 데이터로 단순 직렬화(Serialization)하여 HTTP 응답 바디에 직접 기록한다. * ResponseEntity의 가공 및 추상화 메커니즘: 컨트롤러가 단순 객체가 아닌 `ResponseEntity` 객체를 반환하는 경우, `HandlerAdapter`는 전용 응답 처리기인 `ResponseEntityReturnValueHandler`를 매핑하여 호출한다. * `ResponseEntity`는 단순 바디 데이터뿐만 아니라 HTTP 상태 코드(Status Code), HTTP 응답 헤더(Headers) 등 HTTP 메시지 전체 구성 요소를 자바 객체 수준으로 완벽하게 Wrapping한 상위 추상화 객체다. * 이를 통해 개발자는 유연하게 상태 코드를 세분화하여 동적으로 변경할 수 있으며, 공통 Exception Handling 구조와 결합하여 정밀하게 가공된 표준화된 HTTP 전체 응답 객체 시스템을 완성할 수 있다. ### 📌 Spring Application 전처리 과정 정리 ## Spring Application 실행 과정 — Class Loader / JVM / Application Context / Servlet Context / Embedded Tomcat Spring Boot 애플리케이션이 실행될 때 **JVM의 클래스 로딩부터 Application Context 생성, Bean Definition 등록 및 Reflection을 통한 객체 생성, Embedded Tomcat 및 Servlet Context 구성, DispatcherServlet의 HandlerMapping 준비까지** 어떠한 순서로 진행되는지 정리한다. *** ### 1. 전체 실행 흐름 Spring Boot 애플리케이션 실행 시 전체적인 흐름은 다음과 같다. ``` JVM 시작 ↓ Class Loader ↓ .class 파일을 메모리에 로드 ↓ Classpath에 Spring Boot Web 관련 클래스 존재 여부 확인 ↓ Web Application Type 결정 ↓ Application Context 생성 ↓ Bean Definition 스캔 및 등록 ↓ Bean Definition에 기반한 Reflection / 객체 생성 ↓ 의존성 주입(DI) ↓ Embedded Tomcat 구성 및 실행 ↓ Servlet Container 생성 ↓ DispatcherServlet 등록 ↓ Servlet Context 구성 ↓ DispatcherServlet → HandlerMapping 준비 ↓ 실제 HTTP 요청을 받을 준비 완료 ``` > **핵심:**\ > Spring Boot 애플리케이션은 단순히 `main()` 메서드가 실행되는 것으로 끝나는 것이 아니라,\ > **JVM → Class Loader → Application Context → Bean Definition → Bean 생성/DI → Embedded Tomcat → Servlet Context → DispatcherServlet → HandlerMapping** 순서로 웹 애플리케이션 실행 환경을 구축한다. *** ## 2. JVM과 Class Loader ### 2.1 애플리케이션 실행의 시작 Application이 실행되면 가장 먼저 **JVM이 실행**된다. JVM은 **Class Loader**를 통해 컴파일된 `.class` 파일을 메모리에 로드한다. ``` Java Source ↓ .java ↓ 컴파일 .class ↓ Class Loader ↓ JVM 메모리에 로드 ``` 즉, 개발자가 작성한 Java 클래스가 곧바로 Spring Bean이 되는 것이 아니라, 1. Java 코드가 컴파일되어 `.class` 파일이 만들어지고 2. 애플리케이션 실행 시 JVM의 Class Loader가 해당 클래스를 메모리에 로드하며 3. 이후 Spring이 해당 클래스를 기반으로 Bean을 구성한다. *** ### 2.2 Classpath와 Web Application Type 결정 이 과정에서 **Classpath에 Spring Boot Web 관련 클래스가 존재하는지** 등을 기반으로 애플리케이션의 Web Application Type이 결정된다. 예를 들어 `spring-boot-starter-web`이 의존성으로 포함되어 있다면 Servlet 기반 Web 환경을 구성할 수 있는 클래스들이 Classpath에 존재한다. 따라서 Spring Boot는 이를 감지하여 애플리케이션을 **WebMVC(Servlet) 기반 애플리케이션**으로 판단한다. ``` Classpath ↓ Spring Boot Web 관련 클래스 존재 ↓ Servlet 기반 Web 환경으로 판단 ↓ WebMVC Application 구성 ``` *** ## 3. Application Context 생성과 Bean Definition Spring Boot는 Web Application으로 판단된 이후 **Application Context를 생성**한다. 이 시점에서 중요한 작업 중 하나가 **Bean 스캔 및 Bean Definition 등록**이다. > **Servlet Context보다 Application Context가 먼저 생성된다.** *** ### 3.1 Bean Definition이란? **Bean Definition**은 특정 객체를 Spring Container가 **어떠한 방식으로 생성하고 관리할 것인지에 대한 명세**이다. 즉, Bean Definition 자체가 실제 객체는 아니다. ``` Bean Definition = "이 객체를 어떻게 생성하고 관리할 것인가?" 에 대한 정보 ``` 예를 들어 다음과 같은 클래스가 있다고 하자. ```java @Service public class UserService { } ``` Spring은 컴포넌트 스캔 등을 통해 `UserService`를 Bean으로 관리해야 한다는 것을 발견하고, 해당 Bean을 생성하기 위한 **Bean Definition**을 구성한다. *** ## 4. Bean Definition → Reflection을 통한 객체 생성 → DI Bean Definition이 구성되면 Spring은 해당 정보를 기반으로 실제 Bean 객체를 생성한다. 이 과정에서 **Java Reflection**이 활용된다. ``` Bean Definition ↓ Reflection ↓ 객체 생성 ↓ 의존성 주입(DI) ↓ Spring Bean 완성 ``` 즉, > **Bean Definition은 "어떻게 만들 것인지"에 대한 명세이고, 실제 객체 생성은 이후 Reflection 등을 활용하여 수행된다.** *** ### 4.1 Bean 생성과 의존성 주입 Bean 객체가 생성된 이후에는 Bean 사이의 의존성 주입(DI) 등이 수행된다. 예를 들어 다음과 같은 구조가 있다면, ```java @Service public class OrderService { private final UserService userService; public OrderService(UserService userService) { this.userService = userService; } } ``` Spring은 `OrderService`를 생성할 때 필요한 `UserService` Bean을 찾아 주입한다. 따라서 Application Context가 구성되는 과정에서 Spring이 관리해야 할 Bean들의 객체 생성 및 의존성 관계가 완성된다. *** ## 5. Bean 생성 과정에서의 Life Cycle Bean 생성 및 의존성 주입 과정에서는 Bean Life Cycle도 시작된다. ``` Bean Definition ↓ Bean 객체 생성 ↓ 의존성 주입 ↓ Bean 초기화 과정 ↓ Bean 사용 가능 ``` 따라서 **Application Context 생성 → Bean Definition 등록 → Bean 객체 생성 및 DI**는 Spring 애플리케이션 초기화에서 매우 중요한 과정이다. *** ## 6. `spring-boot-starter-web`과 Servlet / Tomcat ### 6.1 `spring-boot-starter-web` 의존성 Spring Boot 프로젝트에서 다음과 같이 `spring-boot-starter-web` 의존성을 추가하면, ```gradle implementation 'org.springframework.boot:spring-boot-starter-web' ``` Spring Boot 내부에서 **Servlet 관련 클래스와 Embedded Tomcat 관련 구성**을 사용할 수 있게 된다. 즉, `starter-web`을 추가하면 Spring Boot가 Servlet 기반 Web Application을 구성할 수 있는 환경이 만들어진다. *** ## 7. Servlet Class / Servlet 환경 감지 및 조성 Spring Boot에서 `spring-boot-starter-web` 의존성을 추가하면 내부적으로 **Servlet 관련 클래스와 Embedded Tomcat**이 포함된다. Spring Boot의 **Auto Configuration**은 Classpath에 존재하는 클래스를 기반으로 현재 애플리케이션의 환경을 판단한다. > **Auto Configuration이란 Servlet 클래스가 Classpath에 존재할 때 Servlet(Web) 환경이라고 판단하여 그에 맞는 설정을 자동으로 구성하는 과정이다.** 즉, ``` spring-boot-starter-web 추가 ↓ Servlet 관련 클래스 존재 ↓ Spring Boot가 Servlet Web 환경이라고 판단 ↓ Servlet 기반 Web Application 구성 ``` *** ## 8. Embedded Tomcat `spring-boot-starter-web`에는 **Embedded Tomcat**을 사용할 수 있는 구성이 포함되어 있다. Spring Boot의 Embedded Tomcat Auto Configuration이 활성화되면 `TomcatServletWebServerFactory` Bean을 생성하고 이를 기반으로 Tomcat을 구성한다. ``` spring-boot-starter-web ↓ Embedded Tomcat 관련 클래스 존재 ↓ TomcatServletWebServerFactory ↓ Embedded Tomcat 생성 ↓ Tomcat 실행 ``` 여기서 중요한 점은 일반적인 외부 WAS에 WAR 파일을 배포하는 방식과 달리, Spring Boot에서는 **Tomcat 자체가 애플리케이션 내부에서 실행 가능한 WAS 형태로 포함**된다는 것이다. *** ## 9. Embedded Tomcat 실행과 Servlet Container Embedded Tomcat이 실행되면 **Servlet Container**가 구성된다. 그리고 이 Servlet Container에 Spring MVC의 핵심 Servlet인 **DispatcherServlet이 등록**된다. ``` Embedded Tomcat 실행 ↓ Servlet Container 생성 ↓ DispatcherServlet 등록 ↓ Spring MVC 요청 처리 환경 구성 ``` 즉, Spring Boot가 단순히 Spring Bean만 생성하는 것이 아니라, > **Spring Container + Servlet Container를 함께 구성하여 실제 HTTP 요청을 받을 수 있는 환경을 만든다.** *** ## 10. Application Context와 Servlet Context의 관계 여기서 **Application Context와 Servlet Context를 구분**할 필요가 있다. Spring Boot의 초기화 과정에서는 **Application Context가 Servlet Context보다 먼저 생성**된다. ``` Application Context ↓ Bean Definition ↓ Bean 생성 ↓ DI ↓ Servlet/Tomcat 환경 구성 ↓ Servlet Context ↓ DispatcherServlet ``` 즉, Spring이 관리하는 Bean 및 애플리케이션 구성 환경을 먼저 만들고, 이후 Servlet 기반의 Web 실행 환경을 구성한다고 이해할 수 있다. *** ## 11. DispatcherServlet Embedded Tomcat의 Servlet Container가 구성되면 Spring MVC의 **DispatcherServlet**이 Servlet Container에 등록된다. DispatcherServlet은 Spring MVC에서 **요청을 위임받는 프론트 컨트롤러(Front Controller)** 역할을 한다. ``` Client ↓ Tomcat ↓ Servlet Container ↓ DispatcherServlet ↓ HandlerMapping ↓ Controller ``` *** ### 11.1 DispatcherServlet과 HandlerMapping DispatcherServlet은 실제 Controller의 `@RequestMapping` 정보를 직접 관리하는 것이 아니다. **실제 RequestMapping 정보는 HandlerMapping이 관리한다.** 구조적으로 보면 다음과 같다. ``` DispatcherServlet ↓ HandlerMapping ↓ RequestMappingHandlerMapping ↓ Controller + @RequestMapping 정보 ``` 즉, * **DispatcherServlet** → 요청을 위임하는 Front Controller * **HandlerMapping** → 들어온 요청을 처리할 Handler를 찾기 위한 정보 관리 * **RequestMappingHandlerMapping** → Controller의 `@RequestMapping` 정보를 기반으로 요청과 Handler를 매핑 하는 구조이다. *** ## 12. DispatcherServlet의 요청 처리 준비 DispatcherServlet은 HandlerMapping에 요청을 위임할 준비를 완료한다. 이 과정까지 완료되면 **실제 HTTP 요청을 받을 준비가 끝난 것**으로 볼 수 있다. ``` Application Context 생성 ↓ Bean Definition 등록 ↓ Bean 생성 / DI ↓ Embedded Tomcat 실행 ↓ Servlet Container 구성 ↓ DispatcherServlet 등록 ↓ HandlerMapping 구성 ↓ 실제 HTTP 요청 수신 준비 완료 ``` 따라서 DispatcherServlet이 HandlerMapping을 통해 Controller와 `@RequestMapping` 정보를 기반으로 요청을 처리할 수 있는 환경이 구성된다. *** ## 13. 전체 구조 한눈에 보기 ### 13.1 Spring Container 관점 ``` JVM ↓ Class Loader ↓ .class 파일 로드 ↓ Classpath 확인 ↓ Spring Boot Web 환경 감지 ↓ Application Context 생성 ↓ Bean Definition 스캔/등록 ↓ Bean Reflection 객체 생성 ↓ Dependency Injection ↓ Bean 초기화 ``` *** ### 13.2 Web Server / Servlet 관점 ``` spring-boot-starter-web ↓ Servlet 관련 클래스 + Embedded Tomcat 존재 ↓ Spring Boot Auto Configuration ↓ Servlet Web 환경 판단 ↓ Embedded Tomcat Auto Configuration ↓ TomcatServletWebServerFactory ↓ Embedded Tomcat 생성/실행 ↓ Servlet Container 생성 ↓ DispatcherServlet 등록 ↓ Servlet Context 구성 ``` *** ### 13.3 Spring MVC 요청 처리 준비 ``` DispatcherServlet ↓ HandlerMapping ↓ RequestMappingHandlerMapping ↓ Controller ↓ @RequestMapping 정보 ``` DispatcherServlet은 **요청을 위임하는 Front Controller**이고, 실제 `@RequestMapping` 정보는 **HandlerMapping**이 관리한다. *** ## 14. 최종 실행 순서 전체 과정을 하나로 합치면 다음과 같이 이해할 수 있다. ``` [1] JVM 시작 ↓ [2] Class Loader가 .class 파일을 메모리에 로드 ↓ [3] Classpath에 Spring Boot Web 관련 클래스 존재 여부 확인 ↓ [4] Spring Boot가 Web Application Type을 결정 ↓ [5] Application Context 생성 ↓ [6] Bean 스캔 ↓ [7] Bean Definition 등록 ↓ [8] Bean Definition을 기반으로 Reflection 등을 이용하여 객체 생성 ↓ [9] 의존성 주입(DI) ↓ [10] Bean Life Cycle 진행 ↓ [11] Embedded Tomcat Auto Configuration 활성화 ↓ [12] TomcatServletWebServerFactory를 통해 Embedded Tomcat 구성 ↓ [13] Embedded Tomcat 실행 ↓ [14] Servlet Container 생성 ↓ [15] DispatcherServlet 등록 ↓ [16] Servlet Context 구성 ↓ [17] DispatcherServlet이 HandlerMapping에 요청을 위임할 준비 완료 ↓ [18] RequestMappingHandlerMapping이 Controller의 @RequestMapping 정보를 관리 ↓ [19] 실제 HTTP 요청을 받을 준비 완료 ``` *** ## 15. `starter-web`과 `starter-webflux`의 차이 Spring Boot에서 `starter-web` 대신 `starter-webflux`를 사용하는 경우에는 동작 방식이 달라진다. ``` starter-web ↓ Servlet 기반 Web Application ↓ Embedded Tomcat ↓ DispatcherServlet ``` 반면, ``` starter-webflux ↓ Reactive Web Application ↓ Servlet 기반이 아닌 Reactive 환경 ↓ 기본적으로 Netty 사용 ``` 즉, > `starter-web`은 **Servlet 기반 Web 환경**을 구성하고, `starter-webflux`는 **Reactive 기반 Web 환경**을 구성한다. 따라서 `starter-webflux`를 사용하는 경우 Servlet이 아니라 **Reactive Web 환경임을 감지하여 Embedded Tomcat이 아닌 Netty가 동작**하게 된다. *** ## 16. 핵심 정리 #### Class Loader * JVM이 실행될 때 컴파일된 `.class` 파일을 메모리에 로드한다. #### Application Context * Spring이 Bean을 관리하기 위한 핵심 Container이며, Servlet Context보다 먼저 생성된다. #### Bean Definition * Bean 객체 자체가 아니라 **해당 Bean을 어떠한 방식으로 생성하고 관리할 것인지에 대한 명세**이다. #### Reflection * Bean Definition에 기반하여 실제 Bean 객체를 생성하는 과정에서 Java Reflection 등이 활용된다. #### Dependency Injection * 생성된 Bean 사이의 의존관계를 Spring이 연결한다. #### Embedded Tomcat * `spring-boot-starter-web`을 통해 Servlet 기반 Web 환경을 구성할 때 Spring Boot 내부에서 실행되는 WAS이다. #### Servlet Container * Tomcat이 제공하는 Servlet 실행 환경이며, 여기에 DispatcherServlet 등이 등록된다. #### DispatcherServlet * Spring MVC의 **Front Controller**로서 HTTP 요청을 전달받고 적절한 Handler에게 요청을 위임한다. #### HandlerMapping * 요청을 처리할 Handler를 찾기 위한 정보를 관리한다. #### RequestMappingHandlerMapping * Controller의 `@RequestMapping` 정보를 기반으로 HTTP 요청과 Handler를 매핑한다. *** ### 17. 전체 관계 요약 ``` JVM │ ▼ Class Loader │ ▼ .class 메모리 로드 │ ▼ Classpath / Web 환경 감지 │ ▼ Application Context │ ┌──────────┴──────────┐ ▼ ▼ Bean Definition Bean 관리 │ ▼ Reflection을 통한 객체 생성 │ ▼ Dependency Injection │ ▼ Bean Life Cycle │ ▼ Embedded Tomcat Auto Configuration │ ▼ TomcatServletWebServerFactory │ ▼ Embedded Tomcat │ ▼ Servlet Container │ ▼ DispatcherServlet │ ▼ HandlerMapping │ ▼ RequestMappingHandlerMapping │ ▼ Controller + @RequestMapping │ ▼ HTTP 요청 처리 ``` > **핵심적으로 기억할 흐름** > > **JVM → Class Loader → Application Context → Bean Definition → Reflection/Bean 생성 → DI → Embedded Tomcat → Servlet Container → DispatcherServlet → HandlerMapping → Controller** > > 이 전체 초기화 과정이 완료되어야 Spring Boot 애플리케이션이 실제 HTTP 요청을 받을 수 있는 상태가 된다. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://leehyokyun.gitbook.io/openbook/2-5.-spring-core-2-jvm-web-mvc-bean.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.