저는 이 상황을 다섯 번 겪었습니다.

Dante Controller 화면에서 스트림 연결이 됩니다. 클럭도 잡혔습니다. 오류 메시지도 없습니다. 그런데 오디오 레벨 미터는 0에서 꼼짝을 안 합니다. 처음엔 케이블 문제라고 생각했습니다. 두 번째엔 장비 설정 문제라고 생각했습니다. 세 번째부터는 그냥 인정했습니다. 이게 Dante AES67 연동 특유의 구조적 함정이라는 걸.

이 글에서 다루는 함정은 세 가지입니다. PTP 클럭 도메인 충돌, 멀티캐스트 주소 범위 불일치, DSCP 마킹 충돌. 세 가지 모두 화면에서는 정상으로 보이면서, 오디오만 나오지 않습니다. 그 상황에서 원인을 찾는 데 평균 두 시간이 걸립니다. 이 글을 읽고 나면 그 두 시간을 20분으로 줄일 수 있습니다. 제가 다섯 번 겪고 나서야 정리한 내용입니다.

스트림은 보이는데 소리가 안 납니다 — PTP 클럭이 따로 논다는 게 무슨 뜻인가요

스트림이 연결됐는데 소리만 안 나오는 증상이라면, PTP 버전 충돌이 가장 먼저 의심해야 할 원인입니다. Dante는 PTPv1(IEEE 1588-2002)을 기본으로 사용하고, AES67은 PTPv2(IEEE 1588-2008)를 요구하는데, 두 버전은 같은 네트워크에 있어도 직접 통신이 되지 않습니다. 두 시스템이 각자 독립적으로 클럭 마스터를 선출하고, 오디오 패킷은 타이밍 불일치로 수신 측에서 조용히 버려집니다.

이 증상을 처음 만난 현장은 방송국 스튜디오였습니다. Dante 기반 믹서 콘솔에 타 제조사의 AES67 장치를 연결하는 작업이었습니다. 연결 확인, 스트림 설정, 레벨 확인. 절차대로 했습니다. 소리가 안 나왔습니다. 세 시간 뒤에야 원인을 찾았습니다. 클럭이 서로 다른 버전의 프로토콜을 쓰고 있었습니다.

해결 방법은 AES67이 활성화된 Dante 장치 한 대를 경계 클럭(Boundary Clock)으로 구성하는 겁니다. AES67 활성화 Dante 장치는 외부 PTPv2 클럭을 수신하고, 이를 PTPv1로 변환해 Dante 네트워크 전체에 배포하는 역할을 자동으로 수행합니다. Dante Controller에서 해당 장치를 Preferred Leader(Preferred Clock Master)로 지정하면 됩니다.

경계 클럭 구성에서 가장 자주 빠뜨리는 항목이 있습니다. “Enable Sync to External” 옵션입니다. 믹서 콘솔이 Dante 클럭 마스터 역할을 하는 시스템이라면, Dante Controller의 해당 장치 Device View에서 이 옵션을 반드시 활성화해야 합니다. 이를 빠뜨리면 믹서가 자체 내부 클럭을 고집하면서 경계 클럭과 충돌합니다. 오디오가 한 방향만 나오거나, 재생 중 간헐적으로 끊기는 증상이 나타납니다. 모든 케이블을 뽑고 다시 꽂아봐도 증상이 재현되는 이유가 여기 있습니다.

한 가지 더. 방송 장비 중 일부는 출하 시 기본 PTP 도메인 번호가 0이 아닌 경우가 있습니다. Dante는 도메인 0을 사용하므로, 도메인이 다르면 같은 네트워크에 있어도 서로를 인식하지 못합니다. 연동 전 타사 장비의 PTP 도메인 번호를 사양서에서 미리 확인해두는 게 좋습니다.

주소가 두 자리 달랐을 뿐인데 — 멀티캐스트 함정

Dante Controller에서 스트림 연결이 정상으로 보이는데 소리가 안 나온다면, 멀티캐스트 주소 범위를 먼저 확인하세요. Dante Brooklyn II 계열 수신기가 받을 수 있는 주소 범위는 239.x/16이지만, Q-SYS Core 기본값은 233.254.x.x로 이 범위 밖입니다. 앞 두 옥텟이 달라 패킷이 전달되지 않는 구조이고, 화면에는 아무런 오류 표시가 나타나지 않습니다.

