데이터 파이프라인을 운영하다 보면 새벽에 깨어 가장 흔하게 마주치는 알람이 스키마 불일치입니다. 누군가 원천 테이블에 컬럼을 추가하거나 타입을 바꾸면 다운스트림 파이프라인이 줄줄이 무너집니다. 스키마는 변하지 않는 것이 아니라 반드시 변하는 것이며, 문제는 그 변화를 어떻게 안전하게 관리하느냐입니다.
이 글에서는 스키마 진화의 유형, 하위 호환성의 의미, 스키마 레지스트리 활용, 그리고 데이터 계약(data contract) 개념까지 다룹니다.
스키마는 왜 깨지는가
문제의 근원은 생산자와 소비자의 분리입니다. 백엔드 팀이 API 응답에 필드를 추가하거나 이름을 바꿀 때, 그 데이터를 소비하는 데이터 팀은 통보받지 못하는 경우가 많습니다. 변경은 정당하지만 조율되지 않은 변경이 파이프라인을 깨뜨립니다.
변경 유형은 크게 호환되는 변경과 깨뜨리는 변경으로 나뉩니다. 선택적 필드 추가는 보통 안전하지만, 필드 삭제나 타입 변경, 필수 필드 추가는 소비자를 망가뜨립니다.
호환성의 세 가지 방향
스키마 호환성은 방향에 따라 정의됩니다. 이 구분을 명확히 해야 어떤 변경이 허용되는지 판단할 수 있습니다.
- 하위 호환(backward): 새 스키마로 옛 데이터를 읽을 수 있음. 필드 삭제, 선택 필드 추가 허용
- 상위 호환(forward): 옛 스키마로 새 데이터를 읽을 수 있음. 필드 추가 허용
- 완전 호환(full): 양방향 모두 가능. 가장 안전하지만 제약이 큼
스트리밍 환경에서는 보통 하위 호환을 기본으로 둡니다. 소비자를 먼저 업데이트한 뒤 생산자가 따라오는 배포 순서를 강제할 수 있기 때문입니다.
스키마 레지스트리 활용
Kafka 환경에서는 Confluent Schema Registry가 사실상 표준입니다. Avro나 Protobuf 스키마를 중앙에 등록하고, 호환성 규칙을 위반하는 스키마는 등록 자체를 거부합니다. 즉 깨뜨리는 변경이 배포 단계에서 차단됩니다.
# 호환성 정책을 BACKWARD로 설정
curl -X PUT http://registry:8081/config/orders-value
-H "Content-Type: application/json"
-d '{"compatibility": "BACKWARD"}'레지스트리는 메시지에 스키마 전체가 아니라 작은 ID만 실어 보내게 해 네트워크 효율도 높입니다. 소비자는 ID로 스키마를 조회해 역직렬화합니다.
데이터 계약과 운영
최근에는 한 걸음 더 나아가 데이터 계약을 코드로 명시하는 흐름이 강합니다. 생산자가 제공하는 스키마, 품질 기준, SLA를 문서가 아니라 검증 가능한 명세로 정의하고, CI에서 변경을 자동 검사합니다. 변경이 계약을 위반하면 머지 전에 빌드가 실패합니다.
운영 팁으로, 컬럼을 즉시 삭제하지 말고 사용 중단(deprecated) 표시 후 일정 기간 유예하세요. 또한 새 필드는 항상 기본값을 지정하고, 타입 변경은 새 컬럼 추가와 점진적 마이그레이션으로 우회하는 것이 안전합니다.
좋은 스키마 관리란 변화를 막는 것이 아니라 변화를 예측 가능하게 만드는 것이다.
정리
스키마는 반드시 변하므로, 핵심은 하위 호환성을 기준으로 변경을 통제하는 것입니다. 스키마 레지스트리로 깨뜨리는 변경을 배포 단계에서 차단하고, 데이터 계약으로 생산자와 소비자의 기대를 코드화하세요. 필드는 즉시 삭제하지 말고 유예하며, 타입 변경은 점진적으로 우회하는 습관이 파이프라인을 지킵니다.
