AI 비용 장부 다음 단계: LiteLLM Proxy로 “팀별 예산 키”부터 거는 법

LLM API 비용을 줄이려면 먼저 “싼 모델”을 고르는 것이 아니라, 누가 어떤 키로 얼마까지 쓸 수 있는지 호출 경로에서 강제해야 합니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

LLM API를 한두 명이 실험할 때는 모델별 가격표만 비교해도 충분해 보입니다.

하지만 팀 단위로 사용량이 늘어나면 봐야 할 질문이 달라집니다.

“어떤 모델이 더 싼가?”보다 먼저 확인해야 할 것은 이것입니다.

• 누가 API를 쓰고 있는가?
• 어떤 팀, 업무, 에이전트가 비용을 만들고 있는가?
• 예산을 넘기기 전에 호출을 막을 수 있는가?
• 비용 기록이 나중에 분석 가능한 형태로 남는가?

이 글은 이전 단계의 “AI 비용 장부 만들기”에서 한 걸음 더 나아갑니다.

장부가 비용을 기록하는 체계라면, 이번 글은 LiteLLM Proxy를 사용해 실제 LLM 호출 경로에서 키·예산·로그를 강제하는 구조를 다룹니다.

LiteLLM 공식 문서는 Proxy에서 Virtual Keys, 사용자·팀·에이전트 예산, spend tracking, logging/callback을 지원한다고 설명합니다. 또한 GitHub 공식 릴리스 기준 v1.105.0은 2026-10-11 공개로 확인됩니다.

출처: LiteLLM Virtual Keys, LiteLLM Users, LiteLLM Logging, LiteLLM v1.105.0 Release

1. 비용 통제의 단위는 “모델”이 아니라 “키”입니다

많은 팀이 AI 비용을 줄이려고 할 때 먼저 모델 가격표를 엽니다.

물론 모델별 단가는 중요합니다. 하지만 운영 관점에서는 가격표보다 먼저 나눠야 할 단위가 있습니다.

바로 API 키입니다.

하나의 공용 키를 여러 사람이 함께 쓰면, 비용이 발생한 뒤에도 원인을 나누기 어렵습니다.

반대로 팀, 업무, 에이전트 단위로 키를 나누면 다음 질문에 답할 수 있습니다.

• 마케팅팀이 쓴 비용인가, 개발팀이 쓴 비용인가?
• 문서 요약 에이전트가 쓴 비용인가, 고객 응대 에이전트가 쓴 비용인가?
• 테스트용 호출인가, 운영용 호출인가?
• 어느 키에서 예산 초과 위험이 발생했는가?

LiteLLM Proxy의 Virtual Keys는 이 지점에서 의미가 있습니다.

공식 문서에 따르면 LiteLLM Proxy는 Virtual Keys로 호출 단위를 분리할 수 있고, 사용자·팀·에이전트 예산과 spend tracking도 함께 다룰 수 있습니다.

출처: LiteLLM Virtual Keys, LiteLLM Users

즉, 비용 절감의 첫 번째 실행 산출물은 “가장 싼 모델 목록”이 아닙니다.

먼저 만들어야 할 것은 “누가 어떤 키로 얼마까지 쓸 수 있는지”를 정리한 예산 키 표입니다.

예시는 다음과 같은 형태가 될 수 있습니다.

구분	키 단위	사용 목적	예산 기준	로그 확인 필요 여부
팀	부서 또는 프로젝트	공통 업무 자동화	팀 예산	필요
업무	문서 요약, 리서치, 고객 응대 등	반복 작업	업무별 예산	필요
에이전트	특정 자동화 에이전트	백그라운드 실행	에이전트별 예산	필수
개인	실험 또는 개발	테스트 호출	개인 예산	필요

여기서 중요한 점은 “예산을 사후 분석하는 것”이 아니라 “호출 전에 통제 가능한 키 구조를 만드는 것”입니다.

2. max_budget은 비용 폭주를 막는 최소 안전장치입니다

LLM 비용 문제는 대개 한 번에 크게 드러나지 않습니다.

작은 테스트, 반복 실행, 자동화 루프, 에이전트 호출이 쌓이다가 어느 순간 비용 장부에서 이상치를 발견하게 됩니다.

그래서 팀 단위로 AI를 도입할 때는 호출 경로에 예산 제한을 걸어야 합니다.

리서치 기준으로 LiteLLM 문서는 personal, team, agent budgets와 spend tracking을 지원 범위로 설명합니다. 또한 Virtual Key에 max_budget을 연결해 팀·업무·에이전트 단위 비용 폭주를 막는 적용이 가능합니다.

출처: LiteLLM Users, LiteLLM Virtual Keys

여기서 핵심은 예산 체계를 처음부터 너무 정교하게 만들지 않는 것입니다.

완벽한 비용 배부 체계를 먼저 만들려 하면 도입이 늦어집니다. 대신 다음 순서로 나누면 현실적입니다.

1. 공용 키 사용을 중단한다.

2. 팀별 Virtual Key를 만든다.

3. 반복 실행되는 에이전트는 별도 키로 분리한다.

4. 각 키에 max_budget을 둔다.

5. spend tracking으로 실제 사용량을 확인한다.

6. 비용이 큰 키부터 업무 목적과 호출 패턴을 재검토한다.

이 구조의 장점은 책임 추적이 쉬워진다는 데 있습니다.

