45 lines
3.5 KiB
Markdown
45 lines
3.5 KiB
Markdown
---
|
|
id: P-REINFORCE-WIKI-ARCH-CQRS
|
|
title: "명령과 조회 책임 분리 패턴 (CQRS, Command Query Responsibility Segregation)"
|
|
category: "10_Wiki/🏗️ Topics_Arch"
|
|
status: verified
|
|
canonical_id: ""
|
|
aliases: ["CQRS", "Command Query Responsibility Segregation", "명령 조회 분리", "읽기 쓰기 최적화"]
|
|
duplicate_of: ""
|
|
source_trust_level: A
|
|
confidence_score: 1.0
|
|
tags: ["Architecture", "CQRS", "Performance", "Consistency", "Scalability"]
|
|
raw_sources: ["Datacollector_Export_2026-05-02"]
|
|
last_reinforced: 2026-05-02
|
|
github_commit: ""
|
|
---
|
|
|
|
# [[명령과 조회 책임 분리 패턴 (CQRS, Command Query Responsibility Segregation)]]
|
|
|
|
## 1. 개요
|
|
CQRS(Command Query Responsibility Segregation)는 애플리케이션 내에서 데이터를 변경하는 '명령(Command)'과 데이터를 조회하는 '조회(Query)'의 책임을 물리적 또는 논리적으로 분리하는 아키텍처 패턴이다. 이를 통해 시스템의 읽기 성능과 쓰기 일관성을 각기 다른 모델과 기술을 사용하여 독립적으로 최적화할 수 있다.
|
|
|
|
## 2. 핵심 메커니즘
|
|
- **명령 (Command)**: 시스템의 상태를 변경하는 작업 (Create, Update, Delete). 비즈니스 규칙과 데이터 무결성을 보장하는 복잡한 도메인 모델(Entity, Aggregate)을 사용하며, 주로 ORM(JPA, Prisma 등)을 통해 처리.
|
|
- **조회 (Query)**: 시스템의 상태를 단순히 읽어오는 작업 (Read). 도메인 모델의 복잡성을 배제하고, 화면이나 API 요구사항에 최적화된 DTO나 전용 모델을 사용. 성능 극대화를 위해 가벼운 SQL 쿼리 빌더(Slonik, MyBatis 등)나 캐시 레이어 활용.
|
|
|
|
## 3. 실전 적용 가치
|
|
- **하이브리드 데이터 접근**: 쓰기 시에는 엄격한 데이터 정합성을 위해 ORM을 사용하고, 읽기 시에는 조인 성능을 위해 순수 SQL이나 특화된 검색 엔진(Elasticsearch 등)을 사용하는 전략 수립 가능.
|
|
- **확장성 (Scalability)**: 읽기 요청이 압도적으로 많은 서비스에서 읽기 전용 저장소를 복제(Read Replica)하거나 별도의 서비스로 분리하여 성능 한계를 극복.
|
|
- **복잡도 제어**: 하나의 비대한 모델이 읽기와 쓰기 책임을 모두 가지면서 발생하는 유지보수성 저하 문제를 해결.
|
|
|
|
## 4. 트레이드오프 및 주의사항
|
|
- **데이터 일관성 (Eventual Consistency)**: 명령과 조회 저장소를 분리할 경우, 쓰기 발생 직후 조회 결과가 최신화되지 않을 수 있는 지연 시간이 발생함. 이를 관리하기 위한 메시지 큐와 동기화 메커니즘 필요.
|
|
- **구현 오버헤드**: 두 개의 모델과 파이프라인을 유지해야 하므로 코드 복잡도와 관리 포인트가 증가함.
|
|
- **적용 기준**: 비즈니스 로직이 단순하거나 읽기/쓰기 모델의 차이가 거의 없는 경우에는 오버엔지니어링이 될 수 있음.
|
|
|
|
## 5. 지식 연결 (Related)
|
|
- [[Hexagonal_Architecture]]: CQRS가 내부 모듈 간의 책임을 나누는 중추적인 전략으로 사용됨.
|
|
- [[Event_Driven_Architecture]]: 명령 발생 후 조회 모델을 업데이트하기 위해 도메인 이벤트를 비동기로 처리하는 연관 패턴.
|
|
- [[Domain_Driven_Design]]: 복잡한 명령 모델(애그리거트)을 설계할 때 CQRS와 함께 시너지를 냄.
|
|
|
|
## 🧪 검증 상태 (Validation)
|
|
- **정보 상태**: 검증 완료 (Verified)
|
|
- **출처 신뢰도**: A
|
|
- **검토 이유**: 성능과 유연성을 동시에 확보하기 위한 현대적 대규모 시스템 설계의 핵심 패턴 정립.
|