[백엔드 여정] 01. Spring MVC 구조와 핵심 원리 완벽 정리

게시 2026/03/23 업데이트 2026/03/23

By Choi Jiwon

5 분읽는 시간

👋 백엔드 공부의 시작, Spring MVC

지난주부터 본격적으로 백엔드 공부를 시작하며 Spring MVC의 핵심 구조를 배웠습니다. 단순히 코드를 짜는 것을 넘어, 전체적인 요청의 흐름을 이해하는 것이 중요하다는 것을 깨달은 한 주였습니다.

⚙️ 1. Dispatcher Servlet: 모든 요청의 ‘단일 창구’

과거에는 페이지 수만큼 서블릿을 만들어야 해서 관리가 힘들었지만, 현재는 Front Controller 패턴인 Dispatcher Servlet이 모든 요청을 가장 먼저 받아 적절한 곳으로 배분합니다.

요청 처리의 3박자 (Mapping, Adapter, Converter)

Handler Mapping (길 찾기): URL을 보고 어떤 컨트롤러의 메서드와 연결할지 길을 찾아줍니다.
Handler Adapter (실행): 주소는 찾았으니 이제 실제 코드를 돌려주는 역할을 합니다.
Http Message Converter (통역사) ⭐중요: 자바 객체를 JSON으로 번역해서 브라우저에 보내거나, 반대로 JSON을 자바 객체로 변환해줍니다.

🔑 2. 데이터를 낚아채는 법 (Annotation)

URL이나 본문에서 데이터를 가져올 때 상황에 맞는 어노테이션을 써야 합니다.

@PathVariable: /users/1처럼 경로 자체가 데이터일 때 씁니다. 자원을 식별할 때 주로 사용해요.
@RequestParam: /users?name=지원처럼 이름이 검색 조건일 때, 즉 추가 옵션일 때 씁니다.
@RequestBody: JSON은 데이터가 많고 복잡해서 URL에 담을 수 없으므로, 보이지 않는 Body(본문)에 담아 보낼 때 씁니다. 이걸 자바 객체로 쏙 뽑아주는 친구예요.

📦 3. Entity와 DTO, 왜 나눠야 할까?

데이터베이스와 직접 소통하는 Entity와 계층 간 데이터를 전달하는 DTO는 반드시 분리해야 합니다.

🚫 Entity를 직접 반환하면 안 되는 이유

보안 문제: 패스워드나 내부 관리용 필드 같은 민감한 정보가 노출될 수 있습니다.
API 스펙 보호: 테이블 컬럼명이 바뀌어도 API 응답 필드명은 유지해서 클라이언트의 혼란을 막아야 합니다.
불필요한 데이터 방지: 클라이언트에게 꼭 필요한 데이터만 골라서 보내는 것이 효율적입니다.

🏛️ 4. 백엔드의 전체 흐름 (계층 구조)

이해를 돕기 위해 식당 시스템에 비유해 보았습니다.

Controller (식당 홀 직원): 손님의 주문(요청)을 받아 주방에 전달하고 응답을 반환합니다.
Service (주방): 실제 요리(비즈니스 로직)가 이루어지는 곳입니다.
Repository (냉장고/재료 창고): DB에 접근하여 재료를 꺼내오거나 저장합니다.
Entity (실제 식재료): DB 테이블과 1:1로 대응되는 데이터 그 자체입니다.

🎁 5. ResponseEntity: 서버의 매너 있는 응답

단순히 데이터를 리턴하기보다 ResponseEntity를 사용하면 HTTP 상태 코드(200 OK, 201 Created, 404 Not Found 등)를 함께 담아 보낼 수 있습니다. 상태 코드는 클라이언트가 응답을 어떻게 처리할지 판단하는 기준이 되는 ‘대화의 기본’입니다!

🗓️ 다음 주 예고: JPA

이번 주에 객체와 DB의 차이를 살짝 맛보았는데, 다음 주에는 이 둘을 연결해주는 마법 같은 JPA에 대해 배울 예정입니다. 벌써 기대가 되네요!

Backend, Spring