# WebRTC 파일 전송의 작동 원리

Source: https://help.strongfolder.com/ko/guides/how-webrtc-file-transfer-works/
Updated: 2026-11-05

> WebRTC 파일 전송은 세 단계로 작동합니다. 시그널링 서버가 두 브라우저를 소개하고, STUN과 ICE가 가정용 공유기(NAT)를 통과하는 네트워크 경로를 찾으며, 직접 경로가 없으면 TURN 중계로 대체합니다. 그다음 브라우저가 DTLS로 암호화된 데이터 채널을 열고, 파일을 저장하지 않은 채 직접 또는 중계를 거쳐 조각 단위로 전송합니다.

WebRTC 파일 전송을 쓰면 두 브라우저가 클라우드 저장소에 업로드하지 않고 서로 파일을 보낼 수 있습니다.
간단해 보이지만, 인터넷은 원래 가정용 컴퓨터 두 대가 서로 직접 연결하도록 만들어지지 않았습니다. 이
가이드는 StrongFolder를 예로 들어 실제로 무슨 일이 일어나는지, 즉 시그널링, NAT, STUN, ICE, TURN, DTLS,
데이터 채널을 쉬운 말로 설명합니다.

**Key facts**

- **WebRTC**는 두 기기 사이의 직접적이고 암호화된 연결을 위한 브라우저 표준이며, 파일 도구는 그 **데이터 채널**을 씁니다.
- **시그널링**이 브라우저를 소개하고, **STUN**과 **ICE**가 공유기(**NAT**)를 통과하는 경로를 찾으며, 직접 경로가 없으면 **TURN 중계**가 트래픽을 전달합니다.
- **암호화:** 모든 데이터 채널은 **DTLS**를 씁니다. WebRTC에는 암호화하지 않는 모드가 없습니다.
- StrongFolder는 WebRTC 위에 PeerJS를 쓰며, StrongFolder 시그널링 서버, 공개 STUN 서버(Google 포함), 자체 TURN 중계 서버를 사용합니다. 파일은 StrongFolder 서버에 업로드되거나 저장되지 않습니다.
- 파일은 보내는 사람의 디스크에서 받는 사람의 디스크로 조각 단위로 전송되며, 보내는 사람은 온라인을 유지합니다.

## WebRTC란 무엇인가요?

