Day 3 - 관리·모니터링 도구: 시스템을 지켜보고 추적하기

시스템을 만들어 돌리기 시작하면 새로운 질문이 생긴다. "지금 서버가 느린데 CPU가 높은 건가?", "어제 누가 이 보안 설정을 바꿨지?", "우리 리소스가 회사 규칙을 잘 지키고 있나?", "서버 100대에 패치를 한 번에 깔 수 없을까?" 이 네 질문에 답하는 도구가 오늘의 주제다 — CloudWatch, CloudTrail, Config, Systems Manager.

처음에는 이름이 다 비슷해 보이지만, "무엇을 본다"가 서로 다르다. CloudWatch는 성능, CloudTrail은 누가 무엇을 했는지, Config는 설정 상태, Systems Manager는 운영 작업이다. 이 한 줄 차이를 잡는 게 오늘의 목표다.

지켜보는 도구가 없던 시절

이 서비스들이 왜 생겼는지부터 본다. 모니터링 도구가 없던 회사의 하루는 이랬다.

오전 10시, 고객센터에 전화가 온다. "사이트가 안 열려요." 그제야 개발자가 서버에 접속해 본다. 디스크가 꽉 찼는데 언제부터였는지는 모른다. 오후 2시, 보안 담당자가 묻는다. "이 DB 접근 설정, 지난주엔 이렇지 않았는데 누가 바꿨죠?" 아무도 모른다. 오후 4시, 감사팀이 요청한다. "서버 중에 암호화 안 된 게 있는지 목록을 주면 된다." 엑셀을 열고 손으로 세기 시작한다. 서버가 200대라 사흘이 걸린다.

세 상황의 공통점은 하나다 — "눈"이 없었다. 시스템은 계속 돌아가는데, 그 안에서 무슨 일이 일어나는지 밖에서 알 방법이 없었다. 그래서 장애는 늘 고객이 먼저 알려주고, 원인은 늘 사후에 추측으로 메웠다. 오늘 배우는 네 서비스는 각각 그 눈 하나씩을 달아준다.

이렇게 "시스템 밖에서 안의 상태를 알 수 있게 만드는 성질"을 관찰 가능성(Observability)이라고 부른다. 자동차로 치면 계기판이다. 계기판 없는 차도 달리기는 한다. 다만 연료가 언제 떨어질지, 엔진이 과열됐는지를 멈춘 뒤에야 알게 될 뿐이다.

Amazon CloudWatch: 성능과 상태를 지켜보는 눈

Amazon CloudWatch는 AWS 리소스와 애플리케이션의 지표(metrics), 로그(logs), 경보(alarms)를 모아 보여주는 모니터링 서비스다. EC2의 CPU 사용률, RDS의 연결 수, Lambda 실행 시간 같은 숫자를 시간에 따라 그래프로 보고, 임계값을 넘으면 알림을 보내거나 자동 조치를 취한다.

• Metrics(지표): CPU, 네트워크, 디스크 등 수치 데이터를 시계열로 수집.
• Logs(로그): 애플리케이션·시스템 로그를 한곳에 모아 검색.
• Alarms(경보): "CPU 80% 넘으면 알림" 같은 임계값 기반 경보. Auto Scaling을 트리거하기도 함.
• Dashboards(대시보드): 여러 지표를 한 화면으로.

세 요소를 병원에 비유하면

처음 보면 지표·로그·경보가 비슷해 보인다. 지표는 숫자, 로그는 문장, 경보는 그 숫자가 선을 넘었을 때 울리는 종이다. 병원 중환자실을 떠올리면 확실해진다.

경보가 울린 다음에 무슨 일이 벌어지나

CloudWatch 경보는 화면에 빨간 불이 들어오고 끝나는 게 아니라 다음 동작으로 이어진다. 시험 범위에 드는 부분이다.

[지표 수집]  EC2 CPU 사용률 = 85%
      │
      ▼
[경보 판단]  "5분 평균 CPU > 80%" 조건 충족 → 경보 상태(ALARM)
      │
      ├──► Amazon SNS ──► 이메일 / 문자 / 다른 서비스로 알림
      │
      └──► Auto Scaling ──► EC2 인스턴스를 자동으로 더 띄움

