AES67이란 무엇인가요?

정의와 개정 배경

AES67의 공식 명칭은 '네트워크의 오디오 애플리케이션을 위한 AES 표준 - 고성능 스트리밍 IP 오디오 상호 운용성'입니다. AES(Audio Engineering Society)는 2013년 제1판을 발행했고, 산업계 경험을 통해 보다 명확한 정리가 필요한 모호성과 통합 세부 사항이 드러나자 AES67-2018 개정판을 발행했습니다.

이 표준은 하나의 닫힌 생태계를 만들지 않습니다. 각 제품이 요구되는 프로파일을 구현하고 시스템 통합자가 공유 네트워크를 올바르게 구성할 때, 서로 다른 벤더의 제품들이 실시간 오디오를 주고받을 수 있는 기술적 접점을 정의합니다. 따라서 표준 준수는 출발점일 뿐, 모든 선택 기능이나 관리 기능이 자동으로 동작한다는 약속이 아닙니다.

조달과 설계 업무에서는 사용 중인 판본을 명시하고 제조사의 적합성 선언을 확인해야 합니다. AES67-2018은 현행 조달 문서 대부분이 참조하는 개정판이지만, 사양을 확정하기 전에 AES 표준 카탈로그에서 수정안, 정오표, 이후 판본이 있는지 다시 확인하는 것이 좋습니다.

표준은 선택된 계층에서의 상호 운용성을 정의합니다. 사용자에게 보이는 모든 운영 동작을 표준화하지는 않습니다.

AES67이 해결하는 상호 운용성 문제

AES67 이전에는 각 IP 오디오 플랫폼이 비슷한 문제를 저마다의 방식으로 해결했습니다. Dante 네트워크, RAVENNA 네트워크, Livewire 시스템, Q-LAN 설비는 자기 제품군 안에서는 훌륭한 실시간 오디오를 제공할 수 있었지만, 벤더 간 직접 라우팅에는 흔히 브리지, 변환 하드웨어 또는 수작업 우회가 필요했습니다.

이러한 단편화는 상업적·운영적 리스크를 만들었습니다. 시설은 라우팅, 클럭, 제어, 지원을 하나의 생태계에 의존하게 될 수 있었고, 시스템 확장은 음향, 워크플로, 가격을 평가하기도 전에 프로토콜 호환성부터 확인해야 했습니다. 새 플랫폼이 도입되면 기존 장비는 유지하기가 더 어려워졌습니다.

AES67은 오디오 전송을 위한 공통 상호 운용 경로를 정의하여 이 문제에 대응합니다. 네이티브 생태계가 선택한 스트림을 다른 AES67 지원 생태계가 수신할 수 있는 형태로 노출할 수 있게 하는 것입니다. 그래서 AES67은 흔히 브리지에 비유됩니다. 플랫폼 간 차이를 지우지는 않지만, 플랫폼 사이의 통제된 이동을 가능하게 합니다.

IP 오디오 기본 개념

AoIP 시스템은 샘플링된 오디오를 타임스탬프가 붙은 패킷으로 변환하고, 그 패킷을 이더넷과 IP 인프라로 전송한 뒤, 수신 측에서 연속적인 오디오 신호를 재구성합니다. 어려운 부분은 데이터를 옮기는 것이 아니라, 다른 트래픽과 패킷 네트워크를 공유하면서도 샘플 타이밍, 채널 관계, 재생 연속성을 유지하는 것입니다.

AES67은 실시간 미디어를 일반 데이터와 분리할 수 있는 관리형 네트워크를 전제로 합니다. 스위치는 충분한 버퍼링, 멀티캐스트 제어, 트래픽 우선순위 지정을 갖추어야 합니다. 라우터는 설계가 멀티캐스트 라우팅이나 유니캐스트 흐름을 지원할 때 서브넷 간에 스트림을 전달할 수 있지만, 모든 경계는 구성과 모니터링 요구 사항을 추가합니다.

미디어 클럭은 패킷 클럭과 별개입니다. PTP는 장치 시간을 정렬하고, 오디오 샘플레이트가 미디어 클럭을 정의합니다. 수신기는 올바른 샘플링 위상과 안정적인 샘플 스트림을 모두 복원해야 합니다. 패킷 손실, 과도한 지터, 불안정한 클럭은 평균 네트워크 대역폭이 충분하더라도 오디오 끊김을 일으킬 수 있습니다.

네트워크 설계를 단순한 지원 인프라가 아니라 오디오 시스템의 일부로 다뤄야 합니다. VLAN, QoS, PTP 도메인, 멀티캐스트 쿼리어, 스위치 버퍼링 정책은 함께 검증되어야 합니다. 중요한 프로그램 경로에서는 장애 시 저하 모드, 알람 경로, 복구 시간도 정의해야 합니다.

