🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Spotify는 백그라운드 코딩 에이전트 Honk와 Backstage, Fleet Management를 활용해 대규모 데이터셋 소비자 마이그레이션의 반복 작업을 자동화했고, 그 과정에서 표준화된 데이터 환경과 테스트 체계가 에이전트 기반 유지보수의 핵심 조건임을 확인했다.

📌 핵심 요약

• Spotify는 오래된 주요 사용자 데이터셋 두 개를 폐기하고 새 버전으로 전환해야 했으며, 이 데이터셋들은 약 1,800개의 직접 다운스트림 데이터 파이프라인과 더 많은 간접 의존 파이프라인에 영향을 주고 있었다.
• 수작업으로 진행하면 약 10 엔지니어링 주가 필요할 것으로 예상되어, 팀은 Backstage의 엔드포인트 lineage와 Codesearch, Fleetshift, 내부 백그라운드 코딩 에이전트 Honk를 조합해 자동화 가능성을 탐색했다.
• Honk의 성능은 충분하고 정확한 컨텍스트에 크게 의존했으며, 특히 프레임워크별 표준화 수준이 자동 마이그레이션 성공 여부를 갈랐다. Scio는 팀별 구현 편차가 커 제외했고, 상대적으로 표준화된 dbt와 BigQuery Runner에 집중했다.
• 초기에는 사람용 마이그레이션 가이드를 에이전트용 컨텍스트로 바꾸려 했지만 충분하지 않았고, 필드 매핑을 표 형태로 명확히 제공한 뒤에야 대부분의 대상 저장소에서 안정적인 결과가 나오기 시작했다.
• 최종적으로 Spotify는 Fleetshift를 통해 240개의 자동 마이그레이션 PR을 배포했으며, 향후에는 데이터 환경 표준화, 저장소별 테스트·검증 요건 강화, 에이전트가 스스로 문서와 티켓을 읽어 컨텍스트를 수집하는 기능이 더 복잡한 마이그레이션의 기반이 될 것이라고 보았다.

🧩 주요 포인트

1. Spotify는 오래된 주요 사용자 데이터셋 두 개를 폐기하고 새 버전으로 전환해야 했으며, 이 데이터셋들은 약 1,800개의 직접 다운스트림 데이터 파이프라인과 더 많은 간접 의존 파이프라인에 영향을 주고 있었다.
2. 수작업으로 진행하면 약 10 엔지니어링 주가 필요할 것으로 예상되어, 팀은 Backstage의 엔드포인트 lineage와 Codesearch, Fleetshift, 내부 백그라운드 코딩 에이전트 Honk를 조합해 자동화 가능성을 탐색했다.
3. Honk의 성능은 충분하고 정확한 컨텍스트에 크게 의존했으며, 특히 프레임워크별 표준화 수준이 자동 마이그레이션 성공 여부를 갈랐다. Scio는 팀별 구현 편차가 커 제외했고, 상대적으로 표준화된 dbt와 BigQuery Runner에 집중했다.
4. 초기에는 사람용 마이그레이션 가이드를 에이전트용 컨텍스트로 바꾸려 했지만 충분하지 않았고, 필드 매핑을 표 형태로 명확히 제공한 뒤에야 대부분의 대상 저장소에서 안정적인 결과가 나오기 시작했다.
5. 최종적으로 Spotify는 Fleetshift를 통해 240개의 자동 마이그레이션 PR을 배포했으며, 향후에는 데이터 환경 표준화, 저장소별 테스트·검증 요건 강화, 에이전트가 스스로 문서와 티켓을 읽어 컨텍스트를 수집하는 기능이 더 복잡한 마이그레이션의 기반이 될 것이라고 보았다.

🧠 상세 정리

1. 대규모 데이터셋 마이그레이션이라는 문제

이 글은 Spotify가 내부 코드명 Honk로 부르는 백그라운드 코딩 에이전트를 대규모 소프트웨어 유지보수에 활용한 여정을 다룬 시리즈의 네 번째 글이다. 사례의 출발점은 새 기능을 가능하게 하는 추가 차원을 포함한 새 데이터셋 버전을 출시하기 위해, 기존의 매우 많이 쓰이던 사용자 데이터셋 두 개를 폐기해야 했다는 점이다. 두 데이터셋은 직접적으로 약 1,800개의 다운스트림 데이터 파이프라인을 갖고 있었고, 회사 전체로는 수천 개의 파이프라인에 간접 영향을 미쳤다. Spotify는 이를 6개월 안에, BigQuery Runner, dbt, Scio라는 서로 다른 세 가지 파이프라인 프레임워크에 걸쳐 처리해야 했다. 수작업으로는 약 10 엔지니어링 주가 필요할 것으로 예상되었기 때문에, 팀은 Backstage, Fleet Management, Honk를 이용해 반복적인 변경 부담을 줄일 방법을 찾았다.

