121. CQRS 패턴 (Command Query Responsibility Segregation)

핵심 인사이트 (3줄 요약)

본질: CQRS (Command Query Responsibility Segregation, 커맨드 쿼리 책임 분리)는 시스템의 상태를 변경하는 명령(Command)과 상태를 조회하는 쿼리(Query)를 서로 다른 모델과 데이터 저장소로 완전히 분리하여 각각의 요구사항에 최적화하는 아키텍처 패턴이다.

가치: 읽기(Read)와 쓰기(Write) 워크로드는 서로 다른 성능 특성을 가지므로, 분리하면 각각을 독립적으로 최적화·확장할 수 있다. 쓰기 모델은 강한 일관성, 읽기 모델은 비정규화된 빠른 조회에 최적화한다.

판단 포인트: CQRS는 읽기/쓰기 비율이 극단적으로 불균형하거나 쓰기 복잡도(검증·도메인 규칙)와 읽기 복잡도(집계·JOIN)가 극명하게 다른 시스템에 적합하며, 단순 CRUD 시스템에서는 오버엔지니어링이다.

Ⅰ. 개요 및 필요성

CQRS는 그렉 영(Greg Young)이 2010년 이벤트 소싱과 결합하여 널리 알려진 패턴이다. 이전에 버트란드 마이어(Bertrand Meyer)가 CQS (Command Query Separation, 명령 쿼리 분리) 원칙을 메서드 수준에서 제안한 것을 아키텍처 수준으로 확장했다.

기존 단일 모델 방식에서는 동일한 도메인 객체가 읽기·쓰기를 모두 처리한다. 이 경우 복잡한 조회를 위한 JOIN이나 집계 요구사항이 도메인 객체를 오염시키거나, 쓰기 성능 최적화를 위한 인덱스 구조가 읽기 쿼리를 느리게 만드는 양방향 충돌이 생긴다.

┌─────────────────────────────────────────────────────────────┐
│         CQRS 분리 구조: 쓰기 모델 vs 읽기 모델              │
├─────────────────────────────────────────────────────────────┤
│  클라이언트                                                  │
│       │                                                     │
│  ┌────┴────┐                                                │
│  ▼         ▼                                               │
│ Command   Query                                             │
│  │         │                                               │
│  ▼         ▼                                               │
│ 쓰기 모델  읽기 모델                                        │
│ (Write)   (Read)                                            │
│  │         │                                               │
│  ▼         ▼                                               │
│ 쓰기 DB   읽기 DB (비정규화)                                │
│  │                                                         │
│  └──── 이벤트/동기화 ────▶ 읽기 DB 업데이트               │
└─────────────────────────────────────────────────────────────┘

쓰기 DB는 정규화된 RDBMS로 데이터 무결성을 보장하고, 읽기 DB는 비정규화된 조회 최적화 모델(Elasticsearch, Redis, 읽기 전용 뷰)로 구성한다. 두 모델 간의 데이터 동기화는 이벤트나 폴링으로 이루어지며 최종 일관성(eventual consistency)을 수용한다.

📢 섹션 요약 비유: 도서관에서 책을 반납하는 창구(Command)와 도서 검색 단말기(Query)가 분리되어 있으면, 반납 줄이 길어도 검색을 방해하지 않는다. 두 워크로드가 독립적으로 최적화된다.

Ⅱ. 아키텍처 및 핵심 원리

CQRS의 핵심 흐름은 세 단계다. ① 클라이언트가 Command(예: CreateOrderCommand)를 전송, ② Command Handler가 도메인 모델을 업데이트하고 이벤트를 발행, ③ Event Handler가 읽기 모델(Read Model/Projection)을 업데이트.

항목	설명	포인트
Command Model	상태 변경 처리, 검증, 비즈니스 규칙	강한 일관성, 트랜잭션
Query Model	빠른 조회를 위한 비정규화 뷰	낮은 지연, 높은 처리량
Event Bus	쓰기→읽기 동기화 채널	비동기, 내구성
Projection	이벤트에서 읽기 모델 재구성	유연한 뷰 재생성

┌─────────────────────────────────────────────────────────────┐
│      CQRS + 이벤트 소싱 결합 흐름                            │
├─────────────────────────────────────────────────────────────┤
│  Command → Domain Model → 이벤트 저장소(Event Store)        │
│                                    │                        │
│                               이벤트 발행                   │
│                                    │                        │
│                            Projection Handler               │
│                                    │                        │
│                           읽기 DB 업데이트 (Redis, ES)       │
│                                    │                        │
│  Query ───────────────────────────▶ 읽기 DB 조회             │
└─────────────────────────────────────────────────────────────┘

읽기 모델은 필요에 따라 여러 형태로 병렬 유지할 수 있다. 동일한 쓰기 이벤트로부터 관리자용 대시보드 뷰, 사용자용 목록 뷰, 분석용 집계 뷰를 각각 독립적으로 구성하는 것이 가능하다.

📢 섹션 요약 비유: 공장에서 생산 라인(Command)과 품질 검사 보고서(Query)는 분리되어 있다. 생산 라인이 바빠도 검사 보고서를 조회하는 데 지장이 없다.

