DJing Stream: 실시간 배포를 위한 SRT 오디오 아키텍처 사례 연구

macOS 앱이 WebRTC보다 SRT를 우선시하여 방송 품질의 오디오를 달성하는 방법, 그리고 업계 표준이 잘못되었을 수 있는 이유.

아키텍처 과제

원격 DJ 스트리밍은 흥미로운 스트리밍 엔지니어링 문제를 제시합니다. 각 엔드포인트에 15,000달러짜리 방송용 인코더 없이, 방송 품질을 유지하면서 비압축 오디오를 여러 공연장에 동시에 전달하려면 어떻게 해야 할까요?

기존 접근 방식은 비디오와 오디오를 단일 RTMP 또는 HLS 스트림으로 결합하고, 네트워크 변동에는 적응형 비트레이트로 대응하며, 세그먼트 기반 전송에 따르는 15~30초의 지연을 수용합니다. 프로페셔널 DJ-투-공연장 스트리밍을 위해 설계된 macOS 애플리케이션인 DJing Stream은 프로토콜 아키텍처 관점에서 검토할 가치가 있는 근본적으로 다른 접근 방식을 채택합니다.

별도의 스트림, 별도의 프로토콜

핵심 아키텍처 결정은 오디오와 비디오를 근본적으로 다른 프로토콜을 필요로 하는 서로 다른 미디어로 취급하는 것입니다.

이러한 역전(오디오 비트레이트가 비디오보다 높음)은 스트리밍에서 거의 전례가 없습니다. 대부분의 플랫폼은 비디오에 오디오의 5~10배 대역폭을 할당합니다. 그 이유는 다음과 같습니다. 프로페셔널 공연장 배포에서 오디오 품질은 유일하게 중요한 요소입니다. 바의 사운드 시스템은 모든 압축 아티팩트를 드러냅니다. DJ를 보여주는 비디오 피드는 보조적인 것으로, 스크린에 표시하면 좋지만 고객 경험에 필수적이지는 않습니다.

왜 오디오에 SRT인가?

SRT(Secure Reliable Transport)는 프로페셔널 오디오에 필수적인 여러 속성을 제공합니다. 특히 HLS는 LPCM(Linear PCM) 오디오를 지원하지 않습니다. 손실 전송에는 AAC나 AC-3, 무손실 전송에는 ALAC과 같은 코덱이 필요합니다. 이로 인해 HLS는 비압축 오디오에는 부적합하지만, 아래에서 살펴보겠지만 HLS ALAC이 HLS를 통한 무손실 스트리밍의 가능성을 열었습니다.

재전송을 동반한 순서 보장 전송: 패킷이 삭제되거나 순서가 뒤바뀔 수 있는 WebRTC의 최선 노력(best-effort) 모델과 달리, SRT는 손실된 패킷의 자동 재전송을 통한 순서 보장 전송을 제공합니다. 오디오에서 패킷 손실은 청취 가능한 글리치를 의미합니다. SRT의 ARQ 메커니즘은 전송 중 데이터가 손실되면 버퍼가 고갈되기 전에 재전송되도록 보장합니다.

구성 가능한 지연/안정성 트레이드오프: SRT는 재전송 윈도우를 직접 제어하는 지연 파라미터를 노출합니다. 지연이 높을수록 패킷 복구 시간이 늘어나고, 안정성이 향상됩니다. DJing Stream은 이를 사용자 대상 슬라이더로 노출합니다.

Latency Configuration by Use Case:
├── Live venue deployment: 4-5 seconds (maximum reliability)
├── Interactive sessions: 2-3 seconds (accept occasional dropouts)
├── Home listening: 4-6 seconds (prioritize quality)
└── Challenging networks: 8-10 seconds (international, mobile, congested)

고정 비트레이트: SRT는 네트워크 상태에 따라 비트레이트를 적응시키지 않습니다. 일관된 품질을 유지하고 재전송 버퍼에 의존하여 변동을 흡수합니다. 이는 적응형 비트레이트가 청취 가능한 품질 변동을 의미하는 오디오에서 매우 중요합니다.

왜 비디오에 WebRTC인가?

WebRTC는 다른 이유로 비디오에는 여전히 올바른 선택입니다.

• 실시간 피드백: DJ는 관중을 보고 싶어하고, 공연장은 공연하는 DJ를 표시하고 싶을 수 있습니다. 이를 위해서는 품질을 희생하더라도 낮은 지연이 필요합니다.
• NAT 트래버설: WebRTC의 ICE/STUN/TURN 인프라는 NAT 뒤에 있는 DJ와 공연장 간의 피어 투 피어 비디오의 복잡성을 처리합니다.
• 허용 가능한 품질 저하: 비디오 품질 변동은 오디오 글리치와 달리 시각적으로 허용할 수 있습니다.

핵심 통찰은, 비디오가 끊기더라도 오디오는 완벽하게 유지된다는 것입니다. 스트림은 완전히 독립적입니다. 오디오에 영향을 주지 않고 리소스를 절약하기 위해 비디오를 완전히 끌 수 있습니다.

