이벤트소싱

title: 2026-03-14 author: 강병호 (이름) date: 2026-03-14 (날짜) category: TIL/강병호/2026/03 (파일 경로 : TIL/{이름}/{연}/{월}) layout: post (자유) —

이벤트 소싱(Event Sourcing)

일반적으로 데이터베이스에 상태를 저장할 때는 ‘현재 값’을 업데이트하는 방식을 사용합니다. 하지만 이벤트 소싱은 데이터의 최종 상태를 저장하는 대신, 상태를 변화시킨 모든 이벤트(Event)의 이력을 순서대로 저장하는 아키텍처 패턴입니다.

완벽한 감사 추적(Audit Trail): 모든 상태 변화가 기록되므로 특정 시점에 데이터가 왜 그렇게 변했는지 완벽하게 추적할 수 있습니다. 이는 금융이나 물류 시스템처럼 이력이 중요한 도메인에서 매우 강력한 이점이 됩니다.
과거 상태 재현 및 타임 머신 기능: 특정 시점의 이벤트를 재생하여 과거 어느 순간의 상태로든 시스템을 되돌리거나 분석할 수 있습니다.
비즈니스 로직 변경에 유연함: 새로운 요구사항이 생겼을 때, 과거의 이벤트를 새로운 로직에 대입하여 다시 계산할 수 있습니다. 즉, 과거 데이터를 기반으로 새로운 통계나 상태를 생성하기 쉽습니다.

쓰기 성능의 최적화: 데이터베이스의 기존 레코드를 수정(Update)하거나 삭제(Delete)하지 않고 오직 추가(Append-only)만 발생하므로, 쓰기 작업에서 락(Lock) 경합이 적고 속도가 매우 빠릅니다.

읽기 성능 저하 상태를 조회할 때마다 모든 이벤트를 재생해야 하므로 이벤트가 쌓일수록 조회 속도가 느려집니다. 이를 위해 특정 시점의 상태를 중간 저장해두는 스냅샷을 사용합니다. 예를 들어 1,000번째 이벤트까지의 결과를 저장해두면, 조회 시 1,001번째 이벤트부터만 재생하면 됩니다.
데이터 용량의 증가 삭제 없이 계속 추가만 되므로 데이터 양이 기하급수적으로 늘어날 수 있습니다. 저장소 비용이 저렴해지면서 예전보다 부담은 줄었지만, 효율적인 이벤트 저장소(Event Store) 선택을 필수적으로 가져가 효율을 가져갑니다.
복잡도 증가 기존의 CRUD 방식에 익숙한 개발자에게는 패러다임의 전환이 필요하며, 이벤트 스키마가 변경될 때 과거 이벤트와의 호환성을 유지해야 하는 어려움(Versioning)이 있습니다.
CQRS 패턴의 필요성 이벤트 소싱은 구조상 조회(Read)가 까다롭기 때문에, 명령(Command)과 조회(Query)를 분리하는 CQRS(Command Query Responsibility Segregation) 패턴과 함께 사용되는 것이 일반적입니다.