Uber의 Claude Code 예산 관련 이야기는 가장 Claude Code다운 사례입니다

보도된 Uber의 이야기는 너무나 브랜드 이미지에 부합해서 마치 풍자처럼 느껴질 정도입니다. 믿을 수 없을 정도로 유용한 도구, 약간은 마법 같은 워크플로우(workflow), 그러다 4월에 재무팀이 화염방사기를 들고 나타난 격이죠.

만약 그들이 정말로 4개월 만에 연간 Claude Code 예산을 다 써버렸다면, 그것이 Claude Code가 나쁘다는 뜻은 아닙니다. 그것은 사용 패턴이 조달(procurement) 계산 방식보다 더 빠르게 변했다는 것을 의미합니다.

Claude는 코딩을 충분히 잘하기 때문에, 사람들이 더 이상 이를 자동 완성(autocomplete)처럼 취급하지 않고 잠들지 않는 동료처럼 취급하기 시작했습니다. 바로 이 지점에서 비용 곡선이 이상해집니다. 개발자가 리팩터링(refactor)을 요청합니다. Claude는 컨텍스트(context)를 읽고, 계획을 세우고, 편집하고, 테스트하고, 재시도하고, 설명하며, 때로는 루프(loop)를 돌거나 때로는 엉뚱한 곳으로 빠지기도 합니다. 이를 조직 전체로 곱하면 구독(subscription)이라는 비유는 깨지게 됩니다.

제가 계속해서 내리는 결론은 Claude Code에 지능만큼이나 경계(boundaries)가 필요하다는 것입니다. 더 작은 범위의 요청. 명시적인 중단 지점. 더 저렴한 검토 단계. 무작정 실행하기 전에 계획을 세우는 습관 말입니다.

저는 여전히 무거운 작업들을 위해 Claude를 메인 브레인(main brain)으로 유지하고 있습니다. 예전에는 제 할당량(quota)을 소진하곤 했던, 계획을 먼저 세우는 제한적인 실행 작업들은 Verdant를 통해 일부 작업을 라우팅(routing)하기 시작했습니다. 도구마다 다르고 트레이드오프(tradeoffs)도 다릅니다. 비용 측정기(meter) 덕분에 어떤 도구가 무엇을 소비하는지에 대해 진지하게 고민하게 되었습니다.

Claude는 여전히 훌륭합니다. 단지 더 이상 무료가 아니게 되었을 뿐입니다.