헤어질 결심 – SmartThings API 우회 전략

— SmartThings API 유료화에 대응하는 Home Assistant 우회 연동 아이디어 (Matterbridge + 가상 기기 + ST 루틴)

0. 왜 “헤어질 결심”인가

2026년 10월부터 SmartThings API가 유료화됩니다. 상업용 파트너는 별도 요금제, 개인 개발자도 월 $4.99짜리 “퍼스널 플랜”이 예고되어 있고, 정확한 쿼터·요금 체계는 아직 공개되지 않았습니다. Home Assistant의 smartthings 커스텀/공식 통합도 결국 이 API를 호출하는 구조라, 이 유료화 정책이 그대로 적용되면 HA ↔ SmartThings 클라우드 API 구간이 끊기거나 유료 전환이 강제될 가능성이 높습니다.

저는 이참에 SmartThings API에 대한 의존을 최대한 끊어내는 쪽으로 “헤어질 결심”을 했습니다. 다만 모든 기기를 한 번에 정리할 수는 없으니, 일반 스위치류부터 로컬 프로토콜(Matter)과 SmartThings 자체 루틴 엔진을 조합해서 API 호출 없이도 기존과 동일한 사용성을 유지할 수 있는 방법을 고안해봤습니다. 아직 커뮤니티 검증 전인 아이디어라, 의견과 실측 데이터를 구하고자 글을 올립니다.

1. 문제 정의

현재 구조:

[HA] ---(SmartThings Cloud REST API, 유료화 대상)---> [SmartThings Cloud] ---> [실제 기기]

HA에서 ST 기기 상태를 읽으려면: REST API polling 또는 Webhook 구독 → API 호출 발생
HA에서 ST 기기를 제어하려면: REST API command 호출 → API 호출 발생

즉 상태 조회든 제어든 전부 과금 대상이 될 REST API 경유입니다. 이 경로 자체를 없애는 것이 목표입니다.

2. 핵심 아이디어

SmartThings 쪽 자동화(루틴)는 API 과금과 무관하게, ST 앱/허브 내부에서 로컬로 동작한다. Matter는 클라우드 API가 아니라 로컬 네트워크 기반 프로토콜이라 이 유료화 정책과 무관하다.

이 두 가지를 조합하면, HA와 SmartThings 사이에 REST API를 단 한 번도 호출하지 않고도 상태 동기화 + 제어가 가능한 우회로를 만들 수 있습니다.

구조도

[HA: 가상 스위치 (input_boolean / template switch)]
        │
        │ (Matterbridge)
        ▼
[Matter 가상 기기] ── 로컬 Matter 커미셔닝 ──> [SmartThings 허브/앱]
        │                                              │
        │                                              │ ST 루틴 A:
        │                                              │ "실제 스위치 상태 변경 시
        │                                              │  → 가상 Matter 기기 상태 변경"
        │                                              │
        │◄─────── Matter 상태 리포트(Subscribe) ────────┘
        │
        ▼
[HA에서 가상 스위치 상태 = 실제 ST 기기 상태]

반대 방향(제어)도 동일한 원리로 구성합니다.

[HA에서 가상 스위치 ON/OFF 조작]
        │ (Matter 커맨드)
        ▼
[SmartThings 쪽 Matter 가상 기기 상태 변경]
        │
        │ ST 루틴 B:
        │ "가상 Matter 기기 상태 변경 시
        │  → 실제 스위치 제어"
        ▼
[실제 ST 기기 ON/OFF]

핵심은 HA는 오직 Matter로만 이야기하고, “ST 실제기기 ↔ ST 가상기기” 사이의 상태 미러링은 SmartThings 루틴이 전담한다는 점입니다. HA 입장에서는 SmartThings의 존재 자체를 몰라도 되는 구조가 됩니다.

3. 구성 요소

구성 요소	역할
HA `input_boolean` 또는 template switch	ST 실제 기기를 대리하는 가상 스위치
Matterbridge (HA 애드온 또는 별도 컨테이너)	HA 엔티티를 Matter 액세서리로 노출
SmartThings 허브 (또는 SmartThings 앱의 Matter 지원 기능)	Matter 컨트롤러/커미셔너 역할 — 가상 Matter 기기를 로컬로 페어링
SmartThings 루틴 (자동화)	실제기기 ↔ 가상기기 상태를 상호 미러링

4. 구현 절차 (초안)

4-1. HA에 가상 스위치 생성

# configuration.yaml
input_boolean:
  virtual_livingroom_switch:
    name: "거실 스위치 (ST 미러)"
    icon: mdi:toggle-switch

