llm-wiki/vault/40-publish/blog-topics/contract-registry-schema-owner-vs-row-owner-gate-2026-06-20.md

title, source_type, status, related_branches, related_projects, tags, created, status_label, target_audience, inspiration_url, archive_url

title	source_type	status	related_branches	related_projects	tags	created	status_label	target_audience	inspiration_url	archive_url
blog-topic / contract-registry-schema-owner-vs-row-owner-gate-2026-06-20	blog-topic	raw	feature-contract-registry-governance	ca-tmpl	blog-topic ca-tmpl registry governance contract yaml test ownership	2026-06-20	ready-for-canonical	backend-engineer

blog-topic: contract-registry-schema-owner-vs-row-owner-gate-2026-06-20

Layer: raw/blog-topics/ — 채용공고가 아닌 작업·학습에서 나온 블로그 글감 원석. canonical 정제 전 raw 후보이며, wiki/blog/ 직접 생성 근거가 아니다.

Parent / 부모

• raw/branch-notes/feature-contract-registry-governance — 본 branch 의 schema-owner 게이트(ContractRegistrySchemaGovernanceTest) 구현(Phase C2, 2026-06-20)에서 추출.

트리거 / Trigger

• 트리거 유형: branch-work
• 7개 contract registry(error/env/secrets/header/mdc/metric/capability)의 schema 를 한 branch 가 소유하되 row 값 은 8개 sibling branch 에 위임하는 구조에서, "schema 가 실제로 강제되는가" 를 기계로 증명하려 했다. 기존 테스트는 전부 단일 registry 의 값/enum drift 만 봤고, registry 들이 공통 schema 를 따르는지 를 보는 테스트는 없었다.

글감 코어 / Core idea

• 문제 분리(separation of ownership): registry governance 에는 두 종류의 소유권이 있다 — (a) schema owner: 어떤 column 이 있어야 하는가(구조·저장 형식·변경 절차), (b) row owner: 어떤 code/key/name 값이 존재하는가. 이 둘을 한 테스트로 섞으면 위임이 깨진다. ca-skeleton 은 7 registry 의 schema 를 단일 branch 가, 값은 8 sibling 이 소유.
• schema 게이트의 단언 집합: ① N family 존재(파일 부재 = 누락 = FAIL, silent skip 아님) ② 각 파일의 # Schema owner: 헤더 ③ 모든 row 의 identity + 위임 포인터(owner_branch) ④ full row 의 universal contract column(compatibility_impact legal enum + required_test = "모든 registry 항목은 최소 1개 contract test 와 연결") ⑤ 문서화된 면제(reference row)의 명시적 검증.
• 면제를 검증 가능하게: 한 registry(secrets)는 다른 registry(env-keys)로 값을 위임하는 reference row 를 둔다. 이들은 contract column 을 생략한다. 게이트가 이를 그냥 skip 하면 "면제" 와 "누락" 을 구분 못한다 → reference row 는 reference: target 보유를 별도 단언. (이 함정의 디버그 기록: raw/errors/contract-registry-reference-row-universal-column-false-fail-2026-06-20)
• gitignored seed 위의 테스트 이중 모드: registry SSOT 가 /docs(gitignore)에 있어 CI/fresh checkout 엔 부재. 부재 → Assumptions.assumeTrue 로 SKIP(거짓 green 아님), 존재 → 위반 hard FAIL. "데이터가 없으면 통과" 가 아니라 "데이터가 없으면 검사 안 함, 있으면 엄격" 이 정직한 drift gate 의 기본형.
• 검증(게이트의 실효성 증명): seed 로 6 tests green 만으로는 vacuous 일 수 있다 → 음성 변이(illegal compatibility_impact 주입 → 해당 단언 FAIL → 원복) 로 게이트가 실제로 막는지 증명. "green 한 번" 이 아니라 "틀린 데이터에 red" 까지 봐야 신뢰.

왜 의미 있나 / Why it matters

• "문서로만 있는 거버넌스 규칙은 쉽게 깨진다" 를 fitness function 으로 메우는 스켈레톤 가치의 구체 사례 — 단, 이번엔 코드 구조 가 아니라 데이터 계약(registry yaml) 자체가 대상.
• 멀티-owner registry 에서 "schema vs row" 소유권 분리는 monorepo/플랫폼 팀에서 흔한 구조(공통 schema 팀 + 도메인 팀). 그 경계를 테스트로 박제하는 패턴은 이식성이 높다.
• 한계(글에서 솔직히 명시할 것): 이 게이트는 artifact 가 schema 를 따르는가 만 본다. "registry 에 없는 token 이 코드에 등장하는가" 의 정적 탐지(ArchUnit custom rule)는 별개 PoC 로 미구현(planned). 즉 schema 정합 ≠ token 사용 강제.

글감 / Topic seed

• 한 문장 요지: contract registry governance에서는 schema owner와 row owner를 분리하고, schema gate가 면제 row까지 명시적으로 검증해야 drift를 줄일 수 있다.
• 예상 제목 후보:
  • Registry schema owner와 row owner를 나눈 이유
  • YAML registry governance를 테스트로 고정하기

핵심 주장 후보 / Claim candidates

• 사실 후보:
  • registry schema와 row 값은 서로 다른 owner가 가질 수 있다.
  • reference row는 full row와 다른 검증 경로가 필요하다.
• 의견/해석 후보:
  • schema 정합과 token 사용 강제는 다른 gate이며 같은 테스트로 섞으면 소유권이 흐려진다.

Outline seed

1. schema owner와 row owner의 책임을 분리한다.
2. universal contract column과 reference row 면제 검증을 설명한다.
3. schema gate의 한계와 runtime token 강제의 별도 owner를 구분한다.

Canonical 전환 후보 / Canonical extraction candidates

• wiki/projects/ca-tmpl/skeleton-governance-registry-verification-test-scorecard.md 후보:
  • registry schema owner vs row owner gate 글감.
• 필요한 추가 검증:
  • 실제 ContractRegistrySchemaGovernanceTest와 negative mutation 검증 여부.

Sources / 근거 후보

• raw/branch-notes/feature-contract-registry-governance
• raw/branch-notes/feature-contract-verification-test-suite
• raw/errors/contract-registry-reference-row-universal-column-false-fail-2026-06-20

미해결 / Unknown

• 아직 확인해야 할 사실: schema gate 구현과 negative mutation 검증이 현재 코드에 남아 있는지.
• 과장하면 안 되는 부분: schema 정합을 token 사용 강제나 runtime verification으로 확대하지 않는다.

관련 / Related

• raw/branch-notes/feature-contract-registry-governance
• raw/branch-notes/feature-contract-verification-test-suite — runtime token 강제(11 release-blocking gates) 를 소유하는 sibling. 본 글감의 "schema 정합 ≠ token 사용 강제" 경계의 반대편.
• raw/errors/contract-registry-reference-row-universal-column-false-fail-2026-06-20

Decision / 처리 결정

• 액션: promote-to-canonical
• 이유: wiki/projects/ca-tmpl/skeleton-governance-registry-verification-test-scorecard.md 에 contract registry schema owner vs row owner gate 글감으로 반영했다.
• 다음 단계: target canonical이 아직 draft 이므로 blogify 전 registry schema gate 구현·negative mutation 검증 여부를 재확인한다.