HAOS - Z2M 구글홈 연동, Matter Hub로 IPv6 없이 성공한 후기

 

 

홈어시스턴트 구글홈 연동, Matter Hub로 IPv6 없이 성공한 후기

홈어시스턴트(Home Assistant, 이하 HA) 기기를 구글홈에 연동하는 가장 확실한 길은 Home Assistant Matter Hub 애드온이에요. 저는 Zigbee2MQTT로 옮긴 온도센서 3개를 이 방법으로 구글홈에 올렸고, IPv6를 지원하지 않는 ipTIME 공유기에서도 성공했어요. Nabu Casa 구독도, 공유기 교체도 없이 전부 로컬로 끝냈답니다.

이 글에서는 제가 실제로 밟은 순서와, 중간에 "기기를 찾을 수 없음"이라는 실패 화면을 보고도 사실은 성공이었던 반전까지 그대로 적어 볼게요.

---

왜 Matter Hub였을까요?

제 목적은 단순했어요. Zigbee2MQTT(Z2M, Zigbee 기기를 MQTT로 HA에 붙여 주는 도구)로 옮겨 놓은 온도센서들을 구글홈 앱에서도 보고 싶다는 것이었죠.

문제는 HA에 붙은 Zigbee 기기는 HA 안에서만 존재한다는 점이에요. 구글홈은 그 존재를 모릅니다. 그래서 HA 기기를 Matter(스마트홈 기기 공통 표준) 기기인 것처럼 보이게 해 주는 다리가 필요했고, 그 다리가 바로 Home Assistant Matter Hub예요.

---

먼저 연동 방향부터 구분해야 해요

여기서 헷갈리면 며칠을 헤매게 돼요. 스마트홈 연동에는 방향이 두 개 있는데, Matter Hub는 그중 한 방향만 담당하거든요.

방향	하는 일	쓰는 도구
HA → 구글홈	HA 기기를 구글홈으로 내보내기(노출)	Matter Hub (이 글의 주제)
구글홈 → HA	구글홈 스피커를 HA에 media_player로 가져오기	Google Cast 통합

Matter Hub는 HA 엔티티(HA가 기기를 다루는 최소 단위예요)를 Matter 컨트롤러 쪽으로 내보내기만 해요. 반대로 구글홈에만 있는 기기를 HA로 끌어오는 일은 하지 못합니다. 구글홈은 기기를 받아서 쓰는 끝단이고, 다시 내보내는 통로가 없기 때문이에요.

반대 방향인 Google Cast 통합은 별개의 기능이에요. HA 공식 문서에 따르면 Cast 기기를 media_player 엔티티로 자동 발견하는데, 이 자동 발견은 mDNS(같은 네트워크에서 기기 이름을 찾는 방식)에 기대고 있어요. 그래서 서브넷이 다르면 패킷이 넘어가지 못해 IP를 직접 넣어 줘야 한답니다.

Matter Hub는 어떤 기기를 내보낼 수 있나요?

프로토콜과 상관없이 HA 안에서 엔티티가 되어 있으면 전부 가능해요. Zigbee(Z2M)든 WiFi 기기든 MQTT(Tasmota)든 상관없어요. Matter Hub가 보는 건 기기의 통신 방식이 아니라 HA 엔티티니까요.

---

시작 전 전제 조건 두 가지

구글홈 스피커가 Matter 허브 역할을 해야 해요

구글홈 앱만 깔려 있다고 Matter 기기를 붙일 수는 없어요. 집에 실제 허브 기기가 하나 있어야 합니다. 구글 지원 문서도 Matter 기기를 추가하려면 호환 허브가 설정되어 있어야 한다고 안내하고 있어요.

다행히 문턱이 낮아요. Nest Mini와 Google Home Mini 계열도 소프트웨어 업데이트를 거쳐 Wi-Fi 기반 Matter 기기의 허브 역할을 해 줘요. 저도 Google Home Mini로 붙였답니다. 다만 Thread 방식 기기까지 쓰려면 Thread 보더 라우터가 들어간 기기(Nest Wifi Pro, 2세대 Nest Hub, Nest Hub Max)가 따로 필요해요. Matter Hub 브리지는 Wi-Fi·이더넷 기반이라 Mini 급으로 충분했어요.

IPv6, 지레 포기하지 마세요

