집에도 AI Agent를 둔다: Google Home·Apple Home·Matter 가전을 연결해 만드는 자율 스마트홈

이경규·2026년 8월 20일

집에도 AI Agent를 둔다: Google Home·Apple Home·Matter 가전을 연결해 만드는 자율 스마트홈

스마트홈이라고 하면 아직도 이런 모습부터 떠올리기 쉽다.

"거실 불 켜줘."

"에어컨 24도로 맞춰줘."

"TV 꺼줘."

지금까지의 스마트홈은 대부분 명령을 잘 수행하는 자동화 시스템이었다.

하지만 2026년에는 방향이 조금 달라지고 있다.

Google은 Gemini for Home을 단순 음성 명령 도구가 아니라 카메라 이벤트를 이해하고, 사용자의 집 상태를 바탕으로 능동적인 서비스를 제공하는 방향으로 확장하고 있다. Google Home APIs 역시 Android와 iOS에서 기기·자동화·카메라·도어벨 등을 다루는 범위를 계속 넓히고 있다.

Home Assistant 역시 2026년부터 자동화를 만들 때 entity, state, trigger 같은 내부 기술 용어보다 “침실 온도가 18도 아래로 내려가면 난방을 켠다”처럼 원하는 결과에서 시작하는 방식을 기본으로 바꾸고 있다. Matter Server도 matter.js 기반으로 크게 개편되면서 Matter 1.5.1과 새로운 기기 유형에 대한 기반을 넓혔다.

스마트홈의 다음 단계는 단순히 더 많은 기기를 연결하는 것이 아니다.

명령을 실행하는 집

↓

상황을 이해하는 집

↓

목표를 받아
필요한 행동을 판단하는 집

으로 가는 것이다.

그리고 그 가운데 들어가는 것이 Home Agent다.

1. 먼저 결론부터: 지금 쓰는 스마트홈을 버릴 필요는 없다

이미 Google Home이나 Apple Home을 쓰고 있다면 새로운 AI 스마트홈을 위해 집안 기기를 전부 교체할 필요는 없다.

구조는 오히려 기존 시스템 위에 Agent를 얹는 쪽이 자연스럽다.

AI Agent
    ↓
Google Home
Apple Home
Home Assistant
    ↓
Matter / 기존 연동
    ↓
실제 스마트 가전

즉 Agent는 새로운 전등 제어 규격이 아니다.

Agent는:

무엇을 할지 판단

하고,

기존 스마트홈 플랫폼은:

실제로 기기를 제어

한다.

이렇게 역할을 나누는 것이 핵심이다.

2. Matter를 아주 쉽게 이해하면

예전 스마트홈의 가장 큰 불편 중 하나는 제조사마다 생태계가 달랐다는 점이다.

전등 A
→ 제조사 앱 A

플러그 B
→ 제조사 앱 B

센서 C
→ 제조사 앱 C

Matter는 이 문제를 줄이기 위해 만들어진 공통 스마트홈 연결 규격이다.

Apple도 Matter를 서로 다른 플랫폼에서 다양한 스마트홈 액세서리가 함께 동작하도록 하는 상호운용성 표준으로 설명하고 있다. iPhone에서는 Matter Setup Code를 스캔하면 Wi-Fi나 Thread 연결 과정도 시스템이 처리할 수 있다.

아주 단순화하면:

Matter 기기
       ↓
공통 스마트홈 언어
       ↓
Google Home
Apple Home
Home Assistant
기타 Matter 플랫폼

이라고 이해하면 된다.

Matter의 장점은 특정 회사 한 곳에 모든 기기를 맞출 필요가 줄어든다는 것이다.

3. 앞으로 스마트 가전을 산다면 무엇을 보면 될까

비개발자라면 제품 설명에서 가장 먼저 다음을 확인하면 된다.

Matter 지원

그리고 Thread를 사용하는 기기라면:

Thread Border Router

가 집에 있는지도 확인하면 좋다.

대표적으로 스마트 스피커나 허브 중 일부가 이 역할을 한다.

다만 Matter라고 해서 모든 기능이 모든 플랫폼에서 완전히 동일하게 지원되는 것은 아니다.

예를 들어:

기본 ON/OFF
밝기
온도

같은 공통 기능은 잘 맞아도,

제조사 고유 기능은:

자체 앱에서만 지원

될 수 있다.

따라서 구매할 때는:

Matter 지원 여부

+

내가 실제 사용하는 플랫폼에서
원하는 기능까지 지원하는지

