스마트홈을 오래 다뤄본 사람일수록 비슷한 벽에 부딪힌다. 자동화는 잘 돌아가는데, 정작 집 안의 다른 식구들은 앱을 켜지 않는다. 한 개발자가 오픈소스 스마트홈 플랫폼인 홈 어시스턴트(Home Assistant)로 1년간 집을 자동화한 뒤 내린 결론도 같았다. 아무도 열지 않는 대시보드는 기능이 아무리 많아도 소용이 없다는 것이다. 그가 택한 해법은 기능을 더 얹는 대신, 모두가 보고 싶어 할 만큼 매력적인 화면을 만드는 것이었다. 일러스트레이터를 고용해 자기 집을 그림으로 그리게 하고, 그 그림을 그대로 대시보드로 삼았다.
문제의식은 구체적이었다. 모두가 외출하면 에어컨이 꺼지고, 정원 스프링클러는 날씨에 따라 가동 시간을 스스로 계산해 더운 날엔 길게, 비 오는 날엔 아예 건너뛴다. 그러나 사람이 꼭 개입해야 하는 장치도 남는다. 대표적인 것이 정원 조명으로, 앱에서만 켤 수 있는 데다 타이머가 일정 시간 뒤 자동으로 끈다. 꺼지기 직전 조명이 깜빡여 앱을 열어 연장할 시간을 주지만, 가족 중 누구도 그 앱이나 기존 대시보드를 쓰고 싶어 하지 않았다. 물리 스위치를 달아도 타이머 문제는 그대로이고, 스프링클러처럼 앱으로 다루는 편이 훨씬 편한 장치도 있었다.
그림이 곧 프로젝트다
그는 집 구조를 그대로 옮긴 인터랙티브 평면도에 끌렸다. 흔히 보이는 3D 평면도는 대개 정적인 이미지 위에 아이콘을 얹는 방식이었고, 픽셀아트는 매력적이지만 직접 그리거나 스프라이트를 일일이 배치해야 했다. 결국 공간을 아름답게 그려온 환경 아티스트를 추천받아 맡겼다. 여기서 그가 강조하는 교훈은, 좋은 아티스트를 찾고 일정을 잡는 일 자체가 생각보다 어렵다는 점이다. 작가마다 스타일이 다르고, 인기 작가는 몇 달치 예약이 차 있으며 작업에도 수 주에서 수개월이 걸린다. 게다가 대시보드라는 의뢰는 그림만 잘 그려서 되는 것이 아니라, 작가가 이 결과물이 기술적으로 무엇을 위한 것인지 이해해야 한다.
그래서 그는 작가에게 넘길 자료를 꼼꼼히 꾸렸다. 가구 없는 건축 평면도(가구 위치는 직접 표시), 방 사진, 스타일과 색 참고용 일러스트, 다른 대시보드 예시, 그리고 필요한 파일·포맷과 각 자료의 용도를 적은 기술 명세서다. 지난 리모델링의 페인트 색상 코드도 사진으로 보정 가능하지만 참고로 보탰다. 핵심은 기술 명세다. 투명 PNG(애니메이션은 WebP), 층마다 낮과 밤 두 버전, 장치마다 별도 레이어에 '꺼짐'용 정지 이미지와 '켜짐'용 짧은 반복 프레임(8장이면 충분)을 낮·밤 조명으로 각각 요청했다. 무엇보다 모든 파일을 동일한 크기의 공유 캔버스 위에 집 안 제자리에 배치해 내보내도록 했다. 이 한 가지 규칙이 나중에 요소를 맞추는 수고를 며칠씩 줄여준다. 정원은 낮·밤·조명 켠 밤의 세 버전이 됐고, 애니메이션은 스프라이트 시트로 받았다가 직접 WebP로 변환했으니 처음부터 WebP로 요청하라고 조언한다.
재주 몇 가지로 완성되는 구현
그림이 완성되면 홈 어시스턴트 구현은 의외로 단출하다. 기본 제공 카드인 picture-elements 하나가 뼈대다. 일러스트를 배경(image:)으로 깔고, 바뀌는 장치와 상태 표시는 그 위에 각자 좌표를 갖는 요소로 올린다. 장치엔 image, 상태 표시엔 icon과 state-label, 조건부 노출엔 conditional을 썼다. 첫 번째 재주는 state_image로, 꺼짐일 땐 정지 프레임을 켜짐일 땐 애니메이션 WebP를 보여주면 브라우저가 알아서 재생하므로 별도 코드가 필요 없다. 두 번째는 낮/밤 전환이다. 헬퍼를 만들어 일출·일몰에 자동으로 바꾸되 수동 전환도 되도록 해 테스트에 유용하게 썼고, 밤 그림은 낮 그림 위에 conditional로 얹었다.
장치를 누르면 홈 어시스턴트 기본 제어 창(tap_action: more-info)이 열려 별도 설계가 필요 없었다. 예외는 정원 관수로, 아이콘은 하나지만 뒤에 여러 밸브와 타이머가 묶여 있어 기본 창이 없다. 이 경우 HACS로 설치하는 Browser Mod로 직접 팝업 창을 만들었다. 이미지는 URL이나 로컬 경로로 참조하므로 어딘가에 올려야 하는데, 그는 /config/www 폴더를 만들어 홈 어시스턴트 기기에서 직접 제공하는 길을 택했다.
TV라는 마지막 관문
TV에 띄우는 과정이 오히려 까다로웠다. LG webOS 브라우저가 WebP를 지원하지 않는다는 글을 봤지만, 테스트 이미지 한 장으로 사실이 아님을 확인했다. 그 주장은 브라우저가 아니라 TV 내장 사진 뷰어 이야기일 가능성이 높다. 진짜 문제는 webOS가 웹페이지를 화면보호기나 기본 페이지로 지정할 수 없어 리모컨 조작이 매번 필요하다는 점이었다. 그는 TV 소프트웨어를 우회해, 옆에 둔 홈 어시스턴트 기기에 HAOS Kiosk Display 애드온을 설치하고 HDMI 입력에 연결했다. 이제 대시보드는 항상 열려 있는 또 하나의 입력일 뿐이다.
화면 구성은 층별·정원별 개별 뷰와 이를 한데 모은 '전체' 뷰로 나눴다. 여기서 공유 캔버스가 빛을 발한다. 각 뷰는 같은 마스터 캔버스에서 잘라낸 것이라, 전체 뷰에서 각 층을 원래 위치로 되돌리면 이미지 편집기의 레이어처럼 저절로 맞춰진다. 정원을 집 아래에 두고 1층을 지면층보다 살짝 띄워 단면을 들여다보는 듯한 느낌을 냈다. 다만 홈 어시스턴트 UI 편집기는 카드 간 요소 공유를 못 해, 장치를 층 뷰와 전체 뷰에 두 번 설정해야 하는 문제가 있었다. 그는 대시보드를 YAML 모드로 전환해 층별 요소를 파일로 분리하고 양쪽 뷰가 이를 포함하도록 했다. 한 번 수정하면 어디서나 반영되고, 등록을 위한 최초 재시작 뒤엔 브라우저 새로고침만으로 편집이 반영된다. 대가는 비주얼 편집기를 잃는 것이지만, 그 시점엔 대부분 작업이 끝나 있어 부담이 적었다. picture-elements가 다른 카드를 품지 못하는 제약은 vertical-stack으로 층을 쌓고 card-mod(CSS 스타일링용 HACS 플러그인)로 위치를 잡아 해결했다.
흥미로운 반전도 있다. HDMI로 연결된 TV는 리모컨으로 대시보드를 조작할 수 없어 '보는 용도'에 그친다. 그런데 이것이 오히려 효과를 냈다. TV에 멋진 화면이 걸리자, 앱을 꺼리던 가족들이 직접 조작하려고 스스로 휴대폰에 앱을 깔거나 PC에 대시보드를 북마크했다. 층별 뷰는 휴대폰에서 잘 보이고 전체 뷰는 노트북급 화면이 필요하다. TV는 아무도 다른 걸 보지 않을 때 아침과 저녁 몇 시간씩 대시보드로 전환되고, Kiosk Mode로 메뉴를 숨겨 순수한 화면만 남겼다. 결국 이 프로젝트가 주는 실무적 교훈은 코드가 아니라 준비에 있다. 작가 섭외와 명세 정리가 작업의 대부분을 차지했고, 공유 캔버스 같은 사소해 보이는 규칙 하나가 전체 난이도를 좌우했다. 사람이 쓰게 만드는 것이야말로 자동화의 마지막 단계라는 점을, 이 그림 한 장이 보여준다.