[HA 구축기 02] 허브를 HA로 모은 이유

작성자:

스마트홈을 처음 시작할 때는 다들 비슷한 경로를 밟는다. 조명 하나 바꿔보려고 스마트 전구를 샀더니 전용 허브가 따라오고, 로봇청소기를 장만하니 전용 앱이 생기고, 온습도 센서를 달았더니 또 다른 앱이 설치됐다. 어느 순간 스마트폰 홈 화면에는 제조사별 앱이 다섯 개를 넘어서고, 공유기 옆에는 크고 작은 허브들이 쌓이기 시작한다. 이 글은 그 상황에서 벗어나기 위해 Home Assistant(홈 어시스턴트)를 선택하게 된 이유와 과정을 직접 겪으면서 정리한 기록이다.

시리즈 앞 글인 [HA 구축기 01] 스마트홈이 더 불편해진 이유에서 분리된 생태계가 얼마나 피로한지 썼는데, 이번 글은 그 다음 질문인 “그래서 왜 HA로 허브를 모았는가”에 대한 답이다.

앱이 다섯 개를 넘어가면서 생긴 문제들

처음에는 단순했다. 거실 전구 하나를 스마트 전구로 교체하는 것으로 시작했고, 이후 스마트 플러그, 온습도 센서, 현관 카메라 순서로 기기가 늘어났다. 문제는 기기를 살 때마다 해당 브랜드의 앱과 허브를 함께 구입하게 된다는 점이었다.

  • 조명 상태 확인 → 필립스 휴 앱
  • 로봇청소기 예약 → 로보락 앱
  • 온습도 체크 → 미홈 앱
  • 현관 카메라 확인 → 카메라 제조사 앱

각각 따로 열어야 했고, 앱마다 로그인 계정도 달랐다. 자동화를 만들고 싶어도 서로 다른 앱끼리는 연동이 되지 않거나, 연동이 된다고 해도 반드시 클라우드를 거쳐야 해서 반응 속도가 느렸다. 앱에서 버튼을 누르면 내 스마트폰 → 제조사 서버 → 허브 → 기기 순서로 명령이 전달되는데, 체감 지연이 1~2초는 기본이었고 인터넷 상태가 나쁘면 더 길어졌다.

결정적으로 제조사 서버가 점검 중이거나 인터넷이 잠깐 끊기면 집 안에 있는 기기를 아예 제어할 수 없는 상황이 반복됐다. 내 집 안에 있는 기기인데 왜 인터넷이 없으면 불 하나 끄지 못하는가, 라는 의문이 Home Assistant를 찾아보게 된 직접적인 계기였다.

Home Assistant가 뭔지 간단히 정리하면

Home Assistant는 오픈소스 기반의 홈 자동화 플랫폼이다. 라즈베리파이, 구형 미니PC, NAS 같은 로컬 서버에 설치해서 운용하고, 인터넷 연결 없이도 집 안의 기기를 제어하고 자동화를 실행할 수 있다. 2013년에 시작된 프로젝트이고, 지금은 전 세계 수백만 명이 쓰는 커뮤니티 중심 생태계로 성장했다.

핵심은 3,000개가 넘는 통합(Integration)을 공식으로 지원한다는 점이다. 필립스 휴, 삼성 스마트싱스, 샤오미 미홈, 구글 홈, 애플 홈킷, 아마존 알렉사, 다원 스마트 플러그 같은 국내 제품까지 하나의 대시보드 안에서 함께 관리할 수 있다. 기존에 쓰던 기기를 버릴 필요 없이, 이미 가진 것들을 한 곳으로 모을 수 있다는 게 포인트다.

용어가 낯설 수 있으니 짧게 풀면, ‘통합’은 HA가 특정 브랜드나 서비스와 대화할 수 있게 해주는 연결 모듈 같은 것이다. 예를 들어 필립스 휴 통합을 설치하면 HA가 휴 브리지와 직접 통신해서 조명 상태를 읽고 제어할 수 있게 된다.

개별 IoT 허브와 Home Assistant, 어떻게 다른가

