LAN 파일 전송

WebRTC를 사용하여 동일 LAN 내 장치 간 파일과 텍스트를 직접 전송 — 서버 불필요

LAN 파일 전송이란?

LAN 파일 전송은 WebRTC 기술을 사용하여 장치 간 P2P(Peer-to-Peer) 통신을 실현하며, 동일 LAN 내 두 장치가 외부 서버를 경유하지 않고 파일과 텍스트 메시지를 직접 전송할 수 있게 합니다. 모든 데이터는 장치 간에 직접 전송되어 빠르고 안전합니다. 실제 문제 해결에서는 권한, 브라우저 환경, 네트워크 경로, 장치나 서버 상태를 함께 확인해야 합니다.

사용 방법

한 기기에서 "연결 생성"을 클릭하면 시스템이 연결 정보를 포함한 QR 코드를 생성합니다
다른 기기로 QR 코드를 스캔하면 페이지가 자동으로 열리고 응답 코드가 생성됩니다
첫 번째 기기에서 응답 코드를 스캔하면 WebRTC 연결이 설정됩니다
연결되면 양쪽에서 텍스트 메시지와 모든 유형의 파일을 주고받을 수 있습니다

전송 팁

파일 전송 중에는 양쪽 기기 모두 화면을 켜둔 상태에서 네트워크에 연결되어 있어야 합니다. 탭을 닫거나 기기를 절전 모드로 전환하면 WebRTC 세션이 중단됩니다.
대용량 또는 중요한 파일은 전송 후 다운로드된 파일을 확인하세요. 브라우저 메모리, 네트워크 품질, 기기 한계에 따라 신뢰도가 달라질 수 있습니다.

활용 사례

서버 업로드 없이 인근 장치 간 파일 전송하기WebRTC 연결을 생성하고 같은 네트워크의 다른 장치에 생성된 QR 코드 또는 링크를 공유한 뒤 채팅 영역에 파일을 끌어다 놓으세요. 파일 청크는 DataChannel을 통해 이동하고 수신측은 브라우저에서 재구성된 Blob을 다운로드합니다. P2P 방식이므로 전송 중 릴레이 서버, 클라우드 드라이브, 파일 저장소 중개자가 내용을 보지 않습니다.

기기 간에 간단한 텍스트 메모 옮기기P2P 연결이 설정되면 도구가 가벼운 로컬 채팅처럼 작동합니다. 메시징 앱이나 클라우드 클립보드를 사용할 수 없을 때 데스크톱에서 폰으로 명령어, URL, 일회용 코드, 짧은 메모를 전달하기 편리합니다. 메시지는 DataChannel에만 머물러 외부 서버를 거치지 않으므로 채팅 기록 동기화나 기기 백업에 나타나지 않습니다.

브라우저 간 직접 연결 테스트하기Offer/Answer 흐름이 대기, 연결, 실패, 닫힘 같은 연결 상태를 노출하고 협상이 깨졌을 때 초기화 경로를 제공합니다. P2P 연결은 설정된 ICE 서버를 사용하지 않으므로 임의의 인터넷 트래버설이 아닌 로컬 또는 접근 가능한 피어에 가장 적합하며, LAN 전용 토폴로지를 검증할 때 정확히 원하는 동작입니다.

단일 첨부 파일 제한을 초과하는 파일 전송하기WebRTC DataChannel은 스트림을 청크로 분할하므로 수백 MB의 비디오나 로그 아카이브도 이메일, Slack, 대부분의 메신저 앱 크기 제한에 걸리지 않고 브라우저 간에 직접 이동할 수 있습니다. 수신측이 다운로드용 Blob을 재구성하면서 채팅 영역에 진행 이벤트가 표시되고, 로컬 네트워크 경로는 클라우드 왕복보다 훨씬 높은 처리량을 유지합니다.

전송 후 세션 종료 및 Offer 링크 폐기하기교환이 끝나면 초기화 버튼으로 P2P 연결을 해제하고 QR 코드 또는 링크 공유를 중지하여 늦게 온 피어가 열린 방에 연결하지 못하게 하세요. 민감한 파일의 경우 수신 장치의 브라우저 다운로드 기록도 삭제하고 Offer SDP를 폐기하여 클립보드에서 재사용할 수 없게 하세요.

기술 원리