이 흐름의 의미는 크다. 예전에는 "사람이 보고 → 사람이 판단하고 → 사람이 서버를 늘리는" 3단계였다면, 이제는 새벽 3시에 트래픽이 몰려도 아무도 깨지 않고 시스템이 스스로 늘어난다. 지난주에 배운 Auto Scaling이 실제로 언제 움직이는지를 정하는 것이 바로 CloudWatch 경보다. 참고로 경보는 정상(OK), 경보(ALARM), 판단할 데이터가 부족한 상태(INSUFFICIENT_DATA)를 오간다.

어느 온라인 쇼핑몰은 평소 EC2 두 대로 충분하지만 매주 금요일 저녁 할인 시간에 접속자가 몰린다. 이 회사는 "CPU 평균이 70%를 넘으면 서버를 늘리고 30% 아래로 떨어지면 줄인다"는 경보와, "결제 오류 로그가 짧은 시간에 여러 건 쌓이면 담당자에게 문자"라는 경보를 걸어 뒀다. 그 결과 트래픽 대응은 자동으로 이뤄지고, 진짜 이상 징후만 사람에게 온다. 운영자가 밤새 그래프를 노려보던 시대가 끝나는 지점이다.

⚠️ 함정: CloudWatch가 EC2에서 기본으로 수집하는 것은 CPU 사용률·네트워크 입출력처럼 서버 바깥(하이퍼바이저)에서 보이는 값이다. 반면 메모리 사용량이나 디스크 여유 공간처럼 OS 안쪽 정보는 기본 지표에 없다 — 인스턴스 안에 CloudWatch 에이전트를 설치해야 올라온다. OS 안쪽은 공동 책임 모델상 고객의 영역이라 AWS가 임의로 들여다보지 않기 때문이다.

CloudWatch는 Well-Architected의 Operational Excellence(운영 우수성) 핵심 도구다. "관찰성(observability)" — 즉 시스템 내부 상태를 밖에서 알 수 있게 하는 능력 — 의 기반이 된다. "성능 지표", "임계값 경보", "로그 수집"이 보이면 CloudWatch다.

AWS CloudTrail: 누가, 언제, 무엇을 했는가

AWS CloudTrail은 계정 안에서 일어난 API 호출·활동 기록(감사 로그)을 남기는 서비스다. 누군가 EC2를 종료했거나, S3 버킷 정책을 바꿨거나, IAM 사용자를 만들었다면 — 누가, 언제, 어디서(IP), 무엇을 했는지가 전부 기록된다.

CloudWatch가 "시스템이 어떻게 동작하는가(성능)"를 본다면, CloudTrail은 "사람과 서비스가 무엇을 했는가(행위)"를 본다. 보안 감사, 사고 조사, 규정 준수 증빙의 핵심이다.

건물 출입기록부에 비유하기

CloudTrail을 이해하는 가장 쉬운 그림은 회사 건물 1층의 출입기록부다. 건물에 들어오려면 카드를 찍고, 그러면 "몇 시에, 누가, 어느 문으로"가 자동으로 남는다. 아무도 수첩에 적지 않아도 기록은 쌓이고, 사고가 나면 그 기록부터 본다.

AWS 계정에서 일어나는 거의 모든 동작 — EC2를 켜고, S3 버킷을 만들고, IAM 사용자를 추가하고, 보안 그룹을 여는 일 — 은 내부적으로 API 호출이라는 형태로 이뤄진다. 콘솔에서 마우스로 버튼을 눌러도 결국 뒤에서는 API가 호출된다. CloudTrail은 그 API 호출을 자동으로 기록한다. 즉 "카드 리더기를 계정 전체에 달아 둔 것"이다. 기록에는 누가(사용자·역할), 언제, 무엇을(어떤 동작), 어디서(요청 IP), 어떤 대상에 했는지가 남는다. 최근 활동은 콘솔에서 바로 조회할 수 있고, 장기 보관이 필요하면 기록을 S3 버킷에 쌓아 두도록 설정한다(감사 목적이라면 사실상 필수다).

