Home Assistant Matter 서버 9.0 — 공식 C++ SDK를 버리고 matter.js로 다시 쓴 이유

들어가며 — 허브의 심장을 갈아 끼운 업데이트
배경 — Matter 서버는 정확히 뭘 하는 물건인가
타임라인 — 기증에서 편도 GA까지
좋아진 것 — 재시작, OTA, 커미셔닝 보안
치르는 것 — RAM 2배, 편도 티켓, 어린 코드베이스
스펙의 속도 — Matter 1.5.1, 1.6, 그리고 4주
언제 서두르지 말아야 하나
마치며
참고 자료

들어가며 — 허브의 심장을 갈아 끼운 업데이트

집에서 Home Assistant를 돌리는 사람에게 지난 6월 23일은 조용히 큰 날이었습니다. Open Home Foundation의 공지와 함께 Matter Server 앱(구 애드온)이 9.0으로 올라갔는데, 이건 버전 번호 하나가 아니라 구현체 교체였습니다. Python으로 짜고 공식 C++ Matter SDK를 감싸던 서버가, TypeScript로 처음부터 다시 쓴 matter.js 기반 서버로 바뀌었습니다.

이게 남 일이 아닌 이유는 규모에 있습니다. 발표문이 인용한 옵트인 통계 기준으로 Matter 통합은 Home Assistant 인스턴스의 38%에서 돌아가고, 전체 통합 중 사용률 12위입니다. 그 38%의 집에서 Matter 기기와 대화하는 프로세스가 통째로 다른 코드베이스로 교체된 겁니다. 그리고 이 마이그레이션은 편도입니다 — 공식 FAQ의 표현을 그대로 옮기면, 이전 서버로 되돌아갈 수 있느냐는 질문의 답은 "No"입니다.

스마트홈 생태계 전반의 지형도는 작년에 쓴 Matter/Thread 딥다이브에서 다뤘으니, 이 글은 이번 전환 하나에 집중합니다. 왜 바꿨는지, 실제로 무엇이 좋아지는지, 그리고 청구서에 뭐가 적혀 있는지.

배경 — Matter 서버는 정확히 뭘 하는 물건인가

Home Assistant의 Matter 지원은 코어 안에 들어 있지 않습니다. Matter 통합(코어)은 WebSocket으로 별도 프로세스인 Matter 서버에 붙고, 실제 Matter 컨트롤러 역할 — 커미셔닝, 세션 암호화, 구독, OTA — 은 전부 그 서버가 합니다. 월간 코어 릴리스와 서버 릴리스가 분리돼 있는 구조라서, 이번 교체도 2026.7 코어 릴리스(7월 1일)와는 별개로 앱 업데이트 한 번으로 배포됐습니다. 참고로 2026.7 릴리스 노트에서 Matter 관련 항목은 토양 수분 센서 지원 추가 정도가 전부입니다 — 진짜 큰 변화는 코어 밖에서 일어났습니다.

구조를 그림으로 놓으면 이렇습니다.

[이전]  Home Assistant (Matter 통합)
          │  WebSocket
          ▼
        python-matter-server  ── Python 래퍼
          │
          ▼
        공식 Matter SDK (C++ · project-chip/connectedhomeip)

[이후]  Home Assistant (Matter 통합)   ← 코드 변경 없음
          │  WebSocket (동일 API)
          ▼
        matterjs-server + matter.js (TypeScript 단일 스택 · Node.js 런타임)

이전 서버인 python-matter-server는 공식 C++ SDK 위에 Python을 얹은 구조였고, 2025년 3월에는 Home Assistant와 함께 CSA 인증까지 받았습니다 — 오픈소스 프로젝트로는 최초였습니다. 그런데 발표문은 이 구조를 두고 "탄탄한 출발점이었지만, 우리의 오픈소스 야심의 속도를 따라오지 못했다"고 적었습니다. 인증까지 받은 스택을 15개월 만에 버린 이유가 이 한 문장에 들어 있습니다.

