데이터 계약서를 쓰기 시작했습니다

데이터가 조각나 있으면 모든 표면이 싸구려가 됩니다. 제품 페이지와 상담 정책이 서로 다른 말을 하고, 재고 표현이 애매해지고, 개인화가 우연처럼 느껴지고, AI 어시스턴트는 재료가 부실하니 환각을 일으킵니다. 사이트가 아무리 번쩍여도 서비스가 얇게 느껴지는 원인을 따라가보면 대부분 여기였습니다.

파이프라인

파이프라인도 인터페이스처럼 설계합니다. 순서, 실패, 복구, 그리고 다음 액션의 담당자까지요. 모든 게 완벽할 때만 도는 파이프라인은 프로덕션 인프라가 아니라 운이 좋은 프로토타입입니다.

schema validation
  -> lineage check
  -> freshness threshold
  -> privacy policy
  -> release channel
  -> monitoring ledger

단계마다 지키려는 게 있습니다. 신선도는 재고 표현을 지키고, 계보는 책임 소재를 지키고, 프라이버시 정책은 신뢰를 지키고, 릴리스 채널은 조용한 변경이 공개 사고가 되는 걸 막습니다.

데이터 계약

데이터 계약은 데이터를 만드는 쪽과 쓰는 쪽 사이의 약속입니다. 이 필드는 존재할 거고, 이런 뜻이고, 이 시간 안에 도착할 거고, 바뀌면 대시보드가 깨지기 전에 당신이 먼저 듣게 될 거라는 약속. 대부분의 조직은 암묵적 계약으로 굴러가는데, 그건 사실 운으로 굴러간다는 말과 같습니다.

저희는 중요한 이음새에만 계약을 명시합니다. 제품 데이터가 커머스로 가는 길, 고객 신호가 개인화로 가는 길, 운영 상태가 AI 어시스턴트로 가는 길. 문서는 짧습니다. 이 문서가 없을 때 치르는 비용이 길 뿐입니다.

producer:   inventory service (owner: ops platform)
schema:     sku, state[in_stock|low|out|preorder], updated_at
freshness:  < 5 min during commerce hours
change:     versioned, 2-week deprecation window
consumers:  product pages, assistant, care team console

데이터에도 애프터케어

데이터는 재료처럼 늙습니다. 제품 사진은 시즌이 지나고, 정책 문구는 대체되고, 임베딩은 옮겨간 카탈로그에 대해 낡아가고, 어제의 정답이 오늘의 오정보가 됩니다. 옷의 애프터케어를 진지하게 여긴다면 데이터셋에도 같은 감각이 필요했습니다.

저희 방식은 화려하지 않습니다. 정해진 주기의 신선도 리뷰, 패닉 삭제 대신 절차 있는 폐기, 그리고 고객 대면 표면에 들어가는 데이터셋에는 반드시 이름 붙은 주인과 은퇴 계획을 두는 규칙. 아무도 그 데이터셋의 미래를 책임지지 않는 순간, 이미 망가지기 시작한 겁니다.