Agora Web SDK의 경계 — WebRTC 표준과 SD-RTN

"Agora는 자체 코덱을 써서 빠르다고 들었는데, 그럼 브라우저에서는 어떻게 동작하나요?". Agora 도입을 검토하는 자리에서 가장 자주 받는 질문 중 하나입니다. 답은 단순한 "예/아니오"가 아니라 레이어 분리 관점에서 풀어야 합니다 — 코덱 레이어와 네트워크 레이어를 따로 보면 네이티브와 Web의 차이가 자연스럽게 정리됩니다.

이 글은 브라우저 WebRTC의 제약과 Agora가 공개한 SD-RTN의 범위를 나눠 봅니다. 비공개 코덱·전송 프로토콜의 내부 동작은 추정하지 않습니다.

0. 확인 가능한 범위 — 브라우저 API와 Agora 서비스 네트워크

브라우저에서는 WebRTC가 노출하는 미디어·전송 API와 런타임 codec capability 안에서 동작한다. Agora Web SDK는 이 브라우저 연결을 Agora 서비스와 SD-RTN에 연결한다. 네이티브 SDK의 비공개 코덱·FEC·전송 구현은 공개 문서로 확인되는 범위만 기술해야 한다.

흔한 오해와 정정:

1. WebRTC 기본기 — 브라우저가 강제하는 표준

브라우저(Chrome/Firefox/Safari)에는 WebRTC라는 표준이 내장되어 있습니다. 별도 플러그인 없이 getUserMedia() / RTCPeerConnection API로 카메라·마이크 캡처와 실시간 전송이 가능합니다.

[브라우저]
   ↓
WebRTC 내장 (표준 API)
   ↓
코덱: VP8, VP9, H.264, AV1 (브라우저가 결정)
   ↓
네트워크: 공용 인터넷 P2P (또는 SFU/TURN 경유)

브라우저가 결정하는 것들

일반 WebRTC의 한계 3가지

🔴 1. 코덱 제약

• 자체 최적화 코덱을 브라우저에 주입 불가
• 브라우저 벤더가 지원하는 코덱만 사용 가능

🔴 2. 네트워크 경로

• 공용 인터넷 P2P → ISP 비즈니스 계약에 따라 경로 결정
• 애플리케이션이 인터넷의 AS 경로를 직접 고르지는 못하며 지연·손실은 경로 상태에 따라 변동

🔴 3. 패킷 손실 대응 속도

• NACK/RTX는 재전송 왕복 시간이 필요할 수 있음
• 실제 추가 지연은 RTT, playout buffer, 복구 정책에 따라 달라짐

이 세 가지가 Agora 같은 RTC 서비스가 풀어야 할 문제입니다.

2. 네이티브 SDK — 브라우저 밖에서 넓어지는 제어 범위

네이티브 환경(iOS/Android/PC)에서는 Agora SDK를 앱에 직접 포함하므로 브라우저 API보다 캡처·인코더·네트워크 적응을 넓게 제어할 수 있습니다. 다만 Agora가 공개하지 않은 codec pipeline과 패킷 복구 알고리즘을 특정 방식으로 단정하지 않습니다.

[카메라/마이크]
      ↓
 Agora SDK (앱에 내장된 네이티브 라이브러리)
      ↓
 미디어 인코딩·적응 처리
      ↓
 Agora 서비스와 SD-RTN
      ↓
 상대방 디코딩 → 화면 출력

패킷 손실 대응 — 공개 문서 범위에서 읽기

RTC 시스템은 NACK/RTX, FEC, concealment 같은 여러 기법을 조합할 수 있습니다. 아래 흐름은 일반 개념이며 Agora 내부 구현 설명이 아닙니다.

🔴 일반 WebRTC (NACK 기반)
패킷 손실 발생
  → 수신자가 NACK 전송
  → 송신자가 재전송 (RTX)
  → 도착까지 네트워크 왕복 시간의 영향을 받음
  → 그 사이 화면 멈춤 또는 freeze

FEC 또는 concealment를 사용하는 일반적 예
패킷 손실 발생
  → 미리 전송된 FEC 패리티 데이터로 즉시 복원
  → 복구 가능 범위에서는 재전송 없이 복원하거나 손실을 은폐
  → 실패하면 재전송·프레임 폐기·화질 저하가 발생할 수 있음

