이벤트 소싱 (Event Sourcing)

한 줄 정의: 데이터의 "현재 상태"만 저장하는 대신, 상태를 바꾼 모든 사건(이벤트)을 순서대로 기록해서 그 이벤트들을 다시 재생하면 현재 상태를 알 수 있게 하는 설계 방식입니다.

쉽게 풀면

은행 계좌를 예로 들면, 일반적인 방식은 "현재 잔액 10만 원"이라는 결과값만 데이터베이스에 저장합니다. 하지만 이벤트 소싱은 다릅니다. "5만 원 입금", "2만 원 출금", "7만 원 입금" 같은 사건 하나하나를 순서대로 저장해 두고, 필요할 때 이 사건들을 처음부터 다시 계산해서 현재 잔액을 구합니다. 마치 가계부를 결과만 적지 않고 모든 거래 내역을 하나씩 적어 두는 것과 같습니다. 이렇게 하면 "언제, 왜 잔액이 바뀌었는지" 이력을 완벽하게 되짚어볼 수 있습니다.

왜 중요한가

이벤트 소싱은 데이터 변경 이력을 완전하게 보존하기 때문에 감사(audit)나 규제 준수가 중요한 금융·의료 시스템, 그리고 사용자 행동 분석이 핵심인 서비스에서 소프트웨어공학 논문의 단골 소재로 다뤄집니다. 상태를 언제든 과거 시점으로 재구성할 수 있다는 특성은 디버깅과 장애 분석뿐 아니라, 여러 서비스가 독립적으로 이벤트를 구독해 반응하는 분산 시스템·마이크로서비스 아키텍처 설계와도 밀접하게 연결됩니다. 이 때문에 분산 시스템, 소프트웨어 아키텍처, 데이터 관리 분야의 연구에서 폭넓게 인용됩니다.

논문에서는 이렇게 쓰입니다

"제안 시스템은 이벤트 소싱(event sourcing) 패턴을 적용하여 상태 변경 이력을 불변(immutable) 로그로 저장하고, 임의 시점의 상태를 재구성할 수 있도록 하였다."

이 문장은 "상태 변화를 기록으로 남겨서, 나중에 과거 어느 시점의 상태였는지도 다시 계산해 낼 수 있게 만들었다"는 뜻입니다.

"금융 거래 시스템에서 이벤트 소싱 기반 원장을 도입하여 모든 거래 내역을 재생 가능한 이벤트 스트림으로 관리함으로써 감사 추적성을 높였다."

이 문장은 금융 시스템 논문에서, 거래 기록을 이벤트 단위로 남겨 언제든 과거 거래를 검증하고 추적할 수 있도록 설계했다는 뜻입니다.

"마이크로서비스 간 데이터 일관성을 확보하기 위해 이벤트 소싱과 사가(saga) 패턴을 결합한 아키텍처를 제안하였다."

이 문장은 분산 시스템 논문에서, 여러 독립 서비스가 이벤트를 매개로 상태를 조율하는 설계를 이벤트 소싱과 결합해 제안했다는 내용입니다.

조금 더 깊게 보면

이벤트 소싱을 실제로 구현할 때는 이벤트가 계속 누적되며 재생 비용이 커지는 문제를 완화하기 위해 특정 시점의 상태를 스냅샷으로 저장해두고, 그 이후 이벤트만 재생하는 방식이 흔히 쓰입니다. 또한 명령을 처리해 이벤트를 생성하는 쓰기 모델과, 빠른 조회를 위한 읽기 전용 모델을 분리하는 CQRS 패턴과 함께 적용되는 경우가 많은데, 이는 이벤트 재생 부담을 조회 경로에서 분리하기 위함입니다. 이벤트 스트림은 흔히 카프카(Kafka) 같은 메시지 브로커나 전용 이벤트 저장소에 기록되며, 이벤트 순서 보장과 스키마 변경(버전 관리)이 실무에서 중요한 논의 지점으로 다뤄집니다.

주의할 점

이벤트 소싱은 변경 이력을 온전히 보존한다는 장점이 있지만, 이벤트가 계속 쌓이면 현재 상태를 재구성하는 데 시간이 오래 걸릴 수 있습니다. 이를 보완하기 위해 조회 전용 모델을 별도로 두는 CQRS 패턴과 함께 쓰이는 경우가 많습니다.