DeepSeek API 중계와 프록시는 흔히 "주소만 바꾸면 되는 일"로 가볍게 여겨집니다. 하지만 실제 선정에서 답해야 할 것은 네 가지입니다. 비용은 어떻게 계산되는지, 네트워크는 안정적인지, 문제가 생기면 누가 책임지는지, 키와 데이터 처리가 규정을 준수하는지입니다.

이 글은 흔한 방안을 비교하고 이전 및 검증 체크리스트를 제공합니다. 구체적인 가격, 모델 이름, 가용성은 사이트 내 모델 가격과 서비스 제공자 설명을 기준으로 합니다.

안내: DeepSeek는 해당 권리자의 상표이며 이 글은 DeepSeek 공식과 소속 관계가 없습니다. 중계 시장은 빠르게 변하므로 이 글은 2026년 10월의 일반적인 형태를 예로 들며 어떤 서비스 제공자에 대한 보증도 아닙니다.

1. 먼저 정의: 중계, 프록시, 게이트웨이는 다릅니다

  • API 중계(relay): 요청을 업스트림 모델 서비스로 전달하며 과금, 한도, 로그를 함께 제공할 수 있습니다. 시장의 일부 "중계"는 키를 공유하거나 재판매할 뿐이고 안정성과 규정 준수는 운영자에 달려 있습니다.
  • 네트워크 프록시: HTTP, SOCKS, 리버스 프록시로 네트워크 도달성만 해결하고 API 의미는 바꾸지 않습니다. 키는 여전히 자신의 것입니다.
  • 자체 프록시: 서버에 리버스 프록시나 오픈소스 게이트웨이를 배포해 키, 로그, 라우팅을 직접 제어하지만 업스트림 계정, 대역폭, 운영을 모두 감당해야 합니다.
  • 통합 AI 게이트웨이: OpenAI 호환 진입점으로 여러 모델을 모으고 통합 키, 청구, 콘솔을 제공합니다. 상업 게이트웨이와 오픈소스 자체 구축이 모두 이 범주에 들 수 있습니다.

네 개념을 섞으면 네트워크 문제를 모델 문제로 오해하기 쉽습니다. 계약 전에 상대가 어느 계층의 서비스를 제공하는지, 키가 누구 것인지 분명히 물어보세요.

2. 네 가지 방안을 한 표로

기준 공식 직접 연결 자체 프록시 상업 중계 통합 AI 게이트웨이
과금 투명성 공식 청구, 기준이 명확 업스트림 청구에 자체 비용 추가 운영자에 따라 다름, 대사 필요 사이트 내 통합 청구, 계산 규칙 확인
네트워크 안정성 로컬 출구 영향 서버와 회선에 따라 다름 중계 회선에 따라 다름 게이트웨이 회선과 업스트림에 따라 다름
속도 제한과 동시성 공식 계정 단위 제한 직접 제어하지만 업스트림 제한은 받음 공유 풀일 수 있어 확인 필요 게이트웨이 규칙과 요금제에 따름
모델 범위 DeepSeek만 연결한 업스트림에 따라 다름 보통 많지만 확인 필요 멀티모델, 가격 페이지 기준
키 위험 키가 자신의 손에 키가 자신의 손에 공유 또는 재판매 키일 수 있음 보통 독립 키 발급
운영과 지원 공식 문서 전부 직접 감당 제공자 역량에 따름 콘솔, 티켓, 문서

모든 팀에 맞는 방안은 없습니다. DeepSeek만 쓰고 네트워크와 결제가 원활하면 공식 직접 연결이 가장 직접적입니다. 고정 출구와 감사가 필요하면 자체 프록시를, 운영 인력이 없으면 상업 중계를 평가하고, 멀티모델 통합 청구가 필요하면 게이트웨이를 보세요.

3. 가격: "배율"만 보지 마세요

중계는 흔히 "공식 가격 × 배율" 또는 "토큰 패키지"로 견적합니다. 배율이 낮다고 총비용이 낮은 것은 아니므로 최소 여덟 가지를 물어야 합니다.

  1. 입력과 출력을 분리해 계산하는지, 배율이 같은지.
  2. 캐시 적중 입력에 할인이 있는지, 할인은 어떻게 계산하는지.
  3. thinking이 생성한 추론 토큰이 출력에 포함되는지.
  4. 실패 요청과 재시도 요청에 과금되는지.
  5. 스트리밍 요청의 usage가 완전히 반환되는지.
  6. 충전에 최소 금액, 유효 기간, 환불 규칙이 있는지.
  7. 인보이스를 지원하는지, 환율과 결제 통화는 무엇인지.
  8. 사용량 통계와 청구를 프로젝트, 키, 모델별로 나눌 수 있는지.

