# 계약 하나로 파이프라인이 생기는 데이터 플랫폼

## TL;DR

- 데이터 입고 요청을 티켓으로 받아 사람이 파이프라인을 만들어주던 조직을, **Protobuf 스키마 + YAML 계약 파일 하나를 PR로 올리면 파이프라인이 자동 생성되는 플랫폼**으로 바꿨다.
- 계약 하나에서 ETL 파이프라인, Kafka 토픽, 스키마 진화, 권한, retention, compaction, lineage까지 생성·적용된다. 현재 규모는 **데이터 모델 수백 개, 파이프라인 계약 수십 개, 십수 개 서비스 원천 실시간 CDC, DaaS 십여 종** — 같은 전사 AI 워크로드에 공급 중이다.
- 효과는 셀프서비스다. 데이터 입고가 Data Owner의 스키마 제출만으로 완료되고, AI 스킬과 결합해 계약 작성 자체도 자동화했다 — **요청 처리 리드타임 15일 → 3일의 기반**이 됐다.

## 요청 처리형 조직의 한계

데이터 플랫폼 조직의 초기 형태는 대개 비슷하다. "이 데이터를 레이크하우스에 넣어 주세요"라는 요청이 티켓으로 들어오고, 담당자가 원천을 파악하고, 스키마를 정의하고, 파이프라인 코드를 짜고, 권한과 보존 정책을 설정한다. 요청마다 사람의 손이 처음부터 끝까지 들어간다.

이 방식은 요청이 월 몇 건일 때는 문제가 없다. 그러나 사내 AI 수요가 폭발하면서 요청은 늘어나는데, 파이프라인을 만드는 일 자체는 놀랄 만큼 반복적이라는 것이 보였다. 원천이 무엇이든 하는 일은 같았다 — 스키마 정의, 토픽 생성, 적재 잡 배포, 권한 부여, 보존·압축 정책, 계보 등록. 다른 것은 "값"뿐이고 "구조"는 매번 같았다.

반복 요청을 계속 티켓으로 받는 조직은 인원에 비례해서만 성장한다. 우리는 이 반복을 제품으로 만들기로 했다.

## 설계 — 계약(선언)과 구현(생성)의 분리

핵심 아이디어는 파이프라인을 코드가 아니라 **계약(Data Contract)으로 선언**하게 하는 것이다. 데이터를 넣고 싶은 쪽(Data Owner)이 준비하는 것은 두 가지뿐이다.

1. **Protobuf 스키마** — 데이터의 구조. 필드, 타입, 키.
2. **YAML 계약 파일** — 데이터의 운영 속성. 원천, 적재 방식, 보존 기간, 압축 정책, 접근 권한, 변경 불가 여부.

이 두 파일을 저장소에 PR로 올리면, 리뷰·머지 이후는 전부 자동이다. 계약을 읽은 생성 계층이 ETL 파이프라인을 구성하고, Kafka 토픽을 만들고, 테이블을 생성하고, 권한과 retention과 compaction 정책을 적용하고, 데이터 계보(lineage)를 카탈로그에 등록한다. 스키마가 바뀌면 계약의 버전이 올라가고 스키마 진화도 같은 경로로 적용된다.

이 구조의 본질은 **선언과 구현의 분리**다. Data Owner는 "무엇을"만 선언하고, "어떻게"는 플랫폼이 책임진다. 구현이 개선되면 — 적재 엔진을 바꾸든 압축 전략을 바꾸든 — 계약은 그대로인 채 모든 파이프라인이 함께 개선된다. 반대로 계약 스펙이 확장되면 리뷰 포인트는 YAML diff 한 장으로 수렴한다.

부수 효과 중 과소평가할 수 없는 것이 거버넌스다. 보존 기간, 접근 권한, 변경 가능성 같은 정책이 문서가 아니라 **계약 파일 안에, 즉 스키마 옆에** 산다. 정책 문서는 낡지만 계약은 낡을 수 없다 — 그 파일이 곧 실제 파이프라인의 원천이기 때문이다. 감사(audit)가 필요하면 저장소의 계약 파일과 git 히스토리를 보면 된다.

## 규모 — 계약이 감당하고 있는 것

이 구조 위에서 현재 운영 중인 규모는 이렇다.

- **데이터 모델(Protobuf) 수백 개**
- **파이프라인 계약 수십 개**, 별도의 구독(접근 권한) 계약 체계
- **13개 이상 서비스 원천의 실시간 CDC** — 원천 DB의 변경이 실시간으로 레이크하우스에 반영된다
- **DaaS 십여 종** — , 어뷰즈 탐지, 등 전사 AI 워크로드에 데이터 공급

강조하고 싶은 것은 숫자보다 구조다. 모델이 500개를 넘는 동안 파이프라인을 만드는 조직의 손은 거의 늘지 않았다. 요청 건수와 조직 크기의 비례가 끊어진 것 — 그것이 플랫폼화의 정의라고 생각한다.

## 셀프서비스, 그리고 계약 작성의 자동화

플랫폼 전환의 체감 효과는 입고 프로세스에서 가장 크다. 이전에는 "요청 → 협의 → 개발 → 배포"의 전 구간에 우리 조직이 있었다. 지금은 **Data Owner가 스키마를 제출하는 것으로 입고가 완료**된다. 우리는 리뷰어로만 존재한다.

마지막 마찰은 "계약 파일을 어떻게 쓰는지 모르겠다"였는데, 이것도 AI로 풀었다. 계약 작성을 돕는 AI 스킬을 만들어, 원천 스키마(DDL, ES 매핑 등)를 주면 Protobuf와 YAML 계약 초안을 만들고 PR까지 생성하게 했다. 계약이라는 구조화된 타깃이 있었기에 AI 자동화가 정확해질 수 있었다 — 자유 형식의 코드를 생성하는 것보다, 스키마가 정의된 YAML을 생성하는 것이 훨씬 검증 가능하다. 이 조합이 외부 요청 처리 리드타임을 **15일에서 3일로** 줄인 기반이 됐다.

## 교훈

1. **반복 요청은 티켓이 아니라 제품으로 풀어라.** 같은 구조의 요청이 세 번 들어오면, 네 번째부터는 사람이 아니라 시스템이 받아야 한다.
2. **계약(선언)과 구현(생성)을 분리하라.** 선언이 안정되면 구현을 마음껏 갈아탈 수 있고, 사용자와의 인터페이스는 YAML diff 한 장으로 수렴한다.
3. **거버넌스는 문서가 아니라 스키마에 심어라.** 정책이 실행 경로 위에 있으면 낡을 수 없다. 문서 속 정책은 권고지만, 계약 속 정책은 코드다.

플랫폼 조직으로의 전환은 기술 과제인 동시에 정체성의 전환이었다. "요청을 처리하는 팀"에서 "요청이 우리 없이 처리되게 만드는 팀"으로. 전자는 바쁠수록 성과처럼 보이지만, 후자만이 조직보다 빠르게 성장하는 수요를 감당할 수 있다.