9년간의 ‘거의’ 성공 — Raspberry Pi를 디지털 사이니지 플레이어로 쓴 사랑과 좌절의 기록

AI 요약

이 글은 Raspberry Pi를 저비용 디지털 사이니지 플레이어로 사용할 수 있는지 9년 동안 직접 검증한 개발자의 경험을 정리합니다. 글쓴이는 Raspberry Pi가 가격, 생태계, 장기적인 운영체제·드라이버 지원 측면에서 매력적인 하드웨어라고 보면서도, 실제 제품으로 배포하려 하면 하드웨어 가속, 그래픽 스택, Qt 호환성, 원격 유지보수 같은 세부 사항에서 계속 문제가 발생했다고 설명합니다. 2019년에는 Raspberry Pi를 진지한 디지털 사이니지에 사용하지 말라고 권고했지만, 이후 환경이 개선되고 구현 방식을 바꾸면서 2026년에는 garlic-player 1.0과 Raspberry Pi용 공식 AppImage를 공개하게 됩니다.

■ Raspberry Pi 3에서 시작된 영상 출력 문제

글쓴이는 2017년부터 garlic-player를 Raspberry Pi로 가져오려 했습니다. Raspberry Pi 3에서는 FFmpeg가 MMAL API를 통해 코덱 디코딩을 하드웨어 가속할 수 있었지만, 영상 출력 자체에는 가속 경로가 없었습니다. Qt 라이브러리를 사용한 플레이어는 플랫폼 독립성을 얻었지만 디스플레이 출력에 zero-copy 경로가 없었고, 그 결과 CPU 사용률이 약 30%에 불과한 상황에서도 영상이 끊기고 소리가 깨졌습니다.

당시의 해결책은 Omxplayer를 사용하는 것이었습니다. Omxplayer는 GPU에서 영상을 완전히 디코딩했고 H.264에서는 잘 작동했습니다. Luca Carlon은 FFmpeg와 Omxplayer의 일부를 결합해 QML 장면 안에서 영상을 직접 렌더링하는 백엔드를 만들었고, 이를 PiOmxTextures, 줄여서 PoT라고 이름 붙였습니다. 그러나 garlic-player는 QWidget 기반 인터페이스였고 PoT는 QML 기반이었습니다. 글쓴이는 애플리케이션을 라이브러리와 플레이어 컴포넌트로 분리한 뒤 QWidget 플레이어와 별도로 QML 플레이어를 구현해야 했습니다. 영상 코덱 하나를 지원하기 위해 며칠간 리팩터링해야 했지만, Android 멀티미디어 지원에도 QML이 필요했기 때문에 작업 자체는 장기적으로 의미가 있었습니다.

2018년에는 Raspberry Pi Zero에서도 HD 영상을 완전히 부드럽게 재생하는 데 성공했습니다. 그러나 PiOmxTextures를 QMultimedia와 함께 사용할 때 웹뷰 컴포넌트를 열 수 없는 문제가 발생했습니다. 오류도 로그도 없었고, 단지 아무것도 표시되지 않았습니다. 전체 화면 영상은 정상적으로 작동했지만 HTML5 위젯과 웹사이트가 실패했으며, 영상과 웹 콘텐츠를 여러 구역에 배치하는 multi-zone 레이아웃도 사용할 수 없었습니다. garlic-player를 다른 무료 솔루션과 구분해 주던 기능 두 가지가 동시에 사라진 셈입니다.

■ Raspberry Pi 4의 개선과 새로운 제약

2019년 출시된 Raspberry Pi 4는 더 빠른 CPU와 새로운 GPU, 그리고 IoT 장치에서는 드문 두 개의 HDMI 포트를 제공했습니다. 글쓴이는 1080p 영상이 FFmpeg를 통해 끊김 없이 재생되는 것을 확인하며 기대했지만, 하드웨어 가속은 32비트 운영체제에서만 가능했습니다. garlic-player에 더 적합하다고 본 64비트 Raspbian은 사실상 끝나지 않는 베타처럼 보였고, 하드웨어 가속도 제공하지 않았습니다. 최신 운영체제를 선택하면 하드웨어 디코딩을 포기해야 하고, 하드웨어 디코딩을 선택하면 구형 운영체제를 사용해야 하는 상황이었습니다. MMAL이 deprecated 상태가 되면서 PoT도 더 이상 작동하지 않았습니다.

