승인한 걸 얼려라

"넌 행동을 승인하는 게 아냐. 정확한 기계 목록에 대한 행동을 승인하는 거고 — 그 목록은 이후에 움직이면 안 돼."

승인은 blast radius 에 대한 동의

operation 을 승인할 때, 넌 그냥 응, 그거 해 가 아니라 — 응, 정확히 이 기계들한테 해 라고 말하는 거야. target 집합이 바로 네가 승인한 위험의 범위야. 그래서 승인이 일어나는 순간 그 집합이 snapshot 으로 얼려져.

live selector 는 승인을 배신해

target 이 frozen 목록 대신 live query — 모든 always-on 서버 — 라고 상상해. 리뷰하니 세 대가 읽히고, 승인해. 그다음 네 번째 서버가 부팅을 끝내고 이제 query 에 매치돼. live selector 면, 걘 리뷰 안 된 batch 에 조용히 합류해. 승인 시 정확한 host id 를 얼리면 그 문이 닫혀: 네가 본 집합이 도는 집합이야.

preflight 은 현실이 여전히 맞는지 증명해

target 을 얼리는 것만으론 부족해, 세상이 승인이랑 실행 사이에 움직이니까. 그래서 돌리기 직전에, preflight 이 각 frozen target 의 precondition 을 재확인해 — 도달 가능해, capability 여전히 맞아, 이미 진행 중인 conflicting operation 있어? frozen target 에 fresh preflight 를 더하면: 특정 집합을 승인했고, 작업이 실제로 시작할 때 현실이 여전히 동의한다는 뜻이야.

verify 랑 recover 는 미리 정해

operation 은 또, planned 되는 순간부터, 성공을 어떻게 verify 하고 실패에서 어떻게 recover 할지 지녀. 둘 다 돌리기 전에 적히지, incident 도중에 즉흥이 아냐 — rollback plan 을 지어내기 제일 나쁜 때가 이미 불난 동안이니까.

승인한 걸 얼려. 움직이는 selector 가 조용히 넓힐 수 있는 승인은 승인이 아니라 — 나중에 누가 채우는 빈칸이야.

Code

live query 가 아니라 frozen 집합·python

# 틀림 -- target 이 run 시점에 live 로 resolve:
#   op.targets = lambda: query("role = always_on")   # 네 번째 서버가 끼어들 수 있음

# 맞음 -- 한 번 resolve, 승인 시 frozen:
op.target_snapshot = ["office", "server", "laptop"]   # 아빠가 리뷰한 정확히 그것
op.approved_at = "2026-07-19T09:00:00Z"

# 돌리기 직전, preflight 이 각 FROZEN target 을 재확인:
for host in op.target_snapshot:
    assert reachable(host)
    assert caps_match(host, op.required_capabilities)
    assert no_conflicting_op(host)

# 집합을 승인했고; preflight 이 현실이 여전히 맞는지 확인해.
# 서명 후 새로운 게 batch 에 못 들어와.

Exercise

'이 서버들 업데이트해' 에 대한 승인을 설계해. 정확한 frozen 목록을 쓰고, 네 승인이랑 run 사이에 자격이 생길 수 있는 기계 하나를 묘사해. 얼리는 게 뭘 막아주고 — preflight 이 얼리는 것만으론 못 잡는 걸 뭘 잡아?

Hint

얼리는 건 새 기계가 합류하는 걸 막아. preflight 은 이미 승인된 기계가 서명이랑 시작 사이에 바뀐 걸(잠들고, SSH 잃고, 다른 op 시작) 잡아. 둘 다 필요해: 하나는 집합을, 하나는 각 멤버를 지켜.

승인은 blast radius 에 대한 동의

live selector 는 승인을 배신해

preflight 은 현실이 여전히 맞는지 증명해

verify 랑 recover 는 미리 정해

Code

External links

Exercise

Progress

댓글 0