두 가지를 보는 편이 좋다.

4. Google Home을 이미 쓰고 있다면

Google Home 사용자는 가장 먼저 집 구조와 기기 이름부터 정리하는 것이 좋다.

예:

전등1
전등2
스위치1

보다:

거실 메인등

거실 스탠드

현관 센서등

처럼 사람이 읽기 좋은 이름이 낫다.

AI Agent 입장에서도 마찬가지다.

"전등1 꺼줘"

보다

"거실 메인등 꺼줘"

가 Context를 이해하기 쉽다.

5. Google Home에서 가장 먼저 할 일

비개발자라면 다음 정도면 충분하다.

1. Google Home 앱에서 모든 기기를 확인

2. 방을 실제 집 구조에 맞게 정리

3. 기기 이름을 자연스럽게 변경

4. 기존 Routine/Automation 정리

5. 새 Matter 기기는 QR 코드로 추가

6. 외출 / 귀가 / 취침 같은 기본 자동화 구성

AI Agent를 붙이기 전부터 이 작업을 해두는 것이 좋다.

Agent는 정리되지 않은 스마트홈을 마법처럼 정리해주는 도구가 아니다.

오히려:

좋은 Device Naming

좋은 Room 구조

좋은 기본 자동화

위에 Agent를 올려야 결과가 좋아진다.

6. Apple Home을 쓰고 있다면

Apple Home도 기본 방향은 같다.

Matter 액세서리는 홈 앱에 추가할 수 있고, Apple Home에 등록된 Matter 기기는 홈 앱·Siri·제어 센터·HomeKit 앱에서 사용할 수 있다. Apple은 다른 Matter 생태계 앱에서 등록된 액세서리를 다시 활용할 수 있도록 MatterSupport Framework도 제공하고 있다.

일반 사용자는:

iPhone
 ↓
홈 앱
 ↓
액세서리 추가
 ↓
Matter QR Code
 ↓
방 지정
 ↓
기기 이름 설정

순서로 생각하면 된다.

7. Apple Home에서도 Scene부터 정리하면 좋다

처음부터 Agent를 만들기보다 기존 Scene을 먼저 잘 만드는 것이 좋다.

예:

외출

귀가

취침

영화 보기

집중 모드

예를 들어 취침 Scene이라면:

거실 조명 OFF

침실 조명 20%

커튼 닫기

TV OFF

정도로 시작한다.

이후 Agent가:

"잘 준비해줘."

라는 목표를 받았을 때 기존 Scene을 실행하거나 상황에 따라 일부만 수정할 수 있다.

8. 처음 스마트홈을 시작한다면 너무 많이 사지 않는다

처음부터:

카메라
도어락
스마트커튼
에어컨
TV
로봇청소기
센서 20개

까지 연결할 필요는 없다.

가장 쉬운 시작은 다음 정도다.

1단계

Matter 스마트 전구
Matter 스마트 플러그
온습도 센서

이 정도만 있어도 상당히 많은 자동화를 만들 수 있다.

9. 두 번째 단계

스마트홈에 익숙해지면:

커튼

에어컨

공기청정기

로봇청소기

재실 센서

같은 기기를 추가한다.

여기부터는 단순 ON/OFF보다 Context가 중요해진다.

10. 마지막에 보안 기기를 추가한다

카메라

도어벨

도어락

차고문

보안 센서

는 좀 더 신중해야 한다.

이런 장비는 편의보다 권한과 안전 설계가 먼저다.

특히 AI Agent와 연결할 때는 더 그렇다.

11. 처음 만들기 좋은 자동화 5개

스마트홈을 시작했다면 Agent보다 먼저 다음 자동화부터 만들어보면 좋다.

외출

"나 외출할게."

↓

거실 조명 OFF

TV OFF

필요 없는 플러그 OFF

에어컨 절전

도어락 상태 확인

귀가

"집에 거의 다 왔어."

↓

현관 조명 ON

거실 조명 ON

실내 온도 준비

취침

"잘 준비해줘."

↓

거실 조명 OFF

침실 조명 낮춤

TV OFF

커튼 닫기

적절한 수면 온도

반려동물 모드

사람 없음

+

실내 온도 상승

+

반려동물 재실

↓

에어컨 완전 OFF X

안전 온도 유지

이런 상황에서 Agent의 가치가 커진다.

보안

외출 상태

+

현관 움직임 감지

↓

사용자 알림

+

카메라 확인 제안

+