이 함정이 가장 황당한 이유는, Dante Controller에서 모든 게 정상으로 보이기 때문입니다. 스트림이 표시됩니다. 연결 상태도 정상입니다. 오류 메시지도 없습니다. 그런데 소리가 안 납니다. 이 상황을 처음 만났을 때 저는 하드웨어 결함을 의심했습니다. 장비를 교체까지 해봤습니다. 나중에야 멀티캐스트 주소 앞 두 옥텟 차이가 원인이었다는 걸 알았습니다.

AES67은 멀티캐스트 방식으로만 오디오 스트림을 전송합니다. 그런데 제조사마다 기본 멀티캐스트 주소 범위가 다릅니다. Brooklyn II, HC, Broadway 칩셋 기반 Dante 장치는 239.x/16 범위, 즉 239.0.0.0~239.255.255.255만 수신 가능합니다. Q-SYS Core는 AES67 스트림을 기본값 233.254.x.x 범위로 송신합니다.

두 범위는 겹치지 않습니다. Q-SYS Core가 기본값 그대로 233.254.x.x로 스트림을 보내면 Brooklyn II 기반 Dante 장치는 그 스트림을 받지 못합니다. Dante Controller에서는 연결된 것처럼 보이지만 오디오는 전달되지 않습니다.

해결 방법은 간단합니다. Q-SYS Designer에서 AES67 TX 스트림의 멀티캐스트 주소 앞 두 옥텟을 239.69로 변경하면 됩니다. 송신 주소를 239.69.x.x 범위로 맞추는 것만으로 Dante 수신기가 정상적으로 오디오를 받기 시작합니다. 설정 변경 후 Core를 재시작하면 바로 확인할 수 있습니다.

멀티캐스트 주소 범위 문제는 Q-SYS와 Dante 조합에서만 나오는 게 아닙니다. 타사 AES67 장치 중 제조사 자체 기본값을 쓰는 경우라면 동일한 증상이 발생할 수 있습니다. Dante AES67 연동 작업 전에 양쪽 장치의 멀티캐스트 주소 기본값을 사양서에서 확인하는 습관을 들이면 이 함정을 피할 수 있습니다.

AES67이 멀티캐스트만 사용하는 이유도 실용적입니다. 동일한 오디오 스트림을 여러 수신기에 동시에 전달할 때 유니캐스트는 수신기 수만큼 패킷을 복제해야 합니다. 멀티캐스트는 네트워크에 한 번만 보내고 스위치가 분배합니다. 채널 수가 늘어나는 대형 시스템에서 이 차이는 네트워크 부하에 직접 영향을 줍니다. AES67 표준을 규정하는 AIMS Alliance 공식 문서에서도 멀티캐스트 전용 방식의 근거를 확인하실 수 있습니다.

스위치 설정이 절반입니다 — IGMP Snooping과 DSCP 충돌 이야기

AES67이 멀티캐스트를 쓴다면, 네트워크 스위치는 그 멀티캐스트를 제대로 처리해야 합니다. 처리를 못 하면 멀티캐스트 패킷이 네트워크 전체로 flooding됩니다. 스위치에 연결된 모든 장치가 AES67 오디오 패킷을 받게 됩니다. 네트워크가 조용히 마비되기 시작합니다. 오디오가 끊기는 게 아니라 네트워크 전체가 느려지는 방식으로 증상이 납니다.

이를 막는 기능이 IGMP Snooping입니다. 스위치가 멀티캐스트 그룹 멤버십 메시지를 읽어서 해당 스트림이 필요한 포트에만 패킷을 전달합니다. 대부분의 담당자님은 여기까지는 알고 있습니다. IGMP Snooping을 켜야 한다는 것.

그런데 여기서 가장 자주 빠뜨리는 항목이 있습니다. IGMP Querier입니다.

IGMP Snooping은 멀티캐스트 그룹 테이블을 유지합니다. 이 테이블은 주기적으로 갱신되어야 합니다. 갱신을 위해 스위치가 IGMP Query 메시지를 네트워크에 주기적으로 보내야 하는데, 이게 IGMP Querier의 역할입니다. IGMP Snooping을 켜도 Querier를 활성화하지 않으면 그룹 테이블이 시간이 지나면서 소멸합니다. AES67 스트림이 처음엔 잘 나오다가 일정 시간 후 갑자기 끊기는 증상의 주요 원인 중 하나가 바로 이겁니다. IGMP Querier는 네트워크당 한 대의 스위치에서만 활성화해야 합니다. 두 대 이상에서 활성화하면 충돌이 납니다. AES67 표준이 요구하는 IGMP 버전은 IGMPv2(RFC 2236)입니다.

