들어가며: 데이터셋 마이그레이션, 왜 이렇게 고통스러운가?
데이터 팀이라면 누구나 공감할 겁니다. 오래된 데이터셋을 새 버전으로 마이그레이션하는 작업은 '해야 하는 건 알지만, 하고 싶지 않은 일'의 대명사죠. 특히 규모가 커질수록 더 그렇습니다. 스포티파이도 예외는 아니었습니다.
작년 말, 스포티파이의 데이터 플랫폼 팀은 새로운 기능을 제공하기 위해 가장 많이 사용되는 두 개의 사용자 데이터셋을 deprecated 처리하고 새 버전을 출시해야 했습니다. 문제는 이 두 데이터셋이 약 1,800개의 직접적인 다운스트림 데이터 파이프라인을 가지고 있었고, 회사 전체에 간접적으로 영향을 미치는 파이프라인까지 합하면 수천 개에 달했다는 점입니다. 게다가 마이그레이션 기한은 단 6개월.
더 큰 문제는 이 파이프라인들이 스포티파이 내에서 사용되는 세 가지 전혀 다른 파이프라인 프레임워크로 작성되어 있었다는 점입니다:
- SQL 기반 BigQuery Runner
- dbt (데이터 빌드 툴)
- Scala 기반 Scio
수동으로 마이그레이션할 경우 약 10 엔지니어링 주(engineering weeks) 의 노력이 필요할 것으로 추산되었습니다. 이에 스포티파이는 자체 개발한 백그라운드 코딩 에이전트 Honk와 내부 개발자 포털 Backstage, 그리고 대규모 코드 변경을 오케스트레이션하는 Fleet Management 도구를 활용해 이 문제를 해결하기로 결정합니다.
이 글은 스포티파이 엔지니어링 블로그에 게재된 "Background Coding Agents: Supercharging Downstream Consumer Dataset Migrations (Honk, Part 4)"의 핵심 내용을 한국 개발자 커뮤니티의 맥락에서 재구성했습니다. (원문: 스포티파이 엔지니어링 블로그)
Backstage로 마이그레이션 대상을 파악하다
코드 변경을 시작하기 전에 가장 먼저 해야 할 일은 deprecated 데이터셋의 계보(lineage)를 파악하는 것이었습니다. 어떤 리포지토리에서 이 데이터셋을 사용하고 있는지 알아야 변경할 대상이 보이니까요.
여기서 Backstage의 엔드포인트 계보 플러그인과 코드 검색(Code Search) 플러그인이 큰 역할을 했습니다. 각 엔드포인트의 Backstage 페이지는 다운스트림 컨슈머 목록을 명확하게 보여주었고, Code Search를 통해 GitHub Enterprise 전체에서 대상 리포지토리를 찾아내어 마이그레이션 범위를 확정할 수 있었습니다.
이 과정은 Fleetshift 플러그인을 통해 오케스트레이션되었습니다. Fleetshift는 대규모 코드 변경을 체계적으로 관리할 수 있게 해주는 도구로, 마이그레이션 진행 상황을 한눈에 볼 수 있는 대시보드 UI를 제공합니다. 덕분에 수백 개의 PR을 일일이 검색하지 않고도 진행률을 모니터링하고 문제가 발생한 PR을 바로 확인할 수 있었습니다.
Honk의 성패를 가른 컨텍스트 엔지니어링
앞서 AI가 만든 고객 여정, 어떻게 평가할까? CDP 메트릭 완벽 가이드에서도 논의했듯이, AI 에이전트의 성능은 얼마나 좋은 컨텍스트를 제공하느냐에 크게 좌우됩니다. Honk 프로젝트에서도 컨텍스트 엔지니어링이 가장 많은 시간과 반복을 필요로 한 부분이었습니다.
Scio 파이프라인의 교훈: 표준화되지 않은 환경은 에이전트 친화적이지 않다
Honk가 직면한 가장 큰 도전은 세 가지 다른 파이프라인 프레임워크를 처리해야 한다는 점이었습니다. BigQuery Runner와 dbt는 회사 전체에서 비교적 일관된 스타일과 구조를 가지고 있었지만, Scio는 팀마다 사용 방식이 천차만별이었습니다.
이런 비표준화된 환경에서는 Honk가 모든 경우를 처리할 수 있는 올인원(all-in-one) 프롬프트를 작성하는 것이 사실상 불가능에 가까웠습니다. 당시 Honk는 Claude Skills나 사용자 정의 설정 기능을 지원하지 않았기 때문에(이는 마이그레이션 결과의 예측 가능성을 높이기 위한 설계 결정이었습니다), 프롬프트에 모든 것을 담아야 했습니다. 하지만 Scio 파이프라인의 유연성 때문에 프롬프트가 너무 방대해지고 관리가 어려워졌습니다.
결국 스포티파이 팀은 Scio 마이그레이션을 포기하고, 표준화된 BigQuery Runner와 dbt에 집중하기로 결정합니다. 이 결정은 매우 실용적이었습니다. 모든 것을 자동화하려다가 아무것도 자동화하지 못하는 것보다, 잘 되는 것부터 자동화하는 게 낫다는 교훈을 줍니다.
dbt와 BigQuery Runner: 표준화의 힘
표준화된 두 프레임워크에서는 컨텍스트 파일을 정교하게 작성하는 데 집중했습니다. 초기에는 사람이 읽는 마이그레이션 가이드를 그대로 프롬프트에 넣는 방식으로 시도했지만, 결과는 좋지 않았습니다. Honk가 데이터셋 필드 간 매핑을 추측하면서 잘못된 가정을 하는 경우가 많았기 때문입니다.
해결책은 매핑 테이블을 명시적으로 컨텍스트 파일에 포함하는 것이었습니다. Honk가 외부 문서를 읽거나 데이터셋 스키마를 직접 조회할 수 없었기 때문에, 컨텍스트 파일 내에 모든 필드 매핑을 표 형태로 명확히 기술했습니다. 또한 특정 필드는 경우에 따라 사람의 판단이 필요하기 때문에 Honk가 변경하지 말고, 대신 해당 필드 위에 사람용 가이드 링크를 주석으로 추가하도록 지시했습니다.
# 예시: Honk에 제공된 컨텍스트 파일의 일부 (의사 코드)
# 마이그레이션 규칙: user_id 필드는 'user_id_v1' -> 'user_id_v2'로 직접 매핑
# 주의: 'custom_tracking' 필드는 팀별로 다른 로직이 필요하므로 변경하지 말 것
# 대신 아래 주석을 추가할 것: "// TODO: 이 필드는 수동 마이그레이션이 필요합니다. 가이드 참조: [링크]"
테스트 부재라는 현실
또 하나의 현실적인 문제는 BigQuery Runner와 dbt 리포지토리 대부분이 단위 테스트(unit test)를 갖추고 있지 않았다는 점입니다. Honk의 핵심 기능 중 하나는 자신이 만든 변경 사항을 검증하고 결과에 따라 조정하는 피드백 루프인데, 테스트가 없으면 이 기능을 사용할 수 없었습니다.
결국 자동 생성된 PR을 병합하기 전에 다운스트림 팀이 수동으로 테스트를 수행해야 했습니다. 이는 자동화의 효용을 다소 떨어뜨렸지만, 그래도 PR 자체를 자동으로 생성하고 검토 프로세스까지 만들어준 것만으로도 큰 시간 절약이 되었습니다.
결과: 240개의 자동화된 PR, 약 10주 분량의 노력 절감
최종적으로 스포티파이 팀은 Fleetshift를 통해 240개의 자동화된 마이그레이션 PR을 성공적으로 배포했습니다. Backstage와 Fleetshift가 제공하는 개요 UI 덕분에 마이그레이션 진행 상황을 실시간으로 모니터링하고, 문제가 있는 PR을 즉시 찾아내어 담당 팀과 소통할 수 있었습니다.
수작업으로 했다면 10주가 걸렸을 작업을 자동화로 해결한 셈입니다. 하지만 이 성공 뒤에는 '잘 되는 것만 자동화한다'는 전략적 판단과 컨텍스트 엔지니어링에 대한 깊은 이해가 있었습니다.
앞으로의 과제와 교훈
이 프로젝트를 통해 스포티파이가 얻은 가장 큰 교훈은 다음과 같습니다:
-
데이터 환경의 표준화가 선행되어야 한다. Honk와 같은 백그라운드 코딩 에이전트가 진정한 효용을 발휘하려면, 데이터 파이프라인과 리포지토리가 일관된 패턴을 따라야 합니다. 표준화되지 않은 환경에서는 프롬프트 작성 자체가 너무 어렵고, 에이전트의 성능도 떨어집니다.
-
테스트와 검증을 강제해야 한다. 에이전트가 스스로 작업을 검증하고 수정할 수 있으려면, 리포지토리에 테스트가 반드시 있어야 합니다. 이는 단순히 Honk를 위한 요구사항이 아니라, 소프트웨어 엔지니어링 모범 사례이기도 합니다.
-
컨텍스트는 명시적이고 구조화되어야 한다. 에이전트가 '추측'하게 두지 말고, 매핑 테이블과 같은 명확한 구조로 컨텍스트를 제공해야 합니다. 특히 에이전트가 외부 정보를 스스로 수집할 수 없는 환경에서는 더욱 그렇습니다.
-
모든 것을 자동화하려고 하지 마라. Scio 파이프라인 사례에서 보듯, 자동화가 어려운 부분은 과감히 포기하고 잘 되는 부분에 집중하는 전략이 오히려 더 나은 결과를 가져옵니다.
한국 개발 생태계에서의 적용 맥락
한국 개발 환경에서도 비슷한 고민을 하고 계신 분들이 많을 겁니다. 특히 대기업 SI나 금융권처럼 레거시 시스템이 많고, 파이프라인이 다양한 툴과 언어로 흩어져 있는 환경에서는 더욱 그렇죠.
- Backstage는 아직 국내 도입 사례가 많지 않지만, 대규모 마이크로서비스 환경을 운영하는 기업이라면 내부 개발자 포털(IDP) 구축을 고려해볼 만합니다. 스포티파이의 사례는 Backstage가 단순한 서비스 카탈로그를 넘어 대규모 코드 변경을 오케스트레이션하는 플랫폼으로 확장될 수 있음을 보여줍니다.
- 데이터 파이프라인 표준화는 말처럼 쉬운 일이 아닙니다. 하지만 이 사례는 표준화가 단순히 '깔끔한 코드'를 위한 것이 아니라, AI 기반 자동화의 전제 조건임을 보여줍니다. 국내 환경에서는 dbt와 같은 현대적인 데이터 변환 툴의 도입을 검토해보는 것도 좋은 출발점이 될 수 있습니다.
- 테스트 문화는 여전히 많은 국내 조직에서 숙제입니다. Honk 사례는 테스트가 단순히 버그를 줄이는 도구를 넘어, 자동화된 코드 변경의 신뢰성을 보장하는 핵심 요소임을 일깨워줍니다.
이 기술의 한계 또는 주의사항
- Honk와 같은 백그라운드 코딩 에이전트는 표준화된 환경에서 가장 잘 동작합니다. 레거시 시스템이나 비표준 코드베이스가 많은 환경에서는 오히려 도입 비용이 더 클 수 있습니다.
- 현재로서는 복잡한 비즈니스 로직이나 도메인 특화 판단이 필요한 변경은 자동화하기 어렵습니다. 사람의 판단이 필요한 부분은 명확히 구분하고, 에이전트가 건드리지 말아야 할 영역을 사전에 정의해야 합니다.
- 에이전트가 생성한 PR은 반드시 사람이 검토해야 합니다. 완전한 무인 자동화는 아직 위험합니다.
다음 단계 학습 방향
- Backstage에 관심이 있다면: Backstage 공식 문서를 시작으로, 플러그인 개발과 커스터마이징을 학습해보세요.
- 백그라운드 코딩 에이전트를 직접 구축해보고 싶다면: Claude API나 OpenAI의 Function Calling을 활용한 간단한 코드 리팩토링 에이전트부터 시작해보는 것을 추천합니다.
- 데이터 파이프라인 표준화에 관심이 있다면: dbt, Airflow, 그리고 데이터 메시(data mesh) 아키텍처에 대해 공부해보세요.
마치며
스포티파이의 Honk 사례는 AI 에이전트가 실제 프로덕션 환경에서 대규모 마이그레이션을 어떻게 성공적으로 수행할 수 있는지 보여주는 훌륭한 참고 자료입니다. 중요한 것은 'AI가 모든 것을 해결해준다'는 환상이 아니라, 표준화된 환경, 명확한 컨텍스트, 그리고 현명한 자동화 범위 설정이 함께 이루어져야 진정한 효용이 발생한다는 점입니다.
앞으로 Honk 팀은 에이전트가 코드 변경을 수행하기 전에 JIRA 티켓이나 문서를 읽어 스스로 컨텍스트를 수집할 수 있는 기능을 개발 중이라고 합니다. 이렇게 되면 사전 컨텍스트 파일 작성 부담이 줄어들고, 더 복잡한 작업에도 에이전트를 적용할 수 있을 것으로 기대됩니다.
여러분의 조직에서는 어떤 마이그레이션 작업이 자동화될 수 있을까요? 표준화와 테스트부터 시작해보는 건 어떨까요? 😊
함께 보면 좋은 글
