✍️ 필사 모드: Observability 2025 완전 가이드: OpenTelemetry, Grafana·Datadog·Honeycomb·SigNoz, SLO·Error Budget, LLM 관측성 (2025)

Season 5 Ep 8 — 거버넌스가 "관리"라면 관측성은 "현실 파악". 2025년 Observability는 Log·Metric·Trace에서 멈추지 않고 LLM·데이터 파이프라인·사용자 경험까지 포함한다.

• Prologue — "관측성 = 보험이 아니라 제품"
• 1장 · 3대 시그널 + α
  • 1.1 기본 3종
  • 1.2 확장 시그널
  • 1.3 상관관계(Correlation)
• 2장 · OpenTelemetry — 표준의 성숙
  • 2.1 무엇인가
  • 2.2 구조
  • 2.3 왜 중요한가
  • 2.4 도입 난이도
• 3장 · Grafana 스택 (오픈)
  • 3.1 구성
  • 3.2 Grafana Cloud
  • 3.3 강점
  • 3.4 한계
• 4장 · Datadog·New Relic·Splunk·Dynatrace — SaaS 거인들
  • 4.1 Datadog
  • 4.2 New Relic
  • 4.3 Splunk
  • 4.4 Dynatrace
  • 4.5 비교
• 5장 · 새 세대 — Honeycomb·SigNoz·Axiom·Tinybird
  • 5.1 Honeycomb
  • 5.2 SigNoz
  • 5.3 Axiom
  • 5.4 Tinybird
  • 5.5 OpenObserve
  • 5.6 공통점
• 6장 · Logs·Metrics·Traces 구현 실전
  • 6.1 Metric 설계
  • 6.2 Log 설계
  • 6.3 Trace 설계
  • 6.4 RUM
  • 6.5 Synthetic
• 7장 · SLO·SLI·Error Budget
  • 7.1 개념
  • 7.2 왜 중요
  • 7.3 실전 지표
  • 7.4 Error Budget 정책
  • 7.5 도구
• 8장 · LLM Observability (Ep 6 연장)
  • 8.1 추가 시그널
  • 8.2 주요 도구
  • 8.3 OpenLLMetry
  • 8.4 운영 패턴
• 9장 · 카오스 엔지니어링·회복력
  • 9.1 철학
  • 9.2 도구
  • 9.3 실전
  • 9.4 데이터 파이프라인에의 적용
  • 9.5 2025 트렌드
• 10장 · 경보·온콜·사고 대응
  • 10.1 경보 설계
  • 10.2 온콜 문화
  • 10.3 사고 대응
  • 10.4 Postmortem
  • 10.5 도구
• 11장 · 비용 최적화
  • 11.1 로그 비용
  • 11.2 Metric 비용
  • 11.3 Trace 비용
  • 11.4 SaaS 비용
  • 11.5 현실 목표
• 12장 · 한국 기업의 관측성
  • 12.1 현황
  • 12.2 LLM 관측성 도입
  • 12.3 한국 특수성
  • 12.4 참고 사례
• 13장 · 안티패턴 10선
  • 13.1 "배포 후 관측성 추가"
  • 13.2 모든 로그를 DEBUG로
  • 13.3 알람 스팸
  • 13.4 SLO 없는 운영
  • 13.5 Trace 없이 장애 분석
  • 13.6 고카디널리티 Metric 라벨
  • 13.7 로그에 민감정보
  • 13.8 Postmortem 없이 같은 사고 반복
  • 13.9 SaaS 비용 방치
  • 13.10 LLM 관측성 제로
• 14장 · 체크리스트 — 관측성 런칭 전 12가지
• 15장 · 다음 글 예고 — Season 5 Ep 9: "데이터 팀 조직과 커리어"

Prologue — "관측성 = 보험이 아니라 제품"

2015–2020년 많은 팀이 관측성을 "사고 대응용 보험"으로 취급했다. 2025년은 다르다:

• 사용자 문제를 먼저 발견 = 경쟁 우위
• SLO 기반 운영 = 개발 속도·안정성 둘 다
• 관측 데이터 자체가 제품 의사결정의 근거
• LLM 제품은 "결과물이 옳은가"가 관측 대상이 됨

"관측성은 비용"이라던 시대는 끝났다. **"관측성은 제품 품질의 일부"**가 2025년의 표준이다.

---

1장 · 3대 시그널 + α

1.1 기본 3종

• Metric: 시계열 수치(CPU·QPS·지연)
• Log: 이벤트 텍스트
• Trace: 분산 요청 경로

1.2 확장 시그널

