합리적인 결정이 청구서를 만든다
AI 코딩 에이전트 비용이 예상을 넘어설 때, 대개 '어디서 낭비했나'를 찾으려 한다. 그런데 dev.to에 올라온 분석 글은 불편한 진실을 하나 지적한다. 비용을 키우는 건 명백한 실수가 아니라 그 순간에는 전부 합리적으로 느껴지는 결정들이라는 것이다. 파일 하나 더 읽어보기, 좋은 모델로 확인하기, 답변을 바로 메인 스레드에 쓰기—각각은 방어 가능한 판단이고, 합산하면 예산 초과다.
토큰이 새는 다섯 가지 패턴
구조적으로 정리하면 비용 누수의 원인은 다섯 가지로 압축된다. 메인 에이전트가 직접 읽는 모든 파일은 세션이 끝날 때까지 컨텍스트에 잔류하며 매 턴마다 재청구된다. 한 번 읽은 파일에 계속 렌트를 내는 구조다. '확인 삼아 한 번 더' 패턴도 마찬가지—개별 읽기는 방어되지만 총합이 문제가 된다. 그리고 ls, grep, 정의 탐색 같은 구조적 조회를 최신 프론티어 모델에 돌리는 것, 5000단어짜리 결과물을 메인 에이전트가 직접 생성하는 것, 그리고 한 번 부풀어 오른 컨텍스트가 세션이 끝날 때까지 조용히 청구액을 키우는 컨텍스트 블로트. 이 다섯 패턴은 '조심하면 피할 수 있다'는 수준이 아니다. 순간의 판단으로는 절대 잡히지 않는다. 합산 패턴은 집계해야만 보인다.
'조심하겠다'는 전략이 실패하는 이유
그래서 저자가 내린 결론은 의지력에 기대지 말라는 것이다. 필요한 건 순간 바깥에서 패턴을 감지하고 끊는 구조다. 그가 설계한 건 네 가지다. 모든 툴 호출에 실행되며 지출 규율을 강제하는 훅, 행동 전에 모델 등급을 결정하는 라우터와 비싼 에이전트 전에 싸게 정찰하는 위임 규칙, 린 플래너가 새 컨텍스트 워커를 조율하는 부모-자식 구조. 그리고 여기서 그가 '예상치 못한 결과'라고 표현한 게 있다. 비용 절감과 품질 향상이 같은 레버였다는 것이다. 벌크 읽기를 위임하고, 적절한 모델을 라우팅하고, 메인 에이전트의 컨텍스트를 깨끗하게 유지하는 것—이 동작들이 동시에 에이전트를 더 집중되고 정확하게 만들었다.
속도가 공짜가 될 때, 남는 문제는 '뭘 만들고 뭘 막을 것인가'
비용 최적화와 다른 각도에서 같은 문제를 건드리는 시도가 있다. Y Combinator 대표 Garry Tan이 공개한 오픈소스 스택 gstack이다. Claude Code를 23명의 전문가 팀으로 확장하는 구조로, CEO·엔지니어링 매니저·디자이너·QA 리드·보안 담당자·릴리즈 엔지니어가 모든 변경사항을 다중 관점 리뷰로 통과시킨다. gstack이 파는 것은 '더 빠른 코딩'이 아니다. '배포 전 리뷰'다.
gstack의 ETHOS 파일에는 이런 문장이 있다. "엔지니어링 장벽은 무너졌다. 남은 건 취향, 판단, 그리고 완전한 것을 완성하려는 의지다." Garry Tan은 13년 전보다 수백 배 빠르게 코드를 배포한다고 말하지만, 그가 강조하는 건 속도가 아니다. 코드를 작성하는 비용이 거의 없어졌을 때, 실제 병목은 무엇을 만들고 무엇을 배포하지 않을 것인가로 이동한다는 것이다.
'AI가 동의한다'는 건 승인이 아니다
gstack에서 내가 주목하는 원칙은 따로 있다. "AI 모델은 추천한다. 결정은 사람이 한다." 그리고 "두 AI 모델이 같은 변경사항에 동의하는 건 강한 신호다. 명령이 아니다." 이게 왜 중요하냐면, 다중 렌즈 리뷰 파이프라인의 각 역할이 존재하는 이유가 '고무도장'이 아니라 도전하기 위해서이기 때문이다. CEO 렌즈는 이게 정말 10점짜리 제품인지를 묻고, 엔지니어 렌즈는 아키텍처가 엣지 케이스를 버티는지를 묻고, 디자인 렌즈는 기준 자체가 있는지를 묻는다. 그 도전을 취합해 최종 판단을 내리는 건 사람이다.
팀에게 남는 설계 과제
이 두 흐름을 같이 보면 AI-First 워크플로우에서 팀이 설계해야 할 것이 구체화된다.
첫째, 비용 규율은 의지가 아니라 구조로 박아야 한다. 합리적인 결정의 합산이 비용을 만든다는 걸 인정하면, 해법은 팀원에게 '더 조심하라'고 요청하는 게 아니라 모델 라우팅 정책과 컨텍스트 관리 규칙을 시스템으로 강제하는 것이다.
둘째, 속도 이후의 병목을 미리 설계해야 한다. 에이전트가 빨라질수록 '뭘 만들지 않을 것인가', '어떤 코드를 배포하지 않을 것인가'가 팀의 실제 작업이 된다. gstack의 다중 렌즈 리뷰 구조는 솔로 빌더든 팀이든 자신에게 부재한 반론 역할을 AI로 대체하는 방법이다.
셋째, 'AI가 확신할 때'가 가장 조심할 순간이다. 두 모델이 동의하고 AI가 자신 있어 보일 때, 그 결정을 그냥 수용하고 싶은 충동이 가장 강하다. gstack은 그 순간을 리뷰 게이트로 막아둔다.
같은 레버, 다른 방향에서
비용 최적화 분석이 발견한 것과 gstack이 설계한 것은 결국 같은 레버를 다른 방향에서 잡고 있다. 메인 에이전트의 컨텍스트를 집중된 상태로 유지하고, 세부 작업은 적절한 도구와 역할에 위임하고, 최종 판단은 반드시 사람이 내린다. 비용이 낮아지는 동시에 품질이 올라가는 구조는 여기서 나온다. 에이전트가 빠를수록, 이 구조를 먼저 설계한 팀이 이긴다.