[내일배움캠프 TIL] 28일차 - CQRS

오늘은 CQRS에 대해 정리해보았습니다.

 

1. CQRS란 무엇인가?

CQRS는 Command Query Responsibility Segregation의 약자로, 우리말로 하면 "명령과 조회의 책임 분리"라는 뜻입니다.

• Command (명령): 시스템의 상태를 변경하는 작업 (Create, Update, Delete).
• Query (조회): 시스템의 상태를 반환하는 작업 (Read).

보통은 하나의 도메인 모델로 이 두 가지를 다 처리하지만, CQRS는 "데이터를 쓰는 모델"과 "데이터를 읽는 모델"을 아예 찢어버리자는 전략입니다.

---

2. 왜 쓰는 걸까? (도입 배경)

보통 조회가 복잡해지면(Join이 많아지거나 계산이 필요할 때) 성능이 떨어지는데, 이때 명령(CUD) 로직까지 섞여 있으면 코드가 스파게티가 되고 성능 최적화가 어렵습니다.

• 성능 최적화: 읽기 전용 DB를 따로 두어 조회 속도를 비약적으로 높일 수 있습니다.
• 확장성: 서비스가 커져서 조회 요청이 폭주하면, 읽기 서비스만 여러 대로 늘리면 됩니다.
• 유연성: 읽기 모델을 UI에 딱 맞는 형태로 미리 가공해둘 수 있어 화면을 그리기 편해집니다.

---

3. 배송 프로젝트에 적용한다면?

지금 설계 중인 p_delivery_logs나 p_delivery_routes에 CQRS를 대입해보면 이해가 빠릅니다.

• Command (Write):
  • 배송 기사가 '배달 완료' 버튼을 누름.
  • p_deliveries 테이블의 상태가 바뀌고, p_delivery_logs에 한 줄이 쌓임.
  • 데이터의 일관성과 무결성이 중요함.
• Query (Read):
  • 사용자가 '내 배송 어디 있지?' 하고 타임라인을 조회함.
  • 로그 테이블을 매번 조인해서 계산하는 게 아니라, 조회용으로 미리 합쳐놓은(Denormalized) 테이블이나 캐시에서 데이터를 바로 가져옴.
  • 데이터의 빠른 응답 속도가 중요함.

---

4. 주의할 점 (단점)

• 복잡도 상승: 모델이 두 개가 되니 관리할 코드와 DB가 늘어납니다.
• 데이터 동기화: 명령 모델에 데이터를 썼을 때, 읽기 모델까지 반영되는 데 아주 짧은 시간차(Eventual Consistency)가 생길 수 있습니다.