현관등 ON

정도로 시작한다.

바로 문을 열거나 경보를 해제하도록 만들 필요는 없다.

12. 기존 자동화와 AI Agent는 무엇이 다를까

기존 스마트홈 자동화는 대부분 Rule 기반이다.

IF

22:00

THEN

거실 조명 OFF

또는:

IF

현관문 열림

THEN

현관 조명 ON

명확하고 예측 가능하다.

그래서 여전히 중요하다.

13. Agent는 Goal을 받는다

Agent는 조금 다르다.

"잘 준비해줘."

라는 말을 받았다고 하자.

Agent가 현재 상태를 확인한다.

현재 23:20

거실에 사람 없음

침실에 사람 있음

TV ON

거실등 ON

침실 온도 26.5℃

내일 평일

그리고 행동 계획을 만든다.

TV OFF

거실등 OFF

침실 조명 20%

커튼 닫기

에어컨 수면 온도

즉:

기존 Automation

Rule → Action

이라면

Agent

Goal
+
Context
+
Policy

→ Action Plan

이다.

14. 이 차이가 꽤 크다

예를 들어 외출 모드를 보자.

기존 자동화:

외출

↓

에어컨 OFF

하지만 상황이 다음과 같다면?

외부 34℃

집 안 27℃

고양이 집에 있음

두 시간 뒤 귀가 예정

Agent라면:

에어컨 완전 OFF

X

대신:

27℃ 유지

를 선택할 수 있다.

이게 Agentic Smart Home의 매력이다.

15. 집 상태를 하나의 모델로 만든다

개발 관점에서는 여기서 Home State Model 또는 Home Digital Twin이 중요해진다.

Agent가 매번:

전등 API 조회

온도 API 조회

카메라 API 조회

도어락 API 조회

를 직접 돌아다니며 판단하게 만들기보다,

집 전체 상태를 하나의 구조로 정리한다.

예:

{
  "home": {
    "mode": "away",
    "occupancy": "empty"
  },
  "livingRoom": {
    "temperature": 27.1,
    "lights": false,
    "window": "closed"
  },
  "bedroom": {
    "temperature": 25.4,
    "lights": false
  },
  "pet": {
    "home": true
  }
}

Agent는 이 상태를 보고 판단한다.

16. Device가 아니라 집을 이해하게 한다

기존 스마트홈은:

Device 중심

이다.

Light 12

Thermostat 4

Plug 7

Agent에게는 이런 정보보다:

거실

침실

현관

사람

반려동물

온도

보안 상태

가 더 중요하다.

그래서:

Device Graph

위에:

Home Semantic Layer

를 만드는 것이 좋다.

17. 전체 Architecture

구조는 다음 정도가 깔끔하다.

사용자
"잘 준비해줘."
      │
      ▼
┌────────────────────┐
│ Home Agent         │
│                    │
│ Intent             │
│ Planner            │
│ Context            │
│ Memory             │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ Home Digital Twin  │
│                    │
│ Rooms              │
│ Devices            │
│ People             │
│ Pets               │
│ Environment        │
│ Security           │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ Policy Engine      │
│                    │
│ AUTO               │
│ CONFIRM            │
│ DENY               │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ Control Gateway    │
│                    │
│ Google Home APIs   │
│ Apple Home         │
│ Matter             │
│ Home Assistant     │
└─────────┬──────────┘
          │
          ▼
     Physical Home

이 구조에서 LLM이 직접 모든 Device API를 호출하지 않는 것이 중요하다.

18. Agent는 “판단”, 스마트홈 플랫폼은 “실행”

가장 안전한 역할 분리는 다음이다.

Agent

무엇을 할지 판단

Policy Engine

해도 되는지 판단

Control Layer

실제 명령 실행

이렇게 나눈다.

19. 나쁜 구조

LLM
 ↓
Door Lock API
 ↓
Unlock

Agent가 잘못 판단하면 실제 문이 열린다.

20. 더 나은 구조

Agent

"문을 열 필요가 있음"
       ↓
Action Proposal
       ↓
Policy Engine
       ↓
Door Unlock = CONFIRM
       ↓
사용자 승인
       ↓
Control Gateway
       ↓
Unlock

이렇게 해야 한다.

21. 권한을 세 단계로 나눈다

스마트홈 Agent에서 가장 중요한 설계 중 하나다.

AUTO

CONFIRM

DENY

22. AUTO

위험도가 낮은 작업.

전등 ON/OFF

조명 밝기 조절

