이벤트 스키마를 바꿔도 구독자가 멈추지 않게 하는 법

이벤트에 필드를 추가하는 작은 변경도 오래된 구독자를 멈출 수 있습니다. 발행자와 구독자가 서로 다른 시점에 배포된다는 전제로 스키마를 바꿔야 합니다.

데이터 흐름의 경계를 확인한다

새 필드가 필수인지 선택인지부터 정합니다. 구독자가 새 필드를 모를 때도 기존 기능이 동작해야 한다면 기본값과 누락 처리 규칙이 필요합니다. 필드 이름을 재사용해 의미를 바꾸는 일은 호환성 검사만 통과해도 위험할 수 있습니다.

실패와 중복 처리를 정한다

스키마 버전과 호환성 방향을 합의합니다. 새 구독자가 옛 이벤트를 읽어야 하는지, 옛 구독자가 새 이벤트를 읽어야 하는지가 다릅니다. 저장된 이벤트를 나중에 재생하는 시스템이라면 과거 버전을 읽는 능력이 중요합니다.

작은 범위에서 재처리한다

변경은 보통 새 필드 추가, 발행자 전환, 구독자 전환, 옛 필드 제거 순서로 진행합니다. 한 번의 배포로 필드를 삭제하면 아직 갱신하지 못한 서비스가 실패할 수 있습니다. 전환 기간과 제거 책임자를 정합니다.

지연과 불일치를 관측한다

버전별 역직렬화 실패, 미사용 필드 비율, 구독자 업그레이드 완료율을 봅니다. 스키마 등록 단계에서 자동 호환성 검사를 해도 실제 의미 변경은 사람이 검토해야 합니다. 샘플 이벤트를 재생해 오래된 구독자가 어떻게 반응하는지 확인합니다.

복구 절차를 유지한다

이벤트는 외부 계약으로 취급합니다. 필드 이름만 맞춰도 시간대, 단위, null 의미가 바뀌면 계산이 달라집니다. 변경 이유와 마이그레이션 가이드를 남기면 다음 서비스가 같은 실수를 반복하지 않습니다.

현장에 적용할 때의 순서

1. 구독자별 필요한 호환성 방향 정리
2. 추가·전환·제거를 분리 배포
3. 과거 이벤트 재생 테스트

주의할 실패: 의미가 다른 값을 옛 필드에 재사용

관찰할 지표: 역직렬화 오류·전환 완료율

적용 전 체크리스트

• 구독자별 필요한 호환성 방향 정리
• 추가·전환·제거를 분리 배포
• 과거 이벤트 재생 테스트

참고 자료

Confluent — Schema Evolution and Compatibility. 이벤트 스키마의 호환성 방향은 Confluent 공식 문서를 참고했습니다. 단계별 배포 순서는 적용 제안입니다.

이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.

#이벤트스키마 #스키마진화 #호환성 #메시징 #데이터계약 #네이처프랙탈 #시스템설계 #서비스운영 #안정성 #데이터활용