WebRTC 란??

🌐 Aurora: 회사원을 위한 채팅 플랫폼, 그리고 WebRTC

회사원을 위한 채팅 플랫폼 Aurora의 기획이 본격적으로 시작되었다.

나는 프론트엔드 개발자로서 메인 기능인 영상 통화를 담당하게 되었고, 이를 위해 WebRTC라는 기술을 먼저 깊이 이해하고자 한다.

이번 글은 WebRTC에 대한 개념 정리와, 실무에서 어떻게 활용되는지 파악한 내용을 중심으로 정리한 글이다. 개발을 본격적으로 시작하기 전, 기초를 탄탄히 다지는 과정으로 작성했다.

---

🧩 WebRTC란?

Web Real-Time Communication

브라우저나 앱 간에 플러그인 없이 실시간 오디오, 비디오, 데이터를 주고받을 수 있는 기술

WebRTC는 다음과 같은 특징을 갖는다:

• 플러그인이나 외부 앱 없이도 브라우저 간 P2P 통신이 가능
• 낮은 지연 시간, 빠른 연결
• 실시간 음성/영상 통화, 파일 전송, 라이브 스트리밍 등에 사용됨
• 크롬, 파이어폭스, 사파리 등 주요 브라우저 지원

---

🔧 구성 요소

WebRTC는 크게 3가지 핵심 API로 구성된다:

---

🔄 연결 흐름 요약

WebRTC 자체는 브라우저 간의 연결만 담당하며, 그 연결을 성립시키기 위한 **초기 통신(Signaling)**은 개발자가 직접 구현해야 한다.

전체 흐름:

plain
text
복사편집
1. getUserMedia() — 사용자의 미디어 스트림 획득
2. Peer A → offer 생성 → Signaling 서버로 전달
3. Peer B → answer 생성 → Signaling 서버로 전달
4. ICE candidate 교환 → 양방향 연결 성립

• SDP(Session Description Protocol): 오디오/비디오 설정 정보를 담은 문자열
• ICE(Interactive Connectivity Establishment): 네트워크 연결 후보를 서로 교환
• STUN/TURN 서버: NAT 환경에서도 P2P 연결을 가능하게 해주는 중계 서버

---

🏗️ Signaling은 어떻게 구현하나?

WebRTC는 Signaling 방식을 강제하지 않기 때문에 보통 다음과 같은 기술을 사용해 직접 구성한다:

• WebSocket (Socket.IO): 양방향 실시간 메시징
• REST API: 간단한 Signaling 초기 구현에 사용 가능

내가 구현하게 될 Aurora에서는 Signaling 서버로 Socket.IO + Node.js 조합을 고려하고 있다.

---

🕸️ 연결 구조: Mesh vs SFU

✔ Mesh 구조

• 모든 사용자가 서로 직접 연결
• 구현이 간단하지만 참여자 수가 많을수록 성능 저하

✔ SFU 구조 (예: mediasoup, Jitsi)

• 중앙 서버가 각 사용자의 스트림을 중계

• 확장성과 성능 면에서 우수

  → 추후 Aurora에 적용 가능성 있음

---

✍️ 나의 학습 포인트

• RTCPeerConnection 내부 동작 구조 (setLocalDescription, setRemoteDescription 등)
• ICE Candidate의 동작 타이밍과 트릭링(Trickle ICE)
• 실제 환경에서의 네트워크 제약 (NAT, 방화벽, 모바일 등)
• 디버깅 툴: 크롬 → chrome://webrtc-internals

---

📌 정리

---

📅 앞으로의 계획

• 영상 통화 MVP 기능 구현 시작
• 시그널링 서버 프로토타입 개발
• 이후 SFU 구조 적용 여부 검토 (성능 고려)

---

🧠 마무리

WebRTC는 단순히 "실시간 통신 API"가 아니라, 브라우저 네트워크, 보안, 비디오 처리, 서버 아키텍처 등 여러 기술이 맞물린 복합 기술이라는 걸 이번 학습을 통해 느꼈다.

Aurora의 영상 통화 기능을 안정적으로 구현하기 위해, 이 기초 지식을 기반으로 실제 코드 구현에 착수할 예정이다. 앞으로 직접 시도하며 겪게 될 문제들과 해결 과정도 이어서 정리할 계획이다.