1. 이벤트 소싱(Event Sourcing)란?
일반적인 시스템에서는 데이터의 현재 상태(State) 를 저장한다.
그러나 이벤트 소싱에서는 시스템에서 발생한 모든 변경 내역(이벤트)을 저장하고, 이를 기반으로 현재 상태를 유추한다.
즉,데이터를 직접 저장하는 것이 아니라, 변경 이력을 이벤트 형태로 저장하는 방식이다.
💡 이벤트 소싱의 핵심 개념
- 데이터의 최종 상태가 아니라, 상태 변화의 과정(이벤트) 을 저장한다.
- 특정 시점의 상태를 재구성할 수 있다.
- 데이터 변경 기록 자체가 시스템의 근본적인 데이터 저장 방식이 된다.
2. 이벤트 소싱 vs 일반적인 CRUD
일반적인 CRUD 방식
- 유저가 상품을 장바구니에 추가하면, 장바구니 테이블에 새로운 행을 삽입
- 유저가 상품 수량을 변경하면, 해당 행을 업데이트
- 유저가 상품을 제거하면, 해당 행을 삭제
📌 단점:
- 과거 데이터를 복원할 수 없음 (어떤 변경이 있었는지 알 수 없음)
- 데이터 변경 내역을 추적하려면 별도의 로그 테이블이 필요함
이벤트 소싱 방식
- 유저가 상품을 추가하면 "장바구니에 상품 추가됨" 이벤트 저장
- 유저가 수량을 변경하면 "장바구니 상품 수량 변경됨" 이벤트 저장
- 유저가 상품을 제거하면 "장바구니 상품 제거됨" 이벤트 저장
📌 장점:
- 과거 모든 변경 이력을 추적할 수 있음
- 특정 시점의 상태를 다시 복원할 수 있음
- 이벤트를 기반으로 비동기 이벤트 처리 가능 (Kafka, RabbitMQ 등 활용)
3. 이벤트 소싱의 예제
1️⃣ 이벤트 저장 방식
데이터베이스에 현재 상태를 직접 저장하는 것이 아니라 아래와 같이 이벤트를 기록한다.
📌 특징:
- OrderCreated, OrderItemAdded, OrderCompleted 같은 이벤트를 저장함
- 주문의 상태를 DB에서 직접 조회하는 것이 아니라, 이벤트를 순서대로 읽어서 최종 상태를 계산함
2️⃣ 특정 시점의 상태 재구성 (Event Replay)
이벤트 소싱의 가장 큰 장점은 특정 시점의 데이터를 복원할 수 있다는 것이다.
- 예를 들어, 위의 이벤트들을 모두 재생하면(Replay):
- 주문 생성됨 (OrderCreated)
- 상품1 추가됨 (OrderItemAdded)
- 상품2 추가됨 (OrderItemAdded)
- 주문 완료됨 (OrderCompleted)
➡️ 이를 통해 Order 1001의 최종 상태가 주문 완료(PAID) 라는 것을 알 수 있음.
➡️ 만약 특정 시점(예: 상품 추가까지만 완료된 시점)으로 돌아가려면, 해당 시점까지의 이벤트만 적용하면 됨.
4. 이벤트 소싱의 장점과 단점
✅ 장점
- 1.이력 추적 가능
- 모든 변경 사항을 기록하므로, 과거 데이터를 복원할 수 있음
- 2.비동기 이벤트 처리 가능
- 이벤트를 Kafka, RabbitMQ 같은 메시지 큐에 전송하여 다른 서비스에서 활용 가능
- 3.원본 데이터 손실 없음
- 기존 데이터베이스에서는 업데이트/삭제 시 데이터가 사라지지만, 이벤트 소싱에서는 모든 변경 이력이 남아 있음
- 4.리플레이(Replay) 기능 지원
- 특정 시점의 상태를 다시 생성 가능
❌ 단점
- 1.데이터 조회 성능 문제
- 현재 상태를 얻으려면 모든 이벤트를 적용해야 하므로 성능 저하 가능
- 해결책: 스냅샷(Snapshot) 사용 (예: 특정 시점의 상태를 저장하고, 이후 이벤트만 적용)
- 2.데이터 구조 복잡성 증가
- 일반적인 CRUD보다 복잡한 설계 필요
- 3.이벤트 버전 관리 필요
- 이벤트 구조가 변경될 경우 기존 이벤트들과의 호환성 문제 발생 가능
5. 이벤트 소싱을 적용할 만한 시스템
다음과 같은 시스템에서 이벤트 소싱을 활용하면 유리하다.
- 금융 거래 시스템 (모든 변경 이력을 남겨야 함)
- 주문 및 결제 시스템 (주문 상태 변경을 추적해야 함)
- 마이크로서비스 아키텍처 (비동기 이벤트 기반 처리 필요)
- 감사(Audit) 로그가 필요한 시스템 (변경 내역을 상세히 기록해야 함)
6. 이벤트 소싱과 CQRS의 관계
이벤트 소싱(Event Sourcing)과 CQRS(Command Query Responsibility Segregation)은 자주 함께 사용된다.
- 이벤트 소싱: 데이터 저장 방식 (이벤트를 저장하고, 상태를 재구성)
- CQRS: 읽기와 쓰기를 분리하는 설계 패턴 (쓰기 모델과 읽기 모델 분리)
📌 실제로 CQRS + 이벤트 소싱을 함께 사용하면
- Command에서 이벤트를 발생시키고,
- Query에서는 최신 상태를 빠르게 조회할 수 있도록 별도의 읽기 모델(Read Model) 을 구성함.
예를 들어,
- 1.OrderCreated 이벤트가 발생하면 주문 테이블에 이벤트를 저장
- 2.동시에 읽기 전용 데이터베이스(Read DB) 에 주문 상태를 업데이트
- 3.사용자가 주문 내역을 조회하면, 이벤트 테이블이 아닌, 최적화된 Read DB에서 조회
7. 정리
✅ 이벤트 소싱은 설계 기법이자 데이터 저장 전략이다.
✅ CRUD 방식이 데이터의 현재 상태만 저장하는 반면, 이벤트 소싱은 모든 변경 내역을 저장한다.
✅ 과거 데이터를 복원하고, 비동기 이벤트 처리를 활용할 수 있다.
✅ CQRS와 함께 사용하면 성능 문제를 해결할 수 있다.
Fail Fast, Fail Often