본문으로 건너뛰기
HexaTransfer
블로그로 돌아가기
파일 전송

느린 전송 속도 해결: 업로드 문제 진단 및 해결

느린 파일 전송 속도를 진단하고 수정하세요. 네트워크 문제, 브라우저 문제, 서비스 측 병목 현상의 단계별 해결.

느린 업로드를 해결하려면 순서대로 진단하세요: speedtest-cli로 원시 연결 속도를 측정하고, DevTools에서 전송 도구의 실제 처리량과 비교하며, 대역폭을 소비하는 백그라운드 동기화를 확인하고, 서비스가 전송별로 속도를 제한하는지 검증한 뒤, 가장 가까운 지역 엔드포인트에 연결되어 있는지 확인하세요. 500Mbps 회선이 전송 서비스에 40Mbps만 제공한다면 대역폭 경합, CDN 지역 불일치, 서버 스로틀링, 또는 단일 스트림 병목 중 하나입니다. 다른 작업을 하기 전에 DevTools Network 탭에서 모든 것이 표시됩니다.

먼저 연결 속도를 측정하세요

전송 서비스를 탓하기 전에 연결이 실제로 예상한 속도를 제공하는지 확인하세요. 터미널에서 speedtest-cli --json을 실행하거나 브라우저에서 speedtest.net을 사용하세요. 업로드 Mbps, 레이턴시, 지터를 기록하세요. 이것이 최대 한계입니다. "500Mbps" 연결이 speedtest에서 업로드 80Mbps만 제공한다면 어떤 전송 서비스도 더 잘할 수 없습니다.

가능하면 Wi-Fi와 Ethernet 각각에서 두 번 테스트하세요. 차이가 Wi-Fi 비용을 알려줍니다. 평균 가정의 Wi-Fi 5에서는 유선 최대 속도의 30~50%를 잃을 것으로 예상하세요.

speedtest와 실제 전송 처리량 비교

전송 서비스를 열고 업로드를 시작한 뒤 DevTools > Network 탭을 여세요. 개별 요청 처리량을 확인하세요. speedtest가 500Mbps를 말하는데 전송이 150Mbps만 제공한다면 네 가지 원인이 있습니다: 서비스가 단일 스트림을 사용하거나(고지연 파이프를 포화시킬 수 없음), CDN 엔드포인트가 멀거나, 백그라운드 대역폭 소비자가 훔치고 있거나, 서비스가 전송별로 속도를 제한하는 것입니다.

병렬 청크 업로더(tus.io 기반 서비스, S3 멀티파트, HexaTransfer)는 4~8개의 동시 요청을 실행해야 합니다. waterfall에서 개수를 세어보세요. 빠른 회선에서 그보다 적으면 서비스가 대역폭을 낭비하고 있는 것입니다.

백그라운드 동기화 종료

macOS Activity Monitor(Network 탭, "Sent Bytes per sec" 정렬) 및 Windows Resource Monitor(Network 탭)는 모든 프로세스의 대역폭을 보여줍니다. 주요 원인: Dropbox, Google Drive, OneDrive, iCloud Photos, Backblaze, 네트워크 Time Machine, Adobe Creative Cloud 동기화. 일시 중지가 아니라 종료하세요. 일시 중지는 TCP 연결을 열어두는 경우가 있기 때문입니다.

Zoom HD 통화는 업스트림 2.5Mbps를 사용합니다. 다른 탭의 4K YouTube 업로드는 20Mbps를 소비할 수 있습니다. Slack 파일 미리보기도 수백 KB/s를 전송합니다. 비대칭 연결(다운 100Mbps, 업 10Mbps는 일반적인 케이블 플랜)에서는 빠르게 쌓입니다.

지역 엔드포인트 확인

많은 전송 서비스가 CDN 엣지를 통해 라우팅합니다. DNS나 GeoIP가 오래되었다면 시드니에서 프랑크푸르트 엣지로 업로드하고 있을 수 있으며, 이는 300ms 왕복을 추가하여 단일 스트림 처리량을 저해합니다. DevTools Network 패널로 엔드포인트 IP를 확인하고(요청 우클릭 > Copy > Copy URL, 그런 다음 nslookup), ping으로 레이턴시를 확인하세요.

전송 서비스 인제스트의 이상적 레이턴시: 같은 도시는 20ms 미만, 같은 대륙은 50ms 미만, 대륙 간은 100ms 미만. 같은 대륙에 있는데 250ms가 나온다면 먼 엣지를 통해 라우팅되고 있는 것입니다.