FEC(Forward Error Correction)란?

데이터를 보낼 때 복구용 여분 데이터(parity)를 미리 함께 보내는 채널 코딩 기술. 일부 패킷이 손실돼도 여분 데이터로 재전송 없이 즉시 복원 가능.

비유로 설명하면:

📦 택배 비유

책 10권을 보낼 때, 원본 10권 + 복구용 2권을 같이 보냄. 운송 중 2권 분실되어도 나머지 12권 중 10권으로 원본 재구성 가능 → 재배송 요청 불필요.

일반 전송:
[1][2][3][4][5][6][7][8][9][10] 전송
[1][2][_][4][5][6][7][8][9][10] 도착 (3번 손실)
→ 재전송 요청 → 대기 → 도착

FEC 전송:
[1][2][3][4][5][6][7][8][9][10][P1][P2] 전송 (P=parity)
[1][2][_][4][5][6][7][8][9][10][P1][_] 도착 (3번, P2 손실)
→ 사용한 FEC 코드가 허용하는 손실 범위라면 복원 가능

트레이드오프

FEC가 공짜는 아닙니다:

구체적인 FEC 코드와 비율 제어는 제품 구현에 달려 있습니다. Agora의 공개 제품 문서가 밝히지 않은 패킷 구조나 알고리즘은 여기서 가정하지 않습니다.

3. Web SDK — 절반은 표준, 절반은 Agora

여기가 핵심 문제 지점입니다.

RTCPeerConnection의 미디어 협상은 브라우저가 제공하는 코덱 capability 범위에서 이뤄집니다. 애플리케이션은 setCodecPreferences()로 순서를 조정할 수 있지만 임의의 코덱 구현을 이 경로에 직접 주입할 수는 없습니다. WebCodecs·WASM을 이용한 별도 미디어 처리 경로는 이 문장의 범위 밖입니다.

그래서 Agora Web SDK는 이렇게 설계되어 있습니다:

[브라우저]
    ↓
WebRTC API 사용 (어쩔 수 없이)
   - getUserMedia()
   - RTCPeerConnection
   - 코덱: 브라우저가 보고하고 SDP로 협상한 목록
    ↓
SDP/ICE → Agora 서비스에 연결
    ↓
Agora Edge → SD-RTN 경로
    ↓
서비스가 선택한 경로로 라우팅
    ↓
상대방 Edge → 상대방 브라우저

정리하면 — 레이어별 분업

Web SDK의 가치는 네트워크 하나로만 환원되지 않습니다. signaling, media service, 운영 도구, 분석, 확장 기능을 함께 평가해야 합니다.

4. SD-RTN — Software Defined Real-Time Network

SD-RTN은 Agora가 실시간 미디어 전송을 위해 운영하는 소프트웨어 정의 네트워크의 제품명입니다. 공개 페이지의 수치와 설명은 Agora의 제품 주장으로 범위를 표시합니다.

물리 회선과 서비스 네트워크를 구분한다

Agora의 공개 문서는 SD-RTN을 자체 해저케이블로 설명하지 않는다. 여러 데이터센터·통신 경로 위에 품질 측정과 라우팅 정책을 적용하는 서비스로 이해해야 한다.

패킷이 인터넷을 이동하는 기본 메커니즘

서울 PC → 라우터 A → 라우터 B → 라우터 C → 뉴욕 PC

각 라우터는 패킷을 받으면 라우팅 테이블을 보고 "다음 어디로 보낼지" 결정합니다. 이 테이블은 BGP(Border Gateway Protocol) 로 ISP들끼리 합의해 만듭니다.

BGP 경로 선택에는 사업자 정책뿐 아니라 local preference, AS path, MED 등 여러 속성이 관여한다. 애플리케이션이 이 경로를 직접 통제하지는 않는다.

일반 인터넷 경로 — 애플리케이션이 AS 경로를 직접 선택하지 않는다

서울유저 ─→ [ISP A] ─→ [ISP B] ─→ [ISP C] ─→ [ISP D] ─→ [ISP E] ─→ 뉴욕유저
              ↑각 ISP가 독립적으로 라우팅 결정
              ↑서울유저는 이 경로에 개입 불가
              ↑실제 AS hop과 품질은 경로·시점에 따라 달라짐

