🌳 고급 고급
CQRS 패턴
쉽게 이해하기
마트에 비유하면, 물건을 사러 오는 손님과 재고를 관리하는 직원이 같은 시스템을 쓰면 불편하잖아요. 손님은 빠르게 상품 정보를 보고 싶고, 직원은 재고 입출고를 정확히 기록해야 하니까요. CQRS는 아예 손님용 시스템과 직원용 시스템을 따로 만드는 거예요.
핵심 정리
데이터를 읽는(Query) 모델과 쓰는(Command) 모델을 완전히 분리해서, 각각을 독립적으로 최적화하는 아키텍처 패턴이에요.
자세히 알아보기
일반적인 애플리케이션은 같은 데이터 모델로 읽기와 쓰기를 모두 처리해요. 하지만 실제로는 읽기와 쓰기의 요구사항이 완전히 달라요. 읽기는 복잡한 조인이 필요하고 성능이 중요하지만, 쓰기는 정합성과 트랜잭션이 중요하죠. CQRS는 이 둘을 명확히 분리해요.
Command 모델은 데이터 변경만 담당해요. '주문 생성', '재고 감소' 같은 비즈니스 로직을 처리하고, 정규화된 데이터베이스에 저장하죠. 반면 Query 모델은 읽기 전용으로, 복잡한 조인 없이 빠르게 조회할 수 있게 비정규화된 뷰를 만들어요. 예를 들어 '사용자 대시보드'용 읽기 전용 테이블을 따로 만드는 거예요.
두 모델 사이의 동기화는 이벤트로 처리해요. Command 쪽에서 데이터가 변경되면 이벤트를 발행하고, Query 쪽에서 그 이벤트를 받아서 읽기 모델을 업데이트하죠. 이 과정에서 약간의 지연(eventual consistency)이 생길 수 있지만, 대부분의 경우 문제없어요.
실무에서는 읽기와 쓰기의 비율이 극단적으로 차이나는 시스템에서 유용해요. SNS처럼 읽기가 압도적으로 많거나, 금융처럼 쓰기의 정합성이 극도로 중요한 경우죠. Event Sourcing과 함께 쓰면 시너지가 크지만, 구현 복잡도가 올라가니 꼭 필요한 경우에만 적용하세요.