TV OFF

공기청정기

로봇청소기

에어컨 ±1~2℃

상황에 따라 자동 실행할 수 있다.

23. CONFIRM

물리적 안전이나 개인정보와 연결되는 작업.

현관문 Unlock

차고문 Open

카메라 Live View 공유

경보 해제

고온 난방

특정 전열기구 ON

사용자 확인을 거친다.

24. DENY

아예 Agent에게 권한을 주지 않는 작업도 있어야 한다.

예:

보안 시스템 관리자 설정 변경

카메라 영상 외부 업로드

장기 보안 기록 삭제

사용자 승인 없는 도어락 권한 변경

같은 것이다.

Agent에게 무엇을 할 수 있게 할지보다 무엇을 못 하게 할지 먼저 정하는 것이 중요하다.

25. Google Home 쪽은 Agent 시대에 특히 흥미롭다

Google은 2026년 I/O에서 Gemini for Home을 단순한 Assistant 기능을 넘어 proactive, personalized home services를 위한 전체 AI Layer로 확장하는 방향을 강조했다.

특히 카메라 쪽이 재미있다.

기존:

Person detected.

였다면,

Gemini 기반 Camera Intelligence의 방향은:

어떤 일이 발생했는지
맥락을 붙여 설명

하는 쪽이다.

26. Google Home APIs도 카메라 기능을 계속 넓히고 있다

2026년 Google Home APIs iOS Public Beta에는 카메라·도어벨 관련 기능으로:

Visitor announcements

Livestream quality

Image snapshot

Doorbell Quick Responses

Activity Zone 관련 Preview

등이 추가됐다.

스마트홈 Agent에서 카메라가 단순 영상 기기가 아니라 중요한 Context Sensor가 되는 이유다.

27. 그렇다고 카메라 영상을 계속 AI에 보내면 안 된다

예를 들어:

카메라 영상 24시간

↓

LLM

구조는 비용·지연·개인정보 측면에서 좋지 않다.

더 나은 구조는:

Camera / Vision

↓

Event

person_detected
doorbell_pressed
package_detected

↓

Home State

↓

Agent

이다.

28. 예를 들어 새벽 현관 감지

사용자 설정:

"집에 아무도 없을 때
새벽에 현관에서 사람이 오래 머물면 알려줘."

실제 흐름:

Camera

↓

Person Detected

↓

Local / Device Vision

↓

Event

Home State:

occupancy = away

time = 02:13

personDuration = 68 seconds

Agent:

일반 통행보다
주의가 필요한 상황

↓

사용자 알림

현관등 ON

Snapshot 표시

정도로 처리한다.

29. 카메라는 Agent가 직접 보는 눈이라기보다 Event Source다

이 개념이 중요하다.

Sensor

Camera

Doorbell

Thermostat

Door Lock

Energy Meter

가 Event와 State를 만든다.

Agent는 그것을 종합한다.

30. Home Assistant가 재미있는 이유

Google Home이나 Apple Home보다 훨씬 자유로운 구성이 필요하면 Home Assistant가 유용하다.

특히:

브랜드가 다양함

센서가 많음

로컬 자동화 선호

고급 Rule 필요

자체 서버 운영 가능

한 경우다.

Home Assistant는 2026년 Matter Server를 matter.js 기반으로 개편했고 Matter 1.5.1 지원으로 카메라·도어벨·Closure 계열 등 새로운 Matter Device Type 지원 기반을 넓혔다.

31. 비개발자에게도 Home Assistant가 쉬워지고 있다

예전 Home Assistant의 이미지:

YAML

Entity

Trigger

Condition

Action

때문에 진입장벽이 높다고 느끼는 사람이 많았다.

2026.7부터는 자동화 Editor가 목적 중심 Trigger와 Condition을 기본으로 사용한다.

예:

침실 온도가 18℃ 아래로 내려가면
난방 켜기

처럼 원하는 결과에서 시작할 수 있다.

그래서 개발자가 아니어도 예전보다 접근하기 쉬워졌다.

32. 어떤 플랫폼을 선택해야 할까

복잡하게 생각할 필요 없다.

Google Home이 이미 있다

Google Home 계속 사용

+

Matter 기기 추가

+

필요하면 Agent Layer

iPhone 중심이다

Apple Home

+

Matter

+

Siri / Scene

+

필요하면 Agent Layer

Apple은 Matter 액세서리를 홈 앱과 HomeKit API에서 다룰 수 있고, MatterSupport Framework를 통해 다른 Matter 생태계와의 Pairing도 지원한다.

