Antigravity Agent
45 lines
2.8 KiB
Markdown
45 lines
2.8 KiB
Markdown
---
|
|
id: P-REINFORCE-WIKI-ARCH-CQRS
|
|
title: "명령 조회 책임 분리 (CQRS Pattern)"
|
|
category: "10_Wiki/🏗️ Topics_Arch"
|
|
status: verified
|
|
canonical_id: ""
|
|
aliases: ["CQRS", "Command Query Responsibility Segregation", "하이브리드 데이터 레이어"]
|
|
duplicate_of: ""
|
|
source_trust_level: A
|
|
confidence_score: 0.95
|
|
tags: ["Architecture", "CQRS", "Eventual_Consistency", "Database_Optimization", "NestJS"]
|
|
raw_sources: ["Datacollector_Export_2026-05-02"]
|
|
last_reinforced: 2026-05-02
|
|
github_commit: ""
|
|
---
|
|
|
|
# [[명령 조회 책임 분리 (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
|
|
- **검토 이유**: 고부하 엔터프라이즈 시스템의 성능 최적화를 위한 필수 패턴 정립.
|