지난달 한 방송실 도면을 검토하다가 숫자 하나가 계속 눈에 밟혔습니다. “NDI Bridge의 HEVC 압축 기준, 스트림당 3.9Mbps.” 흔한 사무실 와이파이보다도 느린 속도입니다. 그런데 이 숫자 하나로 40킬로미터 떨어진 통제실에서 NDI 카메라 5대를 실시간으로 조종하고 있다는 사례를 읽었을 때, 저는 다시 한번 숫자를 확인했습니다.

위성 링크가 아닙니다. 대칭형 1Gbps 전용 회선을 쓰고도 정부 방화벽 구간을 통과하며 버스트성 패킷 손실을 견뎌야 하는 환경에서 이 결과가 나왔습니다. 답은 NDI 6였습니다. 로컬 네트워크 안에서만 돌던 영상 IP 전송 규격이 광역 네트워크(WAN)로, 그것도 방송 등급 색 재현력(HDR)을 유지한 채로 넘어간 겁니다.

이 글에서는 NDI 6가 무엇을 바꿨는지, 담당자님이 실제로 계약 사양서에 넣어야 할 항목이 무엇인지, 그리고 저희가 대역폭을 계산할 때 실수하기 쉬운 지점이 어디인지를 현장 사례 중심으로 정리합니다. 다 읽고 나면 카메라 견적서를 받았을 때 “이 스펙, 왜 이렇게 다른가요”라고 물어볼 질문이 하나 더 생기실 겁니다.

화면이 계단처럼 보여요 — 색이 끊기는 진짜 이유

담당자님이 “그래픽 화면에서 하늘색이 계단처럼 끊겨 보인다”고 말씀하시면, 저는 카메라가 아니라 색 깊이(color depth)부터 확인합니다. 이 현상은 장비 불량이 아니라 비트 수 부족입니다.

기존 NDI 5 이하 규격은 대부분 채널당 8비트 색 깊이에 머물러 있었습니다. 8비트는 약 1,670만 색상을 표현합니다. 많아 보이지만, 노을 하늘처럼 넓은 면적에 색이 서서히 변하는 장면에서는 이 정도로도 부족합니다. 표현 가능한 색 단계 사이에 빈틈이 생기고, 그 빈틈이 눈에 보이는 계단, 즉 컬러 밴딩(color banding)으로 나타납니다.

NDI 6는 채널당 10비트 이상, 최대 16비트 정밀도까지 지원합니다. 이론상 표현 색상 수는 10억 개 이상으로 늘어납니다. 여기에 하이 다이내믹 레인지(HDR)의 두 축인 PQ(Perceptual Quantizer)와 HLG(Hybrid Log-Gamma)를 모두 지원해, HDR 디스플레이와 일반 디스플레이 양쪽에서 호환됩니다. 색 영역도 기존 BT.709(HD) 기준에서 BT.2020 광색역(WCG) 대응으로 넓어졌고, 투명도를 다루는 알파 채널까지 10비트 이상으로 확장돼 자막·로고 합성 품질이 함께 올라갔습니다.

숫자만 보면 무조건 업그레이드가 정답 같지만, 여기서 확인해야 할 게 하나 더 있습니다. NDI SDK는 라이선스가 이원화돼 있습니다. 일반 개발자용 무상 SDK는 HDR 스트림을 받아서 재생하는 수신(decode) 기능까지만 제공합니다. 카메라나 인코더 하드웨어 단에서 HDR을 실시간으로 만들어 보내는(encode) 기능을 쓰려면 상용 라이선스인 ‘NDI Advanced’ 등급이 필요합니다. 신규 장비 견적을 받으실 때 “HDR 지원”이라는 문구만 보지 말고, 그게 수신 전용인지 송신까지 되는지를 먼저 확인해야 하는 이유입니다.