Ⅲ. 비교 및 연결

CQRS와 전통적 단일 모델(CRUD) 방식의 차이는 시스템 복잡도에 따른 적합성이 명확히 갈린다.

비교 축	A	B
모델 수	단일 도메인 모델	쓰기 모델 + 읽기 모델(들)
일관성	즉각적 일관성	최종 일관성
복잡도	낮음	높음
성능 튜닝	쓰기·읽기 동시 최적화 어려움	각각 독립 최적화
적합 시스템	단순 CRUD, 소규모	복잡 도메인, 대규모 트래픽

CQRS는 이벤트 소싱(Event Sourcing)과 함께 사용되면 최적의 시너지를 발휘한다. 이벤트 소싱이 상태 변화를 이벤트로 저장하면, 이 이벤트들로부터 원하는 형태의 읽기 모델을 언제든 재구성(replay)할 수 있다.

📢 섹션 요약 비유: 은행에서 입출금(Command)을 기록하는 원장과 잔액을 빠르게 보여주는 잔액 조회 화면(Query)이 분리되어 있는 것과 같다. 원장은 정확성, 조회 화면은 속도가 목표다.

Ⅳ. 실무 적용 및 기술사 판단

CQRS 도입의 실질적 결정 기준은 읽기/쓰기 워크로드 비율과 조회 복잡도다. 읽기가 쓰기의 10배 이상이거나, 조회에 복잡한 집계·JOIN이 필요한 경우, 혹은 각기 다른 형태의 뷰가 여러 개 필요한 경우 CQRS 도입을 검토한다.

판단 체크리스트

읽기와 쓰기의 성능 요구사항이 근본적으로 다른가?
쓰기 도메인 로직이 복잡하여 조회 최적화와 충돌하는가?
동일 데이터에 대한 여러 형태의 뷰(관리자/사용자/분석)가 필요한가?
최종 일관성을 비즈니스적으로 수용할 수 있는가?
읽기 모델 동기화 지연을 사용자 경험 관점에서 허용할 수 있는가?

📢 섹션 요약 비유: 신문사에서 기사를 쓰는 기자(Command)와 독자가 읽는 신문(Query)은 분리되어 있다. 기자가 아무리 많이 써도 독자의 신문 읽기에 지장을 주지 않는다.

Ⅴ. 기대효과 및 결론

CQRS를 적용하면 쓰기 서버와 읽기 서버를 독립적으로 수평 확장할 수 있다. 이벤트 기반으로 읽기 모델을 재구성하므로, 새로운 조회 요구사항이 생겼을 때 이벤트를 replay하여 새로운 읽기 모델을 빠르게 추가할 수 있다. 도메인 모델이 조회 최적화 압박에서 해방되어 순수한 비즈니스 규칙을 표현하기 쉬워진다.

한계는 시스템 복잡도 증가와 운영 부담이다. 두 개의 데이터 모델을 유지해야 하고, 동기화 실패 시 불일치를 처리하는 메커니즘이 필요하다. 또한 개발팀이 최종 일관성과 이벤트 기반 사고 방식에 익숙해져야 한다.

미래 방향으로는 ① 서버리스(Serverless) 환경에서 CQRS 읽기 모델을 함수로 구현, ② AI 기반 실시간 읽기 모델 자동 최적화, ③ 그래프DB와의 결합으로 복잡한 관계 조회 최적화가 발전하고 있다.

CQRS는 "읽기와 쓰기는 서로 다른 세계"라는 통찰을 아키텍처 수준에서 구현한 패턴으로, 복잡한 도메인과 고성능 조회를 동시에 달성하기 위한 설계 전략으로 기억해야 한다.

📢 섹션 요약 비유: 회계 장부(Command)는 정확한 기록이 목적이고, 재무 대시보드(Query)는 빠른 의사결정이 목적이다. 같은 정보이지만 목적에 맞게 분리된 형태로 제공한다.

📌 관련 개념 맵

[CQS 원칙(메이어)] → [CQRS 패턴] → [이벤트 소싱] → [EDA] → [읽기 모델 최적화(Elasticsearch·Redis)]

개념	연결 포인트
이벤트 소싱	CQRS의 쓰기 모델로 이벤트 스토어 사용, 읽기 모델 재구성
EDA	CQRS에서 Command→Query 모델 동기화 채널
Projection	이벤트 스트림으로부터 읽기 모델을 구성하는 메커니즘
최종 일관성	CQRS 읽기 모델의 데이터 일관성 보장 수준

📈 관련 키워드 및 발전 흐름도

[CQS 원칙] → [CQRS 아키텍처 패턴] → [이벤트 소싱 결합] → [Kafka 기반 동기화] → [다양한 읽기 모델(ES·Redis)] → [실시간 스트리밍 분석]

👶 어린이를 위한 3줄 비유 설명

일기(Command)를 쓰는 것과 일기를 읽는 것(Query)은 서로 다른 목적이에요.
CQRS는 쓰기 쉬운 일기장과 찾아보기 쉬운 색인 카드를 따로 만드는 방법이에요.
일기를 많이 써도 색인 카드 검색이 느려지지 않아요!