matter.js는 Matter 표준을 TypeScript로 완전히 다시 구현한 프로젝트입니다. 저장소는 Matter 공식 출시 직후인 2022년 11월부터 있었고, 발표문에 따르면 Homebridge와 openHAB의 Matter 지원도 이 라이브러리 위에서 돌아갑니다. 만든 사람인 Ingo Fischer는 2025년 하반기 Open Home Foundation에 풀타임으로 합류하면서 matter.js를 재단에 기증했고, 재단은 2025년 11월 26일 뉴스레터로 Matter 서버를 matter.js 위에 다시 짓겠다는 계획을 공식화했습니다.

타임라인 — 기증에서 편도 GA까지

전환은 기습이 아니라 반년짜리 공개 이행이었습니다. 날짜는 전부 GitHub 커밋/릴리스 기록에서 확인한 것입니다.

날짜	사건
2025-11-26	OHF, matter.js 기증과 서버 재구축 계획 발표
2026-01-22	애드온 8.2.0 — 베타 플래그를 켜면 matter.js 서버로 전환(양방향 전환 가능)
2026-06-09	matterjs-server 1.0.0
2026-06-17	CSA, Matter 1.6 스펙 공개
2026-06-23	앱 9.0.0 GA — matter.js 서버가 기본값, 마이그레이션 편도. 같은 날 python-matter-server 저장소 보관(archive) 처리
2026-07-01	HA 코어 2026.7 릴리스. matter.js에 Matter 1.6.0 지원 PR 병합
2026-07-15	앱 9.1.0 — Matter 1.6.0 지원 탑재

베타 기간에는 데이터가 자동으로 마이그레이션되면서도 Python 서버로 되돌아갈 수 있었지만, 9.0.0 GA부터는 아닙니다. 그래서 공지와 FAQ가 업데이트 전 백업을 반복해서 권고합니다 — 롤백 수단이 백업뿐이기 때문입니다. 노드가 많다면 첫 시작(스토리지 마이그레이션 + 전체 인터뷰)이 꽤 걸리므로, 중간에 재시작을 걸어버리는 HA 워치독을 잠시 꺼두라는 안내도 마이그레이션 FAQ에 명시돼 있습니다.

좋아진 것 — 재시작, OTA, 커미셔닝 보안

마케팅 문구를 걷어내고 FAQ와 체인지로그에 적힌 구체적 변화만 추리면 이렇습니다.

재시작과 재연결. 이전 서버는 시작할 때마다 기기를 처음부터 찾아 전체 인터뷰를 돌렸습니다. 새 서버는 기기의 마지막 주소를 기억해 바로 붙고, 재연결 시에는 바뀐 데이터만 가져오는 부분 인터뷰를 씁니다. Thread 기기가 많은 환경에서는 Thread 네트워크의 대역폭 한계를 존중하며 연결한다는 항목도 FAQ에 따로 적혀 있습니다 — 저전력 메시 네트워크에 재시작 폭풍을 쏟아붓지 않겠다는 뜻입니다.

OTA 업데이트. 이전 서버는 기기 펌웨어 OTA를 위해 Matter 네트워크에 임시 노드를 별도로 띄웠고, FAQ 스스로 "자주 문제를 일으켰다"고 인정합니다. 새 서버는 OTA 로직을 컨트롤러 안에 통합했습니다.

커미셔닝 보안 기본값. 이전 서버는 개발/테스트 인증서만 가진 미인증 기기도 기본으로 커미셔닝해 줬습니다. DIY 기기 붙이기엔 편하지만, 악성 기기가 조용히 패브릭에 들어올 수 있는 통로이기도 했습니다. 새 서버는 이걸 뒤집어서, 테스트 인증서 기기를 붙이려면 Test-Net DCL 옵션을 명시적으로 켜야 합니다. 커미셔닝 시 인증서 폐기(revocation) 목록 확인도 추가됐습니다.

오프라인 커미셔닝. 인증서 검증에 필요한 DCL 데이터를 릴리스 시점 스냅숏으로 서버에 동봉해서, 인터넷 없이도 그 시점까지 등록된 기기는 커미셔닝할 수 있습니다. 인터넷이 연결되면 백그라운드에서 갱신합니다. 다만 README가 밝히듯 동봉 데이터는 낡을 수 있고, 그 사이 나온 기기는 오프라인 상태에서 커미셔닝이 실패할 수 있습니다 — 제어는 로컬이지만 커미셔닝 시점의 신뢰 확인은 여전히 인터넷을 원한다는 것, local-first 관점에서 기억해 둘 지점입니다.