이제 더 복잡한 문제입니다. DSCP 마킹 충돌입니다.

AES67 표준은 PTP 클럭 패킷에 DSCP 46(EF, Expedited Forwarding)을, 오디오 RTP 패킷에는 DSCP 34(AF41, Assured Forwarding)를 사용합니다. 클럭을 최우선으로, 오디오를 그다음으로 처리하는 구조입니다. 그런데 Dante는 오디오 패킷에 DSCP 46을 사용합니다. AES67의 PTP 클럭 패킷과 동일한 값입니다.

두 시스템이 같은 네트워크에 있으면 스위치가 Dante 오디오 패킷과 AES67 PTP 클럭 패킷을 동일한 우선순위 큐로 처리합니다. 트래픽이 몰릴 때 PTP 클럭 패킷이 Dante 오디오와 경쟁하게 됩니다. 클럭 지연이 쌓이면 클럭 정확도가 떨어지고, 오디오 품질이 저하됩니다. 지터나 간헐적 노이즈 형태로 증상이 나타납니다.

가장 확실한 해결 방법은 물리적 분리입니다. Dante 장치들로만 구성된 네트워크와 AES67 장치가 연결된 네트워크를 별도 물리 스위치로 분리합니다. Q-SYS를 사용하는 현장이라면 Designer에서 QoS 프리셋을 “Audinate”로 변경하는 방법으로 일부 완화할 수 있습니다. 네트워크 엔지니어가 있다면 ACL로 트래픽 분류를 구성하는 옵션도 가능합니다.

추가로 두 가지를 반드시 확인해야 합니다. AES67 장치가 연결된 모든 스위치 포트는 1Gbps 링크여야 합니다. 100Mbps 포트에서는 AES67 활성화 장치를 안정적으로 운용할 수 없습니다. 그리고 Energy Efficient Ethernet(EEE, 802.3az)는 반드시 비활성화해야 합니다. 절전 기능이 패킷 처리에 미세한 지연을 만들고, 이 지연이 클럭 동기화에 영향을 줍니다.

Dante AES67 연동 전에 칩셋부터 확인하세요 — UltimoX 함정과 샘플레이트 제한

AES67 모드를 활성화하려고 Dante Controller를 열었는데 AES67 탭이 없는 경우가 있습니다. 두 가지 원인 중 하나입니다.

첫 번째는 DDM(Dante Domain Manager) 환경입니다. 장치가 DDM 도메인에 등록되어 있으면 Dante Controller의 AES67 탭이 자동으로 비활성화됩니다. 이 경우 AES67 설정은 DDM 웹 인터페이스에서만 가능합니다. Domain Details → Advanced Settings 경로로 들어가야 합니다. DDM 환경에서 AES67 도메인은 전체 시스템에서 단 한 개만 생성 가능하며, PTP 도메인 번호 0으로 고정됩니다.

두 번째는 칩셋 문제입니다. Dante 칩셋에는 종류가 있습니다. Brooklyn II, Broadway, HC 칩셋은 AES67을 완전 지원합니다. 하지만 UltimoX 칩셋 기반 장치는 다릅니다. UltimoX 장치는 DDM에 AES67 도메인으로 등록은 되지만, 실제 AES67 오디오 스트림을 주고받지 못합니다. “장치는 보이는데 오디오가 안 난다”는 증상이 나온다면 칩셋을 먼저 확인해야 합니다. Dante Controller Device View에서 장치 정보를 열면 칩셋 종류를 확인할 수 있습니다.

칩셋을 확인했다면 펌웨어 버전도 확인해야 합니다. Brooklyn II 기준 v3.9.x 이상, Broadway와 HC는 v4.2.x 이상이 필요합니다. 이전 버전에서는 AES67 모드가 불안정하거나 지원이 안 됩니다. 그리고 AES67 모드를 활성화한 이후에는 반드시 장치를 리부팅해야 합니다. 설정 변경 후 재시작하지 않으면 적용되지 않습니다. 이걸 빠뜨리고 몇 분 동안 원인을 찾는 일이 실제로 자주 있습니다.

마지막으로 샘플레이트입니다. AES67 표준의 의무 샘플레이트는 48kHz 하나입니다. Dante의 AES67 구현도 48kHz만 지원합니다. AES67 모드를 활성화하면 해당 장치의 샘플레이트는 48kHz로 고정되고, 이후 변경이 불가능합니다.