2. Backstage로 대상 저장소와 의존 관계 파악

코드 변경을 시작하기 전 Spotify가 먼저 해결해야 한 문제는 폐기 대상 데이터셋의 lineage를 이해하고, 실제로 어떤 저장소를 수정해야 하는지 식별하는 일이었다. 이를 위해 Backstage의 엔드포인트 lineage 기능과 Codesearch 플러그인이 사용되었다. 각 데이터 엔드포인트의 Backstage 페이지는 다운스트림 소비자 목록을 명확히 보여주었고, 팀은 이를 통해 마이그레이션의 규모를 빠르게 파악할 수 있었다. 이어 Codesearch 쿼리를 작성해 Spotify의 GitHub Enterprise 전반에서 대상 저장소를 찾고, 이들을 마이그레이션 범위에 포함시켰다. 이렇게 식별된 작업은 Backstage의 Fleetshift 플러그인을 통해 오케스트레이션되었으며, 저장소 몇 개뿐 아니라 수천 개 수준의 변경도 같은 방식으로 관리할 수 있는 흐름을 만들었다.

3. Honk에서 컨텍스트 엔지니어링이 핵심이 된 이유

Honk를 이용한 마이그레이션에서 가장 많은 시간과 반복이 들어간 부분은 대상 저장소를 찾는 일이 아니라, 에이전트가 올바르게 작업할 수 있도록 컨텍스트를 설계하는 일이었다. Spotify는 이전 글에서도 백그라운드 코딩 에이전트와 함께 일할 때 컨텍스트 엔지니어링이 중요하다고 설명했는데, 이번 사례는 그 중요성을 다시 보여준다. Honk는 당시 실행 중 Claude skills나 사용자 정의 설정에 접근할 수 없었고, 외부 문서나 데이터셋 스키마를 스스로 찾아 읽는 방식도 사용할 수 없었다. 이는 마이그레이션 결과의 범위를 통제하기 위한 설계 선택이었지만, 동시에 프롬프트와 컨텍스트 파일이 매우 포괄적이어야 한다는 의미이기도 했다. 에이전트가 알 수 있는 것은 거의 전적으로 사람이 미리 제공한 컨텍스트에 제한되었기 때문에, 누락되거나 모호한 지시는 곧 잘못된 추론으로 이어질 수 있었다.

4. 프레임워크 표준화 수준이 자동화 가능성을 갈랐다

이번 마이그레이션의 큰 난점은 Honk가 서로 다른 세 가지 데이터 파이프라인 프레임워크를 다루어야 했다는 점이었다. BigQuery Runner와 dbt는 회사 전체에서 스타일과 구조가 비교적 일관적이었지만, Scala 기반 Scio는 프레임워크의 유연성 때문에 팀마다 구현 방식의 차이가 컸다. 이처럼 표준화되지 않은 데이터 환경에서는 Honk가 마주칠 수 있는 모든 경우의 수를 하나의 프롬프트로 충분히 설명하기 어려웠다. 특히 Scio 파이프라인을 위한 완전한 프롬프트를 작성하려 하자 내용이 지나치게 복잡해졌고, 당시 Honk가 외부 기술이나 추가 컨텍스트 수집 기능을 활용할 수 없었던 제약과 맞물려 실용성이 낮아졌다. 결국 팀은 그 시점에서 Scio 마이그레이션을 계속 추진하지 않고, 더 표준화된 dbt와 BigQuery Runner에 집중하기로 결정했다.

5. 사람용 가이드를 에이전트용 컨텍스트로 바꾸며 얻은 교훈

