이벤트 및 스케줄링 기반의 CQRS 패턴을 활용한 데이터 집계 최적화
서론: 런타임 재집계의 한계와 능동적 데이터 축적의 필요성
이전의 프로젝트에서는 대량의 데이터를 조회할 때마다 실시간으로 전체 재집계를 수행하는 방식을 주로 사용해 왔습니다. 이러한 방식은 데이터 소스가 늘어날수록 쿼리 연산 부하를 증가시켰고, 결과적으로 시스템 전체의 응답 속도를 저하시키는 고질적인 성능 병목의 원인이 되었습니다.
본 프로젝트에서는 이러한 구조적 한계를 극복하고자 팀 내 기술 표준인 CQRS 패턴을 실무에 적용하였습니다. 단순히 읽기와 쓰기를 분리하는 교과서적인 접근을 넘어, 이벤트와 스케줄링을 활용한 능동적 데이터 축적 방식을 도입하여 조회 시점의 부하를 최소화하고 안정적인 성능을 확보하는 데 집중했습니다.
2. 설계 전략: 전통적 CQRS와 실무형 모델의 결합
본 프로젝트에서는 시스템의 성능 최적화를 위해 CQRS(Command Query Responsibility Segregation) 패턴을 도입했습니다.

2.1. 전통적인 CQRS 방식
전형적인 CQRS 아키텍처는 데이터의 변경을 처리하는 명령(Command)과 조회를 처리하는 조회(Query)의 책임을 엄격히 분리합니다.
- 물리적 분리: 명령용 DB(주로 RDB)와 조회 전용 저장소(NoSQL 등)를 따로 두고, 이벤트 메시징 등을 통해 데이터를 동기화합니다.
- 단방향 흐름: 모든 변경은 명령 모델을 통해서만 일어나며, 모든 읽기 작업은 조회 모델에서만 수행되어 시스템의 확장성을 극대화합니다.
2.2. 프로젝트에 적용한 실무형 CQRS
본 프로젝트에서는 데이터베이스를 물리적으로 나누는 대신, 동일 DB 내에서 논리적으로 모델을 분리하는 방식을 선택하여 운영 비용과 복잡도를 낮췄습니다.
- Command Side (Domain Model) 데이터의 생성, 수정, 삭제(CUD)와 더불어 일반적인 조회를 담당합니다. 비즈니스 로직 수행에 필요한 단건 조회나 정합성이 즉각적으로 보장되어야 하는 기본 조회 기능은 도메인 모델에서 그대로 처리하여 구현 생산성을 유지했습니다.
- Query Side (Read Model) 런타임에 연산 비용이 과도하게 발생하는 대용량 집계 및 통계 조회를 수행합니다. 조회 시점에 수만 건의 데이터를 재계산하지 않고, 이벤트와 스케줄러를 통해 미리 가공되어 축적된 데이터를 즉시 응답할 수 있는 구조를 구축하여 성능을 극대화했습니다.
3. 구현 상세: 이중 동기화 메커니즘의 적용
- Event-Driven Strategy (Real-time Responsiveness): 사용자의 상태 변경(Command)이 발생할 때마다 이벤트를 발행하고, 이를 비동기적으로 처리하여 사용자 응답 속도에 영향을 주지 않으면서 조회용 테이블을 즉각 갱신했습니다. 이는 조회 시점에 모든 로그를 전수 조사하지 않아도 항상 최신 상태의 요약본을 제공합니다.
- Scheduled Accumulation (Stable Data Storage): 이벤트로 처리하기에 연산량이 너무 많거나 복잡한 통계 데이터는 Scheduled 작업(스케줄링 작업)을 통해 주기적으로 처리했습니다. 시스템 부하가 적은 시간에 미리 연산을 끝내둠으로써 시스템 자원을 효율적으로 배분했습니다.
4. 결과: 기술적 고민과 성과
- Performance Optimization: 매 요청 시 수행되던 무거운 집계 연산을 사전 축적 방식으로 전환함으로써, 이론적으로 약 80% 이상의 조회 성능 개선 효과를 기대할 수 있게 되었습니다. 실제 시연 환경에서도 대량 데이터 로딩 시 지연 시간(Latency) 없는 쾌적한 UX를 확인했습니다.
- Scalability & Maintenance: 비즈니스 로직과 조회 로직이 분리됨으로써 코드 가독성이 향상되었고, 향후 새로운 통계 요구사항이 추가되어도 기존 시스템에 영향 없이 유연하게 확장할 수 있는 기반을 마련했습니다.
5. 결론: 기술 표준의 실무 최적화를 통한 자산화
팀 내 기술 표준인 CQRS를 실제 프로젝트에 적용하며, 이론적 모델을 우리 환경에 맞게 최적화하는 과정을 거쳤습니다. 특히 이벤트와 스케줄링을 혼합한 이중 동기화 전략은 기존 프로젝트들의 성능 병목을 해결하는 실질적인 대안이 되었습니다. 이러한 설계 경험과 최적화 노하우는 향후 유사한 집계 기능이 필요한 타 프로젝트에도 적용 가능한 기술 자산이 될 것입니다.
* Reference
- Martin Fowler. (2011). "CQRS"
- Microsoft Azure Architecture Center. "CQRS Design Pattern".