들어가며: 데이터 마이그레이션, 왜 이렇게 고통스러운가?
데이터 팀이라면 누구나 공감할 거예요. 오래된 데이터셋을 deprecated 하고 새로운 버전으로 전환하는 작업은 마치 '진흙탕에서 수영하기'와 같습니다. 데이터 소유자는 물론, 그 데이터를 매일 사용하는 다운스트림 팀들 모두에게 스트레스입니다.
스포티파이도 예외는 아니었어요. 작년 말, 새로운 기능을 위해 두 개의 가장 많이 사용되는 유저 데이터셋을 deprecated 해야 했습니다. 그런데 이 데이터셋에는 약 1,800개의 직접적인 다운스트림 데이터 파이프라인이 연결되어 있었고, 간접적으로는 회사 전체 수천 개에 영향을 미쳤습니다. 게다가 스포티파이 내에서 사용되는 세 가지 완전히 다른 파이프라인 프레임워크(SQL 기반 BigQuery Runner, dbt, Scala 기반 Scio)를 모두 지원해야 했죠.
수동으로 처리했다면 약 10 엔지니어링 주(engineering weeks) 가 필요하다는 추정이 나왔습니다. 이 난관을 어떻게 돌파했을까요? 바로 백그라운드 코딩 에이전트 Honk와 Backstage, Fleet Management 플랫폼의 조합이 해답이었습니다.
이 글은 스포티파이 엔지니어링 블로그 'Background Coding Agents: Supercharging Downstream Consumer Dataset Migrations (Honk, Part 4)'를 기반으로, 국내 개발자분들이 실제 업무에 적용할 수 있는 인사이트를 중심으로 재구성했습니다.
참고 자료: 스포티파이 엔지니어링 블로그 원문 보기
본론 1: Backstage로 데이터 계보(Lineage)를 파악하고 타겟 레포지토리를 발굴하다
코드 변경을 시작하기 전에 가장 먼저 해야 할 일은 어디를 수정해야 하는지 파악하는 것이었습니다. 스포티파이는 Backstage의 엔드포인트 계보(Lineage) 플러그인과 Codesearch를 활용했습니다.
- Backstage 엔드포인트 페이지: 각 엔드포인트의 페이지에서 다운스트림 컨슈머 목록을 한눈에 확인할 수 있었습니다. 마이그레이션 규모를 즉시 파악할 수 있었죠.
- Codesearch 쿼리: 스포티파이 GitHub Enterprise 전역에서 타겟 레포지토리를 찾는 쿼리를 작성했습니다.
- Fleetshift 플러그인: 발견된 레포지토리를 마이그레이션 범위로 마킹하고, 전체 오케스트레이션을 담당했습니다.
이 과정을 통해 240개의 자동화된 PR(Pull Request) 을 생성할 수 있었습니다. Backstage와 Fleetshift의 대시보드 UI는 마이그레이션 진행 상황을 스냅샷처럼 보여주고, 각 PR을 쉽게 클릭해 확인할 수 있게 해주어 문제 해결과 진행 모니터링, 소유 팀과의 커뮤니케이션에 큰 도움이 되었습니다.
본론 2: Honk에게 '맥락(Context)'을 가르치는 기술
앞서 CSS Grid로 지그재그(폭포수) 레이아웃 만들기 translateY(%)의 숨은 마법에서도 강조했듯이, 도구를 제대로 활용하려면 그 도구가 이해할 수 있는 언어로 말해야 합니다. Honk에게는 바로 '컨텍스트 엔지니어링'이 그 핵심이었습니다.
2.1 세 가지 프레임워크, 세 가지 접근법
| 프레임워크 | 표준화 정도 | Honk 적용 결과 | 핵심 교훈 ||---|---|---|---|| dbt | 높음 (일관된 스타일) | ✅ 성공 | 표준화된 환경에서는 프롬프트가 단순해도 잘 동작 || BigQuery Runner | 높음 (일관된 스타일) | ✅ 성공 | 마이그레이션 가이드를 그대로 프롬프트에 넣지 말고, 명확한 매핑 테이블 제공 || Scio (Scala) | 낮음 (팀마다 자유도 높음) | ❌ 중단 | 너무 다양한 패턴을 모두 커버하는 프롬프트는 비현실적. 추가 컨텍스트 수집 기능 필요 |
2.2 프롬프트 작성의 함정과 해결책
처음에는 사람이 읽는 마이그레이션 가이드를 그대로 Claude에게 프롬프트로 제공했습니다. 하지만 결과는 처참했어요. Honk가 필드 매핑을 추측하다가 엉뚱한 방향으로 가는 경우가 많았습니다.
해결책: 모든 필드 매핑을 테이블 형태로 명시적으로 제공했습니다. Honk는 오직 우리가 준 컨텍스트만 볼 수 있었기 때문에, 모호함을 완전히 제거해야 했습니다.
# 예시: Honk가 이해할 수 있는 매핑 테이블 (의사 코드)
mapping_table = {
"old_dataset.user_id": "new_dataset.user_identifier",
"old_dataset.play_count": "new_dataset.total_plays",
"old_dataset.last_active": None # 마이그레이션 제외, 주석 추가 요청
}
또한 마이그레이션을 하지 말아야 할 필드도 명시했습니다. 예를 들어, 특정 사용 사례에 따라 사람의 판단이 필요한 경우에는 Honk가 필드를 그대로 두고, 대신 해당 필드 위에 사람 엔지니어용 가이드 링크를 주석으로 남기도록 했습니다.
2.3 테스트 부재라는 벽
Scio 파이프라인은 대부분 유닛 테스트가 있었지만, BigQuery Runner와 dbt 레포지토리는 빌드 타임 유닛 테스트가 거의 없었습니다. 이는 Honk의 핵심 기능 중 하나인 '자체 검증 후 결과에 따라 조정'을 사용할 수 없다는 뜻이었습니다. 결국 다운스트림 소유 팀이 PR을 머지하기 전에 수동 테스트를 해야 했습니다.
본론 3: 국내 개발 생태계에서의 적용 맥락
스포티파이의 사례는 단순히 해외 빅테크의 이야기가 아닙니다. 국내 환경에서도 충분히 적용 가능한 인사이트가 있습니다.
3.1 SI/금융권 레거시 시스템 마이그레이션
국내 SI 프로젝트나 금융권에서는 수백, 수천 개의 배치 Job과 데이터 파이프라인이 운영됩니다. 이번 사례에서 배울 점은:
- 표준화가 선행되어야 AI 자동화가 가능하다: 스포티파이도 Scio는 표준화 부족으로 자동화를 포기했습니다. 국내 환경에서는 먼저 파이프라인 템플릿 표준화부터 진행하는 것이 우선입니다.
- Backstage 같은 내부 개발자 포털(Internal Developer Portal) 도입 검토: 데이터 계보를 한눈에 파악할 수 있는 도구가 없다면 AI 에이전트도 어디를 고쳐야 할지 알 수 없습니다.
3.2 이 기술의 한계 또는 주의사항
- 컨텍스트 엔지니어링 비용: Honk에게 완벽한 컨텍스트를 제공하는 데 상당한 시간이 소요됩니다. 작은 프로젝트에서는 오히려 수동 작업이 더 빠를 수 있습니다.
- 테스트 인프라 필수: AI가 생성한 코드를 검증할 자동화된 테스트가 없다면, 결국 사람이 다시 검토해야 합니다. '반자동' 상태에 머물 가능성이 큽니다.
- 프레임워크 다양성: 표준화되지 않은 환경에서는 적용이 어렵습니다. 모든 것을 AI가 해결해주지는 않습니다.
결론: AI 코딩 에이전트의 미래와 다음 단계
스포티파이의 Honk 사례는 AI 코딩 에이전트가 단순한 코드 생성기를 넘어, 대규모 시스템 마이그레이션을 현실적으로 자동화할 수 있음을 보여줍니다. 하지만 성공의 열쇠는 AI 자체의 성능보다 조직의 데이터 표준화, 테스트 문화, 그리고 컨텍스트 엔지니어링에 달려 있습니다.
앞으로 Honk 팀은 JIRA 티켓이나 문서를 읽어 스스로 컨텍스트를 수집하는 기능을 개발 중이라고 합니다. 이렇게 되면 사람이 일일이 컨텍스트 파일을 작성해야 하는 부담이 줄어들고, 더 복잡한 작업에도 AI를 적용할 수 있을 것입니다.
함께 보면 좋은 글
다음 단계 학습 방향
- 내부 개발자 포털(Backstage, Port, Cortex 등) 도입 검토 - 데이터 계보와 서비스 카탈로그가 AI 자동화의 기초입니다.
- 파이프라인 표준화 템플릿 작성 - dbt나 BigQuery Runner처럼 일관된 패턴을 강제하세요.
- 작은 단위부터 시작 - 가장 표준화된 파이프라인 10개만 먼저 자동화해보고, 점진적으로 확대하세요.
- AI 에이전트용 테스트 파이프라인 구축 - AI가 생성한 코드를 자동으로 검증할 CI/CD 파이프라인을 함께 만드세요.
# Honk 컨텍스트 파일 예시 (의사 코드)
# 목적: old_user_stats_v1 → new_user_stats_v2 마이그레이션
MIGRATION_RULES = {
"field_mappings": [
{"from": "user_id", "to": "user_identifier", "transform": None},
{"from": "total_listens", "to": "total_plays", "transform": "lambda x: int(x)"},
{"from": "last_login", "to": "last_active_timestamp", "transform": "parse_date"},
{"from": "premium_status", "to": None, "action": "keep_unchanged",
"comment": "사용자별 판단 필요. 사람 엔지니어 가이드: docs/internal/premium-migration.md"}
],
"excluded_fields": ["internal_session_id"],
"testing_required": True,
"pr_template": {
"title": "[AUTO] Migrate {repo_name} from old_user_stats_v1 to new_user_stats_v2",
"labels": ["honk-auto", "dataset-migration"]
}
}
표로 보는 Honk 마이그레이션 성과
| 항목 | 수치 | 비고 |
|---|---|---|
| 대상 다운스트림 파이프라인 | ~1,800개 | 직접적 영향 |
| 자동 생성 PR | 240개 | Fleetshift 통해 배포 |
| 절감된 엔지니어링 시간 | 약 10주 | 수동 대비 |
| 지원 프레임워크 | 3개 (dbt, BigQuery Runner, Scio) | Scio는 중간에 포기 |
| 주요 성공 요인 | Backstage 계보 + 표준화된 프레임워크 + 명시적 매핑 테이블 | |
| 주요 실패 요인 | 표준화 부족(Scio) + 유닛 테스트 부재 |
국내 SI 환경에서의 특별 주의사항 😅
국내 SI 프로젝트에서는 다음과 같은 점을 특히 염두에 두세요:
- 레거시 시스템의 문서화 부족: Backstage 같은 도구 없이 데이터 계보를 파악하는 것부터가 큰 공정입니다. AI 도입 전에 데이터 카탈로그 구축을 먼저 고려하세요.
- 다양한 프레임워크 혼재: 한 프로젝트 안에서도 Informatica, Talend, Spark, Python 스크립트가 섞여 있는 경우가 많습니다. 스포티파이처럼 표준화된 프레임워크부터 시작하는 전략이 필요합니다.
- 테스트 문화: 많은 SI 프로젝트가 데이터 파이프라인에 대한 유닛 테스트를 갖추지 못했습니다. AI 자동화의 효과를 극대화하려면 파이프라인 테스트 자동화가 선행되어야 합니다.
마치며: AI 에이전트 시대의 데이터 엔지니어링
스포티파이의 Honk 사례는 분명 고무적입니다. 하지만 'AI가 모든 것을 대체한다'는 과장된 기대는 경계해야 합니다. 실제로는 표준화, 테스트 인프라, 컨텍스트 엔지니어링이라는 엄청난 준비 작업이 필요했습니다.
그럼에도 불구하고, 한 번 인프라가 갖춰지면 AI 에이전트는 사람이 하기 싫어하는 반복적이고 방대한 마이그레이션 작업을 놀라운 속도로 처리할 수 있습니다. 특히 Holotron-12B와 같은 최신 AI 모델이 등장하면서 추론 효율이 2배 향상된 점을 고려하면, 앞으로 이런 자동화 사례는 더욱 늘어날 것입니다.
다음 단계로 추천하는 액션 아이템:
- 지금 당장 팀에서 사용 중인 데이터 파이프라인의 표준화 현황을 점검하세요.
- 가장 표준화된 파이프라인 하나를 골라, AI 에이전트로 마이그레이션하는 PoC를 진행해보세요.
- 실패해도 괜찮습니다. 스포티파이도 Scio에서 실패했으니까요. 그 경험에서 배우는 것이 더 중요합니다.
"AI는 엔지니어를 대체하는 것이 아니라, 엔지니어가 더 가치 있는 일에 집중할 수 있게 해주는 도구다." - 스포티파이 Honk 팀의 교훈