우버가 1년치 AI 예산을 4개월 만에 날렸다. 원인은 모델이 아니었다. 사내 리더보드에서 불붙은 경쟁 심리가 엔지니어들을 '토큰맥싱(Tokenmaxxing)'—토큰을 최대한 많이 소비하는 행위—으로 몰아갔고, 결국 엔지니어 1인당 월 API 비용이 2,000달러까지 치솟았다. 우버 COO 앤드류 맥도널드가 뒤늦게 인정했듯, 팀은 생성형 AI 과금 구조를 기존 SaaS 고정 구독료처럼 오해했다. 에이전트는 일반 챗봇보다 토큰을 최대 30배 더 소비하는데, 그걸 제어할 장치가 전혀 없었다.
더 뼈아픈 건 ROI다. 전체 코드의 72%가 AI가 자율 생성했지만, 앱 마진이나 매출에 측정 가능한 영향은 없었다. 맥도널드 COO의 반문이 날카롭다. "코드 커밋의 25%가 AI로 이루어졌다고요? 그래서 소비자에게 유용한 기능을 25% 더 생산했나요?" 속도 지표와 비즈니스 성과 사이의 단절—이것이 AI-First 도입 팀이 가장 먼저 직면하는 진짜 문제다.
우버가 결국 꺼내든 해결책은 인당 월 1,500달러 상한선과 사용 대시보드였다. 이건 뒤늦게 빗장을 거는 것이다. 예산이 이미 소진된 뒤의 제한은 통제가 아니라 사후 수습이다. 같은 실수를 반복하지 않으려면 질문이 달라져야 한다. "얼마나 쓸 수 있나"가 아니라 "어떤 구조로 쓸 것인가"부터 설계해야 한다.
dev.to에 게재된 TypeScript 에이전트 비용 추적 사례는 그 설계가 코드 수준에서 어떻게 구현되는지를 보여준다. 핵심 아이디어는 세 가지다. 첫째, 모든 에이전트 단계에 이름을 붙인다—익명 실행은 비용 가시성의 적이다. 둘째, 모든 LLM 호출에서 토큰 수, 모델명, 목적, 추정 비용을 메타데이터로 캡처한다. 셋째, 전체 실행을 플랫 로그가 아닌 트리 구조로 추적해 어느 에이전트의 어느 단계에서 비용이 발생했는지를 역추적할 수 있게 한다. 라우팅 한 번, 신뢰도 검증 한 번, 재시도 한 번—이 작은 결정들이 쌓여 청구서를 만든다. 보이지 않으면 최적화할 수 없다.
비용 통제보다 한 단계 더 나아간 문제가 배포 거버넌스다. AI 에이전트를 운영하는 한 개발자는 dev.to에서 에이전트가 코드를 쓸 수 있지만 프로덕션에 배포하지는 못하도록 아키텍처를 설계한 이유를 설명했다. 그의 핵심 개념은 '리스크 비대칭성(risk asymmetry)'이다. 잘못된 파일 쓰기는 다음 리뷰 사이클에서 잡힌다. 잘못된 프로덕션 배포는 실행되는 순간 라이브다. 같은 실패 모드가 아닌데 같은 접근 권한을 줄 이유가 없다.
그가 구현한 구조는 단순하다. 에이전트는 배포 가능한 작업을 완료하면 단일 스크립트(request-deploy.mjs)를 호출하는 것으로 역할이 끝난다. 실제 배포 토큰을 쥔 별도 프로세스 'Librarian'이 15분 주기로 충돌 검사, 사전 검증을 거쳐 배포를 실행한다. 에이전트는 Librarian과 직접 상호작용하지 않는다. "긴급하다"는 이유로 게이트를 우회할 수도 없다. 이 분리는 마찰을 만들기 위한 게 아니다. 빌드하는 것과 배포하는 것을 구조적으로 분리해 책임 소재를 명확히 하는 것이다. 감사 추적이 읽히려면 아키텍처가 먼저 그렇게 설계되어야 한다.
두 사례를 연결하면 하나의 패턴이 보인다. 우버의 실패는 '측정 없는 허용'이었고, 에이전트 배포 게이트는 '권한 없는 실행 차단'이다. 둘 다 사후 정책이 아니라 사전 아키텍처 결정이다. AI-First 팀이 진짜 설계해야 할 것은 어떤 도구를 쓸지가 아니다. 어떤 실행에 어떤 가시성을 부여하고, 어떤 행위에 어떤 게이트를 놓을지다.
실용적인 출발점 세 가지를 정리하면 이렇다. 첫째, 모든 LLM 호출을 명명된 스텝으로 감싸고 토큰과 비용을 실시간 기록한다—측정 없이는 통제도 없다. 둘째, 에이전트의 실행 범위를 명시적으로 정의한다—쓸 수 있는 것과 없는 것을 코드 수준에서 분리한다. 셋째, 프로덕션 배포 권한은 별도 프로세스로 격리하고 에이전트가 직접 쥐지 않도록 한다. 리더보드를 만들기 전에, 한도를 설정하기 전에, 이 세 가지 구조가 먼저 있어야 한다. 빗장은 설계 실패의 증거다.