• 샘플링은 아날로그 오디오를 정해진 레이트의 이산적 숫자 값으로 변환합니다.
• 패킷화는 수신기가 스트림을 재구성할 수 있도록 순서 번호, 타임스탬프, 페이로드 정보를 추가합니다.
• 버퍼링은 정상적인 네트워크 변동을 흡수하지만 엔드투엔드 레이턴시를 늘립니다.
• 동기화는 독립적인 장치들을 하나의 공유 시간 기준에 정렬된 상태로 유지합니다.

PTPv2, RTP, SDP

AES67은 IEEE 1588-2008 정밀 시간 프로토콜, 흔히 부르는 PTPv2를 사용해 공통 시간 기준을 분배합니다. PTP 메시지를 통해 장치들은 타임스탬프를 비교하고 네트워크 지연을 보정할 수 있습니다. 오디오 시스템에서 이렇게 얻은 시간 기준은 송신자와 수신자가 국부 발진기 주파수에만 의존하지 않고 샘플을 공유 타임라인 위에 배치할 수 있게 합니다.

RFC 3550에 정의된 실시간 전송 프로토콜(RTP)이 오디오 페이로드를 운반합니다. RTP는 순서 번호와 타임스탬프를 제공하여 수신기가 유실되었거나 순서가 바뀐 패킷을 감지하고 의도된 재생 시점을 재구성할 수 있게 합니다. RTCP(RTP Control Protocol)는 수신 통계를 제공할 수 있지만, 제어와 모니터링 방식은 제품마다 다릅니다.

세션 기술 프로토콜(SDP)은 스트림이 수신되기 전에 그 내용을 기술합니다. SDP 문서는 미디어 유형, 주소, 포트, 페이로드 형식, 패킷 타임, 채널 매핑 등의 매개변수를 식별합니다. 시스템에 따라 SDP를 직접 교환하기도 하고, 검색 또는 관리 계층이 전달하기도 합니다. AES67은 범용 장치 제어 프로토콜을 하나로 정의하지 않기 때문에 SDP 처리 방식은 구현마다 다를 수 있습니다.

PTP, RTP, SDP는 AES67이 사용하는 표준입니다. 선택적인 마케팅 라벨이 아닙니다.

QoS, PCM, 멀티캐스트 동작

AES67은 리니어 PCM 오디오를 사용하여 수신기가 상호 운용을 위해 독점 코덱을 필요로 하지 않게 합니다. 공통 페이로드 형식은 16비트와 24비트 PCM이며, L16, L24 같은 RTP 페이로드 타입으로 표기되는 경우가 많습니다. 송신자와 수신자는 샘플레이트, 패킷 타임, 페이로드 타입, 채널 수, 채널 순서에 대해 합의해야 합니다.

QoS가 중요한 이유는 오디오 패킷이 지연에는 민감하지만 대역폭이 반드시 크지는 않기 때문입니다. DSCP 마킹과 큐 처리는 PTP 및 RTP 트래픽에 파일 전송, 백업, 일반 사무 데이터보다 높은 우선순위를 부여합니다. VLAN은 미디어 트래픽 분리에 도움이 되지만, VLAN 분리만으로는 적절한 큐 설계와 모니터링을 대체할 수 없습니다.

멀티캐스트는 하나의 송신자가 모든 엔드포인트로 트래픽을 복제하지 않고도 여러 수신자에게 스트림을 분배할 수 있게 합니다. 동시에 리스크도 있습니다. 잘못 구성된 IGMP 스누핑, 쿼리어 부재, 우발적 플러딩은 네트워크 전체를 마비시킬 수 있습니다. 대규모 구축에서는 커미셔닝 전에 멀티캐스트 주소 범위, 쿼리어 배치, 그룹 제한, PTP 도메인을 계획해야 합니다.

가동 개시 후에는 패킷 손실, 지터, PTP 오프셋, IGMP 상태, 스위치 큐를 지속적으로 관찰해야 합니다. 많은 상호 운용 문제는 완전한 무음이 아니라 간헐적 끊김, 좌우 채널 뒤바뀜, 재시작 후 복구 실패, 높은 부하에서만 나타나는 이상 현상으로 드러납니다. 관측 가능성은 오디오 경로와 함께 설계되어야 합니다.

• 미디어 트래픽을 위한 용량과 큐 예산을 확보합니다.
• 문서화된 멀티캐스트 주소 계획을 사용합니다.
• 모든 스위치에서 PTP 도메인과 우선순위 설정을 확인합니다.
• 구축 후에는 패킷 손실, 지터, 클럭 오프셋, IGMP 상태를 모니터링합니다.

AES67이 정의하지 않는 것

