▲

Uber, Claude Code에 2026년 AI 예산을 4개월 만에 모두 태움

 (briefs.co)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • Uber는 Claude Code와 Cursor 사용 확대로 2026년 AI 예산 전체를 4개월 만에 소진했고, 생산성 실험이 곧바로 예산 재검토 문제로 이어짐
  • Uber CTO는 엔지니어 1인당 월간 API 비용이 500~2,000달러 수준이었다고 밝혔고, 엔지니어의 95% 가 매월 AI 도구를 사용 중임
  • Uber에서 커밋된 코드의 70% 가 AI에서 비롯됐으며, AI 코딩 도구가 엔지니어링 업무의 핵심 흐름으로 들어왔음
  • Claude Code는 2025년 12월 엔지니어링 팀에 배포된 뒤 다단계 작업 역량이 확인되며 2026년 2월까지 사용량이 두 배로 늘었고, 4월에는 연간 예산을 모두 소진함
  • Cursor 사용량 증가는 정체된 반면 Claude Code가 지배적 도구가 됐고, Uber는 연간 R&D 지출 34억 달러 안에서 AI 코딩 도구 비용을 다시 계산해야 하는 상황이 됨

도입 확대와 예산 재검토

  • Uber는 Claude Code와 Cursor 사용이 빠르게 늘면서 비용 급증에도 엔지니어들이 사용을 멈추기 어려울 만큼 두 도구의 가치를 크게 보게 됨
  • 2025년 12월 Claude Code 접근 권한이 엔지니어링 팀에 배포됐고, 다단계 작업 역량이 확인되면서 2026년 2월까지 사용량이 두 배로 늘어남
  • 2026년 4월 비용이 연간 AI 예산 전체를 소진하면서, 리더십은 예상하지 못한 결정을 내려야 하는 상황이 됨
  • Uber CTO는 회사가 AI 예산 편성을 “back to the drawing board”로 되돌렸다고 밝힘

도구별 사용 변화

  • Cursor는 채택 경쟁에 나선 또 다른 주요 도구였지만 사용량 증가가 정체됨
  • Claude Code는 엔지니어링 워크플로에서 지배적인 도구가 됨
  • 생산성 실험으로 시작된 도입이 빠르게 확대되면서 회사 내부 엔지니어링 업무에서 AI 도구 사용이 본격화됨