dbt와 BigQuery Runner에서는 처음에 사람 엔지니어를 위해 작성된 마이그레이션 가이드를 Claude에게 재가공시켜 Honk용 컨텍스트 파일을 만들려 했다. 그러나 초기 결과는 충분히 포괄적이지 않았고, Honk는 한 데이터셋 필드를 다른 필드로 어떻게 매핑해야 하는지에 대해 스스로 가정해야 했다. 그 가정은 자주 틀렸기 때문에, 팀은 컨텍스트 파일 안에 표를 사용해 모든 매핑을 명확하게 정리하는 방식으로 수정했다. 이렇게 Honk가 접근할 수 있는 정보가 제한적이라는 사실을 전제로 세밀한 지시를 제공하자, 대부분의 대상 저장소에서 안정적인 성능이 나타나기 시작했다. 또한 사용 사례별 판단이 필요한 필드 마이그레이션의 경우에는 Honk가 억지로 변경하지 않도록 하고, 대신 해당 필드 위에 사람 엔지니어용 마이그레이션 가이드 링크가 포함된 주석을 남기게 했다.

6. 테스트 부족, 240개 자동 PR, 그리고 향후 방향

이번 작업에서 남은 한계는 BigQuery Runner와 dbt 저장소들이 회사 전반에서 빌드 타임 단위 테스트를 거의 사용하지 않았다는 점이었다. Honk의 중요한 장점 중 하나는 자신의 작업을 검증하고 결과에 따라 수정할 수 있다는 것이지만, 테스트가 없으면 이 기능을 충분히 활용할 수 없었다. 따라서 자동 생성된 PR은 병합 전 다운스트림 소유 팀이 직접 수동 테스트를 수행해야 했다. 그럼에도 Spotify는 Fleetshift를 통해 240개의 자동 마이그레이션 PR을 성공적으로 배포했다. Backstage와 Fleetshift는 진행 상황을 한눈에 보여주는 UI와 자동 PR로 바로 이동할 수 있는 기능을 제공해 문제 해결, 진행 모니터링, 소유 팀과의 커뮤니케이션을 크게 단순화했다. Spotify는 향후 이런 대규모 복합 마이그레이션의 성공이 데이터 환경의 통합과 표준화, 저장소 전반의 테스트·검증 요건 강화, 그리고 에이전트가 JIRA 티켓이나 문서를 읽어 스스로 컨텍스트를 수집하는 기능에 달려 있다고 정리했다.

🧾 핵심 주장 / 시사점

• 에이전트 기반 코드 변경의 병목은 모델 자체보다도, 대상 시스템이 얼마나 표준화되어 있고 필요한 컨텍스트가 얼마나 명시적으로 제공되는지에 있을 수 있다.
• 대규모 자동 마이그레이션에서는 lineage, 코드 검색, PR 오케스트레이션, 진행 현황 UI가 함께 작동해야 하며, 단순히 코드를 생성하는 에이전트만으로는 운영 부담을 충분히 줄이기 어렵다.
• 자동화된 PR 생성이 실질적인 생산성 향상으로 이어지려면 저장소마다 테스트와 검증 체계가 마련되어 있어야 하며, 그렇지 않으면 마지막 품질 보증은 여전히 사람 팀의 수동 확인에 의존하게 된다.

✅ 액션 아이템

• Spotify의 Honk 데이터셋 migration 사례에서 background coding agents가 맡은 작업 범위와 사람이 승인한 경계를 분리한다.
• Backstage, Codesearch, Fleetshift, 표준화된 data platform이 coding agent에 제공한 context layer를 정리한다.
• migration PR 생성, test gate, data lineage 검증이 어떻게 downstream consumer dataset 전환의 위험을 낮췄는지 확인한다.
• 조직 내부 platform engineering 팀이 coding agent를 도입할 때 필요한 repository metadata, ownership, rollback 기준을 목록화한다.
• Spotify 사례를 우리 배치/자동화 운영에 적용한다면 어떤 작업을 background agent에 맡기고 어떤 작업은 human review로 남길지 구분한다.

❓ 열린 질문

• background coding agents가 대량 migration PR을 만들 때 test coverage가 부족한 repository에서는 어떤 보완 gate가 필요할까?
• Codesearch와 Backstage 같은 내부 개발자 플랫폼 없이도 Spotify식 context-rich agent workflow를 재현할 수 있을까?
• Fleetshift가 제공한 표준화된 migration path와 사람이 직접 고치는 예외 처리는 어떤 기준으로 나뉘었을까?
• coding agent가 생성한 PR의 품질은 merge rate, rollback rate, review time 중 어떤 지표로 가장 잘 평가할 수 있을까?
• downstream consumer dataset migration 경험은 API migration, infra config migration, data contract migration에도 그대로 확장될 수 있을까?