이벤트 필드를 바꾼 뒤 오래된 메시지를 재생하니 소비자가 실패합니다. 이벤트 스키마는 어떻게 진화시키나요?

이벤트는 현재 생산자와 소비자뿐 아니라 보관된 과거 데이터와 미래 재처리도 연결합니다. 필드 추가·삭제·타입·의미·기본값의 호환을 버전과 함께 관리해야 합니다.

동작 원리와 전제

새 필드가 선택적이어도 소비자가 엄격 파싱하면 실패할 수 있고 enum 확장은 행동 분기를 바꿀 수 있습니다. 금액 단위 변경은 타입이 같아도 의미상 깨지는 변경입니다. producer·consumer·보관 데이터 조합을 검사합니다.

선택과 실패 처리

명시적 schema version과 변환 계층을 두거나 새 이벤트 유형으로 분리할 수 있습니다. 모든 소비자를 동시에 배포한다고 가정하지 않습니다. 과거 이벤트에 현재 규칙을 적용해도 되는지와 당시 상태를 재현해야 하는지 목적을 정합니다.

구체적인 사례와 검증

현재 상태 이벤트와 당시 사건 이벤트도 구분합니다. order_total의 의미를 세전에서 세후로 바꾸고 같은 필드명을 유지하면 파싱은 성공하지만 집계가 틀릴 수 있습니다. 새 필드나 새 유형으로 의미를 명시하고 과거 자료의 변환을 정의합니다. schema registry의 backward·forward 호환 옵션이 검사하는 범위도 제품과 포맷에 따라 다르므로 이름만 믿지 않습니다. 오래 보관한 이벤트를 현재 소비자로 재생하는 시험을 별도로 수행합니다. 비밀·개인정보가 과거 payload에 남아 있으면 형식 migration뿐 아니라 보관·삭제 정책도 함께 관리해야 합니다.

오래된 payload·새 소비자·새 payload·옛 소비자·재시도를 시험합니다. schema registry는 구조 호환 검사를 도울 수 있지만 업무 의미까지 자동 증명하지 않습니다. DLQ와 재처리 절차에서 원래 버전·ID를 보존하겠습니다.