모니터링 도구를 선택할 때 "기능이 많은 것"이 정답은 아닙니다. AWS 단일 환경에서 EC2 10대를 운영하는 팀과, 멀티 클라우드에서 마이크로서비스 50개를 운영하는 팀이 같은 도구를 쓸 이유가 없습니다. 비용, 운영 부담, 확장성, 팀 역량을 기준으로 판단해야 합니다.
요약
| 기준 | CloudWatch | Datadog | Grafana + Prometheus |
|---|---|---|---|
| 유형 | AWS 매니지드 | SaaS 플랫폼 | 오픈소스 자체 운영 |
| 초기 설정 | 거의 없음 (AWS 자동 연동) | 에이전트 설치 후 빠름 | 직접 구축 필요 |
| 운영 부담 | 낮음 | 낮음 | 높음 |
| 비용 (소규모) | 낮음 | 중간 | 낮음 (인프라 비용만) |
| 비용 (대규모) | 중간~높음 | 높음 | 낮음~중간 |
| 멀티 클라우드 | 어려움 | 강점 | 가능 |
| 커스터마이징 | 제한적 | 중간 | 높음 |
| 추천 환경 | AWS 단일 환경, 소규모 팀 | 멀티 클라우드, 빠른 도입 필요 | Kubernetes 중심, 비용 민감 |
1. 왜 이 비교가 필요한가
팀에서 모니터링 도구를 도입하려고 합니다. 검색하면 CloudWatch, Datadog, Grafana가 반복적으로 등장합니다. 각각의 블로그 글은 자기 도구가 좋다고 말합니다.
하지만 실무에서 도구를 선택할 때 고려해야 할 것은 기능 목록이 아닙니다.
- 비용: 호스트 50대에 Datadog을 붙이면 월 얼마인가?
- 운영 부담: Prometheus를 직접 운영할 인력이 있는가?
- 확장성: 지금은 AWS만 쓰지만, 6개월 후 Azure를 추가할 계획이 있는가?
- 팀 역량: PromQL을 작성할 수 있는 엔지니어가 있는가?
이 글에서는 세 도구의 구조적 차이를 먼저 정리하고, 환경별 선택 기준을 제시합니다.
2. 각 도구의 포지셔닝
세 도구는 같은 문제를 풀지만, 접근 방식이 근본적으로 다릅니다.
CloudWatch: AWS 네이티브 모니터링
CloudWatch는 AWS에 내장된 모니터링 서비스입니다. EC2를 생성하면 CPU, 네트워크 메트릭이 자동으로 수집됩니다. 별도 에이전트 설치 없이 AWS 리소스의 기본 메트릭을 확인할 수 있습니다.
핵심 특성: - AWS 서비스와 자동 통합 (EC2, RDS, Lambda, ECS 등) - 추가 설정 없이 기본 메트릭 수집 - CloudWatch Logs, Alarms, Dashboards를 하나의 서비스에서 제공 - AWS 외부 리소스 모니터링은 제한적
Datadog: 통합 Observability SaaS 플랫폼
Datadog은 Metrics, Logs, Traces, APM, Security를 하나의 플랫폼에서 제공하는 SaaS 서비스입니다. 에이전트를 설치하면 수백 개의 통합(Integration)이 자동으로 데이터를 수집합니다.
핵심 특성: - 750개 이상의 통합 (AWS, Azure, GCP, Kubernetes, 데이터베이스 등) - 멀티 클라우드 환경을 단일 대시보드에서 관리 - 자동 서비스 맵, 이상 탐지(Anomaly Detection) 등 고급 기능 - 호스트/컨테이너 단위 과금으로 규모에 따라 비용 급증 가능
Grafana + Prometheus: 오픈소스 모니터링 스택
Prometheus는 메트릭 수집/저장 엔진이고, Grafana는 시각화 도구입니다. 함께 사용하면 강력한 모니터링 시스템을 구축할 수 있습니다. Kubernetes 생태계에서 사실상 표준입니다.
핵심 특성: - 완전한 오픈소스 (라이선스 비용 없음) - Kubernetes 네이티브 (kube-prometheus-stack으로 빠른 구축) - PromQL로 유연한 쿼리 작성 - 직접 운영해야 하므로 인프라 관리 부담 존재 - Grafana는 다양한 데이터소스 연결 가능 (Prometheus, Loki, Elasticsearch, CloudWatch 등)
3. 아키텍처 차이
CloudWatch 아키텍처
AWS 리소스 → CloudWatch Metrics (자동 수집)
→ CloudWatch Logs (로그 그룹)
→ CloudWatch Alarms (임계값 기반 알림)
→ CloudWatch Dashboards (시각화)
- 데이터 수집, 저장, 알림, 시각화가 모두 AWS 내부에서 처리됩니다.
- 사용자가 관리할 인프라가 없습니다.
- 커스텀 메트릭은
PutMetricDataAPI로 전송합니다. - 상세 모니터링(1분 → 5초 간격)은 추가 비용이 발생합니다.
Datadog 아키텍처
호스트/컨테이너 → Datadog Agent (로컬 수집)
→ Datadog 클라우드 (SaaS 백엔드)
→ 대시보드, 알림, APM, 로그 분석
- 각 호스트에 Datadog Agent를 설치합니다.
- Agent가 메트릭, 로그, 트레이스를 수집하여 Datadog 클라우드로 전송합니다.
- 모든 데이터는 Datadog의 인프라에 저장됩니다.
- 데이터 주권(Data Sovereignty) 요구사항이 있는 경우 주의가 필요합니다.
Grafana + Prometheus 아키텍처
애플리케이션 → /metrics 엔드포인트 노출
Prometheus → Pull 방식으로 메트릭 수집 → 로컬 TSDB 저장
Grafana → Prometheus를 데이터소스로 연결 → 대시보드 시각화
Alertmanager → Prometheus 규칙 기반 알림 발송
- Prometheus가 대상(Target)의
/metrics엔드포인트를 주기적으로 스크래핑합니다. - 수집된 데이터는 Prometheus의 로컬 시계열 데이터베이스(TSDB)에 저장됩니다.
- Grafana는 Prometheus에 PromQL 쿼리를 실행하여 시각화합니다.
- 장기 보존이 필요하면 Thanos나 Cortex 같은 원격 스토리지를 추가합니다.
4. 비용 비교
비용은 도구 선택에서 가장 큰 변수입니다. 세 도구의 과금 구조가 근본적으로 다르기 때문에 단순 비교가 어렵습니다.
4.1 과금 구조 비교
| 항목 | CloudWatch | Datadog | Grafana + Prometheus |
|---|---|---|---|
| 기본 메트릭 | 무료 (AWS 리소스) | 호스트당 $15~23/월 (Infrastructure) | 무료 (인프라 비용만) |
| 커스텀 메트릭 | $0.30/메트릭/월 (처음 10,000개) | 커스텀 메트릭 100개 포함, 초과 시 추가 과금 | 무료 (스토리지 비용만) |
| 로그 수집 | $0.50/GB (수집) + $0.03/GB (저장) | $0.10/GB (수집) + 보존 기간별 추가 | 무료 (Loki 사용 시 스토리지 비용) |
| APM/Tracing | X-Ray: $5/백만 트레이스 | $31~40/호스트/월 (APM) | 무료 (Jaeger/Tempo 자체 운영) |
| 대시보드 | 대시보드당 $3/월 | 포함 | 무료 |
| 알림 | 알람당 $0.10/월 | 포함 | 무료 (Alertmanager) |
4.2 시나리오별 월간 비용 추정
시나리오 A: 소규모 (EC2 10대, AWS 단일 환경)
| 항목 | CloudWatch | Datadog | Grafana + Prometheus |
|---|---|---|---|
| 기본 모니터링 | ~$0 (기본 메트릭 무료) | $150~230 (10호스트 × $15~23) | ~$50 (t3.medium 1대) |
| 커스텀 메트릭 50개 | $15 | 포함 | $0 |
| 로그 50GB/월 | $25 (수집) + $1.5 (저장) | $5 (수집) | ~$5 (EBS 스토리지) |
| 대시보드 3개 | $9 | 포함 | $0 |
| 알람 20개 | $2 | 포함 | $0 |
| 월 합계 | ~$53 | ~$160~240 | ~$55 |
시나리오 B: 중규모 (호스트 50대, 멀티 클라우드, Kubernetes)
| 항목 | CloudWatch | Datadog | Grafana + Prometheus |
|---|---|---|---|
| 기본 모니터링 | ~$0 (AWS 부분만) | $750~1,150 (50호스트) | ~$200 (HA 구성, 3노드) |
| 커스텀 메트릭 500개 | $150 | 추가 과금 가능 | $0 |
| 로그 500GB/월 | $250 + $15 | $50 | ~$30 (S3 저장) |
| APM (10 서비스) | X-Ray ~$50 | $310~400 (APM 추가) | $0 (Jaeger 자체 운영) |
| 대시보드 10개 | $30 | 포함 | $0 |
| 월 합계 | ~$495 (AWS만) | ~$1,200~1,700 | ~$230 |
시나리오 C: 대규모 (호스트 200대, 멀티 클라우드, 마이크로서비스 50개)
| 항목 | CloudWatch | Datadog | Grafana + Prometheus |
|---|---|---|---|
| 기본 모니터링 | 해당 없음 (멀티 클라우드) | $3,000~4,600 | ~$500 (HA + Thanos) |
| APM | 해당 없음 | $1,240~1,600 | $0 |
| 로그 2TB/월 | 해당 없음 | $200 | ~$100 (S3) |
| 월 합계 | 단일 도구로 불가 | ~$4,500~6,500 | ~$600 |
위 가격은 2026년 6월 기준 공개 가격표를 참고한 추정치입니다. Datadog은 연간 계약 시 할인이 적용될 수 있으며, CloudWatch 가격은 리전별로 상이합니다. 정확한 비용은 각 서비스의 공식 Pricing 페이지를 확인해야 합니다.
4.3 비용 관점 핵심 포인트
- CloudWatch: AWS 리소스 기본 메트릭은 무료이므로 소규모 AWS 환경에서 가장 경제적입니다. 다만 커스텀 메트릭과 로그 볼륨이 커지면 비용이 빠르게 증가합니다.
- Datadog: 호스트 단위 과금이 핵심입니다. 호스트 수가 늘어나면 비용이 선형적으로 증가합니다. 컨테이너 환경에서는 컨테이너 5개당 1호스트로 계산되는 등 과금 방식이 복잡합니다.
- Grafana + Prometheus: 라이선스 비용이 없으므로 인프라 비용만 발생합니다. 다만 운영 인력의 인건비를 고려해야 합니다. Prometheus를 안정적으로 운영하려면 스토리지 관리, HA 구성, 업그레이드 등의 작업이 필요합니다.
5. 기능 비교
5.1 메트릭 수집과 쿼리
| 기능 | CloudWatch | Datadog | Grafana + Prometheus |
|---|---|---|---|
| 수집 방식 | Push (PutMetricData API) | Push (Agent → SaaS) | Pull (Prometheus scrape) |
| 쿼리 언어 | CloudWatch Metrics Insights | Datadog Query Language | PromQL |
| 쿼리 유연성 | 제한적 | 중간 | 높음 |
| 수집 간격 | 기본 5분, 상세 1분 | 15초 | 설정 가능 (기본 15초) |
| 보존 기간 | 15개월 (해상도에 따라 다운샘플링) | 15개월 | 설정 가능 (기본 15일, Thanos로 확장) |
| 고카디널리티 지원 | 제한적 (Dimension 30개) | 좋음 | 주의 필요 (메모리 영향) |
PromQL vs CloudWatch Metrics Insights 예시:
# PromQL: 5분간 평균 CPU 사용률이 80% 이상인 인스턴스
avg by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m])) > 0.8
-- CloudWatch Metrics Insights: 비슷한 쿼리
SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId)
WHERE CPUUtilization > 80
GROUP BY InstanceId
PromQL은 시계열 데이터에 특화된 쿼리 언어로, 복잡한 집계와 조건 조합이 가능합니다. CloudWatch Metrics Insights는 SQL 유사 문법으로 접근성은 높지만 표현력이 제한적입니다.
5.2 알림 (Alerting)
| 기능 | CloudWatch | Datadog | Grafana + Prometheus |
|---|---|---|---|
| 알림 조건 | 단일 메트릭 임계값 | 복합 조건, 이상 탐지 | PromQL 기반 복합 조건 |
| 이상 탐지 | 제한적 (Anomaly Detection 있음) | 강점 (ML 기반 자동 탐지) | 제한적 (별도 구성 필요) |
| 알림 채널 | SNS, Lambda, EventBridge | Slack, PagerDuty, 웹훅 등 다수 | Alertmanager (Slack, PagerDuty, 웹훅 등) |
| 알림 그룹핑 | 제한적 | 지원 | Alertmanager에서 지원 |
| 다운타임 설정 | 없음 | 지원 (유지보수 시간 설정) | Alertmanager silence |
| Composite Alarm | 지원 (여러 알람 조합) | 지원 | recording rule + alert rule 조합 |
Datadog의 이상 탐지(Anomaly Detection)는 과거 패턴을 학습하여 "평소와 다른" 상황을 자동으로 감지합니다. 임계값을 수동으로 설정하지 않아도 되므로 운영 부담이 줄어듭니다. 다만 오탐(False Positive)이 발생할 수 있어 초기 튜닝이 필요합니다.
5.3 대시보드와 시각화
| 기능 | CloudWatch | Datadog | Grafana + Prometheus |
|---|---|---|---|
| 대시보드 품질 | 기본적 | 풍부함 | 매우 풍부함 (커뮤니티 대시보드) |
| 템플릿 | AWS 서비스별 기본 제공 | 통합별 자동 생성 | 수천 개의 커뮤니티 대시보드 |
| 커스터마이징 | 제한적 | 중간 | 높음 (패널, 변수, 플러그인) |
| 서비스 맵 | X-Ray Service Map | 자동 생성 | 별도 구성 필요 |
| 다중 데이터소스 | CloudWatch만 | Datadog 내부 데이터만 | 다양한 데이터소스 동시 표시 |
Grafana의 가장 큰 강점은 다중 데이터소스 지원입니다. 하나의 대시보드에서 Prometheus 메트릭, Loki 로그, CloudWatch 데이터, Elasticsearch 로그를 동시에 표시할 수 있습니다. 이는 하이브리드 환경에서 특히 유용합니다.
5.4 로그 관리
| 기능 | CloudWatch Logs | Datadog Logs | Grafana Loki |
|---|---|---|---|
| 수집 방식 | CloudWatch Agent, AWS 서비스 자동 | Datadog Agent | Promtail, Fluentd |
| 인덱싱 | 전체 텍스트 인덱싱 | 전체 텍스트 인덱싱 | 라벨 기반 (본문 미인덱싱) |
| 검색 속도 | 중간 (Log Insights) | 빠름 | 라벨 검색 빠름, 본문 검색 느림 |
| 비용 효율 | 중간 | 높은 편 | 매우 높음 (인덱싱 비용 없음) |
| 쿼리 언어 | CloudWatch Logs Insights | Datadog Log Query | LogQL |
| 라이브 테일 | 지원 | 지원 | 지원 |
Grafana Loki는 "Prometheus for logs"를 표방합니다. 로그 본문을 인덱싱하지 않고 라벨만 인덱싱하므로 저장 비용이 매우 낮습니다. 다만 본문 검색(grep)은 스캔 방식이므로 대량 로그에서는 느릴 수 있습니다.
6. 운영 부담 비교
도구의 기능만큼 중요한 것이 "누가 운영하는가"입니다.
| 항목 | CloudWatch | Datadog | Grafana + Prometheus |
|---|---|---|---|
| 인프라 관리 | AWS 관리 | Datadog 관리 | 직접 관리 |
| 업그레이드 | 자동 | 자동 | 수동 (Helm chart 업그레이드) |
| 스토리지 관리 | 자동 | 자동 | 디스크 용량, 보존 정책 직접 관리 |
| HA 구성 | 기본 제공 | 기본 제공 | 직접 구성 (Thanos/Cortex) |
| 스케일링 | 자동 | 자동 | 수동 (샤딩, 페더레이션) |
| 장애 대응 | AWS 책임 | Datadog 책임 | 팀 책임 |
| 필요 인력 | 0.1 FTE | 0.2 FTE | 0.5~1 FTE |
Prometheus 운영의 현실
Prometheus를 프로덕션에서 운영하려면 다음을 고려해야 합니다:
- 스토리지: 기본 로컬 TSDB는 단일 노드에 저장됩니다. 디스크가 가득 차면 데이터가 유실됩니다. 장기 보존이 필요하면 Thanos나 Cortex를 추가해야 합니다.
- 고가용성: 단일 Prometheus 인스턴스가 죽으면 메트릭 수집이 중단됩니다. HA를 위해 2개 인스턴스를 병렬 운영하고, Thanos로 중복 제거를 해야 합니다.
- 스케일링: 메트릭 수가 수백만 개를 넘으면 단일 Prometheus로는 부족합니다. 샤딩이나 페더레이션을 구성해야 합니다.
- 업그레이드: Prometheus, Grafana, Alertmanager, Thanos 각각의 버전 호환성을 확인하고 업그레이드해야 합니다.
이런 운영 부담을 줄이려면 Grafana Cloud(매니지드 Prometheus + Grafana)를 검토할 수 있습니다. 오픈소스의 유연성을 유지하면서 운영 부담을 줄이는 중간 선택지입니다.
7. 멀티 클라우드와 하이브리드 환경
멀티 클라우드 환경에서 모니터링 도구의 선택은 크게 달라집니다.
| 환경 | CloudWatch | Datadog | Grafana + Prometheus |
|---|---|---|---|
| AWS 단일 | ✅ 최적 | ✅ 가능 | ✅ 가능 |
| Azure 단일 | ❌ 불가 | ✅ 가능 | ✅ 가능 |
| GCP 단일 | ❌ 불가 | ✅ 가능 | ✅ 가능 |
| AWS + Azure | ❌ 부분적 | ✅ 강점 | ✅ 가능 |
| AWS + On-premise | ❌ 제한적 | ✅ 가능 | ✅ 가능 |
| Kubernetes (멀티 클러스터) | ❌ 제한적 | ✅ 가능 | ✅ 강점 |
CloudWatch의 한계
CloudWatch는 AWS 리소스에 최적화되어 있습니다. Azure VM이나 GCP 인스턴스의 메트릭을 CloudWatch로 보내는 것은 기술적으로 가능하지만(커스텀 메트릭 API 사용), 실용적이지 않습니다. 각 클라우드의 네이티브 메트릭을 활용할 수 없고, 비용도 비효율적입니다.
Datadog의 강점
Datadog은 멀티 클라우드 환경에서 가장 빠르게 통합 뷰를 제공합니다. AWS, Azure, GCP 각각의 통합을 활성화하면 모든 클라우드 리소스를 하나의 대시보드에서 확인할 수 있습니다. 서비스 맵도 클라우드 경계를 넘어 자동으로 생성됩니다.
Grafana의 접근 방식
Grafana는 데이터소스를 자유롭게 연결할 수 있으므로, 하나의 대시보드에서 CloudWatch + Azure Monitor + GCP Cloud Monitoring 데이터를 동시에 표시할 수 있습니다. 다만 각 클라우드의 메트릭 체계가 다르므로 대시보드 설계에 노력이 필요합니다.
Kubernetes 환경에서는 Prometheus가 클러스터 내부 메트릭을 수집하고, Thanos로 멀티 클러스터 메트릭을 통합하는 구조가 일반적입니다.
8. 실무 시나리오별 선택 가이드
시나리오 1: 스타트업, AWS 단일 환경, 엔지니어 3명
상황: - EC2 5대 + RDS 1대 + Lambda 10개 - 전담 DevOps/SRE 인력 없음 - 월 모니터링 예산 $100 이하
권장: CloudWatch
이유: - 추가 설정 없이 AWS 리소스 메트릭이 자동 수집됩니다. - 별도 인프라를 운영할 인력이 없습니다. - 비용이 가장 낮습니다. - Lambda, RDS 등 AWS 서비스와의 통합이 자연스럽습니다.
주의점: - CloudWatch 대시보드의 시각화 품질은 Grafana나 Datadog에 비해 제한적입니다. - 나중에 멀티 클라우드로 확장할 때 도구 전환이 필요할 수 있습니다.
시나리오 2: 중견 기업, 멀티 클라우드, 빠른 도입 필요
상황: - AWS + Azure 하이브리드 환경 - 마이크로서비스 20개, 호스트 40대 - 3개월 내 모니터링 체계 구축 필요 - DevOps 팀 5명, Prometheus 운영 경험 없음
권장: Datadog
이유: - 에이전트 설치만으로 빠르게 데이터 수집을 시작할 수 있습니다. - AWS와 Azure를 하나의 대시보드에서 관리할 수 있습니다. - APM, 로그, 트레이싱까지 하나의 플랫폼에서 해결됩니다. - Prometheus를 직접 운영할 인력과 시간이 부족합니다.
주의점: - 월 비용이 $1,000~2,000 수준으로 예상됩니다. - 호스트 수가 늘어나면 비용이 선형적으로 증가합니다. - 연간 계약을 하면 할인이 있지만, 축소 시 유연성이 떨어집니다.
시나리오 3: Kubernetes 중심, 비용 민감, SRE 팀 보유
상황: - EKS/GKE 클러스터 3개, Pod 200개 이상 - SRE 팀 3명 (Prometheus/Grafana 경험 있음) - 월 모니터링 비용을 $500 이하로 유지해야 함 - 커스텀 메트릭과 대시보드 요구사항이 많음
권장: Grafana + Prometheus (+ Loki + Tempo)
이유: - Kubernetes 환경에서 Prometheus는 사실상 표준입니다. ServiceMonitor, PodMonitor로 자동 디스커버리가 가능합니다. - 라이선스 비용이 없으므로 대규모 환경에서도 비용이 낮습니다. - PromQL로 복잡한 쿼리와 알림 조건을 자유롭게 작성할 수 있습니다. - Loki(로그)와 Tempo(트레이싱)를 추가하면 전체 Observability 스택을 구성할 수 있습니다.
주의점: - Prometheus HA, Thanos 구성, 스토리지 관리 등 운영 부담이 있습니다. - 팀에 PromQL과 Kubernetes 운영 경험이 필요합니다. - 초기 구축에 2~4주가 소요될 수 있습니다.
9. 의사결정 플로우
도구 선택 시 다음 순서로 판단합니다:
1. 인프라 환경은?
│
├── AWS 단일 환경
│ ├── 팀 규모 5명 이하, 전담 DevOps 없음
│ │ └── CloudWatch (운영 부담 최소)
│ └── 팀 규모 크고, 커스터마이징 필요
│ └── Grafana + Prometheus 또는 Datadog
│
├── 멀티 클라우드 (AWS + Azure/GCP)
│ ├── 빠른 도입 필요, 예산 여유 있음
│ │ └── Datadog (통합 플랫폼)
│ └── 비용 민감, 운영 인력 있음
│ └── Grafana + Prometheus
│
└── Kubernetes 중심
├── SRE/DevOps 팀 있음, PromQL 가능
│ └── Grafana + Prometheus (네이티브 통합)
└── Kubernetes 운영 경험 부족
└── Datadog (자동 계측, 빠른 시작)
2. 추가 고려사항
├── 데이터 주권 요구사항 → Prometheus (데이터가 내부에 저장)
├── 컴플라이언스 감사 → CloudWatch (AWS 내부) 또는 Prometheus
├── APM/Tracing 필요 → Datadog (통합) 또는 Jaeger/Tempo (자체 운영)
└── 기존 도구 마이그레이션 → Grafana (다중 데이터소스로 점진적 전환)
10. 조합 전략: 하나만 쓸 필요는 없다
실무에서는 하나의 도구만 사용하는 경우보다, 여러 도구를 조합하는 경우가 많습니다.
조합 1: CloudWatch + Grafana
AWS 환경에서 CloudWatch로 데이터를 수집하되, 시각화는 Grafana로 하는 구조입니다.
- CloudWatch를 Grafana의 데이터소스로 연결합니다.
- CloudWatch의 자동 수집 + Grafana의 풍부한 시각화를 조합합니다.
- 추가 인프라 없이 대시보드 품질을 높일 수 있습니다.
- Grafana Cloud를 사용하면 Grafana 자체도 운영할 필요가 없습니다.
조합 2: Prometheus + CloudWatch Exporter
Kubernetes 내부는 Prometheus로, AWS 매니지드 서비스(RDS, ElastiCache 등)는 CloudWatch에서 수집하는 구조입니다.
cloudwatch-exporter를 사용하면 CloudWatch 메트릭을 Prometheus 형식으로 변환할 수 있습니다.- Grafana에서 두 데이터소스를 하나의 대시보드에 표시합니다.
- Kubernetes Pod 메트릭과 RDS 메트릭을 같은 화면에서 상관 분석할 수 있습니다.
조합 3: Datadog + Prometheus (마이그레이션 과도기)
기존 Prometheus 환경에서 Datadog으로 전환하는 과도기에 사용하는 구조입니다.
- Datadog Agent가 Prometheus 메트릭 엔드포인트를 스크래핑할 수 있습니다.
- 기존 Prometheus 계측을 유지하면서 Datadog의 기능을 활용할 수 있습니다.
- 점진적 전환이 가능합니다.
OpenTelemetry로 계측해두면 백엔드를 자유롭게 교체할 수 있습니다. 지금 CloudWatch를 쓰다가 나중에 Datadog이나 Grafana로 전환할 때 애플리케이션 코드를 수정할 필요가 없습니다.
11. 벤더 종속과 전환 비용
도구를 선택할 때 "나중에 바꿀 수 있는가"도 중요한 판단 기준입니다.
| 항목 | CloudWatch | Datadog | Grafana + Prometheus |
|---|---|---|---|
| 데이터 내보내기 | 제한적 (API로 추출 가능) | API로 추출 가능 | 로컬 저장, 자유로운 접근 |
| 대시보드 이식성 | 낮음 (CloudWatch 전용) | 중간 (JSON 내보내기) | 높음 (JSON, 커뮤니티 공유) |
| 알림 규칙 이식성 | 낮음 | 낮음 | 높음 (YAML 기반, GitOps 가능) |
| 계측 코드 종속 | AWS SDK 의존 | Datadog SDK/Agent 의존 | OTel 표준 사용 시 종속 없음 |
| 전환 난이도 | 중간 | 높음 (통합 플랫폼이므로) | 낮음 (표준 기반) |
전환 비용을 줄이는 전략
- 계측은 OpenTelemetry로 통일: 어떤 백엔드를 쓰든 계측 코드는 OTel SDK를 사용합니다. 백엔드만 교체하면 됩니다.
- 대시보드를 코드로 관리: Grafana 대시보드는 JSON으로 관리하고, Terraform이나 Grafonnet으로 버전 관리합니다.
- 알림 규칙을 코드로 관리: Prometheus alerting rules는 YAML 파일로 관리하고 Git에 저장합니다.
- 데이터 보존 정책 분리: 핫 데이터(최근 7일)와 콜드 데이터(장기 보존)를 분리하면 도구 전환 시 영향을 최소화할 수 있습니다.
Datadog 같은 외부 SaaS를 사용할 때는 어떤 데이터가 외부로 전송되는지 확인해야 합니다. 메트릭 라벨에 내부 IP, 호스트명, 서비스 구조가 포함될 수 있습니다. 보안 요구사항이 높은 환경에서는 데이터가 내부에 저장되는 Prometheus가 적합할 수 있습니다.
12. 자주 하는 실수
1. 기능만 보고 Datadog을 선택한 후 비용에 놀라는 경우
Datadog은 기능이 풍부하지만, 호스트 수 × 기능별 과금이 누적됩니다. Infrastructure + APM + Logs를 모두 활성화하면 호스트당 월 $50~80이 될 수 있습니다. 50대면 월 $2,500~4,000입니다. 도입 전에 반드시 비용 시뮬레이션을 해야 합니다.
2. "무료니까" Prometheus를 선택한 후 운영에 지치는 경우
Prometheus는 라이선스 비용이 없지만, 운영 비용(인력)이 발생합니다. 디스크 관리, HA 구성, 업그레이드, 장애 대응을 직접 해야 합니다. 전담 인력 없이 Prometheus를 운영하면 모니터링 시스템 자체가 장애 포인트가 될 수 있습니다.
3. CloudWatch만으로 모든 것을 해결하려는 경우
AWS 환경에서 CloudWatch는 편리하지만, 복잡한 쿼리, 서비스 간 상관 분석, 커스텀 대시보드에서 한계가 있습니다. 서비스가 성장하면 CloudWatch만으로는 부족해지는 시점이 옵니다. 이때 Grafana를 CloudWatch 위에 얹는 것이 자연스러운 확장 경로입니다.
4. 도구를 먼저 선택하고 요구사항을 맞추는 경우
"우리 팀은 Datadog을 쓰기로 했다"가 아니라, "우리 팀의 요구사항은 X이고, 이를 충족하는 도구는 Y이다"가 올바른 순서입니다. 요구사항을 먼저 정의하세요: - 어떤 메트릭을 수집해야 하는가? - 알림은 누가, 어떻게 받아야 하는가? - 로그와 트레이스도 필요한가? - 예산은 얼마인가? - 운영할 인력은 있는가?
5. 마이그레이션 계획 없이 도입하는 경우
모니터링 도구는 한번 도입하면 대시보드, 알림 규칙, 팀 워크플로우가 모두 해당 도구에 맞춰집니다. 나중에 전환하려면 이 모든 것을 다시 만들어야 합니다. 도입 시점에 "3년 후에도 이 도구가 적합한가"를 고려해야 합니다.
13. 정리
- CloudWatch는 AWS 단일 환경에서 가장 낮은 운영 부담과 비용으로 시작할 수 있습니다. 다만 멀티 클라우드 확장이나 고급 시각화에는 한계가 있습니다.
- Datadog은 멀티 클라우드 환경에서 빠르게 통합 Observability를 구축할 때 적합합니다. 다만 규모가 커지면 비용이 급증하므로 사전 비용 시뮬레이션이 필수입니다.
- Grafana + Prometheus는 Kubernetes 환경에서 가장 유연하고 비용 효율적입니다. 다만 운영 인력과 기술 역량이 필요합니다.
- 하나의 도구만 고집할 필요는 없습니다. CloudWatch + Grafana, Prometheus + CloudWatch Exporter 같은 조합이 실무에서 흔합니다.
- OpenTelemetry로 계측을 표준화하면 도구 전환 비용을 줄일 수 있습니다.
- 도구 선택의 핵심 기준은 기능이 아니라 비용, 운영 부담, 팀 역량, 인프라 환경입니다.
관련 글
참고 문서
'Observability' 카테고리의 다른 글
| OpenTelemetry란 무엇인가: 분산 트레이싱 기본 개념 (0) | 2026.06.08 |
|---|---|
| 알림 설계: 노이즈를 줄이고 의미 있는 알림만 받는 방법 (0) | 2026.06.07 |
| Prometheus + Grafana로 Kubernetes 모니터링 구성하기 (0) | 2026.06.06 |
| Observability란 무엇인가: Monitoring, Logging, Tracing의 차이 (0) | 2026.05.31 |
