새벽 3시, 사용자들이 "느리다"고 항의하는데 대시보드는 평온합니다. 알고 보니 알림이 50개나 걸려 있어 다들 무시하던 와중에 진짜 신호가 묻혔습니다. 며칠 뒤엔 누군가 운영 계정에서 보안그룹을 열었는데 "누가 했는지" 기록이 없습니다. 보이지 않으면 고칠 수 없고, 통제하지 않으면 누구나 사고를 낼 수 있습니다. 관측과 거버넌스는 클라우드 운영의 안전망입니다.
- 1지표·로그·추적이 각각 무엇을 보여주는지 구분할 수 있다
- 2실행 가능한 알림을 적게 거는 원칙을 안다
- 3멀티계정과 가드레일로 사고 범위를 제한하는 법을 이해한다
- 4감사 추적의 역할과 보호 필요성을 안다
- 5이 트랙의 조각들이 하나의 운영 체계로 이어짐을 본다
보기 — 관측의 세 신호
지표·로그·추적 — 함께 봐야 원인까지
- 지표(metric): CPU·요청수·지연·에러율 같은 수치 추세. '이상이 있다'를 빠르게 감지. 알림의 근거.
- 로그(log): 그 시점의 상세 이벤트. '무슨 일이 있었나'.
- 추적(trace): 한 요청이 여러 서비스를 거친 경로·구간별 지연. '어디서 느렸나'(특히 MSA 모놀리식 vs 마이크로서비스).
지표로 알아채고, 로그·추적으로 원인을 좁힙니다. 클라우드는 CloudWatch(지표·로그) 등으로 이를 기본 제공하고, 표준 도구(Prometheus/Grafana)도 연동됩니다(Kubernetes 트랙의 관측과 동일 철학).
알림은 적게, 실행 가능하게
"모든 지표에 알림"은 곧 알림 피로로 이어져 진짜 장애를 놓치게 합니다. 좋은 알림은:
- 증상 중심: 사용자 영향이 있는 것(에러율↑, 지연↑, 가용성↓)에 페이징
- 원인 지표는 대시보드로: CPU 70% 같은 건 알림 말고 차트로
- 실행 가능: 받으면 '무엇을 할지' 분명한 것만
이는 SLO·에러버짓·포스트모템의 'SLO 위반 시 알림' 원칙과 직접 연결됩니다.
통제 — 멀티계정과 가드레일
계정으로 격리하고, 중앙에서 강제한다
조직이 커지면 단일 계정에 모든 걸 넣는 건 위험합니다. 한 실수가 전체로 번지고(blast radius), 권한 분리가 어렵습니다.
멀티계정은 운영/개발/결제 등을 별도 계정으로 격리해 사고 범위를 제한합니다. 동시에 중앙(조직)에서 가드레일(SCP 등) 로 정책을 모든 계정에 일괄 강제합니다:
- 허용되지 않은 리전 사용 금지(데이터 주권 IaaS·PaaS·SaaS와 리전·AZ)
- 퍼블릭 S3 버킷 생성 금지(오브젝트·블록·파일 스토리지)
- 루트 액세스 키 생성 금지(계정과 IAM)
- 필수 태그 없으면 생성 차단(클라우드 비용 최적화)
개별 계정의 실수를 사전에 막는 안전망입니다.
감사 추적 — 누가 무엇을 바꿨나
감사 추적(CloudTrail 등) 은 '누가 언제 어떤 API로 무엇을 바꿨는지'를 기록합니다. 침해 조사, 변경 추적, 컴플라이언스에 필수입니다. 단, 이 로그가 지워지거나 변조되면 무용지물이므로 별도 계정·쓰기방지(불변) 스토리지에 보관해 보호합니다.
어떤 경보가 어떤 상태인지 봅니다. 너무 많거나 항상 ALARM/INSUFFICIENT면 손봐야 합니다.
aws cloudwatch describe-alarms \
--query "MetricAlarms[].{Name:AlarmName,Metric:MetricName,State:StateValue}" --output table
+---------------------------+------------------+--------+
| api-5xx-rate-high | 5xxErrorRate | OK |
| api-latency-p99-high | TargetResponse | ALARM | ← 사용자 영향
| cpu-70 (원인지표) | CPUUtilization | OK | ← 대시보드로 충분
+---------------------------+------------------+--------+
aws cloudwatch describe-alarms보안그룹 변경 같은 민감 작업을 누가 했는지 확인합니다.
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress \
--max-results 3 --query "Events[].{Time:EventTime,User:Username,Event:EventName}"
[ { "Time": "2026-06-15T18:02Z", "User": "dev-kim", "Event": "AuthorizeSecurityGroupIngress" } ]
aws cloudtrail lookup-events- describe-alarms에 경보가 수십 개·항상 ALARM/INSUFFICIENT — 알림 피로 신호. 증상 중심으로 정리하고 원인 지표는 대시보드로
- 사용자 영향 증상(5xx·p99 지연·가용성)에 페이징 경보가 걸려 있는지 — 없으면 진짜 장애를 못 받음
- CloudTrail이 모든 리전·계정에서 켜져 있고 별도 보호 스토리지에 보관되는지 — 꺼져 있거나 변조 가능하면 사고 조사 불가
- 가드레일(SCP) 적용 여부 — 퍼블릭 차단·리전 제한·루트키 금지가 조직 차원에서 강제되는지
상황: 알림이 신호 역할을 못 함(과소 또는 과다).
원인: ① 사용자 영향 증상이 아니라 원인 지표(CPU 등)에만 알림을 걸어 진짜 장애를 못 잡음, ② 모든 것에 알림을 걸어 피로 누적→무시, ③ 알림 라우팅(누구에게·어떤 채널)이 미설정.
진단: 경보 목록을 '증상 vs 원인'으로 분류 → 최근 장애 때 어떤 알림이 울렸는지 회고(retro 관점) → 알림 수신·라우팅 확인.
해결: 페이징은 사용자 영향 증상(SLO 위반 SLO·에러버짓·포스트모템)에만, 원인 지표는 대시보드로. 알림마다 '대응 절차(runbook)'를 연결해 실행 가능하게. 정기적으로 알림을 솎아내(노이즈 제거) 신호 대비 잡음을 낮춥니다.
관측·거버넌스는 'SRE 성숙도'를 가르는 지점입니다. 면접에서 "장애를 어떻게 감지·대응하나요?"에 "지표로 SLO 기반 알림, 로그·추적으로 원인 좁히고, 사후 회고로 재발 방지"라 답하면 탄탄합니다. "모든 것에 알림 건다"는 오히려 미성숙 신호입니다.
거버넌스는 조직이 커질수록 중요해집니다. "보안을 어떻게 강제하나요?"에 "멀티계정으로 격리하고 SCP 가드레일로 퍼블릭 차단·리전 제한을 일괄 강제, CloudTrail로 감사"면 좋은 답입니다.
이 트랙을 마치며: 왜 클라우드인가에서 '왜 클라우드인가'로 시작해 IAM·VPC·컴퓨트·스토리지·서버리스·컨테이너·IaC·비용을 거쳐 여기 관측·거버넌스에 닿았습니다. 이 조각들은 따로가 아니라 하나의 운영 체계입니다 — 코드로 선언하고(IaC와 Terraform), 안전하게 배포하고(오토스케일링 + 로드밸런서), 비용을 보고(클라우드 비용 최적화), 관측·통제하는. 더 깊은 컨테이너 오케스트레이션은 Kubernetes, 네트워크 트러블슈팅은 Networking 트랙으로 이어집니다.
이 트랙의 마지막 모듈입니다. 클라우드 위에서 인프라를 설계·운영·통제하는 큰 그림을 갖추셨습니다. 다음은 실제 손을 움직이는 Kubernetes·인프라 운영 트랙에서 깊이를 더해 보세요.