LAN 파일 전송은 WebRTC(Web Real-Time Communication) 위에 구축되어 있으며, WebRTC는 RFC 8825-8835에 정의된 W3C/IETF 표준으로 원래 브라우저 기반 실시간 오디오 및 영상을 위해 설계되었습니다. 동일한 P2P 메커니즘은 데이터 경로에 릴레이 서버 없이 두 브라우저 간에 임의의 바이너리 페이로드를 전달하는 RTCDataChannel API를 지원합니다. 채널을 여는 시그널링은 QR 코드 핸드셰이크가 수행하는 역할입니다: 제공자는 미디어 및 데이터 기능을 설명하는 SDP(Session Description Protocol, RFC 8866) 블록을 생성하고 이를 URL 또는 QR 코드로 인코딩한 뒤, 응답자는 카운터 SDP를 반환합니다. 양쪽이 원격 설명을 적용하면 ICE(Interactive Connectivity Establishment, RFC 8445)가 후보 전송 주소를 수집합니다. 각 후보는 (IP, 포트, 프로토콜) 튜플과 우선순위로 구성됩니다: 호스트 후보(장치 자체의 LAN IP)는 일반적으로 동일 네트워크에서 우선하지만, srflx(서버 반사형, STUN 바인딩 요청에서 학습)와 릴레이(TURN 릴레이, RFC 8656) 후보가 우선순위 순서로 시도됩니다. 연결 검사는 후보 간 STUN 바인딩 요청을 전송하고, 처음 성공하는 쌍이 선택된 후보 쌍이 됩니다. ICE가 연결 상태에 도달하면 DTLS(Datagram Transport Layer Security, RFC 6347, RFC 5246/8446의 TLS 1.2/1.3의 UDP 친화적 변형)가 SDP의 인증서 해시를 사용하여 양쪽 피어의 지문을 확인하고 1-RTT 핸드셰이크를 수행합니다. DTLS 세션 키는 그 위의 모든 SCTP(Stream Control Transmission Protocol, RFC 4960/RFC 9260) 패킷을 보호하며, 각 DataChannel은 단일 DTLS 연결 위에서 실행되는 SCTP 스트림 쌍입니다. 대용량 파일은 DataChannel을 통해 청크 단위로 전송됩니다. 브라우저의 SCTP 계층은 각 메시지를 약 16KB 레코드(기본 SCTP MTU에서 DTLS + SCTP + 청크 헤더 오버헤드를 뺀 값, 구현에 따라 조정 가능, 엔진에 따라 16KB 또는 64KB)로 분할하고 수신측은 순서대로 재조립합니다. 흐름 및 혼잡 제어(RFC 4960 §6)는 발신자가 수신자를 플러딩하는 것을 방지합니다: cwnd는 ACK에 따라 가법적으로 증가하고 손실에 따라 승법적으로 감소하며, 이는 TCP의 AIMD와 동일한 형태이지만 SCTP 연결별로 적용됩니다. 기가비트 LAN에서의 종단간 처리량은 일반적으로 브라우저의 메인 스레드 인코딩 비용(각 청크를 ArrayBuffer 뷰로 변환하여 SCTP 스택에 푸시)에 의해 200-400MB/s로 제한되며, 회선 속도에 의한 것이 아닙니다. 페이지는 수신 청크를 단일 Blob으로 재조립하고 다운로드로 제공하여 사용자가 바이트가 저장될 위치를 결정할 수 있게 하므로, 수신측이 피크 시 기가바이트 단위의 메모리를 차지하지 않습니다. 데이터가 DTLS-SRTP 방식의 암호화를 통해 P2P로 흐르기 때문에 중간 라우터와 릴레이 서버는 암호문만 볼 수 있습니다. 페이지 운영자는 평문을 볼 수 없고 업로드 단계도 없습니다. 대신 SDP 교환에 필요한 시그널링 서버가 필요하며, 이 페이지는 수동 서버리스 시그널링 채널로 QR 코드와 복사-붙여넣기 링크를 사용하므로 스캔이 두 번 필요합니다.

WebRTC는 W3C/IETF 표준(RFC 8825-8835)으로, SDP를 위한 협상, ICE를 위한 후보 수집, DTLS-SRTP/DTLS-SCTP를 위한 전송 보안의 세 가지 엔진을 포함합니다.
QR 코드 핸드셰이크는 서버리스 시그널링입니다: 제공자가 SDP 오퍼를 게시하고 응답자가 SDP 앤서를 반환하며, 중앙 서버가 데이터 경로를 보지 않습니다.
ICE(RFC 8445)는 호스트, srflx(STUN 반사형), prflx(피어 반사형), 릴레이(TURN, RFC 8656) 후보를 수집하며, 연결 검사를 통과하는 최고 우선순위 쌍이 선택된 전송이 됩니다.
DTLS(RFC 6347)는 SDP에 고정된 인증서 해시를 사용하여 1-RTT 지문 확인 핸드셰이크를 수행한 후, 선상의 모든 바이트를 암호화합니다 — 평문 HTTP나 WebSocket 대체 경로는 없습니다.
DataChannel은 원시 UDP가 아닌 SCTP-over-DTLS에서 실행됩니다: SCTP는 UDP 소켓 위에 혼잡 제어(RFC 4960 §6)를 갖춘 정렬된 신뢰성 있는 메시지 지향 스트림을 제공합니다.
청크 크기는 기본적으로 약 16KB입니다(브라우저에 따라 다름, 때로는 64KB): 수신측은 청크를 단일 Blob으로 재조립하고 전체 파일을 메모리에 유지하지 않도록 다운로드를 트리거합니다.
브라우저 메모리가 실제 상한선입니다: 1GB 파일은 약 1GB의 ArrayBuffer 변환을 의미하므로, 휴대폰에서는 네트워크 속도가 아닌 전송당 200-500MB가 실질적인 한계입니다.
WebRTC NAT 트래버설은 네트워크 간 피어에 STUN/TURN 서버가 필요합니다. 이 페이지는 동일 LAN 토폴로지를 가정하므로 호스트 후보(LAN IP)가 일반적으로 우선하고 STUN 서버를 조회하지 않습니다.