브랜드가 너무 많다

Home Assistant

+

Matter

+

기존 Vendor Integration

이 편이 유연하다.

33. 꼭 하나만 선택해야 하는 것도 아니다

Matter의 재미있는 점은 Multi-admin이다.

한 Matter Device를 여러 Smart Home Ecosystem에서 사용할 수 있는 방향으로 설계되어 있다.

Apple 역시 Matter 액세서리를 여러 생태계와 연결할 수 있도록 MatterSupport Framework를 제공한다.

예:

Matter 전등

├─ Apple Home
└─ Google Home

같은 구성도 가능하다.

실제 지원 범위는 기기와 플랫폼에 따라 확인해야 한다.

34. Home Agent를 세 단계로 나누면 이해하기 쉽다

LEVEL 1 — Command Agent

"거실 불 꺼줘."

↓

거실등 OFF

지금의 음성비서와 크게 다르지 않다.

35. LEVEL 2 — Context Agent

"잘 준비해줘."

↓

시간

사람 위치

온도

조명

TV

커튼

반려동물

을 보고 여러 행동을 조합한다.

36. LEVEL 3 — Proactive Agent

사용자가 말하지 않아도 상황을 판단한다.

예:

에어컨 ON

+

창문 OPEN

↓

"창문이 열려 있어
냉방 효율이 떨어지고 있습니다."

또는:

외출

+

현관 움직임

↓

"현관 앞에서 움직임이 감지됐습니다."

Google이 2026년 Gemini for Home에서 강조하고 있는 것도 이런 proactive service 방향이다.

37. 여기부터 개발자 영역으로 들어간다

실제로 Home Agent를 만든다면 단순 LLM 호출 하나로 끝나지 않는다.

필요한 구성은 대략 다음과 같다.

Home Agent

Intent Parser

Planner

State Store

Event Bus

Policy Engine

Control Gateway

Audit Log

38. Home State Store

예:

{
  "timestamp": "2026-08-20T23:10:00+09:00",
  "home": {
    "mode": "home",
    "occupancy": 2
  },
  "livingRoom": {
    "temperature": 27.3,
    "humidity": 62,
    "lights": true,
    "window": "open"
  },
  "bedroom": {
    "temperature": 25.6,
    "lights": false
  }
}

Agent에게 매번 모든 Device 상태를 무작정 넣지 않는다.

39. Event Bus

스마트홈은 상태 변화가 매우 많다.

motion_detected

temperature_changed

door_opened

person_arrived

camera_event

energy_spike

이를 Event 형태로 정리한다.

예:

{
  "type": "window.opened",
  "room": "livingRoom",
  "at": "2026-08-20T22:51:10+09:00"
}

40. Agent가 모든 Event를 처리해서도 안 된다

예:

온도 0.1℃ 변화

↓

LLM 호출

을 반복하면 비효율적이다.

Rule Engine이 먼저 처리한다.

Raw Event

↓

Filter / Rule

↓

Relevant Event

↓

Agent

구조가 좋다.

41. Planner

사용자 요청:

"두 시간 나갔다 올게."

Planner 결과:

{
  "goal": "temporary_away",
  "actions": [
    {
      "device": "livingRoomLight",
      "action": "off"
    },
    {
      "device": "tv",
      "action": "off"
    },
    {
      "device": "thermostat",
      "action": "set",
      "value": 27
    }
  ]
}

중요한 것은 아직 실행하지 않았다는 점이다.

42. Policy Engine이 다음 단계다

Planner가 만든 Action을 검사한다.

light.off

→ AUTO

thermostat.set 27℃

→ AUTO

door.unlock

→ CONFIRM

security.disable

→ DENY

이런 식이다.

43. Device Control Gateway

Agent가 Google Home·Apple Home·Home Assistant의 구현 차이를 직접 알 필요도 없다.

Agent

↓

setLight(
    room: livingRoom,
    state: off
)

같은 내부 Action Contract를 만든다.

Gateway가 실제 구현을 선택한다.

GoogleHomeAdapter

AppleHomeAdapter

HomeAssistantAdapter

MatterAdapter

처럼 나눈다.

44. 이렇게 해야 플랫폼이 바뀌어도 Agent는 유지된다

나쁜 구조:

Agent Prompt

"Google Home의 XYZ Trait을 호출해..."

플랫폼 API가 바뀌면 Prompt까지 바뀐다.

좋은 구조:

Agent

↓

Home Action Contract

↓

Adapter

이다.

45. Action Contract 예

enum HomeAction {
    case setLight(
        room: RoomID,
        state: Bool
    )

    case setTemperature(
        room: RoomID,
        celsius: Double
    )

    case startVacuum

    case requestCameraSnapshot(
        camera: CameraID
    )

    case lockDoor(
        door: DoorID
    )
}

Agent는 이 제한된 Action만 선택한다.

46. 위험 Action은 타입부터 분리한다

예:

enum RestrictedHomeAction {
    case unlockDoor(DoorID)
    case disableAlarm
    case openGarage
}

이런 Action은:

Agent

↓

Action Proposal

↓

User Approval

↓

Execution

만 가능하게 만든다.

47. Agent에게 Raw Device API를 전부 주지 않는다

Agent Tool에:

HTTP Request

Shell

전체 Matter API

전체 Home Assistant API

를 다 주는 것보다:

turnOffLight

setTemperature

startVacuum

lockDoor

getCameraSnapshot

처럼 좁은 Capability를 제공하는 편이 훨씬 안전하다.

48. Camera는 특히 권한을 강하게 나눈다

예:

Camera Event Metadata

AUTO

Snapshot

POLICY

Live View

RESTRICTED

영상 외부 공유

CONFIRM 또는 DENY

같이 구분할 수 있다.

49. 개인 정보는 가능한 한 집 안에 남긴다

스마트홈 Agent에서 중요한 원칙이다.

예:

Raw Video

Raw Audio

Continuous Presence Data

를 무조건 Cloud AI에 보내지 않는다.

가능하면:

Local Sensor / Vision

↓

Structured Event

↓

Agent

로 바꾼다.

50. Agent에게 전달되는 정보도 최소화한다

예를 들어:

person_detected = true

location = frontDoor

duration = 68s

이면 충분한 상황에:

1분짜리 영상 전체

를 보내지 않는다.

51. Memory도 조심해야 한다

Agent가 사용자 생활 패턴을 기억하면 편리하다.

예:

평일 23시쯤 취침

아침 7시 기상

고양이가 집에 있음

침실 선호 온도 24℃

하지만 이건 상당히 민감한 정보다.

따라서:

Memory

↓

사용자 선택

Retention

삭제 기능

Local 우선

정책을 가져야 한다.

52. 자동화와 Agent를 같이 쓰는 것이 정답에 가깝다

Agent가 좋다고 기존 Rule Automation을 버릴 필요가 없다.

오히려:

반복되고 명확한 작업

→ Automation

Context 판단이 필요한 작업

→ Agent

으로 나눈다.

53. 예를 들어 현관등

일몰 후

+

현관 움직임

↓

현관등 ON

Agent가 필요 없다.

Rule이 더 빠르고 안정적이다.

54. 반면 이런 요청은 Agent가 잘 맞는다

"이번 주말 집을 비울 건데
고양이가 있으니까
집 상태 적당히 관리해줘."

필요한 판단이 많다.

온도

공기질

조명

보안

카메라

급수기

귀가 시간

이런 경우 Agent가 가치가 있다.

55. 가장 현실적인 구조

결국 다음 조합이 가장 좋다.

Matter

기기 연결

Google Home / Apple Home / Home Assistant

기기 관리

Rule Automation

단순·반복 작업

AI Agent

Context·Goal 판단

Policy Engine

위험 제어

이다.

56. 처음 시작하는 사람을 위한 가장 쉬운 구성

개발 지식이 없다면 이렇게 시작하면 된다.

Matter 스마트 전구 2개

Matter 스마트 플러그 1개

온습도 센서 1개

↓

Google Home
또는
Apple Home

↓

방 이름 정리

↓

외출
취침
귀가

세 가지 자동화 생성.

여기까지만 해도 충분히 스마트하다.

57. 그 다음 Agent로 넘어간다

익숙해지면:

고정 Scene

↓

Context Automation

↓

Agent

순서로 확장한다.

처음부터 Agent에게 모든 집 제어 권한을 주는 것보다 훨씬 안전하다.

58. Home Assistant까지 넘어갈 시점

다음 상황이면 Home Assistant를 검토할 만하다.

브랜드가 너무 다양함

Google / Apple 자동화가 부족함

로컬 중심으로 운영하고 싶음

센서가 많음

복잡한 조건이 필요함

AI Agent를 직접 연결하고 싶음

