Desired State: 약속

"desired state 는 '이 기계는 … 여야 해' 라는 문장이야. 적어두고, 버전 매기고, 주인이 있는."

policy 는 적어두는 약속

desired state 는 기계가 무엇을 위한 건지 적어두는 층이야. 지금 뭘 하고 있냐가 아니라, 어떤 상태여야 하냐. 작은 policy 필드 몇 개고, 잔소리하는 대시보드랑 믿을 만한 대시보드를 가르는 게 딱 이거야.

'여야 한다' 의 필드들

호스트 policy 엔 이런 게 담겨. availability_policy 는 늘 켜둘지, 자도 될지, 수동인지, 유지보수 중인지. desired_power_state, 떠 있어야 할 expected_services, 이 호스트를 겨눌 수 있는 allowed_operation_classes, 침묵이 무슨 뜻이 되기까지 얼마나 참을지 정하는 alert_after. 필드 하나하나가 status 엔진이 현실이랑 맞춰볼 약속이야.

override 는 편집이 아니라 typed

아빠가 여행 떠나면, 맞는 수는 랩탑을 지우거나 걔 진실을 '앞으로 영영 offline 이어도 됨' 으로 고쳐 쓰는 게 아냐. 주인, 이유, 시작, 만료를 갖춘 임시 override 야. '이 기계는 20일까지 안 닿아도 됨.' 기본 policy 는 안 건드려지고, override 는 알아서 만료되고, 되돌리는 걸 아무도 기억 안 해도 돼.

desired 는 membership 을 못 뒤집어

policy 엔 상사가 있어. membership 이야. retired 된 기계는 'online 이길 기대' 될 수 없어. 걔 management_enabled 은 membership 상태에서 나오니까, suspended 랑 retired 호스트는 그냥 새 작업 대상이 안 돼. desired state 는 힘이 세지만, lifecycle 위가 아니라 그 안에 살아.

당황 말고 약속을 적어. 기계가 어떤 상태여야 하는지 policy 에 한 번 적어두면, '이거 문제야?' 가 새벽 두 시의 고민이 아니라 그냥 비교가 돼.

Code

호스트의 desired state·json

{
  "host_id": "laptop",
  "membership_state": "active",
  "availability_policy": "sleep_allowed",
  "desired_power_state": "sleep_allowed",
  "expected_services": ["backup-agent"],
  "allowed_operation_classes": ["read", "low", "medium"],
  "alert_after_seconds": 604800,
  "override": {
    "owner": "dad",
    "reason": "traveling until the 20th",
    "starts_at": "2026-07-06T00:00:00Z",
    "expires_at": "2026-07-20T00:00:00Z"
  }
}
// 여기 없는 걸 봐. live "online" 필드가 없어. policy 는 뭐가 참이어야
// 하는지를 말해. 랩탑이 지금 닿는지는 observed 층 얘기고, 이 약속에
// 맞춰서 계산돼. 약속이랑 사실을 같은 칸에 저장하는 게 아니라.

Exercise

네 기계 하나에 다섯 필드짜리 policy 를 써봐. 역할, 자도 되는지, 늘 돌아야 할 서비스 하나, 신경 쓰이기 전까지 침묵을 얼마나 참을지, 누가 policy 를 바꿀 수 있는지. 그다음 2주 여행용으로 알아서 만료되는 임시 override 를 하나 붙여.

Hint

override 가 만료 없는 'online-ok = true' 면, override 를 쓴 게 아니라 진실을 고쳐 쓴 거야. 여행 끝나는 순간 되돌리는 걸 까먹지.

policy 는 적어두는 약속

'여야 한다' 의 필드들

override 는 편집이 아니라 typed

desired 는 membership 을 못 뒤집어

Code

External links

Exercise

Progress

댓글 0