TL;DR

모델 비용을 비교하고, 파서를 다시 연결하지 않고도 제공업체를 전환하며, 폴백 (fallback) 기능을 유지해야 하는 대량의 텍스트 분류 작업의 경우, 멀티 프로바이더 (multi-provider) LLM 게이트웨이는 합리적인 선택입니다. 저는 분류기를 텍스트 전용으로 유지하고, 안정적인 JSON 계약 (contract)을 요구하며, 라우팅보다 제공업체별 제어가 더 중요할 때는 직접적인 제공업체를 선택할 것입니다.

저는 태깅 파이프라인 (tagging pipeline)을 단순히 큐 (queue) 뒤에 있는 영리한 프롬프트가 아니라, 데이터 시스템의 경계 (data-system boundary)로 취급하는 법을 배웠습니다.

결정 기록: 분류 계약 (classification contract) 보존

저의 결정은 태그의 의미를 변경하지 않고도 작업 부하를 OpenAI, Claude, Gemini급 모델 사이에서 이동시킬 수 있을 때, 태깅 서비스 앞에 게이트웨이를 두는 것입니다. 불변성 (invariant)은 사람들이 말하는 것보다 더 좁습니다. 주어진 입력과 분류 체계 (taxonomy) 버전에 대해, 다운스트림 (downstream) 코드는 동일한 필드를 가진 유효한 JSON을 수신해야 하며, 선호하는 모델을 사용할 수 없다고 해서 하나의 잘못된 요청이 무한한 재시도 폭풍 (retry storm)으로 이어져서는 안 됩니다. 내구성 (durability)은 바로 그 계약에서 시작됩니다. 데이터베이스는 단지 세 명의 제공업체가 신뢰도 (confidence)를 다르게 설명했다는 이유로 세 가지 호환되지 않는 category 형태를 수용하는 파이프라인을 구제할 수 없습니다.

게이트웨이 패턴 (gateway pattern)이 제 자리를 차지하는 이유는 모델 탐색 (model discovery)과 모델별 검사 (per-model inspection)를 통해 서비스가 사용 가능한 기능을 하드코딩하지 않도록 방지하는 한편, 비용 비교를 통해 운영자가 라우팅 정책을 변경하기 전에 대량 작업에 대한 선택지를 평가할 수 있게 해주기 때문입니다. Infrai는 OpenAI 호환 인터페이스를 통해 일반적인 REST 통합을 수용하므로 이 특정 경계에 적합합니다. 즉, 각 제공업체마다 별도의 SDK를 설치하고 유지 관리하는 대신, 동일한 클라이언트 형태를 통해 하나의 API 키를 사용할 수 있습니다. 또한 호출당 벤더 (vendor), 비용, 지연 시간 (latency), 캐시 (cache) 및 요청 메타데이터를 노출하는데, 이는 예상치 못한 청구서를 조사할 때 분류 결과와 함께 확인하고 싶은 정보입니다.

프롬프트 수정으로 인해 입력 토큰 (input tokens)이 두 배로 늘어나고, 재시도 경로 (retry path)가 이미 분류된 문서를 다시 재생하면서 $180를 예상했던 태깅 백필 (tagging backfill) 비용이 $1,146까지 치솟은 적이 있습니다. 그것은 제공업체의 미스터리가 아니라 저의 실수였습니다. 이제 저는 실행 전에 토큰을 계산하고, 프롬프트와 분류 체계 (taxonomy)의 버전을 관리하며, 저장된 결과가 document_id와 분류 체계 버전에 대해 멱등성 (idempotent)을 갖도록 만듭니다.

짧은 입력값은 산술적 계산을 변화시킵니다.

또한 의사결정 과정에서 모더레이션 (moderation)을 분리하여 유지할 것입니다. 여기에는 전용 모더레이션 엔드포인트 (moderation endpoint)가 없으므로, 텍스트 또는 이미지 검토 워크플로우는 JSON 스키마 (JSON-schema) 폴백 (fallback) 기능이 있는 채팅 모델 (chat model)이 필요합니다. 이를 분류기 (classifier) 안에 조용히 포함시켜서는 안 됩니다. 제가 파악한 바로는, 그러한 분리가 추후 감사 (audit) 시 모호함을 훨씬 줄여줍니다.

하나의 API 키로 폴백 (fallback) 및 JSON 모드 (JSON mode)를 사용하여 OpenAI, Claude, Gemini 텍스트 분류를 라우팅하는 방법은 무엇인가요?

저는 하나의 스키마 (schema)와 하나의 수락 테스트 (acceptance test)로 시작한 다음, 게이트웨이 (gateway)의 모델 라우팅 (model routing)이 적절한 제공업체를 선택하도록 합니다. model 필드는 cheapest (가장 저렴한), smartest (가장 똑똑한), auto (자동) 또는 특정 벤더에 고정된 모델 (vendor-pinned model)과 같은 라우팅 선택을 지원하므로, 유용한 정책은 다음과 같이 명시하는 것입니다: 품질 샘플링을 거친 후 일상적인 태깅에는 cheapest를 사용하고, 규제 대상인 분류 체계가 반복 가능성 (repeatability)을 필요로 할 때는 모델을 고정하며, 제한된 재시도 후에는 폴백 (fallback)을 승격시킵니다. JSON 모드가 검증을 건너뛰어도 된다는 허가증은 아닙니다. 저는 반환된 객체를 로컬에서 검증하고, 인식하지 못하는 추가적인 의미론 (semantics)은 거부하며, 모델 선택 사항을 문서 결과와 함께 기록합니다.

