Prometheus 면접 질문 2026: Prometheus vs Grafana vs Datadog 모니터링 비교

Prometheus 면접 질문은 거의 모든 DevOps 및 SRE 면접에서 등장하며, 대개 "왜 Grafana나 Datadog이 아닌가?"라는 질문이 뒤따릅니다. 지원자는 Prometheus가 메트릭을 스크레이핑하고 저장하는 방식을 설명하고, 올바른 PromQL을 작성하며, 관리형 플랫폼과의 트레이드오프를 논증할 수 있어야 합니다. 면접관은 이 주제로 실제 운영 경험과 교과서적 지식을 구분합니다. 같은 주제는 Prometheus 및 모니터링 면접 모듈에서 연습 문제로 제공됩니다.

DevOps 및 SRE 면접에서 나오는 Prometheus 질문

다음은 가장 자주 출제되는 Prometheus 관련 질문과, 자신 있는 지원자가 내놓는 답변입니다. Prometheus 3.x를 기준으로 하며, 현재 안정 버전은 3.15(2026년 9월)이고 3.16은 릴리스 후보 단계입니다.

"Prometheus는 왜 푸시를 받지 않고 메트릭을 풀(pull) 방식으로 수집합니까?"

Pull 방식은 대상의 상태를 관측 가능하게 만듭니다. 스크레이핑할 때마다 up 시계열이 생성되므로, 중단된 대상은 침묵이 아니라 up == 0으로 드러납니다. 스크레이핑 주기는 서버가 제어하므로 비정상적으로 동작하는 클라이언트로부터 서버를 보호할 수 있고, 대상의 /metrics 엔드포인트를 브라우저로 열어 직접 확인할 수도 있습니다. 대가는 Prometheus가 네트워크를 통해 모든 대상에 도달할 수 있어야 한다는 점입니다. 수명이 짧은 배치 작업에 Pushgateway가 필요하고, 네트워크를 넘나드는 구성에서 remote write를 사용하는 이유가 여기에 있습니다.

"네 가지 메트릭 유형은 무엇이며, Summary가 잘못된 선택이 되는 경우는 언제입니까?"

Counter(증가만 하며 재시작 시 초기화), Gauge(증가와 감소 모두 가능), Histogram(관측값을 버킷별로 집계), Summary(클라이언트에서 분위수를 계산)입니다. Summary의 분위수는 집계할 수 없습니다. Pod 10개의 p99를 평균해도 서비스 전체의 p99가 되지 않습니다. Histogram은 먼저 인스턴스 간에 합산한 뒤 서버에서 분위수로 변환할 수 있으므로, 지연 시간 측정의 기본 선택입니다.

# Classic histogram: aggregate the buckets, keep the le label
histogram_quantile(0.99,
  sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))

# Native histogram: no _bucket suffix, no le label
histogram_quantile(0.99,
  sum by (job) (rate(http_request_duration_seconds[5m])))

클래식 형식에서 by 절에 le를 빠뜨리는 것은 라이브 코딩에서 가장 흔한 PromQL 실수입니다. 쿼리가 쓸모 있는 결과를 반환하지 않습니다.

"rate(), irate(), increase()의 차이는 무엇입니까?"

rate()는 범위 전체에 대한 초당 평균을 반환하며 카운터 초기화를 처리합니다. irate()는 범위 안의 마지막 두 샘플만 사용하므로 반응이 빠르지만 노이즈가 많습니다. 확대한 그래프에는 적합하지만 알림에는 부적합합니다. increase()는 rate()에 범위 길이를 곱한 값입니다. Prometheus가 윈도우 경계까지 외삽하기 때문에 정수 카운터에 대한 increase()가 정수가 아닌 값을 반환할 수 있으며, 면접관은 그 이유를 자주 묻습니다.

"카디널리티란 무엇이며, 카디널리티 폭발은 어떻게 진단합니까?"

메트릭 이름과 레이블 값의 고유한 조합마다 별도의 시계열이 메모리에 유지됩니다. user_id, email, ID가 포함된 원시 URL 경로 같은 레이블은 시계열 수를 계속 늘려 결국 서버의 메모리를 고갈시킵니다. 진단은 TSDB 상태 페이지(/tsdb-status)나 다음 쿼리로 시작합니다.

# Top 10 metric names by number of series
topk(10, count by (__name__) ({__name__=~".+"}))

해결은 소스에서 합니다. metric_relabel_configs로 해당 레이블을 삭제하거나 다시 쓰고, 스크레이핑 작업에 sample_limit을 설정하여 잘못된 배포 하나가 서버 전체를 중단시키지 못하게 합니다.

"레코딩 규칙은 무엇을 위한 것입니까?"

비용이 큰 표현식을 평가 주기마다 미리 계산하고, 그 결과를 새로운 시계열로 저장합니다. 대시보드와 알림은 미리 계산된 가벼운 시계열을 쿼리합니다. 명명 규칙은 level:metric:operations입니다.

