Event Replay가 정합성을 깨뜨리는 순간

이벤트 리플레이가 데이터 정합성을 위협하는 이유

현대 소프트웨어 아키텍처에서 이벤트 소싱은 매우 강력한 패턴입니다. 시스템의 상태를 직접 저장하는 대신, 상태를 변화시키는 모든 사건(Event)을 순차적으로 기록하고 이를 재생(Replay)하여 현재 상태를 복구하는 방식입니다. 하지만 이 과정에서 우리는 종종 데이터 정합성이 깨지는 아찔한 상황을 마주하게 됩니다. 왜 이런 일이 발생하는지, 그리고 이를 어떻게 방지할 수 있는지 깊이 있게 알아보겠습니다.

이벤트 리플레이가 무엇인가

이벤트 리플레이는 저장된 이벤트 로그를 처음부터 끝까지 순차적으로 다시 실행하여 시스템의 현재 상태를 재구축하는 과정입니다. 예를 들어, 은행 계좌 시스템이라면 ‘계좌 생성’, ‘입금 100원’, ‘출금 50원’이라는 이벤트들이 순서대로 기록되어 있습니다. 리플레이는 이 로그를 다시 읽어 현재 잔액이 50원임을 계산해내는 과정입니다. 이 방식은 시스템의 과거 상태를 완벽하게 감사(Audit)할 수 있고, 버그 수정 후 데이터를 재계산할 수 있다는 점에서 매우 유용합니다.

정합성이 깨지는 결정적인 순간들

이론적으로는 완벽해 보이는 이벤트 리플레이가 현실에서 정합성을 잃는 이유는 시스템이 외부 세계와 상호작용하기 때문입니다. 다음은 정합성이 깨지는 대표적인 유형입니다.

• 외부 API 호출의 부작용: 이벤트 리플레이를 수행하는 동안 결제 게이트웨이에 다시 결제 요청을 보내거나, 이메일을 중복 발송하는 등의 사이드 이펙트가 발생합니다.

• 시간 의존성 문제: 이벤트가 발생한 시점의 시간과 리플레이를 수행하는 시점의 시간이 달라지면, 시간에 민감한 로직(예: 만료 시간 계산)이 다른 결과를 도출합니다.
• 외부 데이터 소스의 변화: 이벤트가 참조하는 외부 테이블이나 마스터 데이터가 변경된 경우, 과거의 이벤트가 현재의 참조 데이터와 맞물려 엉뚱한 결과를 낼 수 있습니다.
• 비결정론적 로직: 코드 내에 현재 시간, 난수 생성기, 혹은 시스템 환경 변수 등을 사용하는 로직이 포함되어 있다면, 리플레이할 때마다 결과가 달라질 수 있습니다.

흔한 오해와 진실

많은 개발자가 이벤트 리플레이를 단순히 ‘데이터 복구용’으로만 생각합니다. 하지만 리플레이는 비즈니스 로직을 검증하는 도구이기도 합니다. 흔히 하는 오해 중 하나는 “이벤트 로그만 있으면 언제든 완벽하게 복구 가능하다”는 믿음입니다. 하지만 이벤트 자체가 오염되었거나, 이벤트 처리 로직이 변경된 상태에서 리플레이를 돌리면 시스템은 순식간에 망가집니다. 이벤트는 ‘불변(Immutable)’해야 하지만, 이를 해석하는 로직은 끊임없이 진화하기 때문입니다.

정합성 유지를 위한 실무 가이드라인

정합성을 지키기 위해서는 리플레이 과정을 통제해야 합니다. 다음은 현업에서 사용하는 실용적인 전략들입니다.

1. 사이드 이펙트 격리

이벤트를 리플레이할 때는 외부 시스템(결제, 이메일, 푸시 알림)으로 나가는 통로를 반드시 차단해야 합니다. 이를 ‘이벤트 핸들러의 모드 전환’이라고 부릅니다. 리플레이 모드에서는 실제 외부 호출을 수행하지 않고 로그만 남기거나, 가짜(Mock) 객체를 사용하도록 설계해야 합니다.

2. 시간의 고정

시스템 내부에서 시간을 참조할 때는 직접 시스템 시간을 호출하지 말고, 이벤트에 기록된 타임스탬프를 사용하도록 로직을 작성하세요. 리플레이 시점에는 시스템 시간이 아닌 ‘이벤트 발행 시점의 시간’을 컨텍스트로 제공해야 정합성을 유지할 수 있습니다.

3. 결정론적 로직 강제

