스포티파이는 실제로 무엇을 했는가
앤트로픽 유튜브에 공개된 인터뷰에서 스포티파이 엔지니어링 리더 니클라스 구스타브손은 몇 가지 수치를 공개합니다. 코드 변경 요청(PR)의 73%를 이제 AI가 직접 작성하고, PR 발생 빈도는 75% 이상 늘었으며, 하루 약 4,500번 프로덕션 배포를 하면서도 품질 지표는 그대로 유지되고 있다는 것입니다. 이 모든 걸 가능하게 한 내부 도구가 "Honk"입니다.
Honk는 처음부터 이런 모습은 아니었습니다. 5~6년 전 코드베이스가 엔지니어 수보다 7배 빠르게 늘어나는 걸 발견하면서, 반복적인 유지보수(버전 업그레이드, API 교체 등)를 자동화하려고 만든 도구였습니다. 초창기엔 결정론적 스크립트에 의존했지만 코드의 API 표면이 너무 복잡해 곧 한계에 부딪혔고, 이후 LLM을 붙이는 수십 번의 시행착오 끝에 지금 형태로 자리 잡았습니다. 초기엔 결과를 다시 검토하는 "심사(judge)" 단계가 PR 성공률을 20~30%에서 80%까지 끌어올렸지만, 모델과 에이전트 자체가 좋아지자 이 심사 단계는 아예 제거됐습니다.
AI에게 일을 맡기려면 왜 검증부터 갖춰야 하는가
스포티파이가 사람 검토 없이 PR을 자동으로 병합하기로 했을 때 가장 먼저 한 투자는 테스트 자동화였습니다. 예전엔 코드를 소유한 팀이 모든 PR을 직접 눈으로 확인했기 때문에 테스트가 다소 허술해도 괜찮았지만, 그 사람 검토를 빼려면 테스트가 그 역할을 대신할 수 있을 만큼 탄탄해야 했습니다. 구스타브손은 이를 "사람이 개입하지 않는 폐쇄 루프에서는 검증이 가장 중요한 단 하나의 요소"라고 표현합니다.
이 원칙은 사무 업무에도 그대로 적용됩니다. 보고서 초안, 고객 메일, 데이터 요약처럼 AI에게 맡기고 싶은 업무가 있다면, AI가 만든 결과물이 맞는지 자동으로든 수동으로든 걸러낼 기준부터 마련해야 합니다. 검증 기준 없이 결과물만 빨라지면, 오류도 그만큼 빠르게 퍼집니다.
표준화가 왜 AI 활용도까지 좌우하는가
구스타브손은 같은 기능이 코드베이스 안에서 열 가지 다른 방식으로 구현돼 있으면 AI도 헷갈린다고 말합니다. 반대로 코드와 도구, 프레임워크가 일관될수록 AI가 참고할 패턴이 명확해지고 결과물의 질도 올라갑니다. 원래 이런 표준화는 사람이 일하기 편하자고 시작한 투자였는데, 지금은 AI 활용도를 가르는 조건이 됐다고 그는 짚습니다.
사무 조직도 마찬가지입니다. 보고서 양식, 문서 폴더 구조, 이메일 톤이 팀마다 제각각이면 AI에게 맡길 때마다 매번 다른 결과가 나옵니다. 반대로 양식과 절차가 표준화된 팀은 AI를 붙이자마자 바로 속도가 붙습니다.
AI가 시간을 벌어주면 그 시간은 어디로 가는가
구스타브손 개인의 변화도 흥미롭습니다. 예전엔 AI가 코드의 70~80%를 써주면 나머지는 직접 IDE에서 마무리해야 했는데, 지금은 그 마무리 작업 자체가 사라졌습니다. 그렇게 남은 시간은 저절로 프로토타이핑과 고객 대화, "다음에 뭘 할지"를 고민하는 쪽으로 옮겨갔다고 말합니다.
스포티파이는 이 흐름을 회사 차원의 인프라로 만들었습니다. 개발자가 아닌 직원도 아이디어를 자연어로 설명하면 AI가 실제 작동하는 프로토타입을 만들어주는 시스템을 구축했고, 사내에는 이런 프로토타입을 공유하고 체험하는 "앱스토어"까지 있습니다. 예전엔 아이디어 하나를 검증하려면 엔지니어링 팀을 설득해 몇 주를 기다려야 했지만, 지금은 하루 안에 실제 데이터로 확인할 수 있습니다. 공동 CEO 중 한 명도 이 사내 앱스토어에 직접 만든 프로토타입을 올려둔 상태입니다.
AX 컨설팅 관점에서 사무직 조직은 지금 무엇을 준비해야 하는가
AX 컨설팅 현장에서 만나는 조직들에 항상 묻는 질문이 있습니다. 우리 팀의 업무 노하우는 문서로 꺼내져 있습니까, 아니면 몇 사람의 머릿속에만 있습니까. 스포티파이 사례가 보여주는 것처럼, AI를 얼마나 빨리 얼마나 안전하게 쓸 수 있는지는 결국 검증 기준과 표준화가 얼마나 갖춰져 있느냐에 달려 있습니다.
그리고 구스타브손이 마지막에 남긴 개인적인 소감도 곱씹을 만합니다. 그는 원래 손으로 코드를 짜는 과정 자체를 즐기던 사람이라, AI가 그 재미를 없앨까 봐 걱정했다고 말합니다. 그런데 실제로 자신이 좋아했던 건 "문제를 해결하는 것"이었지 "손으로 코드를 치는 방식"이 아니었다는 걸 깨달았다고 합니다. 이 구분은 사무직에도 유효합니다. 지금 하는 일에서 진짜 좋아하는 부분이 도구를 다루는 과정인지, 아니면 그 결과로 얻는 문제 해결과 판단인지 구분해 보면, AI 시대에 무엇을 지키고 무엇을 넘겨줄지가 훨씬 분명해집니다.