이 차이를 현장에서 설명할 때 저는 무대 조명 디머를 예로 듭니다. 계단식 디머는 밝기를 몇 단계로만 끊어 올리기 때문에 어느 단계에서 툭툭 끊기는 느낌이 납니다. 반면 부드러운 슬라이더 디머는 밝기가 눈에 안 보이게 이어집니다. 8비트와 10비트 이상의 차이가 정확히 이 느낌입니다. 계단 수가 늘어날수록 사람 눈은 그 경계를 못 찾습니다.

이 원리는 영화 색보정, 가상 스튜디오, 품질관리(QC) 모니터링처럼 색상 정확도가 생명인 작업에서 특히 체감됩니다. NDI 6 베타 프로그램에는 2023년 4분기부터 오토데스크, 카이론, 킬로뷰, 루멘스, 매트록스, 파나소닉, 비즈아트 같은 방송 하드웨어·소프트웨어 기업들이 참여했고, 카이론은 실시간 그래픽 솔루션 ‘Chyron PRIME’에 NDI 6 기반 HDR HLG를 통합해 라이브 그래픽과 비디오월, 채널 브랜딩을 하나의 IP 아키텍처로 묶었습니다. 색 깊이 하나가 바뀌었을 뿐인데, 그 위에 얹히는 제작 워크플로 전체가 재구성된 셈입니다.

40킬로미터 밖에서 카메라 5대를 돌려야 하는 상황

WAN 너머 원격 제작은 몇 년 전부터 있었던 이야기입니다. 다만 이전 방식은 손이 많이 갔습니다. NDI 5 시절의 ‘NDI Bridge’ 유틸리티는 공용 인터넷망을 경유해 원격지를 연결하는 아이디어 자체는 훌륭했지만, 로컬 컴퓨터에서 별도 게이트웨이 소프트웨어를 백그라운드로 계속 띄워둬야 했습니다. 그 컴퓨터가 꺼지거나 튕기면 연결도 같이 끊깁니다.

NDI 6는 이 구조를 아예 하드웨어 안으로 옮겼습니다. 카메라나 인코더 자체에 ‘하드웨어용 NDI Bridge’를 내장해, 별도 컴퓨터 중계 없이 장비가 스스로 공용 WAN에 호스트 모드로 직접 접속합니다. 세션이 열리면 비디오와 제어 패킷 전체에 대칭키 암호화가 적용돼 가로채기를 막습니다.

대역폭 문제는 H.264·HEVC(H.265) 압축 기반의 ‘NDI HX’ 전송 표준으로 해결합니다. 일반 고대역폭 NDI 대비 훨씬 가벼운, NDI Bridge의 HEVC 압축 기준 스트림당 평균 3.9Mbps로 원격 방송 송출이 가능합니다. 제가 앞서 언급한 40킬로미터 사례가 바로 이 조합입니다. 말레이시아 교육부의 원격 제작 현장에서는 대칭형 1Gbps 전용 회선을 쓰고도 정부 공용 방화벽 구간의 버스트성 트래픽 손실을 거쳐 PTZ 카메라 4대(볼린 2대, 버드독 2대)와 파나소닉 ENG 카메라 1대, 총 5대를 원격 통제해야 했습니다. 처음에는 버스트성 패킷 손실로 화면이 밀리는 스터터링이 나타났지만, 하드웨어 NDI Bridge의 수신 버퍼 타임을 400ms로 상향 조정하는 것만으로 지터가 상쇄됐고, 엔드투엔드 지연 시간은 1초 미만으로 안정됐습니다.

여기서 확인할 부분은 버퍼를 늘렸다고 문제가 저절로 사라진 게 아니라는 점입니다. 버퍼를 늘리면 지연 시간은 늘어납니다. 지터가 심한 회선일수록 버퍼를 키워 안정성을 확보하고, 실시간 상호작용이 중요한 회선일수록 버퍼를 줄여 반응 속도를 우선합니다. 이 트레이드오프를 현장 회선 상태를 실측한 뒤 결정해야지, 매뉴얼에 적힌 기본값을 그대로 쓰면 안 됩니다.

