Spring 1일차(4)

스프링은 MVC 패턴이 기본이기에 MVC 패턴을 간단히 살펴본다.

 

MVC

MVC는 애플리케이션을 세 가지 역할로 분리하여 구성하는 소프트웨어 설계 패턴으로 사용자의 요청을 받아 로직 처리하고 결과 화면을 보여주는 역할을 나눈다.

구성요소	역학
Model	애플리케이션의 데이터와 비즈니스 로직 담당
View	사용자에게 보여지는 화면 구성
Controller	사용자 입력 처리 및 Model과 View 연결

 

MVC 패턴을 사용하는 이유

MVC 패턴을 사용하지 않아도 모든 걸 한 파일에서 처리할 수 있지만, 가독성이 떨어지고 유지보수가 힘들다.

로직과 화면 분리되어 있지 않아 테스트하기 어렵고 퍼블리셔와 개발자가 함께 작업이 불가능하다.

 

MVC구조로 작성

• 관심사 분리 (SoC): 역할별로 코드가 나뉘어 구조가 명확해짐
• 유지보수 용이: 뷰 변경 시 로직 영향 없음, 로직 변경 시 UI 영향 없음
• 테스트 편리: 비즈니스 로직만 단독 테스트 가능
• 협업 효율 향상: 백엔드와 프론트 작업 분리 가능

 

스프링 MVC

Model2 아키텍처 기반의 웹 애플리케이션 프레임워크로, 요청-처리-응답의 흐름을 명확히 분리하여 유지보수성과 확장성을 높인 구조이다.(model2는 MVC 패턴을 웹 개발에 도입한 구조이다.)

웹 요청을 DispatcherServlet이 중심이 되어 처리하며, 핵심 컴포넌트들을 조합해 자동화된 MVC 흐름을 제공한다.

색상별 의미	설명
🔵 파란색	Spring 프레임워크가 제공하는 컴포넌트
🟣 보라색	개발자가 구현해야 하는 컴포넌트 (Controller 등)
🟢 초록색	View (템플릿 파일 포함) – 일부는 Spring 제공, 일부는 개발자 구현

 

구성요소와 역할

구성요소	설명
DispatcherServlet	요청의 시작과 끝을 담당하며, 클라이언트 요청을 받아서 → 어떤 컨트롤러가 처리할지 찾고 → 결과를 받아 → 사용자에게 보여줌.
HandlerMapping	요청 URL에 맞는 컨트롤러(핸들러)를 찾는 컴포넌트로 URL과 컨트롤러 메서드 매핑 정보를 가지고 있음. DispatcherServlet이 요청을 전달하면, HandlerMapping은 "이 URL은 이 컨트롤러야!" 하고 알려줌.
HandlerAdapter	요청을 실행할 수 있는 형태로 컨트롤러를 호출해주는 컴포넌트
Controller	클라이언트 요청에 따라 비즈니스 로직을 실행, 필요한 데이터를 조회하고(Model에 담고), 어떤 뷰를 보여줄지 뷰 이름을 반환
ModelAndView	모델 데이터 + 뷰 이름을 함께 담는 객체
ViewResolver	뷰 이름에 해당하는 View 객체를 찾아주는 컴포넌트로 컨트롤러가 준 뷰 이름을 받아서실제 파일 위치를 찾음 (예: /WEB-INF/views/hello.jsp)
View	실제 화면 출력 역할 (예: JSP, Thymeleaf 등)로 ViewResolver가 찾아준 뷰를 바탕으로Model의 데이터를 화면에 표시

 

스프링 웹 요청 처리 흐름

1. 브라우저에서 사용자가 /meber.me이라는 url을 보내면, 먼저 DispatcherServlet이 받는다.
2. DispatcherServlet은 요청을 처리할 Controller를 찾기 위해 HandlerMapping에 조회를 요청하고, 매핑 정보를 기반으로 Controller와 메서드를 결정한다.
3. DispatcherServlet은 HandlerAdapter를 통해 해당 컨트롤러를 실행 가능한 형태로 변환 후 실제로 호출한다.
4. Controller는 비즈니스 로직을 수행한 후 결과 데이터를 Model 객체에 담고 사용자에게 응답할 View의 파일명을 반환한다.
5. DispatcherServlet은 이 View 이름을 ViewResolver에 전달한다
6. ViewResolver은 설정된 경로와 접미사를 바탕으로 실제 View 파일(WEB-INF/views/memberPage.jsp)을 찾아 View 객체를 생성한다.
7. 이후 DispatcherServlet은 View 객체에 화면 렌더링을 요청하고 View는 Model 객체에 담긴 데이터 기반으로 최종 화면을 만들어 브라우저에 응답으로 전송한다.

 

스프링 컨테이너

 

스프링 컨테이너는 IoC(제어의 역전)를 구현한 중심 구성 요소로, 애플리케이션에서 사용되는 객체(Bean)를 생성하고, 관리하며, 필요할 때 의존성을 주입(DI)하고 초기화부터 소멸까지의 생명주기를 관리하는 역할을 한다.

이러한 스프링 컨테이너의 대표 구현체는 ApplicationContext이다.

 

ApplicationContext

스프링 컨테이너의 실질적인 구현체이며, 기본적으로 Been(컨테이너가 생성하고 관리하는 객체)을 관리하는 객체인 BeanFactory를 확장해 더 강력한 기능(국제화, 이벤트 처리, AOP, 환경 설정 등)을 포함한다

스프링에서의 대부분의 IoC/DI 기능은 ApplicationContext를 통해 제공됨. 즉, 스프링 컨테이너라는 말은 실질적으로 ApplicationContext를 지칭한다고 볼 수 있다.

우리가 스프링 애플리케이션을 실행하면 ApplicationContext가 자동으로 생성되고 그 안에서 모든 Bean이 등록되고 관리된다.

기능	설명
Bean 등록 및 생성	설정 파일(@Component, @Bean 등)을 읽고 객체 생성
DI(의존성 주입)	필요한 객체를 자동으로 주입
Bean 생명주기 관리	초기화, 소멸 등 관리 (@PostConstruct, @PreDestroy)
이벤트 발행	컨테이너 이벤트(ApplicationEvent)를 발행하고 리스닝 가능
국제화(i18n)	메시지 번역 기능 지원
환경 정보 제공	Environment, PropertySource 등 시스템 설정 읽기

 

Spring Boot에서 ApplicationContext의 생성

@SpringBootApplication
public class MyApp {
    public static void main(String[] args) {
        SpringApplication.run(MyApp.class, args); // 여기서 시작!
    }
}

@SpringBootApplication은 @ComponentScan과 @Configuration, @EnableAutoConfiguration을 포함하는 복합 어노테이션이다.

이 main문을 실행하면 내부에서 ApplicationContext를 생성하고 초기화한다.

 

내부 동작 요약

1. SpringApplication.run() 실행
2.  환경 설정(Environment) 로딩
3. 적절한 ApplicationContext 타입 결정
4. ApplicationContext 생성 및 리프레시 (refresh())
5. Bean 등록, DI 수행
6. CommandLineRunner, ApplicationRunner 실행
7. 애플리케이션 실행 완료