앱 말고, 기계 자체

"앱이 떠 있는 건 앱한테 좋은 소식이야. 그 밑의 기계에 대해선 거의 아무것도 안 알려줘."

좁게 보면 놓쳐

fleet control plane 이라고 하면 다들 앱 모니터링을 떠올려. 웹 서비스 떴나, 큐 빠지나, 컨테이너 멀쩡한가. 진짜 필요한 일이긴 해. 근데 그건 일부야. 건물 꼭대기 층만 보고 건물 전체라고 부르는 거지.

주어는 컴퓨터야

Watchfire 가 보는 건 한 층 아래, Mac 자체야. 어떤 OS 빌드를 도는지. fleet 에 enroll 된 멤버인지, 그냥 네트워크에 굴러다니는 기기인지. 어디로 닿는지. 셸이며 패키지며 설정이며 백그라운드 job 이 흩어졌는지. 돌아야 할 서비스가 진짜 떠 있는지. 앱은 그 신호 중 하나일 뿐이야. health contract 로 받아보는 거지, 일의 경계가 아냐.

넓게 봐야 밥값을 해

앱이 죽는 날, 원인은 대개 한 층 아래 있어. 기계가 OS 업데이트에 뒤처져 의존성이 깨졌거나, 네트워크가 바뀌어 SSH 경로를 잃었거나, 환경이 흩어져 백그라운드 job 이 조용히 멈췄거나. 앱 모니터링은 증상만 보고 원인 앞에선 어깨를 으쓱해. 주어가 기계인 control plane 은 OS 빌드, 도달 여부, drift, 죽은 launchd job 을 한 번에 보고 뭐가 진짜 깨졌는지 짚어.

가져다 쓰되, 흡수하진 마

여기 숨은 규율이 하나 있어. Watchfire 는 형제 엔진의 문서화된 health 를 가져다 써. 떴어? 서빙해? 정도. 근데 그 엔진의 내부 진단이나 재시작 로직을 자기 안에 복사하진 않아. 기계 층은 자기가, 앱 층은 앱이 맡아. 앱한테 기분이 어떤지 묻긴 해도, 앱의 주치의가 되려 들진 않아.

문제가 실제로 사는 층을 관리해. 꼭대기 층만 볼 수 있으면, 지하실 불도 죄다 꼭대기 층의 미스터리로 보여.

Code

관찰 하나, 여러 층·json

{
  "host_id": "server",
  "observed_at": "2026-07-19T04:12:07Z",
  "reachable": { "tailscale": true, "ssh": true },
  "os": { "product": "macOS", "build": "25F84" },
  "resources": { "disk_free_gb": 812, "uptime_days": 6 },
  "services": [
    { "name": "backup-agent",  "expected": true, "loaded": true },
    { "name": "nightly-sync",  "expected": true, "loaded": false }
  ],
  "env_drift": ["shell config newer than fleet baseline"]
}
// 앱 신호(services[])는 reachability, OS, resources, drift 사이의
// 한 칸일 뿐이야. 주어는 기계고, 앱은 그 한 칸이야.

Exercise

네 기계에서 도는 앱 하나 골라. 앱 로그엔 '떠 있음' 인데 밑의 기계는 조용히 망가지는 경우 세 개만 적어봐. 디스크 거의 참, OS 빌드 틀림, autostart 가 멈춘 의존성 같은 거. 하나씩 물어봐. 앱만 보는 모니터링이 이걸 잡아?

Hint

앱은 '나 돌고 있어?' 에 답하고, 기계는 '얼마나 더 버텨?' 에 답해. 디스크 30MB 남은 데서도 프로세스는 멀쩡해 보이거든.

좁게 보면 놓쳐

주어는 컴퓨터야

넓게 봐야 밥값을 해

가져다 쓰되, 흡수하진 마

Code

External links

Exercise

Progress

댓글 0