CQRS를 '읽기·쓰기 분리'로만 외운 사람과, 도입 비용·동기화 지연·도입 조건까지 묶어 답하는 사람을 구분하려는 질문이다. 답에 따라 이벤트 소싱·결과적 일관성·단일 DB CQRS 같은 변형으로 깊이를 캐물을 수 있다.
CQRS는 상태를 바꾸는 명령(Command) 모델과 데이터를 읽는 조회(Query) 모델을 한 벌이 아니라 두 벌로 분리하는 아키텍처 패턴이다. 분리하면 명령은 도메인 일관성에 맞춘 쓰기 최적 저장소, 조회는 화면·집계에 맞춘 읽기 최적 저장소처럼 각자 다른 기술과 모델을 쓸 수 있다. 다만 두 모델 사이를 이벤트나 메시지로 맞춰야 해서 동기화 지연·운영 복잡도·이중 일관성 책임이 같이 생긴다. 그래서 CQRS는 '쓰면 좋아진다'가 아니라 '이 비용을 감당할 가치가 있는가'를 매번 다시 판단해야 하는 선택이다.
조회 쿼리가 도메인 모델 위에서 점점 무거워져 캐시·복제·인덱스로 버티다 한계를 본 경험이 있다면 CQRS 도입 신호를 자기 사례로 풀 수 있다
이벤트나 메시지로 조회 모델을 갱신하다가 동기화 지연·재처리 문제를 겪은 경험이 있다면 결과적 일관성의 운영 비용을 답할 수 있다
단일 DB 안에서 읽기 전용 뷰·읽기 전용 리포지토리로 가벼운 CQRS를 적용해 본 경험이 있다면 도입 단계와 비용의 스펙트럼을 시각화해 설명할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.