항목 개별 IoT 허브 Home Assistant
지원 브랜드 자사 제품 중심 3,000개 이상 통합
인터넷 의존도 클라우드 필수 로컬 우선 동작
자동화 유연성 브랜드 내 제한적 브랜드 간 자유롭게
데이터 저장 위치 제조사 서버 내 서버(로컬)
월 비용 브랜드별 상이 기본 무료
서비스 종료 위험 상대적으로 높음 낮음(오픈소스)

표로 보면 차이가 명확한데, 실제로 써보면 체감 차이가 더 크다. 특히 자동화 항목이 그렇다. 기존 앱 환경에서는 “현관 센서가 감지되면 거실 조명을 켠다”는 자동화를 만들려면 두 기기가 같은 브랜드이거나 구글/애플 같은 중간 플랫폼을 통해야 했다. HA에서는 브랜드가 달라도 같은 자동화 안에서 묶을 수 있다.

로컬 처리가 만들어내는 체감 차이

Home Assistant를 설치하고 가장 먼저 느낀 변화는 반응 속도였다. 기존에는 앱에서 조명 버튼을 누르면 명령이 클라우드를 거쳐 돌아오는 구조라 1~2초 지연이 당연했다. HA로 전환한 뒤에는 명령이 집 안 로컬 네트워크 안에서만 처리되기 때문에 반응이 체감상 거의 즉각적이었다. 정확히 측정하기는 어렵지만, 자동화가 실행될 때 불이 켜지는 느낌 자체가 달라졌다는 표현이 맞다.

그리고 인터넷이 끊겨도 집 안의 자동화가 정상 작동한다는 점이 생각보다 실용적이다. 공유기를 재시작하는 동안에도 현관 센서가 반응하면 복도 조명이 켜지고, 취침 루틴이 정해진 시간에 그대로 실행된다. 이전에는 인터넷이 잠깐 끊기면 자동화가 통째로 멈추는 일이 있었는데, 그 불안감이 사라진 것만으로도 전환할 이유가 충분했다.

다만 모든 기기가 로컬로 처리되는 건 아니다. 일부 기기는 제조사 클라우드를 반드시 거쳐야 하는 구조이고, 이런 기기들은 HA에 연결돼 있어도 인터넷이 끊기면 제어가 안 된다. 기기를 새로 살 때 로컬 통신을 지원하는지 확인하는 습관이 생긴 것도 HA를 쓰면서 생긴 변화 중 하나다.

제조사 서비스 종료 위험, 생각보다 현실적인 문제다

스마트홈 기기를 오래 쓰다 보면 제조사가 앱 지원을 종료하거나 서버를 닫는 사례를 종종 접하게 된다. 위모(WeMo) 일부 기기가 클라우드 서비스 종료로 사실상 사용 불가가 된 사례, 스마트싱스 특정 허브 모델의 지원이 끊긴 사례 등이 있었다. 구글도 스태디아처럼 꽤 큰 서비스를 갑작스럽게 종료한 전례가 있다 보니, 제조사 서버에 완전히 의존하는 구조가 불안하게 느껴지기 시작했다.

오픈소스 플랫폼인 Home Assistant는 특정 기업의 경영 판단에 직접적으로 흔들리지 않는다. 내가 가진 기기가 오래됐더라도, 커뮤니티에서 누군가가 만들어둔 커스텀 통합(HACS)을 통해 계속 사용할 수 있는 경우가 많다. 기기의 수명이 제조사의 서비스 정책보다 길어질 수 있다는 점이, 장기적으로 스마트홈에 투자하는 관점에서 꽤 중요하게 다가왔다.

물론 HA 자체도 오픈소스 커뮤니티에 의존하는 구조이고, 개발이 멈출 가능성이 아예 없다고 할 수는 없다. 하지만 현재 규모와 활성화 수준을 보면, 단일 기업 제품보다 지속 가능성이 높다고 판단했다. 이건 어디까지나 개인적인 판단이고, 각자 상황에 따라 다를 수 있다.

HA로 넘어가기 전에 실제로 확인했던 것들

