대역폭 최적화 팁: 더 빠른 파일 전송을 위해

업로드 대역폭을 최대한 활용하려면 네 가지를 하세요. 기가비트 이더넷(Ethernet)으로 유선 연결, 라우터의 QoS 또는 SQM을 켜서 버퍼블로트(bufferbloat) 제거, ISP가 지원한다면 IPv6으로 전환, 전송 중 Dropbox, iCloud, Google Drive 같은 백그라운드 동기화 일시 중지. 실제로 500 Mbps 업로드 회선인데 180 Mbps만 나오는 경우, 이 네 가지 조치를 합산하면 200~280 Mbps의 처리량을 회수해 10 GB 전송 시간을 45분에서 15분 이내로 줄일 수 있습니다.

대용량 파일엔 유선 연결이 기본

Wi-Fi 6(802.11ax)은 좋은 환경에서 2x2 클라이언트 기준 실제 처리량이 약 600 Mbps입니다. Wi-Fi 5(802.11ac)는 300 Mbps 수준입니다. 벽 하나를 사이에 두면 이 수치가 40~60% 떨어집니다. 기가비트 이더넷은 항상 940 Mbps를 1 ms 미만의 지터로 안정적으로 제공합니다.

15달러짜리 USB-C to Gigabit Ethernet 어댑터가 2 GB 이상의 업로드에서 대부분 노트북의 내장 Wi-Fi를 압도합니다. 케이블을 연결할 수 없다면 최소한 5 GHz 대역으로 전환하고 라우터와 가시선(line-of-sight) 거리 내에 위치하세요. 2.4 GHz는 실제 조건에서 60~80 Mbps에 그치며 파일 전송에는 부적합합니다.

QoS와 SQM으로 버퍼블로트 제거하기

버퍼블로트는 누군가 업로드를 시작하는 순간 Zoom 통화가 끊기는 이유입니다. 전통적인 라우터 버퍼는 포화된 링크에서 패킷을 수초 동안 대기열에 쌓아 지연 시간을 파괴합니다. SQM(Smart Queue Management) 알고리즘인 CAKE와 fq_codel은 부하 상태에서도 대기열을 짧게 유지해, 500 Mbps 업로드가 다른 모든 것에 300 ms의 지연을 추가하지 않습니다.

OpenWrt, pfSense, 그리고 대부분의 최신 라우터(Merlin 펌웨어의 Asus, Ubiquiti UniFi, eero Pro 6E)가 SQM을 지원합니다. 활성화하고, 업링크를 프로비저닝 속도의 약 95%로 설정하면, DSLReports나 Waveform 버퍼블로트 테스트 등급이 F에서 A+로 올라갑니다.

이는 대역폭을 추가하는 것이 아니라, 버퍼블로트로 인해 TCP 송신자가 반복적으로 후퇴하면서 발생하는 40~60%의 처리량 손실을 제거합니다.

IPv6가 보통 더 빠릅니다

듀얼 스택을 지원하는 ISP에서 IPv6는 주요 클라우드 목적지로 더 직접적으로 라우팅되는 경우가 많습니다. AWS, Google Cloud, Cloudflare, Azure 모두 네이티브 IPv6를 실행하며, IPv6 패킷은 모바일 및 일부 가정용 네트워크에서 흔한 IPv4 CGNAT 경로보다 NAT 홉을 1~2개 덜 거칩니다.

ipv6-test.com 또는 test-ipv6.com에서 확인해 보세요. 10/10이라면 이미 IPv6를 사용 중입니다. 그렇지 않다면 라우터에서 IPv6를 활성화하세요(대부분의 ISP가 DHCPv6 또는 PPPoE로 자동 설정을 제공합니다). 대륙 간 업로드에서 20~40%의 차이가 날 수 있습니다.

백그라운드 동기화 앱 모두 끄기

Dropbox, Google Drive, OneDrive, iCloud Photos, 네트워크를 통한 Time Machine, Backblaze 같은 백업 도구는 모두 업로드 대역폭을 조용히 소비합니다. macOS Activity Monitor(네트워크 탭, "전송 바이트" 기준 정렬)와 Windows 리소스 모니터에서 범인을 찾을 수 있습니다.

대용량 전송 전에 명시적으로 일시 중지하세요. iCloud Photos는 특히 촬영 후 가져오기를 완료하면 기가바이트를 조용히 올려보냅니다. Backblaze의 기본 제한은 "자동"으로, 유휴 연결에서 가능한 모든 대역폭을 사용하는 것을 의미합니다.

