Elixir로 슈퍼볼의 시각적 충실도 조정

 (elixir-lang.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Cyanview는 슈퍼볼 같은 대형 생중계에서 수백 대 카메라의 색·노출·피부톤을 맞추는 카메라 셰이딩 장비를 만들며, 핵심 제어 경로에 Elixir를 사용함
  • 방송 현장은 한 번의 실패도 치명적이어서, Cyanview는 IP 네트워크 제어와 Erlang VM의 장치 조정 능력을 제품 기반으로 삼음
  • RCP와 RIO 장비는 Yocto Linux 위에서 Elixir와 C 로직으로 동작하고, MQTT 기반 통신과 제한적인 클라우드 릴레이로 원격 제작을 지원함
  • Elixir의 바이너리 인코딩·디코딩과 supervision tree는 다양한 독점 장비 통합, 연결 장애 격리, 빠른 기능 검증에 활용됨
  • 9명 규모 팀이 200대 이상 카메라 연결, Le Mans·Ninja Warrior·Australian Open·US Open 같은 현장을 지원하며 작은 팀의 제품 범위를 넓힘

방송 현장에서 Cyanview가 푸는 문제

  • 슈퍼볼 같은 생중계에서는 약 200대 카메라의 색상, 노출, 시각적 톤을 맞춰야 함
  • 카메라 셰이딩은 각 카메라가 같은 잔디색과 같은 피부톤을 보여주도록 조정하는 작업임
  • 대상 장비는 대형 방송 카메라, 드론 카메라, PTZ 카메라, 짐벌 장착 미러리스 카메라까지 다양함
  • Cyanview는 라이브 비디오 방송 산업용 제품을 판매하는 벨기에의 소규모 회사이며, 주력 분야는 셰이딩임
  • 방송 산업의 도구는 한 번의 라이브 이벤트에서 바로 검증돼야 하고, 하드 실패를 허용하기 어려움

RCP가 퍼진 방식과 사용 현장

  • 3명 규모의 작은 팀이 만든 Remote Control Panel(RCP)은 마케팅보다 기능을 통해 업계에 퍼짐
  • RCP는 전문 비디오 오퍼레이터가 다음 현장에서 사용함
    • Olympics
    • Super Bowl
    • NFL
    • NBA
    • ESPN
    • Amazon
    • Paris의 다수 패션쇼
  • 단일 RCP에서 100대 이상 카메라를 문제없이 다룬 사례가 있으며, 이는 Elixir 네트워크 스택 위에 구현됨
  • Cyanview는 Elixir를 선택해 네트워킹 기능, 복원력, 빠른 제품 기능 반복을 얻음

Elixir를 선택한 이유

  • Cyanview 창업팀은 주로 임베디드 개발 경험을 갖고 있었고, 제품에는 저수준 C 코드와 FPGA가 많이 들어감
  • 색 과학의 저수준 세부 사항과 빡빡한 타이밍 요구사항 때문에 저수준 구현이 필요함
  • 카메라 소프트웨어는 완전 디지털화 이후에도 아날로그 시스템이나 독점 연결 방식에 묶여 있는 경우가 많음
  • 초기부터 IP 기반 제어를 목표로 삼으면서, 범용 네트워크 위에서 소프트웨어가 장비를 다루는 구조가 됨
  • 원격 제작이 늘어나면서 중앙 위치에서 제작팀이 운영하고 현장 인력을 줄이는 방식이 확산됨
  • 맞춤형 무선 주파수나 직렬 와이어 프로토콜은 대륙 간 거리로 확장하기 어려움
  • Erlang VM은 네트워크를 통해 수많은 장치를 안정적으로 통신·조정하도록 설계됐고, 이 점이 Elixir 도입으로 이어짐

프로토콜 통합과 원격 제작 사례

  • 개발자 Ghislain은 여러 네트워크 프로토콜로 카메라와 비디오 장비를 통합하기 위해 Elixir를 도입함
  • Elixir는 개별 비트 단위까지 바이너리 데이터를 인코딩·디코딩하는 실용 기능을 제공함
  • Cyanview의 핵심 지식재산은 대량의 장비 통합과 리버스 엔지니어링에 있음
  • 제품은 고객이 쓰는 다양한 전문 카메라 시스템과 관련 장비에 호환되도록 설계됨
  • 외부 장비와 원활히 통합할 수 있도록 API도 제공함

  • Beijing–Paris 원격 제어 사례

    • 중국 Olympics 사례에서 Beijing 스튜디오는 많은 Panasonic PTZ 카메라를 사용했고, 팀 대부분은 Paris에서 원격 제어해야 했음
    • Panasonic 카메라 프로토콜은 인터넷 사용을 염두에 두지 않았고, 조정마다 정확한 타이밍과 여러 메시지가 필요했음
    • 네트워크 지연은 타임아웃, 연결 끊김, 시스템 실패로 이어질 수 있었음
    • Cyanview 장비를 Beijing의 카메라 옆에 두고 Paris에서 IP로 제어하는 방식으로 운용함
    • 같은 장소의 장비들은 커스텀 MQTT 프로토콜로 네트워크상에서 통신하고 조정함

RCP·RIO와 UI 구성

  • 전체 시스템은 Yocto Linux를 실행하는 RCP 장비와 Elixir·C 기반 로직으로 구성됨
  • Python은 스크립팅과 도구 용도로 여전히 쓰이지만 역할은 점차 줄어듦
  • 여러 마이크로컨트롤러와 온카메라 장치가 MQTT로 통신함
  • 클라우드 릴레이는 연결성을 돕고, 대시보드와 컨트롤러 UI는 감시와 제어를 제공함
  • 핵심 장비는 두 가지임
    • RCP: 제작 쪽 제어 장비
    • RIO: 카메라의 저지연 조작을 담당하는 장비
  • RCP와 RIO는 모두 Elixir를 실행함
  • 설정 UI는 현재 Elm으로 구축돼 있음
  • 우선순위에 따라 설정 UI는 언어 수를 줄이기 위해 Phoenix LiveView로 전환될 수 있음
  • 컨트롤러 웹 UI는 이미 LiveView로 되어 있고, 저사양 임베디드 Linux 머신에서도 잘 동작함

제한적인 클라우드와 로컬 장비 클러스터

  • Cyanview의 클라우드 부분은 현재 제한적이며, SaaS 중심 구조가 아님
  • 클라우드 릴레이는 카메라 제어 배포·공유, 위치 간 네트워크 포트 전달, 관련 기능을 담당함
  • 클라우드 릴레이도 Elixir로 구축됨
  • 현장의 Elixir 장비들은 작업에 맞춘 커스텀 MQTT 기반 프로토콜로 IP 클러스터를 형성함
  • 이 장비들은 수백 대 카메라와 다른 비디오 장치와 통신함

장애 격리와 supervision tree

  • 많은 독점 장비와 통합하다 보면 장비별 신뢰성과 문서 품질이 크게 다름
  • 일부 장비는 흔히 쓰여서 특성이 잘 알려져 있고, 일부는 좋은 문서를 제공하지만, 다른 장비는 예측하기 어려운 동작을 보임
  • 한 카메라 연결에서 일시적 문제, 버그 있는 프로토콜, 물리 연결 장애가 발생해도 나머지는 계속 작동해야 함
  • Elixir의 supervision tree는 개별 연결 문제를 전체 시스템 장애로 번지지 않게 하는 데 유리함

9명 팀의 역할 분담

  • Cyanview는 9년 동안 천천히 성장했으며, 평균적으로 매년 1명씩 추가됨
  • 현재 9명 규모 팀이 세계 최대급 방송 이벤트를 지원함
  • Elixir 개발자는 2명임
    • Daniil은 일부 UI 개편과 더 많은 클라우드 기능 방향을 맡음
    • Ghislain은 카메라와 통합 작업을 맡음
  • LiveView와 Elm은 장비 UI와 대시보드에 사용됨
  • 다른 임베디드 개발자들은 일상 업무에서 Elixir를 많이 쓰지는 않지만, Elixir로 프로토콜과 인코딩을 구현하는 데 익숙함
  • 이들이 Elixir를 깊게 배우지 않은 주된 이유는 시간이 부족하고, 깊은 Elixir 전문성이 필수는 아니었기 때문임
  • 팀의 업무는 PCB 설계, 전자 부품 선택, 프로토콜 리버스 엔지니어링, 디스플레이 인터페이스, FPGA 구현, 생산 테스트 관리, 실제 프로덕션, 펌웨어 업데이트까지 포함함

기능 확장과 고객 중심 개발

  • Cyanview 장비는 다음과 같은 현장에서 사용됨
    • 24 Hours of Le Mans의 40대 이상 차량 온보드 카메라
    • Ninja Warrior
    • Australian Open
    • US Open
    • Louvre의 스튜디오
    • NFL pylons
    • 200대 이상 카메라 동시 연결
  • IP 위에서 동작하는 세계를 대상으로 Elixir 기반 장비를 만들었고, 이를 통해 다양한 장비 지원과 새로운 기능 제공을 동시에 수행함
  • 기존의 로컬 무선 주파수, 직렬 연결, 유연하지 않은 독점 프로토콜에서 IP 네트워크로 이동하면서 카메라 시스템 운용 방식이 바뀜
  • 기능 세트에는 다음이 포함됨
    • 제한 없는 멀티캠
    • Tally lights
    • Pan & Tilt 제어
    • 컬러 코렉터 통합
    • 전 세계 범위 원격 제작
  • 짐벌 장착 미러리스 카메라로 관중 장면을 촬영하는 수요가 늘자, Cyanview는 짐벌 제어를 빠르게 프로토타이핑하고 고객과 테스트해 검증함
  • 유연한 아키텍처는 핵심 기반을 깨뜨리지 않으면서 새 기능을 빠르게 배송할 수 있게 함
  • Canon이나 RED처럼 방송 셰이딩 리모트를 만들지 않는 카메라 회사들은 고객에게 Cyanview를 추천함
  • Cyanview는 대부분의 방송 하드웨어 회사와 경쟁하기보다 파트너로 자신을 봄
  • 마케팅보다 고객 이벤트 성공 지원과 깊은 고객 서비스를 중시함

앞으로의 방향

  • David Bourgeois는 다시 선택하더라도 Elixir를 고르겠다고 답함
  • Erlang VM은 Cyanview의 요구에 잘 맞았고, Elixir가 기본 제공하는 기능의 가치는 직접 구현해 보기 전에는 충분히 알기 어렵다고 봄
  • Cyanview는 팀을 더 키우고 싶지만, 시간이 걸리더라도 책임감 있게 성장하려 함
  • 현재 작은 팀이 감당할 수 있는 것보다 할 일이 더 많음
  • 주요 RCP 장비와 함께 보완 제품들이 이미 있으며, 향후 더 많은 제품이 예정돼 있음
  • 클라우드 제품과 지금까지의 학습을 바탕으로 한 하드웨어 프로젝트가 계획돼 있음
  • Elixir는 세계 최대 규모 라이브 방송 일부에서 더 중요한 역할을 맡게 됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 스포츠 이벤트에서 여러 각도에 배치된 카메라마다 색 보정을 해야 한다는 건 알고 나면 너무 당연함
    대부분에게는 보이지 않는 어려운 문제를 읽는 게 정말 재미있음

    • 알고 나면 당연하지만, 알기 전에는 떠올리기 힘든 초니치·초중요 기능 중 하나임
    • 이게 99% Invisible 팟캐스트의 기반 같은 주제였고, 엘리베이터 편이 특히 좋았음

  • 하프타임 쇼의 모든 카메라 샷 전환을 추적한 영상이 있음: https://www.youtube.com/watch?v=YXNWfFtgbNI

    • Hamish Hamilton의 YouTube 채널에서는 조정실에서 어떻게 보이는지도 볼 수 있고, 조감독이 샷을 호출하는 장면까지 나옴: https://m.youtube.com/watch?v=gfjWjkTP4p8
      Hamish Hamilton은 2010년 이후 모든 Super Bowl 하프타임 쇼를 연출해 왔음
    • John DeMarsico는 NY Mets의 SNY 중계를 연출하며, 여러 카메라가 하나의 제작물로 합쳐지는 비하인드 장면을 가끔 올리는데 꽤 흥미롭게 볼 만함
      https://x.com/SNYtv/status/1832250958258036871

  • “마케팅 없이도 숙련된 전문가들 사이에서 평판을 얻고 세계 최고 라이브 이벤트의 필수품이 됐다”는 대목이 엔터테인먼트 업계답게 들림
    같은 쇼를 같은 크루와 해마다 하다 보면 정말 모두가 모두를 알고 있고, 일종의 가족 같은 구조가 됨

    • “마케팅 없이”는 명백히 틀린 표현임
      Cyanview에는 스토어프런트 웹사이트도 있고 LinkedIn 마케팅 게시물도 있음

  • Elixir가 미션 크리티컬 방송 시스템에서 힘을 얻는 걸 보니 반가움
    Cyanview의 신뢰성이 Elixir 자체에서 얼마나 오는지, 아니면 MQTT 구현을 잘한 덕인지 궁금함
    다른 언어로는 재현하기 어려웠던 Elixir의 특정 기능이 있었는지도 궁금함

    • 메인 개발자 입장에서, MQTT를 많이 쓰고 아키텍처의 핵심이긴 하지만 Elixir는 느슨하게 결합된 많은 프로세스를 다루는 데 큰 이점을 줌
      BEAM과 OTP는 동시성에 건전한 접근을 제공하고, Elixir는 그 위에 얹힌 좋은 언어임
      프로세스 격리가 좋아 힙까지 프로세스별로 나뉘므로 안정적인 성숙 코드와 실험적 기능을 함께 돌려도 전체가 무너질 걱정이 적고, 프로세스 간 통신도 쉽다
      감독 트리 덕분에 프로세스 관리가 쉽고, 서로 다른 재시작 전략을 가진 특수 감독자도 만들 수 있었음
      네트워크 연결이 끊겼다가 다시 붙는 환경이라 시스템 복원력이 물리적인 카오스 몽키처럼 자주 시험됨
      BEAM식 불변성은 동시성 코드 작성을 크게 단순화해, 한 프로세스 안에서는 데이터가 몰래 바뀔 걱정이 없고 다른 프로세스가 내 상태를 바꿀 수도 없음
      그래서 뮤텍스나 임계 구역이 거의 필요 없지만, 교착 상태는 여전히 가능하니 만능 해결책은 아님
    • 이건 Elixir/Erlang/BEAM이 애초에 설계된 핵심 용도임
      수많은 실시간 피드를 장애 조치와 대체 경로로 조율하고 라우팅하는 일이고, 원래 대상은 전화 통화였음
      영상 스트림은 초당 데이터가 훨씬 크지만 원리는 대부분 이어짐
      이 시스템에 비판적인 편이지만, 이런 용도라면 기본 상태만으로도 매우 강한 기반이 됨
    • 모든 프로그래밍 언어는 어떤 작업이든 할 수 있음
      차이는 그 작업을 얼마나 쉽게 만들어 주느냐에 있음
    • 글에서도 “Erlang VM이 무엇을 할 수 있는지 봤고 우리 필요에 매우 잘 맞았다. 직접 구현해 봐야 Elixir가 기본으로 제공하는 것들을 제대로 알게 된다”고 말함

  • Elixir를 중요 금융 애플리케이션, B2B 성장 인텔리전스, 사기 탐지, 스캔앤고 쇼핑 등 여러 곳에 적용해 봤음
    매번 이 글의 엔지니어링 팀처럼 개발자 경험과 최종 결과가 기대를 넘었고, 아직 Elixir를 안 써봤다면 한번 시도해 볼 만함

    • Elixir와 Erlang은 늘 존중과 찬사를 받아왔는데, 왜 더 널리 쓰이지 않는지 항상 궁금함
      나도 예외는 아니어서 수십 년 동안 좋은 얘기를 들었지만 실제 프로젝트에 써보진 않았음
    • 로보틱스 스타트업에서 Elixir를 쓰고 있고 전적으로 동의함
      예를 들어 클라우드 제품에 사용자가 시설 안의 지정 웨이포인트로 로봇을 원격 호출하고, 로봇이 이동하는 동안 지도 위 위치를 실시간으로 보여주는 기능을 막 배포했음
      이걸 MQTT, LiveView, Phoenix PubSub와 지도 조작용 아주 적은 JavaScript만으로 만들었고, 기존 S3 지도 PNG 표시 코드나 MQTT 수신 처리 등을 제외하면 클라우드 부분은 한 사람이 2~3주 정도에 구현함
      물론 다른 언어로도 할 수 있지만, 핵심 언어 기능이 너무 좋아서 우리 용도에서는 다른 선택지를 압도함

  • 비슷한 애플리케이션에 Gleam이 OTP/BEAM 런타임 말고도 실용적일지 궁금함
    아직 Gleam에 없는 Elixir 라이브러리를 활용해야 할 것 같고, 정적 타입 때문에 컴파일은 느릴 수 있지만 런타임 오류를 더 일찍 잡을 수는 있을 듯함
    디버깅과 빠른 동적 반복 사이의 절충에 가까운지 궁금하고, Gleam과 Elixir 중 하나를 정하려는 중임
    예전 Gleam의 ML식 문법도 좋았고 정적 타입도 좋아함
    C는 Zig로 대체하고 있고, x64에 더해 ARM을 익히며 어셈블리도 다시 다지는 중임

    • Gleam이 Elixir나 Erlang보다 런타임 버그를 더 빨리 잡는다는 증거는 딱히 없다고 봄
      Erlang의 신뢰성 기록은 Java를 포함한 많은 정적 타입 언어보다 강함
      정적 타입이 막아주는 오류 부류가 있긴 하지만 막지 못하는 오류가 훨씬 많음
      TS, Java, Swift, Go, Gleam 같은 언어가 Erlang이나 Elixir보다 실제 런타임 결함을 줄인다고 주장하려면 현실 데이터가 필요함
    • Elixir에 대한 불만 중 하나는 타입 부재임
      지금 작업 중이긴 하지만 아직 써보진 못했고, 그래서 Gleam도 괜찮을 것 같음
      다만 우리가 시작했을 때 Gleam은 0.1도 안 됐고 들어본 적도 없었음
      Erlang, Elixir, Gleam을 섞은 프로젝트도 가능하겠지만 실용성은 잘 모르겠음
    • Gleam에는 이미 OTP 기능의 하위 집합이 있음 https://github.com/gleam-lang/otp
      컴파일도 매우 빠름
      아직 아주 큰 프로젝트는 안 해봤지만 꽤 묵직한 라이브러리들을 써도 전부 아주 빠르게 컴파일됐음

  • 디지털 비디오 세계는 IT의 친척 같은데도, 비디오 업계 밖 사람에게는 늘 진입 장벽이 높게 느껴짐
    해상도, 색, 네트워킹, 저장장치를 부르는 방식이 거의 일부러 다른 것처럼 보임

    • 지금까지 대략 200개 방송용 카메라 모델에 대해 다룬 파라미터가 어떤 범위인지 보여주는 자료임: https://pastebin.com/cgeG2r0k
      이건 영상 엔지니어가 이미지 품질을 조정하기 위한 항목일 뿐이고, 카메라 오퍼레이터용 기능은 보통 다루지 않음
      어려운 점은 이렇게 많은 카메라와 프로토콜 사이에서 일관성을 만드는 데 있음
    • 소비자용 영상 장비만 다뤄본 사람은 420과 422 색공간의 차이, 진지한 시네마 카메라가 왜 색보정 전 영상으로 기록하는지, 후반 작업에서 색 보정 과정이 어떻게 생겼는지 이해하려면 추가 교육과 기초 자료가 필요함
      그다음에야 원시 yuv/y4m 비압축 영상, 초고비트레이트 저압축 영상, 원본 데이터가 너무 커서 강력한 워크스테이션에서도 편집이 어려우니 프록시 영상을 만드는 문제로 넘어갈 수 있음
      전문적인 이유가 없다면 일반 최종 사용자가 깊게 파고들 이점은 거의 없음
      RED 카메라에 7,000달러를 쓰고 렌즈, 짐벌, 케이지, 팔로 포커스, 매트 박스, 메모리 카드 등에 13,000달러를 더 써서 작고 비용 효율적인 단일 카메라 제작 패키지를 만들 생각이라면 파고들 만함

  • 30여 년 전 스튜디오 환경에서 카메라 색 밸런스를 맞추는 일이 업무 일부였음
    컴퓨터는 필요 없었지만, 많아야 카메라가 5대뿐이었음

  • 글에서 “한 장소의 장치들이 맞춤 MQTT 프로토콜로 네트워크에서 통신·조율하며, Elixir 네트워크 스택 위에 구현된 단일 Remote Control Panel(RCP)에서 100대 넘는 카메라를 문제없이 다룬다”는 부분이 눈에 띄었음
    MQTT가 TCP 위에 만들어진 것으로 이해하고 있는데, 내가 같은 해법을 찾았을지는 모르겠지만 꽤 좋은 선택으로 보임

답변달기