코딩이 더 이상 병목이 아니다: 스포티파이의 AI 전환 이야기

스포티파이의 최고 아키텍트 Niklas Gustavsson은 최근 'Code with Claude 2026' 컨퍼런스에서 충격적인 데이터를 공개했습니다. 99% 이상의 엔지니어가 매주 AI 코딩 도구를 사용하고, 94%가 생산성 향상을 체감하며, PR 빈도가 76% 증가했다는 것입니다. 이는 단순한 도구 도입을 넘어, 개발자 경험(Developer Experience)의 패러다임 자체가 바뀌고 있음을 시사합니다.

하지만 더 흥미로운 점은 그다음입니다. 코딩 속도가 빨라지자, 병목이 '코딩'에서 '인간의 의사결정'과 '코드 리뷰'로 이동했다는 사실입니다. 스포티파이는 이 문제를 해결하기 위해 어떤 시스템을 구축했을까요? 해당 원문을 바탕으로 그들의 전략을 깊이 파헤쳐 봅니다.

AI coding agent Honk running on Kubernetes pods at Spotify for automated code migration Developer Related Image

Fleet Management: AI 에이전트의 토대가 된 자동화

스포티파이는 AI 에이전트가 유행하기 훨씬 전부터 'Fleet Management'라는 시스템을 운영해 왔습니다. 생산 코드베이스가 엔지니어 수보다 7배 빠르게 성장하자, 유지보수(의존성 업그레이드, API 마이그레이션, 취약점 패치)에 드는 시간이 기하급수적으로 늘어났기 때문입니다.

이들은 수백 개 팀이 수동으로 컴포넌트를 업데이트하는 대신, 전체 소프트웨어 컴포넌트(Fleet)를 한 번에 변경하는 접근법을 택했습니다. 그 결과물이 'Fleetshift'라는 오케스트레이션 시스템입니다. 현재까지 250만 개 이상의 자동 유지보수 PR이 머지되었으며, 대부분 사람의 개입 없이 자동 머지되었습니다.

# Fleetshift의 개념적 동작 방식 (실제 코드는 내부 구현)
# 목표: 모든 Java 서비스의 로깅 라이브러리를 Log4j 2.x에서 Logback으로 마이그레이션

def migrate_logging_fleet(fleet_components):
    """
    전체 Fleet을 대상으로 로깅 라이브러리 마이그레이션을 실행합니다.
    각 컴포넌트별로 마이그레이션 PR을 생성하고, CI 통과 시 자동 머지합니다.
    """
    for component in fleet_components:
        pr = create_migration_pr(
            component=component,
            change_type="dependency_update",
            # 변경 전: log4j-to-slf4j, 변경 후: logback-classic
            old_dependency="org.apache.logging.log4j:log4j-to-slf4j:2.20.0",
            new_dependency="ch.qos.logback:logback-classic:1.4.14",
            # 추가로 pom.xml의 모든 log4j 참조를 제거하는 스크립트 실행
            migration_script="replace_log4j_with_logback.sh"
        )
        
        # CI가 통과하면 자동 머지, 실패하면 담당자에게 Slack 알림
        if run_ci_and_wait(pr):
            auto_merge(pr)
        else:
            notify_team(component.owner, pr)

이 시스템의 핵심은 **'결정론적 스크립트(Deterministic Script)'**였습니다. 단순하고 반복적인 변경에는 매우 효과적이었지만, 복잡한 코드 리팩토링(API 호출 패턴 변경 등)에는 한계가 있었습니다. 모든 엣지 케이스를 스크립트로 처리하려면 코드가 너무 복잡해졌기 때문입니다.

Developer reviewing AI-generated pull requests on a laptop with Spotify Backstage dashboard Software Concept Art

Honk: 백그라운드에서 일하는 깃털 달린 코딩 친구

LLM의 성숙도가 높아지면서 스포티파이는 결정론적 스크립트의 한계를 극복할 방법을 찾았습니다. 그 결과가 Honk입니다. 이름은 우스꽝스럽지만, 이 '백그라운드 코딩 에이전트'는 현재 스포티파이 운영의 핵심입니다.

Honk의 아키텍처

  • Claude + Agent SDK를 기반으로 구축
  • Kubernetes Pod에서 실행되어 대규모 동시 세션 스케줄링 지원
  • Fleetshift와 통합되어 타겟 식별, 일정 관리, 진행 상황 추적을 사람이 관리
  • CI 환경에서 빌드 검증을 통해 변경의 정확성 확인
  • Slack에서 @Honk 멘션으로 대화 중에도 PR 생성 가능
# Honk가 Slack에서 PR을 생성하는 개념적 흐름
# 실제 구현은 더 복잡하지만, 핵심 아이디어를 보여줍니다.

import json
from slack_sdk import WebClient