SRT를 통한 비압축 PCM

대부분의 스트리밍 플랫폼이 128~320 kbps의 AAC 또는 Opus를 사용하는 반면, DJing Stream은 24비트 PCM 오디오를 전송합니다.

Audio Specifications:
├── Format: Uncompressed 24-bit PCM
├── Sample rate: 44.1 kHz or 48 kHz (auto-detected)
├── Bitrate: ~2,304 kbps
├── Container: MPEG-TS
└── Transport: SRT

참고로, Spotify의 최고 품질은 손실 압축으로 320 kbps입니다. DJing Stream은 압축 아티팩트 없이 7배 이상의 비트레이트를 전달합니다. 트레이드오프는 대역폭입니다. 각 청취자는 오디오만으로 약 2.5 Mbps를 소비합니다.

HLS ALAC: 열악한 조건에서의 무손실 오디오

DJing Stream의 프로토콜에 가장 최근 추가된 것은 ALAC(Apple Lossless Audio Codec)을 사용한 HLS입니다. 비압축 PCM을 사용하는 SRT가 오디오 품질의 최고 표준으로 남아 있지만, HLS ALAC은 무손실 오디오를 희생하지 않으면서 어려운 네트워크 시나리오를 위한 복원력 있는 대안을 추가합니다.

ALAC은 무손실 코덱입니다. 모든 샘플이 수신 측에서 비트 단위로 정확하게 재구성됩니다. AAC이나 Opus와 달리 압축 아티팩트, 스펙트럼 공백, 프리에코가 없습니다. 공연장의 사운드 시스템에 도달하는 오디오는 DJ의 믹서에서 나온 것과 수학적으로 동일합니다. 비압축 PCM과의 차이는 순전히 전송 효율에 있습니다. ALAC은 약 40~60%의 압축을 달성하여 대역폭 요구 사항을 크게 줄입니다.

HLS ALAC Audio Specifications:
├── Format: ALAC (Apple Lossless Audio Codec)
├── Quality: Lossless (bit-perfect reconstruction)
├── Bitrate: ~900-1,400 kbps (vs ~2,304 kbps for PCM)
├── Container: fMP4 segments over HLS
└── Bandwidth savings: ~40-50% vs uncompressed PCM

핵심 장점은 네트워크 복원력입니다. HLS의 세그먼트 기반 전송은 SRT의 실시간 재전송 모델보다 네트워크 지터와 일시적인 연결 끊김을 훨씬 우아하게 흡수하는 재생 버퍼를 도입합니다. 혼잡한 Wi-Fi의 공연장, 여러 ISP 경계를 넘는 국제 스트림, 모바일 테더링 설정의 경우, HLS ALAC은 SRT가 끊기는 조건에서도 재생을 지속하는 폴백을 제공합니다.

트레이드오프는 지연입니다. SRT가 2~10초 내에 오디오를 전달하는 반면, HLS의 세그먼트 기반 접근 방식은 오버헤드를 추가하여 일반적으로 엔드 투 엔드로 10~20초가 됩니다. 대부분의 공연장 배포에서 이는 완벽하게 허용됩니다. 관객은 DJ의 움직임과 서브초 동기화가 필요하지 않으며, 스피커에서 나오는 끊김 없는 무손실 오디오가 필요합니다.

이를 통해 운영자에게 실용적인 결정 매트릭스가 제공됩니다.

Protocol Selection:
├── Stable network + lowest latency → SRT with uncompressed PCM
├── Tough network + lossless quality → HLS with ALAC
└── Video monitoring (any network)   → WebRTC

DJ는 자신의 네트워크 조건에 가장 적합한 오디오 전송 방식을 선택합니다. 낮은 지연이 중요한 안정적인 연결에는 SRT를, 안정성이 우선인 경우에는 HLS ALAC을 사용합니다.

허브 앤 스포크 배포

네트워크 아키텍처는 피어 투 피어가 아닌 릴레이 모델을 사용합니다.

DJ Mixer
    │
    ▼ USB/Thunderbolt
  macOS (AVFoundation capture)
    │
    ▼ MPEG-TS/SRT
  SRT Relay Server
    │
    ├──────────────────┬──────────────────┐
    ▼                  ▼                  ▼
 Venue 1            Venue 2            Venue N
 (SRT Subscriber)   (SRT Subscriber)   (SRT Subscriber)

DJ는 청취자 수에 관계없이 단일 스트림을 게시합니다. 릴레이 서버가 팬아웃 배포를 처리합니다. 이를 통해 DJ의 업로드 대역폭 요구 사항을 일정하게 유지하면서 동시 다중 공연장 전송을 가능하게 합니다.

각 공연장은 SRT 스트림을 AVAudioEngine을 통해 사운드 시스템이나 AirPlay 엔드포인트로 라우팅합니다.

방송 인프라로서의 Apple Silicon

