상태 대신 이벤트를 저장하면 모든 과거를 재생해 쉽게 복구할 수 있나요?

event sourcing은 상태 변화의 이벤트를 원본 이력으로 저장하고 상태를 재구성하는 방식입니다. 재현 가능성을 높일 수 있지만 이벤트 의미·버전·결정성·외부 효과·보관 정책을 관리해야 합니다.

동작 원리와 전제

당시 가격을 이벤트에 저장하지 않고 재생 때 현재 가격 API를 조회하면 과거 상태가 달라질 수 있습니다. 원본 사실과 파생 계산을 분리하고 코드 버전·upcaster·snapshot 기준을 정합니다. 이벤트 하나의 수정은 이후 결과 전체에 영향을 줄 수 있습니다.

선택과 실패 처리

재생 과정에서 메일·결제를 다시 실행하지 않게 projection 계산과 외부 효과를 분리합니다. 개인정보 삭제와 불변 로그 보관이 충돌할 수 있어 민감 데이터 분리·암호화·보존 정책을 사전에 설계합니다.

구체적인 사례와 검증

이벤트는 '잔액을 100으로 바꿈'과 '10을 입금함'처럼 서로 다른 의미를 가질 수 있습니다. 재생 순서·중복 처리·정정 방식이 달라지므로 도메인 사실을 명확히 정의합니다. 잘못된 이벤트를 지우기보다 보정 이벤트를 추가할 수 있지만 법적 삭제나 민감정보 요구와 충돌하면 별도 보관 설계가 필요합니다. snapshot은 오래된 이벤트 재생 시간을 줄이는 파생 결과이며 어떤 이벤트 위치까지 포함했는지 저장해야 합니다. 최종 상태만 같은지뿐 아니라 중간 권리·상태 전이가 올바른지도 검증합니다. 로그를 저장했다고 당시 외부 의사결정 근거가 모두 남는 것은 아닙니다.

동일 이벤트 재생·과거 버전·snapshot 이후 연결·중복·순서 오류를 시험합니다. 읽기 모델은 다시 만들 수 있어도 원본 이벤트가 틀렸으면 자동 정답이 되지 않습니다. 감사 이점과 스키마·운영 복잡성이 필요한지 단순 상태 저장과 비교하겠습니다.