모든 주요 AI 플랫폼은 전송 가능한 요청 수를 제한합니다. OpenAI, Anthropic, Google, DeepSeek — 모두 계정당, 분당, 일당 사용량에 한도를 둡니다. 제품을 구축하거나, 자동화를 실행하거나, 대량의 데이터를 처리할 때 하나의 계정과 하나의 IP로는 금세 한계에 도달합니다. 429 오류가 발생하고, 대기 중인 요청이 쌓이며, 파이프라인이 정체됩니다.
AI 프록시 서버는 애플리케이션과 AI 제공업체 사이에 위치합니다. 프록시로 요청을 보내면, 프록시가 여러 API 키에 요청을 분배하며 각 키는 고유한 IP 주소를 통해 전송됩니다. 제공업체 측에서는 하나의 과부하된 계정이 아닌 별도의 사용자로 인식합니다. 전체 처리 용량은 배가되면서도 개별 키는 안전하게 한도 내에 유지됩니다. 실제로 잘 구성된 프록시는 요청당 15~30ms의 지연 시간만 추가하며, 이는 배치 처리에서는 무시할 수 있는 수준이고, 모델 자체의 생성 시간이 500~3,000ms에 달하는 실시간 채팅 애플리케이션에서도 거의 체감되지 않습니다.
이 방식이 효과적인 이유는 AI 플랫폼이 속도 제한을 IP가 아닌 계정 기준으로 적용하기 때문입니다 — 다만 IP 패턴도 모니터링합니다. 하나의 주소가 10개의 서로 다른 API 키를 빠르게 순환하면 위험 신호로 감지됩니다. 키별로 별도의 전용 프록시를 사용하면 모든 것이 자연스럽게 유지됩니다. 또한 페일오버 전략이 필요합니다. 각 키의 에러율을 모니터링하고, 특정 IP에서 지속적으로 429 또는 403 에러가 반환되면 자동으로 해당 IP를 풀에서 제거하고 백업 IP를 통해 트래픽을 라우팅하십시오. 키-IP 쌍별로 60초마다 헬스 체크를 실행하면 문제가 확산되기 전에 감지할 수 있습니다.
실제 설정 과정
대부분의 AI API 프록시 설정은 제공업체에 관계없이 동일한 패턴을 따릅니다. 경량 프록시 서버(FastAPI, Node, Go — 사용 중인 스택에 맞는 것)를 실행하고 API 키 풀을 보유합니다. 요청이 들어오면 프록시가 다음 사용 가능한 키를 선택하고, 해당 키에 할당된 IP를 통해 요청을 라우팅한 뒤 응답을 반환합니다. 하나의 키가 429(속도 제한 오류)를 받으면 프록시가 다음 키로 전환합니다. 다음은 FastAPI와 httpx:
import httpx, itertoolsfrom fastapi import FastAPI, Request, Response
app = FastAPI()keys = itertools.cycle([ {"api_key": "sk-key1", "proxy": "http://user:pass@ip1:port"}, {"api_key": "sk-key2", "proxy": "http://user:pass@ip2:port"},])@app.post("/v1/chat/completions")async def proxy(request: Request): body = await request.json() slot = next(keys) async with httpx.AsyncClient(proxy=slot["proxy"]) as client: r = await client.post( "https://api.openai.com/v1/chat/completions", json=body, headers={"Authorization": f"Bearer {slot['api_key']}"}, ) # TODO: Add retry logic on 429 — try next key/IP before returning error to caller return Response(content=r.content, status_code=r.status_code)
참고: 이 최소 예제는 단순화를 위해 itertools.cycle을 사용하지만, 429 에러 발생 시 자동 재시도 기능은 포함되어 있지 않습니다. 프로덕션 환경에서는 스로틀링된 키를 건너뛰고 다음 사용 가능한 키-IP 쌍으로 시도한 후, 모두 실패할 경우에만 호출자에게 에러를 반환하는 재시도 로직을 추가하십시오. 현재 거의 모든 AI 프로바이더가 OpenAI API 포맷을 지원하므로, 하나의 프록시로 각 AI 프로바이더가 요구하는 포맷 변환을 처리할 수 있습니다 — 적절한 프로바이더로 라우팅하면 애플리케이션에서는 차이를 인식할 필요가 없습니다. 프로바이더별로 기본 URL과 키 풀만 변경하면, 동일한 20줄짜리 서버로 OpenAI, Anthropic, Google, DeepSeek을 모두 커버할 수 있습니다.
실제로 필요한 IP 수는 얼마인가
이것은 수천 개의 주소가 필요한 웹 스크래핑이 아닙니다. AI API 작업의 경우, 3–15개의 전용 프록시로 대부분의 설정을 커버합니다. API 키당 또는 프로바이더 계정당 하나의 IP를 사용합니다. 볼륨이 아닌 안정성과 클린 IP에 비용을 지불하는 것입니다. 페일오버를 위해 1–2개의 여분 IP를 예비로 확보해 두십시오 — 키가 스로틀링되거나 IP가 플래그 표시되면, 프록시가 자동으로 트래픽을 백업 IP로 전환하여 요청 손실 없이 처리합니다.
플랫폼별 가이드
각 AI 프로바이더마다 고유한 속도 제한, 특이사항, 모범 사례가 있습니다. 저희가 각 프로바이더별로 상세 내용을 별도로 정리하였습니다:
DeepSeek — 공개된 제한이 없으며, 서버 부하에 따라 동적으로 스로틀링됩니다. 피크 시간대에는 경고 없이 요청이 타임아웃될 수 있습니다. 여러 IP에 분산된 다중 키를 사용하면 이 문제를 완화할 수 있습니다. → DeepSeek용 프록시 Google Gemini — 무료 티어가 2025년 말 50~80% 삭감되었습니다. 현재 모델에 따라 분당 5~10회 요청만 가능합니다. 여러 Google Cloud 프로젝트를 통한 키 로테이션이 표준적인 해결 방법입니다. → Gemini용 프록시 Anthropic Claude — 지출 금액에 따라 증가하는 단계별 속도 제한(RPM, 분당 입력/출력 토큰)이 적용됩니다. 평균이 한도 내에 있더라도 버스트 트래픽은 거부됩니다. → Claude용 프록시 OpenAI ChatGPT — 조직당 RPM 및 토큰 제한이 적용됩니다. 가장 널리 사용되는 AI 챗 프록시 대상이며, 관련 도구도 가장 풍부합니다. → ChatGPT용 프록시 Janitor AI — 여기서 「프록시」란 IP 프록시가 아닌 더 나은 모델로의 API 게이트웨이를 의미합니다. 다만 자체 릴레이 서버를 호스팅하는 경우, 클린 아웃바운드 IP를 사용하면 차단을 방지할 수 있습니다. → Janitor AI용 프록시
각 플랫폼마다 제한 기준, 탐지 로직, 프록시 설정의 최적 조건이 모두 다릅니다. 주요 제공업체에 맞는 가이드부터 시작하시고, 모든 API 키-IP 페어에 대해 헬스 모니터링을 설정하며, 장애 조치를 위한 여유 용량을 확보해 두십시오.