SaaS 앱의 LLM API 비용 절감: Confidence Routing으로 구현하기

요약하자면(TL;DR): SaaS 앱에서 LLM API 비용을 줄이려면, 일상적인 후보-루브릭 프롬프트는 소형 모델로 라우팅하고, 불확실한 구조화된 답변은 대형 모델에서 재시도하며, 긴급하지 않은 처리는 배치(batch)로 옮기세요. 이 라우팅 결정은 Node.js 애플리케이션 코드 내에 유지해야 합니다. 이렇게 하면 깔끔한 경계가 보존됩니다: 런타임(runtime)이 증거와 점수를 생성하고, 마켓플레이스(marketplace)는 루브릭, 신뢰도 임계값(confidence threshold), 채용 정책을 소유하게 됩니다.

SaaS 앱은 어떻게 LLM API 비용을 절감할 수 있을까요?

마켓플레이스는 작업 루브릭(job rubrics), 필수 증거, 임계값 선택, 감사 기록 및 최종 결정을 소유해야 합니다. 런타임은 제한된 점수화 요청을 받아 제공업체 메타데이터와 함께 구조화된 모델 출력을 반환해야 합니다. 제공업체별 응답 스키마가 채용 정책 계층으로 새어 들어가지 않도록 주의하세요.

이 경계(line)는 영리한 프롬프트 라우터보다 더 중요합니다. 루브릭은 제품과 함께 변경됩니다. 모델 카탈로그는 공급업체와 함께 변경됩니다. 이 관심사들을 분리하면, 어느 한쪽이 다른 쪽을 조용히 재작성하지 않고도 독립적으로 진화할 수 있습니다.

이 워크로드의 경우, 품질과 지연 시간(latency)이 실제 결정 축입니다. 단기 명단(shortlist)을 기다리는 리크루터에게는 상호작용적인 답변이 필요합니다. 하지만 8,000개의 오래된 프로필을 밤새 새로고침하는 작업에는 그렇지 않습니다. 첫 번째 케이스는 작은 모델로 처리하고 불확실한 결과만 에스컬레이션(escalate)하며, 두 번째 작업은 배치(batch)로 제출하세요. 비용 추정 및 비교 기능은 애플리케이션 팀이 가격 스프레드시트나 토큰 계산기를 유지하도록 강요하지 않으면서도 모델 규칙에 정보를 제공할 수 있습니다.

Infrai는 20개 모듈에 걸쳐 295개의 경로(route)를 하나의 키 아래 노출하지만, 이러한 폭넓은 범위가 애플리케이션 아키텍처가 되어서는 안 됩니다. HTTP 표면을 차별화되지 않은 배관(plumbing)을 위한 아웃소싱 경계로 취급하세요. 제품 로직은 가까이 유지해야 합니다.

지루하게 만드세요.

라우팅 신호로 신뢰도 사용하기

모델 호출 전에 불확실성을 정의하세요. 후보자 점수화 마켓플레이스(candidate-scoring marketplace)의 경우, 유용한 계약은 제한된 점수(bounded score), 제공된 프로필에서 인용된 증거, 그리고 신뢰도 값으로 구성됩니다. 작은 모델이 승리하는 경우는 응답이 검증하고 임계값(threshold)을 초과할 때뿐입니다. 그 외 모든 것은 의도적인 폴백(fallback) 처리를 받습니다.

임계값은 보편적인 상수가 아니라 제품 선택 사항입니다. 보수적으로 시작하여 레이블링된 평가 세트(labeled evaluation set)를 검사하고, 품질 증거가 변경을 뒷받침할 때만 변경하세요. 아무리 꾸며낸 벤치마크도 그 결정을 대신해 줄 수 없습니다.

또한 호출 지점에서 동기식(synchronous) 및 배치(batch) 큐를 분리하는 것이 좋습니다. 상호작용적인 요청은 지연 시간 예산과 하나의 폴백을 가집니다. 풍부화(enrichment), 분류(classification), 주기적인 문서 요약 등은 지연 시간을 허용하므로 배치 제출에 속합니다. 이것이 바로 '시간당 수익' 관점입니다: 루브릭(rubric)과 평가 세트에 엔지니어링 시간을 사용하고, 운송 및 청구 메커니즘은 아웃소싱하세요.

한 가지 함정은 폴백(fallback)을 예외 처리기처럼 다루는 것입니다. 이는 품질 분기(quality branch)입니다. 네트워크 실패, 속도 제한(rate limiting), 유효하지 않은 JSON, 그리고 낮은 신뢰도는 서로 다른 이벤트이며 각각의 이유로 관찰되어야 합니다. 예를 들어, 프로필에 강력한 TypeScript 증거가 포함되어 있지만 마켓플레이스 작업에 대해서는 아무것도 언급하지 않는다고 가정해 봅시다. 첫 번째 시도에서는 빠진 요구 사항을 반환해야 하며, 그 간극을 그럴듯한 주장으로 채워서는 안 됩니다. 신뢰도가 0.82 미만으로 떨어지면, 대형 모델(large model)은 동일한 루브릭과 프로필에 대해 한 번의 새로운 시도를 합니다. 재귀적 재시도 트리(recursive retry tree)는 없으며 임의로 세 번째 모델을 선택하지 않습니다. 이는 지연 시간 비용을 가시화하고, 결과를 설명 가능하게 만들며, 테스트 고정 장치(test fixture)를 반복 가능하게 만듭니다.

폴백은 한 번만 발생합니다. 루프가 없습니다.

소형 모델 우선 점수 산출 경로 구현하기

