"I don't think at the end of the year no one is going to be using an IDE."
Spotify의 엔지니어링 리더 Niklas Gustavsson이 작년 9월에 한 말이다. Boris Cherny가 들었을 때 "미친 소리, 두 달 안에 그런 일이 일어날 리가 없다"고 생각했다. 두 달 뒤, 그 자신도 IDE를 쓰지 않게 됐다. 30년간 코딩을 해온 사람의 워크플로우가 두 달 만에 완전히 바뀌었다.
이 인터뷰를 보면서 계속 떠오른 단어가 하나 있었다. 하네스. 내가 OpenClaw로 에이전트를 돌리면서 계속 써왔던 개념인데, Spotify는 그 하네스의 완성형을 보여주고 있었다.
Honk — 코드베이스 전체를 에이전트가 돌리는 시스템
Spotify에는 Honk라는 시스템이 있다. Claude Agent SDK 위에 구축된 에이전트 플랫폼인데, 하는 일을 하나로 요약하면 "코드베이스 전체에 자동으로 코드 수정 요청을 날린다"다. Spotify를 예로 들어보자. 백엔드 모노레포가 2천만 줄이 넘는다. 엔지니어 2,900명이 매일 이 코드를 고치는데, 과거에는 Java 버전 업그레이드 하나만 해도 수백 개 팀이 각자 코드를 수정해야 했다. 한 번의 마이그레이션에 몇 달이 걸렸다.
그래서 Spotify는 fleet management라는 인프라를 먼저 구축했다. 결정론적 스크립트로 수천 개 저장소에 일괄 수정을 가하는 시스템이다. 수백만 건의 PR을 자동으로 머지했다. 그런데 코드라는 게 API 표면이 엄청 넓다. 메서드 하나 바꾸려고 해도 다섯 가지 호출 패턴이 있고, 각 케이스마다 예외 처리가 필요하다. 결국 스크립트 하나가 수천 줄짜리 예외 처리 덩어리가 됐다. 정적 분석의 한계였다.
LLM이 등장하면서 Spotify는 접근 방식을 바꿨다. 처음에는 모델 앞에 코드를 던져주고 한 번에 수정을 시도했다. 당연히 안 됐다. 그런데 모델이 좋아지면서, 그리고 문제를 쪼개고 LLM을 판사(judge)로 쓰는 방식을 도입하면서 성공률이 올라갔다. judge가 붙었을 때 PR 성공률이 20~30%에서 80%로 뛰었다. 그 뒤로 모델이 더 좋아지면서 judge는 결국 제거됐다. 에이전트 자체가 충분히 정확해졌기 때문이다.
Honk는 Kubernetes 파드에서 돈다. 에이전트가 CI 빌드를 직접 돌릴 수 있다. Linux뿐만 아니라 macOS에서도. iOS 시뮬레이터까지 돌려가며 검증한다. Figma 디자인을 iOS 화면으로 직접 포팅하는 작업도 이 시스템 위에서 돌아간다. 결과는 어마어마하다. 현재 Spotify PR의 73%가 AI가 작성한 것이고, PR 빈도는 75% 이상 개선됐다. 하루 4,500번의 프로덕션 배포가 이루어지는데, 그 상당수가 에이전트가 만든 코드다.
검증이 하네스의 본질이다
인터뷰를 다 듣고 나서 깨달은 건, Spotify가 에이전트를 잘 쓰는 이유는 모델이 좋아서가 아니라는 거다. 검증 인프라가 먼저 쌓여 있었기 때문이다. Niklas가 명시적으로 말한다. 에이전트가 자동으로 PR을 머지하려면, 테스트 자동화가 없으면 불가능하다. 사람이 every PR을 리뷰하던 시절에는 테스트가 조금 부족해도 괜찮았다. 리뷰어가 잡아주니까. 그런데 에이전트가 자동으로 코드를 바꾸고 자동으로 머지하려면, 테스트가 그 자리를 대신해야 한다.
이건 내가 Claude Code를 쓰면서 직접 체감한 것과 정확히 맞물린다. Claude에서 도구를 만들면, Claude가 웹을 직접 띄워서 동작을 검증한다. 화면이 제대로 나오는지, 버튼이 작동하는지, 에러가 없는지를 에이전트가 스스로 확인한다. 이 검증 루프가 얼마나 중요한지를 Claude를 쓰면서 몸으로 배웠다.
반면 OpenClaw 환경은 검증 루프가 아직 부족하다. 에이전트가 코드를 수정하고 파일을 저장하지만, 그 코드가 실제로 제대로 작동하는지를 에이전트가 직접 확인하는 단계까지는 가지 않는 경우가 많다. 블로그 글을 쓰고 git push를 하면, Vercel에서 빌드가 실패했을 때 그걸 에이전트가 자동으로 감지하고 수정하는 루프가 없다. 내가 직접 브라우저를 열어서 확인하거나, 빌드 에러 로그를 보고 수동으로 고쳐야 한다.
Spotify의 교훈은 명확하다. 에이전트가 빠르려면 검증이 빨라야 하고, 검증이 빠르려면 테스트 자동화에 투자해야 한다. 속도와 품질은 트레이드오프가 아니다. 품질 인프라에 투자하면 속도가 올라간다. Niklas는 "표준화"도 같이 언급한다. 코드베이스가 일관된 패턴을 따를수록 에이전트가 더 잘 작동한다. 10가지 다른 스타일이 있으면 에이전트가 헷갈린다. 일관성이 에이전트의 성능을 끌어올린다.
내 OpenClaw 환경으로 돌아와서 생각해보면, 하네스 엔지니어링이 결국 검증 인프라를 얼마나 잘 갖추느냐의 문제라는 걸 깨닫는다. CLAUDE.md, PLAN.md, TODO.md 같은 문서화도 중요하지만, 그건 하네스의 입력측이다. 출력측, 즉 "에이전트가 만든 결과물이 제대로 작동하는지 자동으로 검증하는 루프"가 없으면 하네스는 반쪽짜리다. Spotify는 그 반쪽을 완성한 것이다.
인터뷰에서 특히 흥미로웠던 부분은 프로토타이핑이었다. Spotify에는 내부 앱스토어가 있다. 에이전트로 만든 프로토타입을 올리면 다른 사람들이 받아서 써볼 수 있다. 공동 CEO도 직접 프로토타입을 올렸다. 엔지니어가 아닌 사람도 자연어로 아이디어를 표현하면 Claude가 구현해주는 세상. 아이디어를 검증하는 데 걸리는 시간이 몇 주에서 몇 시간으로 줄었다.
이건 내가 회사에서 하고 있는 일과 직접 맞닿아 있다. 나는 AX 팀을 만들어서 각 팀이 직접 에이전트로 프로토타입과 MVP를 만들 수 있도록 트레이닝하고 있다. 클라이언트에게 보여주는 용도는 아니지만, 내부적으로 아이디어를 빠르게 프로토타입으로 만들어서 다른 팀과 공유하는 일을 지금 하고 있다. Spotify의 내부 앱스토어 모델은 이걸 조직 전체로 확장한 것이다. 각 팀이 에이전트를 써서 자기 아이디어를 직접 구현한다. 엔지니어를 설득할 필요 없이, 에이전트에게 말하면 된다.
내가 AX 팀을 트레이닝하면서 느끼는 건, 기술 자체가 장벽이 아니라는 거다. Claude Code를 쓰는 건 며칠이면 배운다. 진짜 장벽은 "검증 없이 에이전트가 만든 결과물을 신뢰할 수 있나?"라는 질문이다. Spotify가 수년에 걸쳐 쌓은 테스트 자동화, CI 인프라, 컴포넌트 소유권 모델이 없었다면 Honk는 작동하지 않았을 것이다. 나의 AX 팀도 마찬가지다. 에이전트에게 코드를 만들게 하고, 그게 제대로 작동하는지 검증하는 루프를 각 팀이 스스로 갖춰야 한다. 그래야 에이전트의 속도를 믿고 쓸 수 있다.
Niklas가 인터뷰 마지막에 하는 말이 묵직하게 남는다. 30년간 코딩을 즐겨온 사람인데, 이제 에이전트 5개를 백그라운드에 돌려놓고 일한다. "문제를 푸는 걸 좋아했는데, 푸는 방식이 달라져도 그 즐거움은 사라지지 않았다." 하네스가 잘 설계되어 있으면, 에이전트가 반을 하고 사람이 반을 한다. 각자 잘하는 몫을 하는 것이다. 내가 AX 팀에게 가르치는 것도 결국 같은 거다. 에이전트에게 일을 맡기되, 그 결과물을 검증할 수 있는 능력을 갖춰라. 그게 하네스의 본질이다.
Spotify의 하네스를 보고 나서 드는 질문. 다음으로 투자해야 할 것은 모델이나 프롬프트가 아니라, 검증 루프 아닐까?