약 18개 LLM 제공자를 단일 API 뒤에서 운용하며 마주한 툴 호출·과금 문제와 해결 경험

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

작성자는 약 18개의 LLM 제공자를 단일 API로 통합하면서 채팅 분배와 툴 호출 정규화를 분리하고 비용 처리는 호출 시점 USD-per-token으로 정규화한 뒤 사전청구·호출·정산의 단일 파이프라인으로 운영했다고 보고했다. 툴 호출 차이는 어댑터 계층에서 툴 스키마·tool_choice·병렬 호출·usage 파싱 등을 표준 포맷으로 변환하는 방식으로 처리했고, 비용은 레코드 락을 이용한 소액 사전청구 후 실제 사용량과 비교해 환불하거나 보정하는 절차로 정합성을 확보했다. 운영 중 환불 과다, 스트리밍 환불 누락(GeneratorExit 미포괄 예외), 이중 원장 기록으로 인한 이중 청구 등 세 가지 주요 버그가 발견되었고 각각 환불 클램프, BaseException 처리 보완, 단일 원장 쓰기 통합으로 해결되었다. 결과적으로 중앙화된 미터링과 단일 정산 경로가 공급자별 비용 라우팅보다 실무에서 더 안정적인 해법임이 확인되었다.

실용적 조언

네트워크 전송과 프로바이더별 포맷 변환을 분리하라는 권고는 명확한 실무 규칙으로 제시되었으며, 이 방식은 입출력의 책임을 분리해 코드 복잡도를 낮추고 각 계층의 테스트 범위를 축소하는 효과가 있다. 구체적으로 wire-dispatch는 메시지 라우팅과 호환 브랜치 선택을 수행하고 tool-format 번역은 별도 순수 함수 계층에서 스키마 매핑과 선택 로직을 처리한다. 이 구조로 인해 새로운 공급자를 추가할 때 시스템 전체를 건드리지 않고 어댑터만 구현하면 되므로 확장성이 개선된다.
비용 처리는 모든 공급자 가격을 호출 시점의 USD-per-token으로 정규화하고 단일 정산 파이프라인을 통해 사전청구·실제 호출·정산을 수행하는 방식으로 설계하라는 권고가 주어졌다. 구현상 중요한 세부는 사전청구 단계에서 레코드 락(row lock)을 사용해 동시성으로 인한 중복 청구를 방지하고, 호출 완료 후 실제 사용량과 비교해 차액을 환불하거나 추가 청구하는 정산 로직을 반드시 포함하는 것이다. 이 패턴은 로컬 모델의 무료 청구 처리와 공급자별 가격 차이를 일관되게 관리하는 데 유용하다.
환불 및 원장 관련 예외 처리에서는 환불 한도를 실제 청구액으로 클램프하고, 스트리밍 연결 끊김과 같은 특수한 예외를 포괄적으로 잡아 환불 루틴이 항상 실행되도록 해야 하며, 청구 이벤트를 쓰는 지점은 하나로 통합해 단일 소스 오브 트루스를 유지해야 한다. 구체적으로 GeneratorExit 같은 BaseException은 except Exception으로 잡히지 않아 누락 사례를 만들기 때문에 환불 코드가 항상 실행되도록 예외 계층을 설계해야 한다. 또한 중복 원장 작성 지점을 제거하면 이중 청구를 방지하고 감사 추적이 단순해진다.

섹션별 상세

글 작성자는 약 18개의 LLM 제공자를 하나의 API 뒤에서 운영하면서 입력을 먼저 'chat dispatch'로 나누고 일부 공급자에 대해서만 맞춤 분기 처리를 적용하는 구조를 택했다. 이 구조에서는 대다수 제공자를 OpenAI 호환 브랜치로 통합해 동일한 호출 인터페이스로 압축하고, Anthropic·Gemini·Cohere·Replicate 등은 별도 처리 로직을 거쳐 응답을 표준화한다. 원문 근거로는 대부분의 제공자를 하나의 호환 브랜치로 묶고 소수는 bespoke handling이 필요하다고 밝힌 점이 있으며, 이러한 아키텍처는 공급자별 특이성을 격리해 전체 시스템 복잡도를 낮추는 실무적 장점을 제공한다.