공식 문서는 Matter가 기기 발견과 통신에 IPv6를 요구한다고 분명히 적어 두고 있어요. 저도 이 문장을 보고 "우리 집 ipTIME은 IPv6를 지원 안 하는데 글렀네" 하고 접을 뻔했죠.

그런데 조금 더 들여다보니 두 가지가 다른 얘기였어요.

• 링크로컬 IPv6 주소(fe80::/64)는 모든 네트워크 인터페이스에 자동으로 할당돼요. 공유기가 인터넷용 IPv6를 지원하는지와는 별개예요.
• 다만 링크로컬은 서브넷이나 VLAN을 넘어 라우팅되지 않아요. 같은 L2 구간 안에서만 통해요. VLAN을 나눈 환경이라면 ULA(fd00::/8) 주소가 따로 필요하다고 문서가 안내해요.

제 환경은 공유기 하나에 단일 서브넷, 즉 같은 구간이었어요. 그래서 링크로컬 IPv6만으로 통신이 성립했고, 실제로 ipTIME A2004MU에서 연동에 성공했어요. 다만 "IPv6가 없어도 무조건 된다"고 일반화할 생각은 없어요. 이건 어디까지나 제 환경에서의 실증 사례예요. 요점은 해 보기도 전에 포기할 이유는 없다는 거예요.

---

1단계 — 애드온 설치, 저장소는 RiDDiX 포크로

여기서 꼭 짚고 갈 게 있어요. Home Assistant Matter Hub는 원래 t0bst4r가 만든 프로젝트인데, 공식 문서에 따르면 2026년 1월에 유지보수가 중단됐어요. 원 개발자가 개인 사정으로 개발과 지원을 이어가기 어려워졌다고 밝혔죠. 지금은 커뮤니티가 이어받은 RiDDiX 포크가 버그 수정과 신기능을 담당하고 있어요.

그래서 검색으로 나온 예전 문서를 그대로 따라가면 안 돼요. 현행 문서는 riddix.github.io/home-assistant-matter-hub 쪽이에요.

설치는 이렇게 하면 돼요.

1. 먼저, HA에서 설정 > 애드온 > 애드온 스토어로 들어가요.
2. 그다음, 우측 상단 점 세 개(⋮)를 눌러 저장소(Repositories)를 열어요.
3. https://github.com/riddix/home-assistant-addons 를 추가해요.
4. 스토어를 새로고침하고 Home Assistant Matter Hub를 찾아 설치한 뒤 시작해요.

Z2M을 설치할 때는 동글 경로(by-id) 같은 걸 일일이 잡아 줘야 해서 꽤 긴장했는데, Matter Hub는 HA 접속 정보를 알아서 인식해서 따로 설정할 게 없었어요. 허무할 정도로 쉬웠답니다.

참고로 예전 t0bst4r 버전을 쓰고 계셨다면, RiDDiX 포크는 기존 설정과 하위 호환되고 Matter 패브릭 연결과 페어링된 기기가 그대로 보존된다고 문서에 나와 있어요. 페어링을 처음부터 다시 할 필요는 없다는 뜻이에요.

---

2단계 — 브리지 만들기, 채울 건 딱 두 개예요

Matter Hub 웹 UI에서 Bridges > Create Bridge+ 로 들어가요. 브리지(HA 기기를 Matter 기기처럼 보이게 해 주는 다리)를 하나 만드는 단계예요.

입력 항목이 많아 보이지만, 실제로 채울 건 두 개뿐이에요.

채울 것

• Name: 아무 이름이나 괜찮아요. 저는 Google Home으로 했어요.
• Port: 기본값 그대로 두면 돼요. 비어 있다면 5540을 넣으면 됩니다. 공식 문서도 브리지의 필수 속성을 name / port / filter로 설명하면서 포트 기본 시작값을 5540으로 안내해요.

비워 둘 것 (특수 상황용이라 건드리지 않는 편이 안전해요)

• Country Code — 커미셔닝(기기를 내 계정에 등록하는 과정이에요)이 국가코드가 없어서 실패할 때만 KR을 넣어 보면 돼요.
• Startup Priority — 기본값 100 그대로.
• Serial Number Suffix / Unique ID Suffix — 다른 컨트롤러의 캐시 문제를 풀 때 쓰는 값이에요.
• Session Rotation, Feature Flags, Bridge Icon

