지난달, 준공검사 서류에 서명하려던 시설 담당자님 손이 멈췄습니다. 서명 직전, 무대 조명이 이유 없이 두 번 깜빡였기 때문입니다. “이거 원래 이런 거예요?” 저도 처음엔 케이블 문제라고 생각했습니다. 그런데 원인은 케이블이 아니라 네트워크 스위치의 설정 하나였습니다.

DMX512 아날로그 배선을 이더넷 기반 ArtNet 조명 네트워크와 sACN으로 바꾸는 공연장·컨벤션센터가 빠르게 늘고 있습니다. 배선은 단순해지지만, 발주처가 확인해야 할 항목은 오히려 늘어납니다. 케이블 한 가닥이 아니라 스위치 설정, 프로토콜 선택, 무선 대역까지 봐야 하기 때문입니다.

이 글을 읽고 나면 시공사·감리단에 무엇을 물어봐야 하는지가 구체적으로 보입니다. “네트워크 설계 잘 됐죠?”라는 막연한 질문 대신, “IGMP Querier는 어디 있습니까”, “EEE는 껐습니까” 같은 정확한 질문을 던질 수 있게 됩니다.

ArtNet 조명 네트워크로 가기 전, DMX512는 왜 한계에 부딪혔나요

한 줄로 답하면, 512채널이라는 물리적 상한 때문입니다. 무빙라이트 한 대가 수십 채널을 쓰는 요즘 조명 설계에서는 이 상한이 배선 가닥 수를 기하급수적으로 늘립니다.

ESTA(Entertainment Services and Technology Association)가 관리하는 DMX512(ANSI E1.11)는 초당 25만 비트(250kbps) 속도로 신호를 보내는 단방향 프로토콜입니다. 한 가닥의 물리 라인이 담을 수 있는 채널은 512개, 즉 1유니버스뿐입니다. 조명기구 한 대가 색상·팬·틸트·줌·스트로브까지 수십 개 파라미터를 쓰는 지금은, 웬만한 중형 공연장도 유니버스 여러 개를 배선해야 합니다. 유니버스가 늘어날수록 콘솔에서 무대까지 뻗어나가는 케이블 다발도 그만큼 늘어납니다.

더 큰 문제는 진단입니다. DMX512는 신호를 보내기만 할 뿐, 조명기구가 잘 받았는지 되묻지 못합니다. 램프가 나가거나 팬이 멈춰도 콘솔 화면에는 아무 이상 신호가 뜨지 않습니다. 무대 위에서 조명이 꺼진 다음에야 알게 되는 구조입니다.

이더넷 기반 전환은 이 두 문제를 동시에 풉니다. Cat5e/6 케이블 한 가닥으로 수만 유니버스를 실어 나를 수 있고, 배선에 들어가는 구리 소요량도 기존 대비 80~90%까지 줄어듭니다. 여기에 양방향 진단(RDM)까지 얹으면, 램프 수명이나 팬 오작동을 콘솔에서 미리 확인할 수 있습니다. 다만 이 이점은 설계가 제대로 됐을 때 이야기이고, 그 설계의 첫 갈림길이 다음 질문입니다.

Art-Net과 sACN, 뭘 골라야 하나요

정답부터 말하면 “둘 중 하나만”이 아니라 “둘을 어떻게 같이 쓸 것인가”가 실제 설계 질문입니다. 두 프로토콜은 데이터를 뿌리는 방식 자체가 다릅니다.

Art-Net은 사실상의 업계 표준으로, 유니캐스트와 브로드캐스트 방식을 씁니다. 스위치에 물린 모든 장치에게 신호를 뿌리는 방식이라 설정 없이도 바로 동작합니다. 최대 32,768 유니버스를 지원하고, 조명기구 상태를 원격 진단하는 RDM 기능을 프로토콜 안에 기본 내장하고 있어 플러그 앤 플레이가 빠릅니다. 반면 유니버스 수가 늘어나면 불필요한 패킷이 모든 단말로 흘러가면서 하드웨어 부하가 커지는 구조적 약점이 있습니다.

