[Daily morning study] Event Sourcing과 CQRS 패턴

06 Nov 2026 in Daily morning study / -database

#daily morning study

---

Event Sourcing

개념

일반적인 데이터 저장 방식은 현재 상태(state)만 저장한다. 예를 들어 계좌 잔액이 10만원이면 DB에는 balance = 100000만 남는다.

Event Sourcing은 상태 변화를 일으키는 이벤트(사건) 자체를 순서대로 저장하는 패턴이다. 현재 상태는 이벤트들을 처음부터 재생(replay)해서 계산한다.

# 전통적인 방식
accounts 테이블: { id: 1, balance: 70000 }

# Event Sourcing 방식
events 테이블:
  1. AccountCreated  { amount: 100000 }
  2. MoneyWithdrawn  { amount: 30000 }
  3. MoneyWithdrawn  { amount: 20000 }
  → 현재 잔액 = 100000 - 30000 - 20000 = 50000

핵심 특징

이벤트는 불변(immutable)이다. 이벤트 로그는 append-only이며, 과거 이벤트를 수정하거나 삭제하지 않는다. 잘못된 작업을 취소할 때는 보상 이벤트(compensating event)를 추가한다.

단일 진실 공급원(Single Source of Truth)이 이벤트 로그다. 현재 상태는 이벤트 로그로부터 파생된 뷰(projection)다.

이벤트 저장소 구조