참고로 Country Code나 Serial Number Suffix 같은 필드는 제가 실제 화면에서 본 항목이고, 현행 공식 문서 본문에서는 따로 설명을 찾지 못했어요. 그래서 "이런 칸이 있더라" 정도로만 받아들여 주시면 좋겠어요.

---

3단계 — Entity Filters로 필요한 것만 좁게

이 단계가 사실상 이 작업의 핵심이에요. 어떤 HA 엔티티를 구글홈에 내보낼지 고르는 곳이거든요.

브리지 설정의 Entity Filters > Include에 규칙을 추가하면 돼요. Type을 pattern으로 고르면 와일드카드(*)로 여러 엔티티를 한 번에 잡을 수 있어요.

• 예를 들어 sensor.*temperature*라고 넣으면 이름에 temperature가 들어간 센서 엔티티가 전부 걸려요.
• 기본 any 모드에서는 규칙 중 하나라도 맞으면 포함돼요. 공식 문서도 include 규칙 중 하나만 맞으면 포함되고, exclude 규칙에 걸리면 제외된다고 설명해요. 즉 제외가 우선이에요.
• pattern 말고도 domain, area, device class, label 등 열일곱 가지가 넘는 필터 타입이 있어요. 처음에는 pattern 하나로 충분했어요.

필터는 좁게 잡는 편이 좋아요

도메인 전체처럼 넓게 잡으면 배터리 잔량, 링크 품질, 각종 시스템 센서까지 전부 구글홈으로 넘어가요. 그러면 구글홈 앱이 금방 지저분해져요. 꼭 필요한 것만 좁게 고르는 편이 안전해요.

제 화면에서는 규칙을 넣는 순간 "N entities match" 처럼 실제로 걸린 엔티티 수가 표시됐어요. 패턴을 하나 칠 때마다 숫자가 튀어오르니까, 너무 넓게 잡았는지를 그 자리에서 바로 알 수 있었답니다. 이 카운터는 문서에서 확인한 게 아니라 제가 화면에서 본 것이니 참고만 해 주세요.

온도만 넣었는데 습도가 따라왔어요

예상 밖의 이득이 하나 있었어요. *temperature* 패턴 하나만 넣었는데, 구글홈에서 온도와 습도가 같이 보이더라고요.

이유는 공식 문서에서 찾을 수 있었어요. Zigbee 센서는 HA에서 온도·습도·압력·배터리가 각각 별개 엔티티로 생기는데, Matter Hub의 Auto Sensor Grouping 기능이 이들을 하나의 Matter 기기로 자동 결합해 줘요. v2.0.17부터 습도·압력·배터리 결합 플래그가 기본으로 켜져 있어서 따로 설정할 게 없다고 해요.

덕분에 *humidity* 패턴을 중복으로 넣을 뻔한 실수를 피했어요. 다만 문서를 보면 습도 엔티티는 자동 결합되면서도 자체 독립 엔드포인트를 함께 만든다고 하니(애플홈 대응 때문이에요), 컨트롤러에 따라 다르게 보일 수 있어요. 제 구글홈 환경에서는 온도 패턴 하나로 충분했다는 관찰로 봐 주시면 좋겠어요.

---

4단계 — 구글홈 앱에서 페어링하기

브리지 상세 화면으로 들어가면 페어링에 쓸 정보가 보여요.

• Manual Code: 11자리 숫자예요. 이 글에서는 1292xxxxxxx처럼 가려 뒀어요. QR 코드로도 제공돼요.
• Devices: N: 지금 노출 중인 기기 수예요.
• Connected Fabrics: 0: 아직 어떤 컨트롤러도 붙지 않았다는 뜻이에요. 페어링에 성공하면 1로 바뀝니다.

⚠️ Manual Code와 QR 코드는 집 안 기기를 등록할 수 있는 자격증명이에요. 블로그나 커뮤니티에 화면을 올릴 때는 반드시 가려 주세요. QR도 스캔하면 코드가 그대로 드러나니 함께 가려야 해요.

페어링 순서는 이렇게 진행했어요.