관리자용 소프트웨어 옵션도 있습니다. 그래픽 인터페이스 없이 백그라운드 서비스로 상시 구동하는 헤드리스(Headless) NDI Bridge는 Windows 환경에서 REST API와 SSL 인증으로 외부 오케스트레이션 시스템과 연동됩니다. 다만 하드웨어 임베디드 브릿지와 리눅스 기반 NDI High Bandwidth(무손실급)·HX3 조합이 성능 면에서는 여전히 우위에 있습니다. 이미 저희가 이전 글 NDI 6.3이 회의실·행사장 배선을 완전히 바꾼 3가지 이유에서 로컬 배선 관점을 정리했으니, 이번 글은 그 위에 WAN과 색 재현이라는 두 축을 더한다고 보시면 됩니다.

회선 하나 믿고 카메라를 늘렸다가 생기는 사고

WAN 문제를 해결했다고 안심할 단계가 아닙니다. 로컬 백본 대역폭 계산을 빼먹으면 사무실 안에서도 같은 사고가 납니다. 실제로 강당 카메라를 4대에서 6대로 늘리는 프로젝트를 검토하다가, 기존 1Gbps 트렁크 업링크를 그대로 쓰겠다는 계획서를 받은 적이 있습니다. 계산기를 두드리기 전까지는 담당자님도 저도 문제를 못 느꼈습니다.

NDI 대역폭 설계는 아래 식으로 계산합니다. 수식이라는 말에 눈이 감기시는 분들을 위해 미리 말씀드리면, 결국 “스트림 대역폭을 다 더하고 여유분을 얹는다”는 뜻입니다.

$$W_{total} = \left(\sum_{i=1}^{n} B_i\right) \times (1+\alpha)$$

$B_i$는 개별 스트림이 점유하는 비트레이트로, Full NDI(1080p60 무손실급)는 약 130Mbps, NDI HX2·HX3 계열은 1080p60 기준 약 11~62Mbps, 2160p60 기준 약 21~110Mbps(해상도·코덱별로 상이)를 기준으로 넣습니다. $\alpha$는 패킷 오버헤드와 지터 마진을 위한 여유 계수로, 기업용 인프라는 최소 20%, 고대역폭 다중 멀티캐스트 환경에서는 30% 이상을 권장합니다.

앞서 언급한 강당 사례로 계산해 보겠습니다. Full NDI 카메라 4대(각 130Mbps)와 원격 중계용 PTZ 2대(각 62Mbps, NDI HX3 1080p60 H.264 기준)를 동시에 운용한다고 가정합니다.

$$\sum B_i = (130 \times 4) + (62 \times 2) = 644\text{ Mbps}$$

여기에 기업용 최소 마진 20%를 적용합니다.

$$W_{total} = 644 \times 1.2 = 772.8\text{ Mbps}$$

세그먼트 스위칭 허브 구간에는 최소 약 773Mbps 실시간 처리 능력이 담보돼야 합니다. 기존 1Gbps 트렁크 업링크는 숫자상으로는 아직 넘지 않지만, 남는 여유가 1Gbps의 4분의 1에 못 미치는(약 227Mbps) 수준이라 이 회선이 일반 사무용 데이터 트래픽과 섞여 있다면 피크 시간에 곧바로 병목이 옵니다. 그래서 저희는 스위치 간 업링크를 10GbE 규격으로 증설하도록 권고합니다. 773Mbps라는 숫자 자체보다, 1Gbps 한계에 얼마나 바짝 붙어 있는지가 실제 사고 여부를 가릅니다.

대역폭만큼 중요한 게 트래픽 격리입니다. 미디어 전용 가상 네트워크(VLAN)를 물리 스위치 단에서 분리하고, 원하는 단말로만 멀티캐스트 영상이 흐르도록 IGMP Snooping과 IGMP Querier를 정확히 설정해야 합니다. 이 설정이 빠지면 대용량 NDI 멀티캐스트가 일반 사무 PC 포트로 새어 나가 사내 인터넷이 마비되거나, 반대로 사무용 트래픽이 영상 패킷 주기를 밀어내 지터가 악화됩니다.

