데이터베이스 쓰기 병목을 해소하는 CQRS와 비동기 이벤트 프로젝션(Read Projection) 아키텍처

1. 단일 데이터 모델의 구조적 한계와 읽기/쓰기 임피던스 불일치

전통적인 모놀리식 웹 애플리케이션은 동일한 RDBMS 데이터 스키마를 사용하여 데이터 생성·수정(CUD)과 복잡한 화면 조회(R)를 동시에 처리합니다. 그러나 서비스 규모가 급증할수록 쓰기(Write) 워크로드와 읽기(Read) 워크로드의 요구 조건은 극단적으로 상충하게 됩니다.

쓰기 연산은 데이터 정합성과 불일치 방지를 위해 제3정규형(3NF) 이상의 정규화된 스키마와 외래 키(Foreign Key), 엄격한 ACID 트랜잭션 격리 수준을 요구합니다. 반면 읽기 연산은 빠른 화면 렌더링을 위해 수십 개의 테이블을 조인(JOIN)하거나 복잡한 집계 연산을 수행해야 하므로, 동일한 정규화 테이블을 공유할 경우 인덱스 경합, 테이블 락, 버퍼 풀 메모리 고갈이 연쇄적으로 발생하여 시스템 전체의 처리량이 급락합니다.

2. CQRS(Command Query Responsibility Segregation) 패턴의 아키텍처 원리

Martin Fowler의 CQRS 아키텍처 가이드 및 마이크로소프트 클라우드 디자인 패턴에 따르면, CQRS는 시스템의 책임을 두 개의 독립적인 축으로 완전히 분리합니다.

• 명령(Command) 모델: 상태를 변경하는 비즈니스 트랜잭션을 전담합니다. 값을 반환하지 않으며(Void), 도메인 규칙 검증과 데이터 무결성 보장에만 집중하는 쓰기 전용 스토리지(RDBMS)를 운영합니다.
• 조회(Query) 모델: 상태를 절대 변경하지 않으며 화면 표시를 위한 DTO를 즉각 반환합니다. UI 화면 구조에 맞춰 완벽히 비정규화(Denormalized)된 읽기 전용 스토리지(Redis, OpenSearch, MongoDB 등)를 독자적으로 운영합니다.
• 독립적 스케일아웃: 일반적으로 10:1에서 100:1에 달하는 읽기/쓰기 트래픽 불균형에 맞춰 조회 저장소만 수평 확장(Scale-out)할 수 있어 인프라 비용 효율성을 극대화합니다.

3. 비동기 이벤트 프로젝션(Read Projection)과 최종 일관성(Eventual Consistency)

명령 저장소와 조회 저장소가 물리적으로 분리되면 두 저장소 간의 데이터 동기화가 핵심 아키텍처 과제로 대두됩니다. 가장 신뢰할 수 있는 방식은 비동기 이벤트 프로젝션(Asynchronous Event Projection)입니다.

• 도메인 이벤트 발행: 명령 서비스가 트랜잭션을 커밋한 직후 OrderCreated, PaymentApproved와 같은 사실(Fact) 이벤트를 메시지 브로커(Kafka, RabbitMQ)로 발행합니다.
• 프로젝션 워커(Projection Worker): 이벤트를 수신한 비동기 컨슈머는 조회 쿼리에 조인이 일절 발생하지 않도록 미리 조립된 뷰 모델(View Model)을 가공하여 읽기 전용 저장소에 Key-Value 또는 문서 형태로 덮어씁니다.
• 최종 일관성 수용: 수십 밀리초(ms) 수준의 이벤트 전파 지연이 존재하지만, 대부분의 비즈니스 도메인에서 조회 화면은 엄격한 실시간 대신 최종 일관성을 허용함으로써 초당 수만 건의 무경합 조회를 실현합니다.

4. 실전 파이프라인 구현: CQRS 명령 서비스 및 비동기 프로젝션 엔진

다음은 쓰기 모델의 트랜잭션 커밋과 도메인 이벤트 발행, 그리고 읽기 전용 캐시로의 비정규화 프로젝션 워커를 구현한 파이썬 엔지니어링 코드입니다.

import time
import uuid
import json
import logging
from typing import Dict, Any, List, Optional
from dataclasses import dataclass

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s [%(levelname)s] (%(name)s) %(message)s',
    datefmt='%Y-%m-%d %H:%M:%S'
)
logger = logging.getLogger('CQRSEngine')

