[Spring] MVC 10편 - 프론트 컨트롤러 v1~v5 정리

이번 글에서는 프론트 컨트롤러 패턴을 기반으로, v1 → v5까지 프레임워크가 점진적으로 발전하는 과정을 한 번에 정리한다.

이 과정을 이해하면 스프링 MVC의 핵심 구조와 발전 방향이 한눈에 들어오고, 실제 프로젝트에서 확장성 있는 아키텍처를 설계할 때 큰 도움이 된다.

---

1. v1 - 프론트 컨트롤러 도입

목표

• 기존 여러 서블릿을 하나의 입구(Front Controller)로 통합.
• 공통 처리 로직을 한 곳에서 관리.

특징

• ControllerV1 인터페이스를 만들고, 모든 컨트롤러가 이를 구현.
• URL 매핑(controllerMap)을 통해 어떤 요청이 어떤 컨트롤러로 갈지 결정.
• JSP forward 로직은 각 컨트롤러에서 직접 처리.

장점

• 요청 입구 단일화 → 공통 기능(로그, 인증 등) 처리 용이.
• 유지보수성 향상.

한계

• forward 로직이 중복.
• 컨트롤러가 여전히 HttpServletRequest/Response에 강하게 종속.

---

2. v2 - MyView 도입 (뷰 로직 분리)

목표

• forward 코드 중복 제거.

특징

• MyView 객체를 도입해 뷰 이동 로직(dispatcher.forward)을 공통화.
• 컨트롤러는 단순히 new MyView("...")를 반환.

장점

• 중복 제거로 코드 간결화.
• 뷰 호출 로직이 일관되게 관리됨.

한계

• 여전히 Servlet API에 종속.

3. v3 - Servlet 종속성 제거 + ModelView

목표

• 컨트롤러가 Servlet API 없이도 동작.
• 뷰 경로 중복 제거(논리 뷰 이름 사용).

특징

• 요청 파라미터를 Map<String, String>으로 전달.
• 응답 데이터는 Map<String, Object> 모델에 저장.
• ModelView 객체에 뷰 이름과 모델을 함께 담아 반환.
• 프론트 컨트롤러가 뷰 리졸버를 통해 논리 뷰 이름을 실제 경로로 변환.

장점

• 테스트 코드 작성 용이.
• 구현 코드와 서블릿 기술 분리.
• 뷰 경로 변경 시 프론트 컨트롤러만 수정하면 됨.

한계

• 개발자가 매번 ModelView 객체를 생성해야 하는 번거로움.

---

4. v4 - 단순하고 실용적인 컨트롤러

목표

• 개발자가 더 편하게 컨트롤러 작성.

특징

• 모델 객체를 프론트 컨트롤러에서 생성해 컨트롤러에 전달.
• 컨트롤러는 뷰 이름만 반환.
• 모델 생성 및 반환 과정 단순화.

장점

• 불필요한 객체 생성 제거.
• 개발자는 핵심 로직에만 집중 가능.

한계

• 여전히 한 가지 방식의 컨트롤러만 지원.

---

5. v5 - 어댑터 패턴으로 유연한 컨트롤러

목표

• 서로 다른 컨트롤러 인터페이스(v3, v4 등)를 동시에 지원.

특징

• MyHandlerAdapter 도입 → 컨트롤러 실행을 어댑터가 대신 처리.
• 프론트 컨트롤러는 컨트롤러를 직접 실행하지 않고, 해당 컨트롤러를 지원하는 어댑터를 찾아 호출.
• 새로운 컨트롤러 방식이 추가되면 어댑터만 만들면 됨.

장점

• 확장성 극대화.
• 스프링 MVC도 동일한 구조 사용(@Controller, @RequestMapping 처리 등).

한계

• 구조 복잡도 증가.

---

6. v1~v5 비교 정리

버전	주요 변경점	장점	한계
v1	프론트 컨트롤러 도입 (요청 입구 단일화)	공통 처리, 유지보수 ↑	forward 중복, Servlet 종속
v2	MyView 도입 (뷰 로직 분리)	중복 제거, 깔끔	Servlet 종속 유지
v3	Servlet 종속성 제거, ModelView, 논리 뷰 이름	테스트 용이, 구조 단순	ModelView 생성 번거로움
v4	Model 파라미터 제공, 뷰 이름만 반환	개발 편의성 ↑	한 방식만 지원
v5	어댑터 패턴 적용, 다중 컨트롤러 지원	확장성 ↑	구조 복잡도 ↑