AI 도구 비용이 10배 폭증했을 때, JetBrains가 선택한 해법
JetBrains는 단 6개월 만에 개발 관련 AI 지출이 약 10배 증가하는 상황을 맞닥뜨렸다. 이는 JetBrains만의 문제가 아니다. AI 코딩 도구가 개발 워크플로우에 빠르게 스며들면서, 팀 단위로 산발적으로 사용되던 구독과 API 호출이 어느 순간 통제하기 어려운 규모의 운영 비용으로 누적되는 현상은 많은 조직이 공통으로 겪고 있다. 문제는 비용 자체가 아니라 비용이 어디서, 얼마나 발생하는지 파악조차 어렵다는 점이다.
도구를 제한하지 않고, 가시성을 확보한다
JetBrains가 선택한 방향은 직관적이지 않아 보일 수 있다. 비용을 줄이기 위해 승인된 몇 가지 도구만 허용하는 방식 — 이른바 "허용 목록(allowlist)" 전략 — 은 채택하지 않았다. 대신, 엔지니어가 기존처럼 자유롭게 도구를 선택할 수 있도록 유지하면서, 그 사용량을 중앙에서 추적하고 팀별로 집계할 수 있는 공유 접근 및 과금 레이어(shared access and accounting layer) 를 인프라 수준에서 구축했다.
이 접근법의 핵심 가치는 생산성과 통제 사이의 균형이다. 특정 도구를 강제로 제한하면 단기적으로 비용은 줄겠지만, 개발자 경험이 저하되고 비공식 우회 사용이 늘어나는 부작용이 생긴다. 반면 중앙화된 사용량 추적 레이어는 어떤 팀이 어떤 도구를 얼마나 쓰는지 가시화함으로써, 의사결정을 데이터 기반으로 가져갈 수 있게 한다.
백엔드 관점에서 본 설계 시사점
이 구조를 실제로 구현한다면 어떤 형태가 될까? 개념적으로는 API 게이트웨이 패턴과 유사하다. 각 팀의 요청이 외부 AI 서비스로 직접 나가는 대신, 내부 프록시 레이어를 거치면서 팀 식별자, 사용량, 비용을 기록한다.
// 개념적 예시: AI 요청에 팀 컨텍스트를 태깅하는 인터셉터
public class AiUsageTrackingInterceptor implements ClientHttpRequestInterceptor {
private final UsageMetricRepository metricRepository;
@Override
public ClientHttpResponse intercept(HttpRequest request, byte[] body,
ClientHttpRequestExecution execution) throws IOException {
String teamId = TeamContextHolder.getCurrentTeamId();
long start = System.currentTimeMillis();
ClientHttpResponse response = execution.execute(request, body);
long elapsed = System.currentTimeMillis() - start;
metricRepository.record(teamId, request.getURI().getHost(), elapsed, body.length);
return response;
}
}
핵심은 각 호출에 팀 컨텍스트를 태깅하고, 이를 집계하여 대시보드나 알림으로 연결하는 파이프라인이다. 단순히 로그를 쌓는 것을 넘어, 팀별 예산 임계값 초과 시 알림을 보내거나 소비량 리포트를 자동화하는 것이 실질적인 통제로 이어진다.
이러한 구조는 멀티테넌트 SaaS 서비스에서 사용량 기반 과금을 설계할 때와 유사한 사고방식을 요구한다. 누가, 무엇을, 얼마나 쓰는지를 인프라 레벨에서 명확히 하는 것이 먼저다.
정리
- AI 도구 비용 폭증에 대응할 때, 도구를 제한하기보다 사용량의 가시성을 확보하는 것이 지속 가능한 전략이다.
- 공유 접근 및 과금 레이어는 API 게이트웨이·프록시 패턴으로 구현 가능하며, 팀별 컨텍스트 태깅과 집계가 핵심이다.
- 운영 비용 관리는 이제 인프라 설계 단계에서부터 고려해야 할 백엔드 엔지니어의 책임 영역이다.