sACN(ANSI E1.31)은 ANSI/ESTA 공식 인증 표준으로, 멀티캐스트가 기본입니다. 유니버스마다 개별 멀티캐스트 주소가 매핑돼, 그 유니버스를 구독한 노드에만 패킷이 도달합니다. 최대 유니버스 수는 63,999~65,535로 Art-Net보다 넉넉하고, 패킷 단위 우선순위(0~200)를 지정할 수 있어 콘솔 두 대가 동시에 신호를 보내는 상황도 정리할 수 있습니다. 대신 멀티캐스트가 제대로 걸러지려면 스위치가 IGMP를 지원하는 관리형 장비여야 합니다 — 이 조건을 빠뜨리면 Art-Net보다 오히려 더 불안정해질 수 있습니다.

두 프로토콜의 성능 차이를 표로 정리하면 다음과 같습니다.

이 표만 보면 “sACN이 더 우수하다”고 결론짓기 쉽습니다. 그런데 현장에서는 진단 편의성 때문에 Art-Net을 완전히 버리지 못하는 경우가 많습니다. 그래서 다음 질문이 나옵니다.

두 프로토콜을 같이 쓴다고요? 현장에서는 이게 답입니다

네, 실제로 많은 최신 설계가 두 프로토콜을 동시에 병행합니다. 페이드·무빙 제어처럼 타이밍이 예민한 트래픽은 sACN 멀티캐스트로, 기구 상태 진단은 Art-Net의 RDM으로 나눠 보내는 방식입니다.

무대 씬 전환, 페이드 명령처럼 지연이 곧바로 눈에 보이는 제어는 sACN의 멀티캐스트 경로로 보내 대역폭 안정성을 확보합니다. 반대로 조명기구의 온도, 램프 사용 시간, 팬 오작동 여부를 폴링하고 어드레스를 재배정하는 업무는 양방향 RDM이 내장된 Art-Net 레이어로 상시 병행합니다. 최신 노드 컨버터들은 펌웨어 단에서 두 신호를 동시에 모니터링해 HTP(Highest Takes Precedence) 또는 LTP(Latest Takes Precedence) 방식으로 병합하거나, 포트 단위로 수용 프로토콜을 나눠 처리합니다.

발주처가 설계 도서 검토 단계에서 확인해야 할 것은 딱 하나입니다. “이 노드가 두 프로토콜을 동시에 병행 처리한다”는 문구가 사양서에 명문화돼 있는지입니다. 이게 빠지면 나중에 “우리는 Art-Net만 지원합니다”라는 답을 준공 시점에 듣게 됩니다.

프로토콜 설계가 끝났다고 안심하기는 이릅니다. 이더넷 신호는 게이트웨이 노드를 거쳐 결국 물리 DMX 케이블로 조명기구까지 이어지는데, 이 마지막 구간에서 사고가 가장 자주 납니다.

오디오 케이블로 조명을 배선했다가 벌어진 일

결론부터 말하면, DMX 전용 케이블과 일반 XLR 오디오 케이블은 겉모습만 같을 뿐 전기적으로 완전히 다른 물건입니다. 이 둘을 혼용하면 조명기구가 무대 기계 기동 시점에 맞춰 제멋대로 오작동합니다.

DMX512는 초당 25만 번 이상 전송되는 고주파 디지털 사각파 신호입니다. 이 신호가 정상적으로 통신되려면 케이블과 수신단의 특성 임피던스가 110~120Ω 범위 안에서 정확히 맞아야 합니다. 그런데 일반 XLR 오디오 케이블의 임피던스는 대략 45~75Ω 수준으로, DMX 규격보다 한참 낮습니다. 겉으로는 똑같은 3핀 또는 5핀 커넥터라 시공 현장에서 혼용하는 실수가 실제로 자주 일어납니다.

