Prometheus vs Grafana vs Datadog 2026: 모니터링 아키텍처 비교와 DevOps 면접 핵심 질문

Prometheus, Grafana, Datadog는 DevOps 기술 면접에서 가장 빈번하게 비교 분석을 요구받는 모니터링 도구입니다. 각 도구의 아키텍처적 차이와 트레이드오프를 명확하게 설명할 수 있는 능력은 실무 경험의 깊이를 증명하는 핵심 지표로 평가됩니다. 2026년 현재, Prometheus 3.x의 안정화, Grafana 13의 Observability-as-Code 기능, Datadog의 ML 기반 이상 탐지 고도화로 인해 세 도구 간의 경계와 역할 분담이 더욱 명확해졌습니다. 이 글에서는 아키텍처, 쿼리 언어, 알림 전략, 비용 구조, Kubernetes 통합, OpenTelemetry 호환성을 체계적으로 비교하고, devops monitoring 면접에서 실제로 출제되는 observability interview 질문과 답변을 정리합니다.

아키텍처와 데이터 모델: 메트릭 처리 방식의 근본적 차이

세 도구 간의 아키텍처 차이는 가장 기본적이면서도 깊은 이해를 요구하는 영역입니다. grafana interview questions에서도 데이터 소스 연결 구조에 대한 질문이 빈번하게 출제됩니다.

Prometheus는 Pull 기반 모델을 채택하고 있습니다. 설정된 주기마다 대상 서비스의 HTTP 엔드포인트(일반적으로 /metrics)를 스크레이핑하여 시계열 데이터를 수집하고, 자체 TSDB(Time Series Database)에 저장합니다. 각 시계열은 메트릭 이름과 키-값 레이블 조합으로 고유하게 식별됩니다. 2024년 11월 출시된 Prometheus 3.0 이후, v3.8에서 네이티브 히스토그램이 안정화되었고, OTLP 수집이 내장되었으며, Remote Write 2.0으로 클러스터 간 페더레이션이 개선되었습니다.

Grafana는 메트릭을 수집하거나 저장하지 않습니다. Prometheus, Loki, Tempo, InfluxDB, Elasticsearch 등 100개 이상의 데이터 소스에 연결하여 대시보드를 렌더링하는 시각화 계층입니다. Grafana Labs는 Mimir(장기 메트릭 저장소), Loki(로그 집계), Tempo(분산 트레이싱)를 함께 유지관리하여 완전한 오픈소스 옵저버빌리티 스택을 구성합니다. 2026년 5월 출시된 버전 13에서는 Observability-as-Code 도구, 대시보드 Git Sync, 크로스 소스 쿼리를 위한 SQL Expressions가 도입되었습니다.

Datadog는 Push 기반 SaaS로 운영됩니다. 호스트에 설치된 에이전트가 메트릭, 로그, 트레이스를 Datadog 클라우드 백엔드로 전송합니다. 수집, 저장, 쿼리, 알림, 대시보드가 하나의 관리형 플랫폼 안에서 처리됩니다. Watchdog ML 엔진은 수동 임계값 설정 없이 자동으로 이상 탐지를 수행합니다.

# prometheus.yml - Pull-based scrape configuration
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'api-server'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: (.+)
        replacement: ${1}:${2}

이 YAML 구성은 Prometheus의 Pull 모델을 정의합니다. Kubernetes 서비스 디스커버리를 통해 Pod를 자동 감지하고, 15초 간격으로 /metrics 엔드포인트를 스크레이핑합니다. relabel_configs는 Pod 어노테이션 기반으로 스크레이핑 대상을 필터링하고 포트를 동적으로 설정하는 핵심 메커니즘입니다.

PromQL vs Datadog 쿼리 언어: 구문과 표현력 비교

쿼리 언어는 prometheus interview에서 실무 능력을 직접 검증하는 영역입니다. 최소 하나의 쿼리 언어에 대한 유창함을 보여주면서 양쪽의 트레이드오프를 설명할 수 있어야 합니다.

PromQL(Prometheus Query Language)은 Prometheus 및 Grafana 생태계 전반의 메트릭 쿼리 표준입니다. 인스턴트 벡터, 레인지 벡터, 집계 연산자, 레코딩 규칙을 지원합니다.

# Request rate per service over 5 minutes
rate(http_requests_total{job="api-server"}[5m])

# 99th percentile latency using native histograms
histogram_quantile(0.99, rate(http_request_duration_seconds[5m]))

# Error rate as percentage
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m])) * 100

# Predict disk full in 4 hours using linear regression
predict_linear(node_filesystem_avail_bytes[1h], 4 * 3600) < 0

Datadog 쿼리 언어는 함수와 스코핑 중심의 다른 구문 체계를 사용합니다.

