하루에 $788. 청구서를 받고 나서야 문제를 인식했다는 dev.to의 한 개발자 경험담은, AI 코딩 에이전트를 팀에 도입할 때 가장 먼저 마주치는 현실을 압축적으로 보여준다. 에이전트는 조용히 돌아가고, 비용은 조용히 쌓인다. 그리고 109개 에이전트를 동원한 코드 감사 실험과 GitHub Copilot의 추적 논란까지 합치면, 세 가지 설계 결함이 반복적으로 등장한다. 라우팅 전략 없는 비용 구조, 검증 순서가 뒤집힌 워크플로우, 그리고 감사 추적이 빠진 거버넌스.
첫 번째: 라우팅 없이 에이전트를 켜면 비용이 폭발한다
$788 청구서의 구조는 단순하다. 3,572번의 API 호출 중 78%의 비용이 플래그십 모델 하나에서 나왔다. 반면 Haiku는 242번 호출에 $1.70을 썼다. 호출당 단가 차이가 약 360배인데, 거의 모든 작업을 비싼 모델로 라우팅하고 있었던 것이다. 파일 편집, 분류, 보일러플레이트 생성 같은 작업은 저렴한 모델로도 충분히 처리된다.
캐시도 변수다. 해당 사례에서 캐시 읽기 토큰이 700M에 달했는데, 캐시가 작동했기 때문에 $788로 끝났다. 캐시를 깨는 요소—타임스탬프 변경, 툴 목록 순서 변경, 프록시의 프롬프트 정규화—가 하나라도 끼어들면 같은 작업이 10배 비용으로 재청구된다. 에이전트를 팀에 풀기 전에 설계해야 할 것은 간단하다: 기본값은 저렴한 모델, 어려운 작업에만 플래그십으로 에스컬레이션, 키별 예산 캡, 프롬프트 프리픽스의 바이트 안정성 유지. 이게 AI 게이트웨이가 하는 일이고, 이 레이어 없이 에이전트를 켜는 건 수도꼭지 없이 수도관을 연결하는 것과 같다.
두 번째: 검증 순서가 잘못되면 비용의 70%가 낭비된다
109개 에이전트를 동원해 약 5,000줄 코드베이스를 감사한 실험(dev.to)은 더 구체적인 실패 지점을 보여준다. 9.3M 토큰, 약 $46의 API 비용 중 3분의 2 이상이 낭비됐다. 핵심 원인은 검증을 랭킹보다 먼저 수행한 것이다. 109개 에이전트 중 86개(79%)가 검증 단계에 투입됐는데, 이 단계에서 실제로 탈락시킨 발견은 34개 중 2개뿐이었다. 결국 코드를 86번 다시 읽는 비용을 지불하고 6%의 히트율을 얻은 셈이다.
올바른 순서는 이렇다: 탐색 → 중복 제거 → 랭킹 → 상위 12~15개만 검증 → 종합. 같은 결과물, 70% 적은 에이전트. 추가로 놓친 최적화들도 눈에 띈다. JSON.stringify(x, null, 2)의 예쁜 출력 포맷팅이 모든 하위 프롬프트를 30~40% 불렸고, 9개의 매핑 에이전트는 탐색 에이전트가 어차피 코드를 다시 읽기 때문에 이중 과세였다. 멀티 에이전트 워크플로우를 설계할 때 '어디서 넓게 펼칠 것인가'만큼 '어디서 수렴할 것인가'를 먼저 정해야 한다는 교훈이다.
세 번째: "Co-authored-by: Copilot"은 감사 추적이 아니다
2026년 4월, Microsoft는 VS Code 1.117에서 Co-authored-by: Copilot 트레일러를 모든 커밋에 기본값으로 추가했다. 개발자들이 며칠 만에 문제를 발견했다. AI 기능이 비활성화된 상태에서도, 모든 코드를 직접 작성했을 때도 트레일러가 붙었다. VS Code 1.119에서 기본값이 원복되고 동의 절차가 추가됐지만, 이 사건이 드러낸 거버넌스 공백은 그대로 남아있다.
git 트레일러가 알려주는 것은 딱 하나다: 이 커밋 작업 어딘가에 Copilot이라는 도구가 열려 있었다. 어떤 모델이 어떤 줄을 생성했는지, 프롬프트가 무엇이었는지, 인증 경로나 SQL 생성에 AI 코드가 닿았는지—아무것도 알 수 없다. 6개월 후 보안 감사에서 "이 함수의 어떤 부분이 AI 생성이고, 어떤 프롬프트로, 어떤 모델이 썼냐"는 질문을 받는다면 git 트레일러로는 답할 수 없다.
LineageLens 같은 도구가 제시하는 방향은 '커밋 시점 라벨링'이 아닌 '삽입 시점 프로버넌스'다. 어떤 모델이, 어떤 프롬프트로, 언제, 어떤 코드를 삽입했는지를 텍스트가 에디터 버퍼에 들어오는 순간 기록한다. 커밋 시점에는 이미 증거가 사라진다—프롬프트 본문은 어디에도 저장되지 않고, 모델명은 HTTP 응답 헤더에 있었으며, 응답 바디는 처리 후 폐기된다. 라벨은 사후 귀속이지만, 프로버넌스는 라벨이 붙기 전에 이미 존재하는 증거 체인이다.
테크 리드가 지금 당장 결정해야 할 것
세 가지 사례는 각각 다른 문제처럼 보이지만, 공통 원인은 하나다. 에이전트를 '켜는' 결정과 '어떻게 운영할 것인가'를 설계하는 결정이 분리되지 않았다. 모델 라우팅 레이어 없이 에이전트를 켜면 비용이 폭발하고, 워크플로우 순서 설계 없이 멀티 에이전트를 돌리면 비용의 70%가 낭비되며, 거버넌스 구조 없이 AI 코드를 커밋하면 감사 요청에 답할 수 없다.
실행 체크리스트는 간단하다. ① 모델 라우팅 정책 먼저—기본 모델을 저렴한 것으로 설정하고, 에스컬레이션 트리거를 명시하고, 예산 캡을 건다. ② 워크플로우 순서 설계—멀티 에이전트를 쓴다면 탐색은 넓게, 검증은 랭킹 이후 상위 항목에만 집중한다. ③ 삽입 시점 추적 구조—EU AI Act 조항 11·12의 컴플라이언스 윈도우가 2026년 8월에 열린다. "어떤 모델이 이 코드를 썼냐"는 질문이 감사 현장에서 일상이 되기 전에, 커밋 라벨이 아닌 실제 프로버넌스 기록 체계를 갖춰야 한다.
에이전트는 충분히 강력하다. 문제는 항상 그것을 둘러싼 운영 구조다. $788 청구서를 받고 나서 라우팅을 설계한 개발자는 같은 워크로드를 이후 수십 달러대로 처리했다고 밝혔다. 팀에 에이전트를 풀기 전, 이 세 가지를 먼저 설계하는 것이 테크 리드의 일이다.