같은 것을 다섯 가지로 적고 있었다

데이터 계약을 만들다 보면 조용히 자라는 부채가 있습니다 — 같은 것을 여러 모양으로 적는 것. 어느 날 점검해 보니, 함정 제원(길이·배수량·속력·센서)을 표현하는 스키마가 다섯 개나 흩어져 있었습니다. 자산마다 제각각이라, "이 함정의 속력"을 어디서 읽어야 할지조차 애매했습니다.

파편화의 비용

도식 렌더링 중…

스키마가 다섯이면, 그것을 읽는 코드도 다섯 갈래, 검증도 다섯 갈래, 버그도 다섯 배입니다. 새 기능은 어느 스키마를 따라야 하나부터 막힙니다. 단일 진실 공급원(SSOT)이 깨진 상태죠.

⚠️ 파편화는 "당장 편해서" 자란다 — 새 자산을 추가할 때 기존 스키마가 안 맞으면, 그 자리에서 살짝 다른 스키마를 만드는 게 빠릅니다. 그게 다섯 번 반복되면 파편화입니다. "지금 1분 절약"이 "나중에 다섯 배 부채"가 됩니다.

통합 — 정본 하나 + 이행 경로

해법은 정본(canonical) 스키마 하나를 정하고, 기존 데이터를 거기로 이행(migrate) 하는 것입니다.

도식 렌더링 중…

• 감사(audit) — 어떤 자산이 어떤 스키마를 쓰는지, 채택률을 측정. 시작은 정본 채택률 0% 였습니다.
• 이행(migrate) — 기존 데이터를 정본 형식으로 변환. 채택률을 끌어올림.
• 검증(validate) — 정본 스키마에 표준 규칙을 붙여, 값이 물리적으로 타당한지(예: 배수량 대비 속력) 자동 검사.

실제로 이 과정으로 정본 채택률을 0% → 약 78%로 올리고, 21개 검증 테스트를 붙였습니다.

💡 정본은 검증의 닻이다 — 스키마가 하나로 모이면, 거기에 표준(예: 해군 규격·해양공학 식) 검증을 한 번만 붙여도 모든 자산에 적용됩니다. 파편화 상태에선 불가능했던 일관 검증이, 정본 통합으로 비로소 가능해집니다.

한 줄 정리

📌 같은 대상을 여러 스키마로 적으면 코드·검증·버그가 갈래마다 늘어난다(파편화). 해법은 정본 스키마 하나 + 감사→이행→검증 — 채택률을 측정해 끌어올리고(0%→78%), 정본에 표준 검증을 붙여 일관성을 회복한다. 파편화는 "당장 편해서" 자라니, 정본을 의식적으로 지켜야 한다.