"앱이 떠 있는 건 앱에 대한 좋은 소식이야. 그 밑의 기계에 대해선 거의 아무것도 안 알려줘."
솔깃한 좁은 범위
fleet control plane 이라고 하면 대부분 앱 모니터링을 떠올려: 웹 서비스 떴나, 큐 빠지나, 컨테이너 건강한가. 진짜고 유용해 — 근데 그건 부분집합이야. 건물 꼭대기 층을 보고 건물이라고 부르는 거지.
주어는 컴퓨터야
Watchfire 의 주어는 한 층 아래야: Mac 자체. 어떤 OS 빌드를 도는지. fleet 의 enroll 된 멤버인지, 아니면 그냥 네트워크에 있는 어떤 기기인지. 도달 가능한지, 어느 경로로. 환경이 흩어졌는지 — 셸, 패키지, 설정, 백그라운드 job. 돌아야 하는 서비스가 실제로 loaded 됐는지. 앱은 그 신호들 중 하나야, health contract 로 받는 — 일의 경계가 아니라.
넓은 범위가 밥값 하는 이유
앱이 죽은 날, 원인은 종종 그 아래 층에 있어: 기계가 OS 업데이트에 뒤처져서 의존성이 깨졌거나, 네트워크 변경 후 SSH 경로를 잃었거나, 환경이 흩어져서 백그라운드 job 이 조용히 멈췄거나. 앱 모니터링은 증상을 보고 원인 앞에서 어깨를 으쓱해. 주어가 기계인 control plane 은 OS 빌드, 도달성, drift, 그리고 죽은 launchd job 을 한 호흡에 보고 — 뭐가 진짜 깨졌는지 짚어줘.
소비하되, 흡수하지 마
여기 숨은 규율이 있어: Watchfire 는 형제 엔진의 문서화된 health 를 소비해 — 떴어? 서빙해? — 하지만 그 엔진의 내부 진단이나 재시작 로직을 자기 안에 복사하진 않아. 기계 층은 자기 것으로, 앱 층은 앱 것으로 남아. Watchfire 는 앱한테 기분이 어떤지 묻지, 앱의 의사가 되려고 하진 않아.