예를 들어 비용이 늘었을 때 “AI 비용이 많이 나왔다”가 아니라 다음처럼 질문할 수 있습니다.

• 어느 팀 키에서 비용이 늘었는가?
• 특정 에이전트 키에서 반복 호출이 발생했는가?
• 운영 키와 테스트 키가 분리되어 있는가?
• 예산 제한이 없는 키가 남아 있는가?

비용 절감은 모델 교체보다 먼저, 비용이 발생하는 경로를 잘게 나누는 일에서 시작됩니다.

3. logging과 callback 없이는 비용 개선도 반복할 수 없습니다

예산 키를 만들었다면 다음 단계는 로그입니다.

LiteLLM 공식 문서는 logging과 callback을 지원 범위로 설명합니다.

출처: LiteLLM Logging

로그가 필요한 이유는 단순히 “나중에 확인하기 위해서”가 아닙니다.

팀이 비용을 줄이려면 어떤 호출이 반복되고, 어떤 업무가 많은 비용을 만들며, 어떤 키가 예산에 가까워지는지 볼 수 있어야 합니다.

비용 장부가 월말 정산용이라면, Proxy 로그는 운영 중 점검용에 가깝습니다.

특히 에이전트 기반 자동화에서는 로그가 더 중요합니다.

사람이 직접 버튼을 누르는 업무보다 에이전트는 반복 실행, 재시도, 체인 호출이 발생하기 쉽습니다. 이때 키와 로그가 분리되어 있지 않으면 비용이 늘어난 원인을 찾기 어렵습니다.

따라서 LiteLLM Proxy를 비용 게이트웨이로 쓴다면 최소한 다음 항목을 확인해야 합니다.

• 키별 사용량을 추적할 수 있는가?
• 팀별 또는 업무별 예산을 나눌 수 있는가?
• 에이전트 호출을 별도 키로 분리했는가?
• 로그 또는 callback으로 사용 기록을 남길 수 있는가?
• 예산 초과 전후에 어떤 조치를 할지 정했는가?

이 글의 결론은 단순합니다.

LLM 비용 관리는 “나중에 줄이는 일”이 아니라 “처음부터 호출 경로에 넣어두는 일”입니다.

바로 적용하는 체크리스트 또는 비교 기준

아래 체크리스트는 LiteLLM Proxy를 비용 통제용 게이트웨이로 검토할 때 사용할 수 있습니다.

1. 키 분리 기준

• [ ] 공용 API 키를 그대로 쓰고 있지 않은가?
• [ ] 팀별 Virtual Key를 만들 계획이 있는가?
• [ ] 운영용 키와 테스트용 키를 분리했는가?
• [ ] 반복 실행되는 에이전트는 별도 키로 분리했는가?
• [ ] 개인 실험용 키와 서비스 운영 키가 섞이지 않았는가?

2. 예산 기준

• [ ] 팀별 예산 기준이 있는가?
• [ ] 개인 또는 실험용 예산 기준이 있는가?
• [ ] 에이전트별 예산 기준이 있는가?
• [ ] max_budget 적용 대상을 정했는가?
• [ ] 예산 초과 시 중단, 알림, 검토 중 어떤 절차를 따를지 정했는가?

3. 로그와 추적

• [ ] 키별 spend tracking이 가능한 구조인가?
• [ ] logging 또는 callback을 사용할 계획이 있는가?
• [ ] 비용이 늘었을 때 팀·업무·에이전트 단위로 원인을 나눌 수 있는가?
• [ ] 월말 정산용 장부와 운영 중 점검용 로그를 구분했는가?

4. 도입 전 비교 기준

LiteLLM Proxy 도입 여부를 판단할 때는 다음 기준으로 비교하는 것이 좋습니다.

비교 항목	단순 API 직접 호출	LiteLLM Proxy 기반 호출
키 관리	공용 키가 섞이기 쉬움	Virtual Key로 분리 가능
예산 통제	사후 확인 중심	키 단위 예산 적용 가능
사용량 추적	별도 구현 필요	spend tracking 지원 범위 확인됨
팀별 비용 분리	어려움	사용자·팀·에이전트 단위 예산 구조 검토 가능
로그 연계	개별 구현 필요	logging/callback 지원 범위 확인됨

단, 실제 적용 시 세부 설정 방식과 운영 정책은 조직의 인증 방식, 배포 구조, 보안 기준에 따라 달라질 수 있습니다. 이 부분은 도입 환경별 확인이 필요합니다.

마무리 + 생각해볼 질문 1개

AI 비용 절감은 더 싼 모델을 찾는 일에서 끝나지 않습니다.

팀에서 여러 LLM API를 쓰기 시작했다면, 먼저 비용이 발생하는 입구부터 통제해야 합니다.

LiteLLM Proxy의 Virtual Keys, personal/team/agent budgets, spend tracking, logging/callback은 이 문제를 다루는 기본 구성 요소가 될 수 있습니다.

핵심은 복잡한 최적화보다 먼저 팀별·업무별·에이전트별 예산 키를 만드는 것입니다.

마지막으로 이 질문을 남겨봅니다.

우리 조직의 LLM 호출은 지금 “누가 얼마나 쓰는지”를 설명할 수 있는 구조인가요, 아니면 아직 하나의 공용 키 뒤에 숨어 있나요?