난수 생성이나 환경 의존적인 로직은 이벤트 데이터에 해당 값을 미리 포함시키는 것이 좋습니다. 예를 들어, 랜덤 코드가 생성되는 이벤트라면, 그 랜덤 값을 이벤트 생성 시점에 결정하여 저장해두면 리플레이 시에도 동일한 값이 사용됩니다.

전문가의 조언: 리플레이를 위한 설계

이벤트 소싱을 설계하는 전문가들은 리플레이를 염두에 두고 ‘이벤트 버전 관리’를 강조합니다. 시간이 지나 비즈니스 로직이 변경되면 과거의 이벤트 구조와 현재의 로직이 충돌합니다. 이때는 ‘업캐스팅(Upcasting)’ 기법을 사용해야 합니다. 업캐스터는 과거 버전의 이벤트를 현재 버전의 이벤트 형태로 변환해주는 중간 계층입니다. 이를 통해 리플레이 로직을 수정하지 않고도 데이터의 정합성을 보장할 수 있습니다.

비용 효율적으로 정합성을 확인하는 방법

매번 전체 이벤트를 리플레이하는 것은 비용이 많이 듭니다. 대신 다음과 같은 방식을 권장합니다.

• 스냅샷 활용: 100번째, 200번째 등 특정 시점마다 상태를 스냅샷으로 저장해 두세요. 리플레이는 전체가 아닌 마지막 스냅샷 이후부터 시작하면 됩니다.

• 정합성 체크섬: 주기적으로 시스템 상태를 해시값(Checksum)으로 저장하고, 리플레이 결과와 비교하세요. 불일치가 발견되면 즉시 경고를 발생시켜야 합니다.
• 점진적 리플레이: 운영 환경 전체를 리플레이하기 전에, 검증 환경에서 특정 이벤트 구간만을 리플레이하여 결과값을 대조하는 자동화 테스트를 구축하세요.

자주 묻는 질문과 답변

Q: 이벤트 로그가 너무 방대하면 리플레이가 불가능하지 않나요?

A: 맞습니다. 그래서 ‘스냅샷’ 전략이 필수입니다. 또한, 오래된 이벤트는 별도의 저장소로 아카이빙하고, 현재 상태를 나타내는 최신 스냅샷을 기반으로 운영하는 것이 일반적인 해결책입니다.

Q: 외부 데이터가 바뀌었는데 과거 데이터를 그대로 쓰면 안 되는 건가요?

A: 데이터의 성격에 따라 다릅니다. 금융 거래라면 당시의 환율이나 이자율을 반드시 이벤트에 포함해야 합니다. 만약 외부 데이터를 참조만 했다면, 그 시점의 데이터 사본을 이벤트에 남기는 것이 정합성을 지키는 가장 안전한 방법입니다.

Q: 리플레이 중 오류가 발생하면 시스템이 멈추나요?

A: 리플레이는 보통 백그라운드 작업으로 수행됩니다. 오류가 발생했을 때 로그를 남기고 다음 이벤트로 넘어갈지, 아니면 즉시 중단할지를 결정하는 ‘에러 처리 정책’을 명확히 설정해야 합니다. 프로덕션 환경에서는 보통 후자를 택하여 정합성을 보호합니다.

데이터 정합성 확보를 위한 체크리스트

시스템을 배포하기 전에 아래 항목들을 확인해 보시기 바랍니다.

• 모든 외부 API 호출은 리플레이 모드에서 차단되는가?
• 시간 관련 로직은 시스템 시간이 아닌 이벤트 데이터를 참조하는가?
• 이벤트 구조가 변경될 경우를 대비한 업캐스팅 로직이 준비되어 있는가?
• 주기적인 스냅샷 저장이 올바르게 작동하는가?
• 리플레이 결과와 실제 상태를 비교하는 검증 스크립트가 존재하는가?

이벤트 리플레이는 시스템의 과거를 재현하여 미래의 안정성을 확보하는 강력한 도구입니다. 하지만 그 과정에서 발생하는 비결정론적인 요소들을 통제하지 못하면 오히려 데이터의 무결성을 해칠 수 있습니다. 위에서 언급한 설계 원칙과 전략들을 차근차근 적용해 나간다면, 이벤트 소싱 시스템의 신뢰도를 극대화할 수 있을 것입니다. 기술적인 복잡함에 매몰되기보다, 데이터가 생성되고 소비되는 흐름을 항상 주시하는 것이 정합성을 지키는 가장 핵심적인 태도입니다.