SOA-C03 01/16 — 운영 신호와 증거 원천

이 구간은 Domain 1의 세부 도구를 외우기 전에, 운영 질문을 올바른 증거 종류와 AWS 서비스에 연결하는 기준을 만든다. 이 자료가 제공됐다는 사실은 학습이나 숙달의 증거가 아니다.

0. 이미 딴 자격을 반영한 출발점

AWS Cloud Practitioner, AI Practitioner, SAA-C03 합격과 이전 SOA-C03 응시가 있으므로 이 과정은 AWS 서비스가 무엇인가부터 시작하지 않는다. SAA에서 다룬 EC2·VPC·RDS·S3·IAM·가용성·확장·이벤트 관계는 공통 배경으로 짧게 재활성화한다.

이번 과정이 추가할 핵심 질문은 다음과 같다.

SAA: 요구사항을 만족하려면 무엇을 설계·선택하는가?
SOA: 이미 운영 중인 시스템에서 무엇을 관찰하고,
     어느 증거로 원인을 좁히며,
     어떤 조치를 실행한 뒤 무엇으로 회복을 검증하는가?

자격 취득과 자료 제공 이력은 이전 노출을 보여 주지만 기억·숙달을 보증하지 않는다. 따라서 공통 개념은 장황하게 반복하지 않고, 실제 운영 판단에 필요할 때 짧게 복원한다.

1. 운영 증거의 역할 복원

증거	한 줄 역할	대표 AWS 제어면
Metric	시간에 따른 수치의 크기·추세·분포를 본다.	CloudWatch Metrics
Log	특정 시점의 활동 내용과 실행 맥락을 본다.	CloudWatch Logs
Trace	한 요청이 통과한 downstream 경로와 구간별 시간을 본다.	X-Ray
Event	상태 변화나 사실을 pattern과 맞춰 target으로 전달한다.	EventBridge
Account activity	누가 또는 무엇이 어떤 API 활동을 했는지 본다.	CloudTrail
Resource configuration	리소스 속성·관계가 전후로 어떻게 달라졌는지 본다.	AWS Config

목적은 정의 암기가 아니라, 장애를 만났을 때 어느 화면을 먼저 열어야 하는가를 질문의 형태에서 결정하는 것이다.

2. 증거를 고르는 판단 축

운영 질문	우선 증거	대표 서비스	보이는 것
영향이 언제 시작됐고 규모가 얼마나 큰가?	수치의 시계열	CloudWatch Metrics	추세, 임계값, 분포, 상관 시점
오류에 어떤 메시지와 요청 맥락이 남았는가?	상세 활동 레코드	CloudWatch Logs	예외, 상태 코드, application context
요청이 어느 downstream 구간에서 지연됐는가?	요청 경로	X-Ray	segment·subsegment별 latency와 error
어떤 상태 변화에 운영 절차를 연결할 것인가?	구조화된 event	EventBridge	source → rule → target 라우팅
누가 어떤 API 작업을 실행했는가?	계정 활동 기록	CloudTrail	actor, action, resource, time
리소스 설정이 전후에 어떻게 달라졌는가?	구성 시점·이력	AWS Config	attribute·relationship·compliance 변화

서비스 이름보다 질문의 형태를 먼저 고른다. 한 incident에는 여러 질문이 있으므로 하나의 서비스가 모든 증거를 소유할 필요가 없다. Metric이 증상을 발견하고, log·trace가 실행 맥락과 경로를 좁히고, CloudTrail·Config가 직전 변경을 설명하며, EventBridge가 이후 알림이나 remediation을 연결할 수 있다.

3. 수집 경계가 먼저다

관측 화면에 값이 없을 때는 시스템이 정상이라고 결론 내리기 전에 그 신호가 생성·수집·전송되도록 구성됐는지를 확인한다.

AWS service가 기본으로 내보내는 metric은 해당 service의 관리 경계에서 관측한 값이다.
EC2 guest OS 안의 memory·disk 사용량, 애플리케이션 log와 custom metric은 CloudWatch agent 같은 수집기를 구성해 보낼 수 있다.
CloudWatch agent는 EC2, on-premises server, containerized application에서 metrics·logs·traces를 수집할 수 있다. 수집된 추가 metric은 custom metric 과금 경계를 가진다.
같은 이름의 수치라도 namespace와 dimension이 다르면 다른 관측 대상이다. Alarm의 period는 metric resolution과 맞아야 한다.
account와 Region 범위를 맞추지 않으면 실제 신호가 있어도 현재 화면·query·dashboard에서는 보이지 않을 수 있다.