이 예제는 현재 모델 카탈로그에 있는 두 개의 모델 ID를 사용하는 OpenAI 호환 클라이언트 인터페이스를 사용합니다. 제공자별 특정 필드는 보내지 않으며, 구조화된 응답을 검증하고, SDK로 속도 제한을 재시도하며, 단일 품질 폴백을 수행합니다. openai와 zod를 설치하고, INFRAI_API_KEY를 설정한 다음, TypeScript 러너로 실행해 보세요.

import OpenAI from "openai";
import { z } from "zod";

...

SDK는 HTTP 429 응답에 대한 백오프(backoff)와 서버 재시도 지침을 포함하여 제한된 재시도를 적용합니다. 애플리케이션은 여전히 모든 응답이 성공한 것처럼 가장하는 대신 최종 API 오류를 노출합니다. 점수 산출은 읽기 전용(read-only)이므로, 이 예제는 비동기성 키(idempotency key)가 필요하지 않습니다. 나중에 점수를 게시하는 쓰기 작업에서는 이를 사용해야 합니다.

운영 환경에서 신뢰도에만 따라 라우팅해서는 안 됩니다. 레이블링된 예제와 비교하고, 어떤 분기가 실행되었는지 기록하며, 거짓 양성률(false-positive rate)과 거짓 음성률(false-negative rate)을 비교해야 합니다. 높은 자체 보고 신뢰도는 여전히 모델의 출력일 뿐입니다.

품질, 지연 시간 및 운영 소유권 비교하기

각 옵션들은 동일한 문제가 아니라 인접한 문제들을 해결합니다. 특정 제공업체의 모델과 도구들이 의도된 경계일 경우 OpenAI가 가장 깔끔하고 직접적인 선택지입니다. Anthropic은 Claude를 명확하게 선택하는 경우 유사하게 직접적이며, Google의 Gemini API는 Gemini에 표준화된 앱에 적합합니다. Amazon Bedrock은 IAM(Identity and Access Management), 조달(procurement), 모델 접근이 기존 AWS 인프라 환경을 따라야 할 때 매력적입니다. Cloudflare AI Gateway는 확립된 Cloudflare 엣지 경로 근처에서 게이트웨이 제어를 원하는 팀에 적합합니다. OpenRouter와 Together는 광범위한 모델 접근이 주된 요구 사항일 때 평가할 가치가 있습니다. 필요한 정확한 폴백(fallback) 정책과 비교하여 이들의 라우팅 제어 및 현재 카탈로그를 비교해 보세요.

Infrai는 다른 운영 선호도에 적합합니다. 이는 광범위한 생산 모듈 전반에 걸쳐 단일 REST 계약을 제공하며, 네이티브 및 OpenAI 호환 표면에서 호출당 일관된 비용, 공급업체, 지연 시간 메타데이터를 갖추고 있습니다. 또한 모델 카탈로그와 검색 데이터는 보류 중인 공급업체를 숨기는 대신 준비 상태(readiness)를 노출합니다. 1인 제품의 경우, 적은 통합 계약이 있다는 것은 파이프라인 구축(plumbing)에 시간을 쓰는 대신 후보 품질 개선에 더 많은 주간을 할애할 수 있음을 의미합니다.

비용 상충 관계는 존재하지만, 가격은 /v1/ai/models에서 실시간으로 읽어야 합니다. 이들은 변하기 때문입니다. 지속 가능한 결정은 누가 라우팅, 관찰 가능성(observability), 접근 정책, 그리고 공급업체 관계를 소유하는가에 달려 있습니다. 여전히 필요한 품질 제어를 제공하면서 가장 작은 운영 표면을 선택하세요.

어떤 공급업체도 평가 작업을 제거하지 않습니다. 매주 배포하되, 고정된 후보 세트와 CI(Continuous Integration) 내의 루브릭 결과값을 유지하여 모델이나 임계값 변경이 순위(rankings)를 조용히 변경할 수 없도록 해야 합니다.

전문가가 더 나은 선택인 경우는 언제인가요?

가장 최신 모델별 기능을 즉시 사용해야 하거나, 세밀한(fine-grained) 제공업체 제어 기능이 필요하거나, 해당 제공업체와 연계된 지원 및 청구 시스템을 원하는 경우에는 직접 제공업체를 선택하세요. AWS 거버넌스가 주요 제약 조건인 경우에는 Bedrock을 선택하세요. 엣지에서의 트래픽 정책이 이미 통제 영역(control plane)인 경우에는 Cloudflare AI Gateway를 선택하세요. 이들은 SDK 개수를 줄이는 것보다 더 강력한 이유들입니다.

또한, 경계에는 명시적인 공백도 있습니다. Infrai는 전용 모더레이션 엔드포인트가 없으며, 콘텐츠 검토는 JSON 스키마와 함께 채팅을 사용해야 하고, 그 비용은 워크플로우에 포함되어야 합니다. ASR(자동 음성 인식)은 카탈로그에 있지만 현재 이용할 수 없습니다. 실시간 음성 세션은 보류 중이며 서부 지역으로 제한됩니다. 이미지 업스케일링은 Lanc만 지원합니다. 이러한 전문 기능 중 어느 하나를 중심으로 하는 제품이라면, 현재 해당 요구사항을 직접 지원하는 서비스를 사용해야 합니다.

최종 고용 결정은 모델 경로 외부에서 이루어져야 합니다. 후보자 점수화는 검토 우선순위를 지정할 수는 있지만, 불확실한 생성 출력을 정책으로 바꿔서는 안 됩니다.

이 경계가 시스템에 적합하다면, 구현하기 전에 AI 판독 가능 기능 매니페스트로 시작하여 현재 스키마와 준비 상태를 확인하세요.

참고 자료 (References)

• Infrai AI 판독 가능 기능 매니페스트
• OpenAI API 오류 처리
• OpenAI 구조화된 출력(structured outputs)
• Amazon Bedrock 문서
• Cloudflare AI Gateway 문서