[ 트렌드] 🍄 에어컨 곰팡이 잡으려다 AI 에이전트를 만들게 된 이야기 (1편)
관
관리자
Lv.1
07-22 20:48
·
조회 26
·
추천 0
> **연재 예고**: 로컬 LLM + Home Assistant로 "말 안 걸어도 알아서 집 습도를 관리하는 AI"를 만드는 과정을 기록합니다. 오늘은 왜 이걸 시작했는지, 그리고 설계까지.
---
## 시작은 특허 아이디어였다
여름마다 반복되는 그 냄새. 에어컨 켜면 훅 끼치는 퀴퀴한 곰팡이 냄새 말입니다.
"열교환기에 기울기를 줘서 물을 빨리 빼면 되지 않을까?" 하고 특허를 검색해봤습니다. 결과는... 다 있더군요. 경사 배치도, 제습제 내장 건조 장치도, 후장착 UV 살균기도 전부 등록 특허가 존재했습니다. 하드웨어 쪽은 제조사들이 수십 년간 파놓은 밭이었습니다.
그런데 조사하다 보니 이상한 빈틈이 보였습니다.
## 다 있는데, '판단'만 없다
2026년 현재 상황을 정리하면 이렇습니다.
- **제조사 AI 에어컨**: 자동건조 기능 있음. 근데 무조건 정해진 시간만 송풍. 오늘이 장마인지, 집에 사람이 있는지 모름
- **Home Assistant**: 세계 최대 오픈소스 홈 자동화. "습도 70% 넘으면 켜라" 같은 규칙은 무한히 만들 수 있음. 근데 규칙은 규칙일 뿐
- **HA + 로컬 LLM**: 2026년 들어 Ollama 통합이 표준화되면서 "거실 불 꺼줘" 하면 알아듣는 음성 비서는 완성 단계
전부 **반응형**입니다. 사람이 말을 걸어야 움직입니다.
제가 원하는 건 다릅니다. **아무도 말 안 걸었는데** 혼자 이렇게 생각하는 놈입니다.
> "냉방이 방금 끝났네. 실내 습도 78%, 3시간째 오르는 중. 내일까지 비 예보. 집엔 아무도 없음. → 지금 건조 운전 20분 돌리고, 주인이 오면 보고하자."
이런 **자율 판단 루프를 가진 도메인 특화 에이전트**는 찾아봐도 없었습니다. 다들 자비스처럼 '말 걸기'에 몰려 있고, '말 안 걸어도 알아서 하는 전문가'는 비어 있습니다.
## 그래서 만들기로 한 것: MoldGuard
구조는 4층입니다.
```
[판단] 로컬 LLM (Ollama, M1 Max)
↓ "건조 20분 돌려. 이유는 이거야" (JSON)
[검증] 화이트리스트 + 빈도 제한 (코드)
↓ 통과한 명령만
[실행] Home Assistant → 에어컨/제습기
↓
[기록] 모든 판단과 결과를 SQLite에
```
설계 원칙 몇 가지에 공을 들였습니다.
**1. LLM은 판단만, 실행은 코드가.**
LLM 출력이 기기를 직접 만지는 경로는 없습니다. 허용된 액션 목록(건조 운전, 제습기 on/off 정도)을 코드가 검증하고, 이상하면 "아무것도 안 함"이 기본값. AI한테 집 열쇠를 주되, 방마다 잠금장치는 따로 두는 셈입니다.
**2. 카메라 없음, 마이크 없음.**
"집에 사람 있나"는 판단에 중요한 정보인데, 카메라를 달 필요가 없습니다. 폰이 집 Wi-Fi에 붙어 있는지만 보면 됩니다(HA 기본 기능, 추가 비용 0원). 얼굴 인식 같은 민감정보 처리 없이 "누구의 폰이 집에 있다"로 충분합니다.
**3. 침묵이 기본.**
알림은 주 1회 리포트가 원칙입니다. "이번 주 건조 5회 돌렸고, 장마라 2회 늘렸어요. 냄새 안 나죠?" 이 한 줄이면 됩니다. 시도 때도 없이 말 거는 AI는 일주일 안에 꺼집니다.
**4. 어떤 에어컨이든.**
삼성/LG API가 아니라 IR(적외선) 허브로 제어합니다. SwitchBot 허브2 + 온습도계 합쳐서 5만원. 20년 된 벽걸이 에어컨도 에이전트의 손발이 됩니다. 대기업 홈 에이전트는 자사 신제품만 챙기지만, 실제 우리 집은 "삼성 에어컨 + 위닉스 제습기 + 10년 된 보일러" 잡탕이잖아요. 그 잡탕을 그대로 지능화하는 게 목표입니다.
## 첫 실험: 규칙 vs LLM, 진짜 차이 있나?
사실 이 프로젝트엔 불편한 질문이 하나 있습니다.
**"습도 70% 넘으면 건조 돌려" 규칙이면 충분한 거 아냐? LLM이 왜 필요해?**
맞는 지적일 수 있습니다. 그래서 첫 단계는 하드웨어 없이 시뮬레이션입니다. 가상의 장마철 한 달 데이터를 만들어서, 같은 상황에 규칙 기반과 LLM 판단을 나란히 돌려보고 비교합니다. LLM이 정말 더 나은 결정을 하는지, 아니면 비싼 if문에 불과한지. 데이터로 답이 나오면 그때 5만원을 씁니다.
솔직히 어느 쪽 결과가 나와도 재밌을 것 같습니다.
## 왜 이게 에어컨만의 이야기가 아닌가
한 발 물러서면 이런 그림이 보입니다. 가전이 API/IR로 호출 가능해지고, MCP 같은 표준이 도구 호출을 통일하면 — 집집마다 에이전트 하나가 있고, 가전은 그 에이전트의 '스킬'이 되는 세상. CLI로 서버 다루듯 집을 다루는 거죠.
그 세상이 오면 앱스토어처럼 **스킬 마켓**이 생길 겁니다. 그리고 초기 마켓은 언제나 콘텐츠 기근입니다. "한국 장마철 + 누진세 + 아파트 결로"에 맞는 스킬은 구글도 삼성도 안 만듭니다. 그건 우리 같은 사람이 먼저 만드는 겁니다.
MoldGuard는 그 첫 번째 스킬 후보이자, 예행연습입니다.
---
**다음 편 예고**: 시뮬레이터를 만들고, 가상 장마 한 달을 돌립니다. 규칙 vs LLM 대결 결과 공개.
*이 프로젝트는 오픈소스로 공개할 예정입니다. 관심 있으신 분은 댓글 남겨주세요.*
---
## 시작은 특허 아이디어였다
여름마다 반복되는 그 냄새. 에어컨 켜면 훅 끼치는 퀴퀴한 곰팡이 냄새 말입니다.
"열교환기에 기울기를 줘서 물을 빨리 빼면 되지 않을까?" 하고 특허를 검색해봤습니다. 결과는... 다 있더군요. 경사 배치도, 제습제 내장 건조 장치도, 후장착 UV 살균기도 전부 등록 특허가 존재했습니다. 하드웨어 쪽은 제조사들이 수십 년간 파놓은 밭이었습니다.
그런데 조사하다 보니 이상한 빈틈이 보였습니다.
## 다 있는데, '판단'만 없다
2026년 현재 상황을 정리하면 이렇습니다.
- **제조사 AI 에어컨**: 자동건조 기능 있음. 근데 무조건 정해진 시간만 송풍. 오늘이 장마인지, 집에 사람이 있는지 모름
- **Home Assistant**: 세계 최대 오픈소스 홈 자동화. "습도 70% 넘으면 켜라" 같은 규칙은 무한히 만들 수 있음. 근데 규칙은 규칙일 뿐
- **HA + 로컬 LLM**: 2026년 들어 Ollama 통합이 표준화되면서 "거실 불 꺼줘" 하면 알아듣는 음성 비서는 완성 단계
전부 **반응형**입니다. 사람이 말을 걸어야 움직입니다.
제가 원하는 건 다릅니다. **아무도 말 안 걸었는데** 혼자 이렇게 생각하는 놈입니다.
> "냉방이 방금 끝났네. 실내 습도 78%, 3시간째 오르는 중. 내일까지 비 예보. 집엔 아무도 없음. → 지금 건조 운전 20분 돌리고, 주인이 오면 보고하자."
이런 **자율 판단 루프를 가진 도메인 특화 에이전트**는 찾아봐도 없었습니다. 다들 자비스처럼 '말 걸기'에 몰려 있고, '말 안 걸어도 알아서 하는 전문가'는 비어 있습니다.
## 그래서 만들기로 한 것: MoldGuard
구조는 4층입니다.
```
[판단] 로컬 LLM (Ollama, M1 Max)
↓ "건조 20분 돌려. 이유는 이거야" (JSON)
[검증] 화이트리스트 + 빈도 제한 (코드)
↓ 통과한 명령만
[실행] Home Assistant → 에어컨/제습기
↓
[기록] 모든 판단과 결과를 SQLite에
```
설계 원칙 몇 가지에 공을 들였습니다.
**1. LLM은 판단만, 실행은 코드가.**
LLM 출력이 기기를 직접 만지는 경로는 없습니다. 허용된 액션 목록(건조 운전, 제습기 on/off 정도)을 코드가 검증하고, 이상하면 "아무것도 안 함"이 기본값. AI한테 집 열쇠를 주되, 방마다 잠금장치는 따로 두는 셈입니다.
**2. 카메라 없음, 마이크 없음.**
"집에 사람 있나"는 판단에 중요한 정보인데, 카메라를 달 필요가 없습니다. 폰이 집 Wi-Fi에 붙어 있는지만 보면 됩니다(HA 기본 기능, 추가 비용 0원). 얼굴 인식 같은 민감정보 처리 없이 "누구의 폰이 집에 있다"로 충분합니다.
**3. 침묵이 기본.**
알림은 주 1회 리포트가 원칙입니다. "이번 주 건조 5회 돌렸고, 장마라 2회 늘렸어요. 냄새 안 나죠?" 이 한 줄이면 됩니다. 시도 때도 없이 말 거는 AI는 일주일 안에 꺼집니다.
**4. 어떤 에어컨이든.**
삼성/LG API가 아니라 IR(적외선) 허브로 제어합니다. SwitchBot 허브2 + 온습도계 합쳐서 5만원. 20년 된 벽걸이 에어컨도 에이전트의 손발이 됩니다. 대기업 홈 에이전트는 자사 신제품만 챙기지만, 실제 우리 집은 "삼성 에어컨 + 위닉스 제습기 + 10년 된 보일러" 잡탕이잖아요. 그 잡탕을 그대로 지능화하는 게 목표입니다.
## 첫 실험: 규칙 vs LLM, 진짜 차이 있나?
사실 이 프로젝트엔 불편한 질문이 하나 있습니다.
**"습도 70% 넘으면 건조 돌려" 규칙이면 충분한 거 아냐? LLM이 왜 필요해?**
맞는 지적일 수 있습니다. 그래서 첫 단계는 하드웨어 없이 시뮬레이션입니다. 가상의 장마철 한 달 데이터를 만들어서, 같은 상황에 규칙 기반과 LLM 판단을 나란히 돌려보고 비교합니다. LLM이 정말 더 나은 결정을 하는지, 아니면 비싼 if문에 불과한지. 데이터로 답이 나오면 그때 5만원을 씁니다.
솔직히 어느 쪽 결과가 나와도 재밌을 것 같습니다.
## 왜 이게 에어컨만의 이야기가 아닌가
한 발 물러서면 이런 그림이 보입니다. 가전이 API/IR로 호출 가능해지고, MCP 같은 표준이 도구 호출을 통일하면 — 집집마다 에이전트 하나가 있고, 가전은 그 에이전트의 '스킬'이 되는 세상. CLI로 서버 다루듯 집을 다루는 거죠.
그 세상이 오면 앱스토어처럼 **스킬 마켓**이 생길 겁니다. 그리고 초기 마켓은 언제나 콘텐츠 기근입니다. "한국 장마철 + 누진세 + 아파트 결로"에 맞는 스킬은 구글도 삼성도 안 만듭니다. 그건 우리 같은 사람이 먼저 만드는 겁니다.
MoldGuard는 그 첫 번째 스킬 후보이자, 예행연습입니다.
---
**다음 편 예고**: 시뮬레이터를 만들고, 가상 장마 한 달을 돌립니다. 규칙 vs LLM 대결 결과 공개.
*이 프로젝트는 오픈소스로 공개할 예정입니다. 관심 있으신 분은 댓글 남겨주세요.*
💬 0
로그인 후 댓글 작성
첫 댓글을 남겨보세요!