AI 도구 접속 완전 가이드

여섯 가지 도구의 사용성 차이

AI 도구마다 신경 쓰는 지점이 다릅니다. 대화형은 세션 연속성을 가장 중시하고, 이미지형은 업로드와 반환을, 코딩형은 긴 작업과 로컬 프로세스의 협업을 가장 중시합니다. 이들을 '모두 가속이 필요하다'는 한 문장으로 묶는 것은 의미가 없습니다. 형태별로 나눠 봐야 어느 고리를 봐야 할지 알 수 있습니다.

표는 사용 형태와 네트워크 관심 지점만 다루며, 각 플랫폼의 내부 규칙은 포함하지 않습니다. 구체적인 제한은 각 플랫폼의 안내를 기준으로 하세요.

대화형: 세션 연속성이 우선

웹 대화형 도구의 핵심은 다운로드 속도가 아니라 계속 밀어 주는 긴 연결입니다. 어떤 회선이 적합한지 가장 직접적으로 확인하는 방법은 긴 답변이 필요한 질문을 세 번 연속 보내고 중간에 멈추는지 보는 것입니다. 멈추는 위치가 매번 다르면 문제는 회선에 있고, 매번 같은 길이에서 멈춘다면 계정 쪽이나 플랫폼 쪽 한도일 가능성이 큽니다.

또 하나 관찰할 수 있는 신호는 첫 글자 도착 시간입니다. 첫 글자는 정상인데 뒤쪽이 느려지면 세션 중간에 회선 혼잡이 생긴 것이고, 첫 글자부터 늦으면 요청이 서버에 도달하지 못한 것이므로 이름 해석, 핸드셰이크, 출구 차단을 의심해야 합니다.

이미지·디자인: 업로드와 반환은 별개 단계

이미지 생성은 참고 이미지를 업로드하고 결과를 다시 받아와야 하며, 두 단계가 서로 다른 도메인을 지날 수 있습니다. 업로드가 끝에서 멈추는 것은 대개 회선의 분할과 재전송 문제이고, 결과 회수 실패는 다운로드 도메인이 따로 판정되는 경우가 많습니다. 나눠서 테스트하세요. 먼저 같은 회선으로 몇 MB짜리 이미지를 일반 클라우드 드라이브에 올려 보고, 문제가 없으면 결과 반환 쪽을 확인하세요.

이미지 생성 도구는 대기 시간이 원래 깁니다. 대기 중에는 연결이 끊기면 안 됩니다. 모바일에서 백그라운드로 전환하거나 화면을 잠그면 대기 중인 작업이 사라질 수 있는데, 이런 경우는 회선과 무관한 클라이언트 동작입니다.

코딩 보조: 로컬 프로세스도 회선 안에 있습니다

편집기의 자동 완성과 대화 요청은 브라우저가 아니라 로컬 프로세스가 보냅니다. 즉 브라우저의 프록시 설정이 적용되지 않으므로, 편집기나 플러그인 자체 설정에서 따로 구성하거나 시스템 수준 도구가 프로세스별로 처리하게 해야 합니다. 자동 완성 지연이 크고 대화가 계속 로딩만 된다면 회선을 바꾸기 전에 이 계층을 먼저 확인하는 편이 빠릅니다.

프로젝트 인덱싱은 또 다른 독립 경로입니다. 인덱싱이 멈춰도 편집기의 대화는 완전히 정상일 수 있으므로, 이때 판단 기준은 채팅 창이 아니라 인덱싱 진행 표시줄입니다.

오피스 제품군 연동: 교차 출처 요청은 설정이 빠지기 쉽습니다

일부 AI 기능은 오피스 제품군 안에 들어 있어, 페이지는 한 도메인에서 오고 요청은 다른 도메인으로 나갑니다. 주 도메인만 분기 처리하면 사이드바가 계속 로딩되지 않습니다. 판단 방법은 개발자 도구를 열어 요청 목록에서 실패 상태이거나 계속 대기 중인 항목을 찾고, 그 도메인이 메인 페이지와 같은지 확인하는 것입니다.

이런 문제의 특징은 '페이지는 열리는데 기능이 비어 있다'는 점이라 계정 권한 문제로 오판하기 쉽습니다. 요청 목록을 먼저 보면 시간을 크게 아낄 수 있습니다.