2026년 Home Assistant는 Matter 쪽 안정성과 자동화 UX 모두 빠르게 개선되는 중이라 예전보다 접근성이 훨씬 좋아졌다.

59. 개발자가 만든다면 앱의 역할도 달라진다

기존 스마트홈 앱:

Device List

↓

ON / OFF Button

Agent 시대 앱:

Home State

Agent Suggestion

Approval

History

Policy

가 중심이 될 수 있다.

60. 예를 들어 모바일 앱 화면

오늘 집 상태

거실 26.8℃
침실 25.4℃
고양이 재실
현관 이상 없음

Agent Suggestion:

거실 창문이 열려 있는데
에어컨이 작동 중입니다.

창문을 닫은 뒤 냉방을 유지할까요?

버튼:

적용

무시

항상 이렇게 처리

마지막 버튼이 중요하다.

61. “항상 이렇게 처리”가 새로운 자동화를 만든다

처음:

Agent Suggestion

사용자가 계속 승인한다.

↓

Pattern 발견

↓

Automation 생성 제안

↓

앞으로 자동 실행

이렇게 만들 수 있다.

Agent가 단순 실행기에서 Automation Designer 역할까지 하는 것이다.

62. Agent가 계속 생각할 필요도 없다

예:

에어컨 ON
+
창문 OPEN

을 사용자가 세 번 연속:

에어컨 끄기

로 승인했다.

Agent가:

"앞으로 창문이 열린 상태에서
에어컨이 켜지면 자동으로 끌까요?"

라고 제안한다.

사용자가 승인.

그다음부터는:

Rule Automation

으로 바꾼다.

이게 상당히 좋은 구조다.

63. Agent는 새로운 패턴을 발견하고 Rule로 승격한다

Agent 판단

↓

반복

↓

사용자 승인

↓

Automation

그러면 매번 AI를 호출할 필요가 없다.

비용과 지연도 줄어든다.

64. 스마트홈 Agent의 이상적인 역할

결국 Agent가 모든 것을 직접 제어하는 집보다:

Agent

새로운 상황 판단

↓

Automation

반복 상황 처리

구조가 더 효율적이다.

65. 스마트홈을 새로 구성한다면 추천 순서

STEP 1

Matter 중심으로 구매한다.

STEP 2

Google Home 또는 Apple Home에 연결한다.

STEP 3

Room과 Device 이름을 정리한다.

STEP 4

외출·귀가·취침 Scene을 만든다.

STEP 5

단순 Automation을 만든다.

STEP 6

센서와 카메라 Event를 추가한다.

STEP 7

Context Agent를 붙인다.

STEP 8

AUTO / CONFIRM / DENY Policy를 만든다.

이 순서면 과도하게 복잡해지지 않는다.

66. 가장 먼저 바꿔야 하는 생각

스마트홈을 만들 때:

기기를 얼마나 많이 연결했는가?

보다

집의 상태를 얼마나 잘 이해할 수 있는가?

가 더 중요해진다.

67. Matter의 역할도 여기서 명확해진다

Matter는 집의 두뇌가 아니다.

Matter

=

기기들이 서로 연결되는 공통 언어

에 가깝다.

68. AI Agent의 역할

AI Agent

=

집 상태를 읽고
사용자의 목표를 이해하고
무엇을 할지 판단하는 두뇌

다.

그래서 둘은 경쟁 기술이 아니라 서로 다른 층이다.

69. Google Home·Apple Home도 없어지는 것이 아니다

오히려 중요해진다.

AI Agent

판단

↓

Google Home
Apple Home
Home Assistant

제어

↓

Matter

연결

↓

Device

이 구조가 된다.

70. 마무리

스마트홈은 이미 충분히 편리하다.

"불 꺼줘."

"에어컨 켜줘."

"외출 모드 실행해."

만으로도 몇 년 전과 비교하면 상당히 발전했다.

하지만 AI Agent가 들어오면 질문이 달라진다.

무엇을 켤까?

가 아니라:

지금 이 집에
무엇이 필요한가?

를 판단하기 시작한다.

예를 들어:

"두 시간 나갔다 올게."

라는 한마디에서:

사람은 외출

고양이는 재실

외부 기온 34℃

거실 27℃

TV ON

창문 CLOSED

로봇청소기 충전 완료

를 보고:

전등 OFF

TV OFF

에어컨 27℃ 유지

로봇청소기 시작

현관 보안 상태 확인

을 계획하는 식이다.

