122. 이벤트 소싱 (Event Sourcing)

핵심 인사이트 (3줄 요약)

본질: 이벤트 소싱 (Event Sourcing)은 시스템의 현재 상태를 저장하는 대신, 그 상태에 이르기까지의 모든 상태 변화 이벤트(event)를 영구적이고 순서가 보장된 추가 전용(append-only) 이벤트 스트림으로 저장하고, 이 이벤트들을 순서대로 재생(replay)하여 현재 상태를 복원하는 패턴이다.

가치: 데이터의 전체 변경 이력이 이벤트로 보존되므로 완벽한 감사 추적(audit trail), 특정 시점으로의 시간 여행(time travel), 이벤트 재생을 통한 새로운 읽기 모델 생성이 모두 가능해진다.

판단 포인트: 이벤트 소싱은 이벤트 스키마 진화, 스냅샷 전략, 긴 이벤트 스트림의 성능이라는 세 가지 기술적 도전을 수반하므로, 감사 추적과 이력 관리가 핵심 요구사항인 금융·의료·법률 도메인에서 그 가치가 극대화된다.

Ⅰ. 개요 및 필요성

전통적인 CRUD (Create, Read, Update, Delete) 방식에서는 현재 상태만 저장하고 이전 상태는 덮어쓴다. 이 방식은 "지금 무엇인가"는 알 수 있지만 "어떻게 이 상태가 되었는가"는 알 수 없다. 금융 거래에서 현재 잔액은 알 수 있지만 어떤 입출금이 있었는지 알 수 없는 상황이 된다.

이벤트 소싱은 이 문제를 근본적으로 해결한다. 현재 잔액 대신 "100원 입금", "50원 출금", "200원 입금" 같은 이벤트들을 순서대로 저장한다. 현재 잔액(250원)은 이 이벤트들을 재생하여 계산한다. 어떤 시점의 잔액도 해당 시점까지의 이벤트를 재생하면 알 수 있다.

┌─────────────────────────────────────────────────────────────┐
│        이벤트 소싱 vs 전통 CRUD 저장 방식 비교              │
├─────────────────────────────────────────────────────────────┤
│  [전통 CRUD] - 현재 상태만 저장                              │
│  계좌 잔액: 250원 (이력 없음)                                │
│                                                             │
│  [이벤트 소싱] - 이벤트 스트림 저장                          │
│  이벤트 #1: AccountOpened(balance=0)  @2026-01-01           │
│  이벤트 #2: MoneyDeposited(amount=100) @2026-01-02          │
│  이벤트 #3: MoneyWithdrawn(amount=50)  @2026-01-03          │
│  이벤트 #4: MoneyDeposited(amount=200) @2026-01-04          │
│                                                             │
│  현재 상태 = 이벤트 #1~#4 순차 재생 → 잔액 250원            │
└─────────────────────────────────────────────────────────────┘

이벤트는 append-only로만 저장된다. 한번 기록된 이벤트는 수정하거나 삭제하지 않는다. 이 불변성(immutability)이 감사 추적의 신뢰성을 보장한다.

📢 섹션 요약 비유: 회계 장부는 숫자를 지우고 고쳐 쓰지 않는다. 잘못된 금액은 반대 방향의 정정 분개를 추가한다. 이벤트 소싱은 이 회계 원칙을 소프트웨어에 적용한 것이다.

Ⅱ. 아키텍처 및 핵심 원리

이벤트 소싱의 핵심 구성 요소는 이벤트 스토어(Event Store), 애그리게이트(Aggregate), 프로젝션(Projection), 스냅샷(Snapshot)이다.

항목	설명	포인트
이벤트 스토어	이벤트를 append-only로 영구 저장	불변성, 순서 보장, 버전 관리
애그리게이트	이벤트를 소비하여 현재 상태 계산	이벤트 적용(apply) 메서드
프로젝션	이벤트로부터 읽기 모델 생성	CQRS 읽기 모델과 결합
스냅샷	특정 시점 상태 저장으로 재생 최적화	N번째 이벤트마다 스냅샷

┌─────────────────────────────────────────────────────────────┐
│      스냅샷을 통한 이벤트 재생 최적화                        │
├─────────────────────────────────────────────────────────────┤
│  이벤트 스트림:                                             │
│  E1 E2 E3 ... E500 [스냅샷] E501 E502 ... E750 [스냅샷] ... │
│                                                             │
│  현재 상태 복원 시:                                         │
│  가장 최근 스냅샷 로드 + 스냅샷 이후 이벤트만 재생          │
│  (전체 이벤트 재생 불필요 → 성능 최적화)                    │
└─────────────────────────────────────────────────────────────┘

이벤트 스키마 진화가 이벤트 소싱의 핵심 기술 도전이다. 초기에 정의한 이벤트 구조가 비즈니스 변화로 바뀌어야 할 때, 이미 저장된 이벤트를 변경할 수 없으므로 업캐스팅(upcasting) 기법으로 이전 버전 이벤트를 최신 버전으로 변환하여 처리한다.

📢 섹션 요약 비유: Git의 커밋 히스토리와 같다. 현재 코드 상태는 모든 커밋을 순서대로 적용한 결과다. 특정 커밋으로 되돌아가거나(time travel), 새로운 브랜치에서 다른 방향으로 실험(새 읽기 모델)할 수 있다.

