Background Coding Agents: 다운스트림 데이터셋 마이그레이션 가속화 (Honk, Part 4)

Spotify는 두 개의 핵심 user dataset을 폐기하고 새 버전으로 옮기기 위해 약 1,800개의 직접 downstream pipeline과 수천 개의 간접 의존성을 6개월 안에 처리해야 했다. 수작업이면 10 engineering weeks가 걸릴 것으로 봤고, 이를 줄이기 위해 Backstage, Fleetshift, Honk를 동원했다.

먼저 Backstage의 endpoint lineage와 Codesearch로 영향받는 저장소를 빠르게 찾아 migration 대상 범위를 확정했다. 이후 Fleetshift로 대규모 shift를 운영하면서 진행 상황을 한 화면에서 확인하고, 자동 생성된 PR로 바로 진입할 수 있게 했다.

가장 어려웠던 부분은 context engineering이었다. Spotify의 데이터 파이프라인은 BigQuery Runner, dbt, Scio 세 가지 프레임워크로 나뉘어 있었고, 그중 Scio는 팀별 편차가 커서 일괄 프롬프트로 다루기 어려웠다. Honk는 당시 Claude skills나 외부 문서를 직접 읽는 커스텀 기능이 없어서, 충분히 포괄적인 context file을 미리 써줘야 했고, Scio는 결국 이번 작업 범위에서 제외했다.

dbt와 BigQuery Runner에서는 인간용 migration guide를 단순 재활용했을 때 필드 매핑 추론이 자주 틀렸다. 이후 매핑을 표 형태로 명시하고, 판단이 필요한 필드는 바꾸지 말고 위에 코멘트와 가이드 링크를 붙이도록 바꾸자 성능이 크게 나아졌다.

다만 이 두 프레임워크는 빌드 시 unit test가 거의 없어 Honk가 결과를 검증하고 스스로 수정하는 피드백 루프를 충분히 돌릴 수 없었다. 그래서 최종 병합 전 검증은 downstream owning team의 수동 테스트에 의존해야 했다.

그럼에도 결과적으로 240개 자동 migration PR를 성공적으로 배포했다. Spotify는 이 경험을 통해 대규모 배치형 에이전트를 잘 쓰려면 데이터 landscape의 표준화와 저장소 전반의 테스트/검증 체계가 필수라고 정리했다. 앞으로는 Honk가 JIRA나 문서를 먼저 읽어 스스로 context를 수집하는 기능도 로드맵에 올라 있다.