[WebRTC](https://help.strongfolder.com/en/glossary/#webrtc)(Web Real-Time Communication)는 W3C와 IETF가 표준화한, 브라우저 간 실시간
연결을 위한 브라우저 API와 네트워크 프로토콜의 모음입니다. Chrome, Edge, Firefox, Safari, Opera 모두
지원합니다. 화상·음성 통화용으로 만들어졌지만, 어떤 바이너리 데이터든 실어 나르는 **데이터 채널**도 있습니다.
파일이 바로 그런 데이터입니다.

핵심 특성은 이렇습니다. WebRTC 연결이 한번 설정되면 데이터는 서버의 저장소로 가지 않고 **두 끝점 사이를**
오갑니다. 이것이 [브라우저에서 하는 P2P 파일 전송](https://help.strongfolder.com/en/guides/p2p-file-transfer/)을 가능하게 합니다.

## 두 브라우저는 왜 그냥 서로 연결할 수 없나요?

자기만의 공인 주소를 가진 기기가 거의 없기 때문입니다. 노트북은 가정용 공유기, 사무실 방화벽, 또는
이동통신사 네트워크 뒤에 있습니다. 공유기는 [NAT](https://help.strongfolder.com/en/glossary/#nat)(Network Address Translation)를 수행합니다.
여러 사설 기기가 하나의 공인 IP 주소를 나눠 쓰며, 공유기는 안에서 보낸 무언가에 대한 응답 트래픽만
들여보냅니다.

그래서 두 브라우저는 파일 데이터가 흐르기 전에 세 가지 문제에 부딪힙니다.

1. **서로에게 닿는 방법**을 모릅니다. 상대가 있다는 것조차 모릅니다.
2. **자신의 공인 주소**를 모릅니다. 192.168.1.20 같은 사설 주소만 압니다.
3. 공유기가 **요청하지 않은 수신 트래픽을 막을** 수 있습니다.

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단계 — 시그널링.** 보내는 사람이 파일을 고르면 서비스가 링크에 필요한 메타데이터를 기록합니다. 받는
사람이 링크를 열면 두 브라우저가 [시그널링](https://help.strongfolder.com/en/glossary/#signaling) 서버에 연결됩니다. WebRTC는 시그널링 방식을
정의하지 않으며, StrongFolder는 자체 시그널링 서버와 함께 PeerJS를 씁니다.

**3단계 — 제안과 응답.** 한 브라우저가 SDP(Session Description Protocol)로 **제안(offer)**을 만듭니다.
"데이터 채널을 원합니다. 제 암호화 지문과 기능은 이렇습니다." 다른 브라우저가 **응답(answer)**으로 답합니다.
둘 다 시그널링 서버를 거칩니다.

**4단계 — STUN.** 각 브라우저는 [STUN](https://help.strongfolder.com/en/glossary/#stun) 서버에 "내가 어떤 주소와 포트에서 오는 것으로
보이나요?"라고 묻습니다. 답은 공유기가 매핑한 공인 주소입니다. STUN 서버는 아주 작은 요청만 처리하며 파일
데이터는 다루지 않습니다. StrongFolder는 Google을 포함한 공개 STUN 서버와 자체 서버를 씁니다.

**5단계 — ICE 후보.** 각 브라우저는 자신에게 닿을 수 있는 방법인 **후보(candidate)**를 모읍니다. 로컬 네트워크
주소(host), STUN에서 얻은 공인 주소(server-reflexive), TURN 중계 서버의 주소(relayed)입니다. 그리고 시그널링을
통해 후보를 교환합니다.

**6단계 — 연결 확인.** [ICE](https://help.strongfolder.com/en/glossary/#ice)(Interactive Connectivity Establishment)는 후보 쌍을 시험해
작동하는 것 중 가장 좋은 경로를 고릅니다. 두 기기가 같은 Wi-Fi에 있으면 로컬 경로가 선택됩니다. 공유기가
허용하면 직접 인터넷 경로("홀 펀칭")가 선택됩니다. 직접 경로가 하나도 안 되면 중계 경로를 씁니다.

**7단계 — DTLS.** 데이터가 흐르기 전에 브라우저는 [DTLS](https://help.strongfolder.com/en/glossary/#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 |

모든 용어는 [용어집](https://help.strongfolder.com/en/glossary/)에 간단히 설명되어 있습니다.

## TURN 중계는 언제 쓰이고, 무엇을 보나요?

중계는 기본이 아니라 대체 수단입니다. ICE는 직접 후보 쌍이 하나도 연결되지 않을 때만 중계를 씁니다. 대표적으로
**대칭형 NAT**(일부 이동통신사)를 쓰는 네트워크, 외부로 나가는 UDP를 막는 **회사 방화벽**, 또는 일부 VPN입니다.

직접 연결이 불가능한 경우(엄격한 회사 방화벽, 일부 모바일 네트워크) 암호화된 데이터는 StrongFolder 중계(TURN) 서버를 거칩니다. 중계 서버는 데이터를 전달만 하고 저장하지 않습니다.

중계 서버는 DTLS로 암호화된 패킷을 받아 넘겨줍니다. 트래픽이 흐른다는 것, 얼마나 언제 흐르는지는 볼 수
있지만 안에 무엇이 들었는지는 볼 수 없습니다. 모든 바이트가 중계 서버를 한 번 더 거치므로 중계 전송은 직접
전송보다 느릴 수 있습니다. 전송이 유난히 느리다면 다른 네트워크를 써 보세요. 사무실 네트워크에서는 안 되던
직접 연결이 휴대폰 핫스팟이나 집 Wi-Fi에서는 되는 경우가 많습니다.

[지금 파일 보내기](https://strongfolder.com)
## WebRTC 암호화는 얼마나 안전한가요?

WebRTC는 암호화를 필수로 합니다. 암호화되지 않은 데이터 채널을 열 방법이 없습니다. DTLS는 두 브라우저가
협상한 최신 암호 방식을 쓰며, 연결마다 새 키가 만들어집니다.

모든 WebRTC 서비스에 해당하는 솔직한 단서가 하나 있습니다. 두 브라우저는 시그널링 서버를 통해 교환된 인증서
**지문**으로 서로를 확인합니다. 따라서 서비스의 시그널링이 지문을 조작하지 않는다고 믿어야 합니다. 그래서
StrongFolder는 자신의 보호를 직접 보유한 키를 쓰는 종단 간 암호화나 "제로 지식"이 아니라 **전송 중 암호화**라고
설명합니다. "안전하다"의 더 넓은 의미는 [안전한 파일 공유](https://help.strongfolder.com/en/guides/secure-file-sharing/)와
[보안 및 개인정보](https://help.strongfolder.com/en/security/)를 읽어 보세요.

## 보내는 사람의 브라우저는 왜 열려 있어야 하나요?

보내는 사람의 브라우저가 *곧* 원본이기 때문입니다. 대신 쓸 서버 사본이 없습니다. 데이터 채널은 탭이 열려
있고 기기가 깨어 있는 동안에만 보내는 사람의 디스크에서 조각을 읽습니다. 받는 사람이 다운로드를 마칠 때까지 보내는 사람의 브라우저 탭은 열린 채 온라인 상태여야 합니다. 파일은 서버가 아니라 보내는 사람의 기기에서 전송되기 때문입니다. 이에 대비하는
방법은 [보내는 사람이 온라인을 유지해야 하는 이유](https://help.strongfolder.com/en/guides/why-sender-stays-online/)에서 다룹니다.

## WebRTC 파일 전송은 얼마나 빠른가요?

정해진 속도는 없습니다. 상한은 경로에서 가장 느린 구간이며, 보통은 보내는 사람의 **업로드** 속도입니다.
대략적으로 1GB는 50Mbit/s에서 약 2.7분, 100Mbit/s에서 약 80초, 빠른 로컬 네트워크에서는 1분도 한참 안
걸립니다. 실제 전송은 프로토콜 오버헤드, 디스크 속도, 그리고 중계를 쓸 경우 추가 경유 때문에 이 숫자보다
조금 느립니다. 링크 하나를 여러 사람이 열 수 있으며, 각자 보내는 사람에게서 직접 내려받습니다. 동시에 여러 다운로드가 진행되면 보내는 사람의 업로드를 나눠 씁니다.

## 요약

WebRTC 파일 전송은 짧은 협상 뒤에 이어지는 길고 암호화된 데이터 흐름입니다. 시그널링이 브라우저를 소개하고,
STUN과 ICE가 NAT를 통과하는 경로를 찾으며, TURN은 최후의 수단으로 중계하고, DTLS로 암호화된 데이터 채널이
파일을 디스크에서 디스크로 옮깁니다. 보내는 사람으로서 이것이 무엇을 의미하는지 실용적인 면은
[브라우저에서 하는 P2P 파일 전송](https://help.strongfolder.com/en/guides/p2p-file-transfer/)과 [StrongFolder 작동 방식](https://help.strongfolder.com/en/how-it-works/)부터
읽어 보세요.

## FAQ

### WebRTC 데이터 채널이란 무엇인가요?

데이터 채널은 음성이나 영상 대신 임의의 바이트를 두 브라우저 사이에서 실어 나르는 WebRTC의 구성 요소입니다. UDP 위의 DTLS 위에서 SCTP로 작동하므로 암호화되며, 파일 전송에 필요한 신뢰성 있고 순서가 보장되는 전달로 설정할 수 있습니다.

### STUN과 TURN은 무엇이 다른가요?

STUN 서버는 브라우저에 자신의 공인 주소가 어떻게 보이는지만 알려 주어, 두 브라우저가 직접 연결을 시도할 수 있게 합니다. 파일 데이터는 거치지 않습니다. TURN 서버는 중계 서버로, 직접 경로가 작동하지 않으면 암호화된 데이터가 이를 거칩니다. StrongFolder는 자체 TURN 중계 서버를 운영하며, 이 서버는 데이터를 전달만 하고 저장하지 않습니다.

### 시그널링 서버가 제 파일을 보나요?

아니요. 시그널링 서버는 브라우저 사이에서 세션 설명과 네트워크 후보 같은 연결 메시지만 전달합니다. 파일 데이터는 데이터 채널로 직접 또는 TURN 중계를 거쳐 흐릅니다.

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

WebRTC는 모든 데이터 채널을 DTLS로 암호화하므로, 모든 연결에서 파일 데이터는 전송 중에 암호화됩니다. WebRTC는 암호화되지 않은 데이터 채널을 허용하지 않습니다. 키는 두 브라우저가 협상하고 그 지문은 시그널링을 통해 전달되므로, 이는 직접 관리하는 키를 쓰는 종단 간 암호화가 아니라 전송 중 암호화입니다.

### WebRTC 전송이 가끔 실패하거나 느린 이유는 무엇인가요?

대개 네트워크 경로 때문입니다. 엄격한 방화벽이나 VPN이 직접 UDP를 막으면 연결이 TCP를 통한 TURN 중계로 대체되거나 아예 연결되지 않습니다. 다른 네트워크(예: 휴대폰 핫스팟)를 쓰거나, VPN을 끄거나, IT 부서에 WebRTC 허용을 요청하세요.

### TURN 중계 서버가 제 파일을 읽을 수 있나요?

중계 서버는 두 브라우저 사이에서 DTLS로 암호화된 패킷을 전달합니다. 보이는 것은 암호화된 트래픽, 크기, 시간이며 파일 내용은 보이지 않습니다. StrongFolder의 중계 서버는 전달하는 데이터를 저장하지 않습니다.