카메라 선정 단계에서는 대역폭 등급에 맞는 모델을 고르는 것도 설계의 일부입니다. 아래는 NDI 공식 문서 기준 대역폭 등급과, 실제 방송용 PTZ 카메라 제조사인 에이버(AVer)의 라인업을 매칭한 예시입니다.

이 표에서 판단해야 할 지점은 하나입니다. 대역폭 여유가 충분한 백본에는 High Bandwidth급을, 스위치 용량이 제한적이거나 회선을 다중 지사와 공유하는 환경에는 HX2·HX3급을 배정하는 것이 실사고를 줄입니다. 등급을 반대로 배정하면 화질과 네트워크 안정성 둘 다 손해를 봅니다.

이런 설계 문제가 준공 후 터지면 책임 소재가 애매해집니다. 카메라 화면에 노이즈가 나면 영상 장비 공급사는 “하드웨어 불량이 아니다”라고 하고, IT 시공사는 “스위치 구성에는 문제없다”고 맞섭니다. 이 공방을 근본적으로 없애는 방법은 미디어 디바이스 조달과 핵심 스위치 인프라 가설을 하나의 기술 주체에 통합 발주해, 준공 후 사후 테스트까지 단일 주체가 검증하도록 만드는 것입니다. 발주처 입장에서 장비와 네트워크를 별도 회사에 나눠 맡기는 편이 비용 절감처럼 보일 수 있지만, 장애 발생 시 원인 규명에 드는 시간과 재시공 비용을 감안하면 통합 발주가 실질적으로 더 저렴한 경우가 많습니다.

사무실 화상회의도 NDI로 빨려 들어간다

2026년 1월 나온 NDI 6.3 마이너 업데이트는 성능보다 운영 가시성과 생태계 통합에 집중했습니다. 그중 실무자가 가장 먼저 체감하는 변화는 기업 화상회의 플랫폼과의 연동입니다.

Microsoft Teams 환경에서는 IT 관리자가 PowerShell 명령 한 줄로 NDI 스트리밍 정책을 켤 수 있습니다.

Set-CsTeamsMeetingPolicy -Identity "Global" -AllowNDIStreaming $true

이 정책이 배포되면 회의 참가자 개개인의 발표자 카메라 화면, 공유 화면 같은 피드가 각각 독립된 NDI 채널로 로컬 네트워크에 방출됩니다. 이 채널들은 vMix나 OBS Studio 같은 프로덕션 스위처에 고화질 소스로 바로 인입됩니다. 다만 이런 다중 스트림 동시 수신은 로컬 PC에 상당한 부하를 주기 때문에, 실무에서는 단일 시스템 기준 동시 수신 스트림을 2~3개로 제한하고 핵심 발표자 피드만 고정(Pin)하는 방식으로 운용합니다. Zoom Rooms 역시 ‘NDI Advanced’ 엔진을 내장해 원격 고해상도 캠 소스를 로컬 가상 카메라로 자동 매핑하며, ‘ZoomISO’, ‘Tiles for Zoom’ 같은 유틸리티와 함께 쓰는 구성이 늘고 있습니다.

운영 가시성 쪽에서는 송신단 레벨 모니터링(Sender-Level Monitoring)이 새로 생겼습니다. 예전에는 화면에 문제가 보인 다음에야 원인을 찾았다면, 지금은 NDI Discovery Tool이 각 송신 장비의 패킷 손실률, 지터, 실제 인코딩 프레임 레이트를 중앙 콘솔에서 실시간으로 보여줍니다. 여기에 양방향 디스커버리 API가 강화돼, 새 하드웨어가 스위치 포트에 꽂히는 즉시 해상도·코덱·알파 채널 지원 여부를 관리 서버에 자동으로 알립니다. 수동 라우팅 테이블 입력이 사실상 사라진다는 뜻입니다.

