운영 조직의 가장 깊은 부채는 코드가 아니라 사람 머릿속에 있다. "프로덕션 DB를 재시작할 때는 먼저 읽기 복제본 지연을 확인하고, 백업이 끝났는지 보고, 시니어 두 명의 승인을 받고, 트래픽을 빼고, 재시작하고, 헬스체크를 통과하면 트래픽을 다시 넣는다." 이 절차는 위키 문서나 베테랑의 경험으로만 존재한다. 그 베테랑이 휴가를 가거나 퇴사하면, 같은 절차가 새벽 3시에 당직자의 떨리는 손으로 재현되고, 한 단계를 빼먹으면 사고가 난다. Runbook은 이 절차를 글로 적은 것이고, Runbook-as-Code는 그것을 실행 가능한 코드로 만든 것이다. SSM Automation은 AWS에서 이를 구현하는 도구다 — 운영 절차를 선언적 워크플로로 적고, 그 안에 AWS API 호출·스크립트·조건 분기·사람 승인을 단계로 엮는다.
오늘은 SSM Automation을 "리메디에이션 실행기"로만 보지 않고, 그 밑의 워크플로 모델을 판다. Automation Document가 어떤 워크플로 엔진 계보에 속하는지, aws:approve 같은 휴먼-인-더-루프(human-in-the-loop) 단계가 왜 자동화의 패러독스를 푸는지, Step Functions와 Automation이 어떻게 다른지, 멱등성과 출력 전달이 워크플로 엔진의 어떤 근본 문제를 다루는지를 본다