• Profile: CPU·메모리 프로파일링(continuous profiling)
• Event: 비즈니스·배포·릴리스 이벤트
• RUM (Real User Monitoring): 브라우저·모바일 사용자 체감
• Synthetic: 주기적 가상 요청
• LLM 이벤트: 프롬프트·응답·토큰·비용·피드백

1.3 상관관계(Correlation)

• Metric이 뾰족해질 때 해당 시각 Trace·Log로 점프
• User session → Trace → Log 연결
• 2025년 도구들의 기본 UX

---

2장 · OpenTelemetry — 표준의 성숙

2.1 무엇인가

• 2019 CNCF 프로젝트(OpenCensus + OpenTracing 통합)
• Metric·Trace·Log·Profile(2024) 표준
• 벤더 중립 수집 파이프라인

2.2 구조

• SDK: 언어별(Python/Go/JS/Java/Rust 등)
• Collector: 수집·처리·라우팅
• OTLP 프로토콜: gRPC/HTTP
• Exporter: Prometheus·Datadog·Grafana·New Relic 등

2.3 왜 중요한가

• 벤더 락인 제거: 코드는 OTel, 백엔드는 교체 가능
• 2024–2025 대부분 관측성 벤더가 OTel 네이티브 수용
• Semantic Conventions로 메타 표준화(HTTP·DB·메시징)

2.4 도입 난이도

• 기본 수집은 쉽지만
• Semantic Conventions·Sampling·비용 튜닝은 전문성 필요
• 파편화된 과거 Metric/Log 체계 통합이 과제

---

3장 · Grafana 스택 (오픈)

3.1 구성

• Prometheus (Metric): 표준, 대규모는 Mimir/Thanos/VictoriaMetrics
• Loki (Log): "인덱스는 메타만" 설계로 저비용
• Tempo (Trace): OTel 수용, 스토리지 저렴
• Grafana (UI): 통합 대시보드
• Pyroscope (Profile): 2023 인수, 지속 프로파일링

3.2 Grafana Cloud

• 위 스택 관리형 SaaS
• Free tier 존재, 유료는 사용량 기반
• 중견 기업의 가성비 대안

3.3 강점

• 오픈 자유도 + 통합 UX
• 비용 효율적(로그·트레이스 스토리지)
• 커뮤니티 규모 큼

3.4 한계

• 셀프 운영은 여러 컴포넌트 관리 부담
• Datadog 수준의 "all-in-one" 경험엔 못미침

---

4장 · Datadog·New Relic·Splunk·Dynatrace — SaaS 거인들

4.1 Datadog

• 업계 1등, 600+ 통합
• Infrastructure·APM·Logs·RUM·Security·LLM Observability 전부
• 비용이 가장 큰 불만 (매출 성장의 원천이기도)

4.2 New Relic

• 2020 재설계(NRDB)로 통합 시그널
• 2022 가격 모델 변경(데이터 기반 → 사용자 기반)
• Kubernetes·OTel 친화

4.3 Splunk

• 로그·보안 강자, 2023 Cisco 인수
• 엔터프라이즈·보안 특화
• Observability Cloud(AppD·SignalFx) 통합 중

4.4 Dynatrace

• 자동화·AI(Davis) 기반
• 엔터프라이즈·대규모 복잡 시스템

4.5 비교

---

5장 · 새 세대 — Honeycomb·SigNoz·Axiom·Tinybird

5.1 Honeycomb

• High-cardinality·탐색형 관측 선도
• BubbleUp(자동 상관분석)
• 엔지니어 문화 영향력 큼(Charity Majors)

5.2 SigNoz

• 오픈소스 Datadog 대안
• ClickHouse 기반
• 자체 호스팅으로 비용 절감

5.3 Axiom

• 서버리스 로그, 초저비용 스토리지
• 이벤트·분석 중심
• 커뮤니티·개인 프로젝트에 인기

5.4 Tinybird

• ClickHouse API-first
• 실시간 분석·사용자 대면 지표
• 관측성 전용은 아니지만 비슷한 워크로드

5.5 OpenObserve

• 오픈소스 전체 스택
• 비용 ClickHouse 기반

5.6 공통점

• OTel 수용
• ClickHouse/Parquet 기반 저비용 스토리지
• Kafka·Kinesis 수용

---

6장 · Logs·Metrics·Traces 구현 실전

6.1 Metric 설계

• RED(Rate·Errors·Duration) for services
• USE(Utilization·Saturation·Errors) for resources
• Golden signals(Latency·Traffic·Errors·Saturation)
• 고카디널리티 라벨 주의(Prometheus 폭주)

6.2 Log 설계

• 구조화 로그(JSON)
• Trace ID·Span ID·User ID 포함
• 등급(DEBUG/INFO/WARN/ERROR) 일관
• 민감정보 마스킹

6.3 Trace 설계

