데이터 형식·스키마·호환성

필드 하나를 고쳤는데 여러 시스템이 멈추는 이유

주문 메시지의 amount를 숫자에서 문자열로 바꾸거나 필수 필드 currency를 추가했다고 하자. 새 프로그램끼리는 잘 동작해도 아직 교체되지 않은 소비자는 메시지를 읽지 못할 수 있다. 생산자와 소비자가 동시에 한순간에 바뀐다는 보장이 없기 때문이다.

데이터 변경은 파일 한 줄의 수정이 아니라 시간차를 두고 공존하는 여러 버전 사이의 계약 변경이다. 스키마 호환성은 이 시간차 속에서도 서비스를 계속 움직이게 하는 성질이다.

먼저 되짚기: 바이트열에는 구조 복원 규칙이 있다

직렬화는 구조화된 값을 바이트열로 바꾸고 되돌리는 과정이었다. 받는 쪽은 필드 이름·자료형·선택 여부를 알아야 복원할 수 있다. 스키마는 이 구조와 의미를 명시하고, 호환성은 그 스키마가 바뀌는 동안 이전·이후 프로그램이 함께 읽고 쓸 수 있는지를 묻는다.

생산자와 소비자는 같은 순간에 바뀌지 않는다

호환성은 한 프로그램의 새 코드만 보는 것이 아니라 전환기간의 생산자·소비자·과거 데이터를 함께 보는 문제다.

스키마와 스키마 호환성

스키마(schema)는 데이터에 어떤 필드가 있고 각 필드의 이름·자료형·제약·관계·의미가 무엇인지 정한 계약이다. 단순한 모양뿐 아니라 amount가 세금 포함 금액인지, 단위가 원인지 같은 의미도 함께 관리해야 한다.

스키마 호환성은 데이터 형식이 바뀌어도 기존 생산자와 소비자가 계속 해석할 수 있는 성질이다. 새 소비자가 옛 데이터를 읽을 수 있으면 하위 호환, 옛 소비자가 새 데이터를 읽을 수 있으면 상위 호환이라고 부른다. 두 방향을 모두 만족하는지는 변경 종류와 읽기 규칙에 달려 있다.

필드를 안전하게 추가하는 순서

기존 메시지 {orderId, amount}에 currency를 추가한다고 하자. 곧바로 필수 필드로 만들면 옛 생산자가 값을 보내지 못한다. 안전한 변경은 읽는 쪽과 쓰는 쪽의 시간차를 고려한다.

1. 새 소비자 배포: currency가 없으면 합의한 기본 의미로 읽음
2. 새 생산자 배포: currency를 함께 기록함
3. 관찰: 옛 메시지·옛 생산자가 더 남았는지 확인
4. 필요할 때만 제약 강화: 누락을 오류로 바꾸기 전 잔존 버전 제거

이 순서의 핵심은 소비자가 먼저 두 형식을 읽게 한 뒤 생산자가 새 형식을 쓰게 하는 것이다. 필드 삭제는 반대로 먼저 소비자가 그 필드를 사용하지 않도록 바꾸고, 그 후 생산자가 쓰기를 멈춘다. 값의 의미를 바꾸는 변경은 이름이 같아도 비호환일 수 있으므로 새 필드나 새 버전으로 분리하는 편이 안전하다.

SC-1: 선택 필드 하나를 네 조합으로 검증한다

v1 메시지는 {orderId, amount}, v2는 선택 필드 currency를 추가한다고 하자. 새 소비자는 currency가 없으면 기존 의미인 KRW로 읽고, 옛 소비자는 모르는 선택 필드를 무시한다는 계약을 둔다.

생산자는 메시지를 만들어 보내는 프로그램, 소비자는 그 메시지를 읽어 사용하는 프로그램이며 v1/v2는 이전판/새판을 뜻한다. orderId는 주문 식별값, amount는 금액, currency는 통화 표시이고 KRW는 이 예에서 원화의 표시다. 아래 네 조합은 전환기간 동안 모든 거래가 기존의 원화 의미를 유지한다는 가정에서 시험한다. 옛 소비자가 currency를 무시하더라도 기존 금액의 의미가 같아야 정상이다.

이 표가 성립한 뒤에 생산자가 currency를 쓰기 시작할 수 있다. 그런데 새 소비자가 currency 누락을 즉시 오류로 바꾸면 v1 → v2가 실패한다. 따라서 제약 강화는 옛 생산자가 모두 사라진 뒤 별도 단계로 수행한다.

