OpenRouter 요금 체계 분석: 요청 비용, 충전 수수료 및 BYOK

OpenRouter를 사용할 때 정확한 예산을 세우려면 처리된 요청에 따른 비용과 계정 잔액에 미리 충전하는 선불 자금을 명확히 구분해야 합니다. 또한 자체 공급자 API 키를 연동하는 경우 BYOK(Bring Your Own Key) 규칙을 독립적으로 검토해야 합니다. 단순히 공개된 “100만 토큰당 단가” 하나만으로는 이러한 모든 비용 요소를 설명할 수 없습니다.

모델 단가와 크레딧 충전은 서로 다른 항목

공식 FAQ에 따르면, 요청 비용은 선불 크레딧 잔액에서 차감되며 요율은 기본 모델 및 공급자에 따라 결정됩니다. OpenRouter는 추론에 대한 별도 마크업 없이 공급자 가격을 그대로 전달한다고 명시하고 있으며, 플랫폼 수수료는 크레딧을 구매할 때 발생합니다. 2026년 9월 14일 기준 가격 페이지에서 종량제(Pay-as-you-go) 결제에 대해 안내된 수수료는 5.5%입니다.

결제를 진행하기 전에 세 가지 항목을 반드시 대조해야 합니다. 충전되는 크레딧 금액, 화면에 표시된 수수료, 그리고 결제 수단에 최종 청구되는 금액입니다. 최소 결제 수수료, 적용 세금 또는 결제 수단별 추가 요금이 있는지 실시간 결제 창의 계산 내역을 확인하세요. 요금표에 명시된 비율이 최종 결제 금액을 대신하지는 않습니다.

단순화된 계산 예시를 들어보겠습니다. 만약 $100 상당의 크레딧을 구매하면서 5.5%의 플랫폼 수수료만 추가된다면 총 결제 금액은 $105.50가 됩니다. 이는 세금, 환전 수수료, 결제 처리 수수료 등을 제외한 순수 산술 예시이며 실제 결제 완료 화면과는 차이가 있을 수 있습니다. 이후 $20 상당의 크레딧을 사용했다면 남은 잔액은 $80가 되며, 초기 결제 금액 전체를 이 초기 요청들의 비용으로 기록해서는 안 됩니다.

실제 워크로드 비용 추정 방법

프롬프트 캐싱이나 추가 유료 기능이 없는 일반적인 텍스트 생성 시나리오의 계산식은 다음과 같습니다:

request_cost = input_tokens / 1000000 * input_price
             + output_tokens / 1000000 * output_price

2026년 9월 14일 현재 가격 카탈로그를 기준으로 확인한 GLM 그룹의 glm-5.3에 대한 실제 BetterToken 요율을 살펴보겠습니다. 100만 토큰당 미국 달러 기준으로 입력 가격은 $1.232, 출력 가격은 $3.872입니다. 캐시되지 않은 입력 8,000 토큰과 출력 2,000 토큰에 대한 계산 내역은 다음과 같습니다:

input_cost = 8000 / 1000000 * 1.232 = $0.009856
output_cost = 2000 / 1000000 * 3.872 = $0.007744
total_cost = $0.0176
1000_requests = $17.60

BetterToken은 이 비용에 별도의 거래 수수료를 추가하지 않습니다. 따라서 동일한 규모의 요청 1회 비용은 $0.0176이며, 동일한 요청 1,000회 비용은 $17.60로 유지됩니다. 여기에 1.055를 곱할 필요는 없습니다. OpenRouter의 충전 수수료는 BetterToken에 적용되지 않기 때문입니다. 이 시나리오의 토큰 수는 이해를 돕기 위한 예시이며, 가격은 가상의 모델이 아닌 실제 운영 카탈로그에서 직접 가져왔습니다. 캐시된 토큰과 추가 도구 호출은 이 계산에 포함되지 않았습니다. 이는 BetterToken의 계산 예시일 뿐이며, OpenRouter의 GLM-5.3 실제 가격과 직접 비교한 것은 아닙니다.

이러한 계산을 실무 운영 예산으로 전환하려면 전체 대화 기록과 시스템 프롬프트를 포함하여 실제 요청 크기를 측정해야 합니다. 짧은 프롬프트 질의와 긴 컨텍스트 처리를 별도로 구분하여 집계하세요. 자율 에이전트(Autonomous Agent)의 경우 최종 응답에 대해서만 예산을 책정하지 말고, 최종 결과물이 승인될 때까지 발생한 모든 중간 호출을 합산해야 합니다. 만족스럽지 못한 응답으로 인해 재시도가 발생하고 이로 인해 유료 API 호출이 이루어졌다면, 이 역시 지출 내역에 반드시 반영해야 합니다.

프롬프트 캐싱, 이미지 입력, 추론 토큰(reasoning tokens), 요청당 추가 요금 등으로 인해 비용 계산이 달라질 수 있으므로 모델 카드에 명시된 구체적인 과금 단위를 확인하세요. 사용량은 Activity 로그를 통해 검토할 수 있습니다. BetterToken과 비교하려면 가격 페이지와 모델, 토큰 수, 지출 내역을 확인할 수 있는 Workspace의 자체 사용량 기록을 참고하세요. 항상 동일한 작업 부하와 동일한 과금 단위를 기준으로 평가해야 합니다. 서로 다른 두 가격표를 단순히 비교하는 것만으로는 어느 쪽이 더 비용 효율적인지 증명할 수 없습니다.

