MVC 패턴

MVC 패턴이란?

MVC는 Model-View-Controller의 약자로, 애플리케이션을 세 가지 주요 구성 요소로 분리하는 소프트웨어 설계 패턴이다.
주로 웹 애플리케이션에서 사용되며, 코드의 역할을 명확히 나누고 유지보수와 확장성을 높이는 데 유리하다.

• Model(모델):
  애플리케이션의 핵심 데이터와 비즈니스 로직을 담당한다. 예를 들어 게시판이라면, 게시글 데이터를 조회·저장·수정하는 로직이 모델에 속한다.
• View(뷰):
  사용자에게 보이는 UI 화면을 담당한다. HTML, JSP, Thymeleaf 같은 템플릿 엔진이 여기에 해당하며, 데이터를 시각적으로 보여주는 역할을 한다.
• Controller(컨트롤러):
  사용자의 요청을 받아 Model에게 전달하고, 처리 결과를 View로 연결해주는 중간 조율자 역할을 한다. 예를 들어 로그인 요청을 받으면, Controller는 Model에게 인증을 요청하고 결과에 따라 알맞은 화면(View)을 반환한다.

---

MVC 패턴의 흐름

[User] 
   ↓
[Controller] → [Model] → DB
   ↓
[View] → 사용자에게 결과 표시

1. 사용자가 브라우저에서 요청을 보낸다. (예: /login)
2. Controller가 요청을 받아 적절한 Model에게 작업을 요청한다.
3. Model은 로직을 수행하고 결과를 Controller에게 반환한다.
4. Controller는 결과를 View에 전달하고, View는 사용자에게 화면을 출력한다.

---

MVC 패턴의 장점

1. 역할의 명확한 분리
   구성 요소의 책임이 명확하게 구분되어 있어 코드의 가독성이 높고, 유지보수가 쉬워진다.
   화면(View)을 수정해도 핵심 로직(Model)은 영향을 받지 않고, 그 반대도 마찬가지이다.
2. 낮은 결합도와 높은 응집도
   각 구성 요소는 서로 강하게 의존하지 않기 때문에, 독립적으로 개발·수정·테스트가 가능하다.
   코드 재사용성과 유연성이 높아진다.
3. 모델 재사용 가능
   하나의 Model을 여러 View에서 사용할 수 있어, 웹, 모바일, 관리자 페이지 등 다양한 환경에 적용 가능하다.
4. 협업에 유리함
   프론트엔드는 View 중심으로, 백엔드는 Controller와 Model 중심으로 개발할 수 있어 업무 분담과 협업이 효율적이다.

---

MVC 패턴의 한계점

1. 간단한 프로젝트에선 과한 구조가 될 수 있다
   작은 규모의 기능이라도 Model, View, Controller로 나누어야 하므로
   오히려 코드가 복잡해지고 초기 개발 속도를 떨어뜨릴 수 있다.
2. Controller 비대화 현상 (Massive Controller)
   설계가 잘못되면 Controller에 여러 책임이 몰려서, 로직이 복잡해지고 유지보수가 어려워질 수 있다.
   → 일반적으로 Service 계층을 도입해 책임을 분산시킨다.
3. 완전한 역할 분리가 어려운 경우가 있다
   현실적인 코드에서는 View에 일부 로직이 들어가거나,
   Controller가 Model에 과하게 의존하는 등 구조가 흐트러질 수 있다.
4. 테스트 코드 작성의 어려움
   Controller가 여러 책임을 가지면 단위 테스트가 어려워지고,
   의존성 주입이나 계층 분리가 되어 있지 않으면 테스트 코드 작성이 번거로워진다.
5. Model과 View의 의존성을 완전히 분리하기 어렵다
   실무에서는 View에서 Model 객체를 직접 참조하는 일이 많으며,
   이로 인해 설계 원칙에서 말하는 '완전한 분리'가 잘 지켜지지 않을 수 있다.

---

MVC 패턴의 설계 원칙

MVC 패턴을 올바르게 사용하기 위해서는 다음과 같은 구조적 원칙을 지켜야 한다:

• Model은 Controller와 View에 의존하지 않아야 한다.
  Model은 순수하게 데이터와 로직만 처리하는 계층이어야 하며, 다른 구성 요소에 의존하면 안 된다.
• View는 Controller에 의존하면 안 되고, Model만 참조해야 한다.
  View는 Model에서 데이터를 받아 표현하는 데 집중해야 하며, 로직은 Controller나 Model에 맡겨야 한다.
• Controller는 Model과 View에 의존할 수 있다.
  사용자의 입력을 처리하고, 로직을 호출하고, 그 결과를 View에 전달하는 책임을 가지므로, 양쪽에 접근이 가능해야 한다.
• View가 데이터를 필요로 할 때는 Controller를 통해 Model에서 받아야 한다.
  View는 직접 Model을 호출하지 않고, Controller가 필요한 데이터를 준비해 전달해야 한다. (→ 실무에서는 View가 Model을 직접 참조하는 경우도 있지만, 이상적인 구조는 Controller가 중간 다리 역할을 하는 것)