WebRTC: 정의, 아키텍처 및 작동 원리

WebRTC란

WebRTC(Web Real-Time Communication)는 2011년 Google이 시작한 오픈 소스 프로젝트로 W3C(JavaScript API)와 IETF(프로토콜)에 의해 표준화되었습니다. 주요 목표는 플러그인이나 타사 소프트웨어를 설치하지 않고 브라우저와 애플리케이션 간에 저지연 통신을 제공하는 것입니다.

비디오가 서버를 통과하는 기존 솔루션(RTMP, HLS)과 달리 WebRTC는 피어투피어 아키텍처를 사용합니다: 데이터가 참가자 간에 직접 전송됩니다. 이는 HLS의 3-10초에 비해 200-500ms의 지연 시간을 제공합니다 — 음성 및 영상 통화, 게임 스트리밍, 원격 수술에 중요한 차이입니다.

Google WebRTC 팀(2025)에 따르면 이 기술은 총 50억 이상의 설치 수를 가진 애플리케이션에서 사용됩니다: Google Meet, WhatsApp, Discord, Telegram, Zoom(부분적으로). 원격 의료 및 에듀테크 분야의 벤처 스타트업 중 85% 이상이 WebRTC를 기본 실시간 전송 방식으로 선택합니다.

모바일 개발은 2013년 libjingle_peerconnection 릴리스와 함께 완전한 WebRTC 지원을 받았습니다 — Android 및 iOS용 네이티브 구현입니다. 현재 두 플랫폼 모두 H.264 및 VP8의 하드웨어 인코딩, 카메라, 마이크 및 장치 스피커를 지원하는 안정적인 SDK를 보유하고 있습니다.

WebRTC 아키텍처 및 프로토콜

WebRTC 아키텍처는 세 가지 계층으로 구성됩니다. 최상위 계층은 JavaScript API(또는 모바일 플랫폼용 네이티브 API), 중간 계층은 전송 프로토콜, 하위 계층은 코덱 및 보안입니다. 각 계층은 고유한 작업을 해결하지만 연결 설정을 위해서는 모두 필요합니다.

주요 WebRTC API

MediaStream(getUserMedia) — 장치의 마이크와 카메라에서 오디오 및 비디오를 캡처합니다. RTCPeerConnection — P2P 연결을 관리합니다: 인코딩, 전송, 비트레이트 적응. RTCDataChannel — 동일한 채널을 통해 임의의 데이터(텍스트, 파일, 이진 메시지)를 전송합니다.

// WebRTC JavaScript API (브라우저 예제)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

실시간 프로토콜

WebRTC는 오디오 및 비디오에 SRTP(Secure Real-Time Transport Protocol)를 사용합니다 — AES-128 암호화를 갖춘 RTP의 보안 버전입니다. 세션 관리는 DTLS 위에서 SCTP(Stream Control Transmission Protocol)를 통해 이루어집니다. 각 데이터 스트림은 필수적으로 암호화됩니다: WebRTC에는 비보안 모드가 없습니다.

• SRTP/SRTCP — 재생 공격 방지 기능이 있는 미디어 스트림의 암호화된 전송
• DTLS-SRTP — UDP를 통한 Datagram TLS로 암호화 키 설정
• SCTP — DataChannel을 위한 안정적 또는 부분적으로 안정적인 데이터 전달
• ICE(Interactive Connectivity Establishment) — 피어 간 네트워크 경로를 찾기 위한 프레임워크
• Trickle ICE — 후보가 발견될 때마다 전송되는 ICE의 증분 버전으로 연결 설정을 가속화

NAT 트래버설: ICE, STUN 및 TURN

WebRTC의 주요 기술적 과제는 NAT(Network Address Translation) 뒤에 있는 장치 간에 P2P 연결을 설정하는 것입니다. 특별한 메커니즘이 없으면 장치의 로컬 IP 주소가 인터넷에서 보이지 않기 때문에 서로 직접 연결할 수 없습니다.

STUN — 공용 주소 확인

STUN(Session Traversal Utilities for NAT) — “그들의 공용 IP와 포트는 무엇입니까?”라는 질문에 답변하는 서버입니다. 클라이언트가 STUN 서버에 요청을 보내면 서버는 해당 공용 주소를 확인하고 클라이언트에 반환합니다. Google은 STUN 서버 stun:stun.l.google.com:19302를 공개적으로 유지 관리합니다.

// iOS의 WebRTC — ICE 서버 구성
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — 릴레이 연결

TURN(Traversal Using Relays around NAT) — STUN이 도움이 되지 않는 경우(대칭 NAT 또는 기업 방화벽)를 위한 릴레이 서버입니다. 이 모드에서는 모든 데이터가 TURN 서버를 통과합니다 — 속도가 느려지고 지연 시간이 증가하지만 99%의 경우 연결을 보장합니다.