임피던스가 안 맞는 케이블에 조명 데이터를 흘리면, 신호가 케이블 단락부와 수신 회로 접점에서 반사파(signal reflection)를 만듭니다. 반사파는 디지털 파형을 무너뜨려 비트 에러를 누적시킵니다. 겉보기엔 멀쩡하게 켜져 있던 조명기구가 무대 기계가 움직이는 순간 갑자기 멈추거나, 디밍 제어 중 불규칙하게 요동치는 증상이 바로 이 반사파 때문입니다.

이 문제를 막으려면 발주처가 시공 단계에서 세 가지를 직접 확인해야 합니다. 첫째, 데이지 체인의 마지막 조명기구 출력단에 120Ω 종단 저항(터미네이터)이 물려 있는지입니다. 이게 빠지면 반사된 신호가 체인 전체로 역류합니다. 둘째, 이더넷-DMX 게이트웨이 노드의 출력 포트가 갈바닉·광절연 처리된 제품인지입니다. 무대 철골 구조물과 조명 리깅에서 발생하는 접지 전위차가 데이터 라인으로 유입되는 걸 막아줍니다. 셋째, 무대 상부에 거치되는 장비는 Neutrik PowerCon과 EtherCon처럼 래칭 잠금 방식 커넥터를 쓰는지입니다. 진동이 잦은 위치에서 일반 커넥터는 빠질 위험이 있습니다.

물리 배선이 정리됐다면, 이제 그 위에 얹히는 백본 네트워크가 정전 한 번, 케이블 하나 끊김에도 버틸 수 있는지를 봐야 합니다.

케이블 하나 끊었는데 무대가 안 꺼졌다면, 설계가 된 겁니다

이중화 설계가 제대로 됐는지 확인하는 가장 확실한 방법은, 실제로 케이블을 하나 뽑아보는 것입니다. 조명이 끊기지 않고 그대로 유지되면 설계가 통과한 것이고, 한 순간이라도 블랙아웃이 생기면 재설계가 필요합니다.

공연장 조명 네트워크는 패킷 하나만 드롭돼도 무대 전체 연출이 멈출 수 있는 실시간 환경입니다. 그래서 백본은 코어-분배-액세스 3계층 이중화(대형 공연장) 또는 코어를 압축한 2계층 collapsed core 구성(중형 공연장)으로 설계하고, 모든 물리 장비를 2대씩 배치해 한쪽이 죽어도 즉시 우회 경로로 넘어가게 합니다.

이 이중화를 논리적으로 묶어주는 게 LACP(Link Aggregation Control Protocol)입니다. 여기서 발주처가 놓치기 쉬운 함정이 하나 있습니다. 스위치 양단이 모두 LACPDU를 기다리기만 하는 ‘Passive’ 모드로 설정되면, 논리 채널 자체가 아예 생성되지 않습니다. 최소 한쪽은 ‘Active’ 모드로 먼저 신호를 보내야 합니다. 또한 미디어 서버가 OS 부팅 전 네트워크로 펌웨어를 받아오는 PXE 부팅 구간에서는 LACP 알고리즘을 아직 해석하지 못해 포트가 일시적으로 막힐 수 있습니다. 이 구간을 대비해 LACPDU가 감지되지 않는 동안은 포트 하나를 임시 마스터로 살려두는 우회 옵션이 스위치 설정에 반영돼야 부팅 시점의 정체를 피할 수 있습니다.

여기에 더해, 화재 경보와 연계된 비상 트리거도 설계 사양에 명시해야 하는 항목입니다. 백본 인프라 또는 게이트웨이 노드 단에 물리적인 건식 접점(dry contact) 입력을 받는 하드웨어를 지정하고, 화재 신호가 들어오는 즉시 콘솔 제어를 강제로 뮤트한 뒤 노드에 저장된 100% 밝기의 대피 유도 씬을 하드웨어 레벨에서 단독 송출하도록 구성해야 합니다. 네트워크 통신이 끊긴 상황에서도 이 씬만큼은 살아 있어야 하기 때문입니다.

물리 이중화가 끝났다면, 이제 그 네트워크 안에서 실제로 데이터가 어떻게 흐르는지를 볼 차례입니다. 여기서부터는 케이블이 아니라 소프트웨어 설정의 영역입니다.

