WebRTC 파일 전송을 쓰면 두 브라우저가 클라우드 저장소에 업로드하지 않고 서로 파일을 보낼 수 있습니다. 간단해 보이지만, 인터넷은 원래 가정용 컴퓨터 두 대가 서로 직접 연결하도록 만들어지지 않았습니다. 이 가이드는 StrongFolder를 예로 들어 실제로 무슨 일이 일어나는지, 즉 시그널링, NAT, STUN, ICE, TURN, DTLS, 데이터 채널을 쉬운 말로 설명합니다.
WebRTC란 무엇인가요?
WebRTC(Web Real-Time Communication)는 W3C와 IETF가 표준화한, 브라우저 간 실시간 연결을 위한 브라우저 API와 네트워크 프로토콜의 모음입니다. Chrome, Edge, Firefox, Safari, Opera 모두 지원합니다. 화상·음성 통화용으로 만들어졌지만, 어떤 바이너리 데이터든 실어 나르는 데이터 채널도 있습니다. 파일이 바로 그런 데이터입니다.
핵심 특성은 이렇습니다. WebRTC 연결이 한번 설정되면 데이터는 서버의 저장소로 가지 않고 두 끝점 사이를 오갑니다. 이것이 브라우저에서 하는 P2P 파일 전송을 가능하게 합니다.
두 브라우저는 왜 그냥 서로 연결할 수 없나요?
자기만의 공인 주소를 가진 기기가 거의 없기 때문입니다. 노트북은 가정용 공유기, 사무실 방화벽, 또는 이동통신사 네트워크 뒤에 있습니다. 공유기는 NAT(Network Address Translation)를 수행합니다. 여러 사설 기기가 하나의 공인 IP 주소를 나눠 쓰며, 공유기는 안에서 보낸 무언가에 대한 응답 트래픽만 들여보냅니다.
그래서 두 브라우저는 파일 데이터가 흐르기 전에 세 가지 문제에 부딪힙니다.
- 서로에게 닿는 방법을 모릅니다. 상대가 있다는 것조차 모릅니다.
- 자신의 공인 주소를 모릅니다. 192.168.1.20 같은 사설 주소만 압니다.
- 공유기가 요청하지 않은 수신 트래픽을 막을 수 있습니다.
WebRTC는 각 문제를 별도의 메커니즘으로 해결합니다.
WebRTC 파일 전송은 단계별로 어떻게 작동하나요?
"공유"를 클릭하는 순간부터 마지막 바이트까지의 전체 흐름입니다.
Sender browser Servers Recipient browser
────────────── ─────── ─────────────────
1. Choose files ──── metadata ──▶ Signaling server
◀──────── 2. Open link ────────
3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP)
4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?"
5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates
6. ICE checks: try LAN → direct internet → TURN relay
7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake
8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk
1–2단계 — 시그널링. 보내는 사람이 파일을 고르면 서비스가 링크에 필요한 메타데이터를 기록합니다. 받는 사람이 링크를 열면 두 브라우저가 시그널링 서버에 연결됩니다. WebRTC는 시그널링 방식을 정의하지 않으며, StrongFolder는 자체 시그널링 서버와 함께 PeerJS를 씁니다.
3단계 — 제안과 응답. 한 브라우저가 SDP(Session Description Protocol)로 **제안(offer)**을 만듭니다. "데이터 채널을 원합니다. 제 암호화 지문과 기능은 이렇습니다." 다른 브라우저가 **응답(answer)**으로 답합니다. 둘 다 시그널링 서버를 거칩니다.
4단계 — STUN. 각 브라우저는 STUN 서버에 "내가 어떤 주소와 포트에서 오는 것으로 보이나요?"라고 묻습니다. 답은 공유기가 매핑한 공인 주소입니다. STUN 서버는 아주 작은 요청만 처리하며 파일 데이터는 다루지 않습니다. StrongFolder는 Google을 포함한 공개 STUN 서버와 자체 서버를 씁니다.
5단계 — ICE 후보. 각 브라우저는 자신에게 닿을 수 있는 방법인 **후보(candidate)**를 모읍니다. 로컬 네트워크 주소(host), STUN에서 얻은 공인 주소(server-reflexive), TURN 중계 서버의 주소(relayed)입니다. 그리고 시그널링을 통해 후보를 교환합니다.
6단계 — 연결 확인. ICE(Interactive Connectivity Establishment)는 후보 쌍을 시험해 작동하는 것 중 가장 좋은 경로를 고릅니다. 두 기기가 같은 Wi-Fi에 있으면 로컬 경로가 선택됩니다. 공유기가 허용하면 직접 인터넷 경로("홀 펀칭")가 선택됩니다. 직접 경로가 하나도 안 되면 중계 경로를 씁니다.
7단계 — DTLS. 데이터가 흐르기 전에 브라우저는 DTLS 핸드셰이크(UDP용으로 변형한 TLS)를 수행하고, 인증서 지문이 제안과 응답에 담긴 것과 일치하는지 확인합니다. 이제부터 모든 것이 암호화됩니다.
8단계 — 데이터 채널. DTLS 위에서 SCTP가 작동하며, 데이터 채널에 신뢰성 있고 순서가 보장되는 전달을 제공합니다. StrongFolder에서는 받는 사람의 브라우저가 파일을 요청하고, 보내는 사람의 브라우저가 디스크에서 파일을 조각 단위로 읽어 보내며, 받는 사람은 조각이 도착할 때마다 디스크에 씁니다. 그래서 아주 큰 파일도 메모리에 다 올릴 필요가 없습니다.
STUN, TURN, ICE 등의 용어는 무슨 뜻인가요?
| 용어 | 하는 일 | 파일 데이터를 보나? | 표준 |
|---|---|---|---|
| 시그널링 | 브라우저 사이에서 제안, 응답, 후보를 전달 | 아니요 | 표준 없음(앱마다 다름) |
| NAT | 하나의 공인 IP를 여러 기기가 나눠 쓰게 하는 공유기 기능 | — | — |
| STUN | 브라우저에 공인 주소와 포트를 알려 줌 | 아니요 | IETF RFC 8489 |
| ICE | 후보를 모으고 작동하는 경로를 고름 | 아니요 | IETF RFC 8445 |
| TURN | 직접 경로가 안 될 때 트래픽을 중계 | 암호화된 패킷만 | IETF RFC 8656 |
| DTLS | 연결을 암호화(UDP용 TLS) | 암호화함 | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| SCTP 데이터 채널 | 조각을 신뢰성 있게, 순서대로 전달 | 실어 나름(암호화 상태) | IETF RFC 8831 |
모든 용어는 용어집에 간단히 설명되어 있습니다.
TURN 중계는 언제 쓰이고, 무엇을 보나요?
중계는 기본이 아니라 대체 수단입니다. ICE는 직접 후보 쌍이 하나도 연결되지 않을 때만 중계를 씁니다. 대표적으로 대칭형 NAT(일부 이동통신사)를 쓰는 네트워크, 외부로 나가는 UDP를 막는 회사 방화벽, 또는 일부 VPN입니다.
직접 연결이 불가능한 경우(엄격한 회사 방화벽, 일부 모바일 네트워크) 암호화된 데이터는 StrongFolder 중계(TURN) 서버를 거칩니다. 중계 서버는 데이터를 전달만 하고 저장하지 않습니다.
중계 서버는 DTLS로 암호화된 패킷을 받아 넘겨줍니다. 트래픽이 흐른다는 것, 얼마나 언제 흐르는지는 볼 수 있지만 안에 무엇이 들었는지는 볼 수 없습니다. 모든 바이트가 중계 서버를 한 번 더 거치므로 중계 전송은 직접 전송보다 느릴 수 있습니다. 전송이 유난히 느리다면 다른 네트워크를 써 보세요. 사무실 네트워크에서는 안 되던 직접 연결이 휴대폰 핫스팟이나 집 Wi-Fi에서는 되는 경우가 많습니다.
무료 · 브라우저에서 바로 · 가입 불필요
WebRTC 암호화는 얼마나 안전한가요?
WebRTC는 암호화를 필수로 합니다. 암호화되지 않은 데이터 채널을 열 방법이 없습니다. DTLS는 두 브라우저가 협상한 최신 암호 방식을 쓰며, 연결마다 새 키가 만들어집니다.
모든 WebRTC 서비스에 해당하는 솔직한 단서가 하나 있습니다. 두 브라우저는 시그널링 서버를 통해 교환된 인증서 지문으로 서로를 확인합니다. 따라서 서비스의 시그널링이 지문을 조작하지 않는다고 믿어야 합니다. 그래서 StrongFolder는 자신의 보호를 직접 보유한 키를 쓰는 종단 간 암호화나 "제로 지식"이 아니라 전송 중 암호화라고 설명합니다. "안전하다"의 더 넓은 의미는 안전한 파일 공유와 보안 및 개인정보를 읽어 보세요.
보내는 사람의 브라우저는 왜 열려 있어야 하나요?
보내는 사람의 브라우저가 곧 원본이기 때문입니다. 대신 쓸 서버 사본이 없습니다. 데이터 채널은 탭이 열려 있고 기기가 깨어 있는 동안에만 보내는 사람의 디스크에서 조각을 읽습니다. 받는 사람이 다운로드를 마칠 때까지 보내는 사람의 브라우저 탭은 열린 채 온라인 상태여야 합니다. 파일은 서버가 아니라 보내는 사람의 기기에서 전송되기 때문입니다. 이에 대비하는 방법은 보내는 사람이 온라인을 유지해야 하는 이유에서 다룹니다.
WebRTC 파일 전송은 얼마나 빠른가요?
정해진 속도는 없습니다. 상한은 경로에서 가장 느린 구간이며, 보통은 보내는 사람의 업로드 속도입니다. 대략적으로 1GB는 50Mbit/s에서 약 2.7분, 100Mbit/s에서 약 80초, 빠른 로컬 네트워크에서는 1분도 한참 안 걸립니다. 실제 전송은 프로토콜 오버헤드, 디스크 속도, 그리고 중계를 쓸 경우 추가 경유 때문에 이 숫자보다 조금 느립니다. 링크 하나를 여러 사람이 열 수 있으며, 각자 보내는 사람에게서 직접 내려받습니다. 동시에 여러 다운로드가 진행되면 보내는 사람의 업로드를 나눠 씁니다.
요약
WebRTC 파일 전송은 짧은 협상 뒤에 이어지는 길고 암호화된 데이터 흐름입니다. 시그널링이 브라우저를 소개하고, STUN과 ICE가 NAT를 통과하는 경로를 찾으며, TURN은 최후의 수단으로 중계하고, DTLS로 암호화된 데이터 채널이 파일을 디스크에서 디스크로 옮깁니다. 보내는 사람으로서 이것이 무엇을 의미하는지 실용적인 면은 브라우저에서 하는 P2P 파일 전송과 StrongFolder 작동 방식부터 읽어 보세요.