클라우드플레어 OS에는 Home Assistant로 연결하는 기능이 있으며, 허용하면 조명이나 에어컨도 제어할 수 있습니다.
그 정도로만 알고 있는데, 저는 여러 번 같은 질문으로 돌아갔습니다.
그렇다면 평소에는 어떤 화면을 사용하는 걸까요.
조명과 냉방은 이미 Home Assistant에서 조작할 수 있으며, 자주 사용하는 기능에는 물리 버튼도 있다. Cloudflare OS를 통해서도 조작할 수 있다는 점은 그대로 사용 이유가 되었다.
한편, GitHub의 이용 현황을 살펴보니 클라우드에서 자동 검사를 실행할 수 있는 월 3,000분의 가운데 18분만 사용되었고, 남은 2,982분이다.
그러므로 클라우드플레어, 코파일럿, 맥, 그리고 집에서 사용하는 소형 리눅스 PC까지 포함하여 이미 활용 가능한 컴퓨팅 자원의 업무를 재분배했다.
클라우드플레어 OS에는 조명의 스위치가 남지 않았다. Home Assistant나 GitHub 등을 하나하나 확인해야 할 필요 없이 “오늘은 무엇을 확인해야 하는지”가 명확하게 보이는 화면으로 바뀌었다.
GitHub에서 남은 시간은, 집과는 분리된 환경에서 시도해 보는 의미가 있는 테스트에 활용한다. 맥(Mac)과 자택 PC는 현물과 가까운 검토를 담당한다. Copilot 등 이용 쿼타(사용 가능 횟수)가 있는 AI는, 사용이 불가능하더라도 테스트 자체를 멈추지 않는 업무에만 추가한다.
사용 가능한 계산 자원은 활용한다. 다만, 특정 이용 량이 소진된 날에는 가정의 자동화를 업데이트할 수 없게 되는 구성에는 하지 않는다.
검사를 가정 PC로 옮겨 GitHub에 2,982분이 남았습니다.
이전에는 GitHub Actions의 사용 시간을 줄이고 싶었다. Actions는 변경 사항을 집으로 가져오기 전의 자동 점검을 실행하는 시스템이다. 그래서 집에서 사용하는 Linux 소형 PC를 self-hosted runner로 설정했다. Runner는 그 점검을 실제로 실행하는 컴퓨터이다.
실제와 가까운 리눅스 환경에서 확인해 보거나, 긴 처리를 그쪽으로 위탁했다. 평소 편집과 가벼운 검사는 맥에서 가능하다. 그 분류 방식 자체는 잘 되었다.
계획이 너무 잘 진행되어 GitHub 측의 사용량이 “3,000분 중 18분”으로 줄어들었다.
2,982분을 남은 화면을 보며 절약의 방향을 잘못 잡았다는 생각이 들었다. 하지만 분수를 소비하기 위해만 검사를 늘리는 것도 무방하다.
GitHub 쪽에 돌아간 것은, 집 밖에서 움직이는 거기서 의미가 있는 검사였다. 텅 빈 환경에서의 재현, 저장소의 권한만으로 완결되는 점검, 집 PC에 남아있던 소프트웨어에 우연히 의존하지 않는지의 확인. 집에서 통과하는 것이 아니라, 집에서 분리했을 때도 통과하는지 보는 일이다.
한편, 브라우저에서의 가벼운 확인은 맥(Mac), 실제와 유사한 리눅스나 도커(Docker) 조사로는 집 PC를 사용했다. 클라우드플레어 워커스(Cloudflare Workers)에는 이벤트 처리만, 워커스 AI(Workers AI)와 코파일럿(Copilot)에는 짧은 분류나 초동 진단만 수행했다.
그림 아래쪽 부분에 배치된 fallback은 이 분류 방식의 핵심이다. GitHub의 분량을 모두 소진해도 집 PC에서 필수 검사를 계속할 수 있다. Workers AI나 Copilot의 枠이 다 떨어지면 AI의 보조 기능만 제거한다. 모든 무료 또는同梱 枠에도 검사 결과 자체와 Release 경로를 맡기지 않는다. Release는 검사를 완료한 변경 사항을 집으로 배송하는 명시적인 반영 절차이다.
클라우드플레어 OS는 조명 정보가 아닌 “확인 필요” 항목만 수집합니다.
계산 자원의 담당이 지정되었지만, 클라우드플레어 OS의 활용도는 여전히 남아 있었다.
2026년 8월에 공개된 클라우드플레어 OS에는 외부 서비스에 대한 권한을 제한하는 Gatekeeper가 있다. Home Assistant용 Gatekeeper는 상태와 히스토리를 읽는 것뿐만 아니라 조명 및 에어컨 서비스 호출, Lovelace 편집까지 처리하며, 쓰기 작업은 인간의 승인을 거친다.
기능은 흥미롭지만, 거실 조명을 켜려면 Home Assistant나 물리 버튼이 더 빠릅니다. Cloudflare OS에 동일한 버튼을 배치하면 확인 화면이 1장 더 늘어납니다.
그러다 용도를 뒤집었다.
Home Assistant의 경고나 GitHub의 자동 검사는 문제가 발생했을 때만 확인하면 된다.
저는 집의 자동화와 별도로, 아마존 주문 내역, 신용카드 이용 내역, 포인트 사용 기록을 비교하여 동일한 구매 기록으로 가계부 앱에 정리하는 시스템도 만들고 있습니다. 주문과 결제의 조합이 확실한 것은 자동으로 처리하고, 판단하기 어려운 것들만 인간의 확인에 회부합니다.
홈 어시스턴트 경고, GitHub 검사 실패, 구매 및 결제 연결 오류 기록. 분야가 달라도, 내가 보고 싶었던 것은 모두 “인간의 판단이 필요한 예외”뿐이었다.
클라우드플레어 OS는 해당 예외만 수집합니다. 작동 버튼은 제공하지 않으며, 아무런 내용이 없으면 조용히 유지하고 확인이 필요한 경우 건수와 입구만 표시합니다. 상세 조사가 필요한 경우 각 화면으로 다시 돌아갑니다.
이는 완성된 지휘실이 아니다. 현재 Home Assistant Gatekeeper는 Home Assistant 측의 이벤트를 Cloudflare OS로 푸시하는 Hook이 구현되지 않았으며, setHook 또한 동작하지 않는 것으로 명시되어 있다. 처음에는 화면을 열었을 때 확인해야 할 작업을 모아놓은 Operations Inbox로 시작한다.
실시간성을 우선적으로 요구하면 새로운 알림 기반과 유지보수 대상이 증가한다. 내가 줄이고 싶은 것은 이상 유무를 확인하기 위한 순회였다.
AI의 틀이 다 써 버리면 AI 부분만 쉬게 한다.
Copilot이 사용 가능한 동안에는 실패 로그의 원인 후보를 먼저 제시한다. Workers AI에는 짧은 요약이나 분류를 맡기는 데 유용하며, 둘 다 편리하지만 필수적인 검사에는 사용하지 않는다.
프레임을 모두 사용한 날에는 인간이 로그를 읽는다. CI의 성공 여부, 원래 로그, 릴리즈의 문턱은 그대로 남아 있다. AI가 대답하지 않는 것과 집의 변경 사항을 확인하지 못하는 것을 동일한 장애로 간주하지 않는다.
맥과 자가 PC의 분담도 같다. 맥으로 일상적인 편집과 확인을 하고, 리눅스 고유의 조사를 자가 PC에서 실행한다. 조사 결과에서 변경을 수용하는 경우 GitHub로 다시 돌아가 풀 리퀘스트와 자동 점검을 거쳐 릴리스한다. 진단용의 간ทาง을 그대로 집을 바꿔 쓰는 간ทาง에는 하지 않는다.
이 선을 긋는 행위는 무료 枠을 활용하는 것과 무료 枠에 의존하는 것을 분리했다. 枠이 있는 달은 다소 빠르게 진행되고, 枠이 끊어진 달은 다소 조용해진다. 그것으로 충분하다.
다음으로 계산하는 것은 열지 않아도 되는 화면입니다.
운영용 인박스는 먼저 Home Assistant와 GitHub로만 테스트한다. 거기서 세는 것은 2,982분을 몇 분 소비했는가가 아니다.
이상 징후가 없는지 확인하기 위해만 열린 화면이 몇 장이나 줄었는지 확인했다. Cloudflare OS를 한 번만 보아도 충분하다면, 다음에는 주문과 결제 일자 확인에 사람의 확인을 돌리는 기록도 같은 입구로 가져왔다. 확인 장소가 1개 늘어난 것뿐이라면, 이 용도는 제거한다.
먼저 그 자원이 고갈되었을 때 무엇이 멈추는지를 미리 결정해야 한다.
제 경우에는 AI의 초기 진단은 멈추는 것으로 충분합니다. 조명을 켜는 버튼도 Cloudflare OS에는 필요하지 않습니다. 남겨두어야 할 것은 검사 결과, Release 경로, 그리고 오늘 어디를 방문해야 할지 짧은 시간 안에 알 수 있는 진입점입니다.
출처: note 원문
번역: Gemma 3(.44) 초벌 + 교정 25청크
원문 보기 | 출처: note.com