#6 - Controller에 오기 전, 서버 안에서 벌어지는 일

Controller에 오기 전, 서버 안에서 벌어지는 일

Spring Boot 4 초보자를 위한 진짜 서버 이야기
"요청은 Controller로 바로 오는 게 아니다"

이 강의의 목표

이 강의의 목표는 단순하다.

Controller 메서드 한 줄이 실행되기까지, 서버 안에서 어떤 일이 벌어지는지 이해한다.

Spring을 전혀 몰라도 이해할 수 있어야 한다
"왜 여기서 막히는지"를 구조로 설명할 수 있어야 한다
Filter / Security / DispatcherServlet의 경계가 명확해야 한다

먼저 큰 그림부터

요청은 이렇게 이동한다.

text

[사용자]
   ↓
[웹 서버 / WAS (Tomcat)]
   ↓
[Servlet Filter 영역]
   ↓
[Spring Context 영역]
   ↓
[DispatcherServlet]
   ↓
[Interceptor]
   ↓
[Controller]

👉 Controller는 맨 마지막이다.
👉 대부분의 일은 Controller에 오기 전에 이미 끝난다.

1. 사용자의 요청: 모든 일의 시작

1.1 사용자는 무엇을 보낼까?

브라우저
모바일 앱
Postman / curl
다른 서버

이들이 보내는 것은 단 하나.

HTTP 요청

text

POST /orders HTTP/1.1
Host: api.example.com
Authorization: Bearer xxx
Content-Type: application/json

{ "quantity": -10 }

⚠️ 서버 입장에서 이 요청은:

진실 ❌
사실 ❌
주장(Claim) ⭕

2. WAS (Tomcat): Spring 이전의 세계

2.1 WAS의 역할

Tomcat 같은 WAS는 Spring을 모른다.

WAS의 관심사는 이것뿐이다.

포트 열기 (8080)
HTTP 파싱
Thread 할당
Servlet 호출

WAS는 "Java 웹 실행기"다.

2.2 여기서 중요한 경계

[ Tomcat 영역 ] | [ Spring 영역 ]

Tomcat은 표준(Servlet 스펙)만 안다
Spring은 Tomcat 위에 올라탄 손님이다

👉 이 경계를 이해 못 하면 Filter / Security가 헷갈린다.

3. Servlet Filter: 가장 바깥의 방어선

3.1 Filter란 무엇인가?

Filter는 Servlet 표준 기술이다.

Spring이 없어도 존재한다.

text

요청 → Filter → Servlet

3.2 Filter에서 주로 하는 일

인코딩 설정 (UTF-8)
CORS 처리
로깅
XSS 방어
Spring Security 진입 지점

java

public void doFilter(req, res, chain) {
    // 요청 가공
    chain.doFilter(req, res);
    // 응답 가공
}

👉 Filter는 요청을 막을 수 있다.

4. Spring Filter: Spring Context의 시작

여기서부터 Spring이 개입한다.

4.1 DelegatingFilterProxy

Spring Security는 사실 Servlet Filter다.

하지만 내부 구현은 Spring Bean이다.

이를 연결하는 다리가 바로:

DelegatingFilterProxy

text

Servlet Filter
   ↓ 위임
Spring Security Filter Chain

👉 이 시점부터 Spring Context가 열렸다.

5. Spring Security Filter Chain: 대부분의 요청은 여기서 끝난다

5.1 Security는 Controller 앞에 있다

Spring Security는 Controller보다 훨씬 앞단에 있다.

여기서 하는 일:

인증(Authentication)
인가(Authorization)
세션 / 토큰 검증
로그인 여부 판단

5.2 왜 Controller보다 앞에 있을까?

이유는 단순하다.

권한 없는 요청은 Controller를 알 필요가 없다.

인증 실패 → 401
권한 없음 → 403

👉 이 요청은 Controller까지 가지 않는다.

6. DispatcherServlet: Spring MVC의 관문

6.1 DispatcherServlet이란?

모든 HTTP 요청의 교통 정리 담당자

Spring MVC의 핵심이다.

6.2 DispatcherServlet의 질문

요청이 들어오면 묻는다.

이 URL을 처리할 Controller는 누구?
어떤 메서드?
파라미터는 어떻게 매핑?

이때 사용하는 것들:

HandlerMapping
HandlerAdapter
ArgumentResolver

👉 아직 Controller는 실행되지 않았다.

7. Interceptor: Controller 직전의 문지기

7.1 Interceptor의 위치

DispatcherServlet
   ↓
Interceptor
   ↓
Controller

7.2 Interceptor는 무엇을 하나?

로그인 사용자 체크
권한 재확인
요청/응답 로깅
메뉴 접근 제어

java

preHandle()  // Controller 전
postHandle() // Controller 후

👉 Filter와 비슷하지만 Spring Bean이다.

8. 드디어 Controller

여기까지 왔다는 것은:

HTTP 형식 OK
인코딩 OK
보안 OK
라우팅 OK

Controller는 이미 정제된 요청을 받는다.

그래서 Controller의 책임은 명확하다.

요청 구조 검증
Service 호출
응답 반환

9. 초보자가 가장 많이 착각하는 지점

❌ "Controller에서 인증하면 되죠"

→ 이미 늦었다

❌ "Filter랑 Interceptor는 비슷하죠"

→ 위치와 책임이 다르다

❌ "Spring이 다 알아서 해준다"

→ Spring은 설계된 대로만 동작한다

10. 한 장으로 정리

[Tomcat]
  └─ Servlet Filter
        └─ Spring Security Filter
              └─ DispatcherServlet
                    └─ Interceptor
                          └─ Controller

👉 Controller는 시작이 아니라 끝이다.

마무리 한 문장

"Controller 코드는 시스템에서 가장 늦게 실행되는 코드다."

다음 강의에서는:

이 흐름을 코드로 어떻게 설계해야 하는지
Filter / Interceptor를 언제 써야 하는지
Controller를 얇게 유지하는 이유

를 이어서 다룬다.

#6 - Controller에 오기 전, 서버 안에서 벌어지는 일

중년개발자

Controller에 오기 전, 서버 안에서 벌어지는 일

이 강의의 목표

먼저 큰 그림부터

1. 사용자의 요청: 모든 일의 시작

1.1 사용자는 무엇을 보낼까?

2. WAS (Tomcat): Spring 이전의 세계

2.1 WAS의 역할

2.2 여기서 중요한 경계

3. Servlet Filter: 가장 바깥의 방어선

3.1 Filter란 무엇인가?

3.2 Filter에서 주로 하는 일

4. Spring Filter: Spring Context의 시작

4.1 DelegatingFilterProxy

5. Spring Security Filter Chain: 대부분의 요청은 여기서 끝난다

5.1 Security는 Controller 앞에 있다

5.2 왜 Controller보다 앞에 있을까?

6. DispatcherServlet: Spring MVC의 관문

6.1 DispatcherServlet이란?

6.2 DispatcherServlet의 질문

7. Interceptor: Controller 직전의 문지기

7.1 Interceptor의 위치

7.2 Interceptor는 무엇을 하나?

8. 드디어 Controller

9. 초보자가 가장 많이 착각하는 지점

❌ "Controller에서 인증하면 되죠"

❌ "Filter랑 Interceptor는 비슷하죠"

❌ "Spring이 다 알아서 해준다"

10. 한 장으로 정리

마무리 한 문장

목차

댓글 0