같은 Wi-Fi에서 브라우저 파일 전송 속도: 기대할 수 있는 수준
하나의 Wi-Fi 네트워크에서는 도구보다 파일이 전송 시간을 결정합니다. 정상적인 5 GHz 링크에서는 100 MB 파일이 몇 초 만에 이동하는 반면, 1 MB 파일은 생애 대부분을 설정에 씁니다. 이 페이지는 Lan-Share, LocalSend, PairDrop의 파일 크기별 예상 결과, 실제로 속도를 제한하는 요인, 그리고 체크섬으로 내 네트워크를 측정하는 4단계 방법을 정리합니다.
단계별 안내
두 기기를 같은 Wi-Fi에 연결하기
양쪽에서 5 GHz 네트워크에 접속하고, 같은 방에 두고, 어느 쪽이든 VPN을 끄세요. 대역과 거리, 간섭은 어느 도구보다도 숫자를 크게 움직이므로 이 조건들을 고정해야 두 측정을 비교할 수 있습니다.
체크섬이 있는 테스트 파일 만들기
1 MB, 10 MB, 100 MB 파일 세 개를 만드세요. 어떤 결정론적 생성기든 무방하며, Lan-Share 오픈소스 저장소에도 그런 스크립트가 포함되어 있습니다(scripts/test-file.mjs). 보내기 전에 각 파일의 SHA-256 체크섬을 기록해 두면 도착한 파일을 바이트 단위로 검증할 수 있습니다.
양쪽을 페어링하고 각 크기를 세 번씩 보내기
8자리 연결 코드로 브라우저끼리 페어링한 다음, 각 파일을 연속으로 세 번씩 보내세요. 스톱워치는 받는 쪽이 파일을 가져오기 시작할 때 켜고 마지막 바이트가 도착하면 멈춥니다. 세 번 반복하면 순간적인 출렁임이 다듬어지므로, 가운데 값을 남기세요.
바이트를 검증하고 중앙값 구하기
시행 결과를 믿기 전에 받은 파일마다 해시를 계산해 원본과 비교하세요. 파일을 몰래 재인코딩하거나 잘라낸 전송은 빠른 시행이 아니라 실패한 시행입니다. 세 도구 모두 파일을 바이트 그대로 보내므로 올바른 시행과 빠른 시행은 같은 시행입니다.
정상적인 5 GHz 네트워크 하나에서의 예상 결과(추정치이며 실험실 기록이 아님)
| 파일 크기 | 예상 시간 | 예상 속도 |
|---|
| 1 MB | 1–3 s | 대부분 설정 지연 시간 |
|---|
| 10 MB | 2–6 s | 10–35 MB/s |
|---|
| 100 MB | 3–10 s | 10–35 MB/s |
|---|
도구별 숫자가 아니라 범위 하나인 이유
세 도구는 같은 방식으로 같은 Wi-Fi를 타고 갑니다. 파일은 클라우드 중계 없이 로컬 네트워크 위에서 청크 단위로 기기에서 기기로 이동합니다. 같은 네트워크에서는 세 도구의 결과가 서로의 편차 안에 들어옵니다. 그래서 이 표는 파일 크기마다 세 개가 아니라 범위 하나를 보여 줍니다. 한 오후에 도구 사이에서 나타나는 차이는 네트워크 사이의 차이에 비하면 잡음에 불과합니다.
이 범위는 정상적인 가정용 네트워크를 전제로 합니다. 최신 공유기의 5 GHz, 같은 방의 두 기기, VPN 없음. 2.4 GHz로 바꾸거나 벽을 사이에 두거나 스트리밍 기기 세 대와 공기를 나눠 쓰면 같은 파일도 몇 배로 오래 걸립니다. 물리 법칙에서 어떤 도구도 예외가 되지 않습니다.
숫자 읽는 법
1 MB 행은 속도보다 지연 시간의 비중이 큽니다. 그 정도로 작은 파일에서는 페어링 부담, 연결 설정, 마지막 패킷을 기다리는 시간이 대부분을 차지하므로 처리량 수치가 아니라 하한선으로 읽어야 합니다. 100 MB 행이 솔직한 숫자입니다. 그 시점에는 전송이 안정 상태의 속도에 자리 잡았습니다.
속도 단위는 초당 메가바이트(MB/s)이지 메가비트(Mb/s)가 아닙니다. 비교하려면 공유기가 내세우는 메가비트 수를 8로 나누세요. 600 Mb/s를 내세우는 Wi-Fi 링크는 최대 75 MB/s 정도밖에 실어 보내지 못하고, 실제 전송은 그보다 훨씬 아래에 머뭅니다. Wi-Fi는 여러 기기가 나눠 쓰는 반이중 매체라 재전송 한 번마다 시간을 잃습니다.
전송을 느리게 만드는 것들
가장 흔한 원인은 2.4 GHz 대역입니다. 5 GHz 처리량의 일부만 실어 나르며 이웃 네트워크의 간섭을 고스란히 받습니다. 그다음은 거리입니다. 다른 방에 있는 휴대폰만으로도 속도가 절반으로 줄 수 있습니다. 어느 한쪽 기기의 VPN은 로컬 트래픽을 불필요한 터널로 끌고 가고, 공용이나 사무실 네트워크에서는 기기 격리가 기기 간 전송을 아예 막아버릴 수 있습니다.
네트워크 다음으로 전송 경로 자체가 중요합니다. Lan-Share는 파일을 256 KB 청크로 나누고 한 번에 최대 8 MB를 전송 중(in-flight)으로 유지합니다. 덕분에 브라우저 메모리를 고갈시키지 않으면서 파이프를 가득 채울 수 있습니다. 직접 경로는 연결 세부 정보에 Direct로 표시됩니다. 도구가 서버 중계로 물러서면 속도 상한이 Wi-Fi가 아니라 그 서버의 대역폭이 되어버립니다.
실험실 기록이 아니라 범위인 이유
이 숫자들은 전형적인 정상 네트워크에 대한 예상치이지 테스트 실험실에서 기록한 시행 결과가 아닙니다. 하드웨어 차이가 너무 크다는 사실 때문에 하나의 표가 그 이상을 약속할 수는 없습니다. 실제 측정값은 공유기, 아파트 환경, 휴대폰 세대, 그날의 상태에 따라 달라집니다.
위의 4단계 방법이 바로 이런 때에 쓰라고 있는 것입니다. 내 네트워크에서 내 체크섬 파일로 십 분쯤이면 믿을 만한 숫자를 얻을 수 있고, 이 페이지의 범위는 측정한 값이 정상인지 판단하는 기준이 됩니다.
무엇을 고를지
범위가 겹치므로 번거로움으로 결정하세요. Lan-Share는 양쪽 어디에도 설치 없이 브라우저에서 돌고, LocalSend는 양쪽 기기에 앱이 필요하지만 자동 검색을 더해 주고, PairDrop도 브라우저만으로 돌지만 페어링에 공용 릴레이를 필요로 합니다. 도구별 세부 사항은 LocalSend 대안 비교와 PairDrop 대안 비교에 정리되어 있습니다.
브라우저 간 방식 자체를 더 깊이 살펴보려면 — 인터넷이 아예 없는 오프라인 상황까지 포함해 — '인터넷 없이 파일 전송하기' 가이드를, 두 컴퓨터 사이라면 '인터넷 없이 두 컴퓨터 사이에서 파일 전송하기' 가이드를 참고하세요.
문제 해결
- 이 페이지의 수치에 한참 못 미치는 속도로 전송됨
원인 기기들이 2.4 GHz 대역에 있거나 공유기에서 멀리 떨어져 있거나, 벽 너머의 휴대폰이 약한 신호를 붙잡고 있을 가능성이 큽니다.
해결 방법 양쪽 기기를 공유기의 5 GHz SSID로, 같은 방으로 옮긴 뒤 다시 재보세요. 공유기가 대역별로 이름을 따로 내놓는다면 밴드 스티어링에 맡기지 말고 5 GHz를 직접 고르세요.
- 속도가 처음엔 높다가 큰 파일 중간에 무너짐
원인 네트워크의 다른 기기가 자체 대용량 전송을 시작했거나, 보내는 휴대폰이 발열로 성능을 낮추기 시작했을 수 있습니다.
해결 방법 네트워크의 다른 다운로드와 스트리밍을 잠시 멈추고, 휴대폰을 케이스에서 꺼내거나 무선 충전기에서 내려놓은 뒤 다시 시도하세요. 같은 지점에서 무너지는 현상이 반복되면 공유기의 5 GHz 채널 폭을 80 MHz로 맞춰 테스트해 보세요.
- VPN이 켜져 있어 전송이 느려지거나 실패함
원인 VPN이 트래픽을 외부 서버로 돌립니다. 파일이 집 네트워크를 나갔다가 다시 들어오고, 일부 VPN 클라이언트는 로컬 서브넷 트래픽을 아예 차단합니다.
해결 방법 로컬 전송을 할 때는 양쪽에서 VPN을 끄세요. 정책상 끌 수 없다면 VPN 클라이언트에 로컬 접근 허용 설정이 있는지 확인해 켜세요.
- 호텔, 사무실, 캠퍼스 Wi-Fi에서 두 기기가 서로를 못 봄
원인 이런 네트워크는 기기 격리를 켜 둡니다. 접속한 기기들이 서로를 주소로 호출할 수 없으므로 도구와 상관없이 직접 전송은 시작될 수 없습니다.
해결 방법 휴대폰 핫스팟을 만들고 양쪽 기기를 그쪽으로 붙이세요. 핫스팟은 격리가 없는 사설 네트워크입니다. '모바일 핫스팟으로 파일 전송하기' 가이드가 이 경로를 처음부터 끝까지 다룹니다.
자주 묻는 질문
같은 Wi-Fi에서 브라우저 파일 전송은 얼마나 빠른가요?
정상적인 5 GHz 네트워크라면 위 표의 범위를 기준으로 삼으세요. 10 MB는 몇 초, 100 MB는 대략 3~10초이며, 이는 안정적인 10–35 MB/s에 해당합니다. 경험 법칙은 이렇습니다. 공유기가 내세우는 메가비트 수를 8로 나눈 뒤, 그 값의 절반에서 3분의 2 정도를 기대하세요.
전송 속도가 공유기가 내세우는 수치보다 낮은 이유는 무엇인가요?
광고 수치는 이상적 조건에서 한 방향으로 재는 무선 링크의 날것 값입니다. 실제 전송은 승인 패킷과 재전송과 공기를 나눠 쓰고, 다른 기기의 트래픽과도 겹치며, 청크마다 프로토콜 부담을 치릅니다. Wi-Fi는 신호가 약해지면 더 낮은 속도로 떨어지므로 거리만으로도 처리량이 절반이 됩니다.
이 도구들이 속도를 위해 파일을 압축하나요?
아니요. 세 도구 모두 파일을 바이트 그대로 보내며 전송 중에 아무것도 재인코딩하지 않습니다. 위의 체크섬 방법이 정확히 그래서 동작합니다. 압축은 어차피 느린 회선에서만 도움이 됩니다. 로컬 Wi-Fi 네트워크에서는 재인코딩으로 줄여 줄 만한 회선 병목이 드물기 때문입니다.
파일 크기가 전송 속도를 바꾸나요?
작은 파일에서는 그렇습니다. 1 MB 전송은 대부분의 시간을 설정에 씁니다. 페어링, 데이터 채널 열기, 마지막 패킷 기다리기가 그 대부분이라 실질 속도가 도구의 진짜 처리량보다 훨씬 나빠 보입니다. 수십 메가바이트부터는 속도가 안정되고 파일 크기는 더 이상 중요하지 않습니다.
브라우저 탭이 정말 네이티브 앱만큼 빠른가요?
세 도구 모두 같은 Wi-Fi 위의 같은 WebRTC 데이터 채널을 타므로 링크 입장에서는 어느 쪽을 쓰는지가 중요하지 않습니다. 브라우저에는 메모리 상한이 존재하고, 그래서 역압력(backpressure)을 곁들인 청크 전송이 중요하지만, 가정용 네트워크에서 상한을 정하는 것은 탭이 아니라 Wi-Fi입니다. 각각에서 4단계 방법을 한 번씩 돌려 자신의 하드웨어 위에서 비교해 보세요.