CQRS 패턴 알아보기

들어가며

 Event Driven Architecture에 대한 경험이 있으시거나, 혹은 그것에 관심이 있으신 분이라면 종종 CQRS라는 단어를 듣게 됩니다. 저 또한 종종 들었습니다. 하지만 정확하게 CQRS가 어떤 것인지 잘 알지 못했고, 이 글을 통해 정리합니다. 

 혹시 독자분들 중 글을 읽는 중에 "어? 좀 이상한데?"하는 부분이 있다면 언제든지 댓글 부탁드립니다. 저도 공부하면서 정리한 내용이라 부족한 부분이 있을 수 있습니다! :)

CQRS

 CQRS는 Command Query Responsibility Segregation 의 약자로 단어 그대로 해석하면 "명령 조회 책임 분리"입니다. 이는 애플리케이션들을 구성하는 아키텍처에 대한 하나의 패턴입니다. 즉, 애플리케이션을 구현함에 있어 명령과 조회에 대한 책임을 분리하는 것이 CQRS입니다. 그렇다면 명령과 조회는 어떤 것을 의미하며, 이 둘의 책임을 왜 분리됐어야 했는지 알아보고, 나아가 어떻게 분리하여 CQRS 패턴을 구현하는 방법인지 알아봅시다. 

명령과 조회는 왜 분리됐을까?

 일반적인(전통적인?) 애플리케이션은 데이터를 연결된 데이터베이스에 레코드로써 생성(Create)하거나 조회(Read)하거나 갱신(Update)하거나 삭제(Delete)합니다. 그리고 이렇게 애플리케이션이 데이터를 레코드로 저장하는 과정에서 데이터는 특정한 모델(Model)로써 다뤄집니다. 예를 들어, "계좌 잔액" 이라는 데이터는 애플리케이션 내에서 {소유자 ID, 잔액, 일자...}와 같은 속성을 지니는 "BankingBalance.class" 모델로써 다뤄지고, 결국 데이터베이스에는 거래 내역을 나타내는 레코드로써 저장되어, 조회, 갱신, 삭제될 수 있습니다. 

  그러나 이러한 모델은 애플리케이션이 변화하면서 점점 그 형태가 기괴(?)해 질 수 있습니다. 예를 들어, 여러 은행에 관한 계좌를 지원하기 위해 BankingBalance에 "backCode"와 같은 속성이 추가될 수 있습니다. 그리고 이러한 모델은 그대로 레코드로써 데이터베이스에 저장됩니다. 결국 시간이 흐름에 따라 하나의 모델이 점점 다양한 요구사항을 녹여내기 위해 초기 모델보다 거대해지거나 변질될 수 있습니다.

User(UI)에서의 데이터와 데이터베이스의 Record 사이의 애플리케이션 Model. 생성,갱신,삭제와 같은 명령과 조회가 동일한 모델로 처리된다. (출처: https://martinfowler.com/bliki/CQRS.html)

  그런데 만약 그렇게 변질된 모델을 이용하여 데이터를 표현하기 위해선 어떻게 해야 할까요? 기존 표현되던 데이터는 변질된 모델을 재가공해야 합니다. 혹은 새로운 데이터를 표현하기 위해 모델이 다양하게 변경될 수 있습니다. 결국, 모델이 변화함에 따라 실질적으로 데이터를 저장, 갱신, 삭제에 필요한 모델과 조회하여 사용하는 모델 간 차이가 발생하게 됩니다. 그래서 개발자들은 하나의 데이터에 대해 저장, 갱신, 삭제하는 명령 부분과 조회해서 사용하는 조회 부분에 관한 모델을 분리하여 관리하게 됩니다. 이것이 CQRS가 등장하게 된 배경입니다. 

명령 모델과 조회 모델이 분리된 모습. (출처 : https://martinfowler.com/bliki/CQRS.html)

그럼 CQRS 패턴은 만능일까?

 CQRS 패턴은 다른 패턴들과 마찬가지로 어떠한 문제를 해결하는 하나의 방법입니다. 그렇기 때문에 CQRS 패턴은 반드시 적용해야하는 패턴이 아닙니다. 아직 많은 애플리케이션은 CQRS를 적용하지 않는 CRUD 아키텍처가 적합합니다. 게다가 CQRS 패턴은 쉽게 구현할 수 있는 패턴이 아니기에 불필요한 시스템 복잡도를 야기할 수 있습니다. 예를 들어, 모델의 적절한 경계를 구분하기 위해 DDD 방법론이 기반된 도메인 모델링이 필요할 수 있습니다. 

 그렇다면 CQRS 패턴은 어떻게 구현하면 좋을까요?

 CQRS 패턴은 위에서 언급했듯 다양한 방법론과 기술로써 구현할 수 있습니다. 마틴 파울러는 블로그에서 CQRS가 다음과 같은 아키텍쳐 패턴과 방법론을 파생하거나 혹은 필요로 한다고 했습니다.

• 이벤트 형태로 구현된 프로그래밍 모델 
• Event Sourcing
• Eventual Consistency
• Domain Driven Design

그리고 다음과 같이 단계적으로 CQRS 패턴을 구현할 수 있습니다.

기존 아키텍쳐에서 점차 CQRS 패턴이 구현되는 모습. 마지막 단계에서 RDBMS와 NoSQL 간 데이터 이동은 Kafka와 같은 메시지 큐가 적용될 수 있다. (출처 : http://auconsil.blogspot.com/2013/08/cqrs-command-query-responsibility.html)

그리고 최종적으로 명령과 조회에 대한 책임이 별도의 애플리케이션으로 완벽히 분리된 형태로 구현될 수 있습니다.

우아한형제들에서 구현된 CQRS 패턴 모습. 명령과 조회에 관한 책임이 애플리케이션 레벨에서 분리되었다. (출처 : https://www.youtube.com/watch?v=BnS6343GTkY)

마무리 

 이번 글을 통해 CQRS 패턴의 등장 배경부터 관련 기술, 나아가 어떤 모습으로 구현되는지 알아봤습니다. 

참고 

• martinfowler.com/bliki/CQRS.html 
• www.popit.kr/cqrs-eventsourcing/
• auconsil.blogspot.com/2013/08/cqrs-command-query-responsibility.html
• www.youtube.com/watch?v=BnS6343GTkY