방송국 부조정실에서 있었던 일입니다. 대형 컨퍼런스 콘솔에서 나온 오디오를 방송 송출 체인에 붙였는데, 화면이 전환될 때마다 소리가 아주 살짝 밀립니다. 눈으로는 거의 안 보이는데, 귀로는 확실히 걸립니다.

케이블을 바꿔봤습니다. 그대로였습니다. 스위치 포트를 옮겨봤습니다. 여전했습니다. 결국 원인을 찾은 곳은 RTP 패킷 헤더 안이었습니다. 원래 0으로 고정돼야 할 값 하나가, 표준상 허용된 무작위 값으로 들어가 있었습니다.

담당자님이 “AES67끼리 연결한 건데 왜 이런 게 문제가 되나요”라고 물으셨습니다. 맞는 질문입니다. AES67은 2013년 오디오공학회(AES)가 제정한 이후 사실상 오디오 IP 상호운용성의 공통 언어가 됐지만, 2026년 지금은 그 언어 안에 방언이 여럿 생겼습니다. 이 글은 AES67-2023 개정과 그 주변 표준들이 2026년 현재 무엇을 바꿔놓았는지, 현장에서 실제로 부딪히는 지점 위주로 정리한 글입니다.

케이블도 스위치도 멀쩡한데 왜 소리가 어긋났을까요 — 숫자 하나의 범인

앞서 말한 그 부조정실 사례가 답입니다. 범인은 물리 계층이 아니라 RTP 헤더 안의 클록 오프셋 값이었습니다.

이 표준을 따르는 일반 송신기는 보안과 정보 누출 방지를 위해 미디어 원본 클록과 실제 RTP 패킷 타임스탬프 사이에 무작위 오프셋을 허용합니다. 문제는 SMPTE ST 2110 환경입니다. 비디오·오디오·메타데이터를 각각 별도 스트림으로 분리해 전송하는 구조라, 여러 에센스를 프레임 단위로 다시 결합하려면 모든 스트림이 같은 기준 클록에 정확히 맞아떨어져야 합니다. 그래서 SMPTE ST 2110-30:2025 표준은 방송용 송신기가 RTP 클록 오프셋 값을 반드시 0으로 설정하도록 명시하고 있습니다. 이런 일반 송신기를 방송용 ST 2110-30 수신기에 그대로 물리면, 수신 장치가 임의 오프셋을 해석하는 별도 로직을 갖추고 있지 않은 한 이런 미묘한 어긋남이 생깁니다.

케이블·스위치·앰프를 순서대로 의심하기 전에, 소스 장비가 “순수 AES67″인지 “ST 2110-30 준수”인지부터 확인하는 게 진단 순서를 절반으로 줄여줍니다. 두 장비 모두 같은 표준 로고가 붙어 있어도, 이 값 하나 때문에 갈립니다.

PTPv2.1이라는 단어에 뒤로가기 누르고 싶은 분들을 위해 씁니다

수식이 나오면 넘기셔도 괜찮습니다. 결론만 먼저 말씀드리면, AES67-2023의 가장 큰 변화는 시간 동기화 규격을 IEEE 1588-2008(PTPv2)에서 IEEE 1588-2019(PTPv2.1) 호환 구조로 올린 것입니다.

PTP는 마스터 클록과 슬레이브 노드가 메시지를 주고받으며 경로 지연을 계산해 시각을 맞추는 방식입니다. 마스터가 Sync 메시지를 보낸 시각을 t1, 슬레이브가 받은 시각을 t2, 슬레이브가 Delay_Req를 보낸 시각을 t3, 마스터가 받은 시각을 t4라 하면 오프셋은 아래 식으로 나옵니다.

$$\text{Offset} = \frac{(t_2 – t_1) – (t_4 – t_3)}{2}$$

이 계산은 상행·하행 경로 지연이 똑같다는 전제를 깔고 있습니다. 실제 이더넷 스위치는 대기열 지터가 있고, 광케이블과 구리 케이블은 물리적으로 비대칭 지연을 갖습니다. IEEE 1588-2019는 이 비대칭성을 수동 또는 자동으로 보정하는 계산 절차를 새로 정의했고, 동기식 이더넷(SyncE)과 협력해 오차를 줄이는 방식도 지원합니다.

