JetBrains AI 지출 통제 첫 시도 정리 | 개발자 자유와 비용 관리 사이에서
JetBrains의 AI 지출 통제 첫 시도 과정을 읽고 정리했다. 개발자 자유도를 지키면서 비용을 관리하는 게 가능한지가 궁금해졌다.
JetBrains 블로그에서 AI 비용을 다루는 글이 올라왔다. 제목이 “AI 지출 통제를 위한 우리의 첫 시도들”인데, 읽어보니 자기들도 어디서부터 시작해야 할지 몰랐다는 이야기부터 꺼내는 글이었다. 이런 솔직한 톤이 오히려 눈길을 끌었다.
글에 따르면 지난 몇 달 사이 AI 관련 개발 비용이 상당히 늘었는데, 처음엔 어떻게 통제해야 할지 체계 자체가 없었다고 한다. 개발자들이 각자 여러 AI 도구를 골라 쓰는 상황이었고, 어디서 무엇이 얼마나 나가는지 파악조차 안 됐던 상황이었다. 접근 승인 프로세스가 병목이 되기도 했다고.
1️⃣ 세 번의 시도
처음엔 스프레드시트였다. 며칠에 걸쳐 수동으로 데이터를 모았는데, 완성하는 순간 이미 낡은 데이터가 됐다고 한다. 지속적으로 관리하는 게 애초에 불가능한 방식이었다.
두 번째로 내부 대시보드를 만들었다. 실시간 현황 파악은 됐는데, 지출 한도를 설정하거나 강제하는 기능이 없었다. “뭘 쓰고 있는지”는 보이는데 “얼마까지 써도 되는지”를 막을 방법이 없는 상황이었다.
세 번째가 지금 소개하는 JetBrains Central CLI다. 흥미로운 점은 이게 한 개발자가 개인용으로 만든 CLI 래퍼에서 출발했다는 거다. 조직 안에 이미 같은 문제를 혼자 해결해 쓰는 사람이 있었던 거다.
이 CLI의 핵심은 모든 AI 요청을 하나의 트래픽 라우팅 레이어로 통합하는 것이다. 덕분에:
- 인증이 자동화돼서 도구별 개별 로그인이 사라진다
- 써드파티 AI 에이전트 요청도 자동으로 감지해서 같은 레이어로 모인다
- AI 크레딧 단위로 팀·개인별 예산을 설정할 수 있게 된다
2️⃣ 내가 든 생각
이 글에서 JetBrains가 계속 강조한 원칙이 있었는데, “개발자의 도구 선택 자유를 건드리지 않겠다”는 거였다. 어떤 AI 에이전트를 쓸지는 개발자가 결정하고, 비용 집계와 예산 관리만 중앙에서 다루는 구조다. 개발자 입장에선 원하는 모델을 자유롭게 쓰면서 행정 절차는 최소화되고, 관리자 입장에선 팀별·개인별 소비를 세분화해서 볼 수 있게 된다.
👉🏻 이 두 가지가 동시에 가능한 게 라우팅 레이어 구조 덕분인 것 같다. 도구 자체를 제한하는 게 아니라, 요청이 지나가는 길을 공통화하는 방식.
💡 도구를 제한하지 않으면서 비용 통제가 실제로 유지될 수 있을까? 사용량이 다시 늘어나면 어떻게 될지 궁금해졌다.
디자인 관점에서 보면, 이게 결국 거버넌스 레이어 설계 문제에 가까운 것 같다. 기능을 직접 만드는 게 아니라, 기능들이 어떻게 사용되는지를 중간에서 관찰하고 조율하는 인프라를 짜는 일. 공부하면서 이런 종류의 설계 문제를 의식한 적이 별로 없었는데, 이 글에서 그게 꽤 구체적인 엔지니어링 과제라는 걸 처음으로 좀 실감했다.
⭐️ 마지막으로, 개발자 도구를 공부하며 느낀 점
이런 류의 글을 볼 때 자꾸 같은 질문을 하게 되는 것 같다 — 도구를 어떻게 관리하느냐가 도구를 어떻게 만드느냐만큼이나 복잡한 엔지니어링 문제일 수 있다는 것. JetBrains가 결국 만든 것도 AI 도구가 아니라 AI 도구들을 위한 인프라였다.