하지만 중요한 것은 AI가 마음대로 집을 제어하게 만드는 것이 아니다.

가장 좋은 구조는:

Agent

판단

↓

Policy

허용 여부 판단

↓

Google Home
Apple Home
Home Assistant
Matter

실행

이다.

전등이나 온도 같은 낮은 위험의 작업은 자동으로 실행해도 된다.

하지만:

도어락 Unlock

차고문 Open

경보 해제

카메라 Live View

같은 작업에는 여전히 사람의 승인과 명확한 권한 경계가 필요하다.

그래서 Agentic Smart Home의 핵심은 집을 최대한 자동화하는 것이 아니다.

자동화해야 할 것

사람에게 물어봐야 할 것

절대로 Agent에게 맡기지 않을 것

을 구분하는 것이다.

그리고 일반 사용자라면 처음부터 거창하게 시작할 필요도 없다.

Matter 전등

+

Google Home 또는 Apple Home

+

외출 / 귀가 / 취침 자동화

정도로 시작하면 된다.

그다음 센서와 상황 판단을 늘리고, 마지막에 Agent를 붙인다.

한 문장으로 정리하면 이렇다.

Matter가 스마트 가전들을 같은 언어로 연결한다면, AI Agent는 그 기기들을 어떤 상황에서 어떻게 움직일지 판단하는 두뇌가 된다.

앞으로의 스마트홈은 기기가 많은 집보다 집의 상태와 사람의 의도를 잘 이해하는 집에 가까워질 가능성이 높다.

참고 자료

Google Home Developers — Google I/O 2026
Gemini for Home을 기반으로 카메라 Intelligence와 proactive·personalized Home Service를 확대하는 Google의 최신 방향을 확인할 수 있다.
Google Home Developer Newsletter — May 2026
Gemini for Home을 Google Home APIs와 연결된 full-stack AI Offering으로 확장하고, proactive household awareness 같은 서비스를 제공하려는 방향을 설명한다.
Google Home APIs iOS SDK Release Notes
2026년 Public Beta에서 Camera·Doorbell Visitor Announcement, Livestream Quality, Snapshot, Quick Response 등 최신 기능이 추가된 내용을 확인할 수 있다.
Apple Developer — Matter support in iOS
Apple Home에서 Matter 액세서리를 추가하고 여러 Matter Ecosystem 사이에서 액세서리를 활용하는 구조와 MatterSupport Framework를 설명한다.
Home Assistant 2026.7 — Automations that speak your language
Entity·State 중심이 아니라 사용자가 원하는 결과 중심으로 자동화를 만드는 최신 Home Assistant Automation UX를 설명한다.
Home Assistant — The Matter upgrade you’ve been waiting for
matter.js 기반 Matter Server 전환, Matter 1.5.1 지원, Thread 1.4 대응과 Camera·Doorbell 등 새로운 Device Type을 위한 기반 확대를 설명한다.

핵심 참고 포인트

2026년 스마트홈 흐름은 단순히 Matter 기기를 더 많이 연결하는 방향에서 집의 상태를 이해하고 사용자의 목표를 바탕으로 능동적으로 행동하는 방향으로 이동하고 있다. Google은 Gemini for Home을 proactive·personalized service Layer로 확장하고 있으며, Home Assistant는 자동화 자체를 기술 용어보다 사람이 원하는 결과 중심으로 만드는 방향으로 바꾸고 있다.

Matter는 Google Home·Apple Home·Home Assistant를 대체하는 기술이 아니라 여러 제조사의 기기가 서로 연결될 수 있도록 하는 공통 연결 계층에 가깝다. Apple 역시 Matter의 핵심 가치를 플랫폼 간 상호운용성으로 설명하고 있으며, iPhone에서 QR 기반 Commissioning과 Multi-ecosystem 활용을 지원한다.

따라서 실사용자에게 가장 현실적인 접근은 기존 Google Home이나 Apple Home을 그대로 유지하면서 Matter 기기와 기본 자동화를 먼저 정리하고, 이후 Context 판단이 필요한 영역에만 AI Agent를 추가하는 것이다. 개발자 관점에서는 Home Digital Twin → Agent Planner → Policy Engine → Google Home/Apple Home/Home Assistant → Matter Device처럼 판단 계층과 실제 제어 계층을 분리하는 구조가 가장 안정적이다.

이경규

iOS 앱 개발자

이전 포스트

이 코드는 누가 만들었나: AI Coding Agent 시대의 Git Provenance와 PR 증명서 설계

다음 포스트