AES67은 자동 장치 검색 체계를 하나로 규정하지 않습니다. SAP 애넌스를 사용하는 제품도 있고, mDNS나 Bonjour를 사용하는 제품, 네이티브 컨트롤러나 서드파티 오케스트레이션 도구에 의존하는 제품도 있습니다. 장치가 AES67을 지원하더라도 연결을 설정하는 데 수동 SDP 교환이나 벤더 소프트웨어가 필요할 수 있습니다.

또한 범용 연결 관리 모델, 필수 사용자 인터페이스, 완전한 보안 아키텍처도 정의하지 않습니다. 라우팅 권한, 명명 규칙, 펌웨어 업데이트, 접근 제어, 모니터링 API는 제품별 사항으로 남습니다. 그래서 오디오 전송 위에 있는 컨트롤러나 관리 계층이 엔드포인트를 조율할 때 AES67 상호 운용이 가장 잘 작동하는 경우가 많습니다.

이중화도 중요한 경계입니다. AES67은 스트리밍과 동기화 계층을 정의할 뿐, 심리스 패킷 복제나 전환을 정의하지는 않습니다. 무순단 이중화가 필요한 시스템은 흔히 주변 아키텍처의 네트워크 이중화 방식, 예컨대 미디어 보호 기법을 결합한 이중 링크를 추가하며, 정확한 동작은 제품과 네트워크 설계에 따라 달라집니다.

마지막으로, AES67은 데이터시트에 배지가 있다는 이유만으로 상호 운용성을 보장하지 않습니다. 구현은 여전히 호환 가능한 매개변수를 협상하고, 필요한 페이로드 형식을 지원하며, 예상되는 PTP 및 네트워크 조건에서 올바르게 동작해야 합니다.

Dante, RAVENNA와 AES67 상호 운용

Dante는 Audinate의 독점 오디오 네트워킹 기술입니다. Dante의 AES67 상호 운용은 일반적으로 선택된 Dante 플로우가 다른 AES67 장치와 오디오를 주고받을 수 있게 하는 모드나 구성으로 나타납니다. 네이티브 Dante 검색, 라우팅, 제어, 관리는 Dante 생태계의 일부로 남기 때문에, AES67 연결은 여전히 Dante Controller나 다른 Audinate 도구를 필요로 하는 제어 플레인과 공존할 수 있습니다.

RAVENNA는 표준 IP 프로토콜을 기반으로 구축된 개방형 기술 플랫폼으로, AES67 및 SMPTE ST 2110-30과 강하게 정렬되어 있습니다. 최소한의 AES67 상호 운용 계약을 넘어 추가 프로파일, 형식, 채널 수, 동기화 옵션, 이중화 모델을 운반할 수 있습니다. 따라서 AES67은 더 넓은 RAVENNA 구축 안의 공통 계층이지, 모든 RAVENNA 기능을 완전히 설명하는 것이 아닙니다.

하이브리드 설계는 흔합니다. 시설은 스테이지 박스, 앰프, 콘솔을 위해 네이티브 Dante 자산을 유지하면서, 방송 코어나 RAVENNA 제작 시스템, 특정 서드파티 프로세서는 AES67으로 연결할 수 있습니다. 통합 계획에는 어떤 엔드포인트가 네이티브이고 어떤 것이 상호 운용 모드인지, SDP가 어디서 교환되는지, 클럭과 멀티캐스트 정책을 누가 소유하는지 명시해야 합니다.

가장 취약한 부분은 오디오를 보낼 수 있는지 여부가 아니라 경계가 어떻게 유지되는지인 경우가 많습니다. 펌웨어 업그레이드, 장치 재시작, 클럭 마스터 전환, 네트워크 장애 이후에 양측이 다시 연결되는지, 알람이 한곳에 도착하는지, 명확한 유지보수 절차가 있는지는 모두 프로젝트 초기에 정의되어야 합니다.

상호 운용 모드는 시스템 설계 선택입니다. 네이티브 기능 차이를 지우지는 않습니다.

구축 지침

문서화된 신호 및 클럭 계획에서 시작하십시오. 모든 스트림과 그 방향, 샘플레이트, 패킷 타임, 채널 수, 멀티캐스트 그룹, 소스 주소, 수신자, 대체 경로를 나열하십시오. 트래픽 등급마다 네트워크가 유니캐스트를 쓸지 멀티캐스트를 쓸지 결정하고, SDP가 어떻게 전달되고 저장되는지 정의하십시오.

엔드포인트를 추가하기 전에 PTP 도메인 계획을 수립하십시오. 어떤 장치가 그랜드마스터가 될 수 있는지, boundary clock과 transparent clock이 어떻게 처리되는지, 선호하는 그랜드마스터가 사라지면 어떻게 되는지, 네트워크에 안정적인 홀드오버 전략이 있는지 확인하십시오. PTP 성능은 실제 운영에서 예상되는 것과 동일한 스위치 구성과 트래픽 부하로 테스트해야 합니다.