네트워크 시각화. 서버 웹 UI에 Thread/Wi-Fi 토폴로지 뷰가 생겼습니다. 노드마다 역할(리더, 라우터, 슬리피 엔드 디바이스)이 표시되고 링크 색으로 연결 품질을 보여줍니다. 기기와 보더 라우터 사이에 홉이 여러 개 생기는 Thread 메시에서 특히 유용합니다. 정직한 각주도 함께 있습니다 — 슬리피 배터리 기기는 네트워크 정보를 자주 갱신하지 않아서, 시각화에 뜨는 "Unknown devices"나 "External routers"가 오래된 데이터일 수 있다고 FAQ가 미리 못 박아 둡니다.

이 밖에 커미셔닝을 Home Assistant의 블루투스 스택(ESPHome BLE 프록시 포함)으로 통과시키는 ble_proxy 실험 기능, 9.1.0에서 추가된 기기 시간 동기화(time_sync)와 ICD(간헐 연결 기기) 관리 실험 지원 같은 것들이 체인지로그에 쌓이고 있습니다.

치르는 것 — RAM 2배, 편도 티켓, 어린 코드베이스

이제 청구서 차례입니다.

메모리. 공식 수치입니다: 새 서버는 이전 서버의 약 2배 RAM과 조금 더 많은 CPU를 씁니다(마이그레이션 FAQ 기준, 벤더 자체 서술이며 측정 조건은 공개돼 있지 않습니다). 애드온 컨테이너에 Node.js 런타임이 통째로 들어간 구조이니 놀랄 일은 아닙니다. 릴리스 노트도 업데이트 전에 호스트의 여유 리소스를 확인하라고 안내합니다 — Raspberry Pi급 보드에서 애드온을 여럿 굴리는 흔한 구성이라면 특히 그렇습니다.

편도 마이그레이션. 다시 강조하지만 GA 이후에는 Python 서버로 돌아가는 공식 경로가 없습니다. 백업이 유일한 탈출구입니다.

갓 태어난 코드베이스. GA가 매끄럽기만 했던 것도 아닙니다. 9.0.0 출시 후 열흘 안에 애드온 패치가 네 번(9.0.1~9.0.4) 나왔고, 9.0.4의 체인지로그는 서버를 1.1.2에서 1.1.7로 올리며 "보고된 이슈 해결과 RAM/CPU 사용량 대폭 최적화"를 이유로 적었습니다. matterjs-server 체인지로그를 세어 보면 GA 이후 7월 16일까지 3주 남짓 동안 서버 릴리스가 14번입니다. 빠른 대응이라고 읽을 수도, 아직 흔들리는 중이라고 읽을 수도 있는 숫자입니다 — 둘 다 사실일 겁니다. FAQ의 트러블슈팅 섹션에는 마이그레이션 실패로 스토리지가 깨졌을 때 데이터 디렉터리를 직접 지우는 절차, 첫 시작 후 기기가 오프라인으로 남을 때(mDNS 광고 누락) 기기를 껐다 켜라는 안내가 이미 올라와 있습니다.

재인증은 아직. 2025년의 CSA 인증은 Python 기반 서버가 받은 것입니다. matterjs-server의 README는 현재 구현이 "아직 CSA 재인증을 받지 않았으며, 향후 받을 예정"이라고 명시합니다. 인증 상태가 중요한 환경이라면 지금의 서버는 그 사이 공백에 있습니다.

스펙의 속도 — Matter 1.5.1, 1.6, 그리고 4주

이번 전환의 진짜 의미는 올해 CSA의 릴리스 캘린더와 겹쳐 봐야 보입니다.

3월 31일 CSA는 Matter 1.5.1을 냈습니다. 1.5가 도입한 카메라/초인종 지원 위에 멀티스트림 전송(녹화용 고해상도 + 모바일용 저해상도 + 분석용 스트림을 한 세션으로), HEIC 스냅숏, CMAF 기반 HLS/DASH 업로드, PTZ 동작 개선을 얹은 증분 릴리스입니다. 6월 17일에는 Matter 1.6이 나왔습니다. 새 기기 카테고리는 없고, 대신 NFC만으로 커미셔닝 전 과정을 끝내는 NFC 기반 커미셔닝(1.4.1의 NFC 태그는 셋업 정보만 담고 BLE가 필요했습니다 — 천장 조명을 달기 전에 폰을 갖다 대서 등록하는 시나리오가 이제 스펙 안에 있습니다), 여러 생태계가 하나의 패브릭을 공동 관리하는 Joint Fabric, 온도조절기에 직접 명령 대신 시한부 제안을 보내는 Thermostat Suggestions가 핵심입니다.

