현재 상태만 저장할까, 일어난 일 전부를 저장할까?

전통적인 CRUD는 테이블에 현재 상태 한 줄만 유지해요. 계좌 잔고가 100 → 130 → 80으로 바뀌면 컬럼 값을 UPDATE로 덮어씁니다. 편하지만, 이전 값과 그 이유는 그 순간 사라져요. "왜 80이 됐지?"라는 질문에 답할 근거가 DB에 남지 않습니다.

이벤트 소싱(Event Sourcing)은 상태 변경 하나하나를 불변(immutable) 이벤트로 만들어 append-only 로그(이벤트 스토어)에 순서대로 기록해요. 이벤트는 과거형 사실(MoneyDeposited)이고, 한번 쓰이면 수정·삭제하지 않아요. 현재 상태가 필요하면 처음부터 이벤트를 재생(replay)해 다시 계산합니다.

// 이벤트는 과거형 사실 — 불변
sealed interface AccountEvent {}
record AccountOpened(String id, long initial) implements AccountEvent {}
record MoneyDeposited(long amount)          implements AccountEvent {}
record MoneyWithdrawn(long amount)          implements AccountEvent {}

// 현재 상태 = 이벤트들을 fold(재생)한 결과
long balance = events.stream().reduce(0L, (bal, e) -> switch (e) {
    case AccountOpened o    -> o.initial();
    case MoneyDeposited d   -> bal + d.amount();
    case MoneyWithdrawn w   -> bal - w.amount();
}, Long::sum);
// events = [Opened(100), Deposited(30), Withdrawn(50)]  ->  balance == 80

한 애그리거트에 이벤트가 수만·수십만 개 쌓이면, 상태 하나 복원하려고 매번 전부 재생하는 건 느려요. 스냅샷(Snapshot)은 특정 버전까지 재생한 결과 상태를 미리 저장해 두는 최적화예요. 이후에는 가장 최근 스냅샷을 불러온 뒤 그 이후 이벤트만 재생하면 됩니다.

CQRS는 명령(Command, 상태를 바꾸는 쓰기)과 조회(Query, 상태를 읽는 읽기)를 서로 다른 모델로 분리하는 패턴이에요. 하나의 도메인 모델이 쓰기와 읽기를 다 감당하려다 비대해지는 문제를, 두 축으로 나눠 각자 최적화합니다.

이벤트 소싱과 결합하면, 쓰기 쪽이 남긴 이벤트를 구독해 읽기 모델(프로젝션, Projection)을 만들어요. 프로젝션은 조회에 딱 맞게 비정규화된 읽기 전용 뷰(예: RDB 조회 테이블, Elasticsearch 인덱스, Redis 캐시)입니다. 화면·질의마다 서로 다른 프로젝션 여러 개를 둘 수도 있어요.