Antigravity Agent
2.8 KiB
2.8 KiB
id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit
| id | title | category | status | canonical_id | aliases | duplicate_of | source_trust_level | confidence_score | tags | raw_sources | last_reinforced | github_commit | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| P-REINFORCE-WIKI-ARCH-CQRS | 명령 조회 책임 분리 (CQRS Pattern) | 10_Wiki/🏗️ Topics_Arch | verified |
|
A | 0.95 |
|
|
2026-05-02 |
명령 조회 책임 분리 (CQRS Pattern)
1. 개요
CQRS(Command Query Responsibility Segregation)는 애플리케이션 내에서 **데이터 변경(명령, Command)**과 **데이터 조회(조회, Query)**의 책임을 명확히 분리하는 아키텍처 패턴이다. 이를 통해 복잡한 시스템에서 읽기 성능과 쓰기 일관성을 각각 독립적으로 최적화할 수 있다.
2. 핵심 메커니즘
- Command (명령): 시스템의 상태를 변경하는 작업. 비즈니스 규칙과 데이터 무결성 보장이 핵심이다. (예: ORM 활용)
- Query (조회): 시스템의 상태를 읽는 작업. 성능 최적화와 가벼운 응답이 핵심이다. (예: 경량 SQL 쿼리 빌더 활용)
- 하이브리드 패턴: 쓰기에는 무거운 **ORM(Prisma, TypeORM)**을, 읽기에는 가벼운 **SQL 빌더(Kysely, Slonik)**를 사용하는 방식이 실전에서 자주 쓰인다.
3. 고급 통합 전략
- Hexagonal Architecture: 헥사고날 구조에서 모듈 간의 횡단 관심사(Cross-cutting)를 처리하고 아키텍처 경계를 관리하기 위해 도입된다.
- 도메인 이벤트 (Domain Events): 상태 변경 시 이벤트를 발행하여 조회 전용 모델을 업데이트하거나 다른 모듈과 통신한다.
- 결과적 일관성 (Eventual Consistency): 읽기와 쓰기 저장소가 분리될 경우, 데이터가 일시적으로 불일치할 수 있으나 최종적으로 일치하게 되는 모델을 수용한다.
4. 트레이드오프
- 장점: 읽기/쓰기 성능의 독립적 스케일링, 복잡한 비즈니스 로직과 복잡한 조회 요구사항의 분리.
- 단점: 시스템 복잡도 증가, 데이터 동기화 관리 비용(Eventual Consistency), 구현 오버헤드.
5. 지식 연결 (Related)
- Hexagonal_Architecture: CQRS를 수용하기에 최적화된 외부 인터페이스 구조.
- Domain_Driven_Design: 명령(Command) 모델의 비즈니스 규칙을 정의하는 방법론.
- Event_Sourcing: 상태가 아닌 변경 이벤트를 저장하는 기법 (CQRS와 상보적).
🧪 검증 상태 (Validation)
- 정보 상태: 검증 완료 (Verified)
- 출처 신뢰도: A
- 검토 이유: 고부하 엔터프라이즈 시스템의 성능 최적화를 위한 필수 패턴 정립.