# Equivalent request rate in Datadog
sum:http.requests{service:api-server}.as_rate()

# Anomaly detection (Watchdog ML - no equivalent in PromQL)
anomaly(avg:system.cpu.user{service:api-server}, 'agile', 3)

# Forecast query
forecast(avg:system.disk.free{host:web-01}, 'linear', 1)

PromQL은 애드혹 분석에서 더 깊은 표현력을 제공합니다. histogram_quantile, predict_linear 등 통계 함수를 자유롭게 조합할 수 있습니다. 반면 Datadog의 쿼리 언어는 일부 유연성을 포기하는 대신 anomaly()와 forecast() 같은 내장 ML 함수를 제공하여, Prometheus 스택에서는 외부 도구가 필요한 기능을 별도 설정 없이 사용할 수 있습니다.

알림 전략: 규칙 기반 vs ML 기반 탐지

알림 설계 철학은 세 도구 간에 뚜렷한 차이를 보이며, 이 차이를 이해하는 것은 observability interview에서 운영 성숙도를 증명하는 핵심 요소입니다.

Prometheus Alertmanager는 고정 주기로 규칙을 평가하고, 그룹핑, 사일런싱, 인히비션이 적용되는 구성 가능한 파이프라인을 통해 알림을 라우팅합니다.