여기에 더해 대규모 네트워크를 위한 실무 기능이 함께 들어왔습니다. 서로 다른 PTP 도메인을 완전히 분리하는 프로필 격리(SdoId), 핵심 정보는 멀티캐스트로 뿌리고 개별 지연 측정만 유니캐스트로 처리해 대형 시스템의 트래픽 폭풍을 줄이는 혼합 모드, 자동 클록 선출(BMCA)을 우회해 특정 포트를 강제로 마스터 또는 슬레이브로 고정하는 수동 포트 구성, 그리고 클록 위변조 공격을 막는 인증 TLV(Security TLV)까지, 네 가지가 새로 추가됐습니다.

실무 기준값도 명확합니다. 이 표준은 송신 장치의 패킷 지터를 최대 17 패킷 시간(약 17ms) 이내로 요구하며, 안정적인 상호운용성을 위해서는 1 패킷 시간(1ms) 이내를 권장합니다. 수신 장치는 최소 3 패킷 시간의 재생 버퍼를 확보해야 하고, WAN처럼 QoS가 보장되지 않는 구간에서는 최소 20 패킷 시간(20ms)의 여유 버퍼를 두는 게 원칙입니다. 트래픽 우선순위도 정해져 있습니다. PTP 시간 정보는 가장 높은 등급인 Expedited Forwarding(EF)으로, 오디오 스트림 자체는 Assured Forwarding class 4(AF41)로 태깅해 일반 데이터보다 먼저 처리되도록 합니다.

이 값들이 왜 필요한지 이해하고 나면, 스위치 QoS 설정 화면에서 뭘 봐야 하는지가 비로소 보입니다.

우리도 AES67인데 왜 방송 장비랑 안 붙죠 — 표준 안의 또 다른 표준

이 질문, 방송 시스템 연동 프로젝트마다 꼭 한 번은 나옵니다. 답은 PTP 프로필이 다르기 때문입니다.

AES67은 기본적으로 IEEE 1588-2008 Annex J를 준수하는 범용 미디어 프로필을 쓰고, 기본 도메인 번호는 0입니다. 반면 SMPTE ST 2110 장비는 비디오 동기 신호 전송을 위해 설계된 SMPTE ST 2059-2 프로필을 요구하며, 기본 도메인 번호는 127입니다. 두 프로필의 Sync 전송 주기, Delay Req/Resp 전송 주기 같은 세부 파라미터는 대부분 겹치지만 도메인 번호가 다르기 때문에, 스위치의 Boundary Clock을 두 프로필이 공존하는 하이브리드 방식으로 구성하고 두 진영이 합의한 단일 공통 도메인으로 매핑해야 클록 간섭 없이 붙습니다.

방송 환경에서는 채널 수·지연 요구에 따라 수신 장비가 어떤 등급을 지원하는지도 갈립니다. SMPTE ST 2110-30:2025가 정의한 적합성 등급은 다음과 같습니다.

이 표에서 확인해야 할 것은 하나입니다. 상대 장비가 “AES67 지원”이라고만 적혀 있으면, 그게 1ms Packet Time만 지원하는지 125µs까지 지원하는지는 별도로 확인해야 합니다. 등급을 안 맞추고 붙이면 연결은 되는데 채널이 잘리거나 레이턴시가 튀는 문제가 뒤늦게 나타납니다.

또한 리니어 PCM만 다루는 이 표준·ST 2110-30의 한계를 넘어, 돌비 E 같은 압축 메타데이터가 실린 비선형 AES3 신호를 IP로 보내야 할 때는 SMPTE ST 2110-31 규격을 별도로 씁니다. 이건 ST 2110-30과는 다른 규격이라는 점도 헷갈리지 않아야 합니다.

서버 없이도 표준을 지킨다구요 — 무거운 랙을 버린 단테의 선택