또 amount의 단위를 원에서 천 원으로 조용히 바꾸면 네 조합이 문법상 파싱되어도 의미가 깨진다. 형식 호환과 의미 호환을 따로 시험한다.

실제 입력으로 {orderId: 42, amount: 10000}을 v2 소비자에게 보내면 currency 누락을 원화로 해석하여 10,000원 주문을 만든다. 반대로 {orderId: 42, amount: 10000, currency: KRW}를 v1 소비자에게 보내면 currency만 무시하고 같은 10,000원 주문을 만든다. 여기서 currency를 다른 통화로 바꾸면 옛 소비자는 여전히 원화로 읽으므로 “모르는 필드를 무시했다”는 문법 검사가 성공해도 금액 의미는 실패한다. 다른 통화의 쓰기는 해당 의미를 처리하는 소비자로 보내거나 새 버전 경로를 분리할 때까지 보류한다.

전환 담당자는 배포 전에 이 네 입력 조합의 읽은 값과 실제 금액을 비교해 모두 같은지 확인한다. 어느 하나가 오류 또는 다른 의미를 만들면 생산자의 새 쓰기를 시작하지 않고 소비자 준비 단계로 돌아간다. 변경 뒤에도 이전판 요청·과거 기록이 남아 있는지 관찰하고, 원화 기본값을 제거하려면 그 기록의 변환과 소비자 전환이 모두 끝났는지를 확인한다. 이렇게 입력·판정·중단 조건을 두어야 “무중단 변경한다”는 지침이 실행 가능한 절차가 된다.

변경 종류별 판단

호환성 판단은 문법 검사만으로 끝나지 않는다. status="done"의 뜻이 “배송 완료”에서 “처리 완료”로 바뀌면 바이트와 자료형이 같아도 업무 의미는 깨진다. 생산자·소비자 목록, 보존 중인 과거 데이터, 배포 순서와 되돌리기 방법을 함께 본다.

실패조건과 방어

전면 동시 배포 가정은 한 소비자라도 늦게 바뀌면 실패한다. 버전 공존 기간을 설계한다.

기본값의 의미 누락은 필드가 없을 때 그 값이 0인지 모름인지 정하지 않은 경우다. 누락·0·빈 문자열의 의미를 따로 정한다.

소비자 장부 부재는 누가 데이터를 읽는지 몰라 삭제 시점을 결정할 수 없게 한다. 생산·소비 관계와 버전을 추적한다.

형식 검증에만 의존하면 문법상 맞아도 단위·시간대·상태 의미가 달라진 것을 놓칠 수 있다. 대표 사례와 경계값을 사용한 계약 시험을 둔다.

무기한 호환은 모든 옛 형식을 계속 지원하므로 해석 규칙을 복잡하게 만든다. 지원 종료 조건과 데이터 변환 계획을 명시한다.

자체 10점 문제

스키마 호환성과 무중단 변경 절차를 설명하시오.

요구어는 설명이다. 생산자·소비자의 네 조합과 안전한 배포 순서, 의미 비호환을 연결한다.

출처와 적용 경계

본문은 생산자·소비자의 시간차를 다루는 안정된 스키마 진화 원칙과 자체 v1/v2 예를 사용한다. 실제 포맷의 unknown-field 처리·기본값·버전 협상 규칙은 사용하는 직렬화 형식과 제품 문서를 확인한다.

30초 정리

1. 스키마는 필드의 모양뿐 아니라 제약·관계·단위와 업무 의미를 담는 데이터 계약이다.
2. 스키마 호환성은 여러 버전의 생산자·소비자와 과거 데이터가 공존해도 계속 해석할 수 있는 성질이다.
3. 읽는 쪽을 먼저 확장하고 쓰는 쪽을 나중에 바꾸며, 의미 변경·배포 순서·종료 조건까지 관리한다.

자기교정과 조건 변경

옛 소비자가 unknown field를 오류로 처리한다면? v2 생산자가 currency를 보내는 순간 v2→v1이 실패하므로 별도 버전·중간 형식 등 다른 전환전략이 필요하다.

currency의 기본 의미가 KRW가 아니라 모름이라면? 누락을 임의 KRW로 채우지 않고 업무 규칙에 맞는 unknown 상태나 별도 버전을 사용한다.

amount의 자료형을 숫자에서 문자열로 바꾸려면? 같은 이름을 즉시 교체하지 않고 두 형식을 읽는 전환기나 새 필드를 설계한다.