@dataclass
class OrderCreatedEvent:
    event_id: str
    order_id: str
    user_id: str
    total_amount: int
    items: List[Dict[str, Any]]
    created_at: float

class OrderCommandService:
    def __init__(self, event_bus):
        self.event_bus = event_bus
        # 쓰기 전용 RDBMS (정규화된 3NF 모델)
        self.write_db = {}

    def create_order(self, user_id: str, items: List[Dict[str, Any]]) -> str:
        order_id = f'ord_{uuid.uuid4().hex[:8]}'
        total = sum(item['price'] * item['qty'] for item in items)

        # 쓰기 저장소 커밋 (트랜잭션 ACID 보장)
        self.write_db[order_id] = {'user_id': user_id, 'status': 'CREATED', 'total': total}
        logger.info(f'[Command] 주문 데이터베이스 쓰기 커밋 완료: {order_id}')

        # 도메인 이벤트 발행
        evt = OrderCreatedEvent(
            event_id=f'evt_{uuid.uuid4().hex[:8]}',
            order_id=order_id,
            user_id=user_id,
            total_amount=total,
            items=items,
            created_at=time.time()
        )
        self.event_bus.publish(evt)
        return order_id

class OrderReadProjectionWorker:
    def __init__(self):
        # 조회 전용 고속 저장소 (비정규화된 NoSQL/캐시 모델)
        self.read_cache: Dict[str, Dict[str, Any]] = {}

    def on_order_created(self, event: OrderCreatedEvent):
        # 조회 최적화 뷰 모델로 비동기 투영(Projection)
        view_model = {
            'order_id': event.order_id,
            'user_id': event.user_id,
            'summary_title': f'{event.items[0][\'name\']} 외 {len(event.items)-1}건' if len(event.items) > 1 else event.items[0]['name'],
            'total_amount': event.total_amount,
            'item_count': sum(it['qty'] for it in event.items),
            'status_badge': '주문접수',
            'last_updated': event.created_at
        }
        self.read_cache[event.order_id] = view_model
        logger.info(f'[Projection] 읽기 전용 캐시 투영 완료: {event.order_id}')

class InMemoryEventBus:
    def __init__(self):
        self.subscribers = []

    def subscribe(self, handler):
        self.subscribers.append(handler)

    def publish(self, event):
        for handler in self.subscribers:
            handler(event)

if __name__ == '__main__':
    bus = InMemoryEventBus()
    projection_worker = OrderReadProjectionWorker()
    bus.subscribe(projection_worker.on_order_created)

    command_svc = OrderCommandService(event_bus=bus)
    new_id = command_svc.create_order('user_77', [{'name': '무선 키보드', 'price': 89000, 'qty': 1}])
    print('조회 저장소 즉시 룩업:', projection_worker.read_cache.get(new_id))

5. 성능 분석 벤치마크 및 프로덕션 운영 고려사항

초당 15,000건의 동시 조회 요청이 발생하는 대규모 이커머스 결제 내역 화면을 대상으로 단일 RDBMS 모델과 CQRS 이벤트 프로젝션 모델을 비교 실측한 벤치마크 결과는 다음과 같습니다.

프로덕션 환경에서 CQRS 아키텍처를 도입할 때는 다음 사항을 반드시 사전 검토해야 합니다.

• 이중 쓰기 방지를 위한 트랜잭셔널 아웃박스(Transactional Outbox): 명령 저장소 커밋과 메시지 브로커 발행 간의 원자성을 보장하기 위해 아웃박스 테이블 패턴을 필수적으로 결합해야 합니다.
• 프로젝션 리플레이(Projection Replay) 파이프라인: 조회 저장소의 스키마 변경이나 데이터 유실 시 이벤트 히스토리를 처음부터 다시 재생하여 읽기 저장소를 무중단으로 재구축할 수 있는 배치 도구를 구비해야 합니다.
• 도메인 복잡도 기준 도입 평가: 단순 CRUD 연산이 주를 이루는 서비스에 CQRS를 과도하게 적용하면 시스템 복잡도와 운영 비용만 증가하므로, 읽기와 쓰기의 성능 불균형이 극심한 핵심 도메인부터 부분 도입해야 합니다.