Claude Code 토큰 90% 절감, Spotify가 택한 ‘작업 분업’

코딩 에이전트가 쓰는 토큰의 상당 부분은 깊은 추론보다 파일 읽기와 반복 코드 출력에 들어간다. Spotify Engineering의 실험은 이 입출력 작업을 Gemini 2.5 Flash 같은 저비용 모델에 맡기고, Claude Code의 비싼 문맥은 판단이 필요한 순간에 보존하는 구조다. Hacker News의 관심도 절감률 자체보다 어떤 작업은 넘겨도 되고 어떤 작업은 남겨야 하는지에 모였다.

구성의 출발점은 Portal by Spotify의 AiKA Modes다. 명령과 모델, 온도, MCP 도구를 선언하면 일회성 실행 환경에서 동작하는 에이전트를 만들 수 있다. 글쓴이는 여러 파일을 읽고 질문에 구조화된 답을 내는 bulk-reader와 기존 파일의 관례를 따라 테스트·설정·타입 골격을 만드는 code-writer를 구성했다. 두 모드 모두 예시에서는 Gemini 2.5 Flash를 사용하지만 Portal에 등록한 다른 모델로 바꿀 수 있다.

실제 라우팅은 shunt라는 Claude Code 플러그인이 강제한다. 기본 350줄을 넘는 파일을 통째로 읽으려 하면 PreToolUse 훅이 요청을 막고 bulk-reader 사용을 안내한다. 필요한 구간만 지정한 읽기나 파이프로 좁힌 명령은 그대로 통과한다. code-writer는 요구사항과 참조 파일을 작업 모델에 보내고 결과를 디스크에 직접 쓴다. 생성된 전체 코드가 Claude의 문맥에 다시 들어오지 않으므로 입력과 출력 양쪽에서 토큰을 아낀다.

Java 모노레포의 네 가지 시나리오에서 bulk-reader가 만든 요약을 읽는 방식은 원본 파일을 직접 읽을 때보다 평균 약 90% 적은 Claude 토큰을 썼다. 다만 이 수치는 모든 개발 작업의 비용을 90% 줄였다는 뜻은 아니다. 파일이 작으면 네트워크 왕복 비용이 절감분보다 커지고, 각 위임에는 보통 10~30초가 걸린다. Portal의 단일 호출 제한도 30초라 큰 생성 작업은 나눠야 한다.

한계는 더 실무적이다. 작업 모델의 요약에는 신뢰할 만한 줄 번호가 없어 실제 편집 단계에서는 Claude가 해당 구간을 다시 읽어야 했다. 표면적인 패턴은 찾았지만 미묘한 스레드 안전성 버그를 놓친 사례도 있었다. 그래서 디버깅, 아키텍처 결정, 안전에 민감한 코드는 라우팅 대상에서 제외한다. 참조 파일 없이 코드를 만들게 하면 현재 저장소와 맞지 않는 상용구가 나오기 쉬워 code-writer에는 기준 파일을 필수로 붙였다.

이 사례의 쓸모는 특정 제품 조합보다 작업을 난이도와 입출력량으로 나눈 데 있다. 강한 모델 하나에 모든 파일 읽기와 생성을 몰아주는 대신, 훅이 기계적인 작업을 포착하고 저렴한 모델이 정해진 형식으로 처리한다. 절감 효과를 재현하려면 토큰만이 아니라 지연 시간, 재작업률, 놓친 결함까지 함께 측정해야 한다. 비용 라우팅이 코드 품질의 빈틈으로 바뀌지 않도록 경계선을 운영 규칙으로 남기는 것이 관건이다.