1. 먼저, 폰이 HA와 같은 공유기·같은 네트워크에 붙어 있는지 확인해요.
2. 그다음, 구글홈 앱에서 + (추가) > 기기 설정 > 새 기기로 들어가요.
3. 집을 고른 뒤 Matter 코드 입력을 선택하고 Manual Code를 넣어요.
4. "인증되지 않은 Matter 기기" 경고가 뜨면 계속(Continue anyway)을 누르면 돼요.

마지막 경고 화면에서 놀라실 수 있는데, 이건 정상이에요. 직접 만든 브리지는 Matter 인증(CSA 인증)을 받지 않았기 때문에 컨트롤러가 경고를 띄우는 게 예상된 동작이거든요. 구글 개발자 문서도 테스트 기기에서 이 프롬프트가 뜨면 "Add Anyway"를 고르라고 안내하고 있어요. 버그나 위험 신호가 아니랍니다.

---

하이라이트 — "기기를 찾을 수 없음"이 떠도 실패가 아닐 수 있어요

이번 작업에서 제가 얻은 가장 큰 교훈이에요.

코드를 넣고 한참 기다렸는데, 구글홈 앱이 "기기를 찾을 수 없음"이라고 띄웠어요. 솔직히 그 순간엔 포기하고 싶었어요. 그런데 혹시나 하고 Matter Hub의 로그를 열어 봤더니, 전혀 다른 이야기가 적혀 있더라고요.

진짜 성공 여부는 로그가 알려 줘요

커미셔닝이 진행되는 동안 Matter Hub 로그에는 이런 흐름이 찍혀요.

armFailSafe               → 등록 시작 (페일세이프 타이머 시작)
attestationRequest        → 기기 인증서 검증
csrRequest                → 인증서 서명 요청
addTrustedRootCertificate → 루트 인증서 설치
addNoc                    → 운영 인증서(NOC) 발급·설치
commissioningComplete     → 등록 완료

 

이 순서는 제가 우연히 본 게 아니라 Matter 표준 커미셔닝 절차 그대로예요. 구글의 Matter 문서를 보면 기기 발견 → 패스코드 세션 연결 → 기기 정보 읽기 → 국가코드 등 규제 설정 → 인증서 검증(attestation) → CSR → 루트·운영 인증서 설치 → 네트워크 프로비저닝 → 운영 네트워크에서 재발견 → CASE 세션 수립 → CommissioningComplete 순으로 진행된다고 나와 있어요.

그리고 commissioningComplete는 커미셔닝의 마지막 단계예요. 컨트롤러가 이 명령을 보내면 페일세이프 타이머까지 자동으로 풀리고, 기기는 정상 동작 상태로 들어가요. 다시 말해 이 줄이 로그에 찍혔다면 발견·인증·등록이 전부 끝났다는 뜻이에요.

제 로그에는 그 줄이 분명히 있었어요. 앱은 실패라고 했지만, 백엔드에서는 이미 성공해 있었던 거예요.

그래서 어떻게 됐냐면요

반신반의하며 구글홈 앱을 완전히 껐다가 다시 열었어요. 그랬더니 온도센서들이 이미 들어와 있더라고요. 브리지 화면의 Connected Fabrics도 0에서 1로 바뀌어 있었어요.

앱 UI가 타임아웃 때문에 실패를 먼저 표시했을 뿐이었어요. 구글 문서에도 커미셔닝 서비스와 UI 상태가 어긋날 수 있는 구조가 설명되어 있어요. 다만 "앱은 실패라는데 실제로는 성공"이라는 정확히 같은 사례를 공식 문서에서 찾지는 못했으니, 제 환경에서 실제로 겪은 일로 봐 주시면 좋겠어요.

정리하면 이거예요. 앱 화면을 믿지 말고 로그를 믿으세요.

---

그래도 안 될 때 — 발견 실패 체크리스트

로그에 아무 흔적도 없다면, 그때는 진짜 발견 실패예요. 순서대로 확인해 보면 돼요.

