기업의 LLM API 비용은 비싼 모델을 사용해서만 증가하지 않습니다. 불필요한 문맥, 중복 요청, 실패 재시도, 잘못된 모델 라우팅, 예산 귀속 부재가 비용을 여러 방향으로 키웁니다. 이 글에서는 Switchyard로 라우팅 실험을 수행하고 AI Gateway로 예산과 사용량을 통제하는 실행 순서를 설명합니다.
기업 LLM API 비용은 먼저 모델을 바꾸는 방식이 아니라, 요청 유형과 품질 기준을 나누고 호출 과정을 기록하는 방식으로 줄여야 합니다. Switchyard는 모델 라우팅 실험에 활용하고, AI Gateway는 프로젝트별 예산과 사용량을 통합 관리하는 구조가 적합합니다.
이 글은 다음 독자에게 맞습니다.
- 여러 모델을 사용하는 AI 플랫폼 팀
- 에이전트와 자동화 서비스의 비용을 계산하는 기술 책임자
- 모델 라우팅, 사용량 감시, 프로젝트별 예산 통제를 준비하는 백엔드 엔지니어
마지막 업데이트: 2026년 8월 13일
라우팅 기능과 비용 관리 방식은 Switchyard 공식 저장소, LiteLLM 공식 문서, OpenAI 공식 개발자 문서를 기준으로 확인했습니다. 공급업체의 가격, 캐시 정책, 모델 이름, 게이트웨이 기능이 바뀌면 같은 계산식을 그대로 재사용하지 말고 다시 검증해야 합니다.
비용을 줄이기 전에 호출이 커지는 지점을 분해합니다
기업의 LLM API 비용은 대체로 다음 다섯 가지가 겹치면서 증가합니다.
| 비용 증폭 지점 | 실제로 발생하는 낭비 | 먼저 기록할 항목 |
|---|---|---|
| 모델 오배정 | 단순 분류에도 고성능 모델 사용 | 요청 유형, 선택 모델, 품질 결과 |
| 문맥 중복 | 시스템 지침과 이전 대화의 반복 전송 | 입력 토큰, 문맥 구성 요소 |
| 캐시 부재 | 같은 요청과 문서를 매번 새로 처리 | 캐시 키, 적중 여부, 데이터 시점 |
| 재시도 확대 | 시간 초과와 잘못된 출력 뒤 무제한 재호출 | 원 요청 ID, 재시도 횟수, 오류 종류 |
| 예산 귀속 부재 | 어느 팀과 기능이 비용을 만들었는지 확인 불가 | 프로젝트, 환경, 사용자, 업무 목적 |
여기서 중요한 점은 모델 단가가 내려가도 총비용이 줄지 않을 수 있다는 사실입니다. 낮은 비용의 모델이 복잡한 작업을 제대로 처리하지 못하면 재시도와 검수, 강한 모델로의 재호출이 추가됩니다. 한 번의 사용자 요청이 내부에서 몇 번의 모델 호출로 바뀌는지 확인하지 않으면 청구서만 보고 원인을 찾기 어렵습니다.
Switchyard 공식 저장소는 여러 제공업체 형식을 변환하고, 분류기 기반 라우팅과 단계형 라우팅을 구성하며, 요청별 지연 시간·토큰·비용 통계를 수집하는 기능을 설명합니다. 다만 이 기능은 절약 금액을 자동으로 보장하는 기능이 아니라, 라우팅 가설을 검증할 수 있는 실행 계층으로 보는 편이 정확합니다. (github.com)
주의: “저렴한 모델로 모두 교체”는 비용 최적화가 아니라 비용 위치를 바꾸는 조치가 될 수 있습니다. 품질 실패율과 재시도 횟수가 함께 올라가면 총비용은 오히려 커집니다.
첫 단계: 요청을 품질 등급과 비용 등급으로 나눕니다
모델 라우팅은 모델 이름부터 정하는 작업이 아닙니다. 먼저 업무를 분류해야 합니다. 예를 들어 단순한 형식 변환, 필드 추출, 짧은 요약은 낮은 비용의 모델로 처리할 가능성이 높습니다. 반면 보안 정책 판단, 긴 코드 수정, 여러 도구 결과를 통합하는 에이전트 작업은 더 높은 품질 기준이 필요합니다.
다음과 같은 라우팅 표를 먼저 만듭니다.
| 업무 유형 | 기본 경로 | 승격 조건 | 검증 방법 |
|---|---|---|---|
| 형식 변환과 분류 | 낮은 비용 모델 | 필수 필드 누락 | 정답 필드 비교 |
| 일반 요약 | 중간 등급 모델 | 핵심 내용 누락 | 사람이 만든 요약과 비교 |
| 코드 생성 | 중간 등급 모델 | 테스트 실패, 구문 오류 | 자동 테스트 |
| 보안과 정책 판단 | 강한 모델 | 낮은 신뢰도, 근거 누락 | 검토자 승인 |
| 도구를 사용하는 에이전트 | 단계형 라우팅 | 도구 오류, 작업 반복 | 작업 성공 여부와 호출 수 |
Switchyard에서는 분류기 기반 라우팅을 사용해 요청 난이도를 판단하거나, 약한 모델의 결과와 특정 신호를 바탕으로 강한 모델로 넘기는 단계형 구조를 실험할 수 있습니다. 공식 문서에 있는 분류기 모델, 최소 신뢰도, 라우팅 프로필 같은 설정은 라우팅 실험의 출발점으로 사용할 수 있지만, 실제 업무에 적용하기 전에는 기업의 검증 세트로 다시 평가해야 합니다. (github.com)
핵심은 평균 품질이 아니라 실패 비용입니다. 단순 문의에서 낮은 등급 모델이 일부 오답을 내더라도 사람이 바로 수정할 수 있지만, 결제 승인이나 보안 판단에서 같은 오류가 발생하면 모델 단가보다 훨씬 큰 운영 비용이 생깁니다.
두 번째 단계: 문맥 예산을 만들고 반복 입력을 줄입니다
입력 토큰은 사용자 질문만으로 구성되지 않습니다. 시스템 지침, 대화 이력, 검색 결과, 도구 응답, 계정 정보, 권한 목록이 한 요청에 함께 들어가는 경우가 많습니다. 에이전트가 여러 번 도구를 호출하면 같은 문서와 지침이 매 단계 재전송될 수 있습니다.
문맥을 다음처럼 나누면 줄일 부분이 선명해집니다.
| 문맥 요소 | 유지 기준 | 비용 관리 방식 |
|---|---|---|
| 시스템 지침 | 모든 요청에 필요한 규칙만 유지 | 공통 규칙과 업무별 규칙 분리 |
| 대화 이력 | 현재 판단에 필요한 내용만 유지 | 오래된 대화 요약 |
| 검색 결과 | 답변에 사용되는 부분만 전달 | 관련도 낮은 문단 제거 |
| 도구 결과 | 다음 단계에 필요한 필드만 전달 | 전체 응답 대신 구조화된 필드 사용 |
| 감사 기록 | 보존하되 모델 입력과 분리 | 원문 저장과 입력용 요약 분리 |
문맥을 줄일 때 감사 기록까지 삭제하면 안 됩니다. 저장해야 하는 원문과 모델에 보내야 하는 입력은 같은 데이터가 아닙니다. 원문은 권한과 보존 정책에 따라 보관하고, 모델 요청에는 필요한 필드와 요약만 넣는 방식이 안전합니다.
OpenAI는 반복되는 입력을 재사용하는 프롬프트 캐시와 캐시 토큰 정보를 제공하고 있으며, 최신 모델 문서에서는 캐시 읽기뿐 아니라 캐시 기록 비용과 실제 사용량 필드도 확인하도록 안내합니다. 따라서 캐시를 사용하더라도 cached_tokens와 캐시 기록 관련 사용량을 함께 기록해야 순비용을 계산할 수 있습니다. (openai.com)
세 번째 단계: 캐시는 권한과 시점을 포함해 설계합니다
캐시는 단순히 “같은 문장이면 같은 답을 반환”하는 기능이 아닙니다. 기업 환경에서는 동일한 질문이라도 사용자의 권한, 테넌트, 문서 버전, 모델 버전이 다를 수 있습니다.
캐시 키에는 최소한 다음 항목을 포함하는 편이 좋습니다.
- 모델과 제공업체
- 프롬프트 버전
- 테넌트와 권한 범위
- 검색 데이터의 기준 시점
- 도구 정의와 응답 형식
- 언어와 출력 형식
결정성이 높고 변경 빈도가 낮은 작업부터 캐시를 적용해야 합니다. 제품 설명의 구조화, 고정 문서의 분류, 동일한 정책 문구의 변환처럼 결과 재사용이 쉬운 작업이 적합합니다. 반대로 계정 잔액, 재고, 실시간 보안 경보처럼 최신성이 중요한 데이터는 캐시 만료 기준을 짧게 잡거나 캐시 대상에서 제외해야 합니다.
OpenAI의 프롬프트 캐시 안내는 반복 입력을 재사용하는 방식과 사용량 확인 방법을 설명합니다. 공급업체마다 캐시 유지 시간과 과금 규칙이 다르므로 한 제공업체의 정책을 다른 모델에 그대로 적용해서는 안 됩니다. (openai.com)
네 번째 단계: 실패 재시도와 회귀 경로를 제한합니다
재시도는 장애 대응에 필요하지만, 모든 오류를 같은 방식으로 다시 호출하면 비용 증폭기가 됩니다. 시간 초과, 속도 제한, 네트워크 오류, 잘못된 JSON, 안전 정책 거부는 원인이 서로 다릅니다.
| 오류 유형 | 기본 대응 | 피해야 할 방식 |
|---|---|---|
| 일시적 네트워크 오류 | 제한된 횟수의 지수형 대기 | 짧은 간격의 무한 재시도 |
| 속도 제한 | 공급업체별 대기와 다른 경로 검토 | 즉시 같은 모델 재호출 |
| 잘못된 출력 형식 | 짧은 형식 교정 요청 | 전체 문맥을 다시 보내는 반복 호출 |
| 품질 검증 실패 | 승격 모델로 한 번만 전달 | 여러 모델에 무작위로 전송 |
| 정책 거부 | 허용된 대체 작업 또는 사용자 안내 | 거부 요청을 계속 반복 |
각 업무 요청에는 원 요청 ID를 부여하고, 연결된 모든 모델 호출을 같은 계보로 묶어야 합니다. 이때 다음 항목을 함께 남겨야 합니다.
- 최초 요청 시각
- 선택된 모델과 제공업체
- 입력·출력 사용량
- 재시도 횟수
- 오류 유형
- 승격 여부
- 최종 성공 여부
- 전체 지연 시간
LiteLLM 공식 문서는 여러 제공업체를 하나의 형식으로 호출하고, 재시도와 대체 경로, 프로젝트별 지출 추적과 예산 관리를 구성하는 방법을 설명합니다. Switchyard와 LiteLLM을 비교할 때도 특정 도구가 모든 비용 문제를 해결한다고 보기보다, 라우팅 실험 계층과 운영 거버넌스 계층을 어떻게 나눌지 판단해야 합니다. (docs.litellm.ai)
다섯 번째 단계: AI Gateway에서 비용을 업무에 귀속합니다
AI Gateway는 단순한 API 주소 통합기가 아닙니다. 기업에서는 모든 호출에 누가, 어느 프로젝트에서, 어떤 환경으로, 어떤 업무를 수행했는지 기록해야 합니다.
권장되는 비용 귀속 구조는 다음과 같습니다.
| 구분 | 예시 값 | 필요한 이유 |
|---|---|---|
| 테넌트 | 고객 또는 내부 조직 | 고객별 비용 분리 |
| 프로젝트 | 검색, 상담, 개발 자동화 | 기능별 손익 계산 |
| 환경 | 개발, 검증, 운영 | 운영 외 호출 통제 |
| 업무 목적 | 요약, 분류, 코드 생성 | 모델 라우팅 개선 |
| 요청 ID | 애플리케이션의 추적 ID | 실제 사용자 요청과 비용 연결 |
예산은 한 개의 월 한도로 끝내지 않는 편이 좋습니다. 프로젝트별 한도, 환경별 한도, 사용자별 속도 제한, 모델별 허용 목록을 함께 두어야 합니다. 개발 환경에서 테스트 코드가 반복 실행되거나, 에이전트가 같은 작업을 계속 재시도하는 상황을 조기에 막을 수 있기 때문입니다.
LiteLLM은 프로젝트별 지출 추적과 예산, 속도 제한, 가상 키, 로깅 같은 게이트웨이 기능을 공식 문서에서 제공한다고 설명합니다. 기업이 다른 AI Gateway를 선택하더라도 같은 기준으로 프로젝트 키와 요청 ID를 설계해야 비용 보고서가 실제 업무와 연결됩니다. (docs.litellm.ai)
여섯 번째 단계: 낮은 비용 모델의 품질을 검증합니다
모델을 낮추는 실험은 비용만 비교하면 실패하기 쉽습니다. 최소한 다음 네 가지 결과를 함께 봐야 합니다.
- 업무 성공률
- 형식 오류율
- 재시도와 모델 승격 횟수
- 요청 전체의 지연 시간과 비용
검증 세트는 실제 운영 요청에서 익명화한 사례와 경계 사례를 섞어 구성해야 합니다. 쉬운 요청만 넣으면 잘못된 라우팅을 발견하지 못합니다. 특히 다음과 같은 사례를 포함해야 합니다.
- 긴 문맥이 필요한 요청
- 정보가 부족해 추가 질문이 필요한 요청
- 여러 도구 결과를 합쳐야 하는 요청
- 정책상 거부해야 하는 요청
- 출력 형식이 엄격한 요청
- 같은 질문이지만 사용자 권한이 다른 요청
검증 결과가 기준 이하로 떨어지면 강한 모델로 승격합니다. 이때 승격 조건은 분류기의 신뢰도만으로 정하지 말고, 출력 형식 오류, 자동 테스트 실패, 도구 호출 실패, 근거 누락 같은 관찰 가능한 신호와 결합해야 합니다.
경험상 가장 위험한 보고서는 “평균 토큰 비용이 내려갔다”만 표시하는 보고서입니다. 실패 후 재호출까지 합산한 요청당 실제 비용이 함께 표시되지 않으면 최적화 전후를 제대로 비교할 수 없습니다.
일곱 번째 단계: 관측부터 동적 라우팅까지 순서대로 배포합니다
비용 최적화는 다음 순서로 진행하는 편이 안전합니다.
1. 일주일간 기준선을 수집합니다
모델별 입력·출력 사용량, 요청 수, 오류, 재시도, 지연 시간, 프로젝트, 환경을 기록합니다. 이 단계에서는 라우팅 규칙을 바꾸지 않는 것이 좋습니다.
2. 비용을 요청 ID에 연결합니다
청구서 수준의 합계가 아니라 애플리케이션 요청과 모델 호출을 연결합니다. 한 번의 사용자 요청이 내부에서 몇 번 호출되었는지 확인합니다.
3. 중복 문맥을 줄입니다
시스템 지침, 이전 대화, 검색 결과, 도구 응답을 분리하고 각 요소의 보존 이유를 적습니다. 감사용 원문과 모델 입력용 요약을 분리합니다.
4. 재시도 정책을 제한합니다
오류별 재시도 횟수와 대기 시간을 정하고, 반복 실패 시 회로 차단이나 수동 검토로 넘깁니다.
5. 캐시를 안전한 업무부터 적용합니다
모델, 프롬프트 버전, 권한, 데이터 시점을 캐시 키에 포함하고 만료 정책을 업무별로 설정합니다.
6. Switchyard 라우팅을 검증 환경에서 실험합니다
업무 난이도와 품질 기준을 기준으로 모델 계층을 나누고, 검증 세트에서 오분류와 승격 비율을 측정합니다.
7. 운영 환경에는 예산과 중단 조건을 함께 배포합니다
비용 경고, 속도 제한, 모델 허용 목록, 오류율 기준, 자동 중단 조건을 하나의 운영 정책으로 묶습니다.
이 순서를 지키면 비용 절감이 품질 저하나 장애 은폐로 바뀌는 위험을 줄일 수 있습니다. 평가 기준은 비용 하나가 아니라 비용, 품질, 지연, 실패율을 함께 사용해야 합니다.
배포 전 확인할 항목
- [ ] 모든 모델 호출에 원 요청 ID가 연결되어 있습니다.
- [ ] 프로젝트와 환경별 사용량을 분리할 수 있습니다.
- [ ] 요청당 최초 호출과 재시도 호출을 구분합니다.
- [ ] 입력 토큰과 출력 토큰을 각각 기록합니다.
- [ ] 문맥 구성 요소별 크기를 확인할 수 있습니다.
- [ ] 캐시 키에 모델과 프롬프트 버전이 포함되어 있습니다.
- [ ] 캐시 키에 테넌트와 권한 범위가 포함되어 있습니다.
- [ ] 최신성이 중요한 데이터의 만료 조건이 정해져 있습니다.
- [ ] 업무별 품질 검증 세트가 준비되어 있습니다.
- [ ] 낮은 신뢰도와 형식 오류의 승격 조건이 있습니다.
- [ ] 프로젝트별 경고선과 차단선이 구분되어 있습니다.
- [ ] 모델 변경 뒤 비용과 품질을 다시 비교할 절차가 있습니다.
운영 전용 게이트웨이와 검증용 환경을 분리해야 한다면, 필요한 기간에 맞춰 한국 맥 원격 환경이나 미국 동부 맥 원격 환경을 별도로 구성해 트래픽 재생과 라우팅 테스트를 진행할 수 있습니다. 다만 장기간의 고정 부하를 처리하거나 물리 장비와 직접 연결해야 하는 경우에는 전용 서버나 자체 인프라가 더 적합할 수 있습니다.
자주 묻는 내용
기업 LLM API 비용이 계속 늘어나는 가장 흔한 이유는 무엇인가요?
비용이 커지는 이유는 단가가 높은 모델을 쓴다는 사실 하나보다 요청당 입력 문맥과 출력 길이가 계속 늘어나기 때문입니다. 여기에 에이전트의 반복 호출, 실패 후 재시도, 같은 문서의 재전송, 프로젝트별 비용 귀속 부재가 겹칩니다. 따라서 모델 교체 전에 요청 단위 호출 수와 토큰 사용량부터 기록해야 합니다.
Switchyard는 요청에 따라 모델을 어떻게 선택하나요?
Switchyard는 단일 모델을 고정하는 대신 분류기 기반 라우팅, 단계형 라우팅, 무작위 라우팅, 직접 작성한 라우터를 구성할 수 있습니다. 요청의 난이도나 신뢰도 신호를 기준으로 약한 모델에서 강한 모델로 넘기는 실험이 가능합니다. 다만 분류 결과만 믿지 말고 검증용 요청 묶음으로 오분류율과 품질을 함께 확인해야 합니다.
AI Gateway에서 프로젝트별 예산은 어떻게 관리해야 하나요?
프로젝트, 팀, 환경, 사용자, 업무 목적을 구분하는 키를 먼저 만들고 모든 호출에 요청 식별자를 연결해야 합니다. 그다음 누적 사용량과 예상 비용에 따라 경고선, 일시 제한선, 차단선을 나눠 설정합니다. 예산을 단순한 월별 숫자로만 두면 특정 에이전트나 배포 환경에서 발생한 반복 호출을 찾기 어렵습니다.
캐시를 사용하면 대형 언어 모델 API 사용량을 줄일 수 있나요?
반복되는 시스템 지침, 고정된 문서 앞부분, 변하지 않는 검색 결과는 캐시 대상이 될 수 있습니다. 그러나 모델, 프롬프트 버전, 권한 범위, 데이터 갱신 시점을 캐시 키에 포함하지 않으면 오래된 답변이나 다른 사용자의 정보가 재사용될 수 있습니다. 캐시 적중률뿐 아니라 잘못된 재사용과 캐시 기록 비용도 함께 측정해야 합니다.
모델을 낮춰도 답변 품질을 유지하려면 무엇을 확인해야 하나요?
업무별 검증 세트를 만들고 정확성, 형식 준수, 근거 포함 여부, 도구 호출 성공 여부를 평가해야 합니다. 낮은 비용의 모델은 검증을 통과한 분류, 추출, 요약 같은 업무부터 맡기는 편이 안전합니다. 실패 조건이나 낮은 신뢰도 신호가 발생하면 강한 모델로 승격하는 규칙을 미리 정해야 합니다.
현재 환경과 맥 기반 검증 환경을 비교할 때
기존에 개발자 개인 컴퓨터나 공유 클라우드 환경에서 라우팅 실험을 진행하면 권한 분리가 어렵고, 트래픽 재생 중 다른 작업과 자원이 충돌하며, 실험이 끝난 뒤 환경을 정리하기도 어렵습니다. 특히 운영 API 키와 검증용 키가 섞이거나 로그가 여러 장소에 흩어지면 비용 기준선을 다시 만들기 힘듭니다.
반면 맥 기반의 독립 환경은 실험 기간 동안 설정과 로그를 분리하고, Switchyard와 AI Gateway를 고정된 구성으로 재현하기 쉽습니다. 생산 환경을 곧바로 바꾸지 않고 별도 환경에서 요청 분류, 캐시 키, 재시도 정책, 예산 제한을 검증하려는 팀이라면 임시 맥산 임대가 더 나은 선택이 될 수 있습니다. 장기 고정 사용이나 최고 수준의 처리량이 목적이라면 자체 서버를 검토하고, 일정 기간의 재현 가능한 실험이 목적이라면 nuvcloud의 맥 환경으로 범위를 한정하는 방식이 현실적입니다.
인공지능 개발 비용을 줄이는 유연한 원격 맥 환경
nuvcloud는 필요한 성능에 맞는 맥 환경을 제공해 초기 장비 구매와 유지 비용을 줄이는 데 도움을 줍니다.
원격 맥을 활용하면 인공지능 서비스 개발과 시험에 필요한 환경을 빠르게 준비할 수 있습니다.
자주 묻는 질문
기업 LLM API 비용이 계속 늘어나는 가장 흔한 이유는 무엇인가요?
비용이 커지는 이유는 단가가 높은 모델을 쓴다는 사실 하나보다 요청당 입력 문맥과 출력 길이가 계속 늘어나기 때문입니다. 여기에 에이전트의 반복 호출, 실패 후 재시도, 같은 문서의 재전송, 프로젝트별 비용 귀속 부재가 겹칩니다. 따라서 모델 교체 전에 요청 단위 호출 수와 토큰 사용량부터 기록해야 합니다.
Switchyard는 요청에 따라 모델을 어떻게 선택하나요?
Switchyard는 단일 모델을 고정하는 대신 분류기 기반 라우팅, 단계형 라우팅, 무작위 라우팅, 직접 작성한 라우터를 구성할 수 있습니다. 요청의 난이도나 신뢰도 신호를 기준으로 약한 모델에서 강한 모델로 넘기는 실험이 가능합니다. 다만 분류 결과만 믿지 말고 검증용 요청 묶음으로 오분류율과 품질을 함께 확인해야 합니다.
AI Gateway에서 프로젝트별 예산은 어떻게 관리해야 하나요?
프로젝트, 팀, 환경, 사용자, 업무 목적을 구분하는 키를 먼저 만들고 모든 호출에 요청 식별자를 연결해야 합니다. 그다음 누적 사용량과 예상 비용에 따라 경고선, 일시 제한선, 차단선을 나눠 설정합니다. 예산을 단순한 월별 숫자로만 두면 특정 에이전트나 배포 환경에서 발생한 반복 호출을 찾기 어렵습니다.
캐시를 사용하면 대형 언어 모델 API 사용량을 줄일 수 있나요?
반복되는 시스템 지침, 고정된 문서 앞부분, 변하지 않는 검색 결과는 캐시 대상이 될 수 있습니다. 그러나 모델, 프롬프트 버전, 권한 범위, 데이터 갱신 시점을 캐시 키에 포함하지 않으면 오래된 답변이나 다른 사용자의 정보가 재사용될 수 있습니다. 캐시 적중률뿐 아니라 잘못된 재사용과 캐시 기록 비용도 함께 측정해야 합니다.
모델을 낮춰도 답변 품질을 유지하려면 무엇을 확인해야 하나요?
업무별 검증 세트를 만들고 정확성, 형식 준수, 근거 포함 여부, 도구 호출 성공 여부를 평가해야 합니다. 낮은 비용의 모델은 검증을 통과한 분류, 추출, 요약 같은 업무부터 맡기는 편이 안전합니다. 실패 조건이나 낮은 신뢰도 신호가 발생하면 강한 모델로 승격하는 규칙을 미리 정해야 합니다.