막상 HA를 써보기로 결정하고 나서도 막히는 지점이 몇 가지 있었다. 설치 방법이 여러 가지인데 뭘 선택해야 하는지, 기존에 쓰던 기기들이 HA에서 실제로 잘 잡히는지, 하드웨어는 뭘 써야 하는지 같은 것들이다. 시작 전에 미리 확인해두면 좋은 체크리스트를 정리해봤다.

  1. 내가 가진 기기들이 HA에서 지원되는지 확인한다. Home Assistant 공식 사이트의 통합 목록(integrations 페이지)에서 브랜드명으로 검색하면 지원 여부를 바로 확인할 수 있다. 로컬 통신인지 클라우드 경유인지도 여기서 확인된다.
  2. 설치 방식을 먼저 결정한다. HA OS, Docker, VM 등 설치 방식이 여러 가지인데, 처음 시작하는 경우 HA OS 방식이 가장 관리가 편하다. 이미 NAS가 있다면 Docker도 고려할 수 있다. 이 부분은 뒤에 이어지는 구축기 글에서 더 자세히 다룬다.
  3. 하드웨어 선택지를 파악한다. 라즈베리파이 4, 구형 미니PC, NAS, 전용 기기(Home Assistant Yellow 등) 중에서 고르게 된다. 기기 수가 많지 않다면 라즈베리파이 4 정도로도 충분하다.
  4. 지그비나 Z-Wave 기기가 있다면 USB 동글이 필요하다. 이 프로토콜을 쓰는 기기들은 별도 수신기 없이는 HA에서 인식이 안 된다. 미리 확인하지 않으면 설치 후에 당황하게 된다.
  5. 백업 계획을 처음부터 세운다. HA는 설정 파일과 자동화가 쌓일수록 복구가 중요해진다. 초반부터 자동 백업 설정을 해두는 게 낫다.

이 중에서 가장 많이 놓치는 부분이 4번이다. 샤오미나 아카라 기기 중에 지그비 프로토콜을 쓰는 제품들이 꽤 많은데, 미홈 앱에서는 잘 되던 게 HA에서 안 잡힌다고 당황하는 경우가 있다. USB 동글 하나로 해결되는 문제지만, 모르면 원인 파악에 시간이 걸린다.

그래서 HA가 모두에게 맞는 선택인가

솔직히 말하면, 모든 사람에게 HA가 최선의 선택이라고 하기는 어렵다. 초기 설정에 시간이 꽤 걸리고, 처음에 개념을 이해하는 데 진입 장벽이 있다. 기기 하나 연결할 때마다 통합 설정을 직접 해야 하고, 문제가 생기면 로그를 보면서 원인을 찾아야 하는 경우도 있다.

반면 구글 홈이나 애플 홈킷은 설정이 훨씬 간단하고 직관적이다. 같은 생태계 안에서 기기를 맞춰 쓸 생각이라면 굳이 HA를 쓸 이유가 없을 수도 있다.

HA가 맞는 상황을 정리하면 이렇다.

  • 브랜드가 다른 기기들을 이미 여러 개 가지고 있고, 하나로 통합하고 싶을 때
  • 클라우드 의존도를 낮추고 로컬에서 처리하고 싶을 때
  • 복잡한 자동화를 직접 설계하고 싶을 때
  • 설정 과정에서 막히더라도 찾아보면서 해결하는 걸 즐기는 편일 때

반대로 기기 종류가 적고 같은 브랜드로 맞춰져 있다면, 굳이 HA를 도입하는 게 오히려 복잡도만 높이는 결과가 될 수 있다. 이건 직접 겪어보면서 느낀 부분이라 참고 정도로만 봐주면 좋겠다.

다음 글에서는

이번 글은 왜 HA를 선택했는지에 대한 이유와 배경을 정리했다. 다음 글부터는 실제 설치 과정으로 넘어간다. HA 자체가 어떤 구조로 동작하는지 이해하고 나면 설치 방식 선택이 훨씬 쉬워지기 때문에, 다음 글에서는 HA의 구조를 최대한 쉽게 풀어서 설명할 예정이다.

설치 환경을 고민 중이라면 NAS에 Docker로 올리는 방법과 VM으로 HA OS를 설치하는 방법을 각각 정리한 글도 미리 참고해두면 도움이 된다.

같이 보면 좋은 글

시리즈 글 모아보기

댓글 남기기