• 경로 결정 주체: 각 라우터의 BGP 테이블 (분산 결정)
• 경로 변경: 네트워크 운영자와 라우팅 프로토콜이 수행
• 품질 관측: 종단 애플리케이션도 RTT·loss·jitter를 측정할 수 있음

Agora SD-RTN — 인터넷 위에 서비스 경로를 더한다

서울유저 → [Agora 서울] → [Agora 도쿄] → [Agora LA] → 뉴욕유저
              ↑여기도 ISP 씀  ↑여기도 ISP 씀  ↑여기도 ISP 씀
              
각 구간의 실제 AS hop과 RTT는 접속망·피어링·시점에 따라 달라진다.

핵심은 두 가지:

① 가까운 진입점과 다중 경로 활용 사용자를 가까운 서비스 진입점에 연결하고 여러 후보 경로를 비교할 수 있습니다. hop 수 감소는 가능한 결과이지 보장값은 아닙니다.

② 각 구간의 다음 목적지를 Agora가 직접 선택

개념 예시:
  여러 서비스 경로의 품질을 측정
  → 정책에 따라 더 적합한 경로 선택

인터넷의 기반 라우팅은 계속 BGP에 의존하며, Agora는 그 위에서 서비스가 보유한 후보 경로를 선택합니다. 정확한 측정 주기와 전환 알고리즘은 공개되지 않았습니다.

차이를 정리하면

개념 모델

🚗 공용 인터넷 = 네비 없이 외운 길로 운전

서울 → 강남 → 판교 → 수원 → 부산
강남이 막혀도? → 네비가 없으니 그냥 강남 경유
왜? 그게 내가 아는 유일한 경로니까

🛰️ Agora SD-RTN = 실시간 네비 + 거점별 직원

서울 → 부산
Agora: "지금 경부고속도로 막힘 → 중부내륙으로 우회"
       "10분 후 경부 뚫림 → 다시 경부로"
→ 측정 결과와 정책에 따라 서비스 경로 선택
→ Agora 서버들이 고속도로 IC처럼 전국에 깔려 있어 환승 가능

📮 택배 비유

공개 자료로 확인되는 동작 범위

Agora는 공식 페이지에서 네트워크 상태를 모니터링하고 ML을 이용해 트래픽을 적합한 경로로 라우팅한다고 설명합니다. 노드별 측정값, 주기, 전환 임계값, 패킷 단위 동작은 공개 계약이 아니므로 예시 숫자를 실제 구현처럼 쓰지 않습니다.

Last Mile은 여전히 공용 인터넷

마지막 마일 주의: 사용자 단말과 서비스 진입점 사이의 Wi-Fi·모바일·ISP 품질은 SD-RTN만으로 제거할 수 없습니다.

[사용자] ─┬─ 공용 인터넷 (제어 불가) ─┬─ [Agora Edge]
          │                            │
          │     last mile              │
          └────────────────────────────┘

[Agora Edge] ─┬─ SD-RTN 백본 (Agora 제어) ─┬─ [Agora Edge]
              │                              │
              │   여기는 Agora가 라우팅 결정  │
              └──────────────────────────────┘

현재 공개 범위

현재 Agora 공식 페이지는 SD-RTN이 200개가 넘는 국가와 지역을 지원하며 end-to-end latency를 400ms 이하로 제공한다고 주장합니다. 이는 측정 조건이 공개된 보편 법칙이 아니라 Agora의 제품 지표입니다. 과거 마케팅 자료의 거점·지연 수치를 현재 지표와 같은 기준으로 취급하지 않습니다.

1. SDK가 Agora 서비스에 연결합니다.
2. 서비스는 공개 설명상 네트워크 상태와 라우팅 정책을 이용합니다.
3. 실제 경로와 품질은 지역·접속망·서비스 설정으로 측정합니다.

SD-RTN은 인터넷 라우팅을 없애는 기술이 아니라, 그 위에 Agora의 서비스 노드·telemetry·경로 정책을 더하는 구조입니다.

5. "서버가 경로를 관리한다"의 의미