4K 영상도 여러 제약이 있었습니다. VLC player에서는 특정 H.265 프로파일의 영상만 전체 화면으로 재생할 수 있었고, H.264 기반 4K는 지원되지 않았습니다. 창 모드나 garlic-player 안에서 4K를 재생하면 심하게 끊겼습니다. 하드웨어 overlay는 효율적이었지만 Qt widget처럼 복잡한 표면 안에 삽입할 수 없었기 때문입니다. 당시 garlic-player는 QtAv를 통한 FFmpeg와 Qt Multimedia를 멀티미디어 백엔드로 사용했고, 세 번째 백엔드로 libvlc 구현도 추가했지만 재현할 수 없는 방식으로 충돌했습니다. 64비트 베타에서 네 개의 영상을 동시에 재생하는 데 성공한 시점도 있었지만, 이는 소프트웨어 디코딩이었으므로 수백 대의 원격 화면에 배포할 디지털 사이니지 제품에는 적합하지 않았습니다. 글쓴이는 데모와 제품은 다르다고 강조합니다.

■ 2022년 이후의 변화와 Raspberry Pi 5

글쓴이는 이후 Android 하드웨어 기반 프로젝트 요청이 늘어나면서 Android와 garlic-launcher에 집중했습니다. 2022년에는 Raspberry Pi 환경이 크게 변했다는 점을 처음으로 확인했습니다. 여러 최적화, Wayland와 labwc, 작은 성능 개선, 그리고 적어도 VLC에서 사용할 수 있는 V4L2-M2M 디코더가 추가됐습니다. Raspberry Pi 400을 사용한 2023년에는 창 모드에서도 4K H.265 영상이 놀랄 만큼 부드럽게 재생됐습니다. 완벽하지는 않았지만 다음 세대에 대한 기대를 갖게 한 변화였습니다.

Raspberry Pi 5는 eMMC flash를 제공하지 않는다는 점은 같았지만, 배터리로 유지되는 real-time clock, 즉 RTC와 PCIe 인터페이스를 추가했습니다. 디지털 사이니지에서 RTC는 중요합니다. 장치가 충돌하거나 재부팅된 뒤에도 정확한 날짜와 시간이 유지되어야 오프라인 상태에서 시간 예약 콘텐츠를 올바르게 재생할 수 있습니다. 시간이 틀리면 TLS 인증서가 유효하지 않게 되고 CMS 연결도 거부될 수 있습니다. 글쓴이는 약 2달러짜리 배터리 하나가 이 문제를 해결한다고 설명합니다.

반면 Raspberry Pi 5는 전력 소비가 늘어 팬이 필요해졌고, 디지털 사이니지에 특히 큰 제약인 코덱 지원 변경도 있었습니다. 하드웨어 가속이 H.265에만 제공되고 나머지 코덱은 CPU에서 디코딩됐습니다. Raspberry Pi 4는 H.264를 가속했고 Raspberry Pi 3는 더 많은 코덱을 지원했기 때문에, 세 세대가 지나면서 코덱 지원이 오히려 줄어든 셈입니다. 글쓴이는 이 시점에 Raspberry Pi가 대규모 디지털 사이니지 네트워크를 위한 완벽한 해법이 될 수 없다고 판단하고 기대치를 낮췄습니다.

■ Qt WebView 문제와 의존성의 부담

Raspberry Pi OS가 Debian 12 Bookworm 기반으로 바뀐 뒤에는 Qt5 QWebView가 충돌하기 시작했습니다. 웹사이트나 HTML5 위젯을 표시하려는 순간 프로그램이 종료됐지만, 유용한 정보나 재현 가능한 버그 리포트는 없었고 Qt6를 사용하라는 권고만 있었습니다. 그러나 Qt6로의 마이그레이션은 간단한 선택이 아니었습니다. Qt6에서는 QXmlPatterns가 제거됐고, garlic-player는 XPath 2.0 함수를 필요로 했습니다.

글쓴이가 확인한 오픈소스 C++ 라이브러리 중 XPath 2.0을 지원하는 것은 XQilla뿐이었지만, XQilla는 2016년부터 유지보수되지 않았고 문서도 부족했습니다. 게다가 모든 플랫폼에서 Xerces-C를 추가 의존성으로 끌어와야 했습니다. 작동 중인 XML 엔진을 유지보수가 중단된 라이브러리와 더 복잡한 빌드 구성으로 교체하는 것은 WebView 버그를 추적하는 사이드 프로젝트로 감당하기 어렵다고 판단했습니다. pi-gen을 사용해 Raspberry Pi 4용 실험 이미지도 만들었지만, 구성상 64비트 바이너리를 생성하도록 설정했음에도 어느 순간 32비트 바이너리를 만들기 시작하면서 더 이상의 투자를 중단했습니다.

