승인한 걸 굳혀라

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

승인은 blast radius 에 대한 동의

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

live selector 는 승인을 배신해

target 이 굳은 목록 대신 live query 라고 해봐. '모든 늘 켜둔 서버' 같은 거. 리뷰해보니 세 대가 읽히고, 승인해. 그다음 네 번째 서버가 부팅을 끝내고 이제 query 에 걸려. live selector 면, 걔가 리뷰도 안 된 batch 에 조용히 끼어들어. 승인 때 정확한 host id 를 굳혀버리면 그 문이 닫혀. 네가 본 집합이 곧 도는 집합이야.

preflight 이 현실이 아직 맞는지 증명해

target 만 굳혀선 부족해. 승인이랑 실행 사이에 세상이 움직이니까. 그래서 돌리기 직전에 preflight 이 굳은 target 하나하나의 precondition 을 다시 확인해. 닿나? capability 아직 맞나? 이미 도는 conflicting operation 있나? 굳은 target 에 방금 한 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 하고 승인 시 굳힘:
op.target_snapshot = ["office", "server", "laptop"]   # 아빠가 리뷰한 딱 그것
op.approved_at = "2026-07-19T09:00:00Z"

# 돌리기 직전, preflight 이 굳은 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

'이 서버들 업데이트해' 에 대한 승인을 설계해봐. 정확한 굳은 목록을 쓰고, 네 승인이랑 실행 사이에 자격이 생길 수 있는 기계를 하나 그려봐. 굳히는 게 뭘 막아주지? 그리고 굳히는 것만으론 못 잡는 걸 preflight 이 뭘 잡아?

Hint

굳히는 건 새 기계가 끼어드는 걸 막아. preflight 은 이미 승인된 기계가 서명이랑 시작 사이에 바뀐 걸 잡아. 잠들거나, SSH 를 잃거나, 다른 op 를 시작한 경우. 둘 다 필요해. 하나는 집합을 지키고, 하나는 그 안의 멤버 하나하나를 지켜.

승인은 blast radius 에 대한 동의

live selector 는 승인을 배신해

preflight 이 현실이 아직 맞는지 증명해

verify 랑 recover 는 미리 정해

Code

External links

Exercise

Progress

댓글 0