https://www.facebook.com/seunghwan.lee.9003888/AI 코딩 에이전트, 우버도 예산이 터졌다:도입 전 반드시 알아야 할 다섯 가지2025년, 우버는 대담한 실험을 시작했다. 수천 명의 엔지니어에게 Anthropic의 클로드 코드(Claude Code)와 Cursor 같은 AI 코딩 도구를 쥐여주고, 누가 더 많이 쓰는지 내부 리더보드까지 만들어 장려했다. 결과는 어떻게 됐을까. 코드 생산성은 분명히 올라갔다. 지금 우버의 백엔드 라이브 코드 중 약 11%는 이미 AI 에이전트가 작성한 것으로 추산된다. 그런데 2026년 초, CTO 프라빈 네팔리 나가는 솔직하게 인정했다. ["몇 달 만에 AI 예산을 거의 다 써버렸다. 처음부터 다시 설계해야 할 시점이다."]2025년 R&D 지출이 전년 대비 9% 늘어 [34억 달러(약 4조 7천억 원)에 달한 우버가, AI 예산 때문에 "도면을 다시 펼쳐야 한다"고 말하는 상황]이 된 것이다. 이 사례는 단순히 우버 한 회사의 실수가 아니다. 지금 수많은 기업들이 같은 함정으로 걸어 들어가고 있다는 경고장이기도 하다.왜 이런 일이 벌어졌을까. 그리고 AI 코딩 에이전트를 도입하려는 기업이라면 무엇을 먼저 설계해야 할까. 다섯 가지 핵심을 살펴보자.첫 번째 인사이트 — "많이 쓰게 두면 망한다": 사용량 가드레일AI 도구를 회사 전체에 배포하면서 "많이 쓰면 쓸수록 좋다"는 분위기를 만드는 것은, 수도꼭지를 활짝 열어두고 수도 요금은 나중에 보겠다는 것과 같다.우버가 바로 그 실수를 했다. 사용량을 랭킹으로 시각화하고 장려했지만, "어느 작업에, 어느 모델을, 어느 수준까지 써도 되는지"에 대한 기준이 없었다. AI 코딩 에이전트는 단순 검색이나 챗봇과 다르다. 복잡한 코드 작업일수록, 그리고 자동화 루프가 길어질수록, 소비하는 토큰(AI가 처리하는 데이터 단위이자 과금 기준)의 양이 선형이 아니라 기하급수적으로 불어난다. 에이전트 하나가 코드를 쓰고, 오류가 나면 수정하고, 다시 확인하는 루프를 반복하다 보면, 사람이 직접 짜는 것보다 수십 배의 토큰이 소비되는 경우도 생긴다.이를 막으려면 처음부터 사용량 가드레일이 필요하다. 팀이나 프로젝트별로 월간 비용 상한선을 정해두고, 고성능 모델은 꼭 필요한 작업에만 쓰고 나머지는 더 저렴한 모델로 처리하는 구분이 있어야 한다. 장시간 돌아가는 자동화 작업은 별도 승인을 받도록 하는 흐름도 필요하다. "AI를 쓰자"는 구호 이전에, "어떻게 통제하며 쓸지"가 먼저여야 한다는 것이 우버가 몸으로 배운 교훈이다.두 번째 인사이트 — "한 회사에 몰빵하면 협상력이 죽는다": 벤더 믹스우버 내부에서 2025년 말 이후 가장 빠르게 확산된 코딩 도구는 Anthropic의 클로드 코드였다. 엔지니어들의 체감 만족도가 높았고, Cursor의 성장세가 둔화되는 동안 클로드 코드의 사용량은 폭발적으로 늘었다. 그런데 CTO는 다음 단계로 OpenAI의 코딩 모델까지 검토하겠다고 했다. 클로드 코드가 나쁘다는 게 아니다. 한 곳에 지나치게 집중됐을 때의 위험을 인식했기 때문이다.IT 업계에서는 이를 '벤더 락인(vendor lock-in)'이라고 부른다. 특정 회사의 도구에 너무 깊이 의존하게 되면, 그 회사가 가격을 올리거나 서비스 조건을 바꿔도 쉽게 빠져나오지 못한다. 대안 없이 협상 테이블에 앉으면 항상 을이 된다.현명한 접근은 처음부터 메인 벤더와 서브 벤더를 구분해두는 것이다. 예를 들어, 정밀도가 중요한 핵심 작업에는 성능 우선의 고가 모델을, 반복적이고 단순한 작업에는 비용 효율적인 모델을, 특정 도메인에 특화된 작업에는 그에 맞는 전문 모델을 배치하는 식이다. 이렇게 역할을 분리해두면 비용도 낮아지고, 협상력도 유지된다. 우버처럼 수천억 원을 쓴 다음에야 "너무 한 곳에 몰렸구나"를 깨닫는 것은 너무 늦다.세 번째 인사이트 — "좋은 느낌 말고 숫자로 보라": ROI 대시보드우버 사례에서 가장 흥미로운 부분은 이것이다. 엔지니어들은 AI 도구에 만족했고, 실제로 코드도 더 빨리 나왔고, 생산성이 오른 것도 사실이었다. 그런데도 예산은 터졌다. 즉, 체감 생산성과 재무 성과가 따로 논다는 것이다.이 간극이 생기는 이유는 단순하다. "잘 되는 것 같다"는 느낌만으로 의사결정을 했기 때문이다. AI 도구에 한 달에 1억 원을 쓰고 있다면, 그것이 최소 1억 원 이상의 가치를 만들어내고 있는지 숫자로 확인하는 시스템이 없었던 것이다.ROI(투자 대비 효과) 대시보드는 거창한 것이 아니다. 핵심 질문 몇 가지에 답할 수 있으면 된다. 같은 기능을 개발하는 데 AI 도입 전후로 시간이 얼마나 달라졌는가. 버그나 장애는 늘었는가, 줄었는가. AI 비용을 포함했을 때 기능 하나를 만드는 데 드는 실제 비용은 얼마인가. 그리고 AI 없이는 아예 시도하지 못했을 새로운 기능이 몇 개나 나왔는가. 이 네 가지만 팀 단위로 주기적으로 확인해도, "지금 우리가 AI에 쓰는 돈이 가치를 만들어내고 있는가"를 구체적으로 볼 수 있다. 우버의 예산 과소비는 결국 이 시스템이 없었다는 방증이기도 하다.네 번째 인사이트 — "에이전트만 얹으면 실패한다": 워크플로 재설계AI 코딩 에이전트 도입 실패 사례들을 보면 공통된 패턴이 하나 있다. 기존 업무 방식은 그대로 두고, 그 위에 AI 도구만 얹는다는 것이다. 이건 마치 도로 체계는 그대로인데 차량 수만 열 배로 늘리는 것과 같다. 속도는 빨라지지 않고, 혼잡만 생긴다.코딩 에이전트가 코드를 빠르게 만들어낸다고 해서, 그것이 바로 배포까지 이어지는 것은 아니다. AI가 쓴 코드도 사람이 검토해야 하고, 승인 절차를 거쳐야 하고, 보안 검사를 통과해야 한다. 그런데 기존의 검토·승인 체계가 AI의 속도를 감당할 수 있도록 설계되어 있지 않으면, 앞단에서 빨라진 것이 뒷단에서 막혀버린다.그래서 워크플로 재설계는 선택이 아니라 필수다. AI가 자동으로 처리할 수 있는 영역과, 반드시 사람이 직접 확인해야 하는 영역을 명확히 나눠야 한다. AI가 올린 코드에 대한 리뷰 기준도 새로 정해야 한다. 그리고 AI가 만든 코드로 인해 문제가 생겼을 때 누가 책임지는지, 어떻게 에스컬레이션되는지도 미리 설계해야 한다. "나중에 붙이면 된다"는 생각이 통하지 않는 게, AI의 사용량이 이미 폭발한 뒤에 체계를 만들려면 이미 잃은 게 너무 많기 때문이다.다섯 번째 인사이트 — "AI는 비용 절감 기계가 아니다": 조직 전략과 거버넌스마지막이자 가장 근본적인 교훈이다. 많은 기업들이 AI 도구를 도입하면 비용이 줄어들 것이라는 기대를 가진다. 하지만 우버의 사례는 반대를 보여준다. AI는 비용을 자동으로 줄여주는 스위치가 아니라, 조직 구조와 업무 방식과 벤더 전략을 함께 바꿔야만 이득이 나는 도구다.실패하는 기업들의 공통점은 세 가지다. 첫째, AI 도입 목표가 "일단 써보자" 수준에 머문다. 둘째, 각 팀이 제각각 다른 도구를 쓰고, 회사 전체를 아우르는 전략이 없다. 셋째, AI가 만든 결과물을 어디까지 믿을 수 있는지, 문제가 생기면 누가 책임지는지가 모호하다. 이 세 가지가 맞물리면 비용만 늘고, 생산성은 제자리를 맴돈다.우버는 흑자 체질로 돌아선 것을 자랑하던 회사가 AI 투자로 다시 비용이 불어났다고 솔직하게 인정했다. 이건 "AI를 쓰지 말아야 한다"는 이야기가 아니다. 사용량 가드레일, 벤더 믹스, ROI 대시보드, 워크플로 재설계, 그리고 조직 전략과 거버넌스, 이 다섯 가지를 함께 설계하지 않고 도구만 먼저 깔면 AI는 생산성 도구가 아니라 비용 폭탄이 된다는 것이다.마치며AI 코딩 에이전트가 실제 엔터프라이즈 현장에서 쓸 만한 수준에 올라온 것은 사실이다. 우버 엔지니어들이 클로드 코드를 자발적으로 많이 쓴다는 것이 그 증거다. 그러나 "좋은 도구를 쥐여주는 것"과 "그 도구로 실제 비즈니스 가치를 만드는 것" 사이에는 여전히 넓은 설계의 공백이 있다.우버의 사례는 그 공백을 가장 비싼 방법으로 배운 이야기다. 다른 기업들이 같은 수업료를 낼 필요는 없다.