그다음으로 상호 운용성을 제품 시연이 아니라 시스템 차원에서 테스트하십시오. 채널 매핑, 공칭 게인, 샘플 정렬, 링크 장애 후 스트림 복구, 멀티캐스트 조인과 리브 동작, 관리 가시성을 확인하십시오. 펌웨어 불일치, 그랜드마스터 재부팅, 수신기 분리, 혼잡한 업링크 같은 극단 사례도 포함해야 합니다.

커미셔닝은 지속 가능한 증거를 남겨야 합니다. 스위치 구성, PTP 로그, 스트림 기록, 테스트 결과, 향후 변경에 대한 소유권입니다. AES67은 전송 계약을 단순화하지만 전문적인 네트워크 원칙의 필요를 없애지는 않습니다.

SoundNet AES67 모듈 솔루션

표준을 이해하는 것과 제품이 안정적으로 AES67을 구동하는 것은 별개의 일입니다. SoundNet의 YW 시리즈 OEM 모듈은 PTPv2 클로킹, RTP 오디오 전송, 장치 디스커버리를 포함해 실제 양산으로 검증된 완전한 AES67 구현을 임베디드 하드웨어에 담았습니다. 프로페셔널 오디오 제조사는 프로토콜 스택을 처음부터 개발하지 않고도 자사 제품에 네트워크 오디오 기능을 더할 수 있습니다. 라인업은 컴팩트한 4×4 YW04d부터 48/96/192 kHz에서 최대 128×128 채널을 지원하는 YWRG128 Mini-PCI 모듈까지 확장됩니다.

모듈을 둘러싼 것은 전체 워크플로를 아우르는 툴체인입니다. 라이선스가 필요 없는 AES67 LINK Controller가 라우팅과 설정을 맡고, AES67 Virtual Soundcard는 PC를 64×64 엔드포인트로 바꾸며, PoE 방식의 AES67 Panel이 룸 컨트롤을 담당하고, 오픈소스 Stream Monitor가 실제 네트워크에서 멀티캐스트 스트림을 점검합니다.

• 모듈에 내장된 완전한 AES67 스택: 동기화, 전송, 디스커버리를 모듈이 처리하므로 펌웨어 팀의 부담이 아닙니다
• I2S/TDM 인터페이스로 4×4에서 128×128 채널, 48/96/192 kHz 지원
• 선택 가능한 온보드 DSP: 파라메트릭 EQ, 필터, 딜레이, 노이즈 게이트, 하울링 억제 내장
• 소형 엔드포인트부터 고밀도 전송까지 제품군 전체를 한 번의 통합 작업으로 아울러
• 완제품을 위한 툴체인: LINK Controller, VSC, Panel, Stream Monitor가 설정·라우팅·모니터링을 담당

적용 분야와 흔한 오해

AES67은 방송국, 예배 시설, 컨퍼런스 센터, 경기장, 공연장, 녹음 스튜디오, 대형 캠퍼스 설비에서 사용됩니다. 여러 벤더의 장비가 오디오를 공유해야 하거나, 기존 AoIP 자산을 새 제작 코어에 연결해야 하거나, 장기 유지보수성을 위해 표준 기반 전송이 필요한 환경에서 특히 유용합니다.

한 가지 오해는 AES67을 지원하면 모든 AES67 장치를 같은 방식으로 제어할 수 있다고 생각하는 것입니다. 실제로는 오디오가 흐르는 동안에도 검색, 라우팅, 라벨, 모니터링은 분리되어 있을 수 있습니다. 또 다른 오해는 AES67을 품질 등급이나 코덱으로 보는 것입니다. AES67은 상호 운용 프레임워크이며, 오디오 품질은 소스, 샘플 형식, 클럭, 네트워크 동작에 달려 있습니다.

세 번째 오해는 AES67과 ST 2110-30을 같은 표준의 바꿔 쓸 수 있는 이름으로 보는 것입니다. 두 표준은 밀접하지만, AES67은 AES의 오디오 상호 운용 표준이고 ST 2110-30은 SMPTE의 더 포괄적인 프로페셔널 미디어 오버 IP 제품군 중 제약이 있는 오디오 구성 요소입니다. 일부 기술 문서는 제품군을 지칭할 때 공백 없이 ST2110이라고 표기합니다. 이 구분은 방송 워크플로, NMOS 제어, PTP 프로파일, 적합성 레벨을 명시할 때 중요합니다.

마지막으로, AES67은 모든 호환성 문제를 자동으로 해결하는 버튼이 아닙니다. 제품 지원 범위, 사용 가능한 옵션, 라이선스, 펌웨어 상태, 네트워크 설계, 운영 절차가 모두 결과에 영향을 줍니다. 경계를 명확히 문서화하고 엔드투엔드 인수 테스트를 수행하는 것이 배지나 마케팅 주장에 의존하는 것보다 신뢰할 수 있습니다.