스마트홈에 관심을 갖기 시작하면서 자연스럽게 Home Assistant라는 이름을 접하게 됐다. 오픈소스 기반의 홈 자동화 플랫폼이라는 소개에 끌렸고, 마침 집에 24시간 켜져 있는 시놀로지 NAS가 있었기에 “굳이 라즈베리파이를 새로 사지 않아도 되겠다”는 생각으로 NAS Docker 설치를 시도해봤다. 이 글은 그 과정에서 실제로 막혔던 지점, 뒤늦게 알게 된 한계, 그리고 “처음부터 이걸 알았더라면” 싶었던 내용을 정리한 후기다.
결론부터 말하면, 설치 자체는 성공했다. 하지만 막상 쓰려고 하니 생각보다 많은 것들이 제한되어 있었고, 결국 다른 방식으로 갈아타는 선택을 하게 됐다. 왜 그런 결론에 이르렀는지, 순서대로 풀어보겠다.
왜 NAS Docker를 먼저 시도했나
Home Assistant를 처음 접하는 사람들이 가장 많이 선택하는 하드웨어는 라즈베리파이다. 그런데 나는 이미 시놀로지 NAS를 쓰고 있었고, 그 NAS가 하루 종일 켜져 있었다. 추가 전력 소모도 없고, 별도 기기 구매도 필요 없고, Docker 컨테이너 하나만 올리면 되는 거 아닐까 싶었다.
시놀로지 NAS에는 Container Manager라는 공식 패키지가 있다. 예전에는 ‘Docker 패키지’라고 불리던 것인데, 이걸 통해 GUI 방식으로 컨테이너를 관리할 수 있다. 인터넷에 관련 자료도 꽤 많았고, 진입 장벽이 낮아 보였다. 실제로 초기 설치는 어렵지 않았다.
Docker Hub에서 homeassistant/home-assistant 이미지를 받아오고, 포트 설정과 볼륨 마운트(컨테이너 안의 파일을 NAS 실제 폴더에 연결하는 것)를 잡아준 뒤 컨테이너를 실행하면 웹 UI가 뜬다. 처음 온보딩 화면이 나타났을 때는 꽤 설렜다. 이 정도면 금방 쓸 수 있겠다 싶었다.
그런데 실제로 기기를 연결하고 자동화를 구성하려는 순간부터 문제가 하나씩 드러나기 시작했다.
첫 번째 벽: 하드웨어 접근 제한
Home Assistant에는 수백 가지의 통합(Integration) 기능이 있다. 스마트 전구, 온습도 센서, 플러그, 카메라 등 다양한 기기를 연결할 수 있는데, 그 중 상당수가 Bluetooth, Zigbee, Z-Wave 같은 무선 통신 방식을 사용한다. 이런 기기들을 연결하려면 USB 동글 형태의 코디네이터 장치가 필요하다.
문제는 NAS에 USB 장치를 꽂더라도, Docker 컨테이너 안에서 그 장치를 정상적으로 인식시키는 과정이 단순하지 않다는 점이다. 이걸 ‘디바이스 패스스루(device passthrough)’라고 부르는데, 쉽게 말하면 NAS 본체에 꽂힌 USB 장치를 컨테이너 안으로 “통과”시켜주는 설정이다.
시놀로지 DSM(NAS 운영체제)의 권한 구조 때문에 이 패스스루가 원활하지 않은 경우가 많다. 커뮤니티를 찾아보면 이 지점에서 막혀서 포기하거나 다른 방법을 찾는 사람들이 꽤 있다. 나도 Zigbee 코디네이터를 연결해보려다가 장치가 컨테이너에서 아예 보이지 않는 상황을 겪었다.
결국 Wi-Fi 기반 기기들만 연결하는 방향으로 우선 진행했지만, 나중에 Zigbee 기기를 추가하고 싶을 때 이 한계가 다시 발목을 잡을 거라는 걸 알고 있었다.
두 번째 벽: 애드온을 쓸 수 없다
Home Assistant를 쓰는 이유 중 하나가 방대한 커뮤니티 생태계다. 특히 공식 Add-on Store에서 클릭 몇 번으로 설치할 수 있는 애드온들이 많다. 그런데 이 애드온 기능은 Home Assistant OS(HAOS) 또는 Supervised 방식으로 설치했을 때만 사용할 수 있다.
NAS Docker 방식은 ‘Home Assistant Container’ 방식에 해당하는데, 이 방식에서는 Add-on Store 자체가 메뉴에 뜨지 않는다. 즉, 아래와 같은 인기 애드온들을 클릭 한 번으로 설치하는 게 불가능하다.
- Node-RED – 시각적으로 자동화 흐름을 만드는 도구
- Mosquitto MQTT 브로커 – 각종 IoT 기기들이 서로 통신하는 중간 다리 역할
- ESPHome – ESP 기반 DIY 센서를 만들 때 쓰는 펌웨어 도구
- Z-Wave JS – Z-Wave 기기 연결용 서비스
물론 이것들을 별도의 Docker 컨테이너로 따로따로 올릴 수는 있다. 하지만 그렇게 되면 docker-compose.yml 파일을 직접 작성하고, 컨테이너 간 네트워크를 구성하고, 각 서비스 연동을 수동으로 설정해야 한다. “편하게 하려고” 시작했던 것이 어느 순간 훨씬 복잡한 작업의 연속이 되어버렸다.
처음에 NAS Docker를 선택한 이유가 ‘간편함’이었는데, 아이러니하게도 그 방식이 가장 손이 많이 가는 구성이 된 것이다.
세 번째 벽: HACS도 완전하지 않다
HACS는 Home Assistant Community Store의 약자로, 공식 통합 목록에 없는 커스텀 컴포넌트나 테마, 카드 등을 설치할 수 있는 서드파티 스토어다. 이건 NAS Docker 환경에서도 설치 자체는 가능하다.
그런데 문제는 일부 HACS 커스텀 컴포넌트들이 Supervised 환경이나 HAOS를 전제로 만들어져 있다는 점이다. 설치는 됐는데 제대로 작동하지 않거나, 특정 기능이 빠져 있거나, 업데이트 후 갑자기 오류가 나는 경우가 생긴다. 원인을 찾아보면 “이 컴포넌트는 Container 방식에서 지원되지 않습니다”라는 문구가 나오는 경우도 있었다.
쓸 수 있는 것과 제대로 쓸 수 있는 것은 다른 얘기다. 이 부분에서 생각보다 많은 시간을 낭비했다.
네 번째 벽: 업데이트가 번거롭다
Home Assistant는 업데이트가 매우 활발한 프로젝트다. 거의 매달 새 버전이 나오고, 보안 패치나 기능 개선이 잦다. HAOS 환경에서는 웹 UI에서 클릭 한 번으로 업데이트가 완료된다. 반면 Docker 방식에서는 직접 이미지를 새로 받아오고(pull), 기존 컨테이너를 삭제하고, 새로 생성해야 한다.
시놀로지 Container Manager에서 이미지 업데이트를 진행하다가 설정 파일이 꼬이는 경험을 했다. 특정 버전에서 볼륨 마운트 경로 문제로 대시보드 설정이 날아갈 뻔한 적도 있었다. 매번 업데이트 전에 백업을 챙겨야 한다는 부담이 생각보다 크게 느껴졌다.
처음에는 “Docker니까 관리가 편하겠지”라고 생각했는데, Home Assistant 특성상 설정 파일이 복잡하고 버전 간 변경 사항도 많아서 단순히 이미지만 교체하는 것으로 끝나지 않는 경우가 많았다.
NAS Docker 설치 전 확인해야 할 체크리스트
만약 지금 NAS Docker 방식을 고려 중이라면, 아래 항목들을 먼저 확인해보는 걸 권한다. 나처럼 설치하고 나서 뒤늦게 알게 되는 것보다 미리 파악하는 게 훨씬 낫다.
- Zigbee, Z-Wave, Bluetooth 기기를 연결할 계획이 있는가?
있다면 USB 패스스루 문제가 생길 수 있다. NAS 모델과 DSM 버전에 따라 지원 여부가 다르다. - Node-RED, ESPHome, Mosquitto 같은 애드온을 쓸 생각인가?
있다면 Container 방식으로는 별도 Docker 컨테이너를 각각 구성해야 한다. 처음부터 HAOS나 Supervised 방식을 고려하는 게 낫다. - 업데이트를 얼마나 자주, 편하게 하고 싶은가?
자주 최신 버전을 유지하고 싶다면 원클릭 업데이트가 되는 HAOS가 훨씬 편하다. - NAS를 다른 용도로도 쓰고 있는가?
NAS가 파일 서버, 백업 서버 등으로 이미 바쁘게 돌아가고 있다면, Home Assistant 컨테이너가 리소스를 추가로 잡아먹는 것도 고려해야 한다. - Docker나 yaml 설정에 익숙한가?
익숙하지 않다면 오류 발생 시 원인을 찾기가 꽤 어렵다. 처음 시작이라면 HAOS가 훨씬 진입 장벽이 낮다.
설치 방식별 비교: 어떤 걸 선택해야 할까
Home Assistant는 설치 방식이 여러 가지다. 처음 접하면 뭐가 다른지 헷갈리는데, 간단하게 정리해봤다.
| 설치 방식 | 애드온 지원 | 하드웨어 접근 | 업데이트 편의성 | 추천 대상 |
|---|---|---|---|---|
| HAOS (전용 기기/VM) | ✅ 전체 | ✅ 완전 | ✅ 원클릭 | 모든 사용자 |
| Supervised (데비안) | ✅ 전체 | ✅ 지원 | 🔶 보통 | 중급 사용자 |
| Container (일반 Docker) | ❌ 불가 | 🔶 제한적 | 🔶 수동 | 고급 사용자 |
| NAS Docker (이 글) | ❌ 불가 | ❌ 매우 제한 | ❌ 번거로움 | 신중히 선택 |
표에서 보이듯이, NAS Docker 방식은 세 가지 핵심 항목에서 모두 아쉬운 점이 있다. 물론 “Wi-Fi 기반 기기만 쓸 거고, 애드온도 필요 없고, 업데이트도 자주 안 해도 된다”는 조건이라면 NAS Docker로도 충분히 굴릴 수 있다. 하지만 스마트홈을 점점 확장하다 보면 결국 한계에 부딪히는 시점이 온다.
그래서 NAS Docker, 써도 될까
완전히 쓸 수 없는 방식은 아니다. 하지만 처음 시작하는 사람에게 추천하기는 어렵다는 게 솔직한 생각이다. 특히 아래 경우라면 처음부터 다른 방식을 고려하는 게 낫다.
- Zigbee, Z-Wave, Matter 기기를 연결할 계획이 있을 때
- Node-RED나 ESPHome 같은 애드온을 써보고 싶을 때
- Home Assistant를 깊이 파고들고 싶을 때
- Docker나 yaml 설정이 익숙하지 않을 때
반대로 이런 경우라면 NAS Docker도 나쁘지 않다.
- Wi-Fi 기반 기기(Tuya, 샤오미 등)만 쓸 예정일 때
- 새 하드웨어 구매 없이 일단 HA를 맛보고 싶을 때
- Docker 환경에 이미 익숙하고, 수동 설정이 부담스럽지 않을 때
나의 경우는 결국 NAS Docker를 잠시 써보고, 이후 VM 방식으로 HAOS를 설치하는 방향으로 전환했다. NAS에서 VM을 돌리는 방식이라 하드웨어를 새로 사지 않아도 됐고, 애드온도 쓸 수 있어서 훨씬 자유로워졌다. 그 과정은 다음 편에서 이어서 정리했다.
마무리하며
NAS Docker 설치 후기를 한 줄로 요약하면 이렇다. “설치는 쉽고, 쓰기는 어렵다.” 처음에 기대했던 것처럼 간편한 방식이 아니었고, 생각보다 많은 제약이 있었다. 그래도 이 과정에서 Home Assistant가 어떻게 구성되어 있는지, 각 설치 방식이 왜 다른지를 직접 부딪히며 배울 수 있었다. 그게 이 시리즈를 계속 쓰는 이유이기도 하다.
HA를 처음 시작하는 분이라면 어떤 기기를 연결하고 싶은지, 어느 정도 깊이로 파고들 건지를 먼저 생각해보고 설치 방식을 고르길 권한다. 설치 방식 선택이 나중에 생각보다 큰 영향을 미친다.
📌 같이 보면 좋은 글
- [HA 구축기 03] Home Assistant 쉽게 이해하기 – 설치 방식을 고르기 전에 HA 자체가 뭔지 먼저 파악하고 싶다면
- [HA 구축기 05] HA OS VM 설치 가이드 – NAS Docker 대신 VM 방식으로 HAOS를 설치하는 과정을 정리한 글
- Home Assistant 디바이스 연결이 안 될 때 해결 방법 – 기기 연결에서 막힌다면 이 글이 도움이 될 수 있다
- [HA 구축기 02] 허브를 HA로 모은 이유 – 처음에 왜 HA를 선택했는지 배경이 궁금하다면
시리즈 글 모아보기
- 이전 편: 03. Home Assistant 쉽게 이해하기
- 다음 편: 05. HA OS VM 설치 가이드
- 전체 목차: Home Assistant 구축기 전체 목차
- 참고: Home Assistant 공식 문서