비용 압박의 의미

  • Uber의 예상 밖 예산 소진은 AI 도구가 엔지니어링 생산성에 얼마나 가치 있게 받아들여지는지를 보여줌
  • 접근을 제한하는 것이 오히려 비생산적으로 느껴질 정도로 AI 도구의 역할이 커진 상태임
  • 더 많은 개발자가 Claude Code를 채택하면서 다른 회사들도 비슷한 영향을 겪고 있을 가능성이 있음
  • 소프트웨어 회사들은 개발 속도를 유지하면서 비용을 관리해야 하는 압박을 받게 됨
  • 개발자 생산성 도구가 너무 가치 있게 쓰여 엔지니어들이 4개월 만에 전체 예산을 소진했다면, 문제는 도구 자체가 아니라 예산이 채택 곡선을 예측하기에는 너무 이르게 만들어졌다는 결론으로 이어짐

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 회사의 지출을 한 달에 한 번쯤 들여다보면, 점점 더 많은 사람이 월 $1k 토큰 비용을 쓰고 있어서 도대체 어떻게 가능한지 혼란스러움
    LLM을 매일 쓰고, 가장 비싼 모델에 깊은 사고 모드까지 써도 보통 $200~$400이 상한임. 사용 자체를 반대하는 러다이트가 아니라, 책임 있게 월 그만큼을 태우는 방법을 이해하기 어렵다는 뜻임. 월 $5k~$10k를 쓰는 사람이 그게 어떻게 $50k~$100k 가치로 바뀌는지 보여줬으면 함. 회사 입장에서는 연 $100k 토큰 지출을 합리화하기보다, $100~$200/월을 쓰면서 생산성을 내는 주니어 엔지니어를 뽑는 편이 낫다고 봄

    • 책임 있게 돈을 그렇게 태우는 경우는 대체로 세 가지로 보임. 초급자는 긴 대화 재사용 때문에 맥락 압축이나 요약 체크포인트를 안 만들고, 에이전트가 “교육됐다”고 느끼는 거대한 단일 대화를 계속 끌고 감
      중급자는 “하위 에이전트 5개를 띄워 서로 다른 각도에서 해법을 분석하고 요약하라” 같은 패턴을 알게 된 뒤 중독되기 쉬움. 자체가 나쁜 습관은 아니지만 조심하지 않으면 크레딧을 크게 초과함. 숙련자는 10개 작업 트리를 계속 병렬로 돌리고 에이전트 응답 사이를 오가며 극단적으로 멀티태스킹해서 비용이 기하급수적으로 늘 수 있음
    • 첫째로 “회사가 허용하면 낭비한다”는 뻔한 이유가 있음. 맥락을 자주 비우거나 압축하지 않는 것도 포함됨. Opus의 1M 맥락 창은 이제 있고, 200K까지는 품질도 괜찮아서 비우기 전까지 질의마다 토큰을 많이 태움
      코드베이스가 크거나 복잡한 문제도 큼. 팀에 새로 와서 모르는 부분이 많으면, 작업을 받았을 때 Claude에게 관련 코드를 찾게 하고 기존 흐름을 이해한 뒤에야 변경을 시도하게 됨. 전문성은 덜 쌓이지만, Claude로 5일 걸릴 일을 1일에 끝낼 수 있고 모두가 그렇게 하면 뒤처질 수 없음. 그래서 1일 대신 2~3일에 끝내며 코드도 조금 보려는 중간 경로를 택함. 특히 AI 때문에 코드 변경 속도가 엄청나서, 풀 리퀘스트를 LLM에 깊게 설명시키는 도구도 만들었음. 리뷰어는 아니고 팀 작업을 따라가기 위한 용도임. 아직 LLM 활용법을 더 고민하지도 않았고, 코드베이스에 익숙했다면 훨씬 더 많이 썼을 것 같음. 병목은 여전히 적절한 테스트와 리뷰임. 덜 중요한 사내 코드나 개인 코드는 대부분 거의 전부 AI에게 맡기는 것 같고, “superpowers” 스킬을 쓰면 기본 기능에도 토큰을 많이 태움. 보통 20~40K 토큰에서 시작해 끝날 때 80~90K 토큰까지 가니, 완료 직전 여러 요청은 거의 80K 토큰을 보내는 셈임. 낭비지만 남이 내면 그렇게 됨
    • Claude Code가 문제에 대해 말도 안 되게 토큰 비효율적인 해법을 고르는 예를 봤음. 복잡한 머신러닝/예측 문제를 여러 에이전트에 나눠 맡겼고, 각 에이전트가 Jupyter 노트북을 쓰고 실행하고 읽었음
      처음엔 괜찮았지만, 한 에이전트가 셀 출력에 수십만 행을 써서 500MB ipynb 파일을 만들었고 Claude가 그걸 여러 번 읽으려 하면서 맥락 한도를 전부 써버림. 해결책은 CLI 분석 스크립트와 연구 결과 저장 폴더로 더 나은 작업 구조를 정하는 것이었지만, 운영자인 내가 계획과 설계를 해야 했음. 월 $10k 토큰을 쓰는 사람들은 Claude Code라는 비싼 망치로 문제를 게으르게 손 놓고 풀고 있다고밖에 보기 어려움. 예를 들어 매일 Claude가 모든 이메일을 읽게 하는 식인데, 더 똑똑한 해법은 먼저 이메일 본문 HTML에서 잡음을 제거하는 것임
    • 작업 중인 저장소에 정말 좌우됨. 아주 크고, 특히 도구가 많은 커스텀 프레임워크와 API 문서를 참조해야 하면 큰 맥락 창이 필요해져 토큰이 훨씬 빨리 소모됨
      반대로 작거나 모델이 학습한 일반적인 프레임워크를 쓰면 더 작은 맥락 창으로도 많은 일을 해내고 토큰 사용량도 훨씬 낮아짐
    • 비용보다 쿼터 쪽에서도 비슷하게 이해가 안 됨. 200유로짜리 ChatGPT 요금제라 아마 최고 쿼터일 텐데, 가장 비싼 모델과 최고 추론, 빠른 모드로 하루 종일 거의 에이전트 프로그래밍만 해도 한도에 근접하지 않음
      코딩 에이전트를 쓰기 시작한 뒤 한도에 가까웠던 건, 같은 조건으로 크로스플랫폼 개발을 컴퓨터 3대에서 동시에 했을 때뿐이고 그때도 주간 한도에 거의 닿은 정도였음. 보통은 한도의 약 20%까지 내려가지만 그보다 낮아지는 일은 거의 없음. 재미로 프롬프트와 질의를 많이 던지고 있는데도 더 쓰는 방법을 모르겠음

  • 지금 AI에게 답하고 있는 건 알지만, “회사가 이 수준의 생산성을 규모 있게 감당할 수 있는지 파악한다”는 말은 이상함. 실제로 생산적이라면 매출이 늘 테고, 감당 가능 여부가 문제가 되지 않을 것임

    • 맞음. 생산성은 정의상 무언가, 가능하면 가치 있는 것을 만들어냄. 챗봇에 드는 추가 비용이 그만한 가치가 있는지 봐야 함. Uber가 이 엄청난 예산 초과 덕분에 극적으로 더 효율적이고 효과적이 됐는지, 아니면 같은 일을 옮겨 담는 반짝이고 비싼 방법을 사람들에게 준 것뿐인지 의문임
    • 매출은 늘었음. Meta의 최근 실적을 보면 이 경제 상황에서도 매출 +33% 임. 감당 가능 여부는 문제가 아니고, Meta 같은 회사가 엔지니어가 토큰에 하루 $1k를 써도 신경 쓰지 않는 이유가 있음. 직원 1인당 벌어들이는 돈에 비하면 그렇게 큰돈이 아님
    • 개발자가 만드는 모든 변경이 매출을 늘리지는 않고, 매출을 늘리는 변경도 대개 시차가 있음
    • 상대편 논리를 최대한 좋게 보면, 경쟁사도 같은 도구를 써서 같은 생산성 향상을 얻는 경우가 반례가 될 수 있음
    • 제대로 쓰면 정말 극도로 생산적임. 내년에는 이런 유사 AI 모델들이 얼마나 영리해질지 걱정될 정도임

  • “Uber 엔지니어의 95%가 이제 매월 AI 도구를 쓰고, 커밋된 코드의 70%가 AI에서 나온다”는 건 예상 가능한 일임. AI 도구 사용이 성과 평가에 반영되면 그렇게 됨

    • 비개발자가 개발자에게 KPI를 강요할 때 이게 얼마나 쉽게 게임화되는지 과소평가하는 수준이 놀라움. AI든 풀 리퀘스트/라인 수 세기든 마찬가지임
    • KPI가 “무엇을 출시했나”가 아니라 “AI를 얼마나 썼나”가 되는 순간 예산 폭주는 자연스럽게 따라옴. 사람들은 숫자를 맞추려 할 것임
    • 매니저와 부사장들이 모두 “AI를 쓰지 않으면 여기서 일하지 못한다”고 말하면, 당연히 사람들은 쓰게 됨
    • 이 비판이 잘 이해되지 않음. 원래 회사가 원하고 회사가 생산적이라고 생각하는 일을 해서 돈을 받는 게 아니었나 싶음. 그리고 AI 생성 코드가 전부 쓸모없다고 보는지도 의문임

  • “회사가 이 수준의 생산성을 규모 있게 감당할 수 있는지 파악한다”는 부분이 이해가 안 됨. 예산을 썼고 4개월치 데이터가 있는데, 보여줄 결과가 무엇인지가 핵심임
    AI 혐오자도 러다이트도 아니고, $200 Max 요금제를 쓰고 있음. 그런데 Uber가 이 도구를 열어주고 모두에게 쓰라고 권장한 뒤, 그게 잘 작동하자 무슨 일이 벌어졌는지 혼란스러워한다는 말인가? AI가 비용 대비 생산성이 충분하지 않다고 판단하는 건 별개임. 혹시 다음에 만들 것이 바닥난 건가 싶음

    • 개인용 Max와 Teams 요금제는 Enterprise의 API 종량제 비용에 비하면 정말 놀라운 특가임. Enterprise 기능이 꼭 필요했나 봄. 아니면 사용자들에게 $200 Max 구독을 비용 처리하라고 하면 됐을 것임. 기업은 결국 기업답게 행동함
    • 지금 보이는 것은 없을 가능성이 큼. 외부 사용자에게 드러나는 큰 변경은 넓게 배포되기까지 훨씬 오래 걸리기 때문임. 내부적으로는 여러 기능이 더 빨리 진행됐을 것임
      Salesforce에서도 몇 주 걸리던 일이 며칠 걸리는 것처럼 보이는 변화를 봤음. 이것이 곧바로 돈으로 바뀌지는 않지만, 돈을 벌 잠재력은 늘려줌
    • Uber가 다음에 만들 게 무엇인지도 질문할 만함. 승차 호출 플랫폼은 있고 작동함. 음식, 식료품, “차에 들어가는 무엇이든” 배달로도 확장했음. 누군가 차를 운전하는 영역에서 더 무엇이 남았는지 모르겠음
    • 지출 통제 수단이 좋은데 왜 상한을 안 걸었는지 이해가 안 됨. 엔지니어에게 그 지출을 정당화하라고 요구할 수도 있었음
      왜 그렇게 많은 토큰을 써야 하는지, 그 대가로 무엇을 얻는지 물어야 함. 이게 AWS였다면 모두가 “월 지출 안 봤냐”고 손가락질했을 것임
    • AI 논의가 이제 어떤 비판이라도 이단 취급을 피하려면 “나도 교단의 일원이고 불신자는 아니지만”이라고 먼저 말해야 하는 단계에 온 것 같음

  • 이런 글이 나오면 갑자기 개발 생산성 측정이 단순하다고 생각하는 사람이 많아지는 게 흥미로움. 생산성이 매출이나 비용 절감으로 이어지고 매출은 측정 가능하다는 건 맞지만, 그렇게 간단하지 않음
    오늘 돈을 써서 미래 매출을 만드는 기능을 만들기 때문에, 오늘 비용이 급증해도 아직 측정할 매출은 없음. AI로 기능을 오늘 끝냈다고 해서 바로 AI가 생산적/비생산적이라고 말할 수 없고, AI 없이 무엇을 얼마나 했을지와 그때 매출을 추정해야 함. 비즈니스는 흔히 붉은 여왕의 경주라서 개선하지 않으면 경쟁사에 밀려 매출을 잃기도 함. AI 사용은 중요한 일과 “이제 쉬우니까 이것저것 던져보는 일”이 섞였을 가능성이 높고, 실제 생산성 개선을 측정하려면 전자는 남기고 후자는 피하는 법을 알아야 함. AI 찬반이 아니라, “생산적이면 측정 가능할 것”이라고 게으르게 말하지 말자는 뜻임

    • 주된 합의는 오히려 개발자 생산성 측정이 매우 어렵다는 쪽이라고 봄. 측정을 시도할 때마다 그 측정치가 곧 목표가 되어버려, 설령 원래 견고한 측정이었다 해도 무의미해짐
      공장 노동자가 아닌 사람의 생산성을 측정하는 게 쉽다는 생각을 어디서 얻었는지 모르겠음
    • 새 기능이나 더 나은 소프트웨어가 Uber의 매출/이익을 크게 늘리지는 않을 것 같음
    • 선택지가 생산성 0과 생산성 일부만 있는 게 아니라, 음수 생산성일 수도 있음. Claude Code를 써본 경험상 조직에 그렇게 많은 토큰을 쏟아붓는 건 비생산적일 뿐 아니라 적극적으로 해로울 수 있어서 의심하는 것임
    • 작은 생산성 변화는 측정하기 어렵지만, 큰 도약은 명확히 보였을 것임. AI가 생산성에 영향을 주고 있다면 기껏해야 작은 정도로 보임
    • 10배 생산성이라면 간접적으로라도 측정 가능했을 것이고, 오히려 측정을 피할 수 없었을 것임. 초기 주장들은 명백히 거짓이었고, 실제 연구 질문은 1.0배보다 큰가임
      그건 측정하기 매우 어렵다는 데 동의함. 하지만 이 비용을 생각하면 반드시 답할 수 있어야 하고, 배수도 비용을 정당화해야 함

  • [1]에 따르면 Uber 엔지니어링 조직은 약 5,500명임. 지출 범위의 중간값을 $1,250으로 잡으면 엔지니어링 AI 지출은 대략 $6.8M이고, 범위는 $2.75M~$12M임. 글에는 R&D 지출이 $3.4B로 나옴
    AI 지출은 R&D 지출에서 큰 비중은 아님. 4개월 기준 0.3%, 연환산 1% 정도임. 계획하지 않았다면 예산에서 푼돈은 아니지만, 맥락상 아주 크지는 않음. 진짜 질문은 그 금액으로 무엇을 얻었느냐임. 글은 코드 커밋의 70%가 AI 생성이라고 주장하니, 아마 리뷰와 테스트를 통과했을 것임. 기능 수가 빨라졌는지, 품질 문제가 줄었는지, 다른 이점이 있었는지가 중요함. 아쉽게도 글은 지출 증가 외의 결과를 말하지 않음. 4개월은 이점을 평가하기에 너무 이른지도 모름. 반면 애자일 세계라면 또 다를 수 있음. [1] https://www.unifygtm.com/insights-headcount/uber

    • 실제 출처 https://www.theinformation.com/newsletters/applied-ai/uber-c...에는 “백엔드 시스템의 실제 라이브 코드 업데이트 중 약 11% 가 주로 Claude Code로 만든 AI 에이전트에 의해 작성되고 있으며, 3개월 전에는 1% 미만의 일부였다”고 되어 있음
      또 “회사의 소프트웨어 예산이나 AI 코딩 도구 지출의 정확한 수치는 공개하지 않았다”고 함
    • 이 글의 모든 것은 순전히 가짜처럼 보임. 숫자가 맞지 않고, 보고된 정보와도 맞지 않으며, 그냥 허구임

  • 부트스트랩하는 입장에서 대기업 엔지니어가 부러울 때가 많지만, 인센티브가 망가졌다는 걱정도 듦
    내가 Uber 엔지니어라면 작은 변경에도 gpt 5.5 pro @ very high thinking + fast mode를 프롬프트에 쓰지 않을 이유가 없음. 가장 강력하고 따라서 가장 비싼 모델을 쓰지 않을 유인이 없음. 이미지→HTML 변환 테스트로 이런 프롬프트 하나를 써봤더니 단일 프롬프트가 $40 들었음. 직접 내는 사람이라면 거의 절대 이 설정을 안 쓰겠지만, 대기업에서 남이 비용을 내주면 자주 돌릴 것임. 출력은 확실히 더 좋았음. 엔지니어는 무엇을 전달했는지로 평가받지, 그 과정의 비용으로 평가받지 않음. 싸게 하는 방법은 있지만 엔지니어에게 그렇게 할 유인이 없음

    • 소프트웨어 엔지니어는 비쌈. 중위 연봉이 $133k이고 건강보험, 급여세 등은 빠져 있음. $40 LLM 크레딧으로 개발 시간 1시간을 줄일 수 있다면, 안 쓰는 것보다 $26.50 싸다는 계산이 나옴
      실제로 그렇게 되는지는 아직 확신하지 못하지만 이론은 그렇다는 뜻임. LLM 비용을 낮추려는 것도 양날의 검임. 개발자가 줄인 LLM 비용이 그 사람에게 지급하는 비용보다 커야 하기 때문임. 하루를 들여 호출당 $1을 줄이면 급여 비용 회수에 거의 2년이 걸림. 게다가 LLM은 너무 빨리 바뀌어서 그 해법이 2년 안에 깨지지 않을 거라고 확신하기 어려움. 2년 뒤에도 도구 호출을 할지, 추론 모드가 남아 있을지, 최전선 제공자도 모를 것임
    • 회사는 먼저 작업을 얼마나 빠르게 확장할 수 있는지 보고, 이후 효율을 위해 줄이고 싶어 할 수 있음
    • 이미지→HTML은 꽤 복잡한 작업임. 사실상 프론트엔드 개발자의 일이고, $40로는 그들의 1시간도 못 삼

  • 경영진이 소프트웨어 엔지니어링을 에이전트로 대체할 수 있다고 생각하는 일이 흔해질수록, 평균 소프트웨어 엔지니어에 대한 비현실적인 인식에 기반해 결정하는 건 아닌지 궁금함
    한편으로는 넣는 만큼 나온다는 면이 있음. 영리한 CTO는 에이전트로 할 수 있는 일에 매우 흥분하고, 모든 엔지니어도 같은 일을 할 수 있다고 착각할 수 있음. 실제로는 조직의 평균 엔지니어가 어디서 일을 줄일 수 있는지 떠올릴 창의성조차 없을 수 있음. 그래서 에이전트 사용을 의무화하면 생산성은 안 늘고 AI 비용만 증가할 수 있음. 다른 한편으로 AI를 쓰면 두 가지 간극이 더 선명해짐. 누가 에이전트에게 무엇을 하라고 말할 것인가, 그리고 QA/리뷰 주기를 어떻게 감당할 것인가임. 많은 조직에서 제품 담당자는 LLM이 사용할 상세 명세나 계획을 만들 만큼 기술적으로 밝지 않고, 기계의 톱니 같은 개발자는 명세를 만들 위치가 아니라 구현만 하고 싶어 함. 에이전트를 쓰는 개발자가 구현할 거라고 기대하면, 오히려 일이 오기만 기다리는 유휴 인력이 늘 수 있음. 기존 개발자의 속도와 품질을 높이는 선택적 LLM 도입은 찬성하지만, “조직을 재구성하자”는 흐름은 특히 중소 규모 회사에 꽤 위험함

    • 그 이상으로, AI는 힘의 증폭기이고 그 힘이 양수인지 음수인지 신경 쓰지 않음. 소프트웨어 엔지니어링 원칙이 나쁜 사람이 AI를 쓰면 순식간에 완전한 난장판을 만들 수 있음
    • 2번과 관련해, 우리 회사는 개발자가 제품 마인드를 갖고 단순한 톱니가 덜 되도록 강하게 밀고 있음
      나 자신이 다른 개발자보다 제품 마인드가 강해서 편향은 있지만, 이런 사람들이 에이전트로 더 생산적일 위치에 있다고 봄. 에이전트로 구현할 만큼 기술을 알고, 무엇을 구현해야 하는지 알 만큼 제품도 알기 때문임. 다른 회사들도 따라갈 것으로 예상함
    • 결국 대규모 인원 감축을 말하는 셈임

  • Uber가 뭘 개발하고 있는지 모르겠음. 앱과 차량 배정 백엔드가 있고 둘 다 괜찮게 작동함. 왜 그렇게 많이 쓰는지 의문임
    자율주행은 포기했으니 그건 아닐 것임

    • 정말 과소평가된 질문임. 현대 기술 회사들이 그 많은 자원으로 대체 뭘 하고 있는지를 잘 보여줌. Elon이 Twitter 팀 대부분을 줄였고, 초반의 끔찍한 시행착오 뒤에도 인력 80% 감소 상태에서 거의 잘 돌아가지 않았나 싶음
    • “둘 다 괜찮게 작동한다”면 좋겠지만 그렇지 않음. 매칭 알고리즘 최적화 때문에 사용자 경험이 너무 나빠져서 이제 정기적으로 Lyft를 씀
    • “X는 그냥 Y인데 왜 이렇게 복잡하냐”는 식의 댓글은 HN에서 가장 식상함. 싫어하는 대기업 글마다 이런 식으로 쓰는 건 게으르고 읽기 지루함

  • API 토큰으로는, 특히 1M 맥락을 쓰면서 오래된 맥락을 조심해서 비우지 않으면 한 세션에 수백 달러를 날리는 일이 아주 쉬움
    동시에 구독은 같은 사용량을 월 수백 달러에 허용함. Anthropic이 API 사용자에게 엄청나게 비싸게 받거나, 구독을 크게 보조하거나, 둘 다인 듯함

    • https://www.forbes.com/sites/annatong/2026/03/05/cursor-goes...
      “Cursor는 작년에 월 $200 Claude Code 구독이 최대 $2,000어치 컴퓨팅을 쓸 수 있다고 추정했고, 이는 Anthropic의 상당한 보조를 시사했다. 현재는 그 보조가 더 공격적으로 보여, $200 요금제로 약 $5,000어치 컴퓨팅을 소비할 수 있다”
    • Anthropic은 꽤 “흥미로운” 사업 모델을 갖고 있음. 직원이 150명 이하일 때는 구독 가격을 받다가, 151명이 되는 순간 전 직원이 하룻밤 사이에 API 가격을 내야 하고 전체 청구액이 즉시 몇 배로 늘어남
      싼 토큰에 중독시킨 뒤 규모가 커지면 회수하는 방식임. Uber는 정가보다 할인받겠지만, 150명 이하 구독 가격 근처는 아닐 것임
    • 가격을 검토해봤지만 Team에서 Enterprise로 뛰는 것을 정당화할 수 없었음. Enterprise로 가면 월 구독이 완전히 사라져 비용 통제 능력을 잃음
      사용자별 상한은 걸 수 있지만, 월간 롤링 상한이 없으면 팀원에게 “이번 달 남은 기간은 AI 없음”이라고 말해야 하는 상황이 됨. 현재 구조로는 꽤 위험한 거래라고 봄
답변달기