webrtc

3 개의 포스트

포크에서 벗어나기: Meta가 50개 이상의 유스케이스에서 WebRTC를 현대화한 방법 (새 탭에서 열림)

메타는 대규모 오픈소스 프로젝트인 WebRTC를 커스터마이징하여 사용하며 겪었던 '포크 트랩(Forking Trap)'을 해결하기 위해, 최신 업스트림 버전과 내부 최적화 버전을 동시에 실행할 수 있는 듀얼 스택 아키텍처를 구축했습니다. 이를 통해 50개 이상의 유즈케이스에서 안전하게 A/B 테스트를 수행하며 성공적인 마이그레이션을 마쳤고, 결과적으로 성능 향상과 바이너리 크기 최적화 및 보안 강화를 달성했습니다. 현재 메타는 이 구조를 바탕으로 모노레포 환경에서도 업스트림의 최신 업데이트를 지속적으로 반영하며 기술적 부채 없이 서비스를 운영하고 있습니다. **포크 트랩과 모노레포 환경의 도전 과제** * 오픈소스 프로젝트를 내부적으로 포크하여 오래 사용하면 업스트림과의 격차가 벌어져 최신 기능을 반영하기 어려워지는 '포크 트랩'이 발생합니다. * 빌리언 단위의 사용자를 보유한 서비스에서 대규모 라이브러리를 한 번에 교체하는 것은 리스크가 크기 때문에, 구버전과 신버전을 동시에 실행하며 검증할 수 있는 A/B 테스트 역량이 필수적이었습니다. * 하지만 메타의 모노레포 환경과 정적 링크(Static Linking) 방식에서는 동일한 라이브러리의 두 버전을 동시에 포함할 때 '단일 정의 원칙(ODR)' 위반으로 인한 수천 개의 심볼 충돌 문제가 발생했습니다. **심(Shim) 레이어와 듀얼 스택 아키텍처** * 애플리케이션과 WebRTC 구현체 사이에 프록시 역할을 하는 '심(Shim) 레이어'를 구축하여 통합된 API를 제공했습니다. * 애플리케이션은 버전과 무관한 심 API를 호출하고, 심 레이어는 런타임 설정(Flavor)에 따라 레거시 또는 최신 구현체로 호출을 전달합니다. * 모든 라이브러리를 복제하는 대신 최하위 레이어에서 심을 구현함으로써, 바이너리 크기 증가폭을 예상치(38MB) 대비 약 87% 감소한 5MB 수준으로 억제했습니다. **심볼 충돌 해결과 하위 호환성 유지** * 자동화된 네임스페이스 재명명(Renamespacing) 스크립트를 통해 `webrtc::` 네임스페이스를 각 버전에 맞게 `webrtc_legacy::`, `webrtc_latest::` 등으로 분리했습니다. * 네임스페이스 외부에 존재하는 글로벌 C 함수와 변수들은 버전별 식별자를 추가하여 충돌을 방지했습니다. * 기존 코드의 수정을 최소화하기 위해 C++의 `using` 선언을 활용하여, 외부 호출부에서는 여전히 기존 네임스페이스를 사용하는 것처럼 보이게 하면서 내부적으로는 올바른 버전에 연결되도록 설계했습니다. **런타임 버전 디스패치 및 관리** * 템플릿 기반의 헬퍼 라이브러리를 사용하여 중복 로직을 줄이고 버전별 특화 동작을 정의했습니다. * 앱 시작 시점에 결정되는 글로벌 플래그(Enum)를 통해 어떤 WebRTC 버전을 사용할지 동적으로 결정합니다. * 패치 관리의 복잡성을 해결하기 위해 모노레포 내에서 업스트림 버전을 주기적으로 가져오고 내부 패치를 반복적으로 적용하는 워크플로우를 정립했습니다. 대규모 오픈소스 프로젝트를 운영할 때 직접적인 포크보다는 이와 같은 모듈식 아키텍처와 자동화된 네임스페이스 관리를 도입하는 것이 기술적 고립을 막는 효과적인 전략이 될 수 있습니다. 이는 특히 안전한 배포와 지속적인 업스트림 동기화가 중요한 대규모 시스템에서 실무적인 해법을 제시합니다.

서버 의존성 없이 실시간 클라이언트 사이드 노이즈 억제 라이브러리를 구축한 방법 (새 탭에서 열림)