어느 스타트업에서 금요일 밤에 운영 데이터베이스 한 대가 사라졌다. 월요일 아침, 팀은 서로를 의심하는 대신 CloudTrail 기록을 열었다. 특정 IAM 사용자의 액세스 키로 삭제 동작이 호출됐고, 요청 IP는 회사와 무관한 해외 주소였다. 그 개발자가 몇 달 전 공개 저장소에 실수로 키를 커밋한 적이 있었던 것이다. 원인 규명에 30분이 걸렸다. 기록이 없었다면 "누가 실수했겠지"로 끝나고 유출된 키는 계속 살아 있었을 것이다.

⚠️ 함정: CloudTrail은 "성능이 왜 느린가"에 답하지 못하고, CloudWatch는 "누가 이걸 지웠나"에 답하지 못한다. "장애 원인 조사"라는 말만 보고 반사적으로 CloudTrail을 고르면 안 된다. 조사 대상이 사람의 행위면 CloudTrail, 시스템의 상태·성능이면 CloudWatch다. 문장에 "누가(who)"가 있으면 CloudTrail 쪽으로 기운다고 기억한다.

"누가 이 작업을 했는지 추적", "감사(audit)", "보안 사고 조사", "규정 준수 증빙"이 보이면 CloudTrail. CloudWatch(성능)와 헷갈리지 않도록 "성능 vs 행위 기록"으로 구분하면 된다.

AWS Config: 설정이 규칙을 지키는가

AWS Config는 리소스의 설정(configuration) 상태를 기록하고, 정해진 규칙을 지키는지 평가하는 서비스다. 예를 들어 "모든 S3 버킷은 암호화되어야 한다", "보안 그룹에 0.0.0.0/0으로 SSH를 열면 안 된다" 같은 규칙을 만들고, 위반하는 리소스를 자동으로 찾아낸다.

또한 리소스 설정이 시간에 따라 어떻게 바뀌었는지 이력(history)을 남긴다. "이 보안 그룹이 일주일 전엔 어떤 상태였지?"를 되돌아볼 수 있다.

아파트 소방점검에 비유하기

Config를 이해하려면 아파트 정기 소방점검을 떠올리면 된다. 점검원은 각 세대를 돌며 체크리스트를 든다. "소화기가 있는가", "감지기가 작동하는가", "비상구가 막혀 있지 않은가". 그리고 위반 세대 목록을 만들고, 다음 점검 때 고쳐졌는지 확인한다.

AWS Config가 하는 일이 딱 이것이다. 점검 항목(규칙)을 정해 두면, 리소스가 늘어나거나 바뀔 때마다 자동으로 다시 점검한다. 사람이 매번 200대를 세지 않아도 된다.

여기에 하나가 더 붙는다 — 시간 축이다. Config는 설정이 언제 어떻게 바뀌어 왔는지를 타임라인으로 보여주므로 "지난주 화요일 시점의 이 보안 그룹은 어떤 상태였지?"에도 답할 수 있다.

CloudTrail : "누가 변경했나"                        (행위 / 누구)
AWS Config : "지금 설정이 규칙에 맞나, 어떻게 바뀌어 왔나"  (상태 / 적합성)

둘은 경쟁 관계가 아니라 짝이다. 보안 사고를 조사할 때 Config로 "언제부터 설정이 잘못돼 있었는지"를 좁히고, CloudTrail로 "그 시각에 누가 바꿨는지"를 찾는다. 규제 산업에서 Config가 사랑받는 이유도 여기 있다. "지난 1년간 데이터 저장소가 항상 암호화 상태였음"을 감사에서 증명해야 할 때, 스크린샷을 모으는 대신 설정 이력을 그대로 제출하면 되기 때문이다.

함정: Config는 규칙 위반을 찾아서 알려주는 도구이지, "위반이 생기지 않도록 처음부터 막는" 도구가 아니다. 사전에 금지하는 역할은 IAM 정책이나 조직 차원의 서비스 제어 정책(SCP) 쪽이다. 시험에서 "탐지·평가·보고"면 Config, "애초에 권한을 못 쓰게 차단"이면 IAM/SCP 방향으로 갈린다.

"설정 규정 준수(compliance) 확인", "리소스 설정 이력", "규칙 위반 탐지"가 보이면 Config다. CloudTrail("누가 했나")과 묶여 보안·거버넌스를 이루지만, Config는 결과 상태가 규칙에 맞느냐에 초점이 있다는 점이 다르다.