sACN을 골랐는데 왜 여전히 불안정한가요

가장 흔한 원인은 IGMP Querier 부재와 EEE(에너지 효율 이더넷) 활성화, 이 두 가지입니다. 둘 다 스위치 설정 화면 안에 있어서, 겉으로는 멀쩡해 보이는 게 문제입니다.

sACN을 도입한 이유가 멀티캐스트인데, 이 멀티캐스트가 제대로 걸러지려면 스위치의 IGMP Snooping이 특정 포트에 연결된 장비가 가입한 유니버스 주소만 골라 전달해야 합니다. 그런데 이 테이블을 주기적으로 유지시켜주는 IGMP Querier가 VLAN 안 어딘가에 명시적으로 켜져 있지 않으면, 포워딩 테이블이 임의로 사라지면서 멀티캐스트가 브로드캐스트로 넘쳐나거나 통신이 아예 끊깁니다. 단말이 유니버스 구독을 취소할 때 즉시 스트림을 끊어주는 Fast Leave 옵션도 개별 포트마다 켜져 있어야 대역폭이 낭비되지 않습니다.

또 하나, 같은 백본에 Dante나 AES67 같은 디지털 오디오 전송을 함께 태우는 공연장이 많습니다. Dante는 마이크로초 단위 클럭 동기를 위해 PTP 멀티캐스트 패킷(224.0.1.129~224.0.1.132)을 1초에도 수천 번 주고받습니다. sACN도 UDP 포트 5568로 대량의 제어 트래픽을 지속적으로 뿌립니다. 이 둘을 같은 논리망(VLAN 1)에 방치하면 스위치 큐가 조명 패킷으로 병목에 걸리고, Dante는 클럭 동기를 잃어 오디오가 수 초 간격으로 끊기는 사고로 이어집니다. 조명 전용 VLAN과 음향 동기화 전용 VLAN을 하드웨어 단에서 완전히 분리해야 두 시스템이 서로 간섭하지 않습니다. 크레스트론·AMX·엑스트론 같은 통합제어 시스템 신호까지 같은 백본에 얹는 현장이라면, 행정망까지 포함해 최소 3개 VLAN으로 나누는 설계가 기본입니다.

EEE(IEEE 802.3az)는 더 골치 아픈 함정입니다. 이 기능은 선로에 데이터가 없는 유휴 구간이 감지되면 물리층 회로를 저전력 대기 상태(LPI)로 낮춰 전력을 아낍니다. 일반 사무 환경에서는 복구 지연이 수십 마이크로초라 티가 안 납니다. 하지만 조명 콘솔이 정적인 씬을 유지하는 동안 스위치가 이 구간을 유휴로 오인해 LPI에 진입했다가, 페이드나 점멸 큐가 갑자기 발동하는 순간 물리층을 다시 깨우는 지연이 겹쳐 링크가 순간적으로 끊기는 ‘링크 플랩’이 발생합니다. 이때 무빙라이트가 덜컹거리거나 조명이 불규칙하게 깜빡이는 증상이 나타납니다 — 앞서 언급한 준공검사 서명 직전의 깜빡임도 이 EEE 때문이었습니다. 대응은 두 가지입니다. 무관리형 스위치는 EEE를 수동으로 끌 수 없어 처음부터 사용을 배제하고, 관리형 스위치는 콘솔·게이트웨이 노드가 물린 모든 포트에서 EEE를 개별적으로 영구 비활성화한 상태를 준공 검사 시 리포트로 제출받아야 합니다.

유선 네트워크가 안정됐다면, 마지막으로 남는 건 무대 스태프가 아이패드로 들고 다니는 무선 리모컨입니다.

아이패드로 콘솔이 안 잡혀요 — 무선망의 함정

무선에서 조명 콘솔이 검색되지 않는 가장 흔한 원인은 AP의 ‘Directed Multicast’ 기능입니다. 대역폭을 아끼려고 만든 이 기능이, 정작 조명 리모컨 앱이 콘솔을 찾는 방식을 깨뜨립니다.