예시

휴대폰에서 컴퓨터로 사진 보내기

1. 컴퓨터에서 "연결 생성"을 클릭하여 QR 코드 생성
2. 휴대폰으로 스캔하면 페이지가 열리고 응답 코드가 생성됨
3. 컴퓨터에서 응답 코드를 스캔하여 핸드셰이크 완료
4. 보낼 사진을 선택하고 전송 클릭

컴퓨터에서 휴대폰으로 파일 보내기

연결이 완료되면 컴퓨터에서 "파일 전송"을 클릭하고 문서, 압축 파일 또는 동영상을 선택합니다.
휴대폰에 알림이 표시되며 한 번의 탭으로 파일이 저장됩니다.

텍스트 메시지 주고받기

연결되면 양쪽 모두 입력창에 입력하고 전송할 수 있습니다.
별도의 앱이 필요 없으며, 브라우저에서 바로 양방향 채팅이 가능합니다.

자주 묻는 질문

파일 전송은 어떻게 동작하나요?

같은 로컬 네트워크에 있는 두 기기가 WebRTC P2P로 연결됩니다. 시그널링이 연결을 설정하고 나면 파일은 브라우저 사이를 직접 오가며, 중간 서버를 거치지 않습니다. 속도는 로컬 네트워크(Wi-Fi 또는 이더넷)에 따라 달라지며, 일반적인 Wi-Fi에서는 30~150Mbps 정도가 나옵니다.

내 파일이 로컬 네트워크 밖으로 나가나요?

WebRTC 연결이 수립된 뒤에는 나가지 않습니다. 파일 바이트는 두 기기 사이로만 흐릅니다. 연결 전에는 작은 시그널링 단계(세션 디스크립션 교환)가 조정 서버를 거치는데, 이는 메타데이터일 뿐 파일 내용이 아닙니다.

왜 두 기기가 연결되지 않나요?

두 기기 모두 같은 Wi-Fi 네트워크나 LAN 세그먼트에 있어야 합니다. 사내 네트워크는 P2P 연결을 막는 경우가 많고, 게스트 Wi-Fi는 흔히 클라이언트끼리 격리합니다('client isolation'). 개인 Wi-Fi나 핫스팟에서 시도해 보세요. 어느 쪽이든 VPN이 켜져 있어도 직접 연결이 막힐 수 있습니다.

파일 크기 제한이 있나요?

WebRTC 자체에는 프로토콜상 제한이 없지만, 실질적인 한계는 브라우저 메모리와 탭 가동 시간입니다. 데스크톱에서는 몇 GB짜리 전송도 보통 잘 되지만, 모바일 브라우저는 탭을 일시 중단해 전송이 끊길 수 있습니다. 큰 파일을 전송할 때는 양쪽 탭 모두를 전면에 두세요.

전송된 파일은 암호화되나요?

네. WebRTC 데이터 채널은 DTLS-SRTP 종단 간 암호화를 사용합니다. 같은 Wi-Fi에 있는 공격자라도 파일 내용을 읽을 수 없습니다. 시그널링 단계는 조정 서버에 HTTPS로 연결됩니다. 양쪽 끝점 모두 신뢰할 수 있다면 전송 자체는 비공개로 보아도 됩니다.

기술에 익숙하지 않은 사용자도 쓸 수 있나요?

네. 상대방에게 룸 코드/URL을 공유하면 그쪽에서 브라우저로 열기만 해도 자동으로 연결됩니다. 앱 설치도 필요 없습니다. 인터페이스는 플랫폼 제약이 없는 AirDrop처럼 보입니다. iOS Safari, Android Chrome, Windows Edge, macOS Firefox 등 다양한 환경 사이에서 동작합니다.

여러 기기에 동시에 보낼 수 있나요?

대부분의 빌드는 1:1 룸을 지원합니다. 여러 수신자에게 보내려면 전송을 반복하거나 멀티캐스트 도구를 사용하세요. WebRTC로 그룹 전송을 구현하는 것도 가능하지만, 업로드 대역폭이 N배로 들어갑니다.

LAN 파일 전송