AWS Systems Manager: 운영 작업을 한곳에서

AWS Systems Manager(SSM)는 EC2 인스턴스와 온프레미스 서버를 대규모로 운영·관리하는 도구 모음이다. 서버 한 대 한 대 SSH로 들어가지 않고, 중앙에서 명령을 내리고 설정을 관리할 수 있다.

주요 기능 몇 가지:

• Patch Manager: 수많은 서버에 OS 패치를 일괄 적용.
• Session Manager: SSH 키나 열린 포트 없이 안전하게 서버 셸 접속(감사 로그 포함).
• Parameter Store: 설정값·비밀번호·DB 연결 문자열 등을 안전하게 저장·공유.
• Run Command: 여러 서버에 명령을 한 번에 실행.

서버 200대를 손으로 다루면 생기는 일

서버가 3대일 때는 SSH로 하나씩 들어가 명령을 치면 된다. 10분이면 끝난다. 그런데 200대가 되면 이야기가 달라진다. 200번 접속해야 하고 몇 대를 빠뜨렸는지 확인할 방법이 없다. 접속하려면 22번 포트를 열어 둬야 하고 SSH 키를 누군가 관리해야 한다. 키가 유출되면 그대로 침입 경로가 되고, 퇴사자가 생기면 200대에서 그 사람의 키를 지워야 한다. 게다가 누가 어느 서버에서 무슨 명령을 쳤는지는 아무 데도 안 남는다.

Systems Manager는 이 상황을 "서버로 들어가는" 방식에서 "중앙에서 내려보내는" 방식으로 뒤집는다. 관리자는 서버에 직접 접속하는 대신 콘솔에서 대상 그룹을 고르고 작업을 지시한다.

특히 Session Manager는 접속용으로 열어야 했던 22번 포트를 아예 닫아 버릴 수 있게 한다. "보안 장치를 더 추가"한 게 아니라 공격 표면 자체를 없앤 접근이라는 점이 핵심이다. Parameter Store는 DB 주소나 API 키 같은 설정값을 코드 바깥에 두는 곳으로, 코드에 비밀번호를 적어 두는 위험을 없애고 값을 바꿔도 재배포가 필요 없게 해준다.

"여러 서버 일괄 패치", "SSH 키 없이 안전 접속", "설정값/시크릿 중앙 저장", "운영 자동화"가 보이면 Systems Manager. 특히 Session Manager는 22번 포트를 열지 않고도 접속하므로 보안(Security 기둥)에서 자주 언급된다.

함께 알아 둘 두 가지: Trusted Advisor와 Health Dashboard

시험에 가볍게 얼굴을 내미는 도구가 둘 더 있다. 한 줄씩만 잡아 둔다.

AWS Trusted Advisor는 내 계정을 훑어보고 "이렇게 하면 더 좋아진다"고 조언해 주는 자동 점검 도구다. 비용을 낭비하는 유휴 리소스, 위험하게 열린 보안 설정, 가용성이 취약한 구성 같은 것을 찾아 알려준다. 건강검진 결과지에 가깝다(지원 플랜 등급에 따라 확인 가능한 점검 항목 범위가 달라진다).

AWS Health Dashboard는 AWS 쪽 상태를 알려주는 창구다. 특정 리전 서비스에 장애가 있는지 같은 전체 상황과, 내 리소스에 영향을 주는 예정된 이벤트(예: 하드웨어 점검에 따른 인스턴스 재시작 예정)를 보여준다.

함정: "우리 서비스가 안 된다"는 상황에서 Health Dashboard와 CloudWatch를 헷갈리지 않아야 한다. AWS 쪽 장애인지 확인하려면 Health Dashboard, 내 애플리케이션과 리소스 상태를 보려면 CloudWatch다. 그리고 Trusted Advisor는 실시간 감시 도구가 아니라 개선 권고 도구다.

네 도구를 한 장으로 구분하기

CLF 시험은 이 네 가지를 자주 섞어서 헷갈리게 낸다. 가장 빠른 구분법은 "무엇을 본다/한다"다. 성능을 보면 CloudWatch, 행위를 보면 CloudTrail, 설정 적합성을 보면 Config, 운영 작업을 하면 Systems Manager.

한 줄로 외우는 구분법

