우리 집에서 Google Cloud의 각 리전은 얼마나 빠를까?

대부분의 '클라우드 속도 측정' 사이트와 각 업체의 Looking Glass는 그들의 서버에서 측정합니다. 데이터센터에 있는 고품질 회선 서버라서, 알 수 있는 건 '데이터센터에서 데이터센터까지'의 속도뿐입니다. 정작 내가 체감하는 부분, 즉 집 인터넷이나 모바일 회선, 통신사 백본, 국제 구간, 오늘 저녁의 혼잡은 잴 수 없습니다.

Me2Cloud는 모든 요청을 내 브라우저에서 보냅니다. Wi‑Fi, 공유기, 통신사, 통신사가 고른 경로, 저녁 피크까지 전부 결과에 들어갑니다.

1. 먼저 워밍업 요청으로 DNS, TCP, TLS를 맺습니다. 이 시간은 보여 주지만 집계에는 넣지 않습니다.
2. 이어서 같은 연결로 같은 호스트에 5, 10, 20번 요청합니다. 한 번에 왕복 한 번과 업체 서버의 처리 시간만 걸립니다.
3. 업체마다 연결을 유지한다고 확인한 방식을 씁니다: AWS, Azure, Google Cloud, Huawei Cloud, DigitalOcean, Scaleway는 GET, Oracle, IBM Cloud, Alibaba Cloud, Tencent Cloud, Volcengine, Baidu AI Cloud, Naver Cloud, Linode, Vultr, OVHcloud는 HEAD(GET은 연결이 끊겨 3배가 됨), Hetzner만 <img>.
4. 결과는 중앙값(가장 대표적인 값), 평균, P90(10번 중 9번은 이 이하), 지터(연속 두 번의 차이 평균), 손실(시간 초과 비율)입니다.
5. 등급은 중앙값으로 정합니다: T0 갓 ≤ 30 ms, T1 최상급 ≤ 80 ms, T2 상위권 ≤ 150 ms, T3 NPC ≤ 250 ms, 그 이상은 T4 망함. 추천에 쓰는 종합 점수는 '중앙값 + 2 × 지터 + 손실 벌점'이라, 안정적인 60 ms가 들쭉날쭉한 45 ms보다 앞섭니다.

• 내 트래픽과 같은 길. 웹, API, 443 포트 터널, 게임 로그인, 다운로드는 모두 TCP입니다. 많은 통신사가 ICMP를 따로 줄 세우거나 제한하거나 다른 경로로 보내서, ping은 좋은데 페이지가 느리거나 그 반대인 경우가 흔합니다.
• 제한에 묻히지 않음. 공유기와 클라우드는 ICMP를 자주 제한·폐기하지만 공개 HTTPS 엔드포인트는 항상 응답합니다.
• 실제 환경이 반영됨. DNS, IPv4/IPv6 선택, 프록시, 가속 서비스가 브라우저 트래픽에도 적용되므로 실제로 얻는 속도를 잽니다.
• 대신: 매번 약간의 일정한 서버 처리 시간이 들어갑니다. 실측으로 AWS는 0–5 ms, Alibaba Cloud는 약 8 ms, Huawei Cloud OBS는 약 20 ms. 100 ms가 넘는 거리에서는 무시해도 되지만, 아주 가까운 리전에서는 ping보다 조금 크게 나옵니다.

• 가정용 회선은 저녁 20:00–23:00에 가장 붐비고, 해외 구간은 더 심합니다. 낮에는 T1 최상급이던 리전이 밤에는 NPC까지 떨어지기도 합니다.
• 낮에 한 번, 피크에 한 번 재 보세요. 저장된 결과에는 '피크 시간' 표시가 붙고, 결과 화면에서 바꿔 가며 비교할 수 있습니다.
• 측정 중에는 큰 다운로드, 동영상, 클라우드 동기화를 멈추세요. 유선이 Wi‑Fi보다 정확하고, Wi‑Fi라면 공유기 가까이에서.
• 모바일 데이터에서는 신호 세기에 따라 결과가 달라집니다. 실제로 쓸 곳에서 재는 게 가장 좋습니다.

• 서버, 게임 서버, CDN 원본을 계약하기 전에 후보 리전을 추릴 때.
• 같은 업체의 리전끼리, 또는 같은 도시의 다른 업체를 비교할 때.
• 게임, 화상 회의, 원격 데스크톱, SSH에 충분히 안정적인지(지터, 손실) 확인할 때.
• 프록시, 가속 서비스, 새 인터넷 요금제가 정말 효과가 있는지 켜고 끄며 비교할 때.
• 사용자 지정 대상으로 내 서버나 CDN을 대형 업체와 나란히 비교할 때.