이 장 요약: 먼저 도구가 어느 형태인지 확인하고, 그다음 어느 고리를 볼지 정하세요. 대화는 긴 연결, 이미지는 업로드와 반환, 코딩은 로컬 프로세스, 오피스는 교차 출처 요청입니다. 방향이 맞아야 점검이 의미를 갖습니다.

가입과 로그인 단계의 주의 사항

계정 단계의 문제는 대개 늦게 나타납니다. 가입 당일에는 아무 문제가 없다가 며칠 쓰고 나서 검증이 잦아지는 경우입니다. 원인은 대개 가입할 때 정한 지역과 이후 실제로 사용한 출구가 어긋난 데 있습니다. 이 장에서는 가입, 로그인, 검증, 다중 기기 네 단계로 나눠 실수하기 쉬운 지점을 정리합니다.

가입: 지역을 먼저 정하고 정보를 입력하세요

가입 전에 어느 지역 회선을 쓸지 정하고, 가입 절차 내내 그대로 유지하세요. 중간에 지역을 바꾸거나, 가입하다 끊겨 다시 연결하면서 출구가 바뀌면 플랫폼 쪽에 앞뒤가 맞지 않는 기록이 하나 남습니다. 이 기록은 즉시 효과를 내지 않지만 이후 로그인에서 계속 참조됩니다.

정보를 입력할 때 일관성을 유지할 수 있는 항목은 최대한 맞추세요. 인터페이스 언어, 시간대, 결제 수단 소속 지역이 그렇습니다. 모든 항목이 검증되는 것은 아니지만, 충돌 항목이 적을수록 이후 추가 검증이 걸릴 확률이 낮아집니다.

자주 놓치는 점이 하나 더 있습니다. 가입을 마친 직후에 민감한 작업을 하지 마세요. 비밀번호 변경, 연동 방식 변경, 결제 시작 같은 동작 자체가 리스크 관리의 관찰 범위에 들어갑니다. 잠시 정상적으로 사용한 뒤에 이런 작업을 하는 편이 한 번에 몰아서 하는 것보다 안정적입니다.

로그인: 세션에 시작과 끝을 만들어 주세요

로그인에 성공한 직후에 회선을 바꾸지 마세요. 많은 플랫폼에서 세션 토큰은 최초 로그인 출구에 묶여 있습니다. 출구를 바꿔도 토큰은 유효하지만, 다음 민감한 작업에서 재검증을 요구합니다. 지역을 바꿔야 한다면 로그아웃하고 회선을 바꾼 뒤 다시 로그인하는 편이 중간에 바꾸는 것보다 훨씬 안정적입니다.

브라우저 시크릿 모드, 사이트 데이터 삭제, 브라우저 교체는 모두 세션을 새로 만듭니다. 같은 계정으로 두 브라우저에 동시에 로그인하면 서로를 밀어내서 '로그인이 반복적으로 풀리는' 증상이 나타납니다. 이럴 때는 먼저 남는 쪽 하나를 정리하세요.

2차 검증과 복구 수단

복구 수단을 미리 준비해 두세요. 보조 검증 경로, 복구 코드, 연동해 둔 보조 연락처가 그것입니다. 검증을 요구받은 뒤에 찾으려 하면 이미 설정 페이지에 들어가지 못하는 경우가 많습니다. 복구 수단도 지역을 따라가야 합니다. 가입할 때 어느 지역 정보를 썼다면 복구할 때도 같은 세트를 쓰는 편이 좋습니다.

복구 코드는 따로 보관하고, 계정 비밀번호와 같은 곳에 두지 마세요. 이 점은 어떤 구독 서비스든 마찬가지이고 ZaraVPN 계정도 예외가 아닙니다.

여러 기기를 동시에 쓸 때 어떻게 배치할까

같은 계정을 여러 기기에서 동시에 쓰는 것 자체는 문제가 아닙니다. 다만 동시 접속 기기가 많을수록 출구 분포가 복잡해지고 이상하다고 판정될 확률이 높아집니다. 자주 쓰는 기기는 같은 지역에 고정하고, 임시 기기는 쓰고 나면 로그아웃하는 것을 권합니다. ZaraVPN 구독은 대수 제한이 없으며, 계정 쪽 부담은 회선의 기기 상한이 아니라 AI 플랫폼의 다중 출구 판정에서 생깁니다.

