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

# 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 검증 여부를 재확인한다.