또는 상태 피드백까지 자연스럽게 다루려면 template 스위치로 만들어 turn_on/turn_off 시 별도 로직(알림, 로깅 등)을 넣을 수 있게 확장 가능합니다.

4-2. Matterbridge 설치 및 엔티티 노출

HA 애드온 스토어 또는 Docker로 Matterbridge 설치
matterbridge-hass 플러그인으로 위에서 만든 input_boolean.virtual_livingroom_switch를 Matter 액세서리로 브릿징
Matterbridge가 발급하는 페어링 코드(QR/숫자코드) 확인

4-3. SmartThings에서 Matter 기기로 커미셔닝

SmartThings 앱 → 기기 추가 → “Matter 기기 추가” 플로우로 진입
Matterbridge가 노출한 코드로 로컬 커미셔닝 진행
정상적으로 페어링되면 ST 앱 내에 “가상 거실 스위치”라는 새 기기가 생성됨 (이 통신은 로컬 Thread/Wi-Fi 기반이며 REST API를 타지 않음)

4-4. SmartThings 루틴 A (실제 → 가상, 상태 미러링용)

IF   [실제 거실 스위치] 상태가 켜짐으로 변경될 때
THEN [가상 거실 스위치(Matter)] 켜짐으로 설정

IF   [실제 거실 스위치] 상태가 꺼짐으로 변경될 때
THEN [가상 거실 스위치(Matter)] 꺼짐으로 설정

→ 가상 기기의 상태가 바뀌면 Matter Subscribe 리포트를 통해 HA의 input_boolean 상태도 즉시 갱신됩니다.

4-5. SmartThings 루틴 B (가상 → 실제, 제어용)

IF   [가상 거실 스위치(Matter)] 상태가 켜짐으로 변경될 때
THEN [실제 거실 스위치] 켜짐으로 설정

IF   [가상 거실 스위치(Matter)] 상태가 꺼짐으로 변경될 때
THEN [실제 거실 스위치] 꺼짐으로 설정

→ HA에서 input_boolean.virtual_livingroom_switch를 켜면 Matter 커맨드로 가상기기가 켜지고, 루틴 B가 실제 기기를 제어합니다.

4-6. 루프 방지

루틴 A와 B를 동시에 걸어두면 이론상 무한 루프(A가 가상기기를 바꾸면 B가 실제기기를 바꾸고, 그게 다시 A를 트리거…) 우려가 있습니다. 다만 **”상태가 이미 같으면 트리거하지 않는다”**는 SmartThings 루틴의 변경감지(change-triggered) 방식 특성상 실제로는 무한 루프가 발생하지 않을 것으로 예상됩니다 (상태값이 동일해지는 순간 두 루틴 다 트리거 조건을 잃음). 이 부분은 실측으로 반드시 검증이 필요한 지점입니다.

5. 기대 효과

HA ↔ SmartThings 사이에 REST API 호출이 전혀 발생하지 않음 → 유료화와 무관
기존 SmartThings 통합과 사용자 체감상 거의 동일한 양방향 동기화 경험 유지
Matter는 로컬 프로토콜이라 응답속도도 기존 클라우드 폴링 대비 빠를 가능성

6. 아직 검증되지 않은 한계 / 우려 사항 (커뮤니티 의견 구합니다)

루틴 실행 자체도 과금 대상이 될 가능성: 삼성이 “API 사용량”을 어떻게 정의할지 아직 미공개입니다. 앱 내 루틴 엔진 실행이 API 호출과 별개로 과금되지 않는다는 보장은 없습니다. (다만 현재까지 공개된 내용상 루틴/오토메이션은 계정 내부 로직으로, 외부 개발자 API 호출과는 구분되는 것으로 보입니다.)
Matter 커미셔닝 안정성: SmartThings 허브의 Matter 컨트롤러 기능이 실제로 완전 로컬로 동작하는지, 최초 등록/재등록 과정에서 클라우드 콜백이 개입하는지 확인 필요
지연시간: 실측 필요 — 실제기기 변경 → 루틴 A 트리거 → 가상기기 변경 → Matter 리포트 → HA 반영까지의 딜레이
스위치류 외 확장성: on/off 바이너리 상태는 이 구조가 잘 맞지만, 에어컨처럼 다중 캐패빌리티(모드, 온도, 팬속도 등)를 가진 기기는 캐패빌리티별로 가상 기기·루틴을 여러 개 만들어야 해서 복잡도가 급격히 증가함. 이 부분은 별도 글에서 다룰 예정
루틴 개수 제한: SmartThings 앱의 자동화(루틴) 개수/조건 제한에 걸릴 가능성 (기기 수가 많아지면 루틴도 배로 증가)
무한 루프 방지 로직의 실효성: 위 4-6 항목, 실측 검증 필요

