Signaling Server: 정의, 작동 방식 및 사용처

Signaling Server란

Signaling Server — 두 개 이상의 피어 간 WebRTC 연결 설정 프로세스를 조정하는 네트워크 서비스입니다. 오디오, 비디오, DataChannel 데이터와 같은 미디어 데이터는 전송하지 않으며, 피어 발견 및 연결 매개변수 협상에 필요한 제어 정보만 전송합니다. P2P 채널이 성공적으로 설정된 후에는 Signaling Server가 더 이상 필요하지 않을 수 있지만, 일부 아키텍처에서는 후속 신호 교환(예: 통화 종료, 참가자 추가)을 위해 유지됩니다.

시그널링 아키텍처는 세 가지 구성 요소로 구성됩니다: Signaling Server, Signal Channel(클라이언트와 서버 간 전송 프로토콜), 클라이언트 API(일반적으로 브라우저의 WebRTC 스택에 내장). WebRTC 사양(W3C, 2024)은 의도적으로 시그널링 프로토콜을 표준화하지 않으며, 개발자는 애플리케이션에 적합한 전송 방식을 선택할 수 있습니다. 이 유연한 접근 방식을 통해 웹 애플리케이션에는 WebSocket, 채팅 시스템에는 XMPP, 통신 인프라와의 통합에는 SIP를 사용할 수 있습니다.

시그널링 프로세스: 개요

WebRTC 연결을 설정하기 전에 피어는 세션 설명(offer 및 answer), ICE 후보, 세션 종료/수정 정보 등 세 가지 유형의 메시지를 교환해야 합니다. Signaling Server는 방 또는 사용자 식별자를 사용하여 피어 간에 이러한 메시지를 라우팅합니다. 표준 패턴은 두 명의 참가자가 연결되는 “방”을 만들고, 서버가 각 참가자의 메시지를 상대방에게만 중계하는 것입니다.

WebRTC에서 시그널링 작동 방식

Signaling Server는 다음과 같은 일반적인 WebRTC 연결 설정 프로토콜을 구현합니다. 피어는 WebSocket(또는 다른 전송 방식)을 통해 서버에 연결하고 방에 등록합니다. 피어 A(시작자)는 RTCPeerConnection.createOffer()를 통해 offer(발신 미디어 스트림의 SDP 설명)를 생성하고, 이를 로컬 설명으로 설정한 후 Signaling Server로 보냅니다. 서버는 offer를 피어 B로 중계합니다. 피어 B는 offer를 수신하여 원격 설명으로 설정하고, createAnswer()를 통해 answer를 생성한 후 로컬 설명으로 설정하고 서버를 통해 다시 보냅니다. 이 프로세스를 SDP Offer/Answer라고 합니다.

SDP 교환과 병렬로, 각 피어는 ICE 후보(host, srflx, relay)를 수집하여 Signaling Server를 통해 다른 피어로 보냅니다. 원격 피어는 수신된 후보를 RTCPeerConnection.addIceCandidate()를 통해 추가합니다. ICE 프로세스는 작동 경로를 찾기 위해 모든 후보 조합을 테스트합니다. 작동 경로가 발견되면(보통 1~5초 이내), 미디어 트래픽이 피어 간에 직접 흐르기 시작하고 Signaling Server는 더 이상 데이터 전송에 참여하지 않습니다. 다음 제어 이벤트(통화 종료, 스트림 품질 변경)까지 역할이 종료됩니다.

방 메커니즘 및 등록

메시지 주소 지정을 위해 Signaling Server는 방 또는 채널 메커니즘을 사용합니다. 각 새 WebRTC 세션은 고유 식별자(일반적으로 UUID)를 가진 방을 생성합니다. 시작자가 방을 만들고 두 번째 피어의 연결을 기다립니다. 두 번째 피어는 외부 채널(예: 초대 링크)을 통해 받은 ID를 사용하여 방에 참여합니다. 서버는 각 ID가 연결된 클라이언트 목록에 해당하는 방 맵을 유지합니다. 참가자 수가 2명에 도달하면 서버는 피어 간 시그널링 메시지 중계를 시작합니다.

WebRTC 시그널링 프로토콜

Signaling Server는 각각 장단점이 있는 다양한 전송 프로토콜을 사용할 수 있습니다. 프로토콜 선택은 애플리케이션 유형, 인프라 제약 조건 및 호환성 요구 사항에 따라 달라집니다. 다음은 가장 일반적인 프로토콜과 그 특징입니다.

WebSocket은 웹 애플리케이션에서 Signaling Server에 가장 많이 사용되는 프로토콜입니다. SDP 및 ICE 후보의 비동기 교환에 중요한 전이중 통신을 제공하며, WebSocket API를 통해 모든 최신 브라우저에서 기본적으로 지원됩니다. 서버 측 WebSocket 구현은 모든 인기 플랫폼(Node.js, Python, Java, Go)에서 사용 가능합니다. 수백만 사용자를 대상으로 하는 애플리케이션의 경우 Redis Pub/Sub 또는 Kafka 기반의 확장 가능한 WebSocket 솔루션을 사용하여 Signaling Server 인스턴스 간 동기화를 수행합니다.

Signaling Server 구현 예제

ws 라이브러리(WebSocket)와 내장 HTTP 서버를 사용하여 Node.js로 간단한 Signaling Server 구현을 살펴보겠습니다. 서버는 사용자 등록, 방 생성 및 참가자 간 메시지 중계를 지원합니다.

