Observability는 시스템 외부에서 내부 상태를 추론할 수 있는 능력입니다. Monitoring은 "무엇이 문제인가", Logging은 "왜 문제인가", Tracing은 "어디서 느려지는가"에 답합니다. 이 세 가지를 조합해야 장애를 감지하고 원인을 추적할 수 있습니다.
핵심 요약
- Observability는 Monitoring, Logging, Tracing 세 가지 축(Three Pillars)으로 구성됩니다.
- Monitoring은 메트릭 기반으로 시스템 상태를 수치화하고, 임계값 초과 시 알림을 발생시킵니다.
- Logging은 이벤트 단위로 상세 맥락을 기록하며, 장애 원인 분석(Root Cause Analysis)에 사용됩니다.
- Tracing은 분산 시스템에서 하나의 요청이 여러 서비스를 거치는 경로를 추적합니다.
- 세 축은 독립적으로 동작하지 않습니다. 알림(Monitoring) → 로그 확인(Logging) → 병목 추적(Tracing) 순서로 연계해야 장애 대응 시간을 줄일 수 있습니다.
1. 왜 필요한가
마이크로서비스 3개로 구성된 주문 시스템을 운영하고 있다고 가정합니다. 사용자가 "주문이 안 된다"고 신고합니다.
이때 확인해야 할 것들:
- 어떤 서비스에서 에러가 발생하는가? (API Gateway? 결제 서비스? 재고 서비스?)
- 에러율이 얼마나 되는가? 전체 사용자에게 영향을 주는가, 일부인가?
- 언제부터 시작되었는가?
- 에러의 원인은 무엇인가? (타임아웃? DB 연결 실패? 외부 API 장애?)
- 요청이 어떤 경로로 흘러가다가 실패했는가?
서버 1대에 모놀리식 애플리케이션을 운영할 때는 로그 파일 하나를 열면 대부분 파악할 수 있었습니다. 하지만 서비스가 분산되면 하나의 요청이 여러 서비스를 거치고, 각 서비스가 독립적으로 로그를 남깁니다. "어떤 요청이 어디서 실패했는지"를 파악하려면 체계적인 관측 전략이 필요합니다.
Observability는 이 문제를 구조적으로 해결합니다.
| 상황 | Observability 없이 | Observability 있을 때 |
|---|---|---|
| 장애 감지 | 사용자 신고로 인지 | 알림으로 즉시 인지 |
| 영향 범위 파악 | 추측 | 메트릭 대시보드에서 수치 확인 |
| 원인 분석 | 서버별 로그 파일을 하나씩 열어봄 | 중앙 로그에서 에러 필터링 |
| 병목 추적 | 각 서비스 담당자에게 물어봄 | 트레이스에서 지연 구간 확인 |
| 복구 시간 | 수십 분~수 시간 | 수 분 |
2. Observability vs Monitoring: 개념 구분
Observability와 Monitoring은 자주 혼용되지만 범위가 다릅니다.
| 구분 | Monitoring | Observability |
|---|---|---|
| 정의 | 사전에 정의한 지표를 수집하고 감시 | 시스템 내부 상태를 외부에서 추론할 수 있는 능력 |
| 질문 방식 | "CPU가 80%를 넘었는가?" (알려진 문제) | "왜 응답 시간이 갑자기 늘었는가?" (알려지지 않은 문제) |
| 범위 | Observability의 한 축 | Monitoring + Logging + Tracing의 조합 |
| 한계 | 예상하지 못한 장애에 대응하기 어려움 | 세 축이 연계되어야 효과적 |
Monitoring은 "알려진 문제"를 감지하는 데 적합합니다. CPU 사용률, 메모리, 디스크 — 이런 지표에 임계값을 설정하고 초과하면 알림을 보냅니다.
하지만 운영 환경에서는 "예상하지 못한 문제"가 더 많습니다. "특정 사용자 그룹에서만 결제가 실패한다", "화요일 오후 3시에만 응답이 느려진다" — 이런 문제는 사전에 어떤 메트릭을 봐야 하는지 알 수 없습니다.
Observability는 이런 상황에서 "데이터를 조합해서 원인을 추론"할 수 있는 능력을 의미합니다. Monitoring은 Observability를 구성하는 한 축입니다.
3. Three Pillars: 세 가지 축 개요
Observability는 세 가지 데이터 유형으로 구성됩니다. 각각이 답하는 질문이 다릅니다.
| 축 | 데이터 형태 | 답하는 질문 | 예시 |
|---|---|---|---|
| Monitoring (Metrics) | 시계열 수치 | 무엇이 문제인가? | CPU 90%, 에러율 5%, 응답시간 2초 |
| Logging | 텍스트 이벤트 | 왜 문제인가? | "DB connection timeout after 30s" |
| Tracing | 요청 경로 | 어디서 문제인가? | 결제 서비스 → 외부 PG API에서 3초 지연 |
비유로 이해하기
병원 진료에 비유하면:
- Monitoring: 체온계, 혈압계 — "열이 38도입니다" (이상 징후 감지)
- Logging: 환자 차트 — "어제 저녁부터 기침, 오늘 아침 두통 시작" (상세 기록)
- Tracing: CT/MRI — "폐 우측 하엽에 염증 소견" (경로 추적)
체온계만으로는 원인을 알 수 없고, 차트만으로는 위치를 특정할 수 없습니다. 세 가지를 조합해야 진단이 가능합니다.
4. Monitoring (Metrics): 무엇이 문제인가
정의와 역할
Monitoring은 시스템의 상태를 수치(Metric)로 측정하고, 시간에 따른 변화를 추적하는 것입니다. 메트릭은 시계열 데이터(time-series data)로 저장됩니다.
핵심 역할: - 시스템 상태를 실시간으로 파악 - 임계값 초과 시 알림 발생 - 트렌드 분석 (점진적 성능 저하 감지) - 용량 계획 (리소스 증설 시점 판단)
메트릭의 종류
| 유형 | 설명 | 예시 |
|---|---|---|
| Counter | 단조 증가하는 누적값 | 총 요청 수, 총 에러 수 |
| Gauge | 현재 시점의 값 (증감 가능) | CPU 사용률, 메모리 사용량, 활성 연결 수 |
| Histogram | 값의 분포 | 응답 시간 분포 (p50, p95, p99) |
| Summary | 클라이언트 측 분위수 계산 | 요청 지속 시간의 중앙값 |
실무에서 중요한 메트릭: RED와 USE
서비스 모니터링에서 "무엇을 측정할 것인가"는 중요한 설계 결정입니다. 두 가지 프레임워크가 널리 사용됩니다.
RED Method (서비스 관점 — 사용자 경험 중심): - Rate: 초당 요청 수 - Errors: 실패한 요청 비율 - Duration: 요청 처리 시간 (p50, p95, p99)
USE Method (인프라 관점 — 리소스 중심): - Utilization: 리소스 사용률 (CPU 70%) - Saturation: 대기열 길이 (처리 못하고 쌓이는 양) - Errors: 리소스 에러 수 (디스크 I/O 에러)
실무 시나리오: 주문 서비스 모니터링 설계
주문 API 서비스를 모니터링한다면:
# RED Method 적용
- Rate: orders_total (초당 주문 요청 수)
- Errors: orders_failed_total / orders_total (주문 실패율)
- Duration: order_processing_duration_seconds (주문 처리 시간)
# USE Method 적용 (인프라)
- Utilization: container_cpu_usage_seconds_total
- Saturation: container_memory_working_set_bytes
- Errors: node_disk_io_errors_total
알림 설계 예시:
| 조건 | 심각도 | 대응 |
|---|---|---|
| 에러율 > 1% (5분 지속) | Warning | 대시보드 확인 |
| 에러율 > 5% (5분 지속) | Critical | 즉시 대응 |
| p99 응답시간 > 3초 (10분 지속) | Warning | 성능 분석 |
| CPU > 80% (15분 지속) | Warning | 스케일링 검토 |
주요 도구
| 도구 | 유형 | 특징 |
|---|---|---|
| Prometheus | 오픈소스 | Pull 기반 수집, PromQL, Kubernetes 네이티브 |
| CloudWatch | AWS 매니지드 | AWS 서비스 통합, 추가 설정 최소 |
| Azure Monitor | Azure 매니지드 | Azure 리소스 자동 수집 |
| Cloud Monitoring | GCP 매니지드 | GCP 리소스 통합 |
| Datadog | SaaS | 멀티 클라우드, 풍부한 통합, 비용 높음 |
| Grafana | 오픈소스 | 시각화 특화, 다양한 데이터소스 연결 |
5. Logging: 왜 문제인가
정의와 역할
Logging은 시스템에서 발생하는 이벤트를 텍스트로 기록하는 것입니다. 메트릭이 "무엇이 문제인가"를 알려준다면, 로그는 "왜 문제인가"를 설명합니다.
핵심 역할: - 에러의 상세 원인 파악 (스택 트레이스, 에러 메시지) - 사용자 행동 추적 (누가, 언제, 무엇을 했는가) - 감사(Audit) 기록 (보안, 컴플라이언스) - 디버깅 (코드 실행 흐름 확인)
로그 레벨
| 레벨 | 용도 | 운영 환경 출력 |
|---|---|---|
| DEBUG | 개발 시 상세 흐름 확인 | 보통 비활성화 |
| INFO | 정상 동작 기록 (요청 시작/완료) | 선택적 |
| WARN | 잠재적 문제 (재시도 발생, 느린 쿼리) | 활성화 |
| ERROR | 처리 실패 (예외 발생, 타임아웃) | 활성화 |
| FATAL | 시스템 중단 수준의 오류 | 활성화 |
운영 환경에서 DEBUG 로그를 활성화하면 로그 볼륨이 급증하여 비용과 성능에 영향을 줍니다. 일반적으로 WARN 이상만 수집하고, 장애 분석 시 일시적으로 DEBUG를 활성화하는 전략을 사용합니다.
구조화된 로그 (Structured Logging)
전통적인 로그:
2026-05-31 10:23:45 ERROR OrderService - Failed to process order for user 12345: Connection timeout
구조화된 로그 (JSON):
{
"timestamp": "2026-05-31T10:23:45.123Z",
"level": "ERROR",
"service": "order-service",
"trace_id": "abc123def456",
"user_id": "12345",
"order_id": "ORD-98765",
"message": "Failed to process order",
"error": "Connection timeout",
"duration_ms": 30000,
"downstream_service": "payment-service"
}
구조화된 로그의 장점: - 필드 기반 검색이 가능 (user_id = "12345" AND level = "ERROR") - trace_id로 Tracing과 연계 가능 - 자동 파싱과 대시보드 생성이 쉬움 - 알림 조건을 세밀하게 설정 가능
실무 시나리오: 중앙 로그 수집 아키텍처
마이크로서비스 환경에서 각 서비스가 로컬에 로그를 남기면 장애 시 서버마다 접속해서 확인해야 합니다. 중앙 로그 수집 시스템을 구성하면 한 곳에서 모든 서비스의 로그를 검색할 수 있습니다.
일반적인 구성:
| 단계 | 역할 | 도구 예시 |
|---|---|---|
| 수집 (Collection) | 각 서비스에서 로그를 가져옴 | Fluentd, Fluent Bit, Filebeat |
| 전송 (Shipping) | 중앙 저장소로 전달 | Kafka (버퍼), 직접 전송 |
| 저장 (Storage) | 인덱싱 및 보관 | Elasticsearch, Loki, CloudWatch Logs |
| 검색/시각화 | 로그 검색 및 분석 | Kibana, Grafana, CloudWatch Insights |
주요 도구
| 도구 | 유형 | 특징 |
|---|---|---|
| ELK Stack | 오픈소스 | Elasticsearch + Logstash + Kibana, 풍부한 검색 |
| Grafana Loki | 오픈소스 | 라벨 기반 인덱싱, 저비용, Grafana 통합 |
| CloudWatch Logs | AWS 매니지드 | AWS 서비스 자동 연동, Log Insights 쿼리 |
| Azure Log Analytics | Azure 매니지드 | KQL 쿼리, Azure Monitor 통합 |
| Cloud Logging | GCP 매니지드 | GCP 리소스 자동 수집, BigQuery 연동 |
| Datadog Logs | SaaS | 멀티 클라우드, 자동 파싱, 비용 높음 |
6. Tracing: 어디서 문제인가
정의와 역할
Distributed Tracing(분산 트레이싱)은 하나의 요청이 여러 서비스를 거치는 전체 경로를 추적하는 것입니다. 마이크로서비스 환경에서 "어떤 서비스에서 지연이 발생하는가"를 파악하는 데 핵심적입니다.
핵심 역할: - 요청의 전체 경로 시각화 - 서비스 간 지연 구간 식별 - 의존성 관계 파악 - 성능 병목 분석
핵심 개념
| 용어 | 설명 |
|---|---|
| Trace | 하나의 요청에 대한 전체 경로 (여러 Span의 집합) |
| Span | 하나의 작업 단위 (서비스 호출, DB 쿼리 등) |
| Trace ID | 요청 전체를 식별하는 고유 ID (모든 서비스가 공유) |
| Span ID | 개별 작업을 식별하는 ID |
| Parent Span | 현재 Span을 호출한 상위 Span |
Tracing 동작 원리
- 사용자가 API Gateway에 요청을 보냅니다.
- API Gateway가 Trace ID를 생성하고 HTTP 헤더에 포함시킵니다.
- 각 서비스는 Trace ID를 전파하면서 자신의 Span을 기록합니다.
- 모든 Span이 중앙 수집기로 전송됩니다.
- 수집기가 Trace ID로 Span들을 조합하여 전체 경로를 재구성합니다.
실무 시나리오: 주문 처리 지연 추적
사용자가 "주문 완료까지 5초 이상 걸린다"고 신고합니다. Tracing으로 확인하면:
Trace ID: abc-123-def-456
총 소요시간: 5,200ms
├─ API Gateway (50ms)
├─ Order Service (120ms)
│ ├─ 주문 유효성 검증 (20ms)
│ └─ Payment Service 호출 (4,800ms) ← 병목
│ ├─ 결제 요청 생성 (30ms)
│ └─ 외부 PG API 호출 (4,700ms) ← 근본 원인
└─ Notification Service (230ms)
Tracing 없이는 "어디가 느린지" 각 서비스 담당자에게 물어봐야 합니다. Tracing이 있으면 한 화면에서 병목 구간을 즉시 확인할 수 있습니다.
샘플링 전략
모든 요청을 100% 트레이싱하면 데이터 볼륨과 비용이 급증합니다. 실무에서는 샘플링을 적용합니다.
| 전략 | 설명 | 적합 환경 |
|---|---|---|
| Head-based Sampling | 요청 시작 시점에 수집 여부 결정 (예: 10%) | 트래픽이 많은 서비스 |
| Tail-based Sampling | 요청 완료 후 조건에 따라 수집 (에러, 지연) | 중요 요청을 놓치지 않아야 할 때 |
| Rate Limiting | 초당 최대 수집량 제한 | 비용 제어가 중요할 때 |
Tail-based Sampling이 더 유용하지만 구현이 복잡합니다. 요청이 완료될 때까지 모든 Span을 메모리에 보관해야 하기 때문입니다. 일반적으로 Head-based 10~20% + 에러/지연 요청 100% 수집을 조합합니다.
주요 도구
| 도구 | 유형 | 특징 |
|---|---|---|
| Jaeger | 오픈소스 | CNCF 졸업 프로젝트, Kubernetes 친화적 |
| Zipkin | 오픈소스 | 경량, 간단한 설정 |
| AWS X-Ray | AWS 매니지드 | AWS 서비스 자동 연동 |
| Azure Application Insights | Azure 매니지드 | .NET 생태계 강점 |
| Cloud Trace | GCP 매니지드 | GCP 서비스 통합 |
| Datadog APM | SaaS | 멀티 클라우드, 자동 계측 |
| OpenTelemetry | 오픈소스 표준 | 벤더 중립, 수집 표준화 |
7. 세 축의 연계: 장애 대응 흐름
세 축은 독립적으로 사용하는 것이 아니라, 장애 대응 과정에서 순차적으로 연계됩니다.
실무 시나리오: 결제 실패율 급증 대응
1단계 — Monitoring (감지)
알림 발생: "payment-service 에러율이 5%를 초과했습니다 (평소 0.1%)"
대시보드에서 확인: - 에러율: 0.1% → 7.2% (10분 전부터) - p99 응답시간: 200ms → 4,500ms - 영향 범위: 전체 결제 요청의 약 7%
→ "무엇이 문제인가?" 결제 서비스에서 에러가 급증하고 있음
2단계 — Logging (원인 분석)
중앙 로그에서 payment-service의 ERROR 로그를 필터링:
{
"level": "ERROR",
"service": "payment-service",
"message": "Connection timeout to PG API",
"error": "java.net.SocketTimeoutException: connect timed out",
"pg_provider": "nice-pay",
"timeout_ms": 30000,
"trace_id": "abc-123-def-456"
}
→ "왜 문제인가?" 외부 PG사(NICE Pay) API 연결 타임아웃
3단계 — Tracing (경로 확인)
trace_id로 전체 경로를 확인:
Order Service → Payment Service → NICE Pay API (timeout 30s)
→ Fallback: KG Inicis API (성공, 200ms)
→ "어디서 문제인가?" NICE Pay API에서 타임아웃 발생. Fallback으로 KG Inicis를 사용하는 요청은 정상 처리됨.
4단계 — 대응
- 즉시: NICE Pay 비중을 줄이고 KG Inicis로 트래픽 전환
- 단기: NICE Pay 측에 장애 확인 요청
- 장기: Circuit Breaker 패턴 적용하여 타임아웃 시 자동 Fallback
이 과정이 Observability 없이는 "사용자 신고 → 각 서비스 담당자에게 확인 → 로그 파일 수동 검색 → 원인 추측"으로 수십 분이 걸릴 수 있습니다.
8. OpenTelemetry: 통합 표준
OpenTelemetry(OTel)는 Observability 데이터(Metrics, Logs, Traces)를 수집하는 오픈소스 표준입니다. CNCF(Cloud Native Computing Foundation) 프로젝트로, 벤더 종속 없이 데이터를 수집하고 원하는 백엔드로 전송할 수 있습니다.
왜 필요한가
Observability 도구를 선택할 때 가장 큰 리스크는 벤더 종속(Vendor Lock-in)입니다. Datadog SDK로 계측한 코드를 나중에 Jaeger로 바꾸려면 전체 코드를 수정해야 합니다.
OpenTelemetry는 이 문제를 해결합니다: - 계측(Instrumentation)은 OTel SDK로 통일 - 백엔드(저장/분석)는 자유롭게 선택/교체 가능 - Jaeger, Datadog, Grafana, AWS X-Ray 등 대부분의 백엔드가 OTel 형식을 지원
구성 요소
| 구성 요소 | 역할 |
|---|---|
| SDK | 애플리케이션 코드에서 데이터 생성 |
| Auto-instrumentation | 코드 수정 없이 자동 계측 (HTTP, DB, gRPC 등) |
| Collector | 데이터 수집, 처리, 내보내기 (중간 에이전트) |
| Exporter | 특정 백엔드로 데이터 전송 (Jaeger, Prometheus 등) |
새로운 서비스를 구축할 때 Observability 도구를 아직 결정하지 못했다면, OpenTelemetry SDK로 계측해두는 것이 안전합니다. 나중에 백엔드를 바꿔도 애플리케이션 코드를 수정할 필요가 없습니다.
9. 보안 고려사항
Observability 데이터에는 사용자 정보, 요청 내용, 시스템 내부 구조가 포함될 수 있습니다. 로그와 트레이스에 민감 정보가 노출되지 않도록 설계해야 합니다.
민감 정보 노출 위험
| 위험 | 예시 | 대응 |
|---|---|---|
| 로그에 개인정보 포함 | 사용자 이메일, 전화번호가 로그에 기록됨 | 마스킹 처리 (PII Redaction) |
| 트레이스에 요청 본문 포함 | 결제 카드 번호가 Span 속성에 기록됨 | 민감 필드 제외 설정 |
| 메트릭 라벨에 사용자 ID | 카디널리티 폭발 + 개인 추적 가능 | 라벨 값 제한 |
| 로그 저장소 접근 제어 미흡 | 개발자 전원이 프로덕션 로그 열람 가능 | RBAC 적용 |
보안 설계 원칙
- 로그에 민감 정보를 기록하지 않는 것이 기본입니다. 불가피한 경우 마스킹 처리합니다.
- Observability 데이터 저장소에도 접근 제어를 적용합니다. 프로덕션 로그는 필요한 인원만 접근할 수 있어야 합니다.
- 데이터 보존 기간을 정의합니다. 규정(GDPR, 개인정보보호법)에 따라 일정 기간 후 삭제해야 할 수 있습니다.
- 외부 SaaS 도구 사용 시 데이터가 어디에 저장되는지 확인합니다. 민감 데이터가 해외 리전에 저장될 수 있습니다.
10. 비용/운영 고려사항
Observability는 "많이 수집할수록 좋다"가 아닙니다. 데이터 볼륨에 비례하여 저장 비용, 네트워크 비용, 쿼리 성능이 영향을 받습니다. 수집 범위와 보존 기간을 설계해야 합니다.
비용 구조
| 항목 | 비용 발생 요인 | 최적화 방향 |
|---|---|---|
| 메트릭 수집 | 커스텀 메트릭 수, 수집 주기 | 필요한 메트릭만 정의, 수집 주기 조정 |
| 로그 저장 | 로그 볼륨 (GB/일), 보존 기간 | 로그 레벨 관리, 샘플링, 보존 정책 |
| 트레이싱 | Span 수, 샘플링 비율 | Head/Tail-based 샘플링 조합 |
| 알림 | 알림 채널 수, 평가 빈도 | 의미 있는 알림만 설정 |
| 대시보드 | 쿼리 복잡도, 새로고침 주기 | 필요한 대시보드만 유지 |
비용 최적화 전략
로그 비용 줄이기: - 운영 환경에서 DEBUG 로그 비활성화 (볼륨 50~70% 감소 가능) - 헬스체크 로그 제외 (반복적이고 가치 낮음) - 핫 스토리지(검색 가능) → 콜드 스토리지(아카이브) 계층화 - 보존 기간 차등 적용: ERROR 90일, INFO 30일, DEBUG 7일
메트릭 비용 줄이기: - 카디널리티(고유 라벨 조합 수) 관리 — user_id를 라벨로 사용하면 폭발 - 수집 주기: 15초 → 60초로 변경하면 데이터량 4배 감소 (정밀도 trade-off) - 사용하지 않는 메트릭 정리
트레이싱 비용 줄이기: - 샘플링 비율 조정 (전체 10% + 에러 100%) - 내부 헬스체크 요청 제외 - Span 속성에 불필요한 데이터 포함하지 않기
데이터 보존 정책 예시
| 데이터 유형 | 핫 스토리지 | 콜드 스토리지 | 삭제 |
|---|---|---|---|
| 메트릭 (고해상도) | 15일 | 90일 (다운샘플링) | 1년 |
| 메트릭 (저해상도) | - | 2년 | 3년 |
| 로그 (ERROR) | 30일 | 90일 | 1년 |
| 로그 (INFO) | 7일 | 30일 | 90일 |
| 트레이스 | 7일 | 30일 | 90일 |
이 정책은 서비스 특성과 규정 요구사항에 따라 조정합니다. 금융 서비스는 감사 로그를 수 년간 보관해야 할 수 있습니다.
11. 자주 하는 실수
1. 모든 것을 수집하려는 접근
"일단 다 수집하고 나중에 분석하자"는 접근은 비용 폭발로 이어집니다. 수집 전에 "이 데이터로 어떤 질문에 답할 것인가"를 먼저 정의해야 합니다.
2. 알림 피로 (Alert Fatigue)
임계값을 너무 낮게 설정하거나, 모든 지표에 알림을 걸면 하루에 수십 건의 알림이 발생합니다. 팀원들이 알림을 무시하게 되고, 실제 장애 알림도 놓치게 됩니다. 알림은 "사람이 즉시 대응해야 하는 상황"에만 설정합니다.
3. 로그만으로 모든 것을 해결하려는 시도
로그에 모든 정보를 넣으면 Monitoring과 Tracing이 필요 없다고 생각하는 경우입니다. 로그는 검색 기반이므로 "무엇을 찾아야 하는지" 알아야 합니다. 메트릭은 전체 상태를 한눈에 보여주고, 트레이싱은 요청 경로를 시각화합니다. 각각의 역할이 다릅니다.
4. Trace ID를 전파하지 않음
분산 트레이싱을 도입했지만 서비스 간 Trace ID 전파를 누락하면, 각 서비스의 Span이 연결되지 않습니다. HTTP 헤더(traceparent, X-B3-TraceId 등)를 통해 Trace ID를 전파하는 설정을 모든 서비스에 적용해야 합니다.
5. 대시보드만 만들고 알림을 설정하지 않음
대시보드는 "보고 있을 때"만 유용합니다. 새벽 3시에 장애가 발생하면 대시보드를 보는 사람이 없습니다. 핵심 지표에는 반드시 알림을 설정해야 합니다.
6. Observability를 사후에 추가하려는 시도
서비스를 다 만든 후에 Observability를 추가하면 계측 코드를 전체에 삽입해야 합니다. 서비스 설계 단계에서 "어떤 메트릭을 노출할 것인가", "로그 포맷은 무엇인가", "Trace ID를 어떻게 전파할 것인가"를 함께 정의하는 것이 효율적입니다.
12. 도구 선택 가이드
환경별 권장 조합
| 환경 | Monitoring | Logging | Tracing | 비고 |
|---|---|---|---|---|
| AWS 단일 환경 | CloudWatch Metrics | CloudWatch Logs | X-Ray | 추가 설정 최소, AWS 통합 |
| Azure 단일 환경 | Azure Monitor | Log Analytics | Application Insights | Azure 네이티브 통합 |
| GCP 단일 환경 | Cloud Monitoring | Cloud Logging | Cloud Trace | GCP 네이티브 통합 |
| Kubernetes (자체 운영) | Prometheus + Grafana | Loki 또는 ELK | Jaeger | 오픈소스, 비용 효율적 |
| 멀티 클라우드/대규모 | Datadog | Datadog Logs | Datadog APM | 통합 플랫폼, 비용 높음 |
선택 기준
| 기준 | 클라우드 매니지드 | 오픈소스 자체 운영 | SaaS (Datadog 등) |
|---|---|---|---|
| 초기 설정 | 쉬움 | 복잡함 | 쉬움 |
| 운영 부담 | 낮음 | 높음 | 낮음 |
| 비용 (소규모) | 낮음 | 낮음 | 중간 |
| 비용 (대규모) | 중간~높음 | 낮음 | 높음 |
| 커스터마이징 | 제한적 | 높음 | 중간 |
| 벤더 종속 | 클라우드 종속 | 없음 | SaaS 종속 |
| 멀티 클라우드 | 어려움 | 가능 | 가능 |
단일 클라우드 환경이라면 해당 클라우드의 매니지드 서비스로 시작하는 것이 운영 부담이 적습니다. 규모가 커지거나 멀티 클라우드로 확장할 때 OpenTelemetry 기반으로 전환을 검토합니다.
13. 정리
- Observability는 Monitoring(무엇이 문제인가), Logging(왜 문제인가), Tracing(어디서 문제인가) 세 축으로 구성됩니다. 각각이 답하는 질문이 다르므로 세 가지를 조합해야 효과적입니다.
- Monitoring은 시스템 상태를 수치로 파악하고 이상을 감지합니다. RED Method(서비스)와 USE Method(인프라)로 측정 대상을 설계합니다.
- Logging은 이벤트의 상세 맥락을 기록합니다. 구조화된 로그(JSON)를 사용하면 검색과 분석이 쉬워집니다.
- Tracing은 분산 시스템에서 요청 경로를 추적합니다. 샘플링 전략으로 비용과 가시성의 균형을 맞춥니다.
- OpenTelemetry를 사용하면 벤더 종속 없이 Observability 데이터를 수집할 수 있습니다.
- 비용 관리가 중요합니다. "무엇을 수집할 것인가"를 먼저 정의하고, 보존 정책을 설계해야 합니다.
참고 문서
'Observability' 카테고리의 다른 글
| OpenTelemetry란 무엇인가: 분산 트레이싱 기본 개념 (0) | 2026.06.08 |
|---|---|
| 알림 설계: 노이즈를 줄이고 의미 있는 알림만 받는 방법 (0) | 2026.06.07 |
| Prometheus + Grafana로 Kubernetes 모니터링 구성하기 (0) | 2026.06.06 |
| CloudWatch vs Datadog vs Grafana: 모니터링 도구 선택 기준 (0) | 2026.06.01 |