Comrex나 Tieline 같은 제조업체의 기존 방송용 컨트리뷰션 인코더는 엔드포인트당 3,000~15,000달러의 비용이 듭니다. 약간 더 낮은 지연(1~2초)을 달성하지만 포인트 투 포인트로 작동하여 각 공연장 연결에 별도의 하드웨어가 필요합니다.

DJing Stream은 일반 소비자용 Mac에서 실행됩니다. Apple Silicon의 통합 메모리 아키텍처와 하드웨어 가속 미디어 처리를 통해 이전에는 전용 방송 장비가 필요했던 작업이 가능해졌습니다.

• AVFoundation: 모든 USB/Thunderbolt 인터페이스에서의 저지연 오디오 캡처
• 하드웨어 가속 인코딩: 비디오용 (활성화 시)
• 효율적인 SRT 처리: 안정적인 전송을 위해

리퍼비시 Mac mini M1(250~300달러)로 방송 품질의 스트리밍을 무리 없이 처리할 수 있습니다. 진입 장벽이 수천 달러에서 기존 Mac 하드웨어 수준으로 낮아집니다.

소비자 플랫폼과의 비교

Mixcloud Live, Twitch, YouTube Live를 사용하면 되지 않을까요? 오디오 품질 제한(손실 압축, 적응형 비트레이트) 외에도 스트리밍 엔지니어가 이해해야 할 라이선스 고려 사항이 있습니다.

소비자 스트리밍 플랫폼은 개인 청취용으로 라이선스되어 있습니다. 플랫폼 전송에 대한 공연 라이선스를 보유하고 있습니다. 그러나 해당 콘텐츠를 사운드 시스템을 통해 재생하는 공연장은 공연장 자체의 PRO 라이선스(ASCAP, BMI, SESAC, SACEM 등)가 필요한 2차 공연을 만들게 됩니다. 이 회색 지대에서 운영하는 많은 공연장이 이 구분을 인식하지 못하고 있습니다.

DJing Stream은 적절한 공연 라이선스를 이미 보유한 공연장을 위한 전송 인프라로 자리매김합니다. 이는 라이브 DJ나 배경 음악 시스템에 필요한 것과 동일한 라이선스입니다.

기술 사양 요약

구현 시 고려 사항

유사한 아키텍처를 평가하는 스트리밍 엔지니어에게 몇 가지 설계 결정이 주목할 만합니다.

프로토콜 독립성: 오디오와 비디오 스트림을 분리하면 각각이 타협 없이 최적의 프로토콜을 사용할 수 있습니다. 아키텍처적 복잡성은 높아지지만 품질 면의 이점은 상당합니다. 완벽한 오디오/비디오 동기화는 DJ 스트리밍에 필수적이지 않지만, 실시간 시각적 피드백은 반드시 필요합니다. HLS와 같은 표준 세그먼트 기반 프로토콜은 15~30초의 지연을 도입하여 시각적 모니터링을 불가능하게 합니다. WebRTC가 비디오 문제를 해결하고, SRT가 오디오 품질 요구 사항을 처리합니다.

사용자에게 노출된 지연 제어: 지연을 "저지연 모드" 토글 뒤에 숨기는 대신, 사용 사례 가이드와 함께 실제 파라미터를 노출하면 운영자가 정보에 기반한 트레이드오프를 할 수 있습니다.

릴레이 아키텍처 vs. P2P: 허브 앤 스포크 모델은 릴레이 홉을 추가하지만 다중 목적지 전송을 극적으로 단순화하고 소스 대역폭을 일정하게 유지합니다. 1대다 배포가 필요한 모든 애플리케이션에서 이것이 아마도 올바른 선택일 것입니다.

오디오 우선 비트레이트 할당: 오디오 품질이 주요 가치 제안인 애플리케이션의 경우, 표준 비디오 중심 대역폭 할당이 자신의 사용 사례에 적합한지 검토해 보십시오.

결론

DJing Stream은 기존 스트리밍 아키텍처에서의 흥미로운 이탈을 보여줍니다. 오디오에서 WebRTC의 속도보다 SRT의 안정성을 우선시하고, 비디오보다 오디오에 더 많은 대역폭을 할당하며, 열악한 조건에서의 무손실 복원력을 위해 HLS ALAC을 추가하고, Apple Silicon을 활용하여 방송 품질의 전송을 대중화합니다.

공연장 스트리밍 시스템, 원격 프로덕션 워크플로우, 또는 오디오 충실도가 중요한 모든 애플리케이션을 구축하는 경우, 여기서 소개한 아키텍처 패턴(서로 다른 미디어 유형에 대한 별도의 프로토콜, 열악한 네트워크를 위한 무손실 대안, 구성 가능한 지연 트레이드오프, 허브 앤 스포크 배포)은 검토할 가치가 있는 템플릿을 제공합니다.

애플리케이션은 Mac App Store에서 이용 가능합니다. 자세한 정보는 djing.com을 참조하세요.