지킬 수 있습니다. 최신 단테 장비라면 이제 DDM(도메인 매니저) 서버 없이도 표준 스트림을 그대로 구성할 수 있습니다 — 다만 이게 가능해진 건 최근입니다. 야외 스포츠 중계나 일회성 재난 대응 무대에서는 서버 랙 한 대 들일 공간도, 시간도 없습니다. 예전엔 그게 문제였습니다. Dante를 AES67이나 ST 2110-30 모드로 쓰려면 도메인 정보와 보안 정책을 총괄하는 단테 도메인 매니저(DDM) 서버가 상시 구동돼야 했습니다. 현장에 서버를 싣고 다니거나, 최소한 온프레미스 서버에 접속할 네트워크가 필요했습니다.

2026년 기준 배포된 단테 컨트롤러(v4.17 이상)와 브루클린 3 펌웨어(v4.3.1.8 이상)에서는 이 전제가 사라졌습니다. DDM 없는 완전 비관리형(Unmanaged) 모드에서도 표준 스트림 구성과 정밀 파라미터 조정을 전적으로 제어할 수 있습니다. 타사 AoIP 표준 장비가 내보낸 SDP 정보를 단테 컨트롤러 라우팅 창에 직접 입력해 패치를 완료할 수 있고, 멀티캐스트 IP 주소 지정 범위도 224.0.0.0~239.255.255.255 전체 대역으로 열렸습니다. RTP 페이로드 ID도 96~127 범위 안에서 자유롭게 지정해 구형 코덱·게이트웨이와 맞출 수 있고, PTPv2 DSCP 태그, Priority 1/2 값, 멀티캐스트 TTL 같은 세부 파라미터까지 컨트롤러에서 직접 오버라이드할 수 있습니다. PTPv2와 구형 PTPv1 단테 도메인이 섞여 있는 경우, 가장 정밀한 노드 하나가 자동으로 경계 클록(Boundary Clock) 역할을 맡아 두 도메인을 가교합니다.

다만 이 기능이 모든 단테 장비에 똑같이 들어가는 건 아닙니다. 현재 전면 지원은 신형 브루클린 3뿐이고, 자일링스 Zynq 7000/US 기반 단테 IP 코어와 DEP·프로 S1은 추후 펌웨어에서 지원 예정이며 DEP·프로 S1은 이 표준 상호운용성만, ST 2110-30 방송 기능은 빠질 예정입니다. 구형 브루클린 II, 브로드웨이, 울티모 시리즈는 로드맵에서 이미 동결됐고, 특히 가장 널리 퍼진 울티모X 칩셋은 AES67 모드에서 샘플레이트 48kHz·인코딩 PCM24로 고정되는 제약이 있어 이 조건을 벗어나는 스트림과는 호환되지 않습니다. 장비 목록에 “AES67 지원”이라고만 적혀 있으면 믿지 말고, 칩셋 세대까지 확인해야 하는 이유입니다.

소리는 갔는데 페이더가 안 움직여요 — 전송과 제어는 다른 문제입니다

오디오는 문제없이 흐르는데 원격 콘솔에서 볼륨 페이더가 안 움직인다는 민원, 낯설지 않으실 겁니다. 이 규격은 오디오를 실시간으로 실어 나르는 전송 표준입니다. 장치를 찾고, 패치를 연결하고, 게인을 조정하고, 프리셋을 불러오는 제어 계층은 완전히 다른 표준의 몫입니다.

2026년 기준 제어 계층의 핵심은 AES70-2024(오픈 컨트롤 아키텍처, OCA)와 AMWA NMOS입니다. AES70-4는 JSON RPC 기반 텍스트 프로토콜로 현재 초안 검토(Call for Comment) 단계에 있어, 정식 발행되면 웹 콘솔이나 마이크로서비스가 별도 해석기 없이 바로 명령을 보낼 수 있게 될 전망입니다. AES70-2024는 기존 이진 프로토콜(AES70-3)의 point-to-point 링크 사양을 확장하고, AES70-2023부터 있던 데이터셋(Dataset) 규격과 결합해 수천 채널 매트릭스 설정을 파일 단위로 일괄 업로드·다운로드할 수 있게 했으며, 여러 장치 상태를 한 번에 구독하는 다중 이벤트 구독(OcaSubscriptionManager)도 새로 추가했습니다.

