🌳 고급 고급
이벤트 소싱(Event Sourcing)
쉽게 이해하기
은행 통장을 생각해보세요. 현재 잔액만 저장하는 게 아니라 입금, 출금, 이체 내역을 모두 기록하잖아요. 그래서 언제든 과거 어느 시점의 잔액을 계산할 수 있고, 어떤 거래가 문제였는지 추적할 수 있어요. 이벤트 소싱도 똑같은 원리예요.
핵심 정리
데이터의 최종 상태만 저장하는 게 아니라, 그 상태에 이르기까지의 모든 변경 이벤트를 순서대로 기록하는 방식이에요.
자세히 알아보기
전통적인 CRUD 방식은 데이터베이스에 최신 상태만 저장해요. 사용자 이름을 'Kim'에서 'Park'으로 바꾸면, 'Kim'이었다는 사실은 사라지죠. 하지만 이벤트 소싱은 'UserNameChanged(Kim → Park)' 같은 이벤트를 저장해요. 현재 상태는 이벤트들을 순서대로 재생(replay)해서 얻어내는 거예요.
이 방식의 장점은 명확해요. 첫째, 완벽한 감사 추적(audit trail)이 가능해요. 금융, 의료, 법률 분야처럼 '누가 언제 무엇을 왜 바꿨는지' 기록이 중요한 곳에서 필수죠. 둘째, 시간 여행이 가능해요. 과거 어느 시점의 시스템 상태를 정확히 재현할 수 있어서 디버깅이나 분석에 유용해요. 셋째, 이벤트 스트림을 다른 서비스가 구독할 수 있어서 마이크로서비스 아키텍처와 궁합이 좋아요.
단점도 있어요. 이벤트가 계속 쌓이니까 스토리지가 많이 필요하고, 현재 상태를 읽으려면 이벤트를 replay 해야 해서 복잡도가 올라가요. 그래서 보통 스냅샷을 주기적으로 저장해서 성능을 확보하죠. '1000번째 이벤트부터가 아니라 최근 스냅샷 + 이후 100개 이벤트'만 replay 하는 식으로요.
실무에서는 주문 시스템, 재고 관리, 계좌 거래처럼 변경 이력이 중요한 도메인에 적용해요. Kafka나 EventStoreDB 같은 도구를 사용하고, CQRS 패턴과 함께 쓰면 읽기 성능 문제도 해결할 수 있어요.