1080p Zoom 통화는 업스트림 약 3 Mbps를 사용합니다. Google Meet HD 통화는 약 2.5 Mbps입니다. 집에 누군가 화상 통화 중이라면 전송을 그 주변으로 예약하거나 2~3 Mbps 손실을 감수하세요.

DNS와 첫 바이트 시간

잘못 구성된 DNS는 TCP 연결이 시작되기 전에 50~200 ms의 지연을 추가할 수 있습니다. 여전히 ISP 기본 리졸버를 사용 중이라면 Cloudflare의 1.1.1.1 또는 Google의 8.8.8.8로 변경해 보세요. dig +stats 전송서비스.com으로 응답 시간을 비교하세요. 많은 연결을 여는 청크 업로드에서 빠른 리졸버가 전체 처리량에 눈에 띄게 기여합니다.

macOS에서 DNS 변경: 시스템 설정 → 네트워크 → 세부 정보 → DNS. Windows 11: 설정 → 네트워크 및 인터넷 → (어댑터) → DNS 서버 할당 편집.

특이한 네트워크에서의 MTU 조정

VPN, PPPoE DSL 연결, 셀룰러 업링크를 사용 중이라면 MTU가 기본값인 1500 바이트보다 낮을 수 있습니다. MTU가 맞지 않으면 TCP 단편화, 재전송, 처리량 붕괴로 이어집니다. macOS/Linux에서 ping -s 1472 -D google.com, Windows에서 ping -f -l 1472 google.com으로 테스트하세요. 패킷이 돌아오지 않으면 10 바이트씩 낮춰가며 패킷이 반환되는 값을 찾고, 거기에 ICMP 오버헤드 28 바이트를 더한 값을 인터페이스 MTU로 설정하세요.

일반적인 작동 값: 일반 광대역 1500, PPPoE DSL 1492, 일부 WireGuard VPN 1428, 대부분의 5G 통신사 1400.

혼잡 제어: BBR vs Cubic

클라우드로 업로드하는 Linux 시스템에서 TCP 혼잡 제어를 Cubic에서 BBR(Bottleneck Bandwidth and RTT)로 전환하면 고지연, 약간의 손실이 있는 링크에서 처리량이 두 배가 될 수 있습니다. sysctl -w net.ipv4.tcp_congestion_control=bbr로 활성화하세요. macOS와 Windows는 Cubic 기반 알고리즘을 기본으로 사용하며 이 설정을 쉽게 노출하지 않습니다. 하지만 클라우드 호스팅 전송 엔드포인트는 점점 더 BBR을 실행하고 있어, 내 쪽에서 사용하지 않더라도 도움이 됩니다.

이것이 Google Cloud에서 실행되는 서비스(Smash, 일부 SwissTransfer 트래픽)가 레거시 호스트의 동일한 서비스보다 빠르게 느껴지는 이유 중 하나입니다.

브라우저 선택도 중요합니다

Chromium 기반 브라우저(Chrome, Edge, Brave, Arc)는 기본적으로 HTTP/3과 QUIC를 지원하며, 손실이 있는 링크에서 HTTPS 대비 HTTP/2보다 15~25% 더 우수합니다. Firefox도 QUIC를 지원합니다. Safari 17+는 HTTP/3을 지원하지만 일부 서비스에서는 HTTP/2를 기본으로 사용합니다. DevTools 네트워크 패널의 "프로토콜" 열로 확인하세요.

전송 서비스의 업로드 엔드포인트가 HTTP/3를 제공한다면, 4~8개의 동시 스트림을 여는 병렬 업로드에서 청크당 핸드셰이크 왕복이 줄어듭니다.

대역폭을 존중하는 서비스 선택하기

일부 전송 서비스는 아무리 대역폭이 넉넉해도 업로드 속도를 제한합니다. 50 GB 회선도 전송당 30 Mbps로 상한을 두는 도구에서는 느릴 수밖에 없습니다. HexaTransfer는 Web Workers에서 AES-256-GCM 암호화를 실행하면서 HTTP/2로 병렬 청크를 스트리밍하므로, 업로드가 전송당 10 GB 상한까지 연결이 실제로 제공할 수 있는 속도를 그대로 활용합니다. GDPR, HIPAA, PIPA(개인정보 보호법) 준수가 필요한 데이터도 클라이언트 사이드 암호화로 안전하게 처리됩니다.

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