[Spring MVC] 브라우저의 요청은 어떻게 처리될까? 핵심 요약

Spring MVC 특강에서 다룬 수많은 개념 중, 실제 프로젝트를 설계하고 개발할 때 반드시 머릿속에 있어야 할 5가지 뼈대를 정리

💡 핵심 요약 한
"클라이언트는 요청을 보내고, 서버는 각자의 역할(Controller/Service/Repository)에 맞춰 조립된 빈(Bean)들을 통해 응답을 만들어낸다."

1. 모든 요청의 입구: DispatcherServlet

클라이언트(브라우저, Postman 등)가 보낸 API 요청은 곧바로 우리가 만든 Controller로 순간이동하지 않습니다. 식당의 지배인처럼 모든 요청을 가장 먼저 받고 교통정리를 해주는 입구가 바로 DispatcherServlet입니다.

1 클라이언트가 HTTP 요청을 보냄 (예: POST /api/orders)

2 DispatcherServlet이 요청을 가로채서 받음

3 HandlerMapping을 통해 이 URL을 담당하는 Controller를 찾음

4 Controller의 메서드를 실행하고 결과를 돌려받음

5 결과를 JSON 등으로 변환하여 클라이언트에게 응답

코드의 유지보수와 테스트를 위해 역할에 따라 계층을 나눕니다. 예를 들어 미니 주문 서비스를 개발할 때, 하나의 클래스에 HTTP 요청 처리, 재고 확인 로직, DB 저장을 모두 넣으면 코드가 쉽게 망가집니다. 관심사의 분리가 필수입니다.

처음 스프링을 다루면 애노테이션이 마법을 부리는 것 같지만, 사실 @RestController, @Service 등은 스스로 아무 일도 하지 못합니다.

스프링 컨테이너가 이 이름표들을 읽고, "아, 이 클래스는 컨트롤러 역할을 하니까 요청을 연결해 줘야겠구나"라고 판단하여 실제 동작을 수행하는 것.

개발자가 직접 new Service()를 통해 객체를 생성하지 않습니다. 객체의 생성과 관리 권한을 스프링에게 넘겼는데, 이를 IoC (제어의 역전)라고 합니다.

또한, Controller가 Service를 필요로 할 때 스프링이 알아서 생성된 Service 객체를 넣어주는 방식을 DI (의존성 주입)이라고 한다.

이를 통해 클래스 간의 결합도가 낮아져 유연한 설계가 가능해집니다.

스프링이 관리하는 객체(Bean)는 기본적으로 Singleton(싱글톤)으로 생성됩니다.

즉, 컨테이너 안에 딱 한 개의 객체만 만들어져서 모든 클라이언트의 요청이 그 하나의 객체를 공유하여 사용한다.

🚨 실무 주의사항: 싱글톤 객체는 상태(State)를 가지면 안 됩니다.
Service나 Controller의 필드 변수(전역 변수)에 특정 클라이언트의 데이터를 저장하면, 동시에 접속한 다른 사용자의 데이터와 뒤섞이는 심각한 버그가 발생한다.

데이터를 저장하거나 수정해야 하는 변수는 반드시 메서드 내부의 지역 변수로 사용해야 합니다.

위의 5가지 흐름, "요청 → DispatcherServlet → Controller → Service → Repository → DB"의 구조가 가장 중요한거 같다.