• Service boundary마다 span
• DB·외부 API 호출 자동 계측
• Sampling(Head·Tail)로 비용 관리
• Business attribute(org·plan) 포함

6.4 RUM

• 브라우저: Web Vitals(LCP·CLS·INP)
• 모바일: 시작 시간·크래시·네트워크
• 사용자 ID·버전·디바이스 연결

6.5 Synthetic

• 주요 경로 1–5분 주기
• 리전별 체크
• 다단계 워크플로우(로그인→결제) 검증

---

7장 · SLO·SLI·Error Budget

7.1 개념

• SLI(Service Level Indicator): 측정 지표(가용성·지연)
• SLO(Service Level Objective): 목표(99.9% 가용성)
• Error Budget: 허용 실패량(월 43분)

7.2 왜 중요

• 100%는 불가능·비경제적
• 신기능 배포 vs 안정성의 과학적 균형
• 팀 간 공통 언어

7.3 실전 지표

• 가용성: 성공 요청 / 총 요청
• 지연: p95/p99 임계 이내 비율
• 정확성: 결과 오류율
• 신선도: 데이터 지연 시간
• LLM 품질: 평가셋 점수(Ep 6)

7.4 Error Budget 정책

• 예산 소진 시 기능 배포 동결 → 안정화 작업
• 예산 남으면 적극 배포·실험

7.5 도구

• Grafana SLO, Datadog SLO, Nobl9, Blameless
• Prometheus + Sloth(OSS)
• 월·분기 리뷰가 필수

---

8장 · LLM Observability (Ep 6 연장)

8.1 추가 시그널

• 프롬프트·응답 텍스트
• 토큰·비용
• Latency·TTFT(Time to First Token)
• 평가셋 점수·사용자 피드백
• 도구 호출·에이전트 step

8.2 주요 도구

• LangFuse (오픈+SaaS)
• LangSmith (LangChain)
• Phoenix/Arize
• Helicone
• Weights & Biases Weave
• Traceloop (OpenLLMetry 기반)
• Datadog LLM Observability (2024)

8.3 OpenLLMetry

• OpenTelemetry 확장으로 LLM 시맨틱 컨벤션 표준화
• 2024 Traceloop 주도 시작 → 2025 OTel 표준 논의 활발

8.4 운영 패턴

• 프롬프트 A/B·Canary(Ep 11)
• 평가셋 주기 실행 + 회귀 알람
• 사용자 피드백 반영 루프
• 비용·토큰 대시보드

---

9장 · 카오스 엔지니어링·회복력

9.1 철학

• 장애는 불가피 → 의도적으로 발생시켜 학습
• 2010 Netflix Chaos Monkey 기원

9.2 도구

• Gremlin, LitmusChaos(K8s), Steadybit
• AWS Fault Injection Service
• Chaos Toolkit

9.3 실전

• 게임데이(한 팀이 장애 재현, 나머지 대응)
• Runbook 테스트
• 회복 메커니즘(서킷브레이커·리트라이·폴백) 검증

9.4 데이터 파이프라인에의 적용

• Kafka 파티션 중단 시
• DB 페일오버 시
• 엔진 한 개 다운 시

9.5 2025 트렌드

• Resilience as code: 카오스 시나리오를 코드로 관리
• CI 통합: 배포 전 회복 테스트

---

10장 · 경보·온콜·사고 대응

10.1 경보 설계

• Symptom-based: 사용자 영향 기반(5XX 증가)
• Cause-based는 피함: 모든 원인에 경보는 소음
• Severity(P1/P2/P3)
• 스로틀링·억제

10.2 온콜 문화

• 로테이션 주간 단위
• Primary·Secondary
• 보상·휴식 정책

10.3 사고 대응

• Detect → Triage → Mitigate → Resolve → Learn
• 커뮤니케이션 채널(Slack 전용 방)
• 고객 커뮤니케이션(Status page)

10.4 Postmortem

• Blameless
• Timeline·Root cause·Action items
• 공개(내부)·기록 보관

10.5 도구

• PagerDuty, Incident.io, FireHydrant, Rootly
• Slack·MS Teams 통합
• Jira·Linear 연결(액션 추적)

---

11장 · 비용 최적화

11.1 로그 비용

• 구조화·필드 분류로 저장 선택
• 저가 스토리지(ClickHouse·Loki)
• 장기 아카이브(S3 Glacier)
• 민감정보 이미 마스킹

11.2 Metric 비용

• 라벨 카디널리티 관리
• Scrape interval 최적화
• Aggregation rules

11.3 Trace 비용

• Head sampling 1–10%
• Tail sampling(에러·느린 것 우선)
• 자동 dropping(health check 제외)

11.4 SaaS 비용

