EC2 한 대를 관리하는 일은 쉽다. SSH로 들어가서 명령을 치면 된다. 그런데 그 한 대가 열 대가 되고, 백 대가 되고, 수천 대가 되는 순간 모든 게 무너진다. 키를 어떻게 배포하고 회전할 것인가, 누가 언제 어떤 명령을 쳤는지 어떻게 감사할 것인가, 22번 포트를 인터넷에 열어두는 게 맞는가, 패치를 어떻게 동시에 안전하게 적용할 것인가. AWS Systems Manager(SSM)는 이 "fleet 규모 운영"이라는 문제를 정면으로 다루기 위해 만들어진 도구 묶음이다. 이름이 하나지만 실제로는 Run Command, Session Manager, Patch Manager, State Manager, Inventory, Automation 같은 십여 개의 독립 기능이 한 우산 아래 모여 있다.
오늘은 이 우산 밑에서 가장 자주 쓰이는 세 가지 — 원격 명령 실행(Run Command), 셸 접속(Session Manager), 패치 자동화(Patch Manager) — 를 본다. 단순히 "이런 기능이 있다"가 아니라, 왜 SSH를 버리고 SSM Agent라는 풀(pull) 모델로 갔는지, Session Manager가 어떻게 포트 하나 열지 않고 셸을 띄우는지, Patch Baseline의 승인 지연(approve-after-days)이라는 숫자 하나에 어떤 운영 철학이 담겨 있는지를 파고든다