우버 CTO 프라빈 네팔리 나가는 최근 AI 코딩 도구 도입 속도가 예상보다 훨씬 빨라지면서, 애초 잡아둔 예산이 이미 맞지 않게 됐다고 말했다. 핵심은 "AI를 써서 개발 속도를 높였다"가 아니라, 그 속도가 비용 통제 체계보다 더 빨랐다는 점이다.12
이게 지금 중요한 이유는 분명하다. 많은 기업이 생성형 AI를 "개발자당 월 구독료" 수준으로 가볍게 보기 쉽지만, 실제 대규모 운영에선 사용량 기반 과금, 에이전트형 워크플로, 내부 인센티브가 겹치며 비용 구조가 완전히 달라지기 때문이다. 우버 사례는 AI 도입의 병목이 모델 성능이 아니라 FinOps와 거버넌스가 될 수 있음을 보여준다.23
문제는 도입이 아니라, 너무 잘 도입됐다는 점
확인된 사실부터 보자. 우버는 엔지니어들에게 Anthropic의 Claude Code와 Cursor 같은 도구 사용을 적극 장려했고, 내부에서 사용량 리더보드까지 운영했다는 보도가 나왔다.2 그 결과 Claude Code 사용은 급증했고, Cursor는 상대적으로 정체됐으며, 우버는 OpenAI Codex 테스트도 준비 중이다.2
여기서 읽어야 할 포인트는 단순한 "AI 열풍"이 아니다. 우버는 실험적으로 몇 팀만 써본 것이 아니라, 조직 차원에서 사용을 확산시켰다. 내부 경쟁 구조까지 붙이면 도입률은 빠르게 올라간다. 문제는 이런 방식이 생산성 확산에는 유리하지만, 비용 예측에는 불리하다는 점이다.
특히 AI 코딩 도구는 SaaS처럼 보여도 실제로는 "좌석 수 + 사용량" 성격이 강하다. 개발자가 자동완성 몇 번 쓰는 수준과, 긴 컨텍스트를 넣어 코드 생성·수정·테스트를 반복하는 에이전트형 사용은 비용 차이가 크다. 같은 1명이라도 사용 패턴에 따라 비용이 전혀 다르게 나온다. 인당 라이선스 예산만 잡아서는 틀릴 가능성이 높다.
생산성 수치는 인상적이지만, 그것만으로 ROI는 아니다
우버 내부에선 AI가 실제 코드 생산에 이미 깊게 들어온 것으로 보인다. 보도에 따르면 라이브 백엔드 코드 업데이트의 약 11%를 AI 에이전트가 작성하고 있으며, 주당 1,800건 수준의 코드 변경이 내부 AI 에이전트에서 나온다고 한다.23 또 엔지니어의 월간 AI 도구 사용률이 95%에 가깝다는 주장도 나왔다.3
이 수치들은 분명 강하다. AI 코딩이 더 이상 데모가 아니라, 운영 코드 경로에 들어왔다는 뜻이기 때문이다. 우버처럼 매칭, 가격 책정, 버그 수정 같은 실시간 서비스 기업에선 개발 속도 개선이 곧 기능 출시 속도와 운영 효율로 이어질 수 있다.
다만 여기엔 중요한 반론이 있다. "AI가 많이 쓴 코드"와 "비즈니스에 가치 있는 코드"는 같은 말이 아니다. 커밋 비중, 코드 변경 건수, 토큰 사용량은 도입률 지표일 뿐이다. 장애율, 롤백 비율, 리뷰 시간, 배포 리드타임, 온콜 부담, 고객 지표 개선까지 이어져야 ROI라고 부를 수 있다.
즉, 우버 사례는 AI가 효과 없어서 예산이 터진 것이 아니라, 효과가 있어 보이기 때문에 더 위험한 사례다. 잘 쓰이는 도구일수록 사용량이 더 빨리 늘고, 사용량 기반 비용도 더 가파르게 증가한다.
진짜 병목은 모델이 아니라 비용 구조와 인프라 선택이다
우버의 2025년 R&D 비용은 9% 늘어난 34억달러로 보도됐다.2 하지만 이 수치만으로 "AI 때문에 34억달러를 썼다"고 해석하면 안 된다. 확인된 것은 전체 R&D가 늘었고, CTO가 AI 예산 재산정이 필요하다고 말했으며, AI 도구 확산이 비용 압박 요인이라는 점이다.12 R&D 증가분 중 정확히 얼마가 AI 코딩 도구 때문인지는 공개된 정보만으로 단정하기 어렵다.
흥미로운 건 우버가 한편으로는 AWS Graviton4와 Trainium3 같은 커스텀 칩 기반 인프라도 확대하고 있다는 점이다.4 이는 같은 회사가 AI 활용을 넓히는 동시에, 다른 층위에선 비용 최적화 수단도 찾고 있다는 신호다. 다시 말해 지금 기업의 AI 전략은 "모델을 얼마나 잘 쓰느냐"만이 아니라, "어떤 가격 체계와 어떤 컴퓨팅 스택 위에서 쓰느냐"의 문제로 옮겨가고 있다.
실무적으로 보면 여기서 세 가지 판단 기준이 생긴다.
첫째, 좌석 수가 아니라 사용 패턴을 봐야 한다. 일반 보조형 사용과 에이전트형 사용은 예산 항목을 분리하는 편이 맞다.
둘째, 도입 인센티브와 비용 통제를 같이 설계해야 한다. 사용 장려만 하고 팀별 한도, 경보, 프로젝트별 비용 귀속이 없으면 예산은 거의 반드시 늦게 보인다.
셋째, 생산성 지표와 품질 지표를 같이 묶어야 한다. 코드 생성량이 아니라 배포 성과와 운영 안정성까지 연결해야 "비싸지만 worth it"인지 판단할 수 있다.
우버 사례를 과장해서도, 가볍게 봐서도 안 된다
한계도 있다. 현재 알려진 숫자 중 일부는 서로 다른 보도에서 범위와 기준이 조금씩 다르다. 예를 들어 AI가 작성한 코드 비중은 "백엔드 라이브 업데이트 11%"와 "내부 AI 에이전트 기여 8% 수준"처럼 표현 기준이 다르다.23 따라서 이 수치들을 하나의 정확한 단일 지표처럼 읽기보다, "짧은 기간 안에 AI의 실제 코드 기여도가 빠르게 커졌다"는 방향성으로 이해하는 편이 안전하다.
그럼에도 메시지는 선명하다. 우버처럼 자금 여력이 있고 엔지니어링 조직이 큰 회사도 AI 코딩 비용을 과소추정했다면, 더 작은 회사는 더 쉽게 같은 함정에 빠질 수 있다. 반대로 말하면, 지금 경쟁력은 무작정 도입 여부보다 "누가 더 빨리 비용-성과 측정 체계를 붙이느냐"에서 갈릴 가능성이 크다.
이 이슈는 CTO만 볼 일이 아니다. 엔지니어링 매니저는 팀별 사용 정책을, 재무 조직은 AI를 별도 비용 항목으로, 플랫폼 팀은 모델·벤더·클라우드 선택을 다시 봐야 한다. 앞으로 볼 지표는 간단하다. 도입률이 아니라 팀별 실제 비용, 품질 변화, 그리고 특정 벤더나 과금 구조에 대한 의존도가 얼마나 커지는지다.
참고
1Uber's AI Push Hits a Wall-CTO Says Budget Struggles Despite $3.4B Spend
3Uber CTO says AI spending plans fall short as tools like Claude Code drive costs up
4Uber scales on AWS to help power millions of daily trips and train its AI models
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.