추상적으로 "Agora가 경로를 제어한다"라고 말하면 와닿지 않습니다. 라우터와 Agora 서버의 차이를 코드 레벨에서 보면 직관이 잡힙니다.

일반 라우터 — 데이터 평면과 제어 평면

패킷 도착
→ 목적지 IP 확인
→ 라우팅 테이블 조회 (BGP로 사전 합의된 값)
→ 테이블에 적힌 대로 다음 홉으로 전달
제어 평면의 정책과 동적 라우팅 결과를 데이터 평면이 집행.

라우터에도 제어 평면, telemetry, 동적 라우팅과 장애 우회 기능이 있습니다. 애플리케이션 사업자가 인터넷 라우터를 직접 통제하지 못한다는 점과 라우터 자체가 측정·전환을 못 한다는 주장은 구분해야 합니다.

Agora 서버 — 소프트웨어가 도는 컴퓨터

# 제품 문서가 아니라 서비스 경로 선택을 설명하는 의사 코드

while True:
    # 1. 모든 이웃 서버에 계속 핑 날려 측정
    latency_tokyo     = ping("agora-tokyo")     # 32ms
    latency_singapore = ping("agora-singapore") # 28ms
    latency_hongkong  = ping("agora-hongkong")  # 41ms

    # 2. 패킷 오면 지금 가장 빠른 경로로 보냄
    best_route = min(
        ("tokyo", latency_tokyo),
        ("singapore", latency_singapore),
        ("hongkong", latency_hongkong),
        key=lambda x: x[1]
    )
    forward_packet(best_route[0])

    sleep(measurement_interval)  # 실제 주기는 공개되지 않음

이 코드는 개념 설명일 뿐 Agora의 실제 구현이 아닙니다.

라우터 vs Agora 서버

서비스 오버레이는 인터넷 라우팅을 대체하지 않고, 그 위에서 측정 가능한 후보 경로와 운영 정책을 추가합니다.

6. 글로벌 노드는 하나의 서버나 건물을 뜻하지 않는다

"Agora 서버"의 정체

Agora의 한 지역 진입점
  → 여러 서버·가용 영역·주소·네트워크 장비로 구성될 수 있음

유저가 Agora 앱을 켜면:

유저 PC → ISP → ... → 123.45.67.89 (Agora 서울 서버)

이건 유튜브 서버에 접속하는 것과 똑같은 원리입니다. 특별한 마법은 없습니다.

유저 → ISP → 유튜브 서버    (일반 인터넷 통신)
유저 → ISP → Agora 서버     ← 같음

데이터센터란?

데이터센터는 컴퓨팅·전력·냉각·네트워크 시설을 갖춘 물리적 장소지만, 제품의 edge나 point of presence가 곧 건물 하나 또는 서버 한 대를 뜻하지는 않습니다.

┌─────────────────────────────┐
│       데이터센터 건물        │
│                             │
│  [서버][서버][서버][서버]    │
│  [서버][서버][서버][서버]    │
│  [서버][서버][서버][서버]    │
│                             │
│  전기, 냉각, 네트워크 연결   │
└─────────────────────────────┘

왜 많을수록 좋은가?

거점이 가까우면 last-mile RTT를 줄일 가능성이 있지만, 거점 수만으로 hop 수나 품질을 보장할 수는 없습니다.

사용자 → 가까운 서비스 거점 → 서비스가 선택한 지역 간 경로 → 상대 지역 거점 → 사용자

거점 수는 커버리지 지표 중 하나입니다. 안정성은 피어링, 용량, 라우팅 정책, 장애 격리와 사용자의 접속망을 함께 측정해야 합니다.

7. 데이터센터는 ISP와 어떻게 연결되나 — 멀티호밍

여기 또 한 가지 SD-RTN을 빠르게 만드는 비밀이 있습니다 — 데이터센터의 ISP 연결 방식.

일반 유저 vs 데이터센터

🔴 일반 유저 = 단일 ISP 의존

유저(KT 가입) → KT → ... → KT → 목적지
                 ↑KT가 혼잡하면 답 없음
                 ↑다른 ISP로 못 바꿈

가정/사무실은 보통 한 ISP에만 가입. 그 ISP가 느려지면 그대로 영향받습니다.

