이 문서의 목표는 두 가지다. 하나, "현재 상태를 덮어쓰는" 일반적인 CRUD 모델과 "일어난 사건을 append-only로 쌓는" Event Sourcing이 어떻게 다른지 감을 잡는 것. 둘, Event Sourcing과 자주 한 묶음으로 거론되는 CQRS가 사실은 독립된 패턴이며, 언제 함께 쓰고 언제 따로 떼어야 하는지 판단 기준을 세우는 것. 결...
이 문서의 목표는 두 가지다. 하나, "현재 상태를 덮어쓰는" 일반적인 CRUD 모델과 "일어난 사건을 append-only로 쌓는" Event Sourcing이 어떻게 다른지 감을 잡는 것. 둘, Event Sourcing과 자주 한 묶음으로 거론되는 CQRS가 사실은 독립된 패턴이며, 언제 함께 쓰고 언제 따로 떼어야 하는지 판단 기준을 세우는 것.
결론부터 말하면, 두 패턴 모두 "기본값으로 깔지 말아야 할" 고급 패턴이다. 대부분의 서비스는 CRUD + 읽기 전용 복제본으로 충분하고, Event Sourcing은 감사(audit) 요구가 강하거나 상태 변화 이력 자체가 비즈니스 가치인 도메인에서만 비용을 정당화한다.
관련 문서: DDD와 도메인 모델링, Outbox / Inbox Pattern 심화, Spring Batch vs Event-Driven, 분산 트랜잭션과 Outbox 패턴. 본 문서는 "상태를 어떻게 저장하고 읽을 것인가"라는 모델링 축에 집중하고, 위 문서들은 이벤트 발행의 정합성 메커니즘과 도메인 모델 설계에 집중한다.
전통적인 CRUD 모델은 한 행(row)이 곧 현재 상태다.
주문이 PAID에서 SHIPPED로 바뀌면 status 컬럼을 UPDATE로 덮어쓴다.
이 순간 "언제, 왜, 누가 이 전이를 일으켰는가"라는 정보는 사라진다.
-- CRUD: 현재 상태만 남고 변화의 history는 증발한다
UPDATE orders SET status = 'SHIPPED', updated_at = NOW() WHERE id = 1001;물론 별도 history 테이블이나 audit 로그를 두면 이력을 보존할 수 있다. 하지만 그건 "본 모델 옆에 이력을 따로 또 관리한다"는 뜻이고, 본 상태와 이력이 어긋날 위험을 항상 안고 간다. Event Sourcing의 출발점은 이 질문이다 — 이력이 그렇게 중요하다면, 이력을 본 모델 자체로 삼으면 어떨까?
Event Sourcing은 현재 상태를 저장하지 않는다. 대신 도메인에서 일어난 사건(event)을 시간순으로 append-only로 쌓고, 현재 상태는 그 사건들을 처음부터 재생(replay)해 계산한다.
주문 1001의 이벤트 스트림 (append-only, 수정/삭제 없음)
seq 1 OrderPlaced { items: [...], amount: 38000 }
seq 2 PaymentCompleted { method: 'CARD', approvedAt: ... }
seq 3 OrderShipped { carrier: 'CJ', trackingNo: ... }
seq 4 OrderDelivered { deliveredAt: ... }
현재 상태 = fold(이벤트들) → status = DELIVERED여기서 중요한 성질 세 가지를 짚고 간다.
OrderShipped는 이미 일어난 일이라 수정·삭제 대상이 아니다. 잘못이 있으면 UPDATE가 아니라 보정 이벤트(ShipmentCanceled 등)를 새로 추가한다.이벤트가 수천, 수만 개로 쌓이면 매번 처음부터 재생하는 비용이 커진다. 그래서 일정 주기로 스냅샷(snapshot)을 떠둔다. "seq 5000 시점의 상태는 이렇다"를 저장해두고, 그 이후 이벤트만 재생하면 된다.
복원 = 가장 최근 스냅샷(seq 5000) + seq 5001 이후 이벤트만 fold스냅샷은 최적화일 뿐 진실의 원천이 아니다. 스냅샷을 통째로 날려도 이벤트 스트림만 살아 있으면 언제든 다시 만들 수 있어야 한다 — 이 불변식이 깨지면 Event Sourcing의 장점이 무너진다.
CQRS는 Command Query Responsibility Segregation의 약자다. 이름이 길지만 핵심은 단순하다 — 상태를 바꾸는 경로(Command)와 상태를 읽는 경로(Query)를 서로 다른 모델로 분리한다.
흔한 오해부터 정리하면, CQRS는 Event Sourcing을 요구하지 않는다. 둘은 독립 패턴이다. CQRS는 단지 "쓰기용 모델과 읽기용 모델을 같은 스키마로 강제하지 말자"는 주장이다.
Command (쓰기) Query (읽기)
요청 ──▶ 도메인 모델 ──▶ 이벤트/변경 ──▶ projection ──▶ 조회 전용 뷰
(불변식 검증) │ (비정규화, 조인 없음)
└── 비동기 반영 가능CQRS가 Event Sourcing과 자주 붙어 다니는 이유는, ES에서 이벤트 스트림이 읽기에 매우 불편하기 때문이다. "배송 중인 주문 목록을 보여줘" 같은 질의를 이벤트를 매번 재생해서 답할 수는 없다.
그래서 이벤트를 구독해 읽기 전용 projection을 미리 만들어 둔다.
OrderShipped 이벤트가 나올 때마다 shipping_orders 읽기 테이블에 행을 넣고, OrderDelivered가 나오면 빼는 식이다.
쓰기 모델(이벤트 스트림)과 읽기 모델(projection)이 자연히 갈라지므로, ES를 쓰면 CQRS는 거의 필연적으로 따라온다.
반대 방향은 성립하지 않는다 — CQRS만 쓰고 쓰기 측은 평범한 RDB UPDATE로 처리해도 전혀 문제없다.
projection이 비동기로 갱신되면, 쓰기 직후 읽으면 옛 데이터가 보일 수 있다. 사용자가 주문을 넣자마자 목록을 새로고침했는데 안 보이는 상황이다. 이건 버그가 아니라 결과적 일관성(eventual consistency)의 정상 동작이다.
설계 단계에서 "이 화면은 읽기 지연을 몇 초까지 허용하는가"를 명시해야 한다. 허용 못 하는 화면(예: 결제 직후 결제 결과)이라면 그 부분만 쓰기 모델에서 직접 동기로 읽거나, projection 갱신을 동기 트랜잭션 안에 묶는 절충을 둔다.
이벤트는 영원히 남는다.
2년 전 OrderPlaced 이벤트도 오늘 재생 가능해야 한다.
그런데 그동안 이벤트 구조가 바뀌면(필드 추가/이름 변경) 옛 이벤트를 어떻게 읽을 것인가가 큰 숙제가 된다.
schemaVersion을 처음부터 넣어 둔다.OrderStatusChanged { from: PAID, to: CANCELED }처럼 상태 전이 결과만 담으면, CRUD의 UPDATE를 이벤트로 포장한 것에 불과하다.
도메인 의도를 살리려면 OrderCanceledByCustomer { reason: ... }처럼 무슨 일이 왜 일어났는지를 담아야 한다.
이 차이가 나중에 "고객 변심 취소율"과 "재고 부족 취소율"을 분석할 수 있느냐를 가른다.
ES/CQRS는 인지 비용과 운영 복잡도가 높다. 재생 로직, 스냅샷, projection 재구축, 이벤트 버전 관리, 결과적 일관성 대응이 전부 따라온다. 단순 CRUD로 충분한 도메인(설정 관리, 단순 게시판)에 깔면 얻는 것 없이 복잡도만 떠안는다.
도입을 검토할 때 점검할 항목들이다.
(streamId, expectedVersion) 기반 optimistic concurrency로 막는다. 버전이 어긋나면 거절하고 재시도한다.작은 주문 애그리거트를 이벤트 fold로 복원하는 형태를 의사코드로 그려보면 핵심이 잡힌다.
type OrderEvent =
| { type: 'OrderPlaced'; amount: number }
| { type: 'PaymentCompleted' }
| { type: 'OrderShipped' }
| { type: 'OrderCanceledByCustomer'; reason: string };
interface OrderState {
status: 'NEW' | 'PAID' | 'SHIPPED' | 'CANCELED';
amount: number;
}
// 현재 상태 = 초기 상태에서 이벤트를 하나씩 접어(fold) 계산
function apply(state: OrderState, e: OrderEvent): OrderState {
switch (e.type) {
case 'OrderPlaced': return { status: 'NEW', amount: e.amount };
case 'PaymentCompleted': return { ...state, status: 'PAID' };
case 'OrderShipped': return { ...state, status: 'SHIPPED' };
case 'OrderCanceledByCustomer':return { ...state, status: 'CANCELED' };
}
}
function rehydrate(events: OrderEvent[]): OrderState {
return events.reduce(apply, { status: 'NEW', amount: 0 });
}여기서 apply는 순수 함수다.
같은 이벤트 목록이면 항상 같은 상태가 나온다 — 이 결정성(determinism)이 재생·스냅샷·projection 재구축을 모두 가능하게 하는 토대다.
아래 질문에 막힘없이 답할 수 있으면 개념이 잡힌 것이다.
OrderStatusChanged와 OrderCanceledByCustomer 중 무엇이 더 좋은 이벤트인가. 이유는.상태를 덮어쓰지 않고 사건을 쌓는 것이 Event Sourcing, 읽기 모델과 쓰기 모델을 분리하는 것이 CQRS다. 둘 다 강력하지만 비용이 크므로, 이력 자체가 가치이거나 읽기/쓰기 부하 특성이 크게 갈리는 도메인에서만 선택적으로 도입한다.