# alert-rules.yml - Prometheus alerting rules
groups:
  - name: api-server-alerts
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5..",job="api-server"}[5m]))
          / sum(rate(http_requests_total{job="api-server"}[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "API error rate above 5% for 5 minutes"
          runbook: "https://wiki.internal/runbooks/high-error-rate"

      - alert: PodMemoryPressure
        expr: |
          container_memory_working_set_bytes{namespace="production"}
          / container_spec_memory_limit_bytes{namespace="production"} > 0.9
        for: 10m
        labels:
          severity: warning

이 접근 방식은 운영자가 명시적 임계값을 정의해야 합니다. 장점은 완전한 투명성에 있습니다. 모든 알림에는 리뷰 가능한 표현식이 존재합니다. 단점은 임계값 피로 현상입니다. 정적 값은 시즌별, 트래픽 패턴별로 조정이 필요한 경우가 많습니다.

Grafana Alerting(버전 12 이후 통합)은 연결된 모든 데이터 소스에 걸쳐 쿼리를 평가하고, 다차원 알림과 알림 정책을 지원합니다. 여러 데이터 소스의 조건을 단일 알림 규칙에서 결합할 수 있다는 점이 Prometheus 단독 사용 대비 강점입니다.

Datadog Monitors는 정적 임계값과 ML 기반 이상/이탈/예측 모니터를 결합합니다. Watchdog는 수동 규칙 생성 없이 성능 이상을 자동으로 감지합니다. 설정 부담이 감소하는 대신 탐지 로직의 투명성이 낮아지는 트레이드오프가 존재합니다.

2026년 가격 정책과 총소유비용(TCO) 비교

가격 구조는 실제 도구 선택의 결정적 요인이며, 시스템 설계 면접에서도 빈번하게 다루어집니다. 비용 구조에 대한 이해는 비즈니스 감각을 보여주는 지표입니다.

| 비교 항목 | Prometheus + Grafana | Datadog | |-----------|---------------------|--------| | 라이선스 | 무료 (AGPL / Apache 2.0) | 호스트당 월 $15-31 (연간 계약) | | 메트릭 저장소 | 자체 관리 (Mimir/Thanos) | 포함, 보존 기간 기반 과금 | | 로그 관리 | Loki (자체 호스팅) | 수집 GB당 $0.10 + 인덱싱 비용 | | APM / 트레이스 | Tempo (자체 호스팅) | 호스트당 월 $31 | | 인프라 비용 | 스택 운영을 위한 컴퓨팅 + 스토리지 | 없음 (SaaS) | | 운영 오버헤드 | 높음 (업그레이드, 스케일링, HA 구성) | 최소 | | 연간 비용 추정 (50호스트) | $20K-60K (인프라 + 엔지니어링) | $50K-150K | | 벤더 종속 위험 | 낮음 (OpenTelemetry, PromQL 표준) | 높음 (독자적 쿼리 언어) |

오픈소스 스택은 서류상 비용이 낮아 보이지만, 업그레이드, 용량 계획, 고가용성 구성에 전담 엔지니어링 시간이 필요합니다. Datadog의 관리형 모델은 이 부담을 벤더로 이전합니다. 인프라를 운영하는 엔지니어가 5명 미만인 팀에서는 엔지니어링 시간을 비용에 포함할 경우 관리형 솔루션의 총소유비용이 더 낮은 경우가 많습니다.

Kubernetes 모니터링: 통합 깊이 비교

Kubernetes 클러스터의 80% 이상이 메트릭 수집에 Prometheus를 사용하고 있어, 컨테이너 오케스트레이션 모니터링에서 가장 중요한 면접 주제입니다.

Prometheus + Grafana는 kube-prometheus-stack Helm 차트를 통해 Kubernetes와 네이티브 통합됩니다. Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics, 사전 구성된 Grafana 대시보드를 단일 설치로 배포합니다.

# Deploy full monitoring stack on Kubernetes
helm repo add prometheus-community \
  https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi

이 명령은 영구 스토리지와 30일 보존 기간이 설정된 프로덕션급 모니터링 스택을 배포합니다. Prometheus Operator는 Custom Resource Definitions(ServiceMonitor, PodMonitor)를 사용하여 스크레이핑 대상을 선언적으로 구성합니다. 새로운 서비스를 배포할 때 ServiceMonitor CRD만 함께 배포하면 자동으로 모니터링 대상에 포함됩니다.

Datadog는 에이전트 DaemonSet과 Cluster Agent를 배포합니다. Cluster Agent가 API 서버 통신을 중앙에서 처리하여 Kubernetes API에 대한 부하를 줄입니다. Live Containers 뷰는 Pod 상태의 실시간 가시성을 제공하고, Orchestrator Explorer는 Deployment, Service, Pod 간의 관계를 시각적으로 매핑합니다.

Kubernetes 생태계에 이미 투자한 팀에게는 Prometheus 네이티브 접근 방식이 외부 의존성 도입을 피할 수 있는 장점이 있습니다. 운영 투자를 최소화하면서 빠른 설정을 우선시하는 팀은 Datadog을 선호하는 경향이 있습니다.

OpenTelemetry와 벤더 중립성

OpenTelemetry(OTel)는 계측 분야의 산업 표준으로 자리잡았으며, devops monitoring 면접에서 모니터링 도구 비교와 함께 질문되는 빈도가 증가하고 있습니다.

Prometheus 3.0 이후 버전은 OTLP 메트릭을 네이티브로 수신합니다. 중간에 Collector를 배치할 필요가 없습니다. Grafana Alloy(Grafana Agent의 후속)는 OTel Collector와 Prometheus 스크레이퍼 역할을 동시에 수행합니다. Datadog은 OTLP 수집을 지원하지만 "모든 기능에 완전히 접근하려면" 독자적 에이전트 사용을 권장하여 연성 종속(soft lock-in)을 형성합니다.

OTel 도입이 중요한 이유는 계측과 백엔드 선택을 분리하기 때문입니다. OTel SDK로 계측된 애플리케이션 코드는 코드 변경 없이 Prometheus, Grafana Cloud, Datadog, 또는 호환 가능한 모든 백엔드로 텔레메트리를 전송할 수 있습니다. 시스템 설계 면접에서 장기적 옵저버빌리티 전략을 논의할 때 이러한 유연성은 강력한 근거가 됩니다.

DevOps 모니터링 및 옵저버빌리티 면접 질문

다음 질문들은 DevOps 및 SRE 면접에서 반복적으로 출제됩니다. 각 답변은 면접관이 검증하고자 하는 핵심 개념을 중심으로 구성되었습니다.

"모니터링(Monitoring), 옵저버빌리티(Observability), 알림(Alerting)의 차이를 설명하십시오."

모니터링은 사전 정의된 메트릭을 추적하고 알려진 장애 모드를 점검합니다. 옵저버빌리티는 메트릭, 로그, 트레이스("세 기둥")를 통해 사전에 예상하지 못한 장애 모드를 조사할 수 있게 합니다. 알림은 조건이 정의된 임계값이나 이상 탐지 기준선을 초과할 때 알림을 발생시킵니다. 모니터링은 "시스템이 정상인가?"에 답하고, 옵저버빌리티는 "왜 시스템이 비정상인가?"에 답합니다.

"Prometheus가 적합하지 않은 모니터링 시나리오는 무엇입니까?"

Prometheus는 내구성(durability)보다 신뢰성(reliability)에 최적화되어 있습니다. 모니터링 시스템 자체의 가용성을 우선합니다. Prometheus가 어려움을 겪는 시나리오는 다음과 같습니다. 30일을 초과하는 장기 저장(Thanos/Mimir/Cortex가 필요), 100% 정확도가 요구되는 건당 과금 데이터(부하 상태에서 샘플 손실 가능), Push 기반 수집이 필요한 이벤트 기반 시스템(pushgateway가 우회 방안으로 존재)이 해당됩니다.

"Grafana의 'Big Tent' 철학이 옵저버빌리티 아키텍처에 미치는 영향은 무엇입니까?"

Grafana는 데이터 마이그레이션 없이 모든 데이터 소스에 연결합니다. Prometheus, Elasticsearch, CloudWatch, Datadog을 단일 대시보드에서 쿼리할 수 있다는 의미입니다. 트레이드오프는 운영 복잡성입니다. 여러 백엔드를 유지하려면 단일 벤더 접근 방식보다 더 많은 인프라 전문 지식이 필요합니다. 면접관은 지원자가 이 트레이드오프를 명확히 표현할 수 있는지 평가합니다.

"Datadog의 High-Watermark 과금 방식은 무엇이며, 왜 중요합니까?"

Datadog는 시간 단위로 호스트 수를 측정하고, 상위 1%를 제외한 99번째 백분위수 피크를 기준으로 과금합니다. 블랙 프라이데이 트래픽 같은 일시적 오토스케일링 급증이 인스턴스 종료 후에도 월 청구액을 상승시킨다는 의미입니다. 이 사항을 언급할 수 있는 지원자는 SRE 역할에서 점점 더 요구되는 비용 관리에 대한 실무 경험을 보여줍니다.

"Prometheus와 Datadog에서 SLO 기반 알림 전략은 어떻게 다릅니까?"

Prometheus에서 SLO 알림은 레코딩 규칙으로 에러 버짓과 번 레이트 알림을 사전 계산합니다(Google SRE 책의 멀티 윈도우, 멀티 번 레이트 접근 방식). Datadog는 번 레이트를 자동으로 추적하는 내장 SLO 위젯과 모니터를 제공합니다. 두 접근 방식 모두 동일한 개념을 구현하지만, Prometheus는 더 많은 수동 설정이 필요하고 Datadog는 관리형 워크플로를 제공합니다. 지원자는 번 레이트 윈도우(1시간, 6시간, 3일)와 에러 버짓 소비율을 답변에 포함해야 합니다.

모니터링 주제에 대한 심화 학습은 DevOps 모니터링 면접 모듈에서 추가 시나리오와 상세한 해설을 제공합니다.

의사결정 프레임워크: 올바른 스택 선택 기준

| 시나리오 | 권장 스택 | 근거 | |----------|----------|------| | 스타트업, 엔지니어 10명 미만 | Datadog 또는 Grafana Cloud | 운영 오버헤드 최소화 | | 플랫폼 팀을 보유한 대규모 조직 | Prometheus + Grafana + Loki | 완전한 제어, 규모에서의 낮은 단위 비용 | | 멀티클라우드 / 하이브리드 | Prometheus + Grafana | 벤더 중립, 환경 간 일관성 | | 컴플라이언스 중심 (금융, 의료) | 자체 호스팅 Prometheus + Grafana | 데이터가 사내에 유지 | | 급격한 스케일링, 예측 불가능한 성장 | Grafana Cloud (관리형 Mimir) | 인프라 관리 없이 확장 | | ML 기반 이상 탐지 필요 | Datadog | Watchdog는 설정 없이 작동 |

올바른 선택은 팀 규모, 운영 성숙도, 예산 제약의 세 가지 변수에 의해 결정됩니다. 보편적으로 올바른 답은 존재하지 않으며, 면접관은 지원자가 승자를 선언하기보다 트레이드오프를 논리적으로 추론하는 역량을 기대합니다. DevOps 필수 면접 질문 모음에서 모니터링 외 영역의 면접 준비를 병행할 수 있으며, CI/CD 파이프라인 면접 대비에서 인접 주제를 강화할 수 있습니다.

결론

• Prometheus는 Kubernetes 환경의 메트릭 수집 표준이며, 2026년 3.x 버전에서 네이티브 OTLP 지원과 안정화된 네이티브 히스토그램을 제공합니다
• Grafana는 메트릭 데이터베이스가 아닌 시각화 계층이며, 100개 이상의 데이터 소스에 연결됩니다. LGTM 스택(Loki, Grafana, Tempo, Mimir)은 완전한 오픈소스 옵저버빌리티 플랫폼을 구성합니다
• Datadog는 ML 기반 알림과 함께 풀스택 옵저버빌리티로의 가장 빠른 경로를 제공하지만, 높은 가격과 벤더 종속이라는 대가가 따릅니다
• OpenTelemetry 도입은 백엔드 선택의 영구성을 줄입니다. 어떤 도구가 데이터를 저장하고 쿼리하든 계측 코드는 동일하게 유지됩니다
• 면접에서는 단일 도구를 옹호하기보다 비용, 제어, 복잡성 간의 트레이드오프를 논리적으로 추론하는 능력을 보여주어야 합니다
• 실전 면접 준비를 위해 DevOps 모니터링 면접 모듈에서 추가 시나리오와 상세 해설을 학습할 수 있습니다