grandMA Web Remote 같은 모바일 리모컨 앱은 무선망 안에서 콘솔의 주소를 찾기 위해 Bonjour, mDNS(224.0.0.251), SLP 같은 멀티캐스트 탐색 프로토콜을 씁니다. 그런데 기업용 AP(Cisco, Aruba, Ruckus 등)는 무선 대역폭을 절약하기 위해 멀티캐스트 패킷을 개별 단말의 유니캐스트 주소로 강제 변환하는 Directed Multicast 기능을 기본 탑재하고 있습니다. 이 변환 과정에서 탐색 패킷의 헤더 구조가 표준 규격을 벗어나면서, 모바일 단말은 이를 깨진 패킷으로 인식해 폐기해버립니다. 유선 컴퓨터에서는 콘솔이 정상적으로 검색되는데, 같은 순간 무선 아이패드에서만 콘솔이 영영 안 잡히는 이유가 바로 이 헤더 변조입니다.

무선 대역폭 자체도 별도로 관리해야 합니다. 멀티캐스트 프레임은 셀 안에서 신호가 가장 약한 단말까지 안정적으로 받게 하려고 가장 낮은 물리 전송률(2~6Mbps)로 고정 전송됩니다. 여기에 수십 유니버스 규모의 sACN 멀티캐스트가 그대로 밀려들면, 저속 전송이 무선 채널의 물리 점유 시간(airtime) 전체를 잠식해 원격 제어 세션이 통째로 끊기는 사고로 이어집니다.

발주처가 시공 시 요구할 조치는 세 가지입니다. 조명 원격 제어 전용 SSID를 일반 행정·관객용 와이파이와 완전히 분리하고, AP 설정에서 Directed Multicast(또는 Multicast-to-Unicast)를 명시적으로 끄고, 간섭이 적은 5GHz 대역 단독으로 운용하는 것입니다. 이 세 가지가 시방서에 명문화돼 있는지가 준공 검사에서 확인할 항목입니다.

발주처가 준공 전 직접 확인할 5가지

여기까지의 내용을 현장 검수 체크리스트로 압축하면 다섯 항목으로 정리됩니다. 저는 준공 인수 단계에서 이 다섯 가지를 감리단 입회 하에 직접 확인하기 전까지는 서명을 미룹니다.

첫째, LACP 이중화 실시간 절체입니다. 콘솔과 스위치를 묶는 이더넷 선로 중 하나를 실제로 뽑아, 조명 씬 전환에 프레임 끊김이나 재시작이 없는지 현장에서 시연받습니다. 둘째, 전 포트 EEE 영구 비활성화입니다. 스위치 설정 덤프 파일을 문서로 제출받아 콘솔·노드가 물린 포트마다 IEEE 802.3az가 꺼져 있는지 대조합니다. 셋째, 물리 배선 임피던스입니다. 게이트웨이 노드부터 마지막 조명기구까지 전 구간이 110~120Ω 규격의 DMX 전용 케이블인지 실사로 확인합니다. 넷째, VLAN 분리입니다. 조명·음향·행정망이 하드웨어 단에서 논리적으로 나뉘어 있는지 스위치 구성 화면에서 직접 봅니다. 다섯째, 무선망 Directed Multicast 해제입니다. AP 프로필에서 이 기능이 꺼져 있는지 확인한 뒤, 5GHz 단독 대역에서 패킷 손실 없이 리모컨이 연결되는지 실측합니다.

무대 조명 LED·AI 전환 후 현장 운영자가 처음 마주치는 3가지 변화에서 다룬 것처럼, 네트워크가 바뀌면 운영자의 일하는 방식도 함께 바뀝니다. 준공 서류에 서명하기 전, 이 다섯 가지를 감리단에 먼저 물어보시길 권합니다. 서류상의 “이중화 설계 완료”라는 문구보다, 케이블을 직접 뽑아보는 5분이 훨씬 정확합니다.

자주 묻는 질문

ArtNet 조명 네트워크 전환을 준비하는 발주처가 실무에서 가장 많이 묻는 질문을 정리했습니다.

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