• 한 곳의 결과일 뿐입니다. 내 회선이지 사용자 회선이 아닙니다. 사용자 몇 명에게도 재 달라고 하고 내보내서 비교하세요.
• 재는 건 엔드포인트이지, 앞으로 쓸 서버 자체가 아닙니다. 그 리전의 공개 API나 스토리지를 잽니다. 같은 리전의 서버는 보통 같은 네트워크지만 프리미엄 회선(CN2, BGP와 단일 통신사, Lightsail과 EC2 등)은 다를 수 있습니다.
• 대역폭, UDP, 경로는 재지 않습니다. 왕복 시간만 재며 다운로드 속도, UDP 게임 트래픽, 중간 경로는 모릅니다.
• 브라우저의 영향. 확장 기능, 프록시, VPN, 무거운 탭은 잡음이 됩니다. 무거운 탭은 닫고 이 페이지를 앞에 두세요.
• Hetzner는 브라우저에서 연결을 유지할 수 없어 매번 핸드셰이크가 포함됩니다. 일부 나라에서는 닿지 않는 대상도 있습니다.

• 이 페이지는 Cloudflare에 올린 정적 파일뿐입니다. 백엔드도 가입도 분석 도구도 없고, 결과를 업로드하지 않습니다.
• 테스트 요청은 모두 브라우저에서 업체로 바로 갑니다. 위의 요청 기록이나 개발자 도구 Network 탭에서 하나씩 볼 수 있습니다.
• 네트워크 정보는 Cloudflare(speed.cloudflare.com/meta, /cdn-cgi/trace)에서 받고, 선택 사항인 WebRTC 확인은 stun.cloudflare.com에 UDP 출구 주소를 묻습니다. 설정에서 끌 수 있습니다.
• 설정, 사용자 지정 대상, 최근 결과는 이 브라우저의 로컬 저장소에만 있고 '테스트 데이터 지우기'로 결과를 지울 수 있습니다.

공개 엔드포인트를 너무 세게 두드리면 업체의 속도 제한이나 WAF에 걸리고 결과도 망가집니다. 그래서 테스트 속도를 일부러 낮췄습니다:

• 호스트마다 동시에 요청 1개, 샘플 사이는 250–370 ms 쉼(호스트당 초당 최대 2–3회).
• 업체마다 동시에 최대 2개 호스트, 전체 최대 8개(기본 4개).
• 한 번 테스트에 호스트당 최대 21번 요청(워밍업 + 20). 연속 모드 없음.
• 3번 연속 실패한 호스트는 포기하고 계속 재시도하지 않습니다.
• 모두 익명, 쿠키와 Referer 없는 '단순 요청': 사전 요청 없음, 응답은 수백 바이트, 가능하면 HEAD, 큰 파일은 받지 않습니다.

전체 트래픽은 평범한 웹 페이지 하나를 여는 것보다 적습니다. 모든 대상이 익명 요청에 정상 응답하는 것을 확인했습니다(200, 403, 404 모두 측정에는 문제없음).

트래픽이 프록시를 거치면 브라우저가 재는 건 '나→프록시'와 '프록시→업체'이지 내 회선이 아닙니다. 네트워크 표시는 출구가 데이터센터인지, 시간대와 출구 국가가 다른지, WARP가 켜졌는지, WebRTC와 HTTPS 출구가 다른지 같은 흔한 징후를 확인합니다.

직접 연결 규칙 받기로 테스트용 호스트만 직접 연결하게 하고(Clash / Mihomo, Surge, Shadowrocket, Quantumult X, Loon, sing-box, Xray, SwitchyOmega, 도메인 목록 지원) 다시 확인하세요. 프록시 자체를 재고 싶다면 그대로 재면 되고, 그게 프록시의 실제 성능입니다.

• 각 행의 막대는 같은 눈금(로그, 2 ms~3초)입니다. 점은 각 샘플, 띠는 샘플의 가운데 절반 범위, 세로선은 중앙값입니다.
• 띠가 좁을수록 안정적이고, 띠가 넓거나 점이 흩어지면 지터가 큽니다. 빨간 ×는 손실 횟수입니다.
• 행을 펼치면 샘플별 추이, 모든 통계, 사용한 대상이 보입니다. ✓는 조건에 맞는 리전입니다.