2026 모니터링, 옵저버빌리티 완전 가이드

Prometheus·Grafana·Datadog·OpenTelemetry

이 장을 읽기 전에: 7장~10장을 읽어두면 배포 후에 무엇을 계속 봐야 하는지가 연결되기 쉽다.

모니터링은 "죽으면 알아차리기 위한 구조"가 아니다. 본래의 목적은, 무엇이 망가질 것 같은가, 실제로 어디서 망가졌는가, 왜 그렇게 됐는가를 추적할 수 있는 상태를 만드는 것이다.

이 장에서는 메트릭·로그·트레이스, 도구 선정, 알림 설계, SLO, 인시던트 대응, AI 시대의 관측 항목을 정리한다.

� 한국 시장 맥락: 국내 IT 기업(카카오·네이버·토스·쿠팡)은 Datadog 또는 Grafana+Prometheus 스택을 주로 사용한다. ISMS-P 인증에서 로그 보관·접근 기록·이상 탐지는 기술적 보호 조치 필수 항목이므로, 모니터링 설계가 컴플라이언스와 직결된다.

1. 모니터링의 3가지 기둥

이 섹션이 답하는 질문: 무엇을 수집하면 서비스의 상태를 알 수 있는가?

역할 분담

메트릭: 이상을 처음으로 발견한다

로그: 이상의 문맥을 확인한다

트레이스: 느린 부분이나 의존처를 특정한다

자주 있는 잘못

로그만으로 어떻게든 하려고 한다

메트릭은 있지만, 아무도 임계값을 재검토하지 않는다

트레이스를 넣었지만, 샘플링 설계가 없다

정리

3가지 기둥은 대체 관계가 아니다. 검지, 설명, 경로 특정을 각각 담당하고 있다.

2. 모니터링 도구 선정

이 섹션이 답하는 질문: 모니터링 기반은 무엇을 기준으로 선택해야 하는가?

주요 선택지

OpenTelemetry의 위치

OpenTelemetry는 모니터링 도구 자체가 아니라, 계측 데이터를 표준 형식으로 다루기 위한 공통 기반이다. 이것을 넣어두면 수집처나 시각화처를 나중에 바꾸기 쉬워진다.

---

// OpenTelemetry SDK 초기화 — Node.js 예시

import { NodeSDK } from '@opentelemetry/sdk-node';

import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';

import { OTLPMetricExporter } from '@opentelemetry/exporter-metrics-otlp-http';

import { PeriodicExportingMetricReader } from '@opentelemetry/sdk-metrics';

import { Resource } from '@opentelemetry/resources';

import { SEMRESATTRS_SERVICE_NAME, SEMRESATTRS_SERVICE_VERSION } from '@opentelemetry/semantic-conventions';

const sdk = new NodeSDK({

resource: new Resource({

[SEMRESATTRS_SERVICE_NAME]: 'user-service',

[SEMRESATTRS_SERVICE_VERSION]: process.env.APP_VERSION ?? 'unknown',

'deployment.environment': process.env.NODE_ENV ?? 'development',

'service.region': 'ap-northeast-2', // 서울 리전

}),

traceExporter: new OTLPTraceExporter({

url: `${process.env.OTEL_ENDPOINT}/v1/traces`,

}),

metricReader: new PeriodicExportingMetricReader({

exporter: new OTLPMetricExporter({

url: `${process.env.OTEL_ENDPOINT}/v1/metrics`,

}),

exportIntervalMillis: 10_000,

}),

});

sdk.start();

process.on('SIGTERM', () => sdk.shutdown());

---

무엇으로 선택하는가

실무적인 정리

먼저 빠르게 시작하고 싶다: 통합 SaaS (Datadog)

기반을 자신들이 쥐고 싶다: Grafana + Prometheus + Loki

AWS 환경에서 최소 비용으로: CloudWatch + X-Ray

처음에 최소한으로: 에러 모니터링 (Sentry) 먼저 넣는다

향후 선택지를 남기고 싶다: OpenTelemetry를 전제로 한다

⚠️ 모니터링 도구 선정에서 정말 중요한 것은 대시보드의 외관이 아니다. 누가 운용하는가와 어떤 과금이 팽창하기 쉬운가의 2가지다.

� 국내 현황: Datadog은 국내 주요 IT 기업(토스·쿠팡·카카오엔터 등)에서 채택이 늘고 있지만, 데이터가 미국 서버에 저장되므로 개인정보 포함 로그 전송 시 국외 이전 동의가 필요하다. Grafana Cloud 한국 리전은 현재 없어 서울 리전에 자체 Grafana 스택을 구축하거나 CloudWatch를 기본으로 사용하는 팀이 많다.

정리

모니터링 도구는 "무엇이 가장 고기능인가"보다, 자신들이 계속 사용할 수 있는가와 수집 비용을 설명할 수 있는가로 선택해야 한다.

3. 알림 설계와 온콜 체제

이 섹션이 답하는 질문: 언제, 누구에게, 어떤 강도로 통지해야 하는가?

원칙

알림은 "이상이 있다"는 것이 아니라, 지금 당장 인간이 대응해야 하는 것을 알리기 위한 것이다.

레벨 분류의 기본

좋은 알림의 조건

행동 가능하다 — 알림을 받은 사람이 무엇을 해야 할지 명확하다

재현 조건이 명확하다

runbook 링크가 있다

누가 받는가가 결정되어 있다

나쁜 알림의 예

CPU가 잠깐 올랐을 뿐인데 즉시 통지

원인도 절차도 모른다

수신자가 너무 넓다

같은 내용이 몇 번이고 온다

⚠️ 알림 피로는 실제 장애보다 위험해지는 경우가 있다. 반응하지 않는 알림을 늘리느니, 처음에는 적고 예리하게 하는 편이 좋다.

Prometheus 알림 규칙 예시

---

# Prometheus AlertManager 규칙 예시 — 한국 이커머스 서비스 기준

groups:

- name: 결제_서비스_알림

rules:

# Critical: 결제 성공률 99% 미만 5분 지속

- alert: 결제성공률_임계값_초과

expr: |

rate(payment_requests_total{status="success"}[5m])

/

rate(payment_requests_total[5m]) < 0.99

for: 5m

labels:

severity: critical

team: payment

annotations:

summary: "결제 성공률 {{ $value | humanizePercentage }} — 즉시 확인 필요"

description: "5분간 결제 성공률이 99% 아래로 떨어졌습니다."

runbook: "https://wiki.company.com/runbooks/payment-failure"

dashboard: "https://grafana.company.com/d/payment-overview"

# Warning: API p99 레이턴시 2초 초과

- alert: API_레이턴시_경고

expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 2

for: 3m

labels:

severity: warning