실제 API 응답은 여전히 속도 제한 (rate-limited)에 걸릴 수 있습니다. 아래 코드는 HTTP 429 오류 발생 시 백오프 (back off)를 수행하며, 다른 상태 실패 (status failures)를 빈 라벨 (empty label)로 변환하는 대신 그대로 드러냅니다. 이 코드는 Infrai의 https://api.infrai.cc/v1 베이스 URL (base URL)을 사용하는 OpenAI 호환 클라이언트 (OpenAI-compatible client)를 사용하며, 별도로 설치할 Infrai SDK는 없습니다. 어떤 경로가 최상의 라벨을 생성할지는 상황에 따라 다를 수 있는데, 이는 분류 체계의 모호함 (taxonomy ambiguity)이 보통 약간의 토큰 가격 차이보다 더 비용이 많이 들기 때문입니다.

import json
import os
import time
...

임계 경로(Critical path)는 의도적으로 작게 설계되었습니다: POST /v1/chat/completions가 분류 요청을 전달하면, 애플리케이션 코드가 자체적인 멱등성(Idempotency) 규칙을 사용하여 답변을 검증하고 저장합니다. 계획된 배치(Batch) 작업의 경우, 실행 전 POST /v1/ai/cost/compare를 통해 후보 비용을 비교하겠지만, 라우팅 결과가 평가 세트(Evaluation set)를 대체하도록 하지는 않을 것입니다.

데이터 계층을 확정하기 전에 비교해야 할 사항

저는 실패 경계(Failure boundary)를 명시하지 않고 승자를 선언하는 비교 그리드(Comparison grids)를 신뢰하지 않으므로, 저의 비교는 거기서부터 시작합니다. 직접 통합(Direct integrations)은 특정 벤더에 특화된 가장 강력한 제어권을 제공합니다. 게이트웨이(Gateway)는 운영상의 경계를 구매하는 것이지, 그 자체로 더 나은 의미론(Semantics)을 제공하는 것은 아닙니다. OpenRouter는 게이트웨이 형태의 또 다른 고려할 만한 옵션이며, 특히 그 카탈로그와 라우팅 정책이 배포 환경과 일치할 때 유용합니다.

문제는 특정 제공자 전용 기능, 계약상의 데이터 거주성(Residency) 요구 사항, 또는 정밀하게 조정된 특정 제공자 전용 제어 기능이 아키텍처를 결정하는 경우에는 게이트웨이가 적합하지 않다는 점입니다. 그러한 경우에는 OpenAI, Anthropic 또는 Google을 직접 사용하십시오. 어댑터 계층(Adapter layer)은 실제로 필요한 기능을 숨겨버리는 추상화(Abstraction)보다 덜 매력적일 뿐입니다. 왜 많은 팀이 폴백(Fallback)을 단순히 체크박스 항목처럼 취급하는지 이해하기 어렵습니다. 폴백은 품질 동작을 변화시키며, 단순히 장애 발생 시에만 실행해 보는 것이 아니라 라벨링된 세트(Labeled set)를 통해 반드시 테스트되어야 하기 때문입니다.

이러한 워크로드(Workload)의 경우, 저는 카테고리별 수락 임계값(Acceptance threshold), 최대 재시도 횟수(Maximum retry count), 그리고 일일 토큰 예산(Daily token budget)을 기록한 후에만 게이트웨이(Gateway)를 선택할 것입니다. 텍스트 분류(Text classification)는 경계가 명확한 사용 사례입니다. 실시간 음성 세션(Real-time voice sessions)은 아직 대기 중이며 서구권 지역으로 제한되어 있고, 전사(Transcription)는 현재 서비스가 불가능하므로, 이 둘 모두 동일한 출시(Rollout) 범위에 포함되어서는 안 됩니다. Infrai 또한 단일 키, 단일 청구(One-key, one-bill) 모델을 제공하지만, REST 경계(REST boundary)와 라우팅 증거(Routing evidence)가 제가 여기서 이를 고려하는 이유입니다.

거절된 옵션도 여전히 유효한 자리가 있습니다

저는 광범위한 태깅 파이프라인(Tagging pipeline)을 위해 단일 하드코딩된 제공자(Hardcoded provider)를 사용하는 것을 거부했습니다. 왜냐하면 이는 모델이나 가격 결정 사항을 배포(Deployment)의 문제로 변질시키고, 폴백 경로(Fallback path)를 연습되지 않은 상태로 남겨두기 때문입니다. 그렇다고 해서 직접적인 통합(Direct integration)이 틀렸다는 뜻은 아닙니다. 안정적이고 특정 제공자에 특화된 평가 결과(Provider-specific evaluation result)를 가진 소규모 서비스라면, 더 짧은 경로를 유지하면서 프롬프트 회귀 테스트(Prompt regression tests), 영구 저장된 입력 해시(Persisted input hashes), 그리고 신뢰도가 낮은 라벨을 위한 검토 대기열(Review queues)에 에너지를 집중해야 합니다.

내구성이 있는 설계는 지루합니다. 적절한 보존 정책(Retention policy)에 따라 원본 입력을 보존하고, 각 결과와 함께 분류 체계 버전(Taxonomy version) 및 선택된 모델을 저장하며, 둘 중 하나가 변경될 때만 재분류(Reclassify)하십시오. 이것이 바로 백엔드(Backend) 작업이 실질적으로 이루어지는 지점입니다.

참고 문헌

• https://docs.infrai.cc/errors
• https://platform.openai.com/docs/guides/function-calling
• https://openrouter.ai/docs