여기서 새 스택의 속도가 드러납니다. 스펙 공개가 6월 17일, matter.js의 Matter 1.6.0 지원 PR 병합이 7월 1일, 그걸 실은 서버 1.2.0이 7월 9일, Home Assistant 사용자에게 배포된 앱 9.1.0이 7월 15일. 스펙에서 안정 채널까지 정확히 4주입니다. 발표문이 6월에 "1.6은 곧"이라고 적었을 때 그 곧은 3주였습니다. 공식 C++ SDK의 릴리스 주기에 묶여 있던 시절에는 구조적으로 내기 어려운 속도이고, "공식 SDK가 우리 속도를 못 따라온다"던 그 문장의 실증이기도 합니다.

표준 생태계 관점에서도 의미가 있습니다. 사양이 하나뿐인 구현에 사실상 종속되면 구현의 버그가 곧 표준의 동작이 됩니다. TLS나 HTTP가 그랬듯, 대규모로 굴러가는 독립 구현이 하나 더 생기는 건 표준의 건강에 좋은 일입니다 — 이제 Matter에는 상용 생태계 전반이 쓰는 C++ 구현과, 가장 큰 오픈소스 홈 플랫폼에 실배포된 TypeScript 구현이 나란히 존재합니다.

언제 서두르지 말아야 하나

정리하면, 다음 경우에는 업데이트 버튼을 바로 누르지 않는 게 합리적입니다.

호스트 메모리가 빠듯할 때. RAM 약 2배는 공식 수치입니다. 2GB급 보드에서 애드온 여러 개를 이미 꽉 채워 쓰고 있다면 먼저 계산부터 하십시오.
Matter 노드가 많고 중단이 아플 때. 첫 시작은 마이그레이션 + 전체 인터뷰로 오래 걸리고, 롤백은 백업 복원뿐입니다. 주중 저녁에 가볍게 할 일은 아닙니다.
개발/테스트 인증서 DIY 기기를 쓸 때. 직접 빌드한 Matter 펌웨어(ESP32 등)를 붙여 왔다면, 이제 Test-Net DCL 옵션을 켜야 커미셔닝이 됩니다. 몰라서 막히면 기기 고장처럼 보입니다.
인증 상태가 요건일 때. CSA 재인증 전이라는 사실이 문제가 되는 환경이라면 기다릴 이유가 됩니다.
몇 주 더 지켜보고 싶을 때. 3주에 14릴리스라는 패치 속도는 활발함의 증거인 동시에, 당신의 구성에서 밟힐 자갈이 아직 남아 있을 수 있다는 신호입니다. 이슈 트래커를 한 바퀴 돌아보고 결정해도 늦지 않습니다.

반대로 Thread 기기 수십 개가 물린 집에서 서버 재시작마다 몇 분씩 기기들이 죽어 있는 게 고질병이었다면 — 부분 인터뷰와 주소 캐시만으로도 이번 업그레이드는 값을 합니다.

마치며

세계에서 가장 큰 오픈소스 스마트홈 플랫폼이, 인증까지 받아 둔 공식 SDK 기반 스택을 15개월 만에 버리고 TypeScript 재구현으로 갈아탔습니다. 명분은 추상적인 성능이 아니라 속도의 주도권이었고, GA 4주 만에 최신 스펙(1.6)을 안정 채널에 실어 보이며 그 명분을 스스로 증명했습니다. 대가는 명시적입니다 — RAM 2배, 편도 마이그레이션, 재인증 공백, 그리고 어린 코드베이스가 겪는 초기 패치 러시.

당신의 Home Assistant가 Matter 기기 몇 개를 조용히 굴리는 중이라면, 이 전환은 아마 눈치채지 못한 채 지나갈 겁니다 — 드롭인 호환이 목표였고 대체로 그렇게 동작하고 있으니까요. 다만 업데이트 전 백업 하나는 꼭 만들어 두십시오. 이번 티켓은 편도입니다.