■ libvlc와 Qt 수정으로 마침내 구현한 구성

2026년, 마지막 garlic-player 안정 버전 이후 3년이 지나 글쓴이는 다시 Bookworm과 Trixie 환경을 시도했습니다. 마지막 Qt5 라이브러리인 5.1.5.19를 직접 컴파일해 사용하자 첫 시도에서 모든 기능이 작동했습니다. Qt WebEngine과 Raspberry Pi OS에 일부 수정이 반영된 것으로 보였고, 이를 계기로 garlic-player 1.0과 Raspberry Pi용 공식 AppImage를 공개했습니다.

Linux ARM용 garlic-player는 이제 FFmpeg와 QMultimedia 대신 libvlc를 멀티미디어 백엔드로 사용합니다. 이 변경이 핵심 중 하나였습니다. Raspberry Pi 4와 Pi 5에서 일반 SD 카드만으로 구동할 수 있고, HD와 4K 영상이 모두 부드럽게 재생됩니다. 2018년 글쓴이의 의욕을 꺾었던 문제도 사라졌습니다. 영상과 웹뷰를 동시에 사용하는 multi-zone 구성이 정상적으로 작동합니다. 영상 쪽은 libvlc가 해결했고, 웹뷰 쪽은 Qt와 Raspberry Pi OS의 수정이 해결했습니다.

다만 제한 사항은 남아 있습니다. libvlc는 X11/xcb를 필요로 하므로 XWayland 환경에서만 작동하고, 원격 재시작이나 재부팅을 위한 control daemon도 아직 없습니다. 두 기능 모두 작업 목록에 있지만, 글쓴이는 어느 순간에는 세부적인 완벽함을 계속 추구하기보다 작동하는 것을 출시해야 한다고 결론 내립니다.

■ 최종 판단: 소규모에는 적합하지만 대규모 배포에는 신중해야 합니다

글쓴이가 정리한 Raspberry Pi의 장점은 수년간 안정적으로 생산된 하드웨어, 몇 달마다 새 장치로 교체할 필요가 없는 장기 운영성, 오픈소스에 우호적인 회사의 드라이버·운영체제 지원, 그리고 강력한 maker 커뮤니티입니다. 반대로 느린 하드웨어와 인터페이스, 때때로 발생하는 전략적 결정의 문제, eMMC flash의 부재, FFmpeg의 빈약한 비디오 가속, Raspberry Pi 5 이전까지 배터리 백업 RTC가 없었다는 점은 단점으로 꼽습니다.

결론은 2019년의 판단과 크게 다르지 않습니다. 소규모 설치에는 가능하지만 대규모 설치에는 적합하지 않다는 것입니다. 예산이 제한되어 있고 Linux를 다룰 수 있으며 네트워크로 관리해야 할 장치 수가 많지 않다면 Raspberry Pi 4, 더 나은 선택으로는 Raspberry Pi 5를 사용할 수 있습니다. 특히 장치가 설치된 장소에 쉽게 접근해 장애를 직접 처리할 수 있다면 선택할 만합니다. 글쓴이는 과열이나 Wi-Fi 끊김을 겪은 Android HDMI stick과 비교하면 Raspberry Pi가 투명한 드라이버 지원과 지속적인 업데이트를 제공한다는 점에서 더 나은 선택일 수 있다고 봅니다.

그러나 멀리 떨어진 여러 장소에 많은 장치를 설치하는 경우에는 위험이 큽니다. Raspberry Pi는 본질적으로 프로토타이핑과 maker를 위한 tinkering 시스템이므로, 대규모 네트워크에는 높은 안정성과 원격 유지보수 체계가 필요합니다. 장치 한 대의 가격을 아끼려다 장애 대응을 위한 출장 한 번으로 Raspberry Pi 열 대의 비용을 지불할 수 있다는 지적도 덧붙입니다. 최종 교훈은 Raspberry Pi가 완벽한 디지털 사이니지 플레이어가 되기를 기다리는 대신, 현재 작동하는 구성을 받아들이고 출시하는 법을 배웠다는 것입니다.

원문: dev.to / 번역·요약: Trawling