AI API 가속 선택법: 고정 아웃바운드 IP·동시 연결·타임아웃 실측 비교

같은 회선인데 웹페이지는 열리고 API는 타임아웃된다는 사례가 개발자 문의에서 가장 많습니다. 원인은 대개 '통하느냐'가 아니라 '버티느냐'에 있습니다. 웹 요청은 금방 끝나지만 API 호출 한 번은 오래 출력을 이어갈 수 있고, 웹은 실패하면 사용자가 새로고침하지만 API는 프로그램이 재시도하거나 오류를 내뱉습니다. 그래서 어떤 회선이 API에 맞는지는 최고 속도가 아니라 지터, 아웃바운드 안정성, 장시간 연결 유지 능력으로 판단해야 합니다.

이 글에는 속도 측정 스크린샷을 싣지 않습니다. 회선 성능은 시간대와 지역에 따라 달라지므로 다른 사람의 캡처에 담긴 숫자는 참고가 되지 않습니다. 대신 아래에는 재현 가능한 측정 방법과 판단 기준을 제시하니, 자신의 네트워크 환경에서 직접 돌려보면 됩니다.

웹은 열리는데 API만 타임아웃, 어디서 갈릴까

API 호출 한 번을 뜯어보면 경로에 네 구간이 있습니다: 도메인 조회, TCP 연결, TLS 핸드셰이크, 첫 바이트와 이후 데이터 대기입니다. 웹 접속은 이 네 구간이 모두 짧고 정적 리소스는 대개 가까운 곳에서 받아옵니다. 반면 API 엔드포인트는 도메인 하나에 불과하고 근접 접속도 없어서, 네 구간 전부가 밖으로 나가는 회선 하나에 얹힙니다. 어느 구간이든 대기가 생기면 클라이언트가 보는 결과는 우선 타임아웃입니다.

스트리밍 응답은 이 문제를 키웁니다. SSE는 응답 하나를 잘게 나눠 연속으로 내려보내는데, 중간 어느 구간이든 버퍼링을 하면 클라이언트는 읽기 타임아웃이 날 때까지 '멈춘' 상태를 보게 됩니다. 그래서 이런 문제는 총 소요 시간이 아니라 첫 바이트 시간과 데이터 사이 간격으로 판단해야 합니다.

세 가지 회선 형태: 직결, 중계, 전용선

똑같이 '가속'이라고 적혀 있어도 실제 물리 경로는 전혀 다를 수 있습니다. 흔한 세 가지 형태는 아래와 같으며, 여기서는 정성적 비교만 하고 속도 수치는 다루지 않습니다.

직결은 비용이 가장 적게 들지만 운에 맡기는 방식입니다. 경로 전체가 공용 인터넷 국제 구간을 지나므로 저녁 피크의 혼잡이 그대로 API 호출에 전달됩니다. 중계는 '마지막 구간'을 가까운 진입점으로 바꾸고 해외 구간은 터널로 지나가며, 안정성은 진입점 품질과 터널 자체에 달려 있습니다. IEPL 전용선은 2계층 전용 회선으로 공용 인터넷 국제 구간의 혼잡 지점을 거치지 않아 지터가 대체로 작지만, 가격이 더 높고 선택 가능한 지역이 적습니다.

주문 전에 네 가지를 확인하세요: 진입점이 어느 도시에 있는지, 아웃바운드 주소가 고정인지, 구매하려는 등급이 구체적으로 어떤 형태인지, 회선 장애 시 어떻게 전환되는지. 많은 '가속' 문구가 이 네 가지 질문을 견디지 못합니다.

고정 아웃바운드: API 호출에서 가장 먼저 확인할 항목

웹 브라우징은 아웃바운드 주소가 바뀌든 말든 상관없지만, API 호출은 아주 민감합니다. 이유는 네 가지입니다:

• 화이트리스트. 많은 플랫폼이 호출 출발지 주소를 화이트리스트에 넣을 수 있는데, 아웃바운드가 바뀌면 요청이 곧바로 거부됩니다.
• 세션 일관성. 일부 서비스는 세션을 출발지 주소에 묶어두기 때문에, 주소가 흔들리면 2차 검증이나 속도 제한이 걸립니다.
• 장애 대응. 아웃바운드가 고정되어야 로그에서 '이 요청이 어디로 나갔는지'가 유일하게 확정됩니다. 아웃바운드가 이리저리 튀면 로그를 맞추는 일 자체가 노가다가 됩니다.
• 팀 공용. 개발 PC 여러 대가 각자 밖으로 나가면 아웃바운드가 흩어집니다. 해외 게이트웨이 하나에 안정적인 터널을 붙이면 아웃바운드가 하나로 모이고 규칙도 쓰기 쉬워집니다.

고정 아웃바운드가 전용 아웃바운드를 뜻하지는 않습니다. 공유 아웃바운드에 다른 고빈도 요청이 함께 있다면 대상 사이트의 속도 제한이 사용자에게 떨어질 수 있고, 증상은 코드를 한 줄도 바꾸지 않았는데 일정 시간 API가 속도 제한 오류를 자주 돌려주는 것으로 나타납니다.

동시 연결과 타임아웃: 가장 자주 틀리는 두 곳

동시성은 '동시에 열린 스트림' 기준이지 QPS 기준이 아닙니다

HTTP/2 멀티플렉싱 덕분에 여러 요청이 연결 하나를 공유하니 얼마든지 동시에 보내도 될 것 같지만, 서버와 중간 노드에는 동시 스트림 상한이 있어 초과분은 큐에서 대기하고 첫 바이트 시간이 늘어나 결국 타임아웃으로 나타납니다. 스트리밍 API라면 더 주의해야 합니다. 요청 하나가 출력이 끝날 때까지 연결을 붙잡고 있으므로 동시 수는 동시에 열린 스트림 기준으로 계산해야 합니다.

클라이언트 연결 풀도 너무 크게 잡지 마세요. 연결 풀의 의미는 재사용이지 개수 쌓기가 아닙니다. 연결 수가 회선 용량을 넘으면 모든 연결이 느려질 뿐입니다. 배치 작업은 큐와 속도 제한으로 동시 수를 '안정적으로 첫 바이트를 받을 수 있는' 범위에 묶는 편이, 나중에 타임아웃을 만지는 것보다 효과적입니다.

타임아웃은 세 층으로 나눠 설정하세요, 숫자 하나로 전부 관리하지 말고

• 연결 타임아웃은 TCP와 TLS 핸드셰이크를 포괄합니다. 이 구간에서 실패하면 경로가 막힌 것이므로 시간을 늘릴 게 아니라 회선을 바꿔야 합니다.
• 첫 바이트 타임아웃은 서버 대기와 준비 시간을 포괄하므로 여유를 넉넉히 주세요. 연결 타임아웃과는 별개입니다.
• 읽기 타임아웃은 스트리밍 응답의 경우 '데이터 두 덩어리 사이 간격' 기준으로 계산하고, 긴 출력을 총 소요 시간으로 잘라내지 마세요.
• 재시도는 멱등 요청이나 명확히 접수되지 않은 오류에만 적용하세요. 생성형 요청을 무작정 재시도하면 할당량이 두 번 소모됩니다.
• 백오프는 지수 백오프에 무작위 지터를 더해, 배치 전체가 같은 초에 한꺼번에 재연결하지 않도록 하세요.

먼저 명령줄로 다섯 구간의 시간을 재보고, 어떤 파라미터를 조정할지 정하세요:

curl -o /dev/null -s \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  "$API_BASE/v1/models"

클라이언트에서 연결과 읽기를 분리해 설정하는 것이 가장 비용이 적게 드는 단계입니다:

import httpx

# 여기 값은 출발점일 뿐이니 자신의 회선 상황에 맞게 조정하세요
timeout = httpx.Timeout(connect=5.0, read=120.0, write=30.0, pool=5.0)

with httpx.Client(timeout=timeout, http2=True) as client:
    with client.stream("POST", f"{base}/v1/chat/completions", json=payload) as resp:
        resp.raise_for_status()
        for line in resp.iter_lines():
            handle(line)

프로토콜 선택: 흔한 여섯 가지의 차이

프로토콜이 첫 번째 순위는 아니지만 핸드셰이크 비용과 약전계 환경에서의 성능을 좌우합니다. 아래 표는 차이만 다루며 누가 '최강'인지는 다루지 않습니다:

실용적인 판단 몇 가지: TCP 계열 프로토콜은 중간 장비에 더 우호적이고, QUIC 계열은 패킷 손실이 뚜렷한 회선에서 체감이 좋지만 UDP에 의존하므로 속도 제한을 만나면 TCP 계열로 전환할 수 있어야 합니다. VLESS는 자체 암호화를 하지 않아 보안을 전적으로 TLS에 맡기고, Trojan은 인증서에 의존하므로 자동 갱신을 제대로 해두지 않으면 어느 날 갑자기 연결이 되지 않습니다. 클라이언트가 이미 지원하고 유지보수가 활발한 쪽을 고르는 편이 새것을 쫓는 것보다 현실적입니다.

클라이언트와 구독: 플랫폼 차이가 문제 해결에 직접 영향

• Windows와 macOS: 시스템 프록시는 시스템 설정을 읽는 프로그램만 커버합니다. 명령줄 도구와 적지 않은 SDK는 시스템 프록시를 읽지 않으므로 HTTPS_PROXY 환경 변수를 설정하거나 TUN 모드로 모든 트래픽을 넘겨받아야 합니다.
• Linux: 시스템 프록시 계층이 없어 환경 변수나 TUN + 정책 라우팅에 의존합니다. 컨테이너에서 작업을 돌릴 때는 프록시 변수가 자동으로 전달되지 않는다는 점을 유의하세요.
• 분할 라우팅 규칙: API 도메인에는 별도 규칙을 하나 두어 광범위한 규칙에 휘말리지 않게 하세요. DNS 조회 방식도 분할 라우팅과 함께 봐야 합니다. 그렇지 않으면 도메인 조회 결과와 실제 아웃바운드가 어긋나 장애 대응 때 오판하게 됩니다.
• 구독 가져오기: 구독 링크는 본질적으로 노드 목록이며 클라이언트가 주기적으로 갱신합니다. 클라이언트를 바꿀 때는 같은 구독을 가져오는 편이 좋고, 노드를 손으로 옮겨 적지 마세요. 파라미터 하나만 빠져도 '연결은 되는데 동작하지 않는' 상태가 됩니다.

선택 체크리스트: 확인 가능한 것부터, 그다음 설명

서비스를 고를 때는 주관적 느낌에 기대지 않고 검증 가능한 항목부터 보세요. 아래 네 가지는 이 사이트가 공개하는 파라미터로, 그대로 대조해볼 수 있습니다:

• ✅ 명령줄로 조회, 연결, 핸드셰이크, 첫 바이트, 총 소요 시간을 나눠 기록하고, 시간대를 바꿔 여러 번 샘플링해 가장 빠른 한 번이 아니라 지터를 보세요.
• ✅ 재연결을 여러 번 반복한 뒤 에코 주소를 돌려주는 API를 호출해 아웃바운드가 바뀌지 않았는지 확인하세요.
• ✅ 연결 타임아웃과 읽기 타임아웃을 따로 설정하고, 스트리밍 API는 읽기 타임아웃을 별도로 넉넉히 두세요.
• ✅ 배치 작업은 큐로 돌리고 동시에 열리는 스트림 수를 제한하세요.
• ✅ 분할 라우팅 규칙에 API 도메인을 따로 나열하고, DNS 조회 방식이 규칙과 일치하는지 확인하세요.
• ✅ 클라이언트를 바꿀 때는 같은 구독을 가져오고, 노드 목록이 정상적으로 갱신되는지 확인하세요.
• ❌ 웹페이지 로딩 속도로 API 성능을 추정하기.
• ❌ 타임아웃 하나로 모든 요청을 관리하기, 특히 스트리밍 응답에서.
• ❌ 생성형 요청을 무작정 재시도하기.
• ❌ 연결됐다는 이유로 모든 프로그램이 그 회선을 탄다고 생각하기.

상식이지만 자주 놓치는 두 가지가 더 있습니다. 환불 조건은 주문 전에 확인하세요. 이 사이트는 7일 무조건 환불이라 자체 테스트를 한 바퀴 돌리기에 충분합니다. 결제 수단은 알리페이, 위챗페이, USDT를 모두 지원하므로 팀 구매가 어느 쪽으로 이뤄져도 장부가 맞습니다. 가입에는 아이디와 비밀번호만 있으면 되고 이메일 주소는 필요하지 않아, 입력 항목이 하나 줄면 걱정도 하나 줄어듭니다.

결론: 파라미터보다 순서

하나만 기억한다면: '통하는가'와 '안정적인가'를 두 번의 테스트로 나누고, 연결·첫 바이트·읽기 세 구간의 타임아웃을 따로 설정하세요. 이 두 가지만 해두면 'API가 자꾸 타임아웃된다'는 불만 대부분은 사라집니다.