7. 확장: 에어컨(Climate)에 적용하기

스위치는 on/off 단일 캐패빌리티라 위 구조가 비교적 단순하게 맞아떨어집니다. 에어컨은 전원, 모드, 설정온도, 팬속도 등 여러 캐패빌리티가 얽혀 있어서 그대로 옮기기는 어렵지만, 기본 뼈대는 동일하게 가져갈 수 있습니다.

7-1. 구조

[HA: Template Climate (가상 에어컨)]
        │
        │ (Matterbridge)
        ▼
[Matter Thermostat/HVAC 액세서리] ── 로컬 커미셔닝 ──> [SmartThings 허브/앱]
        │                                                    │
        │                                              ST 루틴 A:
        │                                              "실제 에어컨 상태 변경 시
        │                                               → 가상 에어컨 상태 변경"
        │                                                    │
        │◄────────── Matter 상태 리포트 ──────────────────────┘
        ▼
[HA에서 가상 에어컨 상태 = 실제 ST 에어컨 상태]

HA 쪽 가상 기기는 스위치 대신 Template Climate 커스텀 컴포넌트로 구성 → hvac_mode, target_temperature, fan_mode 등을 임의로 세팅/조회할 수 있는 상태 그릇 역할
Matterbridge가 이 Template Climate 엔티티를 Matter Thermostat 클러스터로 노출
SmartThings가 이 Matter 기기를 에어컨(또는 온도조절기)으로 인식해서 커미셔닝

7-2. 현재 확인된 제약: ST 루틴의 캐패빌리티 제한

실기 테스트 중 확인한 부분인데, SmartThings 루틴에서 에어컨류 기기에 걸 수 있는 액션이 켜기/끄기 정도로 제한되는 경우가 많습니다. 즉:

루틴 A(실제 → 가상): 실제 에어컨의 전원 상태 변화는 감지·미러링이 될 가능성이 높지만, 설정온도·모드·팬속도 변경까지 트리거 조건으로 잡히는지는 기기/펌웨어에 따라 다를 수 있음
루틴 B(가상 → 실제): 반대로 “가상 에어컨의 설정온도가 바뀌면 실제 에어컨 온도를 바꿔라” 같은 액션이 루틴 액션 목록에 아예 노출되지 않는 경우가 있음 (전원 on/off 액션만 제공되는 경우)

이게 사실이라면, 이 구조로 에어컨에서 안정적으로 가져올 수 있는 건 전원 상태 동기화 정도이고, 온도/모드까지 완전히 미러링하는 건 현재로선 루틴 UI의 지원 범위에 달려 있습니다.

7-3. 확인이 필요한 부분 (커뮤니티 검증 요청)

루틴 “만약(If)” 조건에서 에어컨의 설정온도 변경이 트리거로 잡히는지 (전원 상태 외의 조건 선택 가능 여부)
루틴 “그러면(Then)” 액션에서 설정온도/모드/팬속도 지정이 가능한지, 아니면 정말 on/off 액션만 노출되는지
이게 에어컨 기기 자체(제조사/모델)의 SmartThings 캐패빌리티 정의 문제인지, 아니면 Matter로 노출된 가상 기기 쪽의 클러스터 구현 문제인지 (Matterbridge가 Thermostat 클러스터의 어떤 attribute까지 지원하는지도 함께 확인 필요)
만약 온도/모드 동기화가 루틴에서 막혀 있다면, 전원만 이 구조로 동기화하고 온도/모드는 여전히 API(또는 유료 플랜)로 처리하는 하이브리드 방식이 현실적인 대안이 될 수 있음

이 부분은 실측 없이는 단정하기 어려워서, 혹시 에어컨을 SmartThings 루틴에 걸어보신 분들 중 “설정온도 변경”이 조건/액션으로 뜨는지 확인해주실 수 있는 분 계시면 큰 도움이 될 것 같습니다.

8. 다음 단계

스위치 1개로 PoC 진행 (지연시간, 루프 여부 실측)
Matterbridge 로그와 SmartThings 루틴 실행 로그 비교 분석
Template Climate + Matterbridge로 가상 에어컨 PoC 진행, 루틴에서 온도 관련 조건/액션 노출 여부 확인
온도 동기화가 막혀 있을 경우, 전원만 동기화하는 하이브리드 구조로 축소 적용
삼성의 API 과금 정책 세부사항(10월 예정) 공개되면 루틴 기반 방식도 과금 대상인지 재확인

댓글로 실제로 이 구조를 테스트해보신 분 계시면 지연시간/안정성 데이터 공유해주시면 감사하겠습니다. 저도 PoC 진행되는 대로 후속 글 올리겠습니다.