OpenRouter와 직접 호출 비교: LLM 호출 방식 선택하기

LLM 호출을 구현하는 세 가지 방식

1) 제공업체 API 직접 사용

단일 공급업체의 엔드포인트와 통합하고, 나머지는 직접 책임집니다. 재시도, 대체 처리, 사용량 추적, 키 교체, 장애 조치가 여기에 포함됩니다.

다음과 같은 경우에 가장 간결한 방식입니다:

• 사용할 모델을 이미 알고 있고,
• 지연 시간이 중요하며,
• 규정 준수 측면에서 공급업체 체인을 더 단순하게 유지해야 하고,
• 트래픽이 충분히 일정하여 한 제공업체의 한도를 기준으로 계획할 수 있는 경우입니다.

2) 게이트웨이 / 통합 서비스 / 릴레이

여러 제공업체 중 하나로 요청을 전달하는 중간 계층에 요청을 보냅니다. OpenRouter가 가장 잘 알려진 사례이지만, 이 방식은 특정 기업 하나에만 국한되지 않습니다.

다음과 같은 경우에 매력적인 방식입니다:

• 한 번의 통합으로 다양한 모델을 선택하고 싶거나,
• 대체 모델로의 라우팅이 필요하거나,
• 모델 실험을 자주 수행하거나,
• 여러 공급업체의 SDK와 결제 계정을 관리하고 싶지 않은 경우입니다.

3) 자체 호스팅

자체 인프라에서 개방형 모델을 실행하며, 보통 자체 라우터를 통해 제공합니다.

다음과 같은 경우에 가장 유리합니다:

• 데이터에 대한 통제권을 타협할 수 없거나,
• 하드웨어를 계속 활용할 만큼 사용량이 많거나,
• 토큰당 비용을 예측할 수 있어야 하며 운영 부담을 감당할 수 있는 경우입니다.

실제로 달라지는 점

사람들이 놓치는 부분은 다음과 같습니다: 최선의 선택은 대개 단순한 토큰 가격만으로 결정되지 않습니다. 장애가 이어지는 전체 과정이 중요합니다.

이 표에는 중요한 사실이 가려져 있습니다: 게이트웨이가 마법처럼 비용을 절감해 주는 경우는 드뭅니다. 과도한 설계를 방지하거나, 서비스 중단 시간을 줄이거나, 작업을 요구 수준을 충족하는 가장 저렴한 모델로 자동 라우팅할 수 있게 할 때 비용이 절감됩니다.

실제로 비용이 달라지는 지점

모든 작업에 단일 모델을 사용한다면 직접 호출이 가장 간단하고 저렴한 경우가 많습니다. 하지만 실제 시스템 대부분은 더 복잡합니다:

• 제품 내 채팅에는 고급 모델을 사용하고,
• 고객 지원 답변 초안에는 더 저렴한 모델을 사용하며,
• 요약에는 작고 빠른 모델을 사용하고,
• 트래픽이 급증할 때는 초과 트래픽을 처리할 용량이 필요합니다.

이럴 때 중계 서비스가 도움이 될 수 있습니다. 표시 가격이 더 낮아서가 아니라 라우팅 결정을 중앙에서 내릴 수 있기 때문입니다.

간단한 정책은 다음과 같을 수 있습니다.

{
  "primary": "anthropic/claude-sonnet-4.6",
  "fallbacks": [
    "openai/gpt-5.5",
    "google/gemini-3"
  ],
  "cheap_path": "openai/haiku-class",
  "timeout_ms": 8000,
  "retry_on": ["rate_limit", "timeout", "upstream_5xx"]
}

이 구성은 특정 공급업체에 종속된 것이 아니라 합리적인 라우터의 기본 형태입니다. 실제로 비용은 낭비를 줄일 때 절감됩니다:

• 모든 추출 작업을 가장 비싼 모델로 보내지 마세요.
• 불안정한 제공업체에 대한 재시도를 끝없이 반복하지 마세요.
• 금요일에 급증하는 트래픽 2%만을 위해 별도의 연동을 계속 유지하지 마세요.

흔히 놓치는 함정이 있습니다: 앱에 도구 호출이나 부수 효과가 있다면 재시도로 인해 작업이 중복 실행될 수 있습니다. 게이트웨이가 시간 초과 후 요청을 재시도하면 모델이 동일한 함수 호출을 다시 출력할 수 있습니다. 멱등성 키와 신중한 도구 설계가 없으면 “유용한 대체 처리”가 “티켓 중복 생성”이나 “결제 이중 청구”로 이어집니다.

게이트웨이가 실질적으로 도움이 되는 경우

다음 중 하나 이상에 해당한다면 저는 통합 서비스나 중계 서비스를 선택합니다:

• 아직 워크로드를 파악하는 중입니다. 초기에는 GPT-5.5, Claude Opus 4.8, Sonnet 4.6, Gemini 3, 오픈 모델 중 어떤 것이 작업에 가장 적합할지 알 수 없습니다.
• 공급업체가 아니라 작업을 기준으로 라우팅하고 싶습니다. 분류기를 사용하면 짧은 프롬프트는 저렴하고 빠른 모델로 보내고, 긴 컨텍스트가 필요한 작업은 실제로 더 적합한 경우 Fable 5 같은 모델로 보낼 수 있습니다.
• 신속한 대체 처리 방안이 필요합니다. 한 제공업체가 요청 속도를 제한하기 시작하면 중계 서비스가 사용자가 알아차리기 전에 트래픽을 전환할 수 있습니다.
• 청구 시스템 다섯 개를 관리하고 싶지 않습니다. 여러 키, 할당량, 지출 대시보드를 관리하는 것보다 청구서와 연동을 하나씩만 관리하는 편이 더 쉽습니다.
• 멀티테넌트 제품에 추상화 계층이 필요합니다. 게이트웨이를 사용하면 앱을 다시 작성하지 않고도 내부적으로 제공업체를 교체할 수 있습니다.

이는 팀 규모가 작을 때 특히 유용합니다. 저는 스타트업 팀들이 제품의 가치를 높이는 것보다 제공업체별 재시도 로직을 연결하는 데 더 많은 시간을 쓰는 모습을 봤습니다. 중계 서비스를 사용하면 이 작업을 한곳으로 모을 수 있습니다.

직접 호출이 더 나은 선택인 경우

다음 중 하나라도 중요하게 생각한다면 제공업체의 API를 직접 사용하는 편이 대체로 유리합니다:

• 최저 지연 시간. 제품의 지연 시간 예산이 빠듯하다면 홉 하나를 줄이는 것도 중요합니다. 300 ms 안에 “즉각적으로 느껴지는” 상호작용을 구현하려 한다면 네트워크와 라우팅 오버헤드가 그 시간의 상당 부분을 차지할 수 있습니다.
• 엄격한 규정 준수 경계. 처리자가 추가될 때마다 관리해야 할 관계, 보관 규칙, 계약 검토도 하나씩 늘어납니다.
• 공급업체별 고유 기능. 일부 제공업체는 통합 서비스가 공통 형식으로 정규화하면서 제외하거나 지원이 늦어지는 기능을 제공합니다.
• 많고 예측 가능한 사용량. 사용량이 안정되면 중간 계층에 비용을 지불하는 것보다 자체 라우팅이 더 저렴할 수 있습니다.
• 더 명확한 지원 경로. 문제가 발생했을 때 책임을 서로 떠넘기는 일이 줄어듭니다.

숨은 이점은 운영상의 명확성입니다. 호출 경로가 직접 연결되어 있으면 장애의 근본 원인을 더 쉽게 분리해 파악할 수 있습니다. 실패한다면 대개 자신의 코드나 제공업체가 원인입니다. 게이트웨이를 사용하면 중계 서비스, 중계 서비스의 라우팅 계층, 상위 제공업체 중 어디에 책임이 있는지도 확인해야 합니다.

자체 호스팅은 차원이 다른 문제

오픈 모델 자체 호스팅은 단순히 “내 서버에서 쓰는 더 저렴한 API”가 아닙니다. 시스템 차원의 문제입니다.

다음 사항을 고려해야 합니다:

• GPU 용량 산정과 활용률,
• 배치 처리,
• 양자화,
• KV 캐시 부담,
• 자동 확장,
• 웜 스타트,
• 안전 필터,
• 모델 업데이트,
• 그리고 롤백 절차.

장점은 제어권입니다. 워크로드가 안정적이고 충분히 많다면 자체 호스팅은 경제적으로 매력적일 수 있습니다. 하지만 하드웨어를 계속 가동할 때만 비용 계산이 성립합니다. 유휴 GPU는 비쌉니다. 부하가 큰 상황에서도 모델 서빙 스택이 제대로 작동하도록 만드는 엔지니어링 시간 역시 비용이 큽니다.

또 다른 흔한 함정은 품질 변화입니다. 오픈 모델이 지금은 요약에 충분히 적합할 수 있지만, 프롬프트 길이, 문체 요구 사항, 도구 사용 방식이 바뀌면 평가 결과가 급격히 나빠질 수 있습니다. “오픈”이라는 이유만으로 자동으로 “관리형 API를 대체할 만큼 저렴하다”고 가정하지 마세요.

실용적인 하이브리드 패턴

실제 시스템에서는 혼합형 아키텍처가 최선인 경우가 많습니다:

# direct path for latency-sensitive traffic
export LLM_ROUTE=direct
export LLM_PROVIDER=anthropic
export LLM_MODEL=claude-sonnet-4.6

# relay path for experimental or burst traffic
export LLM_ROUTE=gateway
export LLM_MODEL=openai/gpt-5.5

그리고 앱 내부에서는:

def choose_route(task_type, tenant_tier, prompt_tokens):
    if task_type == "tool_calling":
        return {"route": "direct", "model": "anthropic/claude-sonnet-4.6"}
    if prompt_tokens > 120_000:
        return {"route": "gateway", "model": "openai/gpt-5.5"}
    if tenant_tier == "free":
        return {"route": "gateway", "model": "openai/haiku-class"}
    return {"route": "direct", "model": "google/gemini-3"}

이 패턴은 핵심 경로를 단순하게 유지하면서도 라우팅을 유연하게 활용할 수 있게 해줍니다. 제가 본 바로는 팀들이 프로덕션 운영 첫 달을 거친 후 이 방식에 도달하는 경우가 많습니다. 핵심 UX에는 직접 호출을, 실험과 초과 트래픽 처리에는 게이트웨이를 사용하고, 자체 호스팅은 경제성이나 개인정보 보호 측면의 이점이 확실한 경우에만 사용합니다.

개인정보 보호, 지연 시간, 신뢰

이 지점에서 엔지니어링은 정책의 문제가 됩니다.

개인정보 보호

게이트웨이는 신뢰 경계를 바꿉니다. 프롬프트가 상위 제공업체로 전달되더라도 다음 질문에 답해야 합니다:

• 중계 서비스가 프롬프트를 기록하나요?
• 프롬프트는 얼마나 오래 보관되나요?
• 어떤 하위 처리자가 프롬프트를 볼 수 있나요?
• 특정 테넌트를 제한된 경로에서만 처리할 수 있나요?
• 특정 리전 고정을 지원하나요?

규제가 적용되는 워크로드에서는 “제공업체가 올바르게 처리하겠다고 약속했다”는 것만으로 충분하지 않습니다. 문서화된 증빙과 그에 부합하는 설계가 필요합니다.

지연 시간

중계 서비스는 홉을 하나 더 추가합니다. 이것이 자동으로 앱을 느리게 만드는 것은 아니지만 불확실성은 늘어납니다. 앱의 통신이 잦고 토큰 스트리밍이 중요하다면 계층이 추가될 때마다 첫 토큰까지 걸리는 시간을 예측하기 더 어려워질 수 있습니다.

요청 속도 제한

직접 연동하면 제공업체의 제한을 그대로 적용받습니다. 게이트웨이는 트래픽을 여러 제공업체로 분산해 이를 완화할 수 있지만 자체적인 요청 제한을 추가할 수도 있습니다. 다시 말해, 한 제한을 다른 제한으로 바꾸는 셈일 수 있습니다. 얻는 이점은 탄력성이며, 제한에서 완전히 벗어나는 것은 아닙니다.

제가 사용하는 결정 기준

이 선택을 한 문장으로 압축해야 한다면: 사용할 모델을 알고 호출 경로가 중요하다면 직접 호출하고, 선택의 유연성과 복원력이 중요하다면 게이트웨이를 사용하며, 제어권과 안정적인 활용률이 운영 비용을 정당화한다면 자체 호스팅하세요.

몇 가지 구체적인 실무 기준은 다음과 같습니다:

• 첫 프로덕션 기능을 출시하고 모델 하나만 필요하다면 직접 호출로 시작하세요.
• 서로 다른 모델 유형이 최소 두 가지이거나 사고 검토에서 장애 조치의 필요성이 드러나기 시작하면 게이트웨이를 추가하세요.
• 실제 활용률 수치와 스택을 직접 운영해야 할 명확한 이유를 확보한 후에만 자체 호스팅하세요.
• 라우팅 실험에는 게이트웨이를 사용하되 핵심 경로의 멱등성을 유지하세요.
• 토큰 가격만이 아니라 전체 과정의 비용을 측정하세요.

실무 핵심 요점

• 우선 선택하세요 직접 API 호출 가장 낮은 지연 시간, 가장 간단한 디버깅, 가장 강력한 공급업체별 지원이 필요할 때.
• 우선 선택하세요 게이트웨이/통합 서비스 여러 모델 간 라우팅, 대체 처리 지원, 여러 제공업체를 아우르는 단일 연동이 필요할 때.
• 우선 선택하세요 자체 호스팅 하드웨어를 계속 가동할 수 있고 운영상의 복잡성을 감수할 수 있을 때만.
• 구축하세요 멱등성과 체계적인 재시도 원칙 자동 대체 처리를 추가하기 전에.
• 비교 총비용: 토큰, 추가 요금, 재시도, 엔지니어링 시간, 사고 복구.
• 다음 항목을 유지하세요: 개인정보 보호와 보관 정책 구매 담당 부서가 묻고 나서가 아니라 처음부터 의사결정에 반영하세요.
• 사용하세요 하이브리드 아키텍처 워크로드에 프리미엄 경로와 범용 경로가 모두 있다면.

원하시면 스타트업 개발자, 플랫폼 팀, 규제 준수 요구가 까다로운 엔터프라이즈 팀 등 특정 독자를 대상으로 관점을 더 뚜렷하게 드러내는 버전으로 바꿔 드릴 수 있습니다.