무료 티어가 무제한 처리를 의미하지는 않는다

가격 페이지에는 무료 플랜에 대해 하루 50회 요청 한도가 명시되어 있습니다. 이 할당량이 모든 계정 유형이나 유료 폴백 경로에 동일하게 적용된다는 보장은 아닙니다. 요청 제한 문서에서는 지출 한도(spending limits)와 요청 속도 제한(request velocity limits)을 구분합니다. HTTP 402 오류는 계정 잔액과 API 키 한도 확인이 필요함을 의미하며, HTTP 429 상태 코드는 OpenRouter 플랫폼 또는 상위 공급자로부터 발생할 수 있습니다.

HTTP 429 오류가 발생하면 응답 본문과 Retry-After 헤더(제공되는 경우)를 확인하고 재시도 사이에 백오프(backoff) 지연 시간을 적용하세요. 무제한 재시도 루프를 작성해서는 안 됩니다. 라우팅 규칙이 유료 모델로 폴백되는 구조라면 배포 전에 해당 모델의 비용을 예산에 반영해 두어야 합니다. 무료 경로는 호환성을 검증하는 데 유용하지만, 프로덕션 환경의 워크로드에는 속도 제한 소진이나 서비스 장애에 대비한 명확한 운영 대응 전략이 필요합니다.

BYOK: 두 청구서를 모두 검증해야 한다

BYOK(Bring Your Own Key)는 자체 상위 공급자 API 키를 사용하여 OpenRouter를 통해 요청을 라우팅하는 방식입니다. 2026년 9월 14일 기준 가격 페이지에 따르면, 종량제(Pay-as-you-go)는 정가 기준 월 최대 $25,000의 추론에 대해 BYOK 수수료가 면제되며, 이후 5%의 플랫폼 수수료가 적용됩니다. 이 금액은 수수료 면제를 위한 기준 금액일 뿐이며, 무료 요청 횟수를 의미하거나 OpenRouter가 상위 공급자 청구서를 대신 납부해 주는 것은 아닙니다.

키 관리는 작업 공간 BYOK 인터페이스에서 수행됩니다. BYOK 문서에 따르면 요청 라우팅은 정해진 계층 순서를 따릅니다. 트래픽은 설정된 우선순위 키(Prioritized keys)를 우선 사용하고, 필요한 경우 공유 OpenRouter 엔드포인트(shared OpenRouter endpoints)로 전환되며, 최종적으로 모델 필터와 라우팅 제약 조건을 고려하여 대체 키(Fallback keys)로 라우팅됩니다. 공유 용량으로 폴백되면 OpenRouter 크레딧 잔액이 소진됩니다. 또한 작업 공간 예산과 가드레일 예산(guardrail budgets)은 기본적으로 BYOK 지출을 제외하므로, 필요한 경우 “Include BYOK spend” 설정을 명시적으로 활성화해야 합니다.

BYOK 파이프라인을 설정하고 검증하려면 다음 순서를 따르는 것이 좋습니다:

1. 권한 및 필터 확인: 공급자 API 키에 필요한 모델 권한이 있는지 확인하고 OpenRouter에서 이에 맞는 모델 필터를 구성합니다.
2. 키 우선순위 정책 설정: 키 간의 우선순위를 정의하고, 요청이 공유 OpenRouter 엔드포인트나 Fallback keys로 전환될 수 있는지 여부를 결정합니다.
3. 예산 할당 분리: 지출 한도를 독립적으로 계획합니다. 즉, 상위 공급자(upstream) 쪽에 직접 설정하는 한도와, 무료 한도 초과 시의 수수료나 폴백 용량을 충당하기 위한 OpenRouter 잔액을 구분하여 관리합니다.
4. 단일 테스트 요청 실행: 제한된 호출을 한 번 보내고, Activity 로그에서 원시 메타데이터 보기(View Raw Metadata)를 열어 provider_responses 블록을 확인한 후 기록된 데이터가 실제 공급자 청구서와 일치하는지 대조합니다. 직접 확인하지 않고 자동화된 비용 추적이 상위 청구서와 완벽히 일치할 것이라고 넘겨짚어서는 안 됩니다.

단일 직접 API로도 운영 요구 사항을 충분히 충족할 수 있다면 해당 API의 월간 청구서와 동일한 작업량을 OpenRouter를 통해 라우팅했을 때의 비용을 비교해 보세요. 여러 모델에 걸친 이중화나 동적 라우팅이 필요한 경우라면 통합 결제 및 표준화된 엔드포인트가 제공하는 아키텍처적 편의성을 함께 고려해야 합니다. 초기 평가 단계에서는 제한된 소규모 테스트 배치만으로도 충분합니다. 단순히 기본 토큰 단가를 비교하는 것보다 채택된 결과물 하나당 소요된 총비용을 확인하는 것이 훨씬 더 유용한 통찰을 제공합니다.