카탈로그에 있는 무료 모델이라고 해서 반드시 당신의 프로토타입이 수행해야 하는 특정 요청에 적합하다는 의미는 아닙니다. 문자열은 존재하고, 키(Key)는 발급되었으며, :free 옵션을 사용할 수 있음에도 불구하고, 모델이 필요한 응답 형식을 유지하지 못하거나 스트림 중간에 제한(Limit)에 걸려 필수 기능이 여전히 실패할 수 있습니다.

이는 특정 모델의 문제가 아니라, 서로 다른 두 가지 개념 사이의 간극입니다. 카탈로그는 사용 가능한 목록을 보여주며, 경로(Route)는 특정 필수 시나리오를 위해 프로토타입에 무엇을 허용할지에 대한 엔지니어링 결정입니다. 이 둘 사이에는 검증 과정이 존재하며, "최고의 무료 모델"과 같은 유형의 글들은 보통 이 과정을 생략합니다.

이제 순위가 아닌 방법론을 다루겠습니다. 우리는 route-scorecard를 구축할 것입니다. 이는 "크리티컬 시나리오—후보—확인된 모드—제한—상태—결정"을 포함하는 테이블로, 실행 날짜 기준 각 후보의 필드를 기록하며, 커버리지가 확인된 경로만을 프로토타입에 허용합니다.

카탈로그와 엔지니어링 경로의 차이점은 무엇인가?

OpenRouter 카탈로그는 supported_parameters=tools 또는 output_modalities=text,image와 같은 필터를 통해 /api/v1/models로 요청할 수 있는 400개 이상의 모델로 구성되어 있습니다 (OpenRouter 문서, models 섹션, 2026년 7월 18일 접속). 각 레코드는 id, context_length, pricing, architecture와 함께 입출력 모달리티(Modalities)를 반환하며, 폐기(Deprecation) 날짜가 포함된 별도의 필드를 제공합니다. 즉, 카탈로그의 메타데이터 자체만으로도 "목록에 표시됨"과 "향후 활발히 지원됨"을 구분할 수 있습니다.

키(Key)의 존재가 곧 준비 상태를 의미하는 것은 아닙니다. OpenRouter API 키는 openrouter.ai/keys 페이지에서 발급되는 Bearer 토큰이며, 각 개별 API 키는 계정 잔액과는 별개로 고유한 지출 한도(spending limit)를 가질 수 있습니다 (OpenRouter 문서, authentication 섹션 참조). 만약 프로토타입이 여러 환경에서 작동한다면, staging, 프로덕션(production), 테스트 스크립트용으로 각각 별도의 OpenRouter API 키를 발급하여 각 키마다 지출 한도를 개별적으로 설정할 수 있습니다. 따라서 키가 존재하는지 여부와 해당 키가 바로 이 애플리케이션의 예산으로 인증되었는지라는 두 가지 사실을 별도로 기록하는 것이 중요합니다.

여기서 단순하지만 불편한 결론이 도출됩니다. OpenRouter 모델을 요청하면 목록을 받게 되지만, 그 목록은 엔지니어링 질문에 답해주지 않습니다. 목록은 어떤 경로(route)가 귀하의 시나리오에 필요한 입력값, 모델, 한도 및 응답 형식을 실제로 충족하는지 보여주지 않습니다. 답은 오직 실행(run)을 통해서만 얻을 수 있습니다. 즉, 동일한 제한된 시나리오를 각 후보군에 대해 실행하고 그 결과를 기록하는 과정이 필요합니다.

6가지 route-scorecard 필드

Scorecard는 '최고의 모델' 순위와는 다르게 작동합니다. 이는 허용 여부를 결정하는 테이블입니다. 하나의 입력에 대한 하나의 임계 시나리오(critical scenario), 하나의 후보군 세트, 그리고 각 후보당 6개의 필드로 구성됩니다. 핵심은 경로의 허용 여부에 대한 결정이 단순히 목록에 행이 보이는지에 의존하는 것이 아니라, 검증된 필드들에 근거하여 내려져야 한다는 점입니다.