TURN은 모든 미디어 트래픽을 자체적으로 통과시키기 때문에 WebRTC 인프라에서 가장 비용이 많이 드는 구성 요소입니다. Coturn Project(2025)에 따르면 8 vCPU와 16GB RAM을 갖춘 일반적인 TURN 서버는 약 200개의 동시 오디오 통화 또는 40개의 HD 비디오 통화를 처리합니다.

ICE 프로세스

ICE는 가능한 모든 후보(로컬 IP, STUN을 통한 공용 IP, TURN을 통한 릴레이)를 수집하고 우선순위 순서로 연결을 시도합니다. 적어도 하나의 후보 쌍(로컬-원격)이 연결성 검사를 통과하면 연결이 설정된 것으로 간주됩니다.

• Host candidates — 서브넷의 장치 로컬 IP 주소(가장 빠르지만 NAT 뒤에서는 작동하지 않음)
• Server Reflexive candidates — STUN 서버를 통해 얻은 공용 IP
• Relay candidates — 릴레이가 이루어지는 TURN 서버 주소(가장 느리지만 가장 안정적)

모바일 앱의 WebRTC

모바일 개발을 위해 Google은 libWebRTC를 유지 관리합니다 — Android(AAR) 및 iOS(XCFramework)용 네이티브 라이브러리입니다. 이 라이브러리에는 전체 프로토콜 스택, 코덱(VP8, VP9, H.264, AV1) 및 인코딩/디코딩을 위한 하드웨어 가속이 포함되어 있습니다.

Android의 WebRTC

Android SDK는 PeerConnectionFactory, PeerConnection, MediaStream 클래스를 제공합니다. 앱은 팩토리를 생성하고, 비디오 코덱을 구성하고, VideoCapturer를 통해 카메라 스트림을 캡처하고, SDP offer/answer를 통해 피어 연결을 설정합니다.

// Android WebRTC — 초기화
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

iOS의 WebRTC

iOS SDK는 RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack 래퍼와 함께 Objective-C API를 사용합니다. 하드웨어 H.264 인코딩은 VideoToolbox를 통해 사용할 수 있습니다. 비디오 표시에는 RTCMTLVideoView(Metal) 또는 RTCVideoRenderer가 사용됩니다.

// iOS WebRTC — 카메라에서 비디오 캡처
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// 카메라 선택(전면/후면)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// 최대 FPS로 캡처 시작
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

프로덕션 영상 통화의 경우 모바일 앱은 일반적으로 libWebRTC 위에 SDK 래퍼를 사용합니다: Twilio Video, Agora, Daily.co. 이 SDK는 시그널링, 룸 관리를 단순화하고 참가자 비디오 그리드를 표시하기 위한 기성 UI 구성 요소를 제공합니다.

시그널링 및 연결 설정

WebRTC는 시그널링 프로토콜을 지정하지 않습니다 — 피어 간 SDP(Session Description Protocol) 메시지 교환입니다. 개발자는 시그널링을 위한 전송 방식을 선택합니다: WebSocket, MQTT, SIP, XMPP 또는 REST API. 시그널링은 한 피어에서 다른 피어로 offer, answer 및 ICE 후보를 전달합니다.

SDP Offer/Answer 교환

프로세스는 offer 생성(초기자가 미디어 기능을 설명)으로 시작하여 시그널링을 통해 두 번째 피어에 전송되며, answer로 응답합니다. SDP 교환 후 각 피어는 ICE를 시작하고 스트림 암호화를 위해 DTLS-SRTP를 실행합니다.

// Android — offer 생성 및 전송
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // 시그널링 서버에 sdp.description 전송
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

시그널링 프로토콜

모바일 앱에서 가장 널리 사용되는 시그널링은 WebSocket을 통한 것입니다 — TCP를 통한 양방향 채널로 서버와 지속적인 연결을 유지합니다. 시그널링 서버는 종종 룸 참가자 간에 메시지를 라우팅하는 별도의 마이크로서비스(Node.js, Golang, Elixir)입니다.

• WebSocket — 지속적인 양방향 연결, 최소 오버헤드, 시그널링의 표준 선택
• WebSocket을 통한 SIP — 표준 VoIP 프로토콜, 기존 전화 인프라와 통합
• MQTT — IoT 및 약한 네트워크를 위한 경량 pub/sub 프로토콜이지만 지연 시간이 더 높음
• Matrix / XMPP — 개인 정보 보호 중심 애플리케이션을 위한 분산 프로토콜

ICE 및 DTLS-SRTP가 완료된 후 시그널링은 더 이상 데이터 전송에 참여하지 않습니다 — 모든 미디어 트래픽이 직접 P2P(또는 TURN 릴레이를 통해)로 흐릅니다. 시그널링 서버는 활성 통화를 중단하지 않고 종료할 수 있습니다. 이것이 WebRTC 분산 아키텍처의 주요 이점입니다.