모니터링 도구 이야기가 나오면 대체로 두 부류로 갈린다. 클라우드 기본 도구만으로 아직 버티는 팀과, 서비스가 늘면서 확인할 화면이 여기저기 흩어져 곤란해진 팀이다. 예전에 Datadog으로 Kubernetes 모니터링하기 (설치/설정) 글에서 Agent 설치와 설정을 다뤘는데, 정작 그 앞 단계인 "우리 규모에 이걸 지금 들여야 하나, 돈은 얼마나 나오나"는 다루지 않았다. 그래서 이번에는 도입 검토 관점으로 정리한다.
결론부터 말하자면, 호스트가 몇 대 안 되고 서비스 경계가 단순하면 CloudWatch나 Azure Monitor로 충분하다. Datadog 같은 통합 관측 SaaS는 메트릭, 트레이스, 로그를 각각 다른 콘솔에서 확인하느라 장애 원인 조사가 길어지기 시작할 때 값을 한다. 인프라 모니터링은 연간 약정 기준 Pro $15/호스트/월, Enterprise $23/호스트/월이고, 청구액이 커지는 쪽은 호스트 수보다 APM 적용 호스트와 로그 인덱싱 볼륨이다.
1. 개요: 관측 도구가 필요해지는 지점
여기서 말하는 통합 관측(Observability) 도구는 인프라 메트릭, 애플리케이션 추적, 로그, 네트워크 통신, 외형 감시를 한 제품에서 수집해 한 화면에서 연결해 보는 SaaS를 말한다. 개별 기능은 클라우드 기본 도구에도 이미 있다. 대응 관계는 다음과 같다.
- 메트릭 = CloudWatch Metrics
- 분산 추적 = AWS X-Ray
- 로그 = CloudWatch Logs
- 네트워크 통신 기록 = VPC Flow Logs
- 외형 감시 = CloudWatch Synthetics
기능이 없어서 문제가 되는 게 아니라, 확인 위치가 서비스별로 나뉘어 있다는 점이 문제가 된다. 결제 API 응답이 느려졌다는 신고가 들어왔을 때 CloudWatch에서 CPU를 보고, X-Ray로 트레이스를 찾고, 다시 CloudWatch Logs에서 해당 시각 로그를 검색하는 과정을 사람이 손으로 잇는다. 시스템이 커질수록 이 손품이 원인 조사 시간의 대부분을 차지한다.
Datadog은 메트릭 그래프에서 그 구간의 트레이스로, 트레이스에서 해당 요청의 로그로 화면 이동(피벗)이 이어지도록 설계돼 있다. 아래에서는 Datadog이 무엇인지, 기능 축은 어떻게 나뉘는지, 요금은 어떤 구조인지, 도입을 검토할 시점은 언제인지를 차례로 살펴본다.
2. Datadog이 다루는 범위
Datadog은 인프라 메트릭, APM(분산 추적), 로그, 네트워크, Synthetic과 RUM, 알림을 하나의 대시보드에서 다루는 SaaS 관측 플랫폼이다. AWS, Google Cloud, Azure 통합을 지원하고, 온프레미스 서버도 Agent를 설치하면 수집 대상이 된다. 공식 요금 페이지 기준 1,000개 이상의 통합(1,000+ integrations)을 제공한다.
수집 방식은 서버에 Agent를 올리는 쪽이 기본이다. Linux 호스트라면 공식 설치 스크립트 한 줄로 끝난다.
$ DD_API_KEY=<YOUR_API_KEY> DD_SITE="ap1.datadoghq.com" \
bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"
$ sudo datadog-agent status
===============
Agent (v7.x.x)
===============
Status date: [실행 시각]
Agent start: [기동 시각]
Pid: [PID]
Go Version: go1.x
Log Level: info
Paths
=====
Config File: /etc/datadog-agent/datadog.yaml
conf.d: /etc/datadog-agent/conf.d
checks.d: /etc/datadog-agent/checks.d
호스트가 안 보일 때 먼저 확인할 값 중 하나가 DD_SITE다. 값을 지정하지 않으면 기본값인 US1(datadoghq.com)로 붙는데, 조직 계정이 다른 사이트에 만들어져 있으면 Agent는 정상 기동되지만 대시보드에 호스트가 나타나지 않는다. 사이트 값은 6.2절에서 다시 다룬다.
3. 기능 축 여섯 가지
3.1 인프라 메트릭
CPU, 메모리, 디스크 같은 호스트 지표를 수집한다. 클라우드 통합을 켜면 관리형 서비스 지표도 같은 화면으로 들어온다.
3.2 APM
요청이 어느 서비스, 어느 구간에서 지연되는지 추적한다. 트레이스 화면에서 그 시각의 인프라 부하와 로그를 함께 확인할 수 있다는 점이 기본 도구 조합과 갈리는 지점이다.
3.3 로그
여러 서버와 서비스의 로그를 한곳에서 검색한다. 에러 발생 시점에서 메트릭이나 트레이스로 이동할 수 있다.
3.4 네트워크
서비스 간 통신량과 의존관계를 시각화한다. MSA로 쪼갠 뒤 호출 관계가 문서와 어긋나 있는 경우를 찾을 때 쓸모가 있다.
3.5 Synthetic과 RUM
Synthetic은 외부에서 주기적으로 접근해 사이트 생존을 감시한다. RUM(Real User Monitoring)은 실제 사용자 브라우저에서 측정한 표시 속도를 본다.
3.6 이상 감지와 알림
CPU 급증, 에러 증가, 응답 지연, 응답 중단을 감지해 Slack이나 메일로 통보한다. 이 여섯 가지를 묶어 얻는 실질적인 이득은 장애 발견과 원인 조사에 드는 시간 단축이다.
4. 요금 구조
아래 수치는 공식 요금 페이지(https://www.datadoghq.com/pricing/)에서 2026-08-28에 확인한 값이다. 앞이 연간 약정, 괄호가 온디맨드 가격이다. 요금표는 개정될 수 있으므로 계약 전 원문을 다시 확인한다. 원화 환산은 하지 않는다.
4.1 인프라 모니터링 플랜
- Free $0: 호스트 5대까지, 메트릭 보존 1일
- Pro $15/호스트/월(온디맨드 $18): 1,000+ 통합, 기본 대시보드, 메트릭 보존 15개월, 호스트당 컨테이너 5개, 호스트당 커스텀 메트릭 100개
- Enterprise $23/호스트/월(온디맨드 $27): 머신러닝 기반 알림, Live Processes, Governance Console, 호스트당 컨테이너 10개, 호스트당 커스텀 메트릭 200개
4.2 APM과 로그
- APM(인프라 호스트에 추가) $31/호스트/월, APM Pro $35, APM Enterprise $40
- APM 단독 $36 / $41 / $47/호스트/월
- Universal Service Monitoring: 같은 호스트에 APM을 구매하면 포함, 단독은 $9/인프라 호스트/월
- 로그 수집(Ingest) 최저 $0.10/GB/월(수집 또는 스캔한 GB 기준, "Starting At" 표기이므로 최저 단가)
- 표준 인덱싱(Standard Indexing) 15일 보존 $1.70/백만 이벤트/월(온디맨드 $2.55). 3일, 7일, 30일 보존 옵션은 단가가 다르다
- Flex Logs Starter $0.60/백만 이벤트 저장/월(온디맨드 $0.90), 최소 보존 3개월
4.3 단순 계산 예시
[가정] 호스트 10대, 그중 APM 적용 4대, 로그 수집 500GB/월, 인덱싱 2천만 이벤트(15일 보존) 인프라 Pro $15 x 10 = $150/월 -> $1,800/년 인프라 Enterprise $23 x 10 = $230/월 -> $2,760/년 (Pro 기준 추가분) APM $31 x 4 = $124/월 로그 수집(최저단가) $0.10 x 500 = $50/월 로그 표준 인덱싱 $1.70 x 20 = $34/월 --------------------------------------------- 합계 = $358/월 -> $4,296/년
인프라만 보면 10대에 월 $150이라 부담이 작아 보이지만, APM과 로그를 얹는 순간 두 배를 넘긴다. 견적을 낼 때는 호스트 수부터 계산하지 말고 APM을 붙일 호스트 수와 인덱싱할 로그 이벤트 수를 먼저 정하는 편을 권한다. 컨테이너와 커스텀 메트릭도 플랜 포함량을 넘으면 별도 과금 대상이다.
4.4 사용량 측정 방식
과금 기준을 모르면 예상 견적이 어긋난다. 공식 문서에 정리된 측정 방식은 다음과 같다.
- 호스트: 시간 단위로 호스트 수를 측정하고, 상위 1%를 제외한 나머지 99% 구간의 최대값(high-water mark)으로 청구한다. 배포나 스케일 아웃으로 잠깐 튄 값은 걸러진다.
- 컨테이너: high-water mark가 아니라 5분마다 기록한 고유 컨테이너 수를 합산해 월간 사용 시간으로 청구한다.
- 커스텀 메트릭: 시간당 제출된 고유 커스텀 메트릭 수의 월간 평균으로 청구한다. 태그 조합이 늘어나면 여기서 부풀어 오른다.
커스텀 메트릭은 태그에 사용자 ID나 요청 ID처럼 값 종류가 많은 항목을 붙이면 조합 수가 급격히 늘 수 있다. 계측 코드를 짤 때 태그 설계를 먼저 검토한다.
5. 플랜 선택 기준
- 호스트 5대 이하이고 지표만 잠깐 보는 수준이면 Free로 감을 잡는다. 다만 메트릭 보존이 1일이라 추세 분석에는 쓸 수 없다.
- 기본 인프라 감시와 대시보드, 알림이 목적이면 Pro가 기준선이다.
- 머신러닝 기반 이상 감지, Live Processes, 조직 단위 거버넌스가 필요하면 Enterprise를 본다.
- 판단이 서지 않으면 Pro로 시작해 실제로 쓰는 기능을 확인한 뒤 올린다. 반대 순서보다 낫다.
6. 한국에서 도입할 때 확인할 것
6.1 달러 청구
요금은 달러로 청구된다. 연간 약정을 잡아도 원화 기준 지출은 환율에 따라 달라지므로 예산에 여유를 잡아둔다.
6.2 데이터 저장 사이트
Datadog은 계정을 만들 때 데이터가 저장될 사이트를 고르며, 나중에 옮기려면 사실상 재구축에 가깝다. 공식 문서 기준 사이트 목록은 다음과 같다.
- US1 (app.datadoghq.com), US3 (us3.datadoghq.com), US5 (us5.datadoghq.com) - 미국
- EU1 (app.datadoghq.eu) - 독일
- UK1 (uk1.datadoghq.com) - 영국
- AP1 (ap1.datadoghq.com) - 일본
- AP2 (ap2.datadoghq.com) - 호주
- US1-FED (app.ddog-gov.com), US2-FED (us2.ddog-gov.com) - 미국 정부용
한국 리전은 없다. 지리적으로 가까운 곳은 AP1(일본)이다. 개인정보나 로그 본문의 국외 이전을 따져야 하는 조직이라면 계정 생성 전에 이 부분을 법무와 정리한다.
6.3 오픈소스 대안
Prometheus, Grafana, Loki, Tempo를 조합하고 계측은 OpenTelemetry로 통일하는 방식이 대안이 된다. 라이선스 비용은 없지만 스토리지와 운영 인력이 비용으로 옮겨간다. Datadog도 OpenTelemetry 수집을 지원하며, 요금 페이지에 OTLP APM Ingest 항목이 따로 있다. OpenTelemetry로 계측해 두면 나중에 수집 백엔드를 바꾸기가 수월하다는 점은 어느 쪽을 고르든 유효하다.
7. 도입을 검토할 시점
다음 신호가 보이면 검토를 시작할 시점으로 본다. 개수보다 성격이 중요해서, 첫 번째 항목은 하나만 해당해도 충분한 신호다.
- 장애를 고객 신고로 먼저 알게 되는 일이 반복된다
- 원인 조사에 시간이 오래 걸린다
- 서버와 서비스 수가 늘어 확인할 콘솔이 흩어졌다
- 온프레미스에서 클라우드로 이전하는 중이고 양쪽을 함께 봐야 한다
- 모니터링 도구가 여러 개로 쪼개져 있어 하나로 합치고 싶다
- 이상 징후를 Slack으로 바로 받고 싶다
반대로 호스트가 몇 대뿐이고 서비스 간 호출이 단순하면 클라우드 기본 도구로 충분한 경우도 많다. 도입 자체보다 계측 대상을 정하고 알림 임계값을 다듬는 작업에 시간이 더 든다는 점도 감안한다.
8. 정리
- Datadog은 기능이 없어서가 아니라 확인 위치가 흩어져서 생기는 조사 지연을 줄이는 도구다
- 인프라 모니터링은 연간 약정 Pro $15, Enterprise $23/호스트/월이며 Free는 호스트 5대, 보존 1일
- 청구액은 APM 적용 호스트, 로그 인덱싱 볼륨, 커스텀 메트릭 카디널리티에서 커지기 쉽다
- Pro로 시작해 필요한 기능을 확인한 뒤 상위 플랜으로 올리는 순서를 권한다
- 계정 생성 전에 사이트(리전)를 확정하고, 달러 청구에 따른 환율 변동을 예산에 반영한다