CREATE TABLE events (
    id          BIGSERIAL PRIMARY KEY,
    aggregate_id UUID NOT NULL,          -- 도메인 객체 식별자
    aggregate_type VARCHAR(100) NOT NULL, -- 예: "Account", "Order"
    event_type  VARCHAR(100) NOT NULL,   -- 예: "MoneyDeposited"
    event_data  JSONB NOT NULL,          -- 이벤트 페이로드
    version     INT NOT NULL,            -- 낙관적 잠금용
    occurred_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- aggregate_id와 version 조합은 unique
CREATE UNIQUE INDEX ON events(aggregate_id, version);

Aggregate 재구성

def get_account(account_id: str) -> Account:
    events = db.query(
        "SELECT * FROM events WHERE aggregate_id = ? ORDER BY version",
        account_id
    )
    account = Account()
    for event in events:
        account.apply(event)  # 이벤트를 하나씩 적용
    return account

이벤트가 수백만 개 쌓이면 재생 시간이 길어지는 문제가 있다. 이를 해결하기 위해 스냅샷(Snapshot)을 사용한다.

스냅샷 패턴

def get_account(account_id: str) -> Account:
    # 가장 최근 스냅샷 조회
    snapshot = db.query(
        "SELECT * FROM snapshots WHERE aggregate_id = ? ORDER BY version DESC LIMIT 1",
        account_id
    )

    if snapshot:
        account = Account.from_snapshot(snapshot)
        # 스냅샷 이후 이벤트만 재생
        events = db.query(
            "SELECT * FROM events WHERE aggregate_id = ? AND version > ? ORDER BY version",
            account_id, snapshot.version
        )
    else:
        account = Account()
        events = db.query(...)

    for event in events:
        account.apply(event)
    return account

Event Sourcing의 장단점

장점

• 완전한 감사 추적(Audit Trail): 모든 상태 변경 이력이 남는다. 금융, 의료 등 규정 준수가 필요한 도메인에 유리하다.
• 시간 여행(Time Travel): 특정 시점의 상태를 재현할 수 있다.
• 이벤트 기반 통합: 다른 서비스가 이벤트를 구독해 비동기로 처리할 수 있다.
• 버그 재현 및 디버깅: 이벤트 시퀀스를 재생해 버그 발생 당시 상태를 복원할 수 있다.

단점

• 쿼리의 복잡성: “현재 잔액이 10만원 이상인 모든 계좌”를 조회하려면 모든 계좌의 이벤트를 재생해야 한다.
• 이벤트 스키마 진화: 이벤트 형식이 바뀌면 기존 이벤트와의 호환성 처리가 복잡하다.
• 결과적 일관성: 프로젝션이 항상 최신 상태가 아닐 수 있다.

---

CQRS (Command Query Responsibility Segregation)

개념

명령(Command)과 조회(Query)를 다른 모델로 분리하는 패턴이다.

• Command: 상태를 변경한다. 반환값은 없거나 성공/실패 여부만 반환한다.
• Query: 상태를 읽는다. 상태를 변경하지 않는다.

기존 CRUD 방식은 같은 모델로 읽기와 쓰기를 모두 처리한다. CQRS는 이를 분리해 각각 최적화한다.

기본 구조

┌────────────────────────────────────────────────────────┐
│                    클라이언트                           │
└────────────┬───────────────────────┬───────────────────┘
             │ Command                │ Query
             ▼                        ▼
  ┌──────────────────┐    ┌───────────────────────┐
  │  Command Handler  │    │   Query Handler        │
  │  (쓰기 모델)      │    │   (읽기 모델)          │
  └────────┬─────────┘    └──────────┬────────────┘
           │                         │
           ▼                         ▼
  ┌────────────────┐        ┌────────────────────┐
  │  Write Store   │        │   Read Store        │
  │  (정규화 DB)   │──────► │   (비정규화 뷰)     │
  └────────────────┘  sync  └────────────────────┘

구현 예시

Command 쪽 (쓰기)

class TransferMoneyCommand:
    from_account_id: str
    to_account_id: str
    amount: int

class TransferMoneyHandler:
    def handle(self, cmd: TransferMoneyCommand):
        # 비즈니스 로직 검증
        from_account = self.account_repo.get(cmd.from_account_id)
        if from_account.balance < cmd.amount:
            raise InsufficientFundsError()

        # 상태 변경 (또는 이벤트 발행)
        from_account.withdraw(cmd.amount)
        to_account = self.account_repo.get(cmd.to_account_id)
        to_account.deposit(cmd.amount)

        self.account_repo.save(from_account)
        self.account_repo.save(to_account)

Query 쪽 (읽기)

class AccountSummaryQuery:
    account_id: str

class AccountSummaryHandler:
    def handle(self, query: AccountSummaryQuery) -> AccountSummaryView:
        # 읽기에 최적화된 뷰 테이블에서 직접 조회
        return self.read_db.query(
            "SELECT * FROM account_summary_view WHERE id = ?",
            query.account_id
        )

읽기 모델은 조회 용도에 맞게 비정규화(denormalization)하거나 Redis 같은 별도 저장소를 사용한다.

CQRS + Event Sourcing 조합

Event Sourcing과 CQRS는 별개의 패턴이지만 함께 사용할 때 시너지가 크다.

Command → Aggregate → 이벤트 저장소 (write store)
                           │
                           ▼ 이벤트 발행
                    Event Handler
                           │
                           ▼ 프로젝션 업데이트
                    Read Model (view)
                           │
                           ▼
                       Query

프로젝션(Projection): 이벤트 로그로부터 읽기 뷰를 만드는 과정.

class AccountBalanceProjection:
    def on(self, event: MoneyDeposited):
        self.read_db.execute(
            "UPDATE account_view SET balance = balance + ? WHERE id = ?",
            event.amount, event.account_id
        )

    def on(self, event: MoneyWithdrawn):
        self.read_db.execute(
            "UPDATE account_view SET balance = balance - ? WHERE id = ?",
            event.amount, event.account_id
        )

프로젝션은 언제든지 이벤트 로그를 처음부터 재생해서 다시 만들 수 있다. 새로운 읽기 요구사항이 생기면 새 프로젝션 뷰를 추가하면 된다.

---

언제 쓸까?

상황	적합성
도메인이 복잡하고 이력 추적이 중요한 경우 (금융, 의료, 커머스)	높음
읽기/쓰기 부하 비율이 크게 다를 때	높음
단순한 CRUD 애플리케이션	낮음 (오버엔지니어링)
팀이 DDD(Domain-Driven Design)에 익숙한 경우	높음

Event Sourcing과 CQRS는 복잡성을 수반하므로, 실제로 그 복잡성이 주는 이점이 있는 도메인에 선택적으로 적용하는 것이 맞다.