class HonkAgent:
    def __init__(self, claude_client, fleet_manager):
        self.claude = claude_client
        self.fleet = fleet_manager
        self.slack = WebClient(token="xoxb-honk-token")
    
    def handle_slack_mention(self, event):
        """
        Slack에서 Honk를 멘션하면 실행됩니다.
        예: "@Honk payment-service의 log4j를 logback으로 바꿔줘"
        """
        message = event["text"]
        channel = event["channel"]
        
        # 1. 자연어 명령을 구조화된 태스크로 변환 (Claude 사용)
        task = self.claude.parse_task(f"""
        다음 요청을 분석하여 마이그레이션 태스크로 변환해줘:
        요청: {message}
        
        응답 형식 (JSON):
        {{
            "target_component": "컴포넌트 이름",
            "action": "dependency_update | refactor | api_migration",
            "parameters": {{}}
        }}
        """)
        
        task_json = json.loads(task)
        
        # 2. Fleetshift에 태스크 등록
        session_id = self.fleet.create_session(
            component=task_json["target_component"],
            action=task_json["action"],
            parameters=task_json["parameters"]
        )
        
        # 3. Honk가 실제 코드 변경 수행 (비동기)
        self.fleet.execute_session_async(session_id, agent=self)
        
        # 4. 사용자에게 진행 상황 알림
        self.slack.chat_postMessage(
            channel=channel,
            text=f"🪶 @{event['user']} 요청하신 작업을 시작했어요! (세션 ID: {session_id})\n"
                 f"진행 상황은 여기서 확인: <https://fleet.spotify.com/sessions/{session_id}>"
        )

최근 사례: 백엔드 서비스의 Java 마이그레이션을 3일 만에 완료했습니다. 과거에는 수백 개 팀이 각자의 컴포넌트를 마이그레이션하는 데 몇 주에서 몇 달이 걸리던 작업이었습니다.

Cloud infrastructure diagram showing fleet management and agent orchestration at scale System Abstract Visual

개발자 경험은 이제 에이전트를 위한 것이기도 하다

스포티파이의 오래된 엔지니어링 원칙 중 하나는 **"우리가 세계 최고 수준으로 잘하는 기술의 수를 줄일수록, 우리는 더 빨리 움직인다"**는 것입니다. 이 원칙은 AI 시대에 더욱 중요해졌습니다.

Backstage와 표준화의 힘

Claude가 일관된 코드를 많이 참조할수록 더 나은 결과를 냅니다. 스포티파이의 Backstage(오픈소스 IDP)는 이를 가능하게 하는 핵심입니다. Backstage는 모든 소프트웨어 컴포넌트를 카탈로그화하고, 표준 기술 스택과 디자인 패턴을 정의합니다.

  • Soundcheck: 팀이 자신의 컴포넌트가 표준을 얼마나 잘 따르고 있는지 자가 진단할 수 있는 UI
  • Golden State: 각 컴포넌트 타입별 권장 기술과 관행 정의
  • MCP/CLI 도구: Backstage의 기능을 Claude가 직접 호출할 수 있도록 노출

한국 개발 생태계에서의 적용 맥락

국내 SI/스타트업 환경에서는 '모든 서비스가 동일한 기술 스택'을 강제하기 어려운 경우가 많습니다. 하지만 마이크로서비스 간의 인터페이스(API 명세, 메시지 포맷)만이라도 표준화하는 것부터 시작할 수 있습니다. 예를 들어, gRPC나 GraphQL로 통일하거나, 이벤트 스키마를 레지스트리로 관리하는 식입니다. 이렇게만 해도 AI 에이전트가 코드를 이해하고 수정하는 난이도가 크게 낮아집니다.

이 기술의 한계 또는 주의사항

  1. 초기 투자 비용: Fleet Management와 Backstage 같은 플랫폼을 구축하는 데는 상당한 엔지니어링 리소스가 필요합니다. 소규모 팀이나 스타트업에는 오버엔지니어링일 수 있습니다.
  2. 에이전트의 맥락 이해 한계: Honk v2에서 '멀티플레이어 협업'을 도입했지만, 여전히 복잡한 비즈니스 로직이나 도메인 지식이 필요한 결정은 사람의 판단이 필요합니다.
  3. PR 리뷰 부담: PR이 76% 증가하면 리뷰어의 병목이 심각해집니다. 자동 머지 정책을 신중하게 설계하지 않으면 품질 저하가 발생할 수 있습니다.

다음 단계 학습 방향

  • Backstage 공식 문서를 읽고 IDP 개념 익히기
  • Claude Agent SDK나 LangGraph를 활용한 간단한 코딩 에이전트 직접 만들어보기
  • **MCP(Model Context Protocol)**의 개념과 활용 사례 학습하기

함께 보면 좋은 글

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.