서비스 모니터링 도구 2026, 장애 대응 전 비용·알림·로그 기준
서비스 모니터링 도구를 고를 때 가장 흔한 실수는 대시보드 화면만 보고 결정하는 것이다.
장애가 터지는 순간 운영팀이 필요한 것은 멋진 그래프가 아니라 어떤 사용자가 어떤 기능에서 실패했는지 바로 좁히는 신호다.
NAVER D2의 광고SDK 에러 모니터링 사례도 같은 문제를 보여준다.
범용 SaaS를 붙였는데 SDK 구조와 실제 장애 맥락이 맞지 않으면 전용 수집과 분류 체계가 필요해진다.
이 글은 서비스 모니터링 도구를 Prometheus, Grafana, Sentry, CloudWatch, Datadog 같은 이름 나열이 아니라 비용·알림·로그·보안 기준으로 고르는 방법을 정리한다.
- 서비스 모니터링 도구는 메트릭, 로그, 트레이스, 프론트엔드 오류를 어떤 사고 흐름으로 묶는지가 핵심이다.
- Prometheus와 Grafana는 계측과 시각화 통제력이 강하지만 장기 저장, 온콜, 운영 인력 비용을 따로 봐야 한다.
- Sentry, Datadog, CloudWatch 같은 SaaS·클라우드형 도구는 시작이 빠르지만 수집량, 개인정보, 벤더 종속 비용을 점검해야 한다.
- 좋은 파일럿은 예쁜 대시보드가 아니라 알림 소음, 원인 추적 시간, 로그 저장비, 롤백 판단 시간을 숫자로 남긴다.
이 글이 필요한 사람
- 장애 대응 시간을 줄이기 위해 서비스 모니터링 도구를 새로 고르는 SRE와 플랫폼 엔지니어
- Prometheus와 Grafana를 직접 운영할지 Datadog·CloudWatch 같은 관리형 도구를 쓸지 고민하는 CTO
- 프론트엔드 오류, 백엔드 지연, 로그 검색, 온콜 알림이 서로 끊겨 있는 개발 리더
- 로그 수집비와 APM 비용이 예산을 넘기 시작한 클라우드 비용 담당자
- 고객 데이터와 세션 리플레이, 운영 로그의 개인정보 노출을 점검해야 하는 보안팀
서비스 모니터링 도구를 고르기 전 정의할 것
먼저 도구 이름을 지우고 어떤 신호가 장애 판단에 필요한지 적어야 한다.
OpenTelemetry 문서는 관측 가능성을 메트릭, 로그, 트레이스 같은 신호를 통해 시스템 밖에서 질문할 수 있는 능력으로 설명한다.
메트릭은 전체 상태를 빠르게 보여준다.
로그는 특정 이벤트와 오류 메시지를 남긴다.
트레이스는 한 요청이 프론트엔드, API, 큐, DB를 지나가는 경로를 보여준다.
프론트엔드 오류 모니터링은 사용자의 브라우저, SDK, 네트워크, 릴리스 버전 차이를 잡는다.
이 네 가지가 따로 놀면 장애 대응은 슬랙 캡처와 로그 grep으로 돌아간다.
도구별 선택 기준 요약
아래 표는 우열표가 아니라 운영 조건에 맞는 출발점을 고르기 위한 기준표다.
| 도구군 | 강한 지점 | 먼저 확인할 것 | 비용 리스크 | 적합한 상황 |
|---|---|---|---|---|
| Prometheus | 메트릭 수집, PromQL, 알림 규칙 통제 | 장기 저장, HA, 라벨 cardinality | 고카디널리티 메트릭과 운영 인력 비용 | 쿠버네티스와 자체 플랫폼 중심 팀 |
| Grafana | 대시보드, 알림, 여러 데이터 소스 연결 | 권한, 폴더 구조, 데이터 소스 접근권 | 대시보드 난립과 관리형 플랜 비용 | 메트릭·로그·트레이스 화면을 한곳에 묶는 팀 |
| Sentry | 프론트엔드·앱 오류, 릴리스 추적, 세션 단서 | 개인정보, 샘플링, 소스맵 접근 | 이벤트 폭증과 리플레이 저장 비용 | 브라우저 오류와 SDK 품질이 중요한 제품팀 |
| CloudWatch | AWS 리소스, 로그, 알람, SLO, RUM 통합 | 계정·리전 구조와 로그 보존 정책 | 로그 수집·쿼리·보존 비용 | AWS 중심 인프라를 빠르게 묶는 팀 |
| Datadog | APM, 인프라, 로그, RUM, 보안 제품 통합 | 사이트 위치, 데이터 거주성, 태그 정책 | 호스트·로그·APM 사용량 기반 비용 | 멀티클라우드와 온콜 체계가 필요한 조직 |
Prometheus: 라벨 설계가 비용과 알림 품질을 가른다
Prometheus 공식 문서는 시계열 데이터를 메트릭 이름과 키-값 라벨로 저장한다고 설명한다.
라벨 설계가 좋으면 서비스, 환경, 리전, 오류 클래스로 빠르게 좁힐 수 있다.
라벨에 사용자 ID, 요청 ID, URL 전체를 넣으면 시계열이 폭증한다.
처음에는 요청 수, 오류율, 지연 시간, 포화도 같은 SLI 중심 메트릭만 표준화하는 편이 낫다.
Grafana: 대시보드보다 권한과 소유자가 먼저다
Grafana 공식 문서는 메트릭, 로그, 트레이스를 쿼리하고 시각화하며 알림을 다룰 수 있다고 설명한다.
한 화면에 모든 것을 모을 수 있다는 장점은 동시에 혼란의 원인이 된다.
팀별 폴더, 데이터 소스 권한, 대시보드 owner, 알림 rule owner를 정하지 않으면 복제된 그래프만 늘어난다.
Sentry: 브라우저 오류와 릴리스 품질을 빨리 좁힌다
Sentry JavaScript 문서는 오류 모니터링, tracing, session replay, logs, user feedback 같은 기능을 제시한다.
프론트엔드에서는 서버 메트릭만으로 원인을 알기 어렵다.
특정 브라우저, SDK 버전, 사용자 행동 직전 이벤트가 핵심이면 Sentry 계열이 빠르다.
다만 세션 리플레이와 사용자 식별자는 개인정보 검토 없이는 켜지 않는 편이 안전하다.
CloudWatch: AWS 안에서는 빠르지만 로그 비용을 경계한다
AWS 문서는 CloudWatch가 AWS 리소스와 애플리케이션을 실시간 모니터링하고 메트릭, 알람, 대시보드, 로그를 제공한다고 설명한다.
AWS만 쓰는 팀은 CloudWatch로 시작하는 것이 빠르다.
반대로 여러 클라우드와 온프레미스를 함께 쓰면 계정·리전·서비스 경계가 운영 화면을 갈라놓을 수 있다.
로그 보존 기간과 Logs Insights 쿼리 습관은 비용에 바로 영향을 준다.
Datadog: 통합은 강하지만 태그와 사이트 선택이 중요하다
Datadog 문서는 사이트가 서로 독립적이며 지역과 보안 요구에 따라 선택해야 한다고 설명한다.
기업은 기능 목록보다 데이터가 어느 사이트로 들어가고 어떤 규정 요구를 만족하는지 먼저 확인해야 한다.
APM, 인프라, 로그, RUM을 한곳에 묶으면 추적은 빨라진다.
태그 표준이 없으면 같은 서비스가 여러 이름으로 잡혀 비용과 대시보드가 동시에 흐트러진다.
비용은 수집량, 보존 기간, 알림 소음으로 계산한다
서비스 모니터링 도구 비용은 월 좌석 가격보다 데이터 수집량에서 더 크게 흔들린다.
로그를 모두 저장하고 트레이스를 전량 보관하며 세션 리플레이까지 켜면 작은 서비스도 빠르게 비싸진다.
반대로 샘플링과 보존 정책을 너무 강하게 걸면 장애 순간에 필요한 단서가 사라진다.
| 비용 항목 | 확인 질문 | 측정 지표 | 실패 신호 |
|---|---|---|---|
| 메트릭 | 라벨이 폭증하지 않는가 | 시계열 수, scrape target 수 | 사용자 ID나 URL 전체가 라벨로 들어감 |
| 로그 | 원문 저장이 필요한가 | 일별 GB, 보존 기간, 쿼리 비용 | 디버그 로그가 운영에 계속 남음 |
| 트레이스 | 어떤 요청을 샘플링할 것인가 | 샘플링 비율, 오류 trace 보존율 | 정상 요청 전량 저장으로 비용 급증 |
| RUM·리플레이 | 개인정보 검토가 끝났는가 | 세션 수, 리플레이 저장량 | 민감 화면이 영상처럼 저장됨 |
| 알림 | 누가 깨야 하는 알림인가 | 주간 page 수, false positive 비율 | 모든 warning이 새벽 온콜로 전송됨 |
보안팀이 확인해야 할 로그와 세션 경계
서비스 모니터링 도구는 장애 대응 도구이면서 민감 데이터 수집 도구다.
운영 로그에는 이메일, 전화번호, 결제 오류, 인증 헤더, 내부 계정 ID가 섞일 수 있다.
프론트엔드 리플레이에는 사용자가 입력한 화면과 클릭 흐름이 남을 수 있다.
따라서 벤더 계약보다 먼저 마스킹, 샘플링, 보존, 접근권한 기준을 문서화해야 한다.
- 로그 수집 전 인증 헤더, 토큰, 쿠키, 이메일, 전화번호를 마스킹한다.
- 운영 로그 원문을 개발자 전체가 볼 수 없도록 서비스별 권한과 감사 로그를 둔다.
- 세션 리플레이는 민감 화면 차단과 법무·보안 검토가 끝난 뒤 제한적으로 켠다.
- 트레이스 속성에는 고객 식별자를 직접 넣지 말고 내부 익명 ID나 해시를 사용한다.
- 외부 SaaS로 나가는 데이터 지역과 보존 기간을 공식 문서와 계약서 기준으로 확인한다.
파일럿은 장애 시나리오로 설계한다
모니터링 파일럿은 정상 상태 대시보드를 만드는 작업이 아니다.
실제 장애처럼 오류를 만들고 누가 얼마나 빨리 원인을 좁히는지 보는 실험이어야 한다.
- 서비스 선택: 매출, 로그인, 결제, 검색처럼 사용자 영향이 큰 경로 하나를 고른다.
- 신호 정의: 성공률, p95 지연 시간, 오류율, 큐 적체, 프론트엔드 예외를 SLI로 둔다.
- 알림 분류: 즉시 호출, 업무시간 티켓, 무시할 warning을 분리한다.
- 데이터 제한: 로그 마스킹, trace sampling, 세션 리플레이 제외 화면을 먼저 정한다.
- 장애 리허설: 500 오류, DB 지연, 배포 롤백, 브라우저 오류를 일부러 발생시킨다.
- 확대 판단: MTTA, MTTR, false positive, 비용 증가율, 개인정보 예외를 보고 결정한다.
실무 시나리오로 보는 선택 기준
시나리오 1: 광고 SDK나 결제 위젯에서 브라우저 오류가 늘어난 경우
서버 지표가 정상인데 사용자가 결제 버튼을 누른 뒤 이탈한다면 프론트엔드 오류와 릴리스 단서가 먼저다.
이 경우 서비스 모니터링 도구는 Sentry 계열 오류 수집, sourcemap 관리, 브라우저·SDK 버전 분류를 우선한다.
NAVER D2 사례처럼 범용 도구가 SDK 맥락을 충분히 담지 못하면 자체 분류 필드와 에러 fingerprint를 보강해야 한다.
시나리오 2: 쿠버네티스 마이크로서비스의 지연 시간이 튀는 경우
여러 API와 큐가 얽힌 지연은 단일 서버 CPU 그래프만으로 잡기 어렵다.
Prometheus로 SLI 메트릭을 모으고 OpenTelemetry trace로 요청 경로를 연결해야 원인 후보가 줄어든다.
Grafana 화면에는 서비스 owner, 배포 버전, 최근 변경, 에러 budget을 함께 보여주는 편이 좋다.
시나리오 3: AWS만 쓰는 초기 팀이 온콜을 시작하는 경우
초기 팀은 CloudWatch로 메트릭, 로그, 알람을 묶는 것이 빠를 수 있다.
그러나 모든 로그를 오래 보관하면 비용이 먼저 커진다.
처음에는 핵심 API 로그만 짧게 보존하고 보안 이벤트와 결제 오류는 별도 보존 정책을 두는 방식이 낫다.
알림·로그 라우팅 정책 스켈레톤
아래 YAML은 서비스 모니터링 도구를 도입하기 전 팀이 합의할 정책의 뼈대다.
도구별 설정 파일이 아니라 알림, 로그, trace, 비용 owner를 분리해 사고 대응 기준을 맞추는 용도다.
# service-monitoring-routing.yaml
# 목적: 서비스 모니터링 도구를 고르기 전 알림, 로그, 추적, 비용 책임자를 분리한다.
# 실제 적용 전에는 팀의 SLO, 개인정보 정책, 클라우드 계정 구조에 맞게 수정한다.
service: checkout-api
owner: sre-platform
review_cycle: monthly
signals:
metrics:
source: prometheus_or_cloudwatch
required_labels:
- service
- environment
- region
- error_class
logs:
source: centralized_log_store
pii_policy: mask_before_ingest
retention_days: 30
traces:
source: opentelemetry
sampling:
normal: 0.05
error: 1.0
frontend_errors:
source: sentry_or_rum
session_replay: disabled_until_privacy_review
alert_rules:
page_now:
- checkout_success_rate_below_slo
- payment_error_spike
- p95_latency_over_budget
ticket_only:
- single_user_browser_error
- non_production_warning
suppress:
- known_test_account
- scheduled_maintenance_window
cost_guardrail:
monthly_budget_owner: engineering_manager
ingest_alert_threshold_percent: 70
cardinality_review_required: true
raw_log_sample_required: false
OpenTelemetry Collector 최소 구성 예시
도구를 바꾸더라도 애플리케이션 계측을 계속 갈아엎지 않으려면 수집 계층을 분리하는 편이 좋다.
아래 예시는 민감 속성을 삭제하고 오류 trace는 보존하며 정상 트래픽은 낮게 샘플링하는 검토용 스켈레톤이다.
# otel-collector-minimal.yaml
# 목적: 서비스 모니터링 도구를 바꿔도 애플리케이션 계측을 다시 갈아엎지 않기 위한 최소 스켈레톤이다.
# 엔드포인트, 인증, 샘플링 값은 선택한 벤더 공식 문서와 내부 보안 기준으로 교체한다.
receivers:
otlp:
protocols:
grpc:
http:
processors:
batch:
timeout: 5s
attributes/sanitize:
actions:
- key: user.email
action: delete
- key: request.header.authorization
action: delete
tail_sampling:
decision_wait: 10s
policies:
- name: keep-errors
type: status_code
status_code:
status_codes:
- ERROR
- name: sample-normal-traffic
type: probabilistic
probabilistic:
sampling_percentage: 5
exporters:
otlp/vendor:
endpoint: monitoring-vendor.example.com:4317
headers:
authorization: ${MONITORING_VENDOR_TOKEN}
service:
pipelines:
traces:
receivers: [otlp]
processors: [attributes/sanitize, tail_sampling, batch]
exporters: [otlp/vendor]
실제 엔드포인트, 인증, processor 지원 여부는 선택한 벤더와 Collector 버전의 공식 문서로 확인해야 한다.
도입 전 체크리스트
- 핵심 서비스별 SLI와 SLO를 먼저 정하고 도구 기능은 그다음에 본다.
- 메트릭 라벨에 사용자별 값과 요청별 값을 넣지 않도록 표준을 만든다.
- 로그 보존 기간, 민감 정보 마스킹, 쿼리 권한, 다운로드 권한을 분리한다.
- 알림은 page now, ticket only, suppress로 나누고 owner 없는 알림은 만들지 않는다.
- 비용 파일럿에는 일별 ingest, trace sampling, log retention, RUM session 수를 반드시 남긴다.
- 벤더 전환 가능성을 위해 OpenTelemetry, 표준 로그 스키마, 태그 규칙을 최대한 유지한다.
함께 보면 좋은 글
데이터독(Datadog) 2025: 인프라 모니터링의 표준 – 네트워크, APM, 보안 통합 분석
클라우드 비용 최적화 2026, AWS 비용 줄이기 전 확인할 운영 기준
취약점 테스트 자동화 2026, CI 보안 하네스 도입 전 비용·오탐 기준
웹방화벽 WAF 도입 2026, 기업 보안팀이 먼저 볼 비용·오탐·우회 기준
API Gateway 완전 가이드 | 클라이언트 요청부터 백엔드 서비스까지 한눈에 보기자주 묻는 질문
서비스 모니터링 도구는 무엇부터 도입해야 하나요?
장애 영향이 큰 서비스 하나의 메트릭, 로그, trace, 프론트엔드 오류를 먼저 묶는 편이 좋다.
전사 대시보드보다 결제, 로그인, 검색 같은 핵심 경로의 원인 추적 시간이 더 중요하다.
Prometheus와 Grafana만으로 충분한가요?
메트릭 중심 운영에는 충분할 수 있다.
프론트엔드 오류, 세션 단서, 로그 장기 저장, 온콜 자동화가 필요하면 Sentry, Loki, Tempo, Datadog, CloudWatch 같은 보강이 필요하다.
Sentry와 Datadog은 어떻게 다르게 봐야 하나요?
Sentry는 브라우저와 애플리케이션 오류, 릴리스 추적, 사용자 피드백 단서에 강하다.
Datadog은 인프라, APM, 로그, RUM, 보안 제품을 한 운영 화면에 묶는 방향이 강하다.
CloudWatch만 쓰면 벤더 종속이 심해지나요?
AWS 중심 팀에는 CloudWatch가 빠른 출발점이다.
멀티클라우드 전환 가능성을 남기려면 OpenTelemetry, 표준 태그, 로그 스키마를 함께 유지해야 한다.
로그 비용은 어떻게 줄이나요?
디버그 로그를 운영에 계속 남기지 말고 서비스별 보존 기간을 다르게 둔다.
사용자별 라벨, 과도한 trace 전량 저장, 불필요한 세션 리플레이를 줄이는 것이 먼저다.
모니터링 알림이 너무 많으면 어떻게 정리하나요?
알림을 즉시 호출, 업무시간 티켓, 억제 대상으로 나눈다.
사용자 영향, SLO 위반, 자동 복구 실패처럼 행동이 필요한 조건만 온콜로 보내야 한다.
출처와 확인일
- NAVER D2 — SaaS 대체하기: AI와 함께한 광고SDK 에러 모니터링 시스템 구축기 (확인일: 2026-06-26)
- OpenTelemetry — Observability primer (확인일: 2026-06-26)
- Prometheus — Overview (확인일: 2026-06-26)
- Grafana Labs — About Grafana (확인일: 2026-06-26)
- Sentry Docs — Browser JavaScript (확인일: 2026-06-26)
- AWS Docs — What is Amazon CloudWatch? (확인일: 2026-06-26)
- Datadog Docs — Getting Started with Datadog Sites (확인일: 2026-06-26)
도구 기능, 가격, 데이터 보관 정책, 지역 옵션은 수시로 바뀔 수 있다.
이 글은 공개 공식 문서와 기술 자료를 바탕으로 한 일반 정보이며 실제 계약과 보안 판단은 각 벤더 문서, 내부 정책, 전문가 검토를 기준으로 결정해야 한다.
댓글
댓글 쓰기