Spotify가 백그라운드 코딩 에이전트 Honk로 데이터셋 1,800개 마이그레이션 자동화

요약

Spotify 한 팀이 가장 많이 쓰이는 사용자 데이터셋 2개를 deprecate해야 했음. 직접 연결된 다운스트림 파이프라인이 약 1,800개. 마이그레이션 마감은 6개월. 프레임워크는 SQL 계열(BigQuery Runner·dbt)과 Scala 계열(Scio) 3종. 사람이 수작업으로 했다면 약 10 엔지니어링 주 분량 노력이 들었을 것으로 자체 추정 .

이 작업을 사내 백그라운드 코딩 에이전트 Honk로 자동화. 대상 리포지토리 식별은 사내 개발자 포털 Backstage가 담당. 자동 PR 일괄 생성·관리는 Backstage 플러그인 Fleetshift가 담당. 결과는 자동 마이그레이션 PR 240건. 표준화가 안 된 Scio는 이번 라운드 범위에서 빠지고, dbt·BigQuery Runner 두 프레임워크에 집중.

내용

deprecate 결정의 배경은 새 버전 데이터셋이 추가 차원(dimension)을 담아야 신규 기능이 열린다는 점. 직접 연결된 파이프라인 외에 간접 영향까지 합치면 회사 전체 수천 개에 닿음.

세 프레임워크의 성격이 같지 않음. BigQuery Runner와 dbt는 SQL 기반이고 회사 전반에서 스타일·구조가 비교적 일정. Scio는 Scala 기반에 프레임워크 자체가 자유도를 많이 주는 탓에 팀마다 작성 방식 편차가 큼.

Honk는 Spotify가 만든 백그라운드 코딩 에이전트로, 사람 개입 없이 코드 변경을 PR로 제출. 기반은 Claude Code. 이 시점의 Honk는 가드레일 목적으로 Claude skills나 사용자 정의 설정 접근이 잠겨 있음. 실행 중에 외부 데이터셋 스키마를 새로 읽거나 외부 문서를 참조할 수 없고, 사람이 미리 써 준 컨텍스트 파일만 활용 가능. 그래서 프롬프트는 처음부터 필요한 정보가 안에 다 들어 있는 상태로 작성해야 함. (외부 컨텍스트 자동 수집 기능은 향후 로드맵에 예정)

Backstage는 endpoint 단위로 다운스트림 소비자 목록을 보여주는 lineage 페이지와 GitHub Enterprise 전체 코드를 검색하는 Codesearch 플러그인을 제공. Fleetshift는 식별한 리포지토리에 마이그레이션 작업을 일괄 적용하고 PR 상태를 모니터링하는 Backstage 플러그인.

접근

대상 리포지토리 식별 — Backstage

코드 변경에 들어가기 전에 어떤 리포지토리를 건드려야 하는지부터 확정해야 함. Backstage의 endpoint lineage 페이지로 deprecate 대상 데이터셋의 다운스트림 소비자 목록을 잡고, Codesearch로 GitHub Enterprise 전반에 흩어진 사용처를 쿼리. 이렇게 모은 리포지토리를 Fleetshift에 마이그레이션 대상으로 등록.

범위 결정 — Scio 제외

Scio는 팀마다 작성 방식 편차가 커서, 모든 변형을 커버하는 단일 프롬프트를 쓰는 일이 비현실적이라고 판단. Honk가 외부 skills·설정에 접근하지 못하는 제약과 겹치자, Scio 마이그레이션은 이번 라운드에서 빼고 dbt·BigQuery Runner 두 프레임워크에만 집중.

컨텍스트 파일 작성 — 필드 매핑 테이블

처음 시도는 사람 엔지니어용 마이그레이션 가이드를 Claude에게 다시 정리시키는 방식. 결과 컨텍스트가 충분히 구체적이지 못해 Honk가 필드 매핑(이전 데이터셋의 어떤 필드가 새 데이터셋의 어떤 필드에 대응되는가)을 추측으로 채우게 됐고, 그 추측이 틀린 경우가 잦음.

수정 방향은 모든 필드 매핑을 표(table) 형식으로 명시. 자동 변환이 위험한 경우(use case별 판단이 필요한 필드)는 변경하지 않고 위에 사람용 마이그레이션 가이드 링크를 주석으로 달도록 지시. 이렇게 컨텍스트를 다듬은 뒤 대다수 대상 리포지토리에서 안정적인 결과가 나오기 시작.

검증 공백 — 다운스트림 팀 수동 테스트

Honk의 강점 중 하나는 자기 변경을 검증하고 결과에 따라 다시 수정하는 피드백 루프. 그런데 dbt·BigQuery Runner 리포지토리는 Scio와 달리 빌드 타임 단위 테스트를 거의 두지 않는 관행이 있어, 자동 검증 루프를 쓸 수 없었음. 그래서 자동 PR을 머지하기 전 데이터셋을 소유한 다운스트림 팀이 직접 수동 테스트를 진행하는 방식으로 검증 단계를 메움.

운영 모니터링 — Fleetshift 대시보드

Fleetshift는 자동 PR들의 상태를 한 화면에서 보여주고, 각 PR로 바로 이동할 수 있게 함. 진행 추적·트러블슈팅·소유 팀 커뮤니케이션이 이 대시보드에서 처리됨.

결과

• 자동 마이그레이션 PR 240건 생성·롤아웃 (Fleetshift 경유).
• 사람이 수작업으로 했다면 약 10 엔지니어링 주 분량의 노력이 들었을 것으로 추정. 자동화로 해당 인력 노력을 절감.
• Scio는 이번 라운드 범위에서 제외. dbt·BigQuery Runner 두 프레임워크에서 대다수 대상 리포지토리가 안정적으로 처리됨.

향후 방향 두 가지가 글에서 짚힘. 첫째, 백그라운드 코딩 에이전트가 더 복잡한 마이그레이션을 다루려면 데이터 환경을 통합·표준화하고 리포지토리 전반에 테스트·검증 요건을 강제해야 함. 둘째, Honk 로드맵에는 에이전트가 코드 변경 전에 JIRA 티켓·문서 등을 스스로 읽어 컨텍스트를 모으는 기능이 예정. 이 기능이 들어가면 사람이 컨텍스트 파일을 통째로 작성해 두는 부담이 줄고 Claude Code 역량을 더 활용할 수 있다고 기대.

참고

• 시리즈 위치: Honk 시리즈 4편. 1편(Spotify의 백그라운드 코딩 에이전트 여정), 2편(Context Engineering), 3편(Feedback Loops) 후속.
• 원문: https://engineering.atspotify.com/2026/4/background-coding-agents-dataset-migrations-honk-part-4/
• 관련 도구: Backstage, Fleetshift, Honk.'