데이터센터의 멀티호밍 예시

서비스 거점
   ├─ ISP/IX/클라우드 연결 A
   ├─ ISP/IX/클라우드 연결 B
   └─ 기타 전송 경로

멀티호밍은 여러 네트워크 연결을 사용하는 일반적 설계입니다. Agora의 특정 국내 통신사 계약과 회선 종류는 공개 출처가 없으므로 적지 않습니다.

멀티호밍이 만드는 차이

일반 유저:
유저 → KT → ... → KT → 목적지
(KT가 혼잡하면 그냥 느려짐. 끝.)

Agora 데이터센터:
서비스 거점 → 연결 A
           → 연결 B
           → 연결 C
(전환 조건과 수렴 시간은 라우팅·서비스 정책에 따름)

정리 — 공개 자료로 확인할 수 있는 범위

구체적인 백본 구성, ISP 계약과 회선 전환 정책은 공개 자료로 확인되지 않으므로 효과를 단정하지 않습니다.

8. 그래서 Web에서 Agora를 쓰는 이유는?

코덱은 어차피 브라우저 표준입니다. 그럼에도 Web SDK를 도입할 만한 이유는 명확합니다:

장점

한계

9. 실무 의사결정 — 언제 네이티브, 언제 Web?

같은 Agora SDK라도 환경마다 최적 구성이 다릅니다.

┌─────────────────────────────────────────────────────┐
│ Q1. 최저 지연 + 최고 화질이 비즈니스 KPI인가?       │
│   YES → 네이티브 앱의 SDK·기기 capability 검토      │
│   NO  → Q2                                          │
├─────────────────────────────────────────────────────┤
│ Q2. 사용자에게 앱 설치를 요구할 수 있는가?         │
│   NO  → Web SDK (SD-RTN만으로도 충분)              │
│   YES → 네이티브 검토                              │
├─────────────────────────────────────────────────────┤
│ Q3. 글로벌 사용자 대상인가?                        │
│   YES → 어떤 플랫폼이든 Agora 검토 가치 있음       │
│   NO  → 단일 리전 SFU(자체 또는 LiveKit 등) 대안   │
└─────────────────────────────────────────────────────┘

시나리오별 권장

10. 한 장 요약 — 암기 카드

네이티브 SDK = SDK 미디어 처리 + Agora 서비스
Web SDK     = 브라우저 WebRTC + Agora 서비스
직접 구축    = 브라우저/네이티브 클라이언트 + 자체 signaling/media 인프라

11. 한 줄 결론

Web SDK는 브라우저가 제공하는 WebRTC capability 안에서 동작하고, Agora의 signaling·media service와 SD-RTN을 이용한다. 네이티브의 비공개 코덱·FEC·전송 내부와 정확한 경로 전환 수치는 공개 문서 없이 단정하지 않는다. 도입 판단은 대상 지역에서의 품질 측정, 운영 기능, 비용으로 한다.

관련 글

• #9 Agora의 기업 방화벽 우회 전략 — Cloud Proxy와 Firewall Whitelist — SD-RTN 위에 얹는 방화벽 통과 레이어
• #8 왜 P2P가 막히는가? — NAT, STUN, TURN 인터넷 구조 이해하기 — WebRTC P2P의 근본 제약
• #0 WebRTC란? ICE? STUN? NAT? TURN? — WebRTC 기본 구조
• #28 H.264 Profile·인코더 옵션·비트레이트의 현실 — 코덱 레이어 깊게 파보기
• #40 라이브 스트리밍 프로토콜 선택 — HLS / LL-HLS / WebRTC 의사결정 — 프로토콜별 비교

참고 자료

• Agora SD-RTN Overview — 현재 공개된 커버리지·지연·라우팅 설명
• Agora Web SDK Documentation — Web SDK 공식 문서
• WebRTC W3C Specification — 브라우저 표준 명세
• RFC 8834 — WebRTC Media Transport and Use of RTP — 혼잡 제어·RTP 사용 요구사항
• RFC 5109 — RTP Payload Format for Generic FEC — ULPFEC 표준
• RFC 8627 — RTP Payload Format for Flexible FEC — FlexFEC 페이로드 포맷 표준