방송 미디어 센터에서는 AMWA NMOS IS-04(장치 자동 발견·등록)와 IS-05(연결 프로비저닝)를 영상 통제 솔루션과 밀결합해 쓰는 게 일반적인 방향입니다. 다만 독립형 소규모 스튜디오나 콤팩트 음향 솔루션에서는 무거운 NMOS 스택 대신 제조사 경량 API를 쓰는 흐름도 확산되고 있습니다. DHD오디오가 v10.4 펌웨어 기반으로 내놓은 Control API v1.2가 대표적입니다. 별도 NMOS 등록 서버나 Ember+ 게이트웨이 없이, AES67·RAVENNA 버스에 얹은 임베디드 코어 포트로 경량 JSON 패킷을 바로 보내 페이더 게인, 라우팅, GPIO 모니터링까지 처리합니다.

새 시스템을 설계할 때는 “오디오가 나오는가”와 “제어가 되는가”를 항상 별도 항목으로 체크리스트에 넣어야 합니다. 하나가 통과했다고 다른 하나도 통과한 게 아닙니다.

PICS 문서 한 장이 준공 당일을 결정합니다

결정합니다. 제조사가 공개하는 PICS(Protocol Implementation Conformance Statement) 문서 하나면, 그 장비가 표준의 어느 조항(Clause)까지 실제로 구현했는지 시공 전에 항목별로 대조할 수 있습니다. 이 확인을 생략하면 문제가 늦게 드러납니다. 타사 제조사 장비가 AES67 지원을 표기했더라도, Packet Time을 0.25ms 저지연 전용으로만 지원하는지 필수 호환 모드인 1ms까지 지원하는지, 채널 용량 제약이 있는지는 제품마다 다르기 때문입니다.

프로필, Packet Time, 채널 수, PTP 도메인 지원 범위를 PICS 기준으로 사전 대조하면 시공 당일 혼용 배치로 인한 불일치를 미리 걸러낼 수 있습니다. 여기까지 읽으셨다면, 이 표준이라는 이름 하나로 끝나는 시대는 지났다는 것도 느끼셨을 겁니다.

네트워크 설계 단계에서 챙길 항목도 정리해두겠습니다.

• 소스 장비가 순수 AES67인지 ST 2110-30 준수(RTP 클록 오프셋 0)인지 확인했는가
• PTP 프로필(AES67 Annex J vs SMPTE ST 2059-2)과 도메인 번호를 공통으로 매핑했는가
• 상대 장비의 Packet Time·채널 수 등급이 우리 쪽 요구와 맞는가
• Dante 장비라면 칩셋 세대(브루클린 3 vs 구형 울티모 계열)를 확인했는가
• 오디오 전송(AES67/ST 2110-30)과 제어(AES70/NMOS)를 각각 별도로 검증했는가

이 중 하나라도 빠지면, 위상 정렬 왜곡이나 소리 끊김은 준공식 당일에야 드러납니다. 비디오·오디오가 융합된 백본에서는 Layer 2 IGMP Snooping으로 멀티캐스트 오버헤드도 관리해야 하고, 공공 경보·안전 방송처럼 EN 54 같은 안전 규격이 걸린 시스템에서는 네이티브 표준 인증을 받은 하드웨어를 우선 배정하는 게 원칙입니다. 무선 구간까지 오디오 IP가 확장되는 흐름인 만큼, PTPv2.1의 인증 TLV 같은 보안 기능을 설계 초기부터 기본값으로 켜두는 것도 이제는 선택이 아닙니다.

Dante와 AES67 연동에서 실제 현장 담당자가 놓치는 세부 설정은 Dante AES67 연동 전 현장 담당자가 놓치는 5가지 설정에서 더 구체적으로 다뤘습니다. 시간 동기화 표준의 또 다른 축인 Milan 표준 완전 정리 — ProAV 네트워크 현장에서 무엇이 달라졌나도 함께 보시면 AES67·Milan·ST 2110 세 표준이 왜 서로 다른 문제를 풀고 있는지 정리가 됩니다.

자주 묻는 질문

AoIP 연동 프로젝트를 앞둔 담당자님이 설계 초기에 가장 많이 묻는 질문들입니다.

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