피어 투 피어 암호화 파일 전송 기술 가이드

개인정보 보호법(PIPA) 제17조는 개인정보의 제3자 제공에 엄격한 동의 요건을 부과합니다. P2P 파일 전송은 파일이 서버에 저장되지 않으므로 이 요건을 본질적으로 충족하는 방식입니다. WebRTC(RFC 8825~8837)는 DTLS 1.3 over UDP 암호화 데이터 채널, ICE·STUN·TURN을 통한 NAT 통과, WebSocket이나 HTTP를 통한 시그널링을 제공합니다. Snapdrop, Wormhole.app, Magic Wormhole이 이 모델의 작동을 증명합니다.

P2P 파일 전송의 장점

매력은 단순합니다: 서버에 파일이 저장되지 않고, 전송 서비스에 대역폭 비용이 없으며, 발신자의 업로드가 곧 수신자의 다운로드입니다. 같은 기가비트 LAN의 두 사용자 간 10GB 전송에서 P2P는 80초에 끝낼 수 있지만, 클라우드 릴레이는 원거리 서버에 업로드 후 다시 다운로드하며 대역폭 사용과 지연 시간을 두 배로 만듭니다. 트레이드오프: 두 당사자가 동시에 온라인이어야 하고, NAT 통과가 실패하는 경우가 있으며, 연결 속도는 더 느린 참여자의 업로드 링크에 종속됩니다.

WebRTC 데이터 채널을 전송으로 사용

WebRTC는 비디오·오디오 프로토콜로 시작했지만 RTCDataChannel이 임의의 바이너리 메시지 전송을 제공합니다. 내부적으로 데이터 채널은 SCTP over DTLS 1.3 over UDP로 동작합니다. DTLS 계층이 AES-128-GCM 또는 ChaCha20-Poly1305로 기밀성과 인증된 무결성을 제공합니다. 파일 전송에는 신뢰할 수 있는 순서 채널을 만들고, 파일을 16KB~64KB 메시지로 청크하여(Chrome의 역사적 한계 256KB), bufferedAmount 임계값을 통한 흐름 제어로 순차 전송합니다.

시그널링 서버의 역할

WebRTC는 피어 간 연결 정보(SDP 오퍼·앤서, ICE 후보)를 교환할 시그널링 서버가 필요합니다. 시그널링 서버는 파일 바이트가 아닌 약 5KB의 연결 메타데이터만 릴레이합니다. Node.js, Python, Go의 WebSocket 기반 시그널링 서비스가 수백 줄의 코드로 이를 처리합니다. Firebase Realtime Database, Supabase Realtime, Pusher도 시그널링 백엔드로 작동합니다. 시그널링 서버는 누가 언제 누구와 통신하는지 알지만 파일 내용은 절대 보지 못합니다.

NAT 통과: STUN, TURN, ICE

대부분의 기기는 NAT 뒤에 있어 직접 IP 연결이 불가능합니다. ICE(Interactive Connectivity Establishment, RFC 8445)는 여러 연결 경로를 시도합니다. STUN(RFC 8489)은 피어가 퍼블릭 STUN 서버를 통해 공개 IP와 포트를 발견하게 합니다. 두 피어가 합리적인 NAT(full-cone 또는 restricted-cone)를 가지면 직접 UDP 연결이 작동하며 약 70%의 시도에서 성공합니다. 대칭 NAT, 기업 방화벽, CGNAT의 경우 TURN(RFC 8656)이 서버를 통해 트래픽을 릴레이합니다. 실제로 P2P 전송의 10~30%가 TURN으로 폴백합니다.

DTLS 위에 암호화 계층 추가

DTLS는 이미 WebRTC 데이터를 암호화하므로, 추가적인 앱 계층 암호화는 이중 안전망입니다. DTLS 핸드셰이크가 피어 인증서를 인증하지만 WebRTC는 일반적으로 자기 서명 인증서를 사용해 신원이 아닌 연결을 검증합니다. SPAKE2 PAKE(Password-Authenticated Key Exchange)를 사용하는 Magic Wormhole은 사람이 읽을 수 있는 짧은 문구에서 강력한 키를 도출해, 시그널링 서버가 손상되어도 복호화할 수 없습니다. AES-256-GCM과 시그널링 랑데부에서 도출된 공유 비밀을 사용한 앱 계층 암호화가 신원 보장을 추가합니다.

P2P 파일 전송의 청킹 전략

WebRTC 데이터 채널의 메시지 크기 한계(대부분 브라우저에서 256KB)로 인해 파일을 16KB~64KB 메시지로 청크해야 합니다. bufferedAmount와 bufferedAmountLowThreshold로 백프레셔를 구현하고, 버퍼가 1MB를 초과하면 전송을 일시 중지하고 256KB 아래로 떨어지면 재개합니다. 무결성을 위해 각 청크를 SHA-256으로 해시하고 먼저 전송된 매니페스트에 해시를 포함합니다.

모바일과 크로스 기기 고려사항

데스크톱 간 P2P는 잘 작동합니다. 모바일-데스크톱에서는 모바일 브라우저의 공격적인 탭 일시 중지, iOS Safari의 덜 신뢰할 수 있는 데이터 채널 구현이 복잡성을 추가합니다. 지속적인 WebRTC 세션은 배터리를 빠르게 소모합니다. 같은 Wi-Fi의 모바일 간 전송에서는 AirDrop(iOS/macOS)과 Nearby Share(Android)가 브라우저 P2P를 능가합니다.

P2P에 특유한 보안 위협

P2P는 클라우드 릴레이에 없는 위협을 도입합니다. IP 주소 노출: 직접 연결은 각 피어의 공개 IP를 상대방에게 드러내 내부 고발이나 활동가처럼 프라이버시에 민감한 맥락에서 신원 노출 위험이 있습니다. 악성 코드 배포는 서비스 운영자가 파일 내용을 절대 보지 못하므로 모더레이션이 어렵습니다. 시그널링 서버의 연결 고갈을 통한 서비스 거부 공격에는 레이트 리밋이 필요합니다.

클라우드 릴레이가 여전히 이기는 경우

발신자와 수신자가 동시에 온라인이 아닌 비동기 전송에서 P2P는 완전히 실패합니다. 세션 창을 초과하는 대용량 전송(모바일 브라우저 탭 종료, 노트북 절전)에서는 클라우드 릴레이의 "업로드 후 링크 공유" 모델이 훨씬 실용적입니다. HexaTransfer는 클라이언트 측 AES-256-GCM 암호화와 함께 클라우드 릴레이 모델을 사용해 P2P의 프라이버시 혜택 대부분을 누리면서 비동기 및 다중 수신자 지원을 훨씬 잘 처리합니다.

https://hexatransfer.com — 무료, 계정 불필요, 최대 10GB.