CQRS
더 많은 작업
CQRS(Command Query Responsibility Segregation, 명령 조회 책임 분리)는 데이터를 바꾸는 명령(Command)과 데이터를 읽는 조회(Query)를 서로 다른 모델, 필요하면 서로 다른 저장소로 나누어 처리하는 소프트웨어 아키텍처 패턴이다.
보통의 정보 시스템은 하나의 데이터 모델로 생성·조회·수정·삭제(CRUD)를 모두 처리한다. 시스템이 커지면 쓰기에 필요한 검증·업무 규칙과, 화면마다 다른 모양으로 빨리 읽어야 하는 조회 요구가 한 모델 안에서 부딪친다. CQRS 는 이 모델을 갱신용 모델과 조회용 모델로 쪼갠다. 이름은 메서드를 상태를 바꾸는 명령과 값을 돌려주는 조회로 나누라는 버트런드 메이어의 명령-조회 분리(Command Query Separation) 원칙에서 왔으며, 그렉 영(Greg Young)이 패턴으로 소개했다. 마틴 파울러는 이 분리가 쓸모 있는 상황도 있지만 대부분의 시스템에는 위험한 복잡성을 더한다고 경고한다.[1]
- 명령 측(쓰기 모델) - 주문 생성, 재고 차감 같은 명령을 받아 업무 규칙을 검증하고 쓰기 저장소에 반영한다. 반영 결과를 이벤트로 발행하기도 한다
- 조회 측(읽기 모델) - 화면이나 API 가 필요로 하는 모양대로 미리 만들어 둔 읽기 전용 뷰(materialized view)에서 조회한다. 조인이나 계산을 미리 해 두므로 읽기가 빠르다
- 동기화 - 쓰기 저장소의 변경을 이벤트나 메시지로 받아 읽기 저장소를 갱신한다. 둘을 같은 데이터베이스의 다른 테이블로 둘 수도, 아예 다른 종류의 데이터베이스로 둘 수도 있다
마이크로소프트는 읽기와 쓰기 저장소를 나누면 각각을 따로 최적화하고 확장할 수 있지만, 읽기 쪽이 최신 변경을 곧바로 반영하지 못하는 최종적 일관성(eventual consistency)을 감수해야 한다고 설명한다.[2]
서비스별 데이터베이스 패턴을 쓰면 각 서비스의 데이터가 서로 다른 데이터베이스에 흩어져 있어 여러 서비스의 데이터를 조인하는 조회가 어려워진다. 크리스 리처드슨은 이런 조회를 구현하는 방법으로 API 조합(여러 서비스를 차례로 불러 합침)과 CQRS(여러 서비스가 발행하는 이벤트를 구독해 조인된 읽기 전용 뷰를 따로 유지)를 든다.[3] 쓰기 쪽 트랜잭션이 여러 서비스에 걸치면 Saga 패턴을 함께 쓴다.
- 읽기와 쓰기의 부하 차이가 커서 따로 확장해야 할 때
- 조회 화면이 여러 원천 데이터를 합친 모양을 자주 요구할 때
- 쓰기 쪽 업무 규칙이 복잡해 조회 요구와 섞으면 모델이 지저분해질 때
- 이벤트 소싱(상태 대신 변경 이벤트를 저장하는 방식)과 함께 쓸 때
단순한 CRUD 시스템에는 두 모델과 동기화 장치를 유지하는 비용이 더 크다.[1]
| 패턴 | 해결하는 문제 | 핵심 |
|---|---|---|
| CQRS | 읽기·쓰기 요구의 충돌, 서비스 간 조인 조회 | 명령 모델과 조회 모델 분리 |
| 서비스별 데이터베이스 패턴 | 서비스 간 데이터 결합 | 서비스마다 자기 데이터베이스를 소유 |
| Saga 패턴 | 여러 서비스에 걸친 쓰기 트랜잭션 | 지역 트랜잭션 연쇄 + 보상 트랜잭션 |
| API 게이트웨이 | 클라이언트의 진입점 통합 | 단일 진입점에서 라우팅·인증 |
| 상관관계 ID | 여러 서비스를 거친 요청의 추적 | 요청마다 같은 식별자를 전달·기록 |
- ↑ 1.0 1.1 Martin Fowler, 「CQRS」, martinfowler.com, 2011-07-14, https://martinfowler.com/bliki/CQRS.html, 확인일: 2026-11-04.
- ↑ 「CQRS pattern」, Azure Architecture Center, Microsoft Learn, https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs, 확인일: 2026-11-04.
- ↑ Chris Richardson, 「Pattern: Database per service」, Microservices.io, https://microservices.io/patterns/data/database-per-service.html, 확인일: 2026-11-04.