const WebSocket = require("ws");
const server = new WebSocket.Server({ port: 8080 });
const rooms = new Map();

server.on("connection", (ws) => {
    ws.roomId = null;

    ws.on("message", (data) => {
        const msg = JSON.parse(data);

        switch (msg.type) {
            case "join":
                handleJoin(ws, msg.roomId);
                break;
            case "offer":
            case "answer":
            case "ice-candidate":
                relayToPeer(ws, msg);
                break;
            case "leave":
                handleLeave(ws);
                break;
        }
    });

    ws.on("close", () => handleLeave(ws));
});

function handleJoin(ws, roomId) {
    if (!rooms.has(roomId)) {
        rooms.set(roomId, []);
    }

    const room = rooms.get(roomId);
    room.push(ws);
    ws.roomId = roomId;

    if (room.length === 2) {
        room[0].send(JSON.stringify({ type: "peer-joined" }));
        room[1].send(JSON.stringify({ type: "peer-joined" }));
    }
}

function relayToPeer(sender, msg) {
    const room = rooms.get(sender.roomId);
    if (!room) return;

    room.forEach(peer => {
        if (peer !== sender && peer.readyState === WebSocket.OPEN) {
            peer.send(JSON.stringify(msg));
        }
    });
}

function handleLeave(ws) {
    if (!ws.roomId) return;
    const room = rooms.get(ws.roomId);
    if (!room) return;

    const idx = room.indexOf(ws);
    if (idx !== -1) room.splice(idx, 1);
    if (room.length === 0) rooms.delete(ws.roomId);
}

이 Signaling Server는 기본 기능을 구현합니다: 방 연결, 두 피어 간 WebRTC 메시지(offer, answer, ice-candidate) 중계, 연결 끊김 관리. 서버는 연결된 WebSocket 클라이언트가 있는 방을 저장하기 위해 Map을 사용합니다. relayToPeer 함수는 발신자를 제외한 방의 모든 참가자에게 메시지를 보냅니다. 프로덕션 환경에서는 메시지 유형 검증, JSON 파싱 오류 처리 및 끊어진 연결 감지를 위한 heartbeat 메커니즘을 추가해야 합니다.

Signaling Server와 클라이언트 통합

클라이언트 측에서 Signaling Server는 브라우저의 WebSocket API를 통해 통합됩니다. 클라이언트는 서버에 연결하고, 방 참여 요청을 보낸 다음, 수신된 WebRTC 메시지를 setRemoteDescription() 및 addIceCandidate()를 통해 RTCPeerConnection에 전달하여 처리합니다. 클라이언트 코드는 onicecandidate 이벤트와 offer/answer 생성 후 RTCPeerConnection에서 얻은 자체 SDP 및 ICE 후보도 서버로 보냅니다.

시그널링에서 SDP와 ICE의 역할

Signaling Server는 SDP(Session Description Protocol)와 ICE 후보라는 두 가지 주요 메타데이터 유형을 전송합니다. SDP는 미디어 스트림 매개변수(코덱, 샘플링 속도, 채널 수, 전송 방향(sendrecv, sendonly, recvonly, inactive))를 설명합니다. ICE 후보에는 피어가 연결에 도달할 수 있는 네트워크 주소(로컬, STUN에서 획득, TURN에서 릴레이)가 포함됩니다.

SDP는 세션 및 미디어 섹션을 포함하는 텍스트 형식으로 제공됩니다. 세션 부분은 일반 매개변수(세션 ID, 버전, 이름)를 설명하고, 미디어 섹션은 각 미디어 스트림(오디오, 비디오, DataChannel)을 코덱, 포트 및 프로토콜과 함께 설명합니다. ICE 후보에는 foundation(그룹화 식별자), 우선 순위, IP 주소, 포트, 유형(host, srflx, relay) 및 프로토콜(UDP, TCP)이 포함됩니다. 각 후보에는 특정 ICE 프로세스에 연결하는 ufrag(사용자 이름 조각) 속성도 포함됩니다.

• SDP Offer — 시작자가 미디어 기능에 대한 설명을 생성하고 Signaling Server를 통해 원격 피어로 보냅니다.
• SDP Answer — 원격 피어가 자체 설명으로 응답하여 미디어 형식 및 코덱을 확인하거나 조정합니다.
• ICE Candidate — 각 피어는 ICE 프레임워크에 의해 발견되는 대로 네트워크 후보를 시그널링 서버로 보냅니다.
• Trickle ICE — 수집 완료 후 한 번에 모두 보내는 대신 발견되는 대로 하나씩 후보를 보내는 최신 최적화입니다.
• 재협상 — 미디어 매개변수가 변경될 때(비디오 활성화/비활성화, 참가자 추가), 피어는 Signaling Server를 통해 새 SDP 교환을 시작합니다.

Trickle ICE는 WebRTC 연결 설정을 크게 가속화합니다. 복잡한 네트워크에서 2~10초가 걸릴 수 있는 모든 ICE 후보의 완전한 수집을 기다리는 대신, 각 후보는 발견 직후 Signaling Server로 전송됩니다. 원격 피어는 후보를 수신하고 ICE 프레임워크를 통해 즉시 연결 테스트를 시작합니다. 이를 통해 대부분의 경우 연결 설정 시간이 500~1500ms로 단축됩니다.