MVC vs CQRS: 무엇이 다르고 언제 써야 할까?

소프트웨어 설계를 공부하다 보면 MVC와 CQRS라는 단어를 자주 접하게 됩니다. 겉으로 보기엔 비슷해 보이지만, 두 아키텍처는 적용 목적, 범위, 복잡성이 완전히 다릅니다.

이 글에서는 MVC와 CQRS의 차이, 언제 어떤 아키텍처를 선택해야 할지 명확히 정리해봅니다.

---

1. 정의부터 짚고 가자

✅ MVC (Model-View-Controller)

• 전통적인 UI 중심 애플리케이션 아키텍처 패턴
• 목적: 사용자 인터페이스를 역할에 따라 분리
• 구성:
  • Model: 데이터와 비즈니스 로직
  • View: 사용자 인터페이스
  • Controller: 사용자 입력 처리 및 흐름 제어

흔히 웹 프레임워크(Spring MVC, Ruby on Rails, ASP.NET MVC 등)에서 사용

---

✅ CQRS (Command Query Responsibility Segregation)

• 도메인 중심의 아키텍처 패턴
• 목적: 읽기와 쓰기를 분리해서 처리 효율성과 복잡성 관리
• 구성:
  • Command: 상태 변경 (쓰기) → 예: 주문 생성, 유저 등록
  • Query: 상태 조회 (읽기) → 예: 유저 리스트 보기, 주문 내역 조회

대규모 시스템, 복잡한 비즈니스 로직, 성능 최적화가 필요한 경우에 사용

---

2. 주요 차이점 비교

항목MVCCQRS

목적	UI 구성 요소 분리	읽기/쓰기 로직 분리
적용 범위	프론트엔드/웹 애플리케이션 중심	백엔드/도메인 중심 시스템
복잡도	상대적으로 단순	상대적으로 복잡 (특히 이벤트 소싱과 함께 쓰일 경우)
읽기/쓰기 분리	분리되지 않음 (Model에서 처리)	명확하게 분리 (Command / Query 모델)
테이블 공유 여부	보통 같은 테이블 사용	읽기/쓰기 모델과 DB를 따로 둘 수 있음
적합한 사례	CRUD 기반 UI, 단순한 애플리케이션	고성능 요구, 비즈니스 로직이 복잡한 시스템

---

3. 언제 MVC를, 언제 CQRS를?

MVC가 적합한 경우:

• 단순한 CRUD 웹 애플리케이션
• 프로토타입, MVP 단계
• 작은 팀, 빠른 개발 주기

CQRS가 적합한 경우:

• 도메인이 복잡하고 비즈니스 규칙이 많을 때
• 읽기/쓰기 성능을 별도로 최적화하고 싶을 때
• Event Sourcing과 결합하여 변경 이력을 관리하고 싶을 때
• 대규모 시스템, 분산 환경

---

4. 같이 쓰는 것도 가능할까?

YES!

실제로 많은 시스템이 프론트엔드에서는 MVC, 백엔드에서는 CQRS 패턴을 사용합니다. 예를 들어:

• 프론트: React/Vue의 MVC 스타일로 UI 렌더링
• 백엔드: CQRS로 명령과 조회 분리, 도메인 모델 설계

---

5. 예시 흐름 비교

MVC 흐름 예:

1. 사용자가 POST /articles로 글 작성 요청
2. Controller가 요청 처리
3. Model이 DB에 저장
4. View가 성공 메시지 렌더링

CQRS 흐름 예:

1. 사용자가 "글 작성" 버튼 클릭
2. Command(CreateArticleCommand) 전송
3. 도메인 서비스 → 저장
4. Query(GetArticleListQuery)로 다시 목록 조회
5. View는 별도의 Read Model로 렌더링

---

결론

요약MVCCQRS

적합한 규모	소규모, 단순 구조	중~대규모, 복잡한 로직
목표	UI 구조 정리	읽기/쓰기 책임 분리
복잡도	낮음	높음 (유연성은 큼)

---

한 줄 정리

👉 MVC는 "화면 중심", CQRS는 "도메인 중심"의 아키텍처이다.