스키마 레지스트리 데이터 계약 관리 가이드: 외주 개발 후에도 깨지지 않는 서버 간 데이터 기준
스키마 레지스트리 데이터 계약 관리 가이드: 외주 개발 후에도 깨지지 않는 서버 간 데이터 기준
답부터 말하면, 데이터 구조 변경 때문에 장애가 나는 팀은 개발 실력이 부족한 것이 아니라 계약 없는 배포 구조를 운영하고 있는 경우가 많습니다. REST API의 v1, v2 경로만 정해도 Kafka 이벤트, 내부 gRPC 메시지, 관리자 화면용 집계 API, 정산 배치 파일, 외부 연동 payload까지는 보호되지 않습니다. 실무 기준은 네 가지입니다. 첫째, 서버 간 주고받는 데이터 구조를 OpenAPI, Protobuf, Avro, JSON Schema 같은 명시적 스키마로 남긴다. 둘째, 후방·전방·전체 호환성 중 어떤 변경을 허용할지 서비스별로 정한다. 셋째, Pull Request와 CI에서 breaking change를 기계적으로 차단한다. 넷째, 외주 개발 인수인계 산출물에 소스코드뿐 아니라 스키마 저장소, 소비자 영향표, 배포 순서를 포함시킨다.
Confluent Schema Registry는 Avro, JSON Schema, Protobuf 스키마를 저장·검증·조회하는 REST 서비스와 Kafka client용 serializer/deserializer를 제공하며, Schema Registry의 호환성 검사는 subject 단위로 스키마 버전을 관리하는 것이 핵심입니다. 즉 도구의 본질은 문서함이 아니라 producer와 consumer가 같은 데이터 약속을 지키도록 배포 전에 막아주는 게이트입니다. ([docs.confluent.io](https://docs.confluent.io/platform/current/schema-registry/index.html))

1. 데이터 계약은 API 문서보다 좁고, 장애 예방에는 더 직접적입니다
데이터 계약은 업스트림이 보내는 값과 다운스트림이 기대하는 값 사이의 약속입니다. 예를 들어 주문 서비스가 OrderCreated 이벤트를 발행하고, 알림 서비스·정산 배치·CRM 연동·관리자 대시보드가 이를 소비한다면 계약의 상대방은 한 팀이 아니라 여러 실행 경로입니다. Confluent의 Data Contracts 문서도 데이터 계약을 upstream component와 downstream component 사이의 합의로 설명하고, 스키마뿐 아니라 품질 검증 규칙, metadata, tag, migration rule 같은 요소를 함께 다룹니다. 다만 일부 고급 rule 기능은 제품·패키지·라이선스 조건을 확인해야 하므로, 작은 팀은 처음부터 모든 기능을 사는 것보다 계약 문서와 CI 검증부터 시작하는 편이 안전합니다. ([docs.confluent.io](https://docs.confluent.io/platform/current/schema-registry/fundamentals/data-contracts.html))
운영 기준: 필드 하나를 바꾸는 일은 코드 수정이 아니라 소비자와의 계약 변경입니다. 계약 변경은 문서, 검증, 배포 순서가 함께 있어야 합니다.
실패 사례는 대개 비슷합니다. 이벤트 payload의 userId를 memberId로 바꿨는데 관리자 화면은 아직 예전 필드를 읽습니다. 정산 배치가 price를 정수 원화로 해석했는데 신규 서비스가 소수점 금액을 넣습니다. Protobuf 메시지에서 더 이상 쓰지 않는 필드 번호를 재사용했더니 오래된 binary payload를 읽을 때 전혀 다른 의미로 파싱됩니다. 이런 문제는 단위 테스트 몇 개로 잡기 어렵고, 배포 전 계약 검사가 필요합니다.
2. OpenAPI, Protobuf, Avro, JSON Schema는 경쟁 도구가 아닙니다
비기술 임원이나 PM 입장에서는 스키마 도구 이름이 모두 비슷해 보입니다. 그러나 선택 기준은 간단합니다. HTTP 요청·응답을 설명하려면 OpenAPI가 자연스럽고, 내부 RPC와 SDK 생성을 중시하면 Protobuf가 강합니다. Kafka 이벤트는 Schema Registry와 연결되는 Avro, Protobuf, JSON Schema 중 팀 언어와 소비자 생태계에 맞춰 고릅니다. OpenAPI Specification은 HTTP API를 사람과 컴퓨터가 이해할 수 있는 언어 독립적 인터페이스로 정의하고, 요청·응답·schema object를 명세할 수 있게 합니다. ([spec.openapis.org](https://spec.openapis.org/oas/v3.1.0.html))

| 상황 | 우선 검토 도구 | 맞는 이유 | 주의할 점 |
|---|---|---|---|
| 프론트엔드, 외부 파트너, 모바일 앱이 호출하는 HTTP API | OpenAPI + API diff | endpoint, request, response, 인증 방식, 예시 payload를 한 문서로 공유하기 쉽습니다. | 문서만 있으면 부족합니다. 실제 provider가 문서대로 동작하는지 테스트해야 합니다. |
| 내부 서비스 간 gRPC, SDK 자동 생성 | Protobuf + Buf | 메시지 타입과 서비스 정의를 기준으로 여러 언어의 client/server 코드를 만들 수 있습니다. | 필드 번호 변경·재사용은 치명적입니다. 삭제한 필드는 reserved로 잠가야 합니다. |
| Kafka 이벤트 스트림, CDC 이후 가공 이벤트 | Schema Registry + Avro 또는 Protobuf 또는 JSON Schema | producer와 consumer가 같은 subject의 스키마 버전을 기준으로 호환성 검사를 받을 수 있습니다. | subject naming strategy를 잘못 정하면 호환성 검사 범위가 너무 넓거나 좁아집니다. |
| JSON 기반 이벤트와 유연한 payload | JSON Schema | 기존 JSON 처리 흐름을 크게 바꾸지 않고 구조 검증을 시작할 수 있습니다. | additionalProperties와 strict/lenient 정책에 따라 실제 호환성 의미가 달라집니다. |
| 특정 소비자가 기대하는 요청·응답 시나리오 | 소비자 주도 계약 테스트 | schema가 모든 가능성을 설명한다면, 계약 테스트는 실제 소비자가 쓰는 concrete interaction을 검증합니다. | 기능 테스트를 대체하지 않습니다. 소비자와 provider 사이의 오해를 줄이는 용도로 설계해야 합니다. |
Pact 문서는 contract testing을 통합 지점의 메시지가 공유된 계약에 맞는지 각 애플리케이션을 분리해 검증하는 기법으로 설명합니다. 따라서 OpenAPI나 Schema Registry가 정적 구조의 기준이라면, 소비자 주도 계약 테스트는 실제 사용 시나리오의 기준입니다. 둘 중 하나만 고르는 문제가 아니라, 외부 API는 OpenAPI와 contract test를 함께 쓰고, 이벤트는 Schema Registry와 consumer smoke test를 함께 쓰는 식으로 계층을 나누는 것이 현실적입니다. ([docs.pact.io](https://docs.pact.io/))
HTTP API 변경 정책을 별도로 세워야 한다면 기존 글인 API 버전 관리 가이드를 함께 보시면 좋습니다. 이 글의 초점은 URL 버전이 아니라 payload 구조, 이벤트 메시지, 내부 RPC까지 포함한 데이터 계약입니다.
3. 호환성 모드는 배포 순서의 언어입니다
스키마 레지스트리에서 가장 먼저 정해야 할 것은 어떤 변경을 허용할지입니다. Confluent Schema Registry의 기본 호환성 모드는 BACKWARD이며, 스키마가 업데이트될 때 새 버전을 받아들이기 전에 호환성을 확인합니다. 또한 Transitive 계열은 직전 버전뿐 아니라 이전 모든 버전과 비교하는 방식입니다. ([docs.confluent.io](https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html))
| 호환성 모드 | 쉽게 말한 의미 | 권장되는 배포 상황 | 주의점 |
|---|---|---|---|
BACKWARD | 새 schema를 쓰는 consumer가 예전 데이터도 읽을 수 있어야 합니다. | consumer를 먼저 배포하고 producer를 나중에 바꿀 수 있는 조직 | 예전 consumer가 새 producer의 데이터를 읽는 것은 별도 보장이 아닙니다. |
FORWARD | 예전 schema를 쓰는 consumer가 새 데이터도 읽을 수 있어야 합니다. | 모바일 앱, 외부 파트너처럼 consumer 업데이트가 느린 경우 | producer가 먼저 바뀌는 상황을 전제로 설계해야 합니다. |
FULL | Backward와 Forward를 모두 만족해야 합니다. | producer와 consumer 배포 순서를 완전히 통제하기 어려운 경우 | 허용되는 변경 폭이 줄어듭니다. 초기 설계에서 optional, default, enum 정책을 잘 잡아야 합니다. |
BACKWARD_TRANSITIVE 등 Transitive | 직전 버전뿐 아니라 과거 버전들과도 호환되어야 합니다. | Kafka topic 보관 기간이 길거나 과거 이벤트 replay가 자주 필요한 경우 | 개발 편의성은 낮아지지만 데이터 재처리 리스크를 줄입니다. |
NONE | 호환성 검사를 하지 않습니다. | 실험용 topic, 폐기 예정 내부 prototype | 운영 데이터, 정산, 외부 연동에는 원칙적으로 피해야 합니다. |
Protobuf를 Kafka 이벤트나 gRPC 계약에 쓴다면 호환성 판단이 더 섬세해집니다. Protocol Buffers 문서는 필드 번호가 wire format에서 필드를 식별하므로 사용 중인 메시지의 필드 번호를 바꿀 수 없고, 삭제한 필드 번호는 재사용하지 않도록 reserved 처리하라고 설명합니다. 또한 필드를 추가하는 것은 binary wire 관점에서 안전하지만, type 변경이나 field number 변경은 기존 메시지 파싱을 깨뜨릴 수 있습니다. ([protobuf.dev](https://protobuf.dev/programming-guides/proto3/))
4. 무엇이 breaking change인지 먼저 합의해야 합니다
스키마 도구는 모든 장애를 자동으로 막지 않습니다. 타입 변경, 필수 필드 추가, Protobuf field number 재사용처럼 기계적으로 잡기 쉬운 문제가 있는 반면, amount의 단위가 원에서 달러로 바뀌는 문제, createdAt이 초 단위에서 밀리초 단위로 바뀌는 문제, enum 값의 의미가 바뀌는 문제는 schema만으로는 부족합니다. 그래서 데이터 계약에는 구조와 함께 의미 설명, 예시, owner, 소비자 목록이 필요합니다.
| 변경 예시 | 장애 가능성 | 기계 검출 | 권장 처리 |
|---|---|---|---|
userId를 memberId로 rename | 기존 consumer가 null 또는 undefined로 처리 | OpenAPI diff, JSON Schema diff, Protobuf JSON 정책에서 일부 검출 | 새 필드를 추가하고 일정 기간 둘 다 제공한 뒤 deprecate |
id 타입을 integer에서 string으로 변경 | 파싱 실패, join 실패, 관리자 검색 오류 | 대부분 검출 가능 | 새 필드로 추가하거나 major version 분리 |
| 필수 필드 추가 | 기존 producer가 값을 만들지 못하거나 기존 데이터 replay 실패 | 형식별로 검출 가능 | optional 또는 default로 시작하고 소비자 전환 후 required 검토 |
| Protobuf field number 재사용 | 기존 binary payload가 다른 의미로 해석될 수 있음 | Buf와 proto lint 정책으로 검출 가능 | 삭제한 번호와 이름을 reserved로 남김 |
| enum 값의 이름은 같지만 의미 변경 | 정산·권한·상태 머신 오류 | 대개 검출 어려움 | 계약 문서에 의미와 전환일을 명시하고 새 enum value 추가 |
| 금액, 시간, timezone, 소수점 정책 변경 | 매출 집계, 알림 예약, SLA 계산 오류 | 대개 검출 어려움 | 단위·timezone·precision을 필드 설명과 예시 payload에 명시 |
| 개인정보 필드 추가 | 접근권한, 로그 마스킹, 보관기간 위반 가능 | tag/rule 체계가 있으면 일부 가능 | PII tag, 로그 제외, masking, 보관 정책을 함께 승인 |
DB 스키마 변경과 이벤트 스키마 변경은 함께 움직입니다. 컬럼을 추가하고 백필하는 동안 이벤트 consumer가 어떤 값을 읽을지 정해야 하기 때문입니다. 운영 중 데이터 변경 절차가 필요하다면 데이터베이스 마이그레이션 전략 가이드의 백필·롤백 기준과 함께 설계해야 합니다.
5. Kafka에서 subject naming strategy가 중요한 이유
Schema Registry에서 subject는 호환성 검사와 버전이 묶이는 namespace입니다. Confluent 문서는 serializer가 schema를 subject 이름 아래 등록하고, compatibility check와 version이 subject에 연결된다고 설명합니다. 기본 TopicNameStrategy는 topic 이름을 기준으로 subject를 만들며, RecordNameStrategy와 TopicRecordNameStrategy는 record 또는 topic+record 기준으로 여러 이벤트 타입을 다루는 선택지를 제공합니다. ([docs.confluent.io](https://docs.confluent.io/platform/current/schema-registry/fundamentals/serdes-develop/index.html))
| 전략 | 적합한 경우 | 운영상 질문 |
|---|---|---|
TopicNameStrategy | 한 topic에 사실상 하나의 이벤트 구조만 흐르는 경우 | 이 topic에 다른 이벤트 타입을 넣고 싶어질 가능성이 있는가? |
RecordNameStrategy | 같은 record가 여러 topic에서 같은 계약으로 쓰이는 경우 | topic별로 같은 이름의 record가 다른 의미를 갖는 상황은 없는가? |
TopicRecordNameStrategy | 한 topic에 여러 이벤트 타입을 넣되 topic별 호환성 범위를 나누고 싶은 경우 | consumer가 record type dispatch와 dead letter 처리를 안정적으로 구현했는가? |
작은 팀은 처음부터 복잡한 multi-event topic을 만들기보다, 핵심 도메인 이벤트를 명확한 topic으로 나누고 subject 전략을 단순하게 가져가는 편이 유지보수에 유리합니다. 반대로 데이터 플랫폼 팀이 있고 event catalog, replay, lineage를 적극 운영한다면 record 기준 전략과 schema references를 검토할 수 있습니다. 중요한 것은 나중에 바꾸기 어렵다는 점입니다. subject 전략은 naming 취향이 아니라 장기 호환성 범위를 결정합니다.
6. CI/CD에서는 스키마 변경을 코드 변경과 같은 수준으로 막아야 합니다
스키마 레지스트리를 도입했는데도 운영 장애가 난다면 대개 세 가지 중 하나입니다. 개발자가 로컬에서만 schema를 바꾸고 registry에 등록하지 않았거나, registry에는 등록했지만 CI가 호환성 실패를 차단하지 않았거나, producer는 배포됐지만 consumer 배포 순서가 맞지 않은 경우입니다. Buf의 buf breaking은 현재 Protobuf schema를 과거 버전과 비교해 client, server, generated code, wire format을 깨뜨릴 수 있는 변경을 보고하며, local, CI, Buf Schema Registry 단계에서 실행할 수 있습니다. ([buf.build](https://buf.build/docs/breaking/))

- 스키마 저장 위치를 정합니다. 애플리케이션 repo 내부의
/schema, 별도 contract repo, monorepo 중 하나를 택합니다. 중요한 것은 배포되는 코드와 어떤 schema version이 연결되는지 추적 가능해야 한다는 점입니다. - PR 템플릿에 소비자 영향 항목을 넣습니다. 어떤 subject, topic, endpoint, proto package가 바뀌는지, known consumer는 누구인지, 배포 순서는 무엇인지 적게 합니다.
- lint와 code generation을 먼저 돌립니다. Protobuf라면 package naming, reserved field, generated SDK를 확인하고, OpenAPI라면 schema validation과 client generation 실패를 확인합니다.
- 호환성 검사를 merge gate로 둡니다. Protobuf는
buf breaking --against '.git#branch=main'처럼 baseline과 비교하고, Kafka schema는 Registry compatibility check 또는 build plugin으로 확인합니다. OpenAPI는 API diff 도구를 붙여 breaking endpoint·response 변경을 잡습니다. Buf usage guide는buf breaking이 baseline으로 Git reference, BSR module, archive 등을 받을 수 있다고 설명합니다. ([buf.build](https://buf.build/docs/breaking/usage/)) - merge 후 registry publish를 자동화합니다. 운영에서는 개발자 노트북에서 수동 등록하는 방식을 피하고, main branch 또는 release tag 기준으로 등록되게 합니다.
- 배포 순서를 runbook으로 남깁니다. BACKWARD 정책이면 보통 consumer를 먼저 올리고 producer를 나중에 바꿉니다. FORWARD가 필요한 외부 consumer 환경이면 producer 변경 전후로 old consumer read 검증이 필요합니다.
- 런타임 관측성을 둡니다. deserialization error, schema id mismatch, unknown field 비율, dead letter queue 증가, contract test 실패율을 배포 지표로 봅니다.
운영 환경에서는 자동 등록을 어디까지 허용할지도 결정해야 합니다. 개발·스테이징은 빠른 실험을 위해 auto registration을 켤 수 있지만, 운영에서는 사전 등록과 승인 절차를 요구하는 팀이 많습니다. 이 결정은 도구 설정 문제가 아니라 조직의 변경관리 수준 문제입니다.
7. 데이터 계약 문서에는 스키마 파일보다 더 많은 정보가 필요합니다
스키마 파일만 있으면 필드 구조는 알 수 있지만, 왜 존재하는지와 누가 쓰는지는 알기 어렵습니다. 특히 외주 개발이나 정부지원 MVP처럼 개발 주체와 운영 주체가 달라지는 프로젝트에서는 다음 항목을 인수인계 산출물로 받아야 합니다.

| 항목 | 받아야 할 내용 | 검수 질문 |
|---|---|---|
| 스키마 원본 | OpenAPI yaml, proto file, Avro schema, JSON Schema 원본과 저장소 경로 | 빌드 산출물이 아니라 사람이 수정 가능한 원본인가? |
| 버전 기준 | subject 이름, package 이름, endpoint version, release tag | 운영 중인 코드가 어떤 스키마 버전과 연결되는가? |
| 호환성 정책 | subject별 BACKWARD, FULL_TRANSITIVE 등 정책 | 왜 이 정책을 선택했는지 배포 순서와 함께 설명되는가? |
| 소비자 목록 | 서비스명, 담당자, 사용 필드, 실패 시 영향 | 필드 삭제 전에 연락해야 할 대상이 명확한가? |
| 예시 payload | 정상, 빈 값, 오류, 경계값, 개인정보 포함 예시 | 테스트와 운영 문의 대응에 바로 쓸 수 있는가? |
| 검증 파이프라인 | CI 설정, 실패 예시, branch protection, registry publish 로그 | 다음 변경 때 자동으로 막히는가? |
| 마이그레이션 계획 | 필드 deprecate 일정, dual write, backfill, rollback 절차 | 깨지는 변경이 필요할 때 승인 흐름이 있는가? |
| 보안·개인정보 | PII tag, masking, 로그 제외, 보관 기간 | 관리자 화면과 로그에서 민감값이 노출되지 않는가? |
외주 개발 인수인계 단계에서는 서버 접속 정보와 소스코드만 확인하면 부족합니다. 다음 개발사가 필드 하나를 바꿀 때 어떤 consumer가 깨지는지 알 수 있어야 유지보수가 가능합니다. 산출물 검수 범위는 외주개발 인수인계 체크리스트와 함께 스키마·계약 항목을 별도로 추가하는 것이 좋습니다.
8. 도입 순서: 작은 팀은 Registry보다 계약 목록부터 시작해도 됩니다
모든 팀이 첫 달부터 완성형 Schema Registry, event catalog, contract test platform을 갖출 필요는 없습니다. 오히려 초기 SaaS나 지원사업 MVP에서는 관리 대상이 적을 때 기준을 잡아두는 것이 중요합니다. 추천 순서는 다음과 같습니다.
- 장애가 자주 나는 경계 3개를 고릅니다. 예: 주문 생성 이벤트, 결제 승인 webhook, 관리자 통계 API.
- 각 경계의 계약 owner를 정합니다. owner가 없으면 필드 삭제와 의미 변경이 회의 없이 일어납니다.
- 스키마 원본을 repo에 넣습니다. 문서 캡처나 Notion 표가 아니라 빌드와 검증이 가능한 파일이어야 합니다.
- 허용 변경과 금지 변경을 표로 정합니다. optional 추가는 허용, type 변경은 금지, enum 의미 변경은 승인 필요처럼 단순하게 시작합니다.
- CI에서 최소 한 가지 검사를 강제합니다. Protobuf면 Buf breaking, OpenAPI면 spec validation과 diff, Kafka면 Schema Registry compatibility check부터 시작합니다.
- 다음 외주·내부 개발 요청서에 반영합니다. 기능 명세서에 endpoint만 쓰지 말고 event, schema, consumer, migration을 포함합니다.
이렇게 하면 도구 도입이 목적이 아니라 운영 기준이 목적이 됩니다. AgentMit이 SaaS, 관리자 대시보드, 업무 자동화, BizMit 백엔드, 정부지원 MVP를 설계할 때도 스키마 레지스트리는 단순 인프라 옵션이 아니라 유지보수 가능한 서버 구조의 일부로 봅니다. 이미 Kafka나 gRPC가 있다면 registry와 CI 검증을 붙이고, 아직 단순 REST 구조라면 OpenAPI와 계약 테스트, admin 화면의 데이터 의미 문서부터 잡는 식으로 단계화할 수 있습니다.
9. 실무 의사결정 체크리스트
- 이 데이터는 HTTP request/response, event, RPC message, batch file 중 무엇인가?
- 이 계약의 producer와 consumer는 각각 누구이며, 외부 파트너나 모바일 앱처럼 업데이트가 느린 consumer가 있는가?
- 과거 데이터를 replay해야 하는가? Kafka retention, audit, 정산 재처리 요구가 있는가?
- 필드 추가는 optional/default로 시작할 수 있는가?
- 필드 rename이 필요한 경우 dual field 기간과 종료일이 정해졌는가?
- Protobuf를 쓴다면 삭제한 field number와 field name을 reserved로 남기는가?
- Schema Registry subject 전략이 topic 운영 방식과 맞는가?
- CI에서 schema compatibility 실패가 merge를 막는가?
- 운영 배포 순서가 compatibility mode와 맞는가?
- 외주 인수인계 문서에 schema repo, registry 설정, consumer 영향표, 예시 payload가 포함되는가?
위 질문에 답하지 못한다면 아직 도구를 구매할 단계가 아니라 데이터 계약 체계를 정리할 단계입니다. 반대로 답은 있지만 구현 시간이 부족하다면 AgentMit은 OpenAPI/Protobuf 스키마 저장소 설계, Kafka Schema Registry 연동, CI/CD breaking change gate, 관리자 화면과 정산 배치에 연결되는 데이터 계약 문서화, BizMit 업무 자동화 백엔드 구조까지 함께 설계할 수 있습니다. 구현 상담이 필요하다면 프로덕션 문의에서 현재 API와 이벤트 구조를 기준으로 논의할 수 있습니다.
FAQ
Q1. 스키마 레지스트리는 Kafka를 쓸 때만 필요한가요?
Kafka 이벤트에서는 효과가 가장 직접적이지만, 핵심은 서버 간 데이터 계약을 버전 관리하고 변경을 검증하는 것입니다. HTTP API는 OpenAPI, 내부 RPC는 Protobuf와 Buf, 이벤트 스트림은 Schema Registry처럼 통신 방식에 맞는 도구를 조합하는 편이 현실적입니다.
Q2. REST API 버전 관리와 데이터 계약 관리는 무엇이 다른가요?
API 버전 관리는 주로 URL, endpoint, 배포 정책을 다룹니다. 데이터 계약 관리는 요청·응답·이벤트·배치 파일의 필드, 타입, 의미, 소비자 영향, 호환성 검증까지 포함합니다. v1 경로를 유지해도 이벤트 필드 의미가 바뀌면 consumer는 깨질 수 있습니다.
Q3. Avro, Protobuf, OpenAPI 중 무엇부터 도입해야 하나요?
외부 또는 프론트엔드 HTTP API가 많으면 OpenAPI부터, 내부 gRPC나 SDK 생성이 중요하면 Protobuf부터, Kafka 이벤트 장애가 반복되면 Schema Registry와 Avro·Protobuf·JSON Schema 중 하나부터 시작하는 것이 좋습니다. 한 번에 모두 도입하기보다 장애가 많이 나는 경계부터 잡는 편이 효과적입니다.
Q4. 후방 호환성과 전방 호환성은 어떤 기준으로 선택하나요?
소비자를 먼저 배포할 수 있으면 후방 호환성이 유리하고, 생산자가 먼저 바뀌어도 기존 소비자가 읽어야 하면 전방 호환성이 필요합니다. 배포 순서를 통제하기 어렵거나 이벤트 재처리가 잦으면 Full 또는 Transitive 계열을 검토해야 합니다.
Q5. 외주 개발 산출물에 스키마 레지스트리를 포함시키려면 무엇을 요구해야 하나요?
소스코드뿐 아니라 스키마 파일 저장소, subject/topic 명명 규칙, 호환성 모드, CI 검증 로그, 예시 payload, 소비자 목록, breaking change 승인 절차, 운영·스테이징 Registry 접속 정보, 롤백 절차를 검수 항목으로 명시해야 합니다.
참고한 공식 문서
- Confluent Schema Registry 공식 문서: 지원 스키마 형식, Registry 역할, SerDes, subject 전략을 확인했습니다. ([docs.confluent.io](https://docs.confluent.io/platform/current/schema-registry/index.html))
- Confluent Schema Evolution 및 Data Contracts 문서: 호환성 모드, transitive 검사, 품질 규칙과 metadata 범위를 정리하는 데 참고했습니다. ([docs.confluent.io](https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html))
- Buf 공식 문서: Protobuf breaking change 검사와 CI baseline 비교 방식을 확인했습니다. ([buf.build](https://buf.build/docs/breaking/))
- Protocol Buffers 공식 문서: field number, reserved field, 안전한 메시지 변경 기준을 확인했습니다. ([protobuf.dev](https://protobuf.dev/programming-guides/proto3/))
- OpenAPI Specification 및 Pact 공식 문서: HTTP API 명세와 소비자 주도 계약 테스트의 역할을 구분하는 데 참고했습니다. ([spec.openapis.org](https://spec.openapis.org/oas/v3.1.0.html))