이 기준을 비교 표에 적고 같은 요청 세트로 실측해야 실제 비용을 계산할 수 있습니다. 구체적인 가격과 과금 방식은 사이트 내 모델 가격과 상대방 청구서를 기준으로 합니다.

4. 안정성: 홍보가 아니라 데이터로 검증

안정성은 최소 여섯 지표로 봅니다. 성공률, P50/P95 지연, 첫 토큰 지연, 타임아웃율, 429 비율, 출력 속도입니다. 테스트에는 실제 길이의 프롬프트를 써서 스트리밍, 긴 컨텍스트, 동시성을 모두 포함하세요.

import os
import statistics
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["RELAY_API_KEY"],
    base_url=os.environ["RELAY_BASE_URL"],
    max_retries=0,
    timeout=60,
)

prompt = "크로스보더 전자상거래 주문 이행의 주요 단계를 200자로 설명하세요."
latencies, errors, usage = [], 0, []

for i in range(20):
    start = time.perf_counter()
    try:
        resp = client.chat.completions.create(
            model=os.environ["RELAY_MODEL"],
            messages=[{"role": "user", "content": prompt}],
            max_tokens=512,
        )
        latencies.append((time.perf_counter() - start) * 1000)
        usage.append(resp.usage.total_tokens if resp.usage else 0)
        print(i, resp.model, resp.usage)
    except Exception as exc:
        errors += 1
        print(i, type(exc).__name__, exc)

if latencies:
    print("성공", len(latencies), "실패", errors)
    print("P50", statistics.median(latencies), "ms")
    print("최대", max(latencies), "ms")
    print("평균 토큰", sum(usage) / len(usage))

이것은 최소 탐침일 뿐 부하 테스트가 아닙니다. 운영 전에는 7일 연속 관찰하고 피크와 비피크에 각각 한 번 실행해 결과를 공식 직접 연결과 비교하세요. 상업 중계는 저녁 피크와 긴 요청을, 자체 프록시는 서버 출구와 업스트림 속도 제한을 중점적으로 보세요.

5. 키 위험과 규정 준수: 가격보다 중요

중계에서 가장 놓치기 쉬운 것은 키 귀속입니다. 공유 키, 재판매 키, 출처가 불분명한 할당량은 네 가지 문제를 일으킬 수 있습니다.

  • 업스트림이 계정을 차단하거나 할당량을 조정하면 업무가 함께 중단되고 직접 이의를 제기할 수 없습니다.
  • 여러 테넌트가 키 하나를 공유하면 속도 제한과 장애가 서로 영향을 주고 원인 파악이 어렵습니다.
  • 요청 내용이 제3자를 거치며 로그, 캐시, 데이터 보존 정책이 투명하지 않습니다.
  • 서비스 약관이 재판매나 공유를 허용하지 않을 수 있어 분쟁 시 계약 근거가 없습니다.

제공자를 고를 때 최소한 법인 주체, 서비스 약관, 개인정보 처리방침, 인보이스 발행 능력, 장애 연락처를 확인하세요. 개인정보, 키, 계약 원문이 포함된 요청을 데이터 이동 경로를 설명하지 못하는 중계에 보내지 마세요. 금융, 의료 등 규제가 강한 시나리오는 공식 직접 연결, 사설 배포, 데이터 처리 계약이 가능한 서비스를 우선 평가하세요.

6. 이전 체크리스트: 직접 연결에서 중계나 게이트웨이로

  1. 현황 기록: 성공률, P50/P95 지연, 요청 1,000건당 토큰 사용량과 청구.
  2. 모델 이름과 파라미터 파악: thinking, max_tokens, tools, JSON 출력, 스트리밍.
  3. 테스트 키와 운영 키를 새로 만들고 각각 예산과 경고를 설정.
  4. base_url과 api_key만 바꾸고 스테이징에서 최소 요청 실행.
  5. 실제 프롬프트로 재생해 출력 품질, 소요 시간, usage 기준을 비교.
  6. 401, 402, 429, 5xx, 타임아웃 매핑을 확인하고 재시도가 장애를 키우지 않는지 점검.
  7. 5%~10% 트래픽으로 점진 전환해 3~7일 관찰하고 공식 직접 연결을 폴백으로 유지.
  8. 전면 전환 후 일주일 더 대사해 청구와 사용량 통계가 일치하는지 확인.

이전할 때 모델, 프롬프트, 게이트웨이를 동시에 바꾸지 마세요. 원인을 귀속할 수 없습니다. 한 번에 변수 하나만 바꾸세요.

7. 중계가 신뢰할 만한지 검증하는 방법

먼저 응답의 model 필드를 보되 이 필드만 믿지는 마세요. 재작성될 수 있습니다. 더 신뢰할 만한 방법은 조합 검증입니다.

검증 항목 방법 이상 신호
지연 같은 프롬프트를 연속 요청해 P50/P95 비교 변동이 극심하거나 장기적으로 직접 연결보다 현저히 느림
오류율 429, 5xx, 타임아웃 비중 집계 피크에 집중 실패
사용량 응답 usage와 백오피스 청구 비교 불일치, 스트리밍 usage 누락
모델 정체성 고정 테스트 세트로 능력 경계와 출력 스타일 비교 능력이 현저히 저하, 컨텍스트가 짧아짐
키 격리 독립 키인지, 교체 가능한지 확인 키 출처 설명 거부
계약과 지원 주체, 약관, 인보이스, 티켓 응답 확인 개인 연락처만 있고 서비스 약관 없음

위험 신호는 다음과 같습니다. 가격이 장기간 공식보다 훨씬 낮음, "무장애"를 약속, 사용량 명세 제공 거부, 공식 키 제출 요구, 데이터 보존 위치 설명 불가. 이런 경우 먼저 소량 트래픽으로 검증하고 운영을 한 번에 옮기지 마세요.

8. 자체 프록시가 더 적합한 경우

자체 프록시는 엔지니어링 역량이 있는 팀에 적합합니다. 고정 출구 IP, 통합 감사, 멀티 업스트림 라우팅이 필요하거나 키를 직접 쥐고 있어야 하는 경우입니다. 흔한 방식은 리버스 프록시에 키 관리, 속도 제한, 로그, 경고를 붙이고 업스트림은 여전히 공식 계정이나 규정을 준수하는 공급자를 쓰는 것입니다.

대가도 계산해야 합니다. 서버, 대역폭, 인증서, 업그레이드, 취약점 수정, 당직이 모두 비용입니다. 가끔만 호출하고 운영 인력이 없다면 자체 구축이 상업 방안보다 더 비쌀 수 있습니다. 자체 구축도 업스트림 속도 제한과 서비스 약관을 우회하지 못합니다.

9. 선택 제안: 제약 순으로 정렬

  1. 네트워크와 결제를 먼저 봅니다. 공식 진입점에 안정적으로 접속하고 충전이 원활한가. 가능하면 공식 직접 연결을 우선합니다.
  2. 다음은 통제력입니다. 고정 출구, 감사 로그, 사설 키가 필요한가. 필요하면 자체 프록시를 평가합니다.
  3. 다음은 모델 범위입니다. 하나의 진입점으로 여러 모델을 호출해야 하는가. 그렇다면 통합 게이트웨이를 봅니다.
  4. 마지막은 서비스 역량입니다. 주체, 약관, 인보이스, 티켓, 데이터 정책을 명확히 설명할 수 있는가.

멀티모델 통합 진입점이 필요하다면 ZSQH AI 게이트웨이에서 테스트 키를 만들어 먼저 실행한 뒤 이전하세요. 구체적인 가격과 사용 가능 모델은 모델 가격에서 확인할 수 있습니다. "저렴함"을 유일한 기준으로 삼지 말고 이전 비용과 장애 비용도 계산하세요.

관련 글:

자주 묻는 질문

중계와 프록시의 차이는 무엇인가요?

프록시는 보통 네트워크 계층 전달을 뜻하며 도달성만 해결합니다. 중계는 계정, 과금, 키 분배까지 포함합니다. 두 단어는 자주 혼용되므로 계약 전에 서비스 경계를 확인하세요.

중계 가격이 공식보다 낮으면 믿을 수 있나요?

대량 구매, 회선 보조금, 할당량 재판매에서 나올 수 있지만 공유 키, 속도 제한, 서비스 불안정이 동반될 수도 있습니다. 과금 기준, 사용량 명세, 계약 조항을 확인한 뒤 소량 트래픽으로 실측하세요.

중계가 모델을 바꿨는지 어떻게 판단하나요?

응답의 model 필드만 보면 안 됩니다. 고정 테스트 세트로 능력 경계, 컨텍스트 길이, 출력 스타일, usage 구조를 비교하고 공식 직접 연결을 대조군으로 남기세요. 능력이 현저히 저하되면 먼저 트래픽을 멈추고 조사하세요.

게이트웨이로 이전하면 코드를 얼마나 고쳐야 하나요?

대부분의 OpenAI SDK 프로젝트는 base_url과 api_key만 바꾸고 모델 이름은 게이트웨이 가격 페이지에 맞춰 조정합니다. thinking, tools, 특정 반환 필드를 쓴다면 호환성 테스트를 추가로 해야 합니다.

기업 사용자가 가장 주의할 점은 무엇인가요?

키 귀속, 데이터 처리 계약, 인보이스와 계약 주체, 장애 대응, 종료 절차입니다. 가격도 중요하지만 업무 연속성과 규정 준수 책임이 더 중요합니다.