하드웨어 쪽에서는 인텔의 ‘Agilex 7 FPGA’ 플랫폼과의 네이티브 SDK 연동이 발표됐고, 저작권 보호 규격인 HDCP와의 충돌을 막기 위해 ProITAV와의 협력으로 HDCP 호환 인코딩·디코딩을 내부에 포함했습니다. 보안 정책 충돌로 화면이 갑자기 까맣게 꺼지는 현상 없이 기업 보고용 화상회의와 콘텐츠 재생 단말을 같은 네트워크에 태울 수 있게 됐다는 의미입니다.

수신 클라이언트를 운영할 때는 세 가지 도메인을 구분해서 설정합니다. 화면에 안 보이는 백그라운드 소스는 Pause로 리소스를 회수하고, 상시 유지해야 할 피드는 KeepAlive로 지정합니다. 대역폭은 원격 프리뷰용 Lowest, 마스터 녹화용 Highest, 오디오만 필요한 경우 Audio only로 나눕니다. 지연 시간은 일반 고정 카메라는 Normal(Safe), PTZ 트래킹은 Low, 극한의 실시간 상호작용에는 Lowest(Unbuffered)를 씁니다. 이 중 Lowest(Unbuffered)는 지터가 심한 일반 네트워크에서는 프레임 드롭 위험이 커지므로, 안정된 전용 회선에서만 선택하는 것이 맞습니다.

NDI 6, 컨설턴트가 지금 계약서에 넣는 문구

NDI 6를 처음 검토할 때 저는 색 깊이 숫자에만 집중했습니다. 10비트, 16비트, 10억 색상 — 스펙 시트만 보면 화려합니다. 그런데 실제로 발주 사양서에 반영해야 하는 건 그 숫자보다 두 가지입니다.

첫째, 신규 카메라·인코더를 선정할 때 NDI 6.3 기반의 송신단 레벨 모니터링 API와 양방향 디스커버리 기능이 펌웨어에 내장돼 있는지를 필수 항목으로 명시합니다. 이 기능이 없으면 패킷 손실이 화면에 나타나기 전까지는 아무도 문제를 알 수 없습니다. 둘째, 네트워크 백본 설계를 장비 도입 일정보다 먼저 확정합니다. 앞서 계산한 대역폭 공식을 도면 확정 전에 돌려보지 않으면, 카메라를 다 설치하고 나서 스위치를 다시 뜯는 상황이 옵니다.

저희 화상회의 카메라 연결 방식 USB·HDMI·IP 3가지 비교 가이드에서는 이런 IP 전송이 회의실 카메라 선택에 어떻게 연결되는지 다뤘고, 원격 사이트 오디오망 운영 관점은 출장 없이 지사 오디오망 고치는 Dante Director 완전 가이드에서 다룬 적이 있습니다. NDI 6가 영상 쪽에서 하는 일을, Dante Director는 오디오 쪽에서 이미 하고 있었던 셈입니다.

담당자님이 지금 견적서를 받고 계시다면, 스펙 시트에서 “HDR 지원”이라는 문구를 보시는 대신 다음 두 가지를 먼저 물어보시길 권합니다. 이 장비가 HDR을 인코딩까지 하는지, 아니면 디코딩만 하는지. 그리고 이 카메라 대수를 다 더했을 때 백본 대역폭이 실제로 얼마나 필요한지. 이 두 질문에 명확히 답하는 공급사라면, 나머지 계약 조건도 신뢰할 만합니다.

자주 묻는 질문

NDI 6 도입을 검토하실 때 자주 받는 질문을 정리했습니다.

색과 대역폭은 HDR 표준을 정의하는 ITU-R BT.2100 권고안을 기준으로 검증하는 것이 원칙입니다.

[email protected] · https://www.symconsulting.co.kr