Shelly ThreadLink가 Thread를 IP 네트워크로 바꾸는 것은 아닙니다. Thread는 처음부터 IPv6를 기반으로 구축되었습니다. 달라지는 점은 Shelly가 이 네트워크를 사용하는 방식입니다. Thread를 주로 Matter용으로 할당하고 공급업체 API, 클라우드 연결 및 고급 기능은 Wi-Fi에 유지하는 대신, ThreadLink는 이러한 경로 중 여러 가지를 동일한 저전력 메시를 통해 전달하도록 설계되었습니다.
따라서 ThreadLink는 또 하나의 Matter 호환성 발표보다 더 흥미롭습니다. 약속대로 구현된다면 Thread는 스마트 홈의 저전력 IP 에지가 될 수 있습니다. 릴레이, 스위치, 센서 및 제어 장치가 Thread를 통해 통신하는 동안 Home Assistant, 서버, Wi-Fi 기기 및 이더넷 시스템은 더 넓은 로컬 네트워크의 일부로 남게 됩니다. 다만 펌웨어는 아직 제공되지 않았으며, Shelly는 현재 9월 3일 발표 후 약 3개월 뒤에 옵트인 업데이트를 제공할 계획입니다.
Shelly ThreadLink란 무엇인가요?
ThreadLink는 사용 가능한 Shelly Gen4 기기에서 Thread를 지원하는 무선 기능을 주로 하나의 애플리케이션 경로로 제한하지 않고 더 광범위한 IP 연결로 사용하는 새로운 대체 펌웨어입니다.
Shelly는 공식 ThreadLink 발표에서 이 펌웨어가 Thread를 통해 IPv6 네트워킹을 실행하면서 TCP와 RPC/UDP 통신을 지원할 것이라고 밝혔습니다. 동일한 저전력 무선 기능이 다음을 전달하도록 설계되었습니다.
- Matter 연결,
- Shelly Cloud 트래픽,
- Shelly RPC 및 API 통신,
- 기기 간 직접 제어,
- 구성 및 진단,
- 더 심층적인 Home Assistant 통합.
핵심 아키텍처 변경은 다음과 같습니다.
일반적인 현재 모델
Matter
|
Thread
Shelly 기기 ───── Wi-Fi ───── Shelly API
|
└─────────── Wi-Fi ───── 클라우드
THREADLINK 방향
Matter
|
Shelly API ─────── Thread ───── 클라우드 경로
|
로컬 P2P
기기의 공급업체별 측면에 Wi-Fi를 사용하고 Thread가 Matter를 전달하도록 하는 대신, Shelly는 Thread 자체가 여러 애플리케이션에 동시에 IP 전송을 제공하도록 하려 합니다.
이 구분이 중요한 이유는 Matter와 Thread가 네트워크의 동일한 계층이 아니기 때문입니다.
Shelly ThreadLink는 지금 사용할 수 있나요?
아니요. ThreadLink는 발표되었지만 프로덕션 펌웨어는 아직 정식으로 제공되지 않습니다.
Shelly는 2026년 9월 3일 발표 후 약 3개월이 지나면 사용 가능한 Gen4 기기용 별도 무료 옵트인 펌웨어로 제공할 예정이라고 밝혔습니다.
사용자는 기기별로 표준 Wi-Fi 중심 펌웨어를 실행할지 ThreadLink를 실행할지 선택하게 됩니다.
| ThreadLink 상태 | 현재 상태 |
|---|---|
| 발표됨 | 예 — 2026년 9월 3일 |
| 정식 제공 | 아직 아님 |
| 대상 하드웨어 | 사용 가능한 Shelly Gen4 기기 |
| 펌웨어 유형 | 별도 옵트인 업데이트 |
| 예상 시기 | 발표 후 약 3개월 |
| 가격 | 무료 업데이트로 제공 예정 |
이는 ThreadLink를 현재 모든 Gen4 소유자가 바로 활성화할 수 있는 기능이 아니라, 발표된 아키텍처로 취급해야 한다는 의미입니다.
또한 모든 Gen4 모델이 해당 펌웨어를 받게 될 것이라고 주장하기에는 아직 이르다는 뜻이기도 합니다. Shelly는 구체적으로 지원 대상 Gen4 기기라고 명시하고 있으므로 최종 호환 목록이 중요합니다.
Thread는 이미 IP 네트워크가 아니었나요?
그렇습니다. 이는 바로잡아야 할 가장 중요한 오해입니다.
Thread는 IEEE 802.15.4 무선 통신 위에서 6LoWPAN을 사용하는 IPv6 기반 메시 네트워크로 설계되었습니다. Thread Group의 Thread의 IPv6 기반에 대한 설명은 Matter가 존재하기 수년 전으로 이 설계 원칙을 거슬러 올라갑니다.
네트워킹 스택은 다음과 같이 단순화할 수 있습니다.
애플리케이션
Matter
제조업체 프로토콜
기타 IP 서비스
|
v
전송 계층
UDP / TCP
|
v
네트워크
IPv6
|
v
적응 계층
6LoWPAN
|
v
무선
IEEE 802.15.4
따라서 Thread는 많은 사람이 흔히 설명하는 것처럼 Matter 전용 무선 프로토콜이 아닙니다.
Thread는 그 위에서 애플리케이션 프로토콜을 전달할 수 있는 저전력 IP 네트워크입니다.
현재 Matter는 가장 눈에 띄는 소비자 스마트 홈 애플리케이션이지만, Thread 자체는 애플리케이션 계층에 구애받지 않도록 설계되었습니다.
ThreadLink는 Thread를 IP 네트워크로 만드는 것이 아닙니다. 이미 IP 네트워크인 Thread를 더욱 IP 네트워크답게 사용합니다.
ThreadLink에서 실제로 새로운 점은 무엇인가요?
새로운 점은 IPv6 자체가 아닙니다. 하나의 소비자 IoT 기기가 Wi-Fi에 의존하는 경우가 많은 여러 애플리케이션 경로에 Thread를 사용하도록 했다는 점입니다.
MATTER 파이프로서의 THREAD
Matter
|
Thread
↓
네트워크로서의 THREAD
Matter ─────────┐
|
Shelly RPC ─────┤
|
로컬 API ──────┼── IPv6 / Thread
|
P2P 로직 ──────┤
|
클라우드 경로 ─────┘
이로 인해 무선 통신의 역할이 달라집니다.
이제 Thread는 다른 생태계가 Matter를 통해 릴레이를 제어할 수 있기 때문에서만 유용한 것이 아닙니다. Shelly 자체의 애플리케이션 트래픽, 로컬 로직, 구성, 진단 정보, 그리고 잠재적으로 소프트웨어 업데이트까지 전달할 수 있습니다.
Shelly는 ThreadLink가 빠른 로컬 통신을 위해 UDP를 지원하고, 구성 데이터와 진단 정보처럼 더 크거나 안정성이 중요한 전송을 위해 완전한 TCP 지원을 제공한다고 설명합니다.
이는 Thread에 연결된 소비자 기기가 할 수 있는 일을 훨씬 더 폭넓게 해석한 것입니다.
Matter는 왜 Shelly의 모든 기능을 노출하지 않을까요?
상호 운용성과 제조업체 차별화는 서로 다른 문제를 해결하기 때문입니다.
Matter는 제조업체와 스마트 홈 플랫폼에 표준화된 기기 모델을 제공합니다. Matter 호환 릴레이는 Apple Home, Google Home, Amazon Alexa, SmartThings 또는 Home Assistant가 각 플랫폼마다 완전히 다른 독점 프로토콜을 구현하지 않아도 이해할 수 있는 방식으로 알려진 기능을 노출할 수 있습니다.
이러한 표준화는 가치가 있습니다.
하지만 제조업체는 표준화된 Matter 모델을 넘어서는 기능을 여전히 노출할 수 있습니다. 예를 들면 다음과 같습니다.
- 더 상세한 에너지 측정,
- 진단 정보,
- 특수 릴레이 동작,
- 기기별 구성,
- 스크립팅 또는 자동화 기능,
- 고급 상태 정보,
- 그리고 공급업체 관리 기능.
오늘날에는 대개 다음과 같은 두 개의 병렬 경로가 만들어집니다.
기기
|
+-- Matter
| |
| v
| 표준 기능
| Apple / Google / HA
|
+-- 공급업체 API
|
v
고급 기능
진단
구성
ThreadLink는 서로 다른 두 네트워크 전송 방식을 요구하지 않고 이 두 경로를 모두 유지하려고 합니다.
Matter
\
\
Thread
/
/
Shelly RPC
Shelly는 전용 Home Assistant 모듈을 통해 Matter 데이터 모델이 제공하는 범위를 넘어서는 더 광범위한 Shelly 기능 세트를 사용할 수 있게 될 것이라고 말합니다.
따라서 ThreadLink가 중요한 이유는 Matter가 Thread에서 유일한 애플리케이션일 필요 없이 Thread에서 하나의 애플리케이션으로 유지될 수 있기 때문입니다.
Wi-Fi 없이 Shelly 기기끼리 서로 제어할 수 있을까?
Shelly의 ThreadLink 설계에 따르면 그렇습니다.
Shelly는 ThreadLink 기기가 API를 통해 Thread 메시를 사용하여 직접 통신할 수 있으므로 장면, 인터록, 자동화를 P2P로 실행할 수 있다고 말합니다.
중요한 부분은 장애 발생 경로입니다.
Shelly는 다음과 같은 경우에도 기기 간 관계가 계속 작동할 수 있다고 말합니다.
- 인터넷 연결이 끊기며,
- Shelly Cloud에 연결할 수 없고,
- 또는 집의 Wi-Fi 네트워크가 중단됩니다.
따라서 간단한 관계는 다음과 같이 나타낼 수 있습니다.
벽 스위치
|
Thread
|
v
릴레이
항상 다음을 요구하는 대신:
벽 스위치
|
v
Wi-Fi / 라우터
|
v
홈 서버
|
v
Wi-Fi / 라우터
|
v
릴레이
그렇다고 서버 경로가 잘못된 것은 아닙니다.
이는 모든 로컬 동작이 반드시 Home Assistant를 사용해야 하는 것은 아니라는 뜻입니다.
로컬 제어에도 여전히 Home Assistant가 필요한가?
단순한 기기 간 관계라면 항상 그런 것은 아닙니다. 더 광범위한 오케스트레이션에서는 Home Assistant가 여전히 전혀 다른 역할을 합니다.
하나의 로컬 벽 스위치가 하나의 릴레이를 켜는 것은 여러 시스템을 결합하는 자동화와 본질적으로 다릅니다.
기기 수준 로직으로 처리할 수 있는 항목:
- 간단한 스위치-릴레이 관계,
- 인터록,
- 기본 장면,
- 그리고 즉각적인 폴백 동작.
홈 자동화 서버는 다음과 같은 로직에 더 적합합니다.
만약
태양광 잉여 전력 > 3000 W
그리고
배터리 SOC > 80%
그리고
방에 사람이 있음
그리고
전기 요금이 낮음
그 다음
HVAC / 가전 부하 활성화
이 워크플로는 에너지, 재실 상태, 가격, 일정, 그리고 잠재적으로 여러 프로토콜을 아우릅니다.
이는 더 높은 오케스트레이션 계층에 속합니다. Home Assistant 로컬 처리로 향하는 더 광범위한 움직임도 같은 원칙을 따릅니다. 적절한 의사 결정은 집 안 가까이에 두고, 실제로 필요한 작업에만 클라우드 의존성을 남겨 두는 것입니다.
기기 수준 로컬 제어
스위치
|
Thread P2P
|
릴레이
서버 수준 로컬 제어
태양광 ─────┐
에너지 미터 ┤
재실 상태 ──┼── Home Assistant ── HVAC
일정 ───────┤
기타 IoT ───┘
로컬 우선이 항상 서버 우선을 의미하는 것은 아닙니다.
견고한 스마트 홈은 간단한 동작에 로컬 기기 간 관계를 활용하고, 홈 서버는 시스템 간 로직, 기록, 정책, 대시보드 및 상태 관리에 집중하도록 할 수 있습니다.
ThreadLink는 Wi-Fi 없이 어떻게 클라우드에 연결할 수 있을까요?
ThreadLink의 더욱 독특한 약속 중 하나는 엔드포인트가 Thread 기기로 유지되면서도 Shelly Cloud에 액세스할 수 있다는 것입니다.
기기 자체에는 이 경로를 위해 Wi-Fi 자격 증명이 필요하지 않습니다.
Shelly는 이 아키텍처를 다음과 같이 설명합니다.
Shelly ThreadLink 기기
|
v
IPv6 / Thread
|
v
Thread 보더 라우터
|
v
NAT64
|
v
IPv4 인터넷 서비스
|
v
Shelly Cloud
이러한 개념은 Thread의 broader한 발전 방향과도 맞닿아 있습니다. Thread 1.4는 Thread 네트워크에서 인터넷 서비스로 이어지는 표준 경로에 관한 추가 작업을 공식화했으며, 여기에는 네트워크 경계에서의 IPv6-IPv4 연결도 포함됩니다.
중요한 개념적 변화는 다음과 같습니다.
이제 클라우드 연결이 엔드포인트의 Wi-Fi 연결을 반드시 의미하지는 않습니다.
저전력 기기는 로컬에서 Thread를 사용하고, 네트워크 상위 단계의 IP 라우팅을 통해 외부 서비스에 액세스할 수 있습니다.
그렇다고 ThreadLink가 로컬 전용이라는 뜻은 아닙니다.
이는 로컬 기기 통신과 선택적 클라우드 연결이 동일한 IP 아키텍처를 공유할 수 있다는 점을 보여 줍니다.
Thread 보더 라우터는 실제로 무엇을 할까요?
Thread 보더 라우터는 Thread 메시를 더 넓은 IP 네트워크에 연결합니다. 기본적으로 라우터이며, 모든 스마트 홈 명령을 변환하는 프로토콜 변환기가 아닙니다.
Thread Group의 Thread 보더 라우터 역할에 대한 설명은 이러한 차이를 명확히 보여 줍니다.
기존 스마트 홈 아키텍처는 흔히 다음과 같은 형태입니다.
Zigbee 기기
|
v
Zigbee 네트워크
|
v
벤더 허브
|
프로토콜 변환
|
v
IP 네트워크
반면 Thread는 기기 네트워크 자체에서 IP를 사용합니다.
Thread 기기
|
IPv6 / Thread
|
v
보더 라우터
|
IP 라우팅
|
v
홈 LAN
보더 라우터는 물리적 네트워크 세그먼트 간에 패킷을 전달합니다.
Thread의 모든 애플리케이션 명령을 독점 LAN 프로토콜로 변환할 필요가 없습니다.
즉, Home Assistant는 로컬 네트워크의 다른 위치에 있어도 됩니다.
Thread 기기
|
Thread 메시
|
보더 라우터
|
이더넷 / Wi-Fi LAN
|
+-- Home Assistant
+-- 홈 서버
+-- 기타 IP 서비스
따라서 Matter 컨트롤러와 Thread 보더 라우터는 서로 다른 역할을 수행합니다. 보더 라우터는 네트워크 연결성을 제공하고, Matter는 해당 네트워크 위에서 애플리케이션 및 컨트롤러 관계를 제공합니다. 여러 플랫폼이 동일한 Matter 기기를 독립적으로 제어하는 경우, 여러 Matter 컨트롤러는 별도의 신뢰 및 소유권 계층을 추가하며, Thread 라우팅만으로는 이 문제를 해결할 수 없습니다.
트래픽이 Thread 메시를 벗어나면 일반적인 IP 규칙이 여전히 적용됩니다. Home Assistant 네트워크 연결성은 여전히 사용 가능한 주소 지정, 라우팅, 정책, 그리고 컨트롤러와 엔드포인트 사이의 정상적인 반환 경로에 달려 있습니다.
ThreadLink는 Thread가 Wi-Fi를 대체한다는 의미인가요?
아니요. Thread와 Wi-Fi는 서로 다른 유형의 트래픽에 맞게 최적화되어 있습니다.
현재 Home Assistant의 Thread 문서에서는 Thread를 저전력 및 저대역폭 기술로 설명하며, 비교적 적은 양의 데이터를 주고받는 장치에 특히 적합하다고 안내합니다.
| 워크로드 | 자연스러운 네트워크 |
|---|---|
| 동작 센서 | Thread |
| 벽 스위치 | Thread |
| 릴레이 | Thread |
| 도어록 | Thread |
| 저속 환경 센서 | Thread |
| 보안 카메라 | Wi-Fi / 이더넷 |
| 비디오 디스플레이 | Wi-Fi / 이더넷 |
| 노트북 | Wi-Fi / 이더넷 |
| NAS | 이더넷 |
저전력 릴레이에는 Wi-Fi의 대역폭이 필요하지 않습니다.
4K 보안 카메라를 Thread가 IP 기반이라는 이유만으로 Thread에 연결할 필요는 없습니다.
Thread는 새로운 Wi-Fi가 되어가는 것이 아닙니다. 동일한 홈 네트워크의 저전력 IP 엣지가 될 수 있습니다.
Thread는 홈 LAN의 저전력 엣지가 되어가고 있을까요?
이 점에서 ThreadLink는 개별 Shelly 펌웨어 발표보다 더 흥미롭습니다.
미래의 로컬 네트워크는 서로 격리된 여러 스마트 홈 생태계라기보다 여러 물리적 전송 방식에 걸쳐 구축된 하나의 IP 아키텍처에 가까운 형태가 될 수 있습니다.
홈 서버
|
|
홈 IP 네트워크
|
+-----------------+----------------+
| | |
이더넷 Wi-Fi THREAD
| | |
NAS 카메라 릴레이
서버 휴대폰 센서
워크스테이션 TV 스위치
잠금장치
엔드포인트의 모든 장치가 동일한 무선 기술을 사용할 필요는 없습니다.
적절한 경우 상위 계층이 표준 라우팅을 통해 통신할 수 있다는 점이 더 중요합니다.
이는 Thread, Wi-Fi, 이더넷이 하나의 승자를 두고 경쟁하도록 만드는 것과는 근본적으로 다릅니다.
미래의 스마트 홈에는 하나의 무선 네트워크만 존재하지 않을 수 있습니다. 여러 물리적 네트워크에 걸쳐 하나의 IP 아키텍처가 구축될 수 있습니다.
ThreadLink는 Home Assistant에 어떤 변화를 가져올까요?
ThreadLink는 Home Assistant에 동일한 물리적 Shelly 장치로 연결되는 두 가지 유용한 경로를 제공할 수 있습니다.
첫 번째는 표준 Matter입니다.
Shelly 기기
|
Thread를 통한 Matter
|
Thread 보더 라우터
|
Home Assistant Matter 컨트롤러
|
표준 Matter 기능
두 번째는 Shelly가 계획 중인 공급업체별 경로입니다.
Shelly 기기
|
Thread를 통한 Shelly RPC
|
Thread 보더 라우터
|
Home Assistant
|
Shelly 전용 기능
공식 Home Assistant Matter 아키텍처는 이미 네트워크와 애플리케이션의 구분을 명확히 보여 줍니다. Matter는 기기에 따라 Wi-Fi, 이더넷 또는 Thread를 통해 통신할 수 있는 애플리케이션 계층 제어 프로토콜입니다.
ThreadLink는 이러한 계층형 설계를 기반으로 합니다.
Matter는 생태계 간 상호 운용성을 제공하는 동시에 Shelly 통합은 기기별 고급 기능을 더 깊이 유지할 수 있습니다.
이는 사용자에게 상호 운용성과 고급 공급업체 기능 중 하나를 선택하도록 강요하는 것보다 더 발전된 아키텍처입니다.
오늘날 하나의 Thread 네트워크가 정말 가능할까요?
항상 그런 것은 아닙니다. 오늘날의 Thread 구축 환경은 이상적인 아키텍처가 시사하는 것보다 여전히 더 분산되어 있을 수 있습니다.
Home Assistant는 현재 Thread 통합을 진행 중인 작업으로 설명하며, 한 가정에 존재하는 서로 다른 Thread 네트워크를 명시적으로 추적합니다.
가정에서는 다음과 같은 구성이 발견될 수 있습니다.
Apple Thread 네트워크
|
서로 다른 자격 증명
Google Thread 네트워크
|
서로 다른 자격 증명
Home Assistant Thread 네트워크
|
different credentials
서로 다른 Thread 네트워크에 있는 기기들은 모두 Thread를 사용한다는 이유만으로 자동으로 하나의 대규모 메시가 되지 않습니다.
Home Assistant는 사용자가 기존 네트워크를 확인하고, 지원되는 경우 Home Assistant 보더 라우터를 선호하는 기존 네트워크에 연결하도록 도울 수 있습니다. 그러나 모든 가정에서 소비자 생태계가 완벽하게 통합된 하나의 Thread 메시와 동등한 수준에 도달한 것은 아직 아닙니다.
이는 ThreadLink에 대한 중요한 현실 점검입니다.
기술적으로 우아한 IP 아키텍처도 보더 라우터 호환성, 공유 자격 증명, 네트워크 토폴로지, 실제 구현 지원 여부에 여전히 좌우됩니다.
Thread 1.4는 상황을 어떻게 바꿀까요?
Thread 1.4는 생태계를 통합 네트워크라는 개념에 한층 더 가깝게 만듭니다.
Thread Group은 주요 개선 사항 중 하나를 더 쉬워진 하나의 메시 네트워크라고 설명합니다.
업데이트된 기기와 서로 다른 생태계의 보더 라우터가 기존 Thread 네트워크를 인식하고 참여하도록 하는 것이 목표입니다. 불필요하게 또 다른 메시를 생성하지 않도록 하기 위해서입니다.
Thread 1.4에는 다음과 같은 기능도 추가되거나 개선되었습니다.
- 클라우드 연결을 향한 표준화된 경로,
- 인프라 기반 Thread,
- 네트워크 진단 및 문제 해결 가시성,
- 생태계 간 네트워크 통합,
- 및 커미셔닝 개선
이로써 ThreadLink를 더 넓은 맥락에서 이해할 수 있습니다.
초기 THREAD
저전력 IPv6 메시
|
Matter가 지배적인 표준이 됨
소비자 애플리케이션
THREAD 1.4
더 나은 네트워크 통합
더 나은 보더 라우터 인프라
클라우드 경로
진단
|
v
THREADLINK 아이디어
Matter
공급업체 API
클라우드
P2P
|
동일한 저전력 IP 전송
따라서 ThreadLink는 모든 공급업체가 동일한 접근 방식을 채택할 것이라는 증거가 아닙니다.
하지만 이는 Thread의 네트워크 아키텍처가 항상 가능하게 해 온 애플리케이션 다양성의 구체적인 사례입니다.
모든 스마트 홈 자동화가 홈 서버를 거쳐야 할까요?
아니요. 복원력 있는 시스템은 동작의 복잡도와 중요도에 따라 로직을 분산할 수 있습니다.
| 계층 | 적절한 책임 |
|---|---|
| 기기 | 즉각적인 로컬 동작 및 대체 동작 |
| Thread 메시 | 저전력 로컬 IP 전송 및 피어 통신 |
| 보더 라우터 | Thread와 더 넓은 LAN 간 라우팅 |
| Home Assistant | 기기 간 및 프로토콜 간 오케스트레이션 |
| 홈 서버 | 지속적인 서비스, 자동화, 기록, 정책 |
| NAS | 백업 및 영구 데이터 |
| 클라우드 | 선택적 원격 서비스 및 공급업체 기능 |
간단한 인터록에는 반드시 서버 왕복이 필요하지는 않습니다.
집 전체의 에너지 자동화에는 서버가 필요할 가능성이 높습니다.
이러한 분리는 한 계층의 장애가 모든 로컬 기능을 자동으로 제거하지 않기 때문에 네트워크의 복원력을 높일 수 있습니다. 또한 실제 Home Assistant 성능 경로가 Home Assistant를 실행하는 CPU뿐 아니라 무선 통신, 네트워크, 브로커, 대상 기기 및 저장소를 포함하는 이유도 설명해 줍니다.
ThreadLink가 홈 서버의 중요성을 낮출까요?
홈 서버가 프로토콜 게이트웨이로서는 덜 중요해질 수 있지만, 오케스트레이션 계층으로서는 역할이 더 명확해질 수 있습니다.
기존 스마트 홈은 많은 기기 네트워크가 홈 IP 네트워크에 직접 참여할 수 없었기 때문에 브리지가 계속 추가되었습니다.
기존 모델
Zigbee 기기 ── 공급업체 허브 ──┐
|
기타 기기 ─── 게이트웨이 ─────┼── 홈 서버
|
Wi-Fi 기기 ─────────────────┘
보다 IP 중심적인 아키텍처는 다음과 같이 달라질 수 있습니다.
기기 계층
Thread 기기
Wi-Fi 기기
이더넷 기기
|
v
IP 네트워크 계층
|
v
제어 계층
Home Assistant
|
+-- 자동화
+-- 상태
+-- 기록
+-- 정책
+-- 대시보드
+-- 프로토콜 간 로직
|
v
데이터 계층
백업
NAS
영구 저장소
서버가 존재 이유를 입증하기 위해 더 이상 모든 패킷이 서버를 거칠 필요는 없습니다.
그 가치는 점점 더 큰 그림을 유지하는 데서 비롯됩니다.
- 어떤 기기가 존재하는지
- 현재 어떤 상태인지
- 서로 관련 없는 시스템이 어떻게 상호 작용하는지
- 어제 무슨 일이 있었는지
- 어떤 자동화를 실행해야 하는지
- 서비스가 실패할 때 어떻게 동작해야 하는지
- 구성과 기록이 어떻게 보호되는지
이러한 역할에는 서로 다른 스토리지 및 복구 요구 사항이 있습니다. Home Assistant 영구 데이터를 임시 런타임 상태와 분리하면 이 아키텍처의 데이터 계층을 훨씬 쉽게 보호할 수 있습니다.
Thread는 프로토콜 변환의 필요성을 줄여 주지만 홈 오토메이션 소프트웨어의 필요성까지 줄여 주는 것은 아닙니다.
그렇다고 Home Assistant에 갑자기 강력한 하드웨어가 필요하다는 뜻은 아닙니다. 일반적인 자동화에 필요한 현재 Home Assistant 서버 하드웨어 요구 사항은 여전히 높지 않습니다. 일반적으로 서버 작업량을 크게 만드는 것은 카메라, 장기간의 기록, 로컬 음성 기능, 데이터베이스 및 추가 서비스입니다.
이러한 서비스 중 여러 가지를 함께 운영할 예정이라면 스마트 홈 서버 규모 산정은 Thread 기기 수가 아니라 전체 서비스 스택을 기준으로 해야 합니다.
Shelly Gen4 소유자는 Wi-Fi에서 ThreadLink로 전환해야 할까요?
그러한 권고를 하기에는 아직 이릅니다.
펌웨어는 아직 정식 출시되지 않았고, 최종 지원 기기 목록이 중요하며, 기존 Thread 네트워크 및 Border Router와의 실제 상호 운용성은 시연 환경을 벗어나 테스트해야 합니다.
ThreadLink를 사용할 수 있게 되면 Gen4 소유자는 다음을 평가해야 합니다:
- 사용 중인 정확한 Shelly 기기가 지원 대상인지 여부
- 적합한 Thread Border Router가 이미 있는지 여부
- 가정의 Thread 네트워크가 통합되어 있는지 또는 분할되어 있는지 여부
- 새 Home Assistant 모듈을 통해 필요한 Shelly 기능이 작동하는지 여부
- 클라우드 액세스가 필요한지 여부
- 기기 간 직접 로직이 유용한지 여부
- 기존 Wi-Fi 설치 환경이 이미 안정적으로 작동하는지 여부
| 상황 | ThreadLink 전망 |
|---|---|
| Wi-Fi Shelly 기기가 이미 완벽하게 작동함 | 서둘러 전환할 이유 없음 |
| 릴레이가 밀집된 설치 환경 | 잠재적으로 흥미로움 |
| Matter와 더 심층적인 Shelly 기능 필요 | 지켜볼 만한 강력한 사용 사례 |
| Wi-Fi 장애 중 로컬 P2P를 원함 | 뛰어난 아키텍처상의 이점 |
| Thread Border Router 없음 | LAN/클라우드 액세스에 추가 인프라 필요 |
| 여러 개로 분할된 Thread 네트워크 | 먼저 토폴로지를 이해해야 함 |
| 지원되지 않는 Gen4 모델 | ThreadLink를 사용하지 못할 수 있음 |
따라서 2026년의 올바른 입장은 발표만을 근거로 정상 작동 중인 설치 환경을 마이그레이션하기보다 구현 상황을 지켜보는 것입니다.
Thread가 스마트 홈의 로컬 IP 네트워크가 되어 가고 있을까요?
Thread가 스마트 홈의 유일한 로컬 네트워크가 될 가능성은 낮습니다. 대신 해당 네트워크의 저전력 IP 엣지가 될 가능성이 더 큽니다.
이더넷은 서버, NAS 기기 및 고정형 고대역폭 시스템에 적합한 자연스러운 전송 수단으로 남습니다.
Wi-Fi는 휴대폰, 노트북, 카메라, 디스플레이 및 훨씬 더 높은 대역폭이 필요한 기기에 적합한 자연스러운 무선 네트워크로 남습니다.
Thread는 저전력 엣지에 적합합니다.
- 센서,
- 릴레이,
- 스위치,
- 잠금장치,
- 제어,
- 그리고 비교적 적은 양의 데이터를 교환하는 기타 기기
Shelly ThreadLink가 흥미로운 이유는 이 엣지를 하나의 애플리케이션만을 위한 격리된 영역으로 취급하지 않기 때문입니다.
Matter는 표준화된 생태계 제어 기능을 제공할 수 있습니다.
Shelly RPC는 더 풍부한 제조업체 기능을 제공할 수 있습니다.
피어 통신을 사용하면 간단한 작업을 로컬에서 처리할 수 있습니다.
Border Router는 메시를 더 넓은 LAN에 연결할 수 있습니다.
Home Assistant는 여러 프로토콜을 아우르며 오케스트레이션할 수 있습니다.
또한 엔드포인트 자체가 Wi-Fi에 연결되지 않아도 클라우드 연결을 선택 사항으로 유지할 수 있습니다.
전용 로컬 시스템에서 이러한 오케스트레이션 계층을 사용하려는 사용자에게 ZimaBoard 2 스마트 홈은 확장 가능한 상시 작동 서버에 컨트롤러를 유지하면서 Thread Border Router와 엔드포인트 라디오는 네트워크의 별도 구성 요소로 두는 한 가지 예입니다.
따라서 미래의 스마트 홈에서는 Thread, Wi-Fi 및 이더넷 중 하나를 선택하기보다 동일한 IP 아키텍처 안에서 각각에 역할을 부여하는 것이 더 중요해질 수 있습니다.
이것이 바로 ThreadLink의 더 큰 개념입니다.
Thread는 처음부터 IP 네트워크였습니다.
Shelly는 단지 Thread를 그런 방식으로 사용하기 시작하는 것입니다.
FAQ: Shelly ThreadLink 및 Thread 스마트 홈 네트워킹
Shelly ThreadLink란 무엇인가요?
ThreadLink는 적합한 Shelly Gen4 기기를 위한 옵트인 펌웨어로 발표되었습니다. Shelly에 따르면 이 기능은 기기의 Thread 라디오를 사용해 동일한 저전력 IP 메시에서 Matter, Shelly RPC/API 트래픽, 클라우드 연결 및 기기 간 직접 통신을 전달합니다.
Shelly ThreadLink를 지금 사용할 수 있나요?
아니요. Shelly는 2026년 9월 3일 ThreadLink를 발표했으며, 현재 적합한 Gen4 기기에 대해 약 3개월 후 무료 옵트인 펌웨어를 출시할 계획입니다.
모든 Shelly Gen4 기기가 ThreadLink를 지원하나요?
Shelly는 적합한 Gen4 기기에 대한 업데이트만 약속했습니다. 최종 호환성 목록은 펌웨어를 사용할 수 있게 될 때 확인해야 합니다.
ThreadLink가 Thread를 IP 네트워크로 바꾸나요?
아니요. Thread는 처음부터 IPv6, 6LoWPAN 및 IEEE 802.15.4를 기반으로 했습니다. ThreadLink는 기존 IP 네트워크에서 Matter뿐 아니라 더 많은 기능을 실행하여 Shelly가 이 네트워크를 사용하는 방식을 바꿉니다.
Matter는 Thread와 같은 것인가요?
아니요. Matter는 애플리케이션 수준의 스마트 홈 제어 표준입니다. Thread는 Matter 또는 기타 호환 애플리케이션 프로토콜을 전송할 수 있는 저전력 IPv6 메시 네트워크입니다.
Matter 없이도 Thread를 사용할 수 있나요?
예. Thread는 애플리케이션 계층에 종속되지 않습니다. 현재 소비자용 Thread 제품은 Matter와 강하게 연관되어 있지만, Thread 자체는 다른 IP 기반 애플리케이션 프로토콜도 전송할 수 있습니다.
ThreadLink 장치는 Wi-Fi 없이 작동할 수 있나요?
Shelly에 따르면 ThreadLink 장치는 Thread를 Matter, 로컬 API 통신, 피어 투 피어 자동화 및 보더 라우터를 통한 클라우드 연결에 사용할 수 있으며, 엔드포인트 자체가 Wi-Fi에 연결되지 않아도 됩니다.
ThreadLink는 인터넷 없이도 작동할 수 있나요?
Shelly에 따르면 인터넷 연결이나 Wi-Fi 네트워크가 중단되더라도 장치 간 직접 장면, 인터록 및 자동화는 Thread 메시 내부에서 로컬로 작동할 수 있습니다.
ThreadLink에 Thread 보더 라우터가 필요한가요?
ThreadLink 장치가 더 넓은 홈 LAN, 앱, Home Assistant 또는 클라우드 서비스와 통신하려면 보더 라우터가 필요합니다. Shelly에 따르면 장치 간 장면은 Thread 메시 내부에서 자체적으로 작동할 수 있습니다.
ThreadLink가 Home Assistant를 대체하나요?
아니요. 단순한 장치 관계에서는 직접 피어 투 피어 로직을 사용해 서버가 필요하지 않게 할 수 있지만, 프로토콜 간 자동화, 기록, 대시보드, 정책, 일정 및 집 전체의 오케스트레이션에는 여전히 Home Assistant가 유용합니다.
Thread가 Wi-Fi를 대체할까요?
아마 그렇지 않을 것입니다. Thread는 저전력 및 비교적 낮은 대역폭의 IoT 장치를 위해 설계되었습니다. 카메라, 디스플레이, 휴대폰 및 컴퓨터와 같이 더 높은 대역폭이 필요한 제품에는 여전히 Wi-Fi가 더 적합합니다.
Thread 보더 라우터와 스마트 홈 허브의 차이점은 무엇인가요?
Thread 보더 라우터는 주로 Thread 메시와 더 넓은 IP 네트워크 사이에서 IPv6 트래픽을 라우팅합니다. 기존 허브나 브리지는 흔히 비IP 장치 네트워크와 IP 기반 LAN 또는 애플리케이션 사이를 변환합니다.
한 가정에 둘 이상의 Thread 네트워크가 있을 수 있나요?
예. 현재 가정에는 서로 다른 자격 증명을 사용하는 Apple, Google, Home Assistant 또는 기타 Thread 네트워크가 별도로 존재할 수 있습니다. Thread 1.4는 이러한 네트워크를 하나의 기존 메시로 더 쉽게 통합하도록 설계되었지만, 실제 구현은 여전히 장치와 생태계의 지원 여부에 따라 달라집니다.
Thread 1.4는 무엇을 변경하나요?
Thread 1.4는 생태계 간 네트워크 참여, 보더 라우터 인프라, 클라우드 연결, 진단, 커미셔닝, 안정성 및 더 큰 통합 Thread 메시를 유지하는 기능을 향상합니다.
ThreadLink가 홈 서버에 중요한 이유는 무엇인가요?
이는 Thread, Wi-Fi, 이더넷이 기본 IP 전송을 담당하는 동안 홈 서버가 독점 장치 네트워크를 변환하는 데 덜 집중하고, 오케스트레이션, 상태, 기록, 정책, 시스템 간 자동화 및 내구성 있는 데이터에 더 집중할 수 있음을 시사합니다.
지원 및 팁
더 읽어보기

Home Assistant가 Wi-Fi에서는 작동하지만 이더넷이나 VPN에서는 작동하지 않음
각 네트워크 경로를 개별적으로 테스트하고, 인터페이스와 라우팅 상태를 확인한 다음, 직접 IP 연결과 검색 기능을 구분하여 실패한 계층만 복구하세요.

보호되지 않은 데이터를 남기지 않고 Home Assistant를 폐기하는 방법
교체 또는 보관을 입증하고, 모든 신뢰 경로를 폐기하며, 데이터를 저장하는 각 장치를 안전하게 삭제하고, 문서화된 보호 복구 사본만 보존하세요.

홈 서버에서 Home Assistant 자동 업데이트를 사용해야 할까요?
가정에 미치는 영향, 호환성 위험, 관찰 시간, 복구 준비 상태를 고려해 수동 업데이트, 알림만 제공, 또는 단계적 자동 업데이트를 선택하세요.