1. 폰의 WiFi 대역을 확인해요. 폰이 5GHz고 HA 호스트가 2.4GHz나 유선이면, mDNS가 대역을 넘지 못하는 경우가 있어요. 폰을 2.4GHz로 옮겨 보세요. 실제로 같은 SSID여도 대역 사이로 멀티캐스트가 전달되지 않아 기기 발견만 실패하는 사례가 여럿 보고돼요. 핑은 되는데 발견만 안 되는 게 전형적인 증상이에요.
2. AP 격리를 꺼요. 공유기 무선 설정의 "AP 격리 / 무선 사용자 간 통신 차단"이 켜져 있으면 기기끼리 통신 자체가 막혀요. 공식 연결 문제 가이드도 AP·클라이언트 격리는 반드시 꺼야 한다고 명시해요. 가정용 ipTIME에는 이 옵션이 아예 없거나 꺼져 있는 경우가 많아요.
3. Matter Hub 로그를 봐요. 접근 흔적이 남아 있다면 발견은 이미 된 거예요. 그러면 위의 "실패가 아닐 수 있어요" 쪽을 다시 확인해 보세요.
4. 네트워크를 나눠 쓴다면 포트를 열어요. 세그먼트가 나뉜 환경이라면 5353, 5540, 5541 (TCP·UDP)을 열어야 한다고 문서가 안내해요. 5353이 mDNS용이에요.

반대로, 건드리지 않아도 되는 것들

저는 이 문제를 풀면서 엉뚱한 곳을 만질 뻔했어요. 아래 항목들은 이번 문제와 전혀 무관했어요.

• 무선 확장 기능(WDS, 이지메시)
• 공유기의 허브·AP 모드 전환
• 내부 게이트웨이 설정

"안 건드려도 되는 것"을 아는 것도 시간을 아껴 주는 정보라고 생각해요.

---

결과 — 무엇이 남았나요

• 온도센서 3개를 구글홈에 노출하는 데 성공했어요. 각각 온도와 습도가 함께 표시돼요.
• IPv6를 지원하지 않는 ipTIME A2004MU에서도 동작했어요. 공유기를 바꾸지 않았어요.
• Nabu Casa 구독도 하지 않았어요. 전부 로컬 통신으로 끝났어요.
• 앞으로 다른 기기를 Z2M으로 옮길 때마다, 이 브리지의 Entity Filter에 한 줄 추가하면 구글홈에 자동으로 올라가요.

---

자주 묻는 질문

Q. 구글홈 스피커가 없어도 되나요?
아니요. Matter 기기를 추가하려면 허브 역할을 하는 실제 기기가 필요해요. 다만 Google Home Mini나 Nest Mini 정도면 Wi-Fi 기반 Matter 기기에는 충분했어요.

Q. 구글홈에 있는 기기를 HA로 가져올 수도 있나요?
Matter Hub로는 안 돼요. 이 도구는 HA → 구글홈 한 방향 전용이에요. 구글홈 스피커 자체를 HA에서 다루고 싶다면 Google Cast 통합을 쓰면 돼요.

Q. "인증되지 않은 기기" 경고가 뜨는데 괜찮나요?
직접 만든 브리지는 Matter 인증을 받지 않았기 때문에 나오는 정상적인 안내예요. 그대로 진행하면 됩니다.

Q. 습도 패턴도 따로 넣어야 하나요?
제 구글홈 환경에서는 온도 패턴 하나로 습도까지 같이 나왔어요. Auto Sensor Grouping이 자동으로 묶어 주기 때문이에요. 컨트롤러에 따라 다를 수 있으니 먼저 온도만 넣고 확인해 보세요.

---

마무리

정리하면, Home Assistant Matter Hub는 HA에 있는 기기를 구글홈으로 내보내 주는 다리예요. 저장소는 RiDDiX 포크를 쓰고, 브리지는 Name과 Port만 채우고, Entity Filter로 필요한 것만 좁게 고르면 준비가 끝나요.

그리고 가장 기억에 남는 건 역시 이거예요. 구글홈 앱이 "기기를 찾을 수 없음"이라고 해도 그게 끝이 아니에요. Matter Hub 로그에 commissioningComplete가 찍혔다면 이미 성공한 거고, 앱을 껐다 켜면 기기가 조용히 들어와 있을 수 있어요.

IPv6를 지원하지 않는 공유기라고 미리 접지 않으셨으면 좋겠어요. 저도 안 될 거라 생각하고 시작했는데, 막상 해 보니 되더라고요. 한 번만 붙여 두면 그다음부터는 필터에 한 줄 추가하는 일이 전부라, 처음의 수고가 꽤 오래 값을 해 준답니다.