가족이나 소규모 팀이 함께 쓸 때는 모든 기기가 같은 출구에 몰리지 않도록 더 신경 써야 합니다. 계정 하나에 기기 몇 대까지 되는지, 가족 공유는 어떻게 계산하는지는 다중 기기와 가족 공유 글에 더 자세히 정리되어 있습니다.

구독 링크는 계정 자격 증명과 같습니다. 단체 채팅방에 붙여 넣거나 스크린샷을 찍거나 문의 본문에 적지 마세요. 새 기기에 가져와야 할 때는 패널에서 다시 복사하고, 몇 달 전에 쓰던 옛 링크를 쓰지 마세요. 더 자세한 보관 방법은 계정과 구독 링크 보관 글에 있습니다.

이 장 요약: 계정 단계의 안정성은 대부분 출구가 앞뒤로 일치하는지에 달려 있습니다. 가입할 때 지역을 정하고, 로그인할 때 함부로 바꾸지 않고, 검증 전에 복구 수단을 준비하고, 여러 기기의 출구를 분산하는 것. 이 네 가지를 지키면 '갑자기 왜 검증을 하지' 하는 상황 대부분을 피할 수 있습니다.

웹과 API 호출의 차이

웹이 열리니까 API도 되겠거니 하는 것이 개발자가 가장 자주 밟는 함정입니다. 둘은 엔드포인트도, 타임아웃 정책도, 속도 제한 기준도 다릅니다. 웹은 정상인데 스크립트만 오류를 내는 상황은 아주 흔합니다. 이 장에서는 엔드포인트, 스트리밍, 속도 제한, 오류 코드 네 가지로 나눠 설명합니다.

엔드포인트와 도메인은 한 세트가 아닙니다

웹은 페이지와 프런트엔드 API를 요청하고, API 호출은 다른 도메인 세트를 요청합니다. 분기 규칙이 페이지 도메인만 덮고 있으면 스크립트는 직결로 실패합니다. 방법은 API 도메인을 규칙에 따로 넣거나, 개발 환경에서 프로세스 수준 프록시를 써서 모든 아웃바운드 요청이 같은 회선을 지나게 하는 것입니다.

또 다른 차이는 요청 헤더입니다. 웹 요청에는 브라우저 지문과 사이트 쿠키가 실리지만, API 요청에는 토큰만 실립니다. 일부 플랫폼은 순수 토큰 요청을 더 엄격하게 검증합니다. 특히 새 계정의 첫 호출에서 그렇습니다. 이럴 때는 웹에서 정상적인 대화를 한 번 마친 뒤 스크립트로 돌아가는 편이 반복 재시도보다 효과적입니다.

스트리밍 응답과 타임아웃 파라미터

API의 스트리밍 반환도 긴 연결에 의존합니다. 기본 타임아웃은 보통 일반 요청 기준으로 설정되어 있어 수십 초 동안 데이터가 없으면 끊기는데, 긴 답변의 생성 시간은 그 값을 훨씬 넘을 수 있습니다. 읽기 타임아웃을 늘리고 스트리밍 응답에 별도로 설정하는 것이 개발자 쪽에서 가장 흔한 두 줄짜리 수정입니다.

# 예시일 뿐입니다: 로컬 프록시 포트를 환경 변수에 넣고, 토큰은 자리표시자 값을 쓰며, 저장소에 커밋하지 마세요
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export NO_PROXY="localhost,127.0.0.1,.internal"

curl -sS https://example.com/v1/models \
  -H "Authorization: Bearer YOUR_TOKEN" \
  --max-time 120

스트리밍 응답에서 놓치기 쉬운 점이 하나 더 있습니다. 연결은 성공했는데 서버가 첫 조각을 좀처럼 밀어 주지 않는 경우입니다. 이때 대기는 읽기 타임아웃 이전에 일어나므로 멈춘 것처럼 보입니다. 첫 조각 타임아웃과 전체 타임아웃을 따로 설정하고 로그에 둘 다 남겨야 점검할 근거가 생깁니다.

속도 제한과 동시성 제어