성능은?      → CloudWatch   (계기판)
누가 했나?   → CloudTrail   (출입기록부)
규칙 맞나?   → Config       (점검표)

"어제 저녁 웹사이트가 30분간 느렸다"는 한 사건을 CloudWatch는 "CPU가 95%로 치솟았다"고, CloudTrail은 "그 직전에 누군가 Auto Scaling 최대 대수를 낮췄다"고, Config는 "그 설정이 회사 표준을 위반했다"고 설명한다. 증상은 CloudWatch, 범인은 CloudTrail, 규칙은 Config. 고르기 막히면 "묻는 게 증상인가, 범인인가, 규칙인가"를 자문하면 된다.

용어 정리표

시험에 이렇게 나온다

이 영역은 대부분 "이런 상황이면 어떤 서비스?" 형태로 나온다. 아래 표현이 보이면 오른쪽이 답일 확률이 높다.

시험은 세부 기능을 깊게 묻지 않는다. "이 서비스는 무엇을 위해 존재하는가" 한 줄만 정확하면 대부분 맞힐 수 있다.

정리

오늘은 시스템을 지켜보고 관리하는 네 가지 도구를 봤다. CloudWatch(성능 모니터링), CloudTrail(행위 감사), Config(설정 규정 준수), Systems Manager(대규모 운영). 이들은 따로가 아니라 함께 쓰인다 — CloudWatch로 이상 징후를 잡고, CloudTrail로 원인 행위를 추적하고, Config로 규칙 위반을 찾고, Systems Manager로 수정을 일괄 적용하는 식이다.

크게 보면 오늘 배운 것은 "운영을 사람의 성실함이 아니라 시스템의 구조에 맡기는 방법"이다. 장애를 고객이 알려주기 전에 경보가 울리고, 변경 기록이 저절로 남고, 규칙 위반이 자동으로 드러난다. AWS Well-Architected가 말하는 운영 우수성(Operational Excellence)이 실제로는 이런 모습이다.

스스로 확인해 본다. CloudWatch의 세 요소는 각각 무엇을 담는가? 경보가 울린 뒤 이어질 수 있는 동작 두 가지는? CloudTrail이 답하는 질문을 한 단어로 말하면? Config가 CloudTrail과 다른 점은? SSH 키 없이 서버에 접속하게 해주는 기능의 이름은? 여기에 한 줄씩 답할 수 있으면 오늘 분량은 충분하다.

다음 글에서는 이런 인프라를 코드로 자동 생성·배포하는 방법 — CloudFormation, Elastic Beanstalk, 그리고 컨테이너·서버리스 — 을 본다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

EC2 인스턴스의 CPU 사용률을 시계열로 추적하고, 80%를 넘으면 알림을 보내려 한다. 가장 적합한 서비스는?

• AAWS CloudTrail
• BAmazon CloudWatch
• CAWS Config
• DAWS Systems Manager

문제 2

보안 조사를 위해 "누가, 언제, 어떤 IP에서 S3 버킷 정책을 변경했는지"를 확인해야 한다. 가장 적합한 서비스는?

• AAmazon CloudWatch
• BAWS Config
• CAWS CloudTrail
• DAmazon SNS

문제 3

"모든 S3 버킷은 암호화되어야 한다"는 회사 규칙을 위반하는 리소스를 자동으로 탐지하고 설정 이력을 추적하려 한다. 가장 적합한 서비스는?

• AAWS Config
• BAmazon CloudWatch
• CAWS Systems Manager
• DAmazon SQS

문제 4

수백 대의 EC2 인스턴스에 SSH 키나 열린 포트 없이 OS 패치를 일괄 적용하려 한다. 가장 적합한 서비스는?

• AAmazon CloudWatch
• BAWS CloudTrail
• CAWS Systems Manager
• DAWS Config

문제 5

CloudWatch와 CloudTrail의 역할 차이로 가장 정확한 설명은?

• ACloudWatch는 API 행위를 기록하고, CloudTrail은 성능을 모니터링한다
• BCloudWatch는 성능 지표·로그·경보, CloudTrail은 누가 무엇을 했는지의 활동 기록이다
• C둘 다 설정 규정 준수만 평가한다
• D둘 다 서버 패치를 자동화한다