Music Assistant의 README는 짧고 단정하다. "무료, 오픈소스 미디어 라이브러리 매니저로 스트리밍 서비스와 다양한 스피커를 연결한다." 그런데 바로 다음 문장이 이 프로젝트의 정체를 결정한다. "서버는 Raspberry Pi, NAS, Intel NUC 같이 항상 켜져 있는 기기에서 돌아야 한다." 무심코 지나칠 한 줄이지만, 이게 모든 아키텍처 결정의 출발점이다.
왜 굳이 always-on을 강제할까. 클라우드 SaaS로 풀면 사용자는 박스를 관리할 필요가 없고 개발자는 배포가 편하다. 하지만 멀티룸 오디오는 본질적으로 stateful한 문제다. 어느 방에서 어떤 큐가 어디까지 흘렀는지, 어떤 스피커들이 한 그룹으로 묶여 있는지, 크로스페이드는 어느 타이밍에 잘려야 하는지를 누군가 끊김 없이 들고 있어야 한다. 동시에 입력 측에는 Spotify와 Apple Music 같은 클라우드 스트리밍의 OAuth 토큰이, 출력 측에는 Sonos·Chromecast·각종 스마트 스피커의 디스커버리 상태가 흩어져 있다. 이 코디네이터를 사용자의 LAN 안에 두는 순간, latency·mDNS 디스커버리·토큰 보관·로컬 NAS 음원 접근이 한꺼번에 풀린다.
같은 가설을 비디오에서 먼저 증명한 게 Plex다. 라이브러리는 자기 서버를 가질 자격이 있다는 명제. Music Assistant는 그걸 오디오와 멀티룸 제어로 옮긴다. 차이는 오디오 쪽이 디바이스 프로토콜 지옥이라는 점이다. 각 스피커 벤더의 SDK와 프로토콜을 추상화 한 겹으로 묶고, 새 디바이스가 등장할 때마다 플러그인으로 흡수해야 한다. Python으로 서버를 짠 이유도 이 확장성에 가깝다. C++로 짠 코덱 최적화가 아니라, 다양한 벤더 SDK를 빠르게 감싸고 커뮤니티가 PR로 채워 넣는 구조에 더 맞는 언어 선택이다.
Home Assistant 생태계와 자연스럽게 붙는 것도 우연이 아니다. 같은 always-on 박스 위에 살기로 합의한 코드들은 결국 서로의 entity와 이벤트 버스를 공유한다. 음악 큐가 "누가 집에 들어옴" 같은 자동화 트리거의 한 축이 되는 순간, 이 서버는 단순한 미디어 매니저에서 홈 오토메이션의 오디오 서브시스템으로 정체성이 한 단계 진화한다. 그래서 이 프로젝트를 평가할 때 "오픈소스 Sonos 대체재"라는 프레임은 한 겹을 놓친다. 진짜 베팅은 가정용 오디오가 클라우드의 손님이 아니라 우리 집 박스의 주인이어야 한다는 쪽이다. 별 수치보다 흥미로운 건, 이 거래—내 NUC을 운용할 책임을 지는 대신 내 음원과 토큰의 통제권을 갖는 거래—에 동의하는 사용자가 꾸준히 늘고 있다는 사실이다.