따라서 첫 질문은 값이 0인가?보다 이 신호를 누가, 어디에서, 어떤 주기로 만들고 있는가?다.

4. 운영 관계: 관측에서 개입까지

workload·AWS control plane
→ metric·log·trace·event·activity·configuration 생성
→ 수집·보존 범위 설정
→ 시간·리소스·계정·Region 축 정렬
→ 증상과 직전 변경의 관계를 가설로 구성
→ alarm·rule·notification·runbook으로 개입
→ 같은 신호와 별도 안전성 지표로 결과 검증

여기서 동시에 일어났다는 사실은 원인 확정이 아니다. 예를 들어 배포 직후 지연이 증가했다면 배포는 유력한 변경 맥락이다. trace와 log에서 실제 지연 경로가 맞고, 구성 이력에서 관련 설정 변화가 확인되며, rollback 뒤 같은 지표가 회복되는지까지 연결할수록 원인 가설의 증거가 강해진다.

5. 완성된 운영 적용

사례 A — API 지연 증가

CloudWatch latency·error metric으로 영향 시작 시점과 범위를 확인한다.
같은 시간·리소스 차원으로 application log를 조회해 timeout·exception 맥락을 찾는다.
X-Ray trace에서 요청이 application 내부, downstream API, database 중 어느 segment에서 오래 머무는지 구분한다.
CloudTrail과 AWS Config에서 직전 배포·권한·network·resource configuration 변경을 확인한다.
확인한 원인에 맞는 복구를 실행한 뒤 latency·error·성공률과 관련 log·trace를 다시 확인한다.

이 흐름은 CloudWatch가 원인을 알려준다가 아니라, CloudWatch가 영향의 모양을 보여 주고 다른 증거를 같은 좌표에 정렬하게 한다는 관계다.

사례 B — Security Group ingress가 예상과 다르게 열림

AWS Config의 현재 configuration과 history로 어떤 rule이 언제 어떻게 바뀌었는지 확인한다.
CloudTrail에서 해당 변경 API, 호출 identity, 요청 시각과 대상 resource를 확인한다.
EventBridge rule은 관련 event를 SNS, Lambda, Systems Manager Automation 같은 target으로 전달하는 반응 경로를 구성할 수 있다.
remediation 뒤 Config에서 desired configuration과 compliance가 회복됐는지 검증한다.

여기서는 Config가 상태 전후, CloudTrail이 행위 주체와 API 활동, EventBridge가 반응 경로를 맡는다.

사례 C — EC2 애플리케이션이 메모리 압력으로 불안정함

CloudWatch agent에서 guest OS memory metric과 application log를 수집하도록 구성한다.
mem_used_percent 같은 수치로 압력의 추세와 시작 시점을 보고, OOM·allocation failure log로 실행 맥락을 확인한다.
EC2·load balancer·application metric을 같은 시간축에 맞춰 customer impact와 host pressure의 관계를 구분한다.
구성 변경이나 배포가 있었다면 CloudTrail·Config 증거를 더하고, 조치 뒤 memory·latency·error가 함께 회복되는지 확인한다.

핵심은 guest 내부 신호가 필요할 때 guest 안에서 관측해 전송하는 수집 경계를 세우는 것이다.

6. 긍정형 연결 요약

영향의 크기와 추세 → CloudWatch metric
오류의 상세 내용과 실행 맥락 → CloudWatch Logs
한 요청의 downstream 경로와 구간별 시간 → X-Ray trace
상태 변화의 pattern matching과 target 전달 → EventBridge
identity·service가 수행한 계정 활동 → CloudTrail event
리소스 속성·관계의 시점별 상태 → AWS Config configuration history
EC2 guest OS·application telemetry → CloudWatch agent
발견 → 조사 → 변경 맥락 → 개입 → 검증 → 여러 증거를 같은 시간·리소스 범위에 정렬

이 구간은 이전에 하나로 보이기 쉬운 모니터링 데이터를 수치·내용·경로·변화·행위·구성 상태로 나눠 보게 하는 지도를 제공한다.

7. 공식 원천

다음 미전달 단원은 계획과 원장 기준 02/16 — 수집·경보·대시보드·알림이다.

DanzzaN

탐색기