[CS] CQRS 패턴 (Command Query Responsibility Segregation)

CQRS(Command Query Responsibility Segregation)

명령(Command)과 조회(Query)의 책임을 분리하는 소프트웨어 설계 패턴

 

시스템에서 처리하는 작업 종류

• 명령(Command): 시스템의 상태를 변경하는 작업
  예: 주문 생성, 주문 취소, 결제 처리
• 조회(Query): 시스템의 상태를 읽기만 하는 작업
  예: 주문 내역 조회, 사용자 정보 확인

---

CQRS의 핵심 개념

• 명령 모델과 조회 모델을 각각 별도로 분리하여 관리한다.
• 하나의 리소스를 명령용과 조회용 두 개의 모델로 나눌 수 있다.
  • 예: Order (명령 모델), OrderData (조회 모델)
• 명령 모델은 변경 작업에 집중하고, 조회 모델은 데이터 출력을 최적화할 수 있다.

예시: 쇼핑몰 주문 시스템

Order: 주문 생성, 결제 처리, 주문 취소 등의 상태 변경 작업을 처리하는 명령 모델
OrderData: 주문 상태, 결제 내역 등 사용자에게 보여줄 정보를 제공하는 조회 모델

---

CQRS의 장점

• 명령과 조회 책임이 분리되어 코드가 깔끔해지고 유지보수가 쉬워진다.
• 명령 모델과 조회 모델에 각각 적합한 기술을 선택할 수 있다.
  • 명령 모델: 트랜잭션이 중요한 RDB(MySQL 등)
  • 조회 모델: 빠른 조회가 필요한 NoSQL(MongoDB 등)
• 조회 모델은 UI에 최적화된 형태로 데이터를 구성할 수 있다.
  • 예: Order + Product + User 정보를 하나의 뷰로 제공

기술 조합 예시

- 명령 모델: 도메인 중심 설계에 적합한 JPA 활용
- 조회 모델: SQL 중심의 효율적인 조회를 위한 MyBatis 사용

---

CQRS의 단점

• 명령 모델과 조회 모델을 별도로 구현해야 하므로 개발량이 많아진다.
• 데이터가 변경될 때, 명령 모델의 결과를 조회 모델로 동기화하는 추가 로직이 필요하다.
  • 이벤트 기반 처리 등의 비동기 전파 방식이 흔히 사용됨
• 단순한 시스템에는 오히려 과한 설계가 될 수 있다.

---

CQRS 도입이 적합한 경우

• 읽기와 쓰기 복잡도가 확연히 다른 경우
• 조회 성능을 극대화해야 하는 경우
• 도메인 로직이 복잡해 유지보수가 어려운 경우
• UI 화면에서 다양한 데이터를 빠르게 결합·조회해야 하는 경우

결론

CQRS는 시스템의 복잡도를 명확히 분리해 유지보수성을 높이고, 성능 최적화와 기술 선택의 유연성을 제공한다.
그러나 구현 비용이 크기 때문에, 실제 적용 시에는 시스템의 규모와 요구사항을 고려해 신중히 도입해야 한다.