groups:
  - name: api-recording-rules
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

"알림 규칙의 for 절은 어떤 역할을 합니까?"

표현식이 참이 된 알림은 inactive에서 pending으로 전환되고, 조건이 for 기간 동안 계속 유지되어야 firing에 도달합니다. 이를 통해 스크레이핑 한 번에 그치는 일시적 변동을 걸러냅니다. keep_firing_for는 반대 역할을 합니다. 조건이 해소된 뒤에도 일정 시간 동안 알림을 발생 상태로 유지하여, 플래핑하는 알림이 담당자를 두 번 호출하는 것을 막습니다.

"Prometheus의 고가용성은 어떻게 구성합니까?"

같은 대상을 스크레이핑하는 동일한 레플리카 두 개를 실행하고, 각각에 서로 다른 replica 외부 레이블을 부여합니다. 두 레플리카 모두 Alertmanager 클러스터로 알림을 보내며, Alertmanager는 가십 프로토콜로 알림을 중복 제거합니다. 쿼리 측에서는 Thanos Query나 Mimir가 replica 레이블을 무시하여 두 시계열을 중복 제거합니다. Prometheus 자체에는 클러스터링 기능이 없으며, 단일 서버의 로컬 TSDB는 복제되지 않습니다.

"멀티 클러스터 구성에서는 페더레이션과 remote write 중 무엇을 사용합니까?"

페더레이션은 글로벌 Prometheus가 각 클러스터 Prometheus의 /federate 엔드포인트에서 선택한 시계열(대개 집계된 시계열)을 스크레이핑하는 방식입니다. 소수의 롤업에 적합합니다. remote write는 모든 샘플을 Mimir, Thanos Receive, 벤더 백엔드 같은 중앙 저장소로 스트리밍하며, 글로벌 쿼리와 장기 보존을 위한 표준 답변입니다.

"서비스 디스커버리에서 사라진 대상은 어떻게 감지합니까?"

up == 0은 대상이 여전히 디스커버리되는 동안에만 발생합니다. Pod나 서비스 디스커버리 항목이 사라지면 시계열 자체가 존재하지 않게 되어 알림이 발생하지 않습니다. 이 경우는 absent(up{job="api-server"})로 감지합니다.

"Prometheus 3에서는 무엇이 바뀌었습니까?"

Prometheus 3.0(2024년 11월)은 새로운 UI를 도입하고, 메트릭 이름과 레이블 이름에 UTF-8 문자를 허용했으며, /api/v1/otlp/v1/metrics에 내장 OTLP 수신기를 추가했습니다(--web.enable-otlp-receiver로 활성화). 네이티브 히스토그램은 3.8에서 안정화되었습니다. 3.9부터는 기존 기능 플래그가 아무 효과가 없으며, 수집하려면 스크레이핑 설정이나 전역 설정에 scrape_native_histograms: true가 필요합니다. 3.15에서는 XOR2 float 청크 인코딩이 안정화되고 OpenMetrics 2.0 스크레이핑이 추가되었습니다.

아키텍처와 데이터 모델: 도구별 메트릭 처리 방식

Prometheus 기본기를 확인한 뒤, 면접관은 보통 세 도구의 아키텍처 차이로 넘어갑니다.

Prometheus는 Pull 기반 모델을 채택하고 있습니다. 설정된 주기마다 대상 서비스의 HTTP 엔드포인트(일반적으로 /metrics)를 스크레이핑하여 시계열 데이터를 수집하고, 자체 TSDB(Time Series Database)에 저장합니다. 각 시계열은 메트릭 이름과 키-값 레이블 조합으로 고유하게 식별됩니다. 3.x 라인에서는 안정화된 네이티브 히스토그램, OTLP 수신기, 샘플을 중앙 저장소로 전송하는 Remote Write 2.0이 추가되었습니다.

Grafana는 메트릭을 수집하거나 저장하지 않습니다. Prometheus, Loki, Tempo, InfluxDB, Elasticsearch 등 100개 이상의 데이터 소스에 연결하여 대시보드를 렌더링하는 시각화 계층입니다. Grafana Labs는 Mimir(장기 메트릭 저장소), Loki(로그 집계), Tempo(분산 트레이싱)를 함께 유지관리하며, 이들과 Grafana가 오픈소스 LGTM 스택을 구성합니다. 2026년 4월 GrafanaCON에서 발표된 Grafana 13은 대시보드 Git Sync를 정식 출시(GA)하고, 동적 대시보드를 기본으로 활성화했으며, grafana-cli와 grafana-server 명령을 제거했습니다.

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

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

scrape_configs:
  - job_name: 'api-server'
    scrape_native_histograms: true
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__