방송 시설에서는 이 제한이 중요합니다. 방송 편집 워크플로가 44.1kHz로 운용 중이라면 AES67 연동 자체가 불가능합니다. Pull-down 샘플레이트(47.952kHz)도 지원하지 않으므로, 방송 규격 29.97fps 기반 시설에서는 AES67 도입 전 전체 시스템 샘플레이트 전환 계획을 먼저 세워야 합니다. 이미 구축된 시스템에서 48kHz로 전환하는 작업이 예상보다 범위가 넓어지는 경우가 많습니다.

패킷 타임도 확인 대상입니다. AES67 표준의 의무 레이턴시 값은 1ms입니다. 타사 AES67 장치가 4ms를 기본값으로 사용하는 경우, 레이턴시 불일치로 오디오 품질이 저하됩니다. 연동하는 양쪽 장치 모두 패킷 타임을 1ms로 맞추는 것이 권장됩니다. 단일 홉·최소 네트워크 지연이라는 이상적 조건에서 총 시스템 레이턴시는 아날로그 I/O 변환 포함 시 약 3.167ms 수준입니다. 그러나 이는 실험실 기준 수치이며, 실제 현장에서는 홉 수 증가·스위치 처리 지연·PTP 재동기화 등의 조건이 더해져 5~8ms 수준을 기준으로 설계 여유를 확보하는 것이 적절합니다. 이 수치를 과소평가하면 레이턴시 민감 구간에서 예상치 못한 품질 저하가 발생할 수 있습니다.

이 순서대로 확인하면 두 시간이 20분이 됩니다

저는 지금 Dante AES67 연동 작업이 들어오면 현장에 가기 전에 이 순서를 먼저 정리합니다. 작업 중에 원인을 찾는 게 아니라, 원인이 될 수 있는 항목을 미리 차단하는 방식입니다.

장비 단 확인 (연동 전)

• 각 Dante 장치 칩셋 확인 → UltimoX이면 교체 또는 외부 브릿지 필요
• 펌웨어 버전 확인 → Brooklyn II v3.9.x+, Broadway/HC v4.2.x+
• DDM 사용 여부 확인 → DDM 환경이라면 DDM 웹 인터페이스에서 AES67 활성화
• AES67 모드 활성화 → Dante Controller AES67 Config 탭 → Enabled → 리부팅 필수
• 시스템 샘플레이트 전체 확인 → 48kHz로 통일, pull-down 불가 확인

클럭 동기화 (PTP 설정)

• AES67 활성화 Dante 장치를 Preferred Leader로 지정
• 믹서/콘솔이 클럭 마스터라면 “Enable Sync to External” 활성화
• 타사 장비 PTP 도메인 번호 사양서 확인 → 도메인 0으로 통일
• 패킷 타임 양쪽 장치 모두 1ms로 통일

멀티캐스트 주소 확인

• Dante 수신기 칩셋의 수신 가능 멀티캐스트 범위 확인 (Brooklyn II 계열: 239.x/16)
• Q-SYS 사용 시 AES67 TX 주소 앞 두 옥텟 → 239.69로 변경
• 타사 장비 기본 멀티캐스트 주소 사양서 확인

네트워크 스위치 설정

• 모든 AES67 연결 포트 1Gbps 확인
• Energy Efficient Ethernet(EEE, 802.3az) 비활성화
• IGMP Snooping 활성화 + IGMP Querier 동시 활성화 (네트워크당 1대)
• DSCP 설정 확인 → Dante와 AES67 혼용 시 물리적 분리 또는 ACL 구성 권장

이 목록을 연동 전에 한 번 훑으면, 시운전 당일 원인 불명의 두 시간을 상당 부분 줄일 수 있습니다. 제가 현장에서 배운 건 결국 이겁니다. Dante AES67 연동에서 문제가 날 때 원인은 거의 항상 이 목록 안에 있습니다. 케이블을 의심하기 전에 이 순서를 먼저 확인하는 습관이 가장 빠른 지름길입니다.

AES67과 관련된 현장 사례와 네트워크 AV 설계 이슈는 컨설팅 인사이트에서 더 읽으실 수 있습니다. AoIP 네트워크 기초와 Dante 설계 원칙은 AV 기초 지식에서 확인하실 수 있습니다.

자주 묻는 질문

Dante AES67 연동 작업에서 현장 담당자님이 가장 자주 보내오는 질문들을 정리했습니다.

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