AI 코딩 에이전트를 도입하는 팀들이 공통적으로 맞닥뜨리는 벽이 있다. 처음엔 빠르게 돌아가는 것 같은데, 어느 순간 비용 청구서가 예상을 훨씬 초과하거나, 에이전트가 같은 실수를 반복하거나, 루프가 돌아가는 동안 개발자가 뭘 해야 할지 모르는 상황이 온다. 이 세 문제는 사실 하나의 뿌리에서 나온다. 루프를 '돌리는 것'과 '설계하는 것'을 혼동한 것이다.
최근 세 가지 관점이 이 문제를 다른 각도에서 조명하고 있다. Addy Osmani가 정리한 루프 엔지니어링 개념, Claude Code를 외부에서 강화하는 훅 기반 도구들, 그리고 다중 에이전트 시스템의 토큰 소비를 실측한 Tokenomics 연구다. 각각을 따로 읽으면 흥미로운 아이디어들이지만, 묶어서 읽으면 하나의 실전 설계 원칙이 나온다.
토큰이 어디로 가는지 먼저 봐라
ChatDev 프레임워크로 30개 소프트웨어 개발 태스크를 실측한 Tokenomics 연구의 결론은 직관과 다르다. 많은 팀이 '코드 생성'이 가장 비싼 단계라고 생각하지만, 실제로 초기 코딩 단계는 전체 토큰의 평균 8.6%만 쓴다. 진짜 비용은 코드 리뷰 단계에서 터진다. 평균 59.4%다.
이유는 구조에 있다. 에이전트들이 코드 개선을 협업으로 수행할 때, 에이전트 간 컨텍스트 전달이 반복적으로 일어난다. 연구는 이를 'communication tax'라고 부른다. 전체 토큰의 53.9%가 입력 토큰이고, 출력은 24.4%에 불과하다. 새로운 것을 생성하는 데 쓰는 비용보다 기존 맥락을 주고받는 데 쓰는 비용이 두 배 이상이라는 뜻이다. 루프를 많이 돌릴수록 이 communication tax가 복리로 쌓인다.
실용적 함의는 명확하다. 그린필드 신규 프로젝트와 기존 코드 리팩터링·디버깅 프로젝트는 비용 구조 자체가 다르다. 레거시 코드 개선에 에이전트 루프를 붙이면, 입력 중심의 비싼 코드 리뷰 사이클이 비용 대부분을 먹는다. 팀이 에이전트 도입 ROI를 계산할 때 이 차이를 모르면 숫자가 맞지 않는다.
루프는 프롬프트가 아니라 시스템이다
Addy Osmani가 제시한 루프 엔지니어링의 핵심 전환은 간단하다. 개발자가 매번 프롬프트를 쓰는 대신, 에이전트가 무엇을 찾고, 어떻게 처리하고, 언제 멈출지를 시스템으로 설계한다는 것이다. 워크트리로 병렬 작업 공간을 나누고, 스킬 문서로 프로젝트 관행을 에이전트에게 주입하고, MCP 커넥터로 Linear·Slack·DB를 연결하는 구조가 그 구성 요소다.
그런데 여기서 Tokenomics 연구의 발견과 교차점이 생긴다. 루프가 복잡해질수록—서브에이전트가 늘어나고, 반복 검증 사이클이 추가될수록—communication tax가 기하급수적으로 커진다. 루프를 설계할 때 '무엇을 자동화할 것인가'만큼 '어느 단계에서 컨텍스트 전달을 최소화할 것인가'를 함께 설계해야 한다는 뜻이다. 검증 루프를 촘촘하게 짤수록 토큰 비용이 올라간다는 트레이드오프를 미리 인식해야 한다.
프롬프트로 못 고치는 건 구조로 고쳐라
Claude Code에 Throughline·Caveat·Spotter 세 가지 외부 강화 도구를 npm에 공개한 개발자의 접근은 이 트레이드오프를 정면으로 다룬다. 그는 먼저 "be careful"류 프롬프트가 해결할 수 있는 문제와 해결할 수 없는 문제를 명확히 구분했다.
프롬프트로 고칠 수 있는 건 Claude가 '잊어서' 생기는 문제다. 볼 수 있게 해주면 된다. 하지만 고칠 수 없는 건 Claude가 자신의 한계를 인식하지 못하는 구조적 문제다. 컨텍스트가 부풀어 있다는 걸 Claude 자신은 알 수 없다. 지난 세션에서 빠진 함정을 기억하지 못한다. 호출을 빠뜨렸다는 사실 자체를 모른다.
세 도구의 설계 원칙은 단순하다. Claude에게 아무것도 요구하지 않는다. Throughline은 도구 입출력을 SQLite로 오프로드해 컨텍스트 부담을 줄인다—이건 Tokenomics 연구가 말한 입력 토큰 과잉 문제를 훅 레벨에서 직접 자르는 접근이다. Caveat는 과거 함정 노트를 유사 상황에서 자동 주입한다. Spotter는 별도 Claude(Haiku 4.5)가 사이드에서 놓친 도구 호출을 감지해 알린다. Claude 코드 변경 없이 훅만으로 동작한다.
Tokenomics 관점에서 보면 이 세 도구는 communication tax를 줄이는 실용적 구현이기도 하다. Throughline이 이미 쓴 파일 내용을 컨텍스트에서 제거한다는 건, 불필요한 입력 토큰 반복을 외부에서 막는다는 뜻이다. 루프 설계에 이런 외부 강화 레이어를 추가하면 검증 품질은 유지하면서 비용 증가를 억제할 수 있다.
루프 설계의 실전 원칙
세 관점을 하나의 설계 원칙으로 정리하면 이렇다.
첫째, 비용 지도를 먼저 그려라. 어떤 단계에서 토큰이 집중되는지 파악하지 않고 루프를 설계하면 예산 초과는 시간 문제다. 신규 개발인지 기존 코드 개선인지에 따라 비용 구조가 전혀 다르다는 걸 전제하고 설계를 시작해야 한다.
둘째, 검증 단계 전에 human-in-the-loop 체크포인트를 넣어라. Tokenomics 연구는 코드 리뷰 루프가 비용을 지배한다고 말한다. 반복 검증이 시작되기 전에 사람이 한 번 개입하면 불필요한 루프를 차단할 수 있다. 루프를 최대한 자율적으로 돌리고 싶은 욕구와, 비용이 폭발하기 전에 잡아야 하는 현실 사이에서 균형점을 설계하는 게 테크 리드의 일이다.
셋째, 프롬프트로 고칠 수 없는 문제는 구조로 해결해라. CLAUDE.md가 무거워질수록 읽히지 않는다. 컨텍스트 관리, 과거 기억, 누락 탐지는 훅 레벨의 외부 강화로 처리하는 게 더 효과적이다.
넷째, 작성자와 검증자를 분리해라. Addy Osmani가 강조한 이 원칙은 Spotter 도구의 설계이기도 하고, Tokenomics 연구에서 별도 에이전트가 리뷰를 담당하는 구조와도 일치한다. 만든 에이전트가 스스로 평가하면 관대해진다.
루프가 성숙해지면 다음 문제가 온다
솔직히 말하면, 지금 언급한 세 도구가 다루지 못하는 문제들이 더 있다. 긴 세션에서 Claude의 페르소나가 흐려지는 롤 드리프트, 서브에이전트가 부모 세션의 암묵적 컨텍스트를 물려받지 못하는 문제, 여러 도구 중 잘못된 도구를 선택하는 판단 오류가 그것이다. 이건 현재진행형 문제다.
Tokenomics 연구도 한계를 인정한다. ChatDev와 GPT-5 단일 조합의 측정이라 다른 아키텍처에선 패턴이 달라질 수 있다. 하지만 방향은 분명하다. communication tax를 줄이는 더 효율적인 에이전트 협업 프로토콜이 필요하고, 단순한 전체 컨텍스트 전달을 넘어서는 방식이 요구된다.
팀에 루프를 도입하려는 테크 리드에게 가장 실용적인 조언은 이것이다. 루프를 설계하기 전에 먼저 비용 지도를 그리고, 프롬프트가 해결할 수 없는 문제를 구조로 보완하고, 검증 단계의 토큰 비용을 관리하는 체크포인트를 미리 심어라. 루프는 자동화 도구가 아니라 시스템 설계 결정이다.