Ⅲ. 비교 및 연결

이벤트 소싱과 전통 CRUD의 선택은 "현재 상태"와 "변화의 이력" 중 무엇이 핵심 자산인지에 따라 결정된다.

비교 축	A	B
저장 대상	현재 상태 (Latest State)	변화 이벤트 스트림
이력 추적	별도 감사 테이블 필요	이벤트 자체가 이력
시간 여행	불가 (이전 상태 소실)	이벤트 재생으로 가능
복잡도	단순	높음
읽기 성능	직접 조회 (빠름)	프로젝션 필요

이벤트 소싱은 DDD (도메인 주도 설계)의 애그리게이트(Aggregate) 패턴, CQRS와 삼위일체를 이룬다. DDD 애그리게이트가 도메인 경계를 정의하고, 이벤트 소싱이 상태 변화를 이벤트로 저장하며, CQRS가 읽기 모델을 분리한다.

📢 섹션 요약 비유: 사진(CRUD)은 현재 모습만 담지만, 영상(이벤트 소싱)은 모든 순간의 변화를 담는다. 사진으로는 어제 어디에 있었는지 알 수 없지만, 영상은 재생하면 알 수 있다.

Ⅳ. 실무 적용 및 기술사 판단

이벤트 소싱의 실무 도입에서 가장 많이 간과하는 것은 GDPR (General Data Protection Regulation, 일반 개인정보보호 규정) 등 개인정보 삭제 요구와의 충돌이다. 이벤트가 append-only라 삭제가 불가능하므로, 암호화 삭제(cryptographic erasure) 기법으로 개인정보를 암호화하고 키만 삭제하는 방식을 사용한다.

판단 체크리스트

완벽한 감사 추적(audit trail)이 법적·비즈니스적으로 필요한가?
과거 특정 시점의 상태 조회(time travel)가 요구사항인가?
이벤트 스키마 진화 전략이 계획되어 있는가?
스냅샷 전략으로 이벤트 재생 성능이 수용 가능한가?
GDPR 등 개인정보 삭제 요구에 대한 암호화 삭제 전략이 있는가?

📢 섹션 요약 비유: 의료 기록은 현재 상태만 기록하지 않고 모든 진료 이력을 보존한다. 특정 날의 진료 내용을 다시 볼 수 있고, 이력으로 현재 상태를 설명한다.

Ⅴ. 기대효과 및 결론

이벤트 소싱을 적용하면 완벽한 감사 추적, 시간 여행, 이벤트 재생을 통한 버그 재현·재처리, 새로운 읽기 모델의 언제든지 추가가 가능해진다. 특히 금융·의료·법률처럼 이력 추적이 규정 요구사항인 도메인에서 추가 감사 테이블 없이 이 요구사항을 자연스럽게 충족한다.

한계는 기술 복잡도와 초기 학습 비용이다. 이벤트 스키마 설계, 스냅샷 전략, 프로젝션 관리, GDPR 대응이 모두 추가 설계 고려사항이다. 조회 지연(최종 일관성)도 감수해야 한다.

미래 방향으로는 ① 이벤트 소싱 전용 데이터베이스(EventStoreDB)의 성숙, ② 블록체인과 이벤트 소싱의 감사 추적 공유 원칙 활용, ③ ML 모델 학습 데이터로 이벤트 스트림 활용이 주목받고 있다.

이벤트 소싱은 "현재 상태는 과거 모든 변화의 결과물"이라는 철학을 시스템 설계에 적용한 것으로, 변화의 이력이 핵심 자산인 도메인에서 가장 강력한 무기로 기억해야 한다.

📢 섹션 요약 비유: 블랙박스는 현재 차량 상태가 아니라 사고 직전까지의 모든 이동 이력을 기록한다. 이벤트 소싱은 소프트웨어 시스템의 블랙박스다.

📌 관련 개념 맵

[CRUD 이력 소실 문제] → [이벤트 소싱] → [애그리게이트] → [CQRS 읽기 모델] → [감사 추적·시간 여행]

개념	연결 포인트
CQRS	이벤트 소싱의 쓰기 이벤트로부터 읽기 모델 생성
애그리게이트	이벤트를 적용하여 현재 상태를 유지하는 DDD 개념
스냅샷	이벤트 재생 성능 최적화 기법
EventStoreDB	이벤트 소싱 전용 데이터베이스

📈 관련 키워드 및 발전 흐름도

[CRUD 상태 덮어쓰기] → [이벤트 로그 패턴] → [이벤트 소싱 패턴(그렉 영)] → [CQRS+DDD 결합] → [EventStoreDB] → [블록체인·ML 이벤트 스트림 활용]

👶 어린이를 위한 3줄 비유 설명

저금통(현재 잔액)만 보면 돈을 얼마나 넣고 뺐는지 모르잖아요.
이벤트 소싱은 "100원 넣기", "50원 꺼내기" 같은 모든 기록을 순서대로 남기는 방법이에요.
그러면 어느 날의 잔액도 기록을 되감아서 계산할 수 있어요!