수백 대의 서버를 관리하는 일을 상상해보세요. 각 서버에 일일이 접속해서 보안 패치를 적용하고, 소프트웨어를 설치하고, 상태를 점검하는 것은 사실상 불가능합니다. AWS Systems Manager(SSM)는 이 문제를 해결하는 중앙 집중식 관리 도구입니다.
Systems Manager란 무엇인가요?
Systems Manager는 대형 아파트 단지의 건물 관리 시스템과 같습니다. 관리자가 각 세대(서버)에 직접 찾아가지 않고도 중앙 관제실에서 모든 세대의 상태를 파악하고, 문제가 생기면 원격으로 조치할 수 있습니다.
Systems Manager를 사용하려면 두 가지 전제 조건이 있습니다. 첫째, 관리하려는 EC2 인스턴스에 SSM Agent가 설치되어 있어야 합니다. Amazon Linux 2, Windows Server 등 AWS에서 제공하는 대부분의 공식 AMI에는 기본으로 설치되어 있습니다. 직접 만든 커스텀 AMI는 수동 설치가 필요합니다. 둘째, EC2 인스턴스에 적절한 IAM 역할이 필요합니다. AmazonSSMManagedInstanceCore 정책이 포함된 역할을 인스턴스에 연결해야 합니다.
이 두 가지가 없으면 Systems Manager의 어떤 기능도 동작하지 않습니다.
Patch Manager — 보안 패치 자동화
온라인 쇼핑몰을 운영하는데, 보안팀에서 "이번 주 금요일 밤 12시까지 모든 서버에 최신 보안 패치를 적용하세요"라는 지시를 받았습니다. 서버가 200대라면 어떻게 할까요? Patch Manager가 이 상황을 해결합니다.
Patch Manager는 패치 기준선(Patch Baseline)이라는 규칙을 만드는 것부터 시작합니다. "어떤 패치를 자동으로 승인할 것인가"를 정의하는 문서입니다. AWS가 제공하는 기본 기준선은 보안 패치를 자동으로 7일 후에 승인합니다. 직접 기준선을 만들어서 특정 패치를 즉시 승인하거나 특정 패치를 영구적으로 거부할 수도 있습니다.
패치 기준선이 준비되었으면, 언제 적용할지를 정해야 합니다. 이것이 유지 관리 기간(Maintenance Window)입니다. "매주 일요일 새벽 2시부터 4시까지"처럼 서비스 영향이 적은 시간대를 지정합니다. 이 시간에 Patch Manager가 자동으로 해당 서버들에 패치를 적용합니다.
시험 핵심: "업무 시간 외에 자동으로 EC2에 보안 패치를 적용하려면?" 하면 Patch Manager + Maintenance Window가 정답입니다.
Run Command — SSH 없이 원격 명령 실행
서버 200대에 새로운 설정 파일을 배포해야 합니다. 전통적인 방법은 각 서버에 SSH로 접속해서 명령을 실행하는 것입니다. SSH 키를 관리하고, 보안 그룹에 22번 포트를 열고, 200번 반복합니다. 불편하고 보안 위험도 있습니다.
Run Command는 이 모든 과정을 없애줍니다. AWS 콘솔이나 CLI에서 명령을 한 번 입력하면, 태그나 인스턴스 ID로 선택한 수백 대의 서버에 동시에 실행됩니다.
Run Command의 특징을 살펴봅시다. SSH 키가 전혀 필요 없습니다. 보안 그룹에 22번 포트(SSH)를 열 필요도 없습니다. 서버에 태그(예: Environment=Production, Role=WebServer)를 붙여두면 "Production 환경의 WebServer 역할을 가진 모든 인스턴스에 명령 실행"처럼 대상을 지정할 수 있습니다. 명령 실행 결과는 S3 버킷이나 CloudWatch Logs에 자동으로 저장됩니다. Rate Control 기능으로 한 번에 몇 대씩 실행할지, 실패가 몇 개 이상이면 중단할지도 설정할 수 있습니다.
시험 핵심: "SSH 없이 수백 대 EC2에 동시에 스크립트나 명령을 실행하려면?" 하면 Run Command가 정답입니다.
Session Manager — 안전한 서버 접속
개발팀에서 "운영 서버에 접속해서 로그를 확인해야 한다"고 합니다. 전통적으로는 SSH 키를 발급하거나 배스천(Bastion) 호스트를 경유해서 접속합니다. Session Manager는 이 모든 과정을 간소화합니다.
Session Manager는 SSH, RDP, 배스천 호스트, 보안 그룹 인바운드 규칙이 전혀 없어도 EC2 인스턴스에 접속할 수 있게 합니다. AWS 콘솔에서 "Connect" 버튼 한 번으로 브라우저 기반 터미널이 열립니다. AWS CLI로도 접속할 수 있습니다.
보안 측면에서 Session Manager는 매우 강력합니다. 모든 접속 세션이 AWS CloudTrail에 자동으로 기록됩니다. "누가, 언제, 어떤 서버에 접속했는가"를 항상 추적할 수 있습니다. 원하면 세션 중에 입력한 명령과 출력 내용 전체를 S3나 CloudWatch Logs에 저장할 수도 있습니다.
IAM 정책으로 접근을 세밀하게 제어할 수 있습니다. 특정 인스턴스에만 접속을 허용하거나, 특정 시간대에만 허용하는 등의 조건을 설정할 수 있습니다.
시험 핵심: "보안팀이 서버 접속 내역을 감사해야 한다" 또는 "SSH 없이 EC2에 접속하려면?" 하면 Session Manager가 정답입니다.
State Manager — 원하는 상태 유지하기
서버가 부팅될 때마다 자동으로 특정 에이전트가 실행되어야 한다고 가정해봅시다. 그런데 누군가 실수로 그 에이전트를 중지시키거나, 잘못된 설정 파일을 배포하면 어떻게 될까요? State Manager는 이런 상황을 방지합니다.
State Manager는 인스턴스가 "원하는 상태(Desired State)"를 항상 유지하도록 합니다. 연결(Association)이라는 설정을 만들어서 "이 인스턴스들은 항상 이런 상태여야 한다"고 정의합니다. State Manager는 정기적으로 상태를 확인하고, 원하는 상태에서 벗어났으면 자동으로 복구합니다.
예를 들면 이런 식입니다. "모든 EC2 인스턴스에 CloudWatch 에이전트가 항상 설치되고 실행 중이어야 한다." 이 Association을 만들어두면, 에이전트가 중지되거나 제거되더라도 State Manager가 자동으로 다시 설치하고 시작합니다.
Automation — 자동 복구 Runbook 만들기
새벽 3시에 운영 서버의 CPU 사용률이 100%로 치솟았습니다. 담당자가 잠에서 깨어나 서버에 접속해서 문제를 파악하고 재시작하는 데 30분이 걸렸습니다. Automation을 사용하면 이 과정을 사람 없이 자동으로 처리할 수 있습니다.
Automation은 여러 단계를 조합한 자동화 작업(Runbook)을 만드는 기능입니다. AWS가 이미 만들어둔 Runbook도 있습니다. EC2 인스턴스 재시작, AMI 생성, EBS 스냅샷 생성 등 자주 사용하는 작업들이 준비되어 있습니다.
직접 Runbook을 만들 수도 있습니다. 예를 들어 "CPU 사용률 경보 → 인스턴스 메모리 사용량 확인 → 상위 프로세스 목록 S3에 저장 → 인스턴스 재시작 → 재시작 완료 알림 전송"처럼 여러 단계를 묶어서 자동화합니다.
중요한 운영 작업에는 승인 단계를 넣을 수 있습니다. "데이터베이스를 재시작하기 전에 운영팀장의 승인을 받아야 한다"는 단계를 포함할 수 있어서, 완전 자동화와 인간 확인을 적절히 조합할 수 있습니다.
CloudWatch Alarm이나 EventBridge와 연동하면 특정 이벤트 발생 시 자동으로 Runbook이 실행됩니다.
시험 핵심: "CloudWatch 경보 발생 시 자동으로 EC2를 재시작하려면?" 하면 Automation Runbook + CloudWatch Alarm이 정답입니다.
!Systems Manager 핵심 기능 4가지
Parameter Store — 설정값과 비밀번호 안전하게 저장하기
애플리케이션이 데이터베이스에 접속하려면 데이터베이스 주소, 사용자 이름, 비밀번호가 필요합니다. 이 값들을 코드 안에 직접 넣으면 보안 사고로 이어질 수 있습니다. Parameter Store는 이런 값들을 안전하게 저장하고 관리하는 서비스입니다.
Parameter Store에는 세 가지 유형이 있습니다.
String은 일반 텍스트로 저장합니다. 데이터베이스 호스트 주소나 API 엔드포인트처럼 민감하지 않은 설정값에 사용합니다.
StringList는 쉼표로 구분된 값 목록입니다. 허용 IP 주소 목록처럼 여러 값을 한꺼번에 저장할 때 사용합니다.
SecureString은 KMS 키로 암호화해서 저장합니다. 데이터베이스 비밀번호, API 키, 인증서처럼 민감한 정보에 사용합니다.
계층 구조로 정리할 수 있어서 /myapp/prod/db/password처럼 경로를 만들면 환경별로 값을 깔끔하게 관리할 수 있습니다. 변경 이력도 자동으로 추적합니다.
Secrets Manager와 자주 비교됩니다. Parameter Store Standard 티어는 무료이고, Secrets Manager는 유료지만 자동 로테이션 기능을 제공합니다. "비용 없이 암호화된 설정값을 저장하려면?" 하면 Parameter Store SecureString, "데이터베이스 비밀번호를 자동으로 주기적으로 교체하려면?" 하면 Secrets Manager입니다.
시험 핵심: "비용 없이 설정값을 암호화해서 저장하려면?" 하면 Parameter Store SecureString이 정답입니다.
EC2 Image Builder — 골든 AMI 자동 생성
회사에서 사용하는 표준 서버 이미지가 있다고 해봅시다. 보안 설정, 필수 소프트웨어, 회사 정책이 모두 적용된 이미지입니다. 이것을 "골든 AMI"라고 합니다. EC2 Image Builder는 이 골든 AMI를 자동으로 만들고 업데이트하는 파이프라인입니다.
파이프라인은 이렇게 동작합니다. 베이스 이미지(AWS 공식 Amazon Linux 등)를 선택합니다. 설치할 소프트웨어와 적용할 설정을 정의합니다. 테스트 단계에서 이미지가 올바르게 만들어졌는지 확인합니다. 테스트를 통과하면 여러 리전에 배포합니다.
보안 패치가 나올 때마다 새 골든 AMI를 자동으로 만들도록 스케줄을 설정할 수도 있습니다.
Inventory — 소프트웨어 목록 파악하기
100대의 서버에 어떤 소프트웨어가 설치되어 있는지, 어떤 버전인지 파악해야 한다면? Systems Manager Inventory가 이 정보를 자동으로 수집합니다.
각 인스턴스에 설치된 소프트웨어 목록, 네트워크 설정, Windows 업데이트 상태, 실행 중인 서비스 등의 정보를 중앙에서 한눈에 볼 수 있습니다. 특정 버전의 소프트웨어가 설치된 서버를 빠르게 찾거나, 라이선스 관리를 위한 설치 현황을 파악하는 데 유용합니다.
시험 핵심 정리
"SSH 없이 수백 대 서버에 동시에 명령 실행" -- Run Command