TECH 으로 돌아가기
TECH HACKER NEWS 오늘 7분 읽기 26 READS

스포티파이 '포털'로 클로드 코드 토큰 90% 절감하기: AI 코딩의 잡무 분리 전략

스포티파이 '포털'로 클로드 코드 토큰 90% 절감하기: AI 코딩의 잡무 분리 전략
SOURCE IMAGE · HACKER NEWS

AI 코딩 에이전트가 실제로 하는 일 대부분은 '사고'가 아니라 '입출력(I/O)'이다. 한 메서드의 동작을 파악하려고 파일 다섯 개를 읽고, 옆에 있는 스무 개의 테스트 파일과 똑같은 패턴으로 새 테스트를 찍어내고, 회의 후 문서를 갱신하는 일이 그렇다. 이 과정에서 수천 개의 토큰이 소모되지만 정작 추론은 거의 일어나지 않는다. 문제는 좌석 라이선스 비용이 아니라 토큰이며, 이 단순 작업까지 전부 최상위 프런티어 모델에 맡기는 구조가 낭비의 핵심이다. 스포티파이 엔지니어링 블로그에 실린 이 사례는 그 잡무를 더 저렴한 모델로 넘기고, 비싼 모델은 진짜 사고가 필요한 문제에만 쓰자는 발상에서 출발한다.

비용 압박은 개인 차원의 문제가 아니다. 글에 따르면 2028년경 AI 코딩 비용은 개발자 평균 연봉을 넘어설 것으로 전망되며, 엔지니어링 리더 4분의 1이 이미 개발자 1인당 월 200~500달러를 토큰에 쓰고 있고 일부는 2,000달러를 훌쩍 넘긴다. 도구가 비용을 상쇄하려면 굳이 프런티어 토큰이 필요 없는 작업에 그것을 태우지 않아야 한다는 것이다.

모드: 인프라 문제를 설정 문제로 바꾸다

해법의 중심에는 스포티파이 내부 플랫폼 '포털(Portal)'의 AiKA 모드가 있다. 모드는 일시적 런타임 위에서 도는 선언형 에이전트로, 저자는 이를 'AWS 람다의 에이전트 버전'에 비유한다. 지시문을 정의하고 모델과 온도 같은 파라미터를 고른 뒤 MCP 도구를 붙이면, 서버 운영이나 API 키 관리 없이 CLI나 API로 호출할 수 있다. 저자는 여기에 두 개의 모드를 만들었다. 여러 파일을 읽고 질문에 구조화된 요약으로 답하는 '벌크 리더(bulk-reader)', 그리고 사양과 참조 파일을 받아 기존 패턴에 맞는 코드를 생성하는 '코드 라이터(code-writer)'다. 예시에서 두 모드 모두 워커 모델로 제미나이 2.5 플래시를 쓰지만, 모델 필드는 포털에 설정된 어떤 모델이든 받는다.

'션트' 플러그인이 강제하는 라우팅

초기 버전은 CLAUDE.md에 라우팅 규칙을 적어 클로드가 스스로 포털로 넘기도록 한 방식이었다. 그러나 규칙은 권고일 뿐 강제되지 않았고 클로드가 무시할 수 있었으며 프로젝트마다 복사해야 했다. 현재 버전은 'shunt'라는 클로드 코드 플러그인으로, 포털 CLI 액션 레지스트리를 거쳐 동작한다. 핵심은 도구 호출 직전에 발동하는 PreToolUse 훅 두 개다. check-file-size는 Read 호출마다 실행돼 파일이 기준선(기본 350줄)을 넘으면 읽기를 막고 /bulk-reader 스킬을 쓰도록 유도한다. check-bash-read는 큰 파일에 대한 cat, head, tail, less, more를 잡아낸다. 다만 offset/limit을 지정한 부분 읽기나 파이프 명령(cat file | grep) 같은 표적형 읽기는 그대로 통과시킨다. 기준선은 SHUNT_MIN_LINES 환경변수로 조정된다.

실무적으로 중요한 점은 데이터 흐름이다. bulk-read는 파일들을 XML 태그로 감싸 질문과 함께 워커 모델로 보내고, 원본 코퍼스는 클로드의 컨텍스트에 들어가지 않는다. 호출은 일회성이라 후속 질문에서 파일을 다시 보내도 부담이 없다. code-write는 생성된 코드에서 마크다운 펜스를 제거하고 곧바로 디스크에 쓰기 때문에 클로드는 결과 코드를 아예 보지 않는다. 참조 파일은 필수인데, 맞출 패턴이 없으면 워커가 프로젝트에 맞지 않는 코드를 만들어내기 때문이다. 훅이 비싼 읽기를 막고 스킬 문서가 호출 문법을 안내하는 이중 구조 덕분에, 클로드가 스킬 설명을 읽지 않아도 시스템은 무너지지 않고 완만하게 성능이 낮아진다.

어디까지 위임할 수 있고 어디서 멈추는가

자바 모노레포에서 네 가지 시나리오로 측정한 결과, 벌크 리더의 평균 토큰 절감률은 약 90%에 달했다. 다만 저자는 한계도 분명히 짚는다. 편집은 위임할 수 없다. 워커의 요약에는 신뢰할 만한 줄 번호가 없어, 분석 결과로 코드를 고쳐야 하면 해당 구간을 직접 읽어야 한다. 추론도 위임 대상이 아니다. 테스트에서 워커 모델은 표면적 패턴은 잡았지만 미묘한 스레드 안전성 버그를 놓쳤고, 클로드는 맥락을 받자마자 몇 초 만에 이를 찾아냈다. 그래서 라우팅은 디버깅, 아키텍처 결정, 안전이 중요한 코드를 명시적으로 제외한다.

지연 시간도 고려 요소다. 각 위임은 클로드 코드에서 포털 백엔드, 워커 모델을 거쳐 돌아오는 왕복이라 보통 10~30초가 걸리고 포털은 한 호출을 30초로 제한한다. 큰 읽기에는 감수할 만하지만 작은 작업에서는 오히려 손해라, 기준선 아래에서는 위임 오버헤드가 절감분을 넘어선다. 대용량 생성은 여러 번으로 쪼개야 한다는 점도 실무에서 유념할 대목이다.

결국 플러그인은 클로드 코드에 특화된 결과물이지만, 그 밑에 깔린 아이디어는 모드가 떠받치는 '모델 라우팅'이다. 플러그인은 언제 위임할지를, 모드는 어떻게 응답할지를 결정하도록 분리돼 있어 워커 모델이나 지시문을 바꿔도 플러그인은 그대로다. 두 모드는 이미 공개돼 있어 별도로 만들 필요 없이 마켓플레이스(spotify/portal-ai-plugins)에서 설치하고 /portal:setup으로 인증하면 쓸 수 있으며, 필요하면 포크한 버전이 자동으로 우선 적용된다. 한국의 개발 조직에도 시사점은 분명하다. 토큰 비용을 줄이는 길은 더 싼 상위 모델을 기다리는 것이 아니라, 어떤 작업이 진짜 사고를 요구하는지 구분해 나머지를 값싼 경로로 흘려보내는 설계에 있다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://engineering.atspotify.com/2026/9/portal-by-spotify-c...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...