Datadog의 CoScreen 팀은 원격 협업 중 발생하는 배경 소음을 실시간으로 제거하기 위해, 높은 성능과 이식성을 갖춘 오픈소스 라이브러리인 `dtln-rs`를 개발했습니다. 기존의 노이즈 억제 도구들은 WebRTC와의 통합이 어렵거나 고성능 서버 자원을 요구한다는 한계가 있었으나, 이 라이브러리는 클라이언트 측에서 효율적으로 동작하도록 설계되었습니다. 결과적으로 M1 맥북 프로 기준 1초의 오디오를 단 33ms 만에 처리하며, 서버 의존성 없이 다양한 플랫폼에서 고품질의 실시간 소음 제거를 가능하게 합니다. **dtln-rs: 경량화된 실시간 노이즈 억제 라이브러리** * DTLN(Dual-Signal Transformation LSTM Network) 모델을 기반으로 구축된 Rust 언어 기반의 프로젝트입니다. * WebAssembly(WASM), Native Rust, Node.js 네이티브 모듈 등 다양한 타겟으로 빌드할 수 있어 웹 브라우저와 네이티브 앱 모두에 쉽게 통합 가능합니다. * 실제 테스트에서 이웃의 잔디 깎는 기계 소음을 완전히 제거할 정도로 뛰어난 성능을 보여주었으며, 이를 통해 사용자에게 실제적인 가치를 전달합니다. **DTLN 모델의 작동 원리와 효율성** * STFT(단시간 푸리에 변환)를 사용하여 소리를 작은 단위로 분해하고, 주파수별 볼륨(크기 스펙트럼)과 위상(Phase) 정보를 분석합니다. * LSTM(장단기 메모리) 신경망이 포함된 모델을 통해 분석된 데이터 중 어떤 부분이 음성이고 어떤 부분이 소음인지 실시간으로 판단합니다. * 위상 정보와 크기 성분을 모두 활용하는 딥러닝 방식 덕분에 에어컨 소음, 카페 소음, 종이 부스럭거리는 소리 등 다양한 환경에 동적으로 적응하며 즉각적인 감쇠가 가능합니다. **기존 기술의 한계와 개발 배경** * 기존의 고성능 AI 노이즈 제거 모델들은 대부분 강력한 서버 하드웨어를 필요로 하며, 이는 추가적인 지연 시간(Latency)과 막대한 서버 비용을 발생시킵니다. * WebRTC는 널리 쓰이는 오픈소스 기술임에도 불구하고 내장된 노이즈 제거 기능은 구세대 솔루션에 머물러 있어 현대적인 협업 도구들의 품질 요구 수준을 충족하지 못했습니다. * Google 등 대기업이 사용하는 최첨단 모델은 비공개 소스이거나 전용 서버 인프라에 종속되어 있어, 소규모 팀이나 일반 개발자들이 자신들의 앱에 고품질 기능을 구현하기에는 제약이 컸습니다. 실시간 오디오 및 비디오 애플리케이션을 개발하면서 서버 비용 부담 없이 고성능 노이즈 캔슬링 기능을 추가하고 싶다면 `dtln-rs`를 검토해 보시기 바랍니다. 클라이언트 측 리소스를 효율적으로 활용하면서도 WebRTC와 매끄럽게 결합되는 이 라이브러리는 사용자 경험을 한 단계 끌어올리는 실용적인 해결책이 될 것입니다.

디스코드에서 수백만 (새 탭에서 열림)

디스코드(Discord)는 서비스 초기 광범위한 호환성을 위해 32비트 아키텍처를 선택했으나, 현대적인 컴퓨팅 환경에 발맞춰 64비트 전환의 필요성을 강조하고 있습니다. 32비트는 단일 버전으로 거의 모든 윈도우 환경을 지원할 수 있다는 장점이 있었지만, 엄격한 메모리 제한으로 인해 발생하는 크래시 문제와 라이브러리 지원 중단이라는 한계에 봉착했습니다. 결과적으로 디스코드는 더 높은 안정성과 성능을 제공하기 위해 최신 하드웨어 표준인 64비트 아키텍처로의 이전을 추진하고 있습니다. ### 초기 32비트 선택의 배경과 이점 * **광범위한 호환성**: 2015년 출시 당시 디스코드는 윈도우의 하위 호환성 레이어를 활용해 32비트와 64비트 기기 모두에서 작동하는 단일 앱 버전을 유지하고자 했습니다. * **개발 효율성**: 하나의 실행 파일만 관리하면 되었기에 초기 개발 단계에서 리소스를 집중하고 사용자 접근성을 높이는 데 유리했습니다. * **적은 메모리 사용량**: 이론적으로 32비트 애플리케이션은 64비트에 비해 포인터 크기가 작아 메모리를 덜 사용하는 특성이 있습니다. ### 32비트 아키텍처의 기술적 한계 * **메모리 주소 지정 제한**: 32비트 애플리케이션은 사용할 수 있는 메모리 양에 물리적인 상한선이 존재합니다. 64비트 기기에서 실행하더라도 이 제한을 초과하면 성능 저하나 예기치 않은 크래시가 발생합니다. * **성능 저하 및 오류**: 디스코드가 고도화됨에 따라 메모리 집약적인 작업이 늘어났고, 32비트의 한계치에 도달하여 사용자 경험을 해치는 사례가 빈번해졌습니다. ### 64비트 전환의 필연성 * **라이브러리 생태계의 변화**: 디코드의 기반이 되는 Electron, WebRTC와 같은 주요 라이브러리들은 이미 수년 전부터 64비트를 기본 아키텍처로 채택하고 있습니다. * **유지보수 및 보안 리스크**: 업계 표준이 64비트로 이동함에 따라 32비트 라이브러리에 대한 버그 수정이나 최적화가 줄어들고 있으며, 이는 장기적으로 잠재적인 보안 취약점과 비효율성에 노출될 위험을 높입니다. * **미래 지향적 최적화**: 64비트 환경에서는 더 많은 시스템 자원을 안정적으로 활용할 수 있어, 인게임 오버레이와 같은 고성능 기능을 더욱 매끄럽게 구현할 수 있습니다. 데스크톱 애플리케이션 개발 시 초기에는 32비트의 범용성이 매력적일 수 있으나, 서비스의 규모가 커지고 현대적인 라이브러리를 지속적으로 활용해야 한다면 64비트 전환은 선택이 아닌 필수입니다. 안정적인 메모리 관리와 커뮤니티의 기술 지원을 받기 위해서는 하드웨어 표준에 맞춘 아키텍처 업데이트가 반드시 선행되어야 합니다.