웹 요청 하나의 컨트롤러가 인증·가격 계산·DB 저장·HTML 렌더링을 모두 맡습니다. MVC에서 책임을 어떻게 나누나요?

MVC는 입력을 받는 경계, 업무 규칙과 상태를 다루는 영역, 사용자에게 표현하는 영역을 나누어 변경 이유를 분리하는 방식입니다. 컨트롤러는 요청을 해석하고 필요한 서비스 메서드를 호출한 뒤 응답을 선택하는 얇은 경계에 두고, 모델 또는 서비스는 가격·권한·상태 전이 같은 업무 규칙을 소유하게 하겠습니다. 뷰는 데이터를 HTML이나 다른 표현으로 바꾸되 업무 판단을 맡지 않습니다.

컨트롤러가 인증부터 할인 계산, 여러 테이블의 저장, HTML 문자열 조립까지 수행하면 입력 형식과 업무 정책과 표시 형식이 한 메서드에 결합됩니다. 모바일 API를 추가하거나 할인 규칙을 바꾸거나 화면 템플릿을 교체할 때 모두 컨트롤러를 수정하게 되는 fat controller가 됩니다. 요청 DTO를 검증한 뒤 OrderService.place(command)처럼 주문 처리 서비스를 호출하고, 결과를 뷰 모델로 변환해 뷰에 넘기면 각 계층의 역할이 선명해집니다.

다만 모델이라는 이름의 거대한 객체 하나에 모든 로직을 넣거나, 서비스를 단순히 DB 호출의 다른 이름으로 만드는 것도 해결이 아닙니다. 규칙의 소유자는 업무 개념에 따라 정하고, 트랜잭션 범위와 오류 변환처럼 경계에 필요한 책임은 명시하겠습니다. 컨트롤러를 얇게 만드는 목표는 줄 수 자체가 아니라 요청 형식이나 템플릿 변경이 핵심 업무 규칙을 흔들지 않게 하는 것입니다. 프레임워크가 MVC라는 이름을 사용해도 실제 책임 배치가 자동으로 보장되지는 않습니다.

규칙과 어댑터를 분리합니다

컨트롤러는 요청을 해석하고 인증된 주체를 확인한 뒤 명령을 서비스에 전달합니다. 서비스·도메인 객체는 가격·권한·주문 상태 전이와 트랜잭션을 소유하고, 저장소는 영속화 세부사항을 맡습니다. 뷰는 이미 결정된 결과를 HTML이나 JSON으로 표현합니다. 로그인 여부와 주문 소유권은 다르므로 컨트롤러가 인증을 통과시켜도 서비스가 자원 인가를 다시 확인해야 합니다.

오류와 읽기·쓰기를 구분합니다

입력 형식 오류, 가격 정책에 따른 거절, DB timeout은 서로 다른 결과이므로 어댑터가 각각 HTTP 응답으로 매핑합니다. 템플릿이 DB를 직접 조회해 재고를 판단하면 표현 계층에 규칙이 새어 나가므로 서비스가 뷰 모델을 제공합니다. 조회 전용 화면은 읽기 모델을 단순화할 수 있지만 주문 변경은 멱등성·동시성·커밋 범위가 필요합니다. 모델이라는 이름의 거대 객체나 CRUD만 하는 서비스가 생기지 않는지, 할인 정책 변경이 템플릿과 입력 형식을 건드리지 않는지 경계를 확인하겠습니다.

구체적인 경계 사례

같은 주문 기능을 HTTP와 메시지 소비자가 함께 호출하는 상황을 생각하겠습니다. 두 어댑터가 인증된 주체·주문 ID·요청 ID를 명령으로 변환하고 같은 처리 서비스를 호출하면 할인·인가·상태 전이는 한곳에서 적용됩니다. HTTP 객체를 서비스에 그대로 넘기면 소비자가 가짜 HTTP 요청을 만들어야 하므로 경계가 잘못된 신호입니다.

뷰가 내부 엔터티를 그대로 직렬화하면 숨겨야 할 필드나 지연 로딩 관계가 노출될 수 있습니다. 응답 전용 모델에서 공개 필드를 선택하고, HTML 표현에서는 사용자 문자열을 문맥에 맞게 이스케이프합니다. 업무 규칙을 뷰에 넣지 않는다는 원칙이 출력 인코딩과 접근성까지 서비스 책임으로 옮긴다는 뜻은 아닙니다. MVC는 UI 책임 분리이고 도메인 경계·프로세스 분리는 별도의 설계 축입니다.