이 YAML 구성은 Prometheus의 Pull 모델을 정의합니다. Kubernetes 서비스 디스커버리로 Pod를 감지하고, prometheus.io/scrape: "true" 어노테이션이 있는 Pod만 남긴 뒤, 주소를 어노테이션에 지정된 포트로 다시 쓰고 15초 간격으로 /metrics를 스크레이핑합니다. 두 번째 규칙은 두 소스 레이블을 ;로 연결하므로, 정규식은 host:port;port 형태와 일치하도록 작성되어 있습니다.

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 (no built-in PromQL equivalent)
anomalies(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의 쿼리 언어는 일부 유연성을 포기하는 대신 anomalies()(알고리즘 basic, agile, robust)와 forecast()(linear, seasonal) 같은 내장 알고리즘 함수를 제공하여, Prometheus 스택에서는 외부 도구가 필요한 기능을 별도 설정 없이 사용할 수 있습니다.

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

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

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

# 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(통합 알림 시스템, Grafana 9부터 기본값)은 연결된 모든 데이터 소스에 걸쳐 쿼리를 평가하고, 다차원 알림과 알림 정책을 지원합니다. 여러 데이터 소스의 조건을 단일 알림 규칙에서 결합할 수 있다는 점이 Prometheus 단독 사용 대비 강점입니다.

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

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

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

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

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

Prometheus는 Kubernetes 생태계의 기본 메트릭 시스템이므로, 컨테이너 오케스트레이션 모니터링에서 가장 중요한 면접 주제입니다.

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만 함께 배포하면 자동으로 모니터링 대상에 포함됩니다. 이처럼 차트 값을 재정의하는 방법은 Helm 차트 면접 가이드에서 더 자세히 다룹니다.

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.x는 --web.enable-otlp-receiver를 설정하면 OTLP 메트릭을 직접 수신하므로, 중간에 Collector를 둘 필요가 더 이상 없습니다. Grafana Alloy(Grafana Agent의 후속)는 OTel Collector와 Prometheus 스크레이퍼 역할을 동시에 수행합니다. Datadog은 OTLP 수집을 지원하지만 "모든 기능에 완전히 접근하려면" 독자적 에이전트 사용을 권장하여 연성 종속(soft lock-in)을 형성합니다.

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

세 도구를 비교하는 옵저버빌리티 면접 질문

Prometheus 자체에 대한 질문을 넘어, 다음 질문들은 지원자가 여러 도구를 넘나들며 추론할 수 있는지를 검증합니다. 각 답변은 면접관이 확인하려는 핵심 개념을 중심으로 구성되었습니다.

"모니터링(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일)와 에러 버짓 소비율을 답변에 포함해야 합니다.

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

올바른 선택은 팀 규모, 운영 성숙도, 예산 제약의 세 가지 변수에 의해 결정됩니다. 보편적으로 올바른 답은 존재하지 않으며, 면접관은 지원자가 승자를 선언하기보다 트레이드오프를 논리적으로 추론하는 역량을 기대합니다.

출처

• Prometheus releases: 3.15.0(2026년 9월)에서 XOR2 청크 인코딩이 안정화되고, OpenMetrics 2.0 스크레이핑이 추가되었으며, --log.level이 지원 중단 예정으로 지정되었습니다
• Prometheus native histograms specification: 3.8부터 안정화, 3.9부터 scrape_native_histograms 필수
• What's new in Grafana 13.0: Git Sync 정식 출시, 동적 대시보드 기본 적용, 호환성을 깨는 변경 사항
• Datadog list pricing: 비용 표에 사용한 인프라, APM, 로그 가격
• Datadog algorithmic functions: anomalies()와 forecast() 구문

Prometheus 및 옵저버빌리티 면접에서 기억할 핵심

• Prometheus는 Kubernetes 환경의 메트릭 수집 표준입니다. Pull과 Push의 차이, 네 가지 메트릭 유형, rate()와 irate()의 차이, 카디널리티, 고가용성은 확실히 설명할 수 있어야 합니다
• Prometheus 3.9 이상에서는 scrape_native_histograms: true를 설정해야만 네이티브 히스토그램이 수집됩니다
• Grafana는 메트릭 데이터베이스가 아닌 시각화 계층이며, 100개 이상의 데이터 소스에 연결됩니다. LGTM 스택(Loki, Grafana, Tempo, Mimir)은 완전한 오픈소스 옵저버빌리티 플랫폼을 구성합니다
• Datadog는 내장 이상 탐지와 함께 풀스택 옵저버빌리티로의 가장 빠른 경로를 제공하지만, 높은 가격과 벤더 종속이라는 대가가 따릅니다
• OpenTelemetry 도입은 백엔드 선택의 영구성을 줄입니다. 어떤 도구가 데이터를 저장하고 쿼리하든 계측 코드는 동일하게 유지됩니다
• 면접에서는 단일 도구를 옹호하기보다 비용, 제어, 복잡성 간의 트레이드오프를 논리적으로 추론하는 능력을 보여주어야 합니다
• 더 폭넓은 준비를 위해 DevOps 필수 면접 질문 가이드에서 면접관이 모니터링에 이어 묻는 인접 주제를 확인할 수 있습니다