작업 흐름 상 툴 호출 관련 정규화는 별도의 'tool-calling adapters' 계층에서 이루어지며 이 계층은 공급자마다 다른 툴 스키마, 도구 선택 방식, 병렬 호출 규칙, 사용량 파싱, 시드 처리 등을 입력으로 받아 공통 포맷으로 변환한다. 어댑터는 입력 텍스트와 메타데이터를 받아 필요한 필드를 매핑하고, 표준 스키마로 변환한 호출을 수행한 후 응답을 다시 표준화해 상위 로직에 반환하는 방식으로 동작한다. 원문에서 약 10가지 차이점이 존재한다고 언급한 부분이 근거로, 이 방식은 공급자 간 상호운용성을 확보하고 각 공급자의 특수 처리를 국소화해 유지보수 비용을 줄이는 효과를 낸다.

비용 청구는 가장 어려운 문제로 규정되며 운영자는 모든 공급자의 가격을 호출 시점의 USD-per-token으로 정규화한 뒤 단일 병목 지점에서 사전청구·호출·정산의 세 단계로 처리하는 정책을 적용했다. 구체적 절차는(1) 레코드 락 하에서 소액을 사전청구하고, (2) 실제 호출을 수행하며, (3) 실제 사용량과 추정치를 비교해 차액을 환불하거나 보정하는 형태로 이루어진다는 점이 원문에 명시되어 있다. 이 방식은 로컬 모델에는 과금을 0으로 처리하면서도 공급자별 가격 차이를 통일된 계산법으로 관리해 청구 정합성을 확보하는 장점이 있다.

운영 과정에서 발견된 세 가지 주요 비용 관련 버그와 그 수정 방식도 구체적으로 제시되었다. 첫째, 환불 경로에서 과다 환불이 발생해 크레딧을 발행하는 버그는 환불액을 실제 청구액으로 한정(clamp)함으로써 해결되었고, 둘째 스트리밍 중 클라이언트 연결 끊김 시 환불이 누락된 문제는 asyncio가 GeneratorExit를 BaseException으로 올리기 때문에 except Exception으로는 잡히지 않아 환불 로직이 실행되지 않은 사례로서 BaseException을 포괄하는 예외 처리로 보완했다. 셋째, 한 이벤트에 대해 두 곳이 원장을 쓰는 중복 기록 문제가 이중 청구로 이어진 바 있으며 이는 원장 쓰기 지점을 하나로 통합해 단일 진실의 원천을 확보하는 방식으로 해결되었다는 점이 근거로 제시되었고, 이들 수정은 실무에서 미터링의 일관성이 비용 정합성과 직결됨을 보여준다.

용어 해설

함수 호출 규격(Function Calling): — Function Calling은 모델이 외부 기능(툴)을 호출하기 위해 사용하는 입력·출력 스키마와 호출 결정 로직을 뜻한다. 이 규격은 툴 이름과 파라미터 포맷, 호출 조건을 포함하며 호출 전 파싱→스키마 매핑→응답 처리의 순서로 작동한다. 제공자마다 포맷과 선택 로직이 달라 중간 어댑터로 표준화해야 일관된 툴 호출이 가능하다.
툴 호출 인터페이스(Tool Calling): — Tool Calling은 LLM이 외부 API나 기능을 실행하기 위한 인터페이스 계층으로서 툴 목록, 선택 로직, 병렬 호출 규칙과 사용량 파싱을 포함한다. 입력 텍스트를 받아 어떤 툴을 호출할지 결정하고 툴 응답을 모델 입력으로 재주입하는 흐름으로 구성된다. 제공자별 차이를 어댑터가 중재하면 상호운용성이 확보된다.
미터링(과금 계측)(Metering): — Metering은 요청 단위로 사용량과 비용을 측정하고 기록하는 체계로, 토큰 기준 과금, 청구 이벤트 생성, 사전청구 및 정산 과정을 포함한다. 올바른 미터링은 단일 진실의 원천(ledger row)을 유지하고 동시성 제어로 중복 청구와 환불 오차를 방지한다. 운영 관점에서 비용 추정·사전청구·사후정산의 파이프라인화가 핵심이다.
사전 청구(Preflight Charge): — Preflight Charge는 실제 호출 전에 소액을 잠정 청구하여 동시성 환경에서 비용 추정을 잠시 확보하는 방식이다. 구현은 레코드에 행 잠금(row lock)을 걸어 동일 이벤트 중복 처리와 실시간 정합성을 확보하고, 호출 완료 후 실제 사용량과 비교해 차액을 환불하거나 추가 청구하는 순서로 이루어진다. 이 방식은 공급자별 가격 차이를 보정하는 데 유용하다.

코드 예제

text

null

null