• 사용량 기반 모델의 급증 주의
• 월간 리뷰 + 예산 알람
• 오픈 대안 고려

11.5 현실 목표

• 관측성 비용 / 인프라 비용 = 5–15%가 일반적
• 20% 초과 시 최적화 필요 신호

---

12장 · 한국 기업의 관측성

12.1 현황

• 대기업: Datadog·Dynatrace·Splunk + 자체 구축
• 인터넷: Grafana 스택·Prometheus 자체 + 일부 SaaS
• 스타트업: Grafana Cloud·Datadog·Axiom 혼합
• 금융·공공: 온프레 Elastic·Splunk·Prometheus

12.2 LLM 관측성 도입

• 2024 시작, 2025 급격 확대
• LangFuse 오픈소스 자체 호스팅
• 자체 구축 케이스(토스·카카오·네이버)

12.3 한국 특수성

• 망분리 환경의 전량 온프레 요구
• 한국어 로그·경보 문구
• 공휴일·주말 대응 문화
• 금융감독원 감사 요구사항

12.4 참고 사례

• 쿠팡: 자체 관측성 플랫폼 + 오픈 혼합
• 네이버: 대규모 Elastic + 자체 APM
• 삼성·LG·SK: 엔터프라이즈 도구 + SI 구축
• 토스: SLO 기반 운영 문화 선도

---

13장 · 안티패턴 10선

13.1 "배포 후 관측성 추가"

처음부터 계측해야 값어치 있음.

13.2 모든 로그를 DEBUG로

비용 폭증·중요 신호 묻힘.

13.3 알람 스팸

모든 에러에 알람 → 알람 무시 증후군.

13.4 SLO 없는 운영

"개발 vs 안정성" 정치 분쟁.

13.5 Trace 없이 장애 분석

수 시간 소요, 원인 모름.

13.6 고카디널리티 Metric 라벨

Prometheus 폭주.

13.7 로그에 민감정보

감사·유출 사고.

13.8 Postmortem 없이 같은 사고 반복

학습 루프 부재.

13.9 SaaS 비용 방치

월말 청구서 쇼크.

13.10 LLM 관측성 제로

환각·거부·비용 폭주 무감지.

---

14장 · 체크리스트 — 관측성 런칭 전 12가지

• OpenTelemetry 기반 계측 (SDK + Collector)
• 3대 시그널 + RUM + Synthetic
• 구조화 로그 + Trace ID 연결
• SLO/SLI 정의와 대시보드
• Error budget 정책
• 온콜 로테이션 + Runbook
• 심각도·알람 설계 (Symptom-based)
• Postmortem 프로세스 (Blameless)
• LLM 관측성(프롬프트·토큰·피드백)
• 비용 대시보드 + 리뷰 주기
• 카오스 엔지니어링·회복력 훈련
• 보안·개인정보 가이드

---

15장 · 다음 글 예고 — Season 5 Ep 9: "데이터 팀 조직과 커리어"

기술·거버넌스·관측성을 쌓았으니, 다음은 그것을 만드는 사람들. Ep 9은 데이터·AI 팀의 조직과 커리어.

• 데이터 엔지니어 vs 분석 엔지니어 vs 플랫폼 엔지니어 vs 사이언티스트
• ML Engineer·AI Engineer의 부상
• Central vs Embedded vs Mesh 조직 모델
• 스타트업·대기업의 팀 규모와 역할
• 온콜·지식 공유 문화
• 리더십 경로(매니저 vs IC)
• 글로벌 원격·국내 특수성
• 연봉·보상 체계 2025
• 채용·면접 트렌드
• 학습·커리어 전략

"도구보다 중요한 건 팀" — 2025년 데이터 조직의 현주소.

다음 글에서 만나자.

---

요약: 2025년 관측성은 "3대 시그널 + α"(Metric·Log·Trace + Profile·RUM·Synthetic·LLM 이벤트)로 확장됐고, OpenTelemetry가 수집 표준이 되면서 벤더 락인이 빠르게 해소 중. Grafana 스택은 오픈·가성비, Datadog·New Relic·Splunk·Dynatrace는 통합·엔터프라이즈, Honeycomb·SigNoz·Axiom은 새 세대 저비용·고탐색. SLO·Error Budget이 개발-안정성 균형의 언어가 되고, LLM 관측성(LangFuse·Phoenix·Helicone·Datadog LLM)이 Ep 6의 연장선에서 주류가 됐다. **"관측성은 보험이 아니라 제품 품질"**이라는 선언이 2025년의 기본값. 한국 기업은 망분리·한국어·SLO 문화를 융합해가는 중이며, 다음 편은 그 관측성을 만드는 데이터 팀과 사람들.