DNS를 변경하여 오래된 GeoIP 배제

아직 ISP 기본 DNS를 사용 중이라면 Cloudflare(1.1.1.1), Google(8.8.8.8), 또는 Quad9(9.9.9.9)를 임시로 시도해 보세요. 다른 리졸버는 ECS(EDNS Client Subnet) 쿼리에 다르게 응답하기 때문에 다른 CDN 엣지를 반환합니다. 전환만으로 업로드 레이턴시가 50ms 감소하고 처리량이 20% 향상될 수 있습니다.

라우터 버퍼블로트

버퍼블로트는 일반 speedtest에서는 보이지 않지만 혼합 사용 연결을 망칩니다. waveform.com/tools/bufferbloat에서 Waveform 버퍼블로트 테스트를 실행하세요. A+ 등급은 라우터가 대기열을 깔끔하게 처리한다는 의미입니다. F 등급은 라우터가 부하 시 200~2000ms의 레이턴시를 유발한다는 것으로, TCP 혼잡 제어가 반복적으로 후퇴하여 업로드 처리량을 대폭 감소시킵니다.

해결책: OpenWrt 또는 pfSense에서 SQM(Smart Queue Management) 활성화, Asus/Netgear/Ubiquiti에서 QoS 활성화, 또는 기본적으로 이를 지원하는 라우터 구매(최신 eero, Google Nest Wifi Pro).

VPN 비활성화(필요하지 않은 경우)

VPN은 20~80ms의 레이턴시를 추가하며 일반적으로 VPN 서버 업스트림에서 처리량을 제한합니다. 혼잡한 PIA 또는 NordVPN 엔드포인트를 통한 1Gbps 회선은 50Mbps로 떨어질 수 있습니다. 좋은 VPN 공급자(Mullvad, ProtonVPN Plus)는 더 잘 버티지만, 무료 VPN은 거의 항상 업로드를 제한합니다.

전송 서비스가 이미 TLS 1.3과 엔드투엔드 암호화를 사용한다면 전송 중 기밀성을 위해 VPN은 불필요합니다. 업로드 중에는 끄고, 이후에 다시 켜세요.

브라우저 선택과 프로토콜

Chrome, Edge, Brave, Firefox는 모두 HTTP/3(QUIC)을 기본 지원합니다. Safari도 지원하지만 일부 호스트에서는 기본적으로 HTTP/2를 사용합니다. UDP 기반 HTTP/3은 손실이 많은 셀룰러, 호텔 Wi-Fi, 또는 마지막 구간 링크에서 TCP 기반 HTTP/2보다 패킷 손실에 훨씬 더 잘 견딥니다.

DevTools의 Network > Protocol 컬럼을 확인하세요. h2라면 HTTP/2, h3이라면 HTTP/3입니다. HTTP/3으로 업로드를 제공하는 서비스는 손실이 많은 링크에서 15~30%의 처리량 향상을 보입니다.

문제 격리를 위한 다른 네트워크 시도

가장 빠른 진단법: 휴대폰을 테더링하여 테스트 청크를 1분 업로드해 보세요. 휴대폰 테더링이 홈 Wi-Fi보다 빠르다면 로컬 네트워크(라우터, ISP, 또는 장치)에 문제가 있는 것입니다. 같은 속도라면 병목은 더 upstream에 있습니다(트랜짓 혼잡, 서비스 측 한계).

이 하나의 테스트로 2분 안에 가능한 원인의 절반을 제거합니다.

서비스가 병목인 경우

일부 전송 서비스는 단순히 전송별 처리량을 제한합니다. 일부 도구의 무료 티어는 연결에 관계없이 10MB/s 이상에서 스로틀합니다. 유료 티어는 종종 스로틀을 제거합니다.

다른 모든 것을 배제했음에도 500Mbps 회선이 특정 서비스에 30Mbps만 제공한다면 서비스가 한계입니다. HexaTransfer는 전송별 스로틀이 없으며 실제 파이프가 전송당 10GB 한도까지 밀어올릴 수 있는 것을 포화시키는 병렬 청크 업로드를 실행합니다.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.

엔드투엔드 암호화로 대용량 파일을 안전하게 전송

엔드투엔드 암호화로 최대 10GB의 파일을 무료로 전송하세요. 계정이 필요하지 않습니다. 업로드 전에 브라우저에서 파일이 암호화되어 다른 사람은 읽을 수 없습니다.

파일 보내기