클라우드 인프라를 운영하다 보면 언제나 같은 물음과 마주칩니다. '지금 시스템이 잘 돌아가고 있나?' 이 물음에 답하려면 메트릭, 로그, 트레이스라는 세 가지 신호를 수집하고 분석하는 체계, 즉 옵저버빌리티(Observability) 스택이 필요합니다. Google Cloud에서는 이 역할을 Cloud Monitoring과 Cloud Logging이 중심에서 담당합니다.
---
운영 가시성 없이 클라우드를 운영한다는 것
수십~수백 대의 VM과 수십 개의 관리형 서비스가 얽혀있는 클라우드 환경에서 '직접 서버실에 가서 확인'하는 방식은 불가능합니다. 문제가 생겨도 어디서, 언제부터, 왜 생겼는지 알 수 없는 상태를 '블랙박스 운영'이라고 합니다. 운영 가시성(Observability)이란 시스템 내부에서 무슨 일이 벌어지는지 외부에서 관찰할 수 있는 능력입니다. 옵저버빌리티의 세 기둥은 아래와 같습니다.
| 신호 종류 | 무엇을 알 수 있나 | GCP 도구 | |-----------|-------------------|----------| | 메트릭(Metrics) | 수치로 표현되는 상태 — CPU 80%, 요청 지연 200ms | Cloud Monitoring | | 로그(Logs) | 특정 시점에 무슨 일이 일어났는지 — 에러 메시지, 이벤트 기록 | Cloud Logging | | 트레이스(Traces) | 요청이 서비스 간에 어떻게 흘렀는지 — 병목 구간 파악 | Cloud Trace |
메트릭은 '지금 상태가 어떤가', 로그는 '무슨 일이 있었나', 트레이스는 '왜 느린가'에 각각 답합니다. 시험에서도 시나리오에 따라 어떤 도구를 써야 하는지 구분하는 문제가 자주 출제되므로 이 세 가지를 명확히 구별해두는 것이 중요합니다.
---
Cloud Monitoring의 핵심 구성 요소
Cloud Monitoring은 과거에 Stackdriver Monitoring이라고 불렸습니다. GCP 리소스에서 자동으로 수집된 수천 가지 메트릭을 저장하고, 대시보드와 알림 정책을 통해 운영팀이 시스템 상태를 한눈에 파악할 수 있게 해주는 서비스입니다.
메트릭 수집 구조
Compute Engine VM은 Ops Agent를 설치하면 시스템 레벨 메트릭(CPU, 메모리, 디스크, 네트워크)과 애플리케이션 로그를 모두 수집할 수 있습니다. Cloud SQL, GKE, Cloud Run 같은 관리형 서비스는 별도 에이전트 없이 자동으로 메트릭이 수집됩니다. 커스텀 애플리케이션 메트릭은 OpenTelemetry SDK 또는 Prometheus를 사용하며, GKE 환경에서는 Managed Service for Prometheus로 Prometheus 메트릭을 그대로 수집할 수 있습니다.
대시보드와 알림 정책
Cloud Monitoring의 두 핵심 기능은 대시보드(메트릭 시각화)와 알림 정책(Alerting Policy)입니다. 알림 정책은 특정 메트릭이 임계값을 초과하면 자동으로 알림을 보내는 기능으로, 조건(Condition)·알림 채널(Notification Channel)·문서(Documentation)로 구성됩니다.
| 구성 요소 | 역할 | 예시 | |-----------|------|------| | 조건(Condition) | 어떤 메트릭이, 어떤 임계값을, 얼마나 지속할 때 | disk/read_latencies > 100ms, 5분 이상 | | 알림 채널 | 누구에게, 어떻게 알릴까 | 이메일, Slack, PagerDuty, Webhook, Pub/Sub | | 지속 시간(Duration) | 일시적 스파이크 무시, 일정 시간 지속될 때만 트리거 | 1분, 5분, 10분 | | 문서(Documentation) | 알림과 함께 전달할 런북, 안내 메시지 | '이 알림이 오면 X를 확인하세요' |
지속 시간 조건은 알림 피로(Alert Fatigue)를 줄이는 데 매우 중요합니다. 순간적으로 CPU가 100%를 찍었다가 바로 내려오는 경우에도 조건이 트리거되면 운영팀은 계속 알림을 받아 '알림 피로'를 겪게 됩니다. 지속 시간을 5분 이상으로 설정하면 일시적 스파이크는 무시하고 실제 문제가 될 때만 알림을 보낼 수 있습니다.
---
Cloud Logging과 로그 라우터의 작동 원리
Cloud Logging은 GCP의 중앙 집중식 로그 관리 서비스입니다. 시험에서 중요한 로그 종류는 두 가지입니다. Admin Activity 감사 로그는 GCP 리소스 생성·삭제·변경(IAM, 스키마 변경 등)을 자동 기록하며 비활성화가 불가능합니다. Data Access 감사 로그는 BigQuery 쿼리·GCS 읽기 같은 데이터 접근 작업을 기록하며, 기본 비활성 상태이므로 별도 활성화가 필요합니다.
로그 라우터와 싱크
Cloud Logging의 핵심 아키텍처는 로그 라우터(Log Router)와 싱크(Sink)입니다. 로그 라우터는 수신된 로그를 검사하고, 싱크의 필터 조건에 맞는 로그를 지정된 목적지로 내보냅니다. 흐름은 '로그 소스 → Cloud Logging 수집 → 로그 라우터 → 싱크 필터 매칭 → 목적지' 순입니다. 시험에서 가장 자주 헷갈리는 부분이 바로 싱크 목적지 선택이므로 아래 표를 외워두는 것이 좋습니다.
| 싱크 목적지 | 사용 시나리오 | 키워드 힌트 | |------------|--------------|-------------| | Cloud Storage | 장기 보관, 규정 준수 아카이빙, 감사 로그 보존 | '장기 보관', '아카이브', 'compliance' | | BigQuery | 로그 기반 분석, SQL 쿼리, BI 대시보드 연동 | '분석', 'SQL 쿼리', 'BigQuery' | | Pub/Sub | 실시간 처리, 외부 시스템 연동, 스트리밍 파이프라인 | '실시간', '외부 시스템', '스트리밍' | | Splunk | 기존 SIEM 도구 연동 | 'Splunk', 'SIEM' | | 타 Cloud Logging | 조직 간 로그 집중화, 보안 프로젝트로 감사 로그 라우팅 | '중앙화', '다른 프로젝트' |
---
로그 기반 메트릭과 SLO 기반 알림 설계
로그 기반 메트릭(Log-based Metrics)
Cloud Logging의 강력한 기능 중 하나는 로그에서 메트릭을 생성하는 것입니다. 'ERROR' 문자열이 포함된 로그 건수를 카운터 메트릭으로 만들면, Cloud Monitoring에서 이 메트릭을 기준으로 알림 정책을 설정할 수 있습니다. 유형은 카운터(Counter, 로그 패턴 발생 건수)와 분포(Distribution, 로그에서 추출한 수치값의 분포) 두 가지입니다. 시험에서 '로그의 특정 패턴 횟수가 임계값을 초과하면 알림'이라는 시나리오가 나오면 로그 기반 메트릭을 떠올리세요.
SLO 기반 알림 설계
SLO(Service Level Objective)는 서비스 품질 목표입니다. Cloud Monitoring은 SLO를 직접 정의하고, 오류 예산(Error Budget) 소진 속도에 따라 알림을 보냅니다. 월간 99.9% 가용성 SLO에서 오류 예산의 10%가 1시간 안에 소진되면 즉시 알림, 1%가 24시간에 걸쳐 소진되면 느린 채널로 보내는 방식입니다. 이것이 알림 피로를 줄이는 SRE 관점의 알림 설계입니다.
| 알림 방식 | 특징 | 언제 적합한가 | |-----------|------|---------------| | 임계값 기반 알림 | 특정 메트릭이 수치를 넘을 때 | 즉각 대응이 필요한 인프라 메트릭 | | 로그 기반 메트릭 알림 | 로그 패턴의 빈도가 임계값 초과 시 | 에러 로그 급증, 보안 이벤트 감지 | | SLO 기반 알림 | 오류 예산 소진 속도 기반 | SLO 운영, 알림 피로 최소화 |
---
업타임 체크로 가용성 측정하기
Uptime Check는 외부에서 서비스의 가용성을 주기적으로 확인하는 기능입니다. Cloud Monitoring이 전 세계 여러 리전에서 지정한 URL이나 IP로 HTTP/HTTPS/TCP 요청을 보내고, 응답 코드·응답 본문·응답 시간을 검사합니다.
| 구성 요소 | 설명 | |-----------|------| | 체크 대상 | URL, IP 주소, GCP 리소스 (https://example.com/health 등) | | 프로토콜 | HTTP, HTTPS, TCP | | 체크 주기 | 1분~15분 (1분 권장) | | 콘텐츠 매처 | 응답 본문에 특정 문자열('OK', 'healthy')이 있어야 성공 | | 체크 위치 | us-east1, europe-west1, asia-east1 등 다수 리전 동시 체크 |
Uptime Check 실패 → Cloud Monitoring 알림 정책과 연동 → 즉시 알림. 실사용자가 서비스에 접근할 수 없는 상황을 가장 빠르게 탐지하는 방법입니다. 단, 내부 IP 전용 VM은 기본적으로 체크 불가이며, 외부에서 접근 가능한 엔드포인트에만 적용할 수 있습니다.
---
Cloud Trace, Error Reporting, Cloud Profiler 한 줄 정리
Cloud Monitoring과 Cloud Logging 외에도 GCP 옵저버빌리티 스택에는 세 가지 도구가 더 있습니다. 역할을 한 줄로 정리해두면 시나리오 문제에서 헷갈리지 않습니다.
| 서비스 | 역할 | 언제 사용하나 | |--------|------|---------------| | Cloud Trace | 요청이 서비스 간에 어떻게 흘렀는지 추적 (분산 트레이싱) | API 레이턴시 높을 때, 병목 서비스 특정 | | Error Reporting | 에러를 자동 집계·그룹화, 신규 에러 알림 | 배포 후 에러 급증 여부 빠르게 파악 | | Cloud Profiler | 프로덕션 CPU/메모리 소비 코드 경로 플레임 그래프 분석 | 성능 최적화, 메모리 누수 탐지 |
Cloud Trace는 OpenTelemetry SDK 또는 Cloud Trace API로 계측합니다. GKE·Cloud Run은 자동 트레이스 수집 옵션이 있어 별도 코드 없이도 기본 레이턴시 정보를 얻을 수 있습니다. Error Reporting은 Cloud Logging의 에러 로그에서 자동 추출·그룹화하며, 같은 에러가 처음 발생할 때 알림을 보냅니다. Cloud Profiler는 경량 에이전트로 오버헤드가 매우 적어 프로덕션에서 상시 활성화할 수 있습니다.
!Cloud Trace vs Error Reporting vs Cloud Profiler
시험에서 자주 헷갈리는 모니터링·로깅 시나리오
이 섹션은 실제 시험 문제 유형을 바탕으로 자주 혼동되는 시나리오를 정리합니다.
시나리오 1: 싱크 목적지 선택
가장 자주 출제되는 유형입니다. 키워드를 보고 즉시 싱크 목적지를 떠올릴 수 있어야 합니다.
| 키워드 | 정답 싱크 | 오답 싱크 | |--------|-----------|----------| | 장기 보관, 규정 준수, 아카이브, 감사 로그 90일 보존 | Cloud Storage | BigQuery (분석용) | | 실시간 처리, 외부 시스템 연동, 스트리밍 파이프라인 | Pub/Sub | Cloud Storage (배치) | | SQL 쿼리로 로그 분석, BI 대시보드, 로그 패턴 분석 | BigQuery | Pub/Sub (실시간) |
시나리오 2: 알림 도구 선택
| 시나리오 | 정답 | 이유 | |----------|------|------| | CPU 사용률이 80%를 5분 이상 초과하면 알림 | Cloud Monitoring 알림 정책 (메트릭 기반) | 수치 임계값 + 지속 시간 조건 | | HTTP 500 에러 로그가 분당 10건 이상이면 알림 | 로그 기반 메트릭 + 알림 정책 | 로그 패턴 → 메트릭 변환 | | 외부에서 웹사이트 접속이 안 되면 알림 | Uptime Check + 알림 정책 | 외부 가용성 모니터링 | | BigQuery 스키마 변경 이벤트 발생 시 알림 | Cloud Audit Logs + Pub/Sub + Cloud Functions | 이벤트 기반, 메트릭 아님 |
시나리오 3: Ops Agent 트러블슈팅
'메트릭은 정상 수집되는데 로그가 안 들어온다'면 Ops Agent 로그 수집 구성 문제입니다. 기본 설정은 syslog 등 시스템 로그만 수집하므로, 웹 서버 액세스 로그 등 애플리케이션 로그는 의 에 파일 경로를 명시적으로 추가해야 합니다.
시나리오 4: Cloud Armor vs Cloud Logging 기반 IP 차단
SSH(22 포트) 무차별 대입 공격 차단은 Cloud Armor가 아니라 'Cloud Logging 로그 기반 메트릭 → Cloud Functions → Firewall Rules' 자동화 워크플로우입니다. Cloud Armor는 HTTP(S) 트래픽(80/443)만 처리하는 WAF이므로 SSH 포트를 직접 처리할 수 없습니다.
---
정리: 운영 가시성 체크리스트와 트러블슈팅 워크플로우
운영 가시성 체크리스트