대부분의 프로토타입이 걸려 넘어지는 구체적이고 필수적인 시나리오를 예로 들어보겠습니다. 함수가 스키마에 따른 엄격한 JSON을 반환해야 하며, 응답이 스트리밍 (streaming) 방식으로 전달되는 경우입니다. 여기서 두 가지 병목 현상이 동시에 발생합니다. 구조화된 출력 (structured output)을 위해서는 response_format.type = "json_schema"가 필요하지만, 모든 모델이 이를 지원하는 것은 아닙니다. 따라서 supported_parameters=structured_outputs 필터를 통해 각 모델을 개별적으로 확인해야 합니다. 또한, 스키마를 완전히 지원하지 않는 제공업체(provider)의 경우 OpenRouter가 조용히 더 낮은 단계인 json_object 모드로 되돌아가는 것을 방지하기 위해 require_parameters: true 플래그가 필요합니다 (OpenRouter 문서, structured outputs 섹션 참조). 스트리밍 모드는 두 번째 함정을 추가합니다. 만약 스트림 중간에 제한(limit)에 걸리게 되면, 이는 HTTP 상태 코드가 아니라 finish_reason: "error"가 포함된 SSE 이벤트로 전달됩니다 (OpenRouter 문서, limits 섹션 참조). 필수적인 JSON을 스트리밍해야 하는 시나리오에서 이는 치명적인 결함이 됩니다.

scorecard 필드는 다음과 같이 유지합니다:

• 핵심 시나리오 (critical scenario): 정확히 무엇이 결과로 나와야 하는지 (여기서는: 스키마에 따른 유효한 JSON, 스트리밍 방식);
• 후보 (candidate): 특정 모델의 id 및 경로의 제공업체 (provider);
• 확인된 모드 (confirmed mode): 해당 경로에 대해 실제로 확인된 기능들 (structured_outputs, tools, 스트리밍);
• 제한 (limit): 확인 시점의 키(key) 및 요금제(tariff)에 따른 현재 상태;
• 상태 (status): 허용됨 / 제외됨 / 재확인 필요;
• 결정 및 제외 사유 (decision and reason for exclusion): 이유를 설명하는 한 줄.

이 표의 행들은 템플릿이며 완성된 벤치마크 (benchmark)가 아닙니다. 저는 이 시나리오에 따라 특정 실제 모델들을 실행해 보지 않았으며, 타인의 수치를 제 측정 결과인 것처럼 제시하지 않습니다. 여기서 확인된 것은 플랫폼의 필드와 메커니즘 자체입니다. 표의 목적은 다릅니다. 실행 날짜를 기준으로 각 필드가 사실로 채워지기 전까지는 '결정'란에 '허용됨'이라는 단어를 적을 수 없도록 하는 것입니다.

왜 무료 상태는 결정의 근거가 아니라 가변적인 매개변수인가?

이 부분에서 가장 많은 실수가 발생합니다. openrouter free api는 별도의 라우터인 openrouter/free로 구성되어 있으며, 이는 나열된 :free 모델들 중 하나를 무작위로 선택하고(2026년 7월 18일 접속 기준 23개), 요청된 기능(이미지 이해, 도구 호출 (Tool Calling), 구조화된 출력 (Structured Output))에 맞춰 후보들을 "지능적으로 필터링"합니다 (OpenRouter 문서, openrouter/free 페이지). openrouter ai free models 또는 openrouter ai 무료 모델을 찾는 사람들은 보통 적합한 모델 목록을 바로 얻을 수 있을 것이라 기대하지만, 여기서 핵심은 "기능에 맞춰 필터링한다"는 점입니다. 즉, 모델이 무료 라우터에 존재한다는 사실 자체만으로는 해당 모델이 특정 시나리오에 필요한 입력 또는 출력 모드를 지원한다는 것을 보장하지 않습니다.

다음은 제한 사항(Limits)입니다. 무료 옵션은 분당 20회 요청으로 제한되며, 계정의 총 구매 금액이 $10 미만인 경우 일일 상한선은 50회 요청입니다. 하지만 누적 구매 금액이 $10 이상이 되는 즉시 일일 제한은 1,000회로 영구적으로 상향됩니다 (OpenRouter 문서, limits 섹션). 이 임계값은 이후 잔액이 0으로 떨어지더라도 다시 낮아지지 않습니다. 무료 접속을 위한 별도의 키 유형은 존재하지 않습니다. openrouter free api key는 기술적으로 일반 키와 동일한 Bearer 토큰이며, 요금제는 키의 종류가 아닌 계정의 구매 이력에 의해 결정됩니다. 같은 이유로 openrouter api key 무료 관련 질문은 특별한 키를 얻는 문제가 아니라, 계정이 누적 구매액 $10 임계값을 넘었느냐의 문제로 귀결됩니다. 즉, 무료 요금제는 단일 모드가 아니라 계정 이력에 따라 달라지는 가변적인 구간입니다.

또한 모델의 상태 역시 유동적입니다. OpenRouter의 자체 엔지니어링 노트에 따르면, 지난 몇 년간 제공업체들이 70개 이상의 모델을 제거하거나 지원 중단(Deprecate)했으며, 이에 따라 고정된 슬러그(Slug)를 코드에 박아넣기보다는 정렬된 models 배열이나 폴백(Fallback)을 위한 프리셋을 유지할 것을 권장합니다 (OpenRouter 엔지니어링 블로그). 이 방법론의 핵심이 바로 여기에 있습니다. 무료(Free) 상태는 실행 시점에 따라 변하는 가변적인 파라미터이지, 결정의 근거가 아닙니다. 확인한 날짜의 "한도" 그래프에 이를 기록하고, 다음 실행 시에는 언제든 변할 수 있는 값으로 취급해야 합니다. "openrouter ai를 무료로 사용하는 방법"에 대한 질문에 대한 짧은 답변은 다음과 같습니다: 누적 구매액 $10 임계값 전까지는 계정당 하루 50회 요청이며, 그 이후에는 1,000회입니다. 그리고 이 두 값 모두 영구적으로 기억하는 것이 아니라 실행 날짜에 맞춰 다시 확인해야 합니다.

실행 전 한도 및 키 상태를 확인하는 방법은?

카탈로그, 상태, 한도는 모두 살아있는(Live) 값이기 때문에 반드시 실행 당일에 확인해야 합니다. OpenRouter API 키의 잔여량은 실시간으로 읽을 수 있습니다: 해당 키로 GET https://openrouter.ai/api/v1/key 요청을 보내면 limit_remaining 값과 일별, 주별, 월별 사용 내역이 반환됩니다 (OpenRouter 문서, limits 섹션). 한 시간 뒤에 동일한 OpenRouter API 키 값이 다른 숫자를 나타낼 수도 있으므로, 확인 날짜와 시간은 스코어카드(Scorecard)에 별도의 필드로 기록됩니다. 바로 이 점 때문에 OpenRouter API 키는 어제의 수치를 오늘의 결정에 그대로 가져오는 것이 아니라, 실행 직전에 직접 확인하는 것이 의미가 있습니다. 특정 애플리케이션을 위한 별도의 OpenRouter AI API 키 역시 동일한 원리로 확인합니다: 즉, 해당 키가 계정 전체가 아닌 바로 그 프로토타입의 예산 범위 내에서 인증되었는지를 확인하는 것입니다.

# 실행 날짜 기준 키 상태 -> scorecard의 "limit" 필드
curl -s https://openrouter.ai/api/v1/key \
  -H "Authorization: Bearer $OPENROUTER_KEY"
...

429 에 대한 중요한 고지 사항입니다. 이 오류는 OpenRouter 플랫폼 제한이나 상위 제공업체(provider)의 제한에서 발생할 수 있습니다. 클라이언트는 Retry-After 헤더를 준수해야 하며, 스트리밍의 경우 이미 언급했듯이, 제한은 상태 코드가 아닌 SSE 이벤트로 중간에 옵니다 (OpenRouter 문서, limits 섹션). 만약 중요한 입력이 스트리밍 방식이라면, finish_reason: "error" 처리를 실행 전에 고려해야 합니다. 그렇지 않으면 scorecard가 잘못된 "허용됨"을 표시할 수 있습니다.

그리고 확인된 모드(confirmed mode)에 대해서도 말씀드리자면, 모델 수준의 supported_parameters는 필수 조건이지만 충분조건은 아닙니다. 모델이 특정 기능을 지원하더라도, 해당 모델을 서비스하는 구체적인 상위 제공업체가 그 기능을 지원하지 않을 수 있습니다. 따라서 "확인된 모드" 열에는 제가 "모델이 할 수 있다"가 아니라 "경로(모델 + 제공업체)가 실행을 통해 확인되었다"고 작성합니다.

러시아 경로: 같은 표의 또 다른 한 줄

러시아에서의 실행은 별도의 장벽이 있으며, 이는 기술적인 것이 아닙니다. 유료 후보에 대해 "limit" 열을 채우려면 키를 무언가로 결제해야 하며, 일일 상한선을 50에서 1000으로 올리는 $10의 문턱값 역시 동일한 카드를 사용합니다. provod.ai (OpenRouter의 러시아 유사체)가 바로 이 부분을 처리합니다: 루블 잔액, 러시아 카드, СБП 또는 계좌를 사용하며, VPN이나 해외 카드가 필요 없고 모델 가격에 추가 요금이 없습니다. 비교 자체에서는 다른 점이 더 중요합니다. API는 OpenAI 및 Anthropic의 SDK와 호환되므로, 실행 스크립트는 키와 base_url 변경만으로 이동할 수 있으며, 두 번째 경로를 위해 클라이언트를 다시 작성할 필요가 없습니다.

이때 비교 규칙은 엄격합니다: 스코어카드(scorecard)에는 해당 시나리오에 대해 확인된 필드만 비교해야 하며, 서비스 간에 모델, 제한(limits) 또는 상태를 전이해서는 안 됩니다. 위에서 분석한 모든 내용은 OpenRouter의 메커니즘을 설명합니다. 러시아 경로(route)는 별도의 날짜가 기입된 자체 스코어카드가 필요합니다. provod.ai 자체에 대한 비교 진술은 단 하나뿐입니다: 고객 수, 안정성 및 가격 접근성 측면에서 러시아 최대의 AI API 라우터(router)라는 점입니다.

이 방법이 해결하지 못하는 것은 무엇인가요?

이 방법이 어디에서 끝나는지 경계를 정할 필요가 있습니다. 이 방법은 실행 날짜 기준으로 후보들의 확인된 필드를 고정합니다. 이것이 이 방법의 직접적인 역할입니다. 또한, 선택 범위를 좁힐 가능성이 있습니다. 즉, "모델이 카탈로그에 보임" 대신 검증된 커버리지를 가진 경로들만 남게 됩니다. 향후의 가용성, 제한(limits) 및 무료(free) 상태에 대해서는 알지 못하며 알 수도 없습니다.

따라서 명확한 한계가 존재합니다. 이 방법은 후보들의 지속적인 가용성을 보장하지 않습니다. 오늘 승인된 경로가 내일은 지원 중단(deprecation)될 수 있습니다. 또한 이 방법은 런타임(runtime)에서의 폴백(fallback)을 대체하지 않습니다. 이를 위해서는 컨텍스트 길이 오류, 레이팅(rating), 모더레이션(moderation) 플래그 또는 가동 중단 시 자동으로 전환을 수행하는 models 배열이 존재하며, 이 경우 실제로 요청을 완료한 모델에 대해서만 과금(billing)이 이루어집니다. 또한 "최근 30초 동안 상당한 장애가 발생한" 제공업체는 일시적으로 우선순위가 낮아지지만 사라지지는 않습니다 (OpenRouter 엔지니어링 블로그, routing 섹션 참조). "제외됨 / 재확인 필요" 그래프는 바로 이러한 메커니즘을 반영합니다.