웹은 한 번에 메시지 하나를 보내지만 스크립트는 수십 개를 동시에 보낼 수 있습니다. 플랫폼의 속도 제한은 계정과 출구 두 축으로 계산되며, 어느 한쪽이 넘으면 제한 오류가 돌아옵니다. 방법은 동시성을 한 자릿수로 낮추고, 실패하면 지수 백오프로 재시도하며, 제한 응답을 받은 직후에 곧바로 다시 보내지 않는 것입니다.

동시성은 계정 상태와도 관련이 있습니다. 새 계정, 비밀번호를 막 바꾼 계정, 지역을 막 바꾼 계정은 보통 더 엄격한 관찰 기간에 들어갑니다. 같은 동시성이라도 관찰 기간에는 제한이 걸리기 쉽습니다. 대량 작업은 계정을 얼마간 안정적으로 쓴 뒤에 돌리는 편이 파라미터를 반복해서 조정하는 것보다 효과적입니다.

오류 코드는 나눠서 봐야 합니다

자격 증명 오류와 지역 제한은 보통 4xx 중 서로 다른 코드로 돌아오고, 속도 제한은 별도 분류이며, 서버 장애는 5xx입니다. 속도 제한을 네트워크 장애로 보고 회선을 바꾸면 출구만 더 불안정해지고, 자격 증명 오류를 속도 제한으로 보고 기다리면 시간만 버립니다. 먼저 오류 코드로 분류하고, 그다음에 회선 교체인지 동시성 하향인지 재로그인인지 정하세요.

로그에는 세 가지를 함께 남기는 것이 좋습니다. 상태 코드, 소요 시간, 현재 출구 지역입니다. 상태 코드만 남기면 나중에 회선 문제인지 계정 문제인지 판단할 수 없습니다.

이 장 요약: 웹과 API는 요구 사항이 두 세트입니다. 엔드포인트는 따로 덮어야 하고, 타임아웃은 스트리밍을 위해 늘려야 하고, 동시성은 눌러야 하고, 오류 코드는 먼저 분류해야 합니다. 네 가지를 마치면 스크립트 쪽의 간헐적 실패가 눈에 띄게 줄어듭니다.

개발자 환경의 설정 요점

명령줄, 편집기 플러그인, 컨테이너와 CI는 완전히 다른 세 가지 네트워크 환경입니다. 공통점은 모두 브라우저 프록시 설정의 영향을 받지 않아 각자 구성해야 한다는 것입니다. 이 장에서는 환경별로 실행 가능한 설정 방법과 검증 순서를 제시합니다.

명령줄: 환경 변수가 우선

대부분의 명령줄 도구는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 세 환경 변수를 읽습니다. 셸 설정 파일에 넣어 두는 편이 매번 인자를 붙이는 것보다 안정적입니다. 대소문자에 주의하세요. 일부 도구는 소문자 형태만 인식하므로 둘 다 적어 두면 부작용 없이 안전합니다.

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7891"
export NO_PROXY="localhost,127.0.0.1,.internal,.local"

세부 사항이 하나 더 있습니다. 일부 도구는 프록시 주소를 자체 설정 파일에 적어 두는데, 설정 파일의 우선순위가 환경 변수보다 높습니다. 환경 변수를 바꿔도 효과가 없으면 설정 파일에 옛 값이 남아 있는지 먼저 확인하세요.

편집기 플러그인: 로컬 포트와 인증서

편집기 안의 AI 플러그인은 보통 로컬 프로세스가 요청을 보냅니다. 어떤 플러그인은 시스템 프록시를 읽고, 어떤 것은 자체 설정 항목만 읽고, 어떤 것은 전혀 읽지 않아 시스템 수준 분기 도구가 프로세스 이름으로 처리해야 합니다. 먼저 플러그인 설정 페이지에 프록시 항목이 있는지 확인하고, 없으면 시스템 수준 도구가 처리하게 하는 편이 환경 변수를 건드리는 것보다 안정적입니다.

인증서 문제도 이 계층에 몰려 있습니다. 플러그인이 시스템 인증서 저장소를 신뢰하지 않으면 인증서 체인 오류를 내는데, 브라우저에서 같은 주소는 정상입니다. 판단 기준은 오류 문구에 인증서 관련 단어가 있는지입니다. 있다면 먼저 인증서를 해결하고 회선을 급히 바꾸지 마세요.

컨테이너와 CI: 출구를 예측 가능하게

컨테이너 안의 환경 변수는 호스트에서 자동으로 상속되지 않으므로 오케스트레이션 파일이나 이미지 정의에 명시해야 합니다. CI 환경은 더 특수합니다. 실행기가 플랫폼에 의해 배정되어 출구 지역을 통제할 수 없으므로, 자격 증명은 반드시 플랫폼의 시크릿 관리에 두고 저장소에 쓰지 마세요. 대량 작업에 고정 출구가 필요하면 파이프라인에 고정 회선을 붙인 단계를 따로 두세요.

import os
import requests

proxies = {
    "http": os.environ.get("HTTP_PROXY", ""),
    "https": os.environ.get("HTTPS_PROXY", ""),
}
resp = requests.get(
    "https://example.com/v1/models",
    proxies=proxies,
    timeout=(10, 120),
)
print(resp.status_code)

로그에는 구체적인 주소보다 출구 지역을 남기는 편이 더 유용합니다. 주소는 바뀌고, 지역이 판단 근거이기 때문입니다.

데스크톱 클라이언트와 모바일

데스크톱과 모바일의 문제는 시스템 프록시와 클라이언트 자체 스위치가 충돌하는 데서 더 자주 생깁니다. 양쪽이 동시에 켜져 있으면 트래픽이 어느 쪽으로 가는지 확정되지 않습니다. 원칙은 같은 시점에 처리 주체를 하나만 두는 것입니다. Windows 데스크톱의 분기와 부팅 시 자동 실행 설정은 데스크톱 분기와 호환성에서 자세히 다뤘고, iOS에서 클라이언트를 받아 적용을 확인하기까지의 전체 순서는 iOS 처음부터 설정하기에 있습니다.

로컬 디버깅의 최소 검증 순서

설정을 마친 뒤 아래 네 단계로 검증하면 어느 계층이 적용되지 않았는지 빠르게 찾을 수 있습니다.

1. 먼저 브라우저로 네트워크 확인 페이지를 열어 출구 지역이 예상과 같은지 확인합니다.
2. 다음으로 명령줄에서 상태 코드만 반환하는 주소를 요청해 프로세스 수준 프록시가 적용되는지 확인합니다.
3. 그다음 편집기 플러그인에서 짧은 메시지를 보내 플러그인 계층이 프록시를 우회하지 않는지 확인합니다.
4. 마지막으로 전체 스트리밍 요청을 한 번 실행해 긴 연결이 끝까지 버티는지 확인합니다.

네 단계 중 어느 하나라도 실패하면 문제는 그 계층에 고정되므로 더 내려가서 추측할 필요가 없습니다.

이 장 요약: 브라우저 프록시는 브라우저만 담당합니다. 명령줄은 환경 변수, 플러그인은 프로세스 수준 처리, 컨테이너와 CI는 명시적 선언에 기댑니다. 네 단계 순서로 검증하는 편이 회선을 반복해서 바꾸는 것보다 시간을 아낍니다.

계정 정지와 속도 제한의 원인

계정 정지와 속도 제한은 다른 일입니다. 속도 제한은 일시적이며 보통 수십 분에서 몇 시간 안에 자동 해제됩니다. 계정 정지는 계정 단위 조치이고 복구하려면 이의 신청을 거쳐야 합니다. 속도 제한을 정지로 보고 대응하면 쓸데없는 동작을 잔뜩 하게 되고, 오히려 계정을 더 엄격한 관찰 명단으로 밀어 넣습니다. 이 장에서는 네 가지 흔한 원인으로 나눠 설명합니다.

출구 IP가 다수 계정에 공유될 때

같은 출구에 계정이 밀집할수록 플랫폼이 그 출구를 신뢰하는 정도는 낮아집니다. 이런 문제의 특징은 지역을 바꾸면 정상으로 돌아오고, 되돌리면 다시 문제가 생긴다는 점입니다. 판단 근거는 같은 회선이 다른 계정에서도 이상한지입니다. 다른 계정은 정상이라면 문제는 계정 자체에, 똑같이 이상하다면 문제는 출구에 있습니다.

공유 출구 자체는 잘못이 아닙니다. 공용 네트워크, 회사 네트워크, 학교 네트워크는 모두 공유 출구입니다. 문제는 공유 규모와 사용 리듬입니다. 같은 출구에서 아주 짧은 시간에 대량의 새 로그인과 대량의 긴 답변 요청이 발생할 때 추가 관심을 받습니다.

로그인 지역이 자주 튈 때

하루 안에 세 곳 이상의 지역에서 로그인하는 것은 가장 전형적인 이상 패턴 중 하나입니다. 여러 지역을 써야 한다면 기기마다 다른 지역을 고정하는 편이 모든 기기를 무작위로 떠돌게 하는 것보다 안전합니다. 기기와 지역을 일대일로 맞춰 두면 장기적으로 점검도 쉬워집니다.

출장이나 여행처럼 실제 지역 변화는 피할 수 없습니다. 이때는 도착한 뒤 바로 로그인하지 말고 하루 전에 미리 전환하세요. 플랫폼에 적응할 시간을 주는 것이 어떤 요령보다 효과적입니다.

자동화 스크립트와 동시성 급증

스크립트의 요청 리듬은 사람과 크게 다릅니다. 간격이 정확하고, 동시성이 높고, 멈춤이 없습니다. 동시성을 낮추고, 무작위 간격을 넣고, 실패 시 지수 백오프를 적용하는 것이 가장 효과적인 세 가지 조정입니다. 이 중 가장 빨리 효과가 나타나는 것은 동시성입니다. 속도 제한은 보통 시간 창으로 계산되어 급증에 가장 민감하기 때문입니다.

재시도 폭풍도 있습니다. 한 번 실패한 뒤 곧바로 다시 보내고, 그 재전송도 실패하면서 눈덩이처럼 커집니다. 재시도에 상한을 두고 연속 실패 후에는 스스로 잠시 멈추는 편이 무한 재시도보다 낫습니다.

결제와 구독 단계의 이상

결제 단계의 지역과 계정 지역이 충돌하는 것도 흔한 유발 요인입니다. 결제 수단 소속 지역, 청구 정보, 현재 출구 지역 세 가지를 최대한 일치시키세요. 이 원칙은 AI 도구뿐 아니라 어떤 구독 서비스에도 적용됩니다.

구독 변경 자체도 검증을 한 번 유발합니다. 업그레이드, 갱신, 결제 수단 변경은 모두 기록됩니다. 이런 작업은 가능하면 같은 기간에 모아서 처리하고, 오늘 결제 수단을 바꾸고 내일 지역을 바꾸고 모레 정보를 고치는 식으로 흩어 놓지 마세요.

접근 방식: 한 번에 변수 하나만

점검에서 가장 피해야 할 것은 회선, 계정, 기기를 동시에 바꾸는 것입니다. 한 번에 변수 하나만 바꾸고 한 차례 관찰한 뒤 다음 단계를 정하세요. 많이 바꾸면 문제가 생겼을 때 어느 항목이 원인인지 설명할 수 없어 결국 추측에 기대게 됩니다.

이 장 요약: 출구 밀도, 지역 점프, 동시성 급증, 결제 충돌이 네 가지 주요 원인입니다. 대응도 네 가지입니다. 출구를 분산하고, 지역을 고정하고, 동시성을 누르고, 지역 정보를 통일합니다. 한 번에 변수 하나만 바꾸세요.

용도별 회선 선택과 시간대 배치

회선은 빠를수록 좋은 것이 아니라 잘 맞을수록 좋습니다. 대화 한 번의 데이터량은 아주 작아서 지연에 민감하고 대역폭에는 둔감합니다. 대량 작업은 정반대입니다. 용도로 나눠 보는 편이 두루뭉술하게 속도를 재는 것보다 유용합니다. ZaraVPN은 100+ 국가 / 170+ 회선을 제공하며, 구체적인 지역과 유형은 회선 페이지에서 하나씩 확인할 수 있습니다. 실제 선택 가능한 회선은 패널을 기준으로 하세요.

세 가지 회선 유형의 차이

전용 회선은 고정 경로를 지나 우회가 적고 흔들림이 낮아 긴 연결과 실시간 대화에 적합합니다. 중계는 홉이 하나 더 붙어 커버 지역이 넓고, 특정 지역에서만 제공되는 서비스에 접근할 때 적합합니다. 직결은 가장 가벼워서 로컬 네트워크 자체가 순조로운 상황에 맞습니다. 셋에 절대적인 우열은 없고, 접근하려는 서비스가 어느 지역에 있는지, 로컬 네트워크에서 그 지역까지의 경로가 안정적인지에 달려 있습니다.

고를 때는 먼저 목표 서비스의 지역을 보고, 다음으로 로컬에서 그 지역까지의 경로를 보세요. 목표도 아시아태평양이고 로컬도 아시아태평양이면 전용 회선이 대개 가장 안정적입니다. 목표가 멀고 로컬 경로가 우회한다면 오히려 중계가 더 적합합니다.

용도별 회선 선택 대조표

표는 일반적인 권장 사항이며, 실제 선택은 로컬 네트워크에서 목표 지역까지의 경로를 기준으로 하세요. 회선 페이지에서 지역별로 하나씩 비교할 수 있습니다.

시간대 배치: 무거운 작업은 회선이 한산한 시간에

저녁 피크 시간대에는 국가 간 회선 혼잡이 가장 뚜렷해지고 긴 연결이 끊길 확률이 올라갑니다. 대량 작업이나 대용량 업로드처럼 즉시 응답이 필요 없는 작업은 아침이나 야간에 배치하면 성공률이 높아집니다. 일상 대화는 영향이 작지만, 피크 시간대에 자주 끊긴다면 같은 지역의 다른 회선으로 잠시 바꿔 보세요.

배치 방식은 일주일 업무표를 짜는 것과 비슷합니다. 안정성이 가장 중요한 작업은 회선이 가장 한산한 시간대에, 재시도가 가능한 작업은 피크 시간대에 두세요. 그러면 중간에 한 번 끊겨도 대가는 크지 않습니다.

여러 기기에 회선을 어떻게 배분할까

대수 제한이 없다는 것은 기기마다 회선을 따로 배정할 수 있다는 뜻입니다. 기기 용도별로 고정하는 것을 권합니다. 업무 기기는 안정적인 회선 하나에 고정하고, 임시 기기는 다른 회선을 쓰세요. 모든 기기가 같은 출구에 몰리지 않게 하는 것이 핵심입니다. 기기가 많을수록 출구 분산이 중요하다는 점은 앞 장의 정지 원인에서 이미 다뤘습니다.

같은 계정을 웹, 데스크톱 클라이언트, 모바일에서 동시에 쓸 때는 세 지점이 같은 지역에 놓이도록 하세요. 지역 일치가 각 회선의 개별 최적화보다 중요합니다.

트래픽을 낭비 없이 계산하는 방법

대화형 사용의 트래픽은 이미지와 파일 업로드보다 훨씬 적습니다. 월 구독 ¥9.9에 60GB면 한 사람이 일상 대화를 하는 데는 대개 충분합니다. 소재를 자주 올리거나 대량 작업을 돌릴 때 비로소 ¥18/월 250GB나 ¥28/월 500GB 두 단계가 필요해집니다. 트래픽은 개통일 기준으로 매달 초기화되고, 중간에 업그레이드하면 차액은 남은 일수로 환산됩니다. 단계별 세부 내용은 요금제 페이지에 있습니다.

트래픽 팩은 다 쓸 때까지 유효하고 영구히 만료되지 않아, 사용량이 불규칙하고 매달 갱신하고 싶지 않은 경우에 맞습니다. 사용량 기복이 큰 사용자라면 월 구독과 트래픽 팩을 나눠 보는 편이 무작정 상위 단계로 올리는 것보다 유리합니다.

이 장 요약: 회선은 목표 지역을 먼저 보고 경로를 다음에 보세요. 배치는 무거운 작업을 먼저 보고 시간대를 다음에 보세요. 여러 기기는 출구 분산이 먼저이고 각자의 최적화는 그다음입니다. 트래픽은 느낌이 아니라 용도로 계산하세요.

문제 해결과 자가 점검 체크리스트

문제 해결의 가치는 요행이 아니라 범위를 좁히는 데 있습니다. 아래 네 가지 현상은 각각 정해진 확인 순서가 있어, 그대로 따라가면 대부분 몇 분 안에 위치를 찾을 수 있습니다. 각 단계마다 변수 하나만 바꾸고, 바꾼 뒤 한 차례 관찰하고 나서 계속하세요.

열리지 않거나 계속 로딩만 될 때

먼저 일반 웹페이지로 기본 연결을 확인하고, 다음으로 네트워크 확인 페이지에서 출구 지역이 예상과 맞는지 보고, 마지막에 목표 서비스를 의심하세요. 세 단계가 모두 정상인데도 열리지 않는다면 회선에서 목표 지역까지의 경로 문제일 가능성이 크므로, 같은 지역의 다른 회선으로 바꿔 시도하세요.

회선을 바꿔도 같다면 문제는 로컬에 있을 수 있습니다. 도메인 이름 해석이 옛 주소로 캐시되었거나, 시스템 시간 편차가 커서 핸드셰이크가 실패했거나, 보안 소프트웨어가 아웃바운드 연결을 막은 경우입니다. 항목별로 하나씩 배제하는 편이 회선을 반복해서 바꾸는 것보다 효과적입니다.

답변이 중간에 끊길 때

끊긴 위치를 기록하세요. 매번 같은 초라면 타임아웃 설정을, 무작위 위치라면 회선 흔들림을 보세요. 모바일이라면 네트워크 전환을, 데스크톱이라면 처리 주체가 둘 동시에 켜져 있는지를 배제해야 합니다. 끊긴 뒤에 곧바로 다시 보내지 말고, 로그에서 마지막으로 데이터를 받은 시각이 언제인지 먼저 확인하세요.

세 번 연속 같은 길이에서 멈춘다면 계정 쪽 한도일 가능성이 높고 회선 문제가 아닙니다. 이때는 회선을 바꿔도 의미가 없으니 잠시 기다렸다가 다시 시도하는 편이 현실적입니다.

로그인 상태가 반복적으로 풀릴 때

세션 중간에 지역을 바꾼 적이 있는지, 브라우저가 사이트 데이터를 지웠는지, 같은 계정으로 여러 기기에서 동시에 로그인했는지 확인하세요. 세 가지를 모두 배제한 뒤에야 계정 자체가 더 엄격한 검증 절차에 들어갔는지 고려하세요.

시스템 시간이 정확하지 않은 경우도 있습니다. 시간 편차가 있으면 토큰 검증이 실패해서 '로그인 만료'와 거의 같은 증상이 나타납니다. 시스템 시간이 자동 동기화되는지 한 번 보는 것만으로 시간을 꽤 아낄 수 있습니다.

플러그인과 명령줄 오류

인증서 오류는 대개 프록시 도구가 루트 인증서를 제대로 설치하지 않았거나 플러그인이 시스템 인증서 저장소를 신뢰하지 않는 경우입니다. 타임아웃 오류는 프로세스 수준 프록시가 적용되는지 먼저 보세요. 연결이 재설정된다면 로컬 네트워크 문제인지 회선 문제인지 구분해야 합니다. 셋은 대응이 완전히 다르므로 먼저 오류 문구로 분류하세요.

명령줄에서 흔한 원인이 하나 더 있습니다. 도구가 자체 설정 파일을 읽어 환경 변수를 덮어쓰는 경우입니다. 환경 변수를 반복해서 고치는 것보다 설정 파일의 우선순위를 확인하는 편이 빠릅니다.

한눈에 보는 대조표

표는 증상별로 분류한 것이며 특정 플랫폼의 내부 규칙은 다루지 않습니다. 같은 증상에 여러 원인이 있을 수 있으니 순서대로 배제하면 됩니다.

이어서 보기

이 페이지는 시스템 수준의 판단 방법을 다룹니다. 특정 기기에 어떻게 설치하고 구독을 어떻게 가져오는지는 사용 안내 페이지에서 주 흐름을 한 번 따라가는 편이 빠릅니다. 어떤 회선을 고를 수 있는지 먼저 보고 싶다면 회선 페이지로, 도구별 접속 요점을 하나씩 확인하고 싶다면 AI 가속 특집이 도구별로 분류해 두었습니다.

이 장 요약: 먼저 분류하고, 그다음 점검하세요. 한 번에 변수 하나만 바꾸고, 로그를 볼 수 있으면 느낌에 기대지 마세요. 대부분의 연결 문제는 회선이 나빠서가 아니라 어느 한 계층이 제대로 설정되지 않아서 생깁니다.