CQRS (Command Query Responsibility Segregation)
* CQRS 란?
📝직역하자면 명령과 쿼리의 역할을 구분한다는 것이다. Create-Insert, Update, Delete 와 같이 데이터를 변경하는 것과
Select-Read 와 같이 데이터를 조회하는 것 두 가지의 책임을 분리한다는 것이다.
* 왜 사용할까?
우리가 사용하는(혹은 사용했던) 전통적인 CRUD 아키텍쳐 기반에서 시스템을 유지보수하다 보면, 추가적인 요구사항과 정책의 변화들로 자연스럽게 로직상의 Domain Model 복잡도가 증가하게 된다. 시간이 갈 수록 유지보수 비용은 점진적으로 증가하게 되며 해당 시스템은 첫 기획의도와는 다른 방향으로 변질되는 케이스를 종종 볼 수 있다. 그렇게 모든 요구사항을 충족하며 확장성을 고려한 Domain Model 을 만드는 건 굉장히 어려운 일이 되어버렸다.
그래서 우리 개발자들은 고민하기 시작했다.
무엇이 문제일까? 왜 문제가 될까?
그 시작점은 모델에 있었다.
사용자 조회, Admin, 대시보드 등 비즈니스 로직은 Controller 부터 분리되어 있지만 하나의 Model을 사용하여 명령과 조회를 수행한다는 것을 확인했다.
사용자가 개명을 하게되어 이름만을 바꾸고 싶을 뿐인데 Model 자체를 던져버리는 경우가 많았고, SumCount 와 같은 관리용 데이터 등이 실제 조회에서는 사용되지 않으나 선언되어 있는 경우가 많았다. (이런 내역을 다 알지 못하는 후대 개발자들은 스파게티 코드가 된 프로젝트를 Legacy 모드로 변환시켜 차세대 프로젝트로 재개발을 진행한다.)
이러한 문제를 해결하기 위해 명령 도메인과 조회 도메인을 분리하게 된다.
*DDD(Domain-driven design) 의 시작으로 볼 수 있으나, Bounded Context 에서만 사용되어야 한다.
* 어떻게 구현할까?
마틴 파울러는 CQRS가 아래와 같은 아키텍쳐 패턴과 방법론을 파생하거나 혹은 필요로 한다고 했다.
- Event Sourcing
- EagerReadDerivation
- Domain Driven Design
- Eventual Consistency
 |  |  |
|---|
위에서 아래로 기존 모델 아키텍처에서 CQRS 패턴이 적용되는 모습을 볼 수 있다.
CQRS 적용의 마지막 단계에서 RDBMS와 NoSQL 관계에서는 Kafka와 같은 메시지 큐가 적용될 수 있다.
여기에 Redis, Elasticsearch 를 곁들인다면 성능면에서도 훌륭한 개선이 될 듯 하다.
마치며
CQRS 패턴을 알게된 후, Toy Project 에서 구현한 경험이 있다. 이 프로젝트는 규모가 작고 통합테스트의 Cost 가 Production 단계에서의 단위테스트보다 작기에 케이스가 적은 관계로 아쉽게도 당장 활용은 어려울 것 같았다.
Legacy 와 스파게티 코드로 가득한 Production 프로젝트들을 개선하는 작업 진행중에 발견하여 스터디한 CQRS 패턴이 훗 날 큰 도움이 되기를 바라며 천천히 차근차근 진행해보아야겠다.
