💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 2026년, 옵저버빌리티는 "왜?"에 답해야 한다

2015년 옵저버빌리티는 메트릭·로그·트레이스 3 기둥(three pillars)이라는 단어와 함께 시작했다. 2023년 CNCF는 여기에 **continuous profiling**을 네 번째 기둥으로 공식화했다. 그리고 2026년 현재, 진짜 변화는 다른 곳에서 일어났다. **계측(instrumentation)이 사라졌다**는 것이다.

5년 전만 해도 Java 앱에 트레이스를 붙이려면 OpenTelemetry SDK를 import하고, 모든 함수에 어노테이션을 달고, 컨텍스트 전파를 코드로 짜야 했다. 2026년의 표준은 **eBPF로 커널 레벨에서 자동으로 잡는다**이다. Cilium Hubble은 클러스터의 모든 패킷을 본다. Pixie는 K8s 노드에 DaemonSet 하나로 모든 HTTP/gRPC/SQL 요청을 본다. Beyla, Coroot, Caretta는 코드를 한 줄도 안 고치고 골든 시그널을 뽑는다.

그렇다고 SDK 시대가 끝난 것은 아니다. **OpenTelemetry는 2024년 CNCF Graduated**가 됐고, OTLP는 사실상의 와이어 프로토콜 표준이 됐다. eBPF가 "공짜로 얻는 80%"라면, OTel SDK는 "남은 20%의 비즈니스 의미"를 채운다. 즉, 2026년 스택의 진짜 모양은 **eBPF + OTel 하이브리드**다.

이 글은 그 지도를 그린다 — 메트릭·로그·트레이스·프로파일 4 기둥, eBPF의 모든 도구(Cilium / Hubble / Tetragon / Pixie / Inspektor Gadget / Coroot / Beyla / Caretta), Grafana LGTM(Loki + Tempo + Mimir + Pyroscope), Datadog/New Relic/Dynatrace 같은 SaaS 거인, 네트워크 옵저버빌리티 전용 도구들(Suzieq, ntopng, ThousandEyes), 그리고 한국·일본 기업의 실제 사용 사례까지.

> **옵저버빌리티는 모니터링의 상위 집합이다.** 모니터링이 "정해진 지표가 임계치를 넘는지 보는 것"이라면, 옵저버빌리티는 "임의의 질문에 답할 수 있는 시스템 상태"다. 2026년의 차이를 만드는 건 도구가 아니라 **이 질문을 던질 수 있게 만드는 스택 설계**다.

다루는 것:

1. 4 기둥(metrics / logs / traces / profiles)과 골든 시그널

2. eBPF 혁명 — Cilium 1.16, Hubble, Tetragon, Pixie

3. OpenTelemetry 2026 — Collector, OTLP, Auto-instrument

4. 메트릭 스택 — Prometheus 3.0, VictoriaMetrics, Mimir

5. 로그 스택 — Loki 3, Elastic, Vector, Quickwit, OpenObserve, SigNoz

6. 트레이스 스택 — Tempo 2, Jaeger 2, Zipkin, Honeycomb

7. Continuous Profiling — Pyroscope, Parca, Polar Signals

8. 네트워크 옵저버빌리티 — Suzieq, Skydive, ntopng, ThousandEyes

9. RUM & 합성 모니터링 — Cloudflare, Checkly, Grafana Synthetic

10. APM 비교 — Datadog, New Relic, Dynatrace, AppDynamics

11. K8s 옵저버빌리티 — Prometheus Operator, k9s, Lens

12. 서비스 메시 + 옵저버빌리티 — Kiali, Linkerd dashboard

13. DevSecOps + 옵저버빌리티 — Falco + OTel

14. 스토리지 백엔드 — VictoriaMetrics, Mimir, ClickHouse, MinIO

15. 비용 모델 — Datadog $35-70/host vs self-host LGTM

16. 한국 사례 — NCsoft Pixie, Coupang Datadog, Naver OTel, Kakao Grafana

17. 일본 사례 — Mercari, LINE Yahoo, CyberAgent

18. SLO/SLI와 에러 버짓 운영

19. 알림과 PagerDuty/Opsgenie/Incident.io

20. AI-native 옵저버빌리티의 윤곽

21. 도입 로드맵 — 어디서 시작할 것인가

22. 참고 문헌

1. 4 기둥과 골든 시그널 — 무엇을 측정하는가

옵저버빌리티의 출발점은 "무엇을 보느냐"다. 2026년 현재 합의된 답은 4 기둥이다.

- **메트릭(Metrics)** — 시계열 숫자. `http_requests_total`, `cpu_usage_seconds_total` 같은 카운터/게이지/히스토그램. 가장 싸고 가장 오래 보관할 수 있다.

- **로그(Logs)** — 이벤트 텍스트. 사건이 일어났을 때의 컨텍스트가 풍부하지만, 비싸고 검색이 느리다.

- **트레이스(Traces)** — 분산 요청의 인과관계. 한 사용자 요청이 마이크로서비스 A → B → C → DB를 어떻게 지나갔는지 보여준다.

- **프로파일(Profiles)** — CPU/메모리/락 점유의 함수 단위 분포. 어떤 함수가 CPU를 가장 많이 쓰는지를 항상(continuously) 추적한다.

여기에 Google SRE 책의 **골든 시그널 4종**을 매핑하는 것이 표준 운영 시각이다.

| 골든 시그널 | 정의 | 메트릭 예시 |

| ----------- | -------------------------- | --------------------------------- |

| Latency | 요청을 처리하는 데 걸린 시간 | p50/p95/p99 응답 시간 |

| Traffic | 시스템이 받고 있는 부하 | RPS, QPS, MB/s |

| Errors | 실패율 | 5xx 비율, 예외 카운트 |

| Saturation | 자원 포화도 | CPU 사용률, 큐 길이, 디스크 IOPS |

> **2023년 USE 메소드와 RED 메소드** — Brendan Gregg의 USE(Utilization / Saturation / Errors)는 자원 중심, Tom Wilkie의 RED(Rate / Errors / Duration)는 요청 중심. 둘 다 골든 시그널의 사촌이고, 어떤 시각으로 시작할지에 따라 첫 대시보드의 모양이 달라진다.

2. eBPF 혁명 — Cilium, Hubble, Tetragon, Pixie

2026년 옵저버빌리티의 진짜 변곡점은 **eBPF**(extended Berkeley Packet Filter)다. 리눅스 커널 안에 안전한 가상머신을 띄워 패킷·시스템 콜·소켓 이벤트를 가로채는 기술인데, 이게 옵저버빌리티에 가져온 변화가 결정적이다.

**eBPF가 바꾼 것**:

1. **언어 무관(language-agnostic) 계측** — Go/Java/Python/Rust 무관하게 커널이 모든 syscall을 본다.

2. **제로 코드 변경(zero-code-change)** — DaemonSet 하나만 띄우면 끝.

3. **저오버헤드** — 커널 수준이라 1~3% CPU.

4. **L7 가시성** — HTTP/gRPC/SQL 파서를 eBPF로 돌려 메서드·경로·상태코드까지 잡는다.

**대표 도구**:

- **Cilium 1.16** (Isovalent, 2024년 Cisco 인수) — K8s 네트워킹 + 옵저버빌리티. CNI, 서비스 메시(Cilium Service Mesh), 보안, 가시성을 한 묶음으로.

- **Cilium Hubble** — Cilium 위에 얹는 흐름(flow) 가시화 레이어. `kubectl exec`로 Hubble CLI를 띄우면 어떤 파드가 어떤 파드에 어떤 포트로 말을 거는지 실시간으로 본다.

- **Tetragon** — Cilium의 런타임 보안 자매 프로젝트. 어떤 프로세스가 어떤 파일을 열었고 어떤 syscall을 호출했는지 추적.

- **Pixie** (New Relic 인수, CNCF Sandbox) — K8s에 DaemonSet 한 줄로 깔면 모든 HTTP/gRPC/Postgres/Redis 호출을 자동 캡처. PxL이라는 자체 쿼리 언어 제공.

- **Inspektor Gadget** — eBPF 기반 K8s 디버깅 툴킷. `kubectl gadget trace dns` 같은 커맨드로 즉시 트레이스.

- **Coroot, Caretta, Beyla** — eBPF로 서비스 맵·골든 시그널을 자동 생성하는 신세대 도구들. Beyla는 Grafana Labs 출신.

- **bpftrace / BCC Tools** — Brendan Gregg의 클래식. `execsnoop`, `tcptracer`, `biolatency` 같은 단일 목적 추적 도구.

Cilium Hubble UI 설치 (helm)

cilium install --version 1.16.0

cilium hubble enable --ui

cilium hubble port-forward

http://localhost:12000 에서 실시간 흐름 시각화

> **Pixie의 마법** — 보통 분산 트레이싱을 붙이려면 모든 서비스에 OTel SDK를 박아야 한다. Pixie는 K8s 노드에 PEM(Pixie Edge Module) DaemonSet 하나만 설치하면 끝이다. 5분 만에 모든 마이크로서비스의 HTTP·gRPC 호출 그래프가 보인다.

3. OpenTelemetry 2026 — 사실상의 표준

**OpenTelemetry(OTel)는 2024년 CNCF Graduated**가 됐다. CNCF에서 Kubernetes 다음으로 큰 프로젝트가 됐다는 뜻이다. 2026년 현재 OTel은 "관찰 데이터의 와이어 표준"이라고 부를 만하다.

**구성요소**:

- **OTel SDK** — Go / Java / JS / Python / Rust / .NET / PHP / Ruby / Swift 등 11개 공식 언어 지원

- **OTel Collector** — 데이터 파이프라인. 수집(receivers) → 처리(processors) → 전송(exporters)

- **Auto-instrumentation** — Java는 `-javaagent` 한 줄, Python은 `opentelemetry-instrument` 한 줄로 자동 계측

- **OTLP 프로토콜** — gRPC + HTTP. 메트릭/로그/트레이스/프로파일(2025년 GA) 모두 한 프로토콜로 전송

otel-collector-config.yaml

receivers:

otlp:

protocols:

grpc:

endpoint: 0.0.0.0:4317

http:

endpoint: 0.0.0.0:4318

processors:

batch:

timeout: 10s

exporters:

prometheus:

endpoint: 0.0.0.0:8889

loki:

endpoint: http://loki:3100/loki/api/v1/push

otlp/tempo:

endpoint: tempo:4317

tls:

insecure: true

service:

pipelines:

metrics:

receivers: [otlp]

processors: [batch]

exporters: [prometheus]

logs:

receivers: [otlp]

processors: [batch]

exporters: [loki]

traces:

receivers: [otlp]

processors: [batch]

exporters: [otlp/tempo]

> **왜 OTel이 이겼나** — 5년 전만 해도 Datadog Agent, New Relic Agent, Jaeger Client, Zipkin Brave가 모두 자기 SDK를 강요했다. 한 회사가 Datadog → New Relic으로 옮기는 데만 수개월이 걸렸다. OTel은 "데이터는 표준화, 백엔드는 자유"라는 약속으로 이 lock-in을 깼다. 2026년에는 Datadog조차 OTLP를 1급 시민으로 받는다.

4. 메트릭 스택 — Prometheus 3.0과 그 동료들

메트릭은 가장 오래되고 가장 성숙한 기둥이다. 2026년 현재 표준은 단연 **Prometheus 생태계**다.

- **Prometheus 3.0** (2024.11 릴리스) — UTF-8 라벨, 네이티브 히스토그램, OTLP receiver 내장

- **VictoriaMetrics** — Prometheus 호환의 고성능 대안. 단일 바이너리, 10배 압축

- **Grafana Mimir** — Prometheus의 수평 확장 백엔드. AWS S3/GCS/MinIO에 장기 저장

- **Thanos** — Mimir의 선배. Prometheus + S3 + 멀티 리전 글로벌 뷰

- **Cortex** — Mimir의 전신. 여전히 일부 인스톨레이션에서 사용

- **Datadog / New Relic / Dynatrace** — 상용 메트릭 스택. SaaS 대시보드까지 포함.

Prometheus 3.0 scrape 예시 + OTLP receive

global:

scrape_interval: 15s

OTLP receiver (3.0 신기능)

otlp:

promote_resource_attributes:

- service.name

- service.namespace

- deployment.environment

scrape_configs:

- job_name: 'kubernetes-pods'

kubernetes_sd_configs:

- role: pod

VictoriaMetrics와 Mimir의 차이:

| 항목 | VictoriaMetrics | Grafana Mimir |

| ---------- | --------------- | ------------------------ |

| 아키텍처 | 단일 바이너리 | 분산 마이크로서비스 |

| 저장소 | 로컬 디스크 | S3/GCS/MinIO |

| 쿼리 언어 | PromQL + MetricsQL | PromQL |

| 압축 | 매우 높음 | 보통 |

| 운영 난이도 | 낮음 | 중간 |

| 적합한 규모 | 단일~중규모 | 멀티테넌트 대규모 |

5. 로그 스택 — Loki, Elastic, Vector, Quickwit

로그는 가장 비싸고 가장 자주 문제를 일으키는 기둥이다. 2026년에는 **인덱스를 줄이고 컬럼 스토어를 쓰자**는 흐름이 확고하다.

- **Grafana Loki 3.x** — "라벨만 인덱싱"하는 로그 DB. Prometheus와 같은 모델, S3 백엔드

- **Elasticsearch / OpenSearch** — 클래식. 전체 텍스트 인덱싱. 강력하지만 비싸다

- **Quickwit** — Rust로 작성된 검색 엔진. S3 우선, 풀텍스트 인덱싱, Elastic 대안

- **VictoriaLogs** — VictoriaMetrics 팀의 로그 DB. 빠른 풀텍스트

- **OpenObserve** — Rust 기반 올인원(메트릭·로그·트레이스)

- **SigNoz** — ClickHouse 위의 오픈소스 옵저버빌리티 (메트릭·로그·트레이스)

- **ClickHouse** — 컬럼 스토어. Uber, Cloudflare가 로그 백엔드로 채택

- **Fluentd / Fluent Bit / Vector** — 로그 수집기. Vector는 2021년 Datadog이 인수한 Rust 기반의 신세대

Fluent Bit -> Loki 파이프라인 예시

[INPUT]

Name tail

Path /var/log/containers/*.log

Parser docker

Tag kube.*

[OUTPUT]

Name loki

Match kube.*

Host loki.observability.svc

Port 3100

Labels job=fluentbit

**Loki vs Elasticsearch 일반론**:

- 로그가 메트릭과 같이 다뤄지길 원한다 → Loki

- 풀텍스트 검색, SIEM, 보안 분석이 1순위 → Elasticsearch / OpenSearch

- Rust 스택, S3 우선 → Quickwit / VictoriaLogs

- 메트릭·로그·트레이스 통합 → SigNoz / OpenObserve

6. 트레이스 스택 — Tempo 2, Jaeger 2

분산 트레이스는 마이크로서비스의 인과관계를 본다. "한 사용자 요청이 어디서 느렸나"의 정답을 준다.

- **Grafana Tempo 2.x** — 라벨만 인덱싱, S3 백엔드, Loki와 같은 철학

- **Jaeger 2** (CNCF Graduated, 2024년 풀 재작성) — OTel Collector 기반으로 다시 작성. v1 호환

- **Zipkin** — Twitter 원조. 여전히 단순한 설치를 원할 때 좋다

- **Honeycomb** — 이벤트 기반 옵저버빌리티의 원조. Charity Majors의 영향력

- **Lightstep** (ServiceNow 인수) — 대규모 트레이스 분석

- **AWS X-Ray / GCP Cloud Trace / Azure Monitor** — 클라우드 네이티브 옵션

- **Datadog APM / New Relic APM / Dynatrace** — 상용 통합

Python OTel auto-instrument 한 줄

pip install opentelemetry-distro opentelemetry-exporter-otlp

opentelemetry-bootstrap -a install

opentelemetry-instrument --traces_exporter otlp \

--exporter_otlp_endpoint http://tempo:4317 python app.py

> **Jaeger 2의 의미** — 1.x 시절 Jaeger는 자체 Cassandra/Elasticsearch 백엔드와 자체 SDK를 가졌다. 2024년 Jaeger 2는 모든 것을 OTel Collector 기반으로 재작성했다. 이는 "트레이스 백엔드도 더 이상 lock-in이 아니다"라는 선언이다.

7. Continuous Profiling — Pyroscope, Parca

2023년부터 옵저버빌리티의 **네 번째 기둥**으로 정착한 것이 continuous profiling이다. 프로덕션에서 항상 CPU/메모리/락 프로파일을 1~5% 오버헤드로 잡는다.

- **Grafana Pyroscope** — CNCF, Polar Signals의 Parca와 합쳐진 후속작

- **Parca** — 오리지널 eBPF 기반 프로파일링. 2024년 Pyroscope에 통합

- **Polar Signals Cloud** — Parca의 상용 호스팅

- **Datadog Continuous Profiler** — APM에 통합된 상용 옵션

- **Pyroscope OSS** — 자가 호스팅 가능

대표 사용 사례:

- **CPU 핫스팟 찾기** — 어떤 함수가 CPU의 60%를 먹는지 한눈에

- **메모리 누수 추적** — 시간에 따른 alloc/free 그래프

- **락 컨텐션 분석** — 어떤 mutex가 가장 자주 blocking인지

Pyroscope를 Kubernetes에 배포 (Helm)

helm repo add grafana https://grafana.github.io/helm-charts

helm install pyroscope grafana/pyroscope \

--set pyroscope.config.scrape_configs[0].job_name=k8s-pods

> **eBPF + Pyroscope 조합** — Pyroscope의 eBPF 프로파일러는 노드 레벨에서 모든 프로세스의 CPU 프로파일을 자동으로 수집한다. 코드 변경 없이 Go, Rust, C++, Python까지 한 번에 잡힌다.

8. 네트워크 옵저버빌리티 전용 도구

서비스 옵저버빌리티와는 결이 다른 **네트워크 자체**의 가시성도 중요한 카테고리다.

- **Suzieq** — 네트워크 옵저버빌리티. 스위치·라우터·방화벽 상태를 SQL로 질의

- **Skydive** — 실시간 네트워크 토폴로지 + 트래픽 시각화

- **ntopng / ntop** — 플로우 분석(NetFlow / IPFIX / sFlow)의 클래식

- **Netflix Atlas** — Netflix가 만든 시계열 모니터링. 클라우드 네트워크 메트릭에 강함

- **Wireshark / tcpdump** — 패킷 캡처의 표준. eBPF 시대에도 여전히 마지막 답

- **Cisco ThousandEyes** — 인터넷 경로 모니터링 SaaS. BGP, DNS, CDN 가시성

- **Catchpoint / Pingdom** — 합성 모니터링과 인터넷 모니터링의 상용 옵션

- **Kentik** — 대규모 네트워크 분석 SaaS

- **Arista CloudVision** — 데이터센터 네트워크 옵저버빌리티

Suzieq 예시: 모든 BGP 세션 상태를 SQL로 조회

$ suzieq-cli

suzieq> bgp show state=NotEstd

namespace hostname vrf peer state

prod leaf01 default 10.0.0.2 Active

prod leaf03 default 10.0.0.6 Connect

> **클라우드와 함께 네트워크 옵저버빌리티가 다시 중요해진 이유** — 5년 전에는 "네트워크는 클라우드 vendor가 알아서 한다"였다. 2026년에는 멀티 클라우드, 멀티 리전, 서비스 메시, 0 트러스트 네트워크가 일상이 되면서 **누가 누구와 무엇을 말하고 있나**가 다시 핵심 질문이 됐다.

9. RUM(Real User Monitoring)과 합성 모니터링

서버 측 옵저버빌리티 못지않게 중요한 게 **사용자 화면에서 실제로 어떻게 보이는가**다.

**RUM(Real User Monitoring)**:

- **Datadog RUM** — 가장 성숙. 세션 리플레이까지

- **New Relic Browser** — 브라우저 모니터링 클래식

- **Cloudflare Browser Insights** — CDN과 통합된 RUM

- **Sentry Performance** — 에러 모니터링과 통합된 RUM (별도 글에서 다룸)

- **PostHog Session Replay** — 프로덕트 분석 + 세션 리플레이

**합성 모니터링(Synthetic Monitoring)**:

- **Checkly** — 코드 우선 합성 모니터링. Playwright 통합

- **Datadog Synthetics** — 멀티스텝 API/브라우저 체크

- **Grafana Synthetic Monitoring** — Grafana Cloud에 통합

- **Pingdom** — 클래식 가용성 모니터링

- **UptimeRobot, Better Stack** — 단순 ping 모니터링의 저비용 옵션

// Checkly 합성 모니터 예시 (Playwright)

test('homepage loads', async ({ page }) => {

const res = await page.goto('https://example.com')

expect(res.status()).toBeLessThan(400)

await expect(page.locator('h1')).toContainText('Welcome')

})

> **2026년의 RUM 표준** — Core Web Vitals(LCP, INP, CLS)를 OTLP로 OTel Collector에 보내고, Grafana로 보는 패턴이 자리잡았다. Cloudflare는 이걸 무료로 제공한다.

10. APM 비교 — Datadog vs New Relic vs Dynatrace

상용 APM(Application Performance Monitoring) 시장의 3강은 여전히 같다.

| -------- | -------------- | ----------------- | ------------------ |

| OTel 지원| 1급 시민 | 1급 시민 | 1급 시민 |

| K8s | 강함 | 강함 | 강함 |

**기타 옵션**:

- **AppDynamics** (Cisco/Splunk) — 엔터프라이즈

- **Elastic Observability** — Elastic Stack 통합

- **Splunk Observability** (구 SignalFx) — Splunk Cloud 통합

- **Honeycomb** — 이벤트 기반 옵저버빌리티의 prestige 브랜드

- **Logz.io / Sumo Logic** — SaaS ELK/통합

> **2026년의 트렌드** — "Datadog 한 벤더 lock-in"에서 "Grafana LGTM 자가호스팅 + Datadog/New Relic을 일부 영역에" 하이브리드로 옮겨가는 회사가 늘고 있다. 비용 압박이 그 주된 이유다.

11. K8s 옵저버빌리티 — Operator, k9s, Lens

쿠버네티스 옵저버빌리티는 별도 카테고리로 다뤄질 정도로 풍부하다.

- **Prometheus Operator** — Prometheus를 K8s 네이티브로 운영. `ServiceMonitor`, `PodMonitor` CRD

- **kube-prometheus-stack** — Helm 차트 통합 (Prometheus + Grafana + Alertmanager + node-exporter)

- **kube-state-metrics** — K8s 리소스 상태를 Prometheus 메트릭으로 노출

- **node-exporter** — 노드 시스템 메트릭

- **k9s** — 터미널 K8s 클라이언트의 끝판왕

- **Lens / OpenLens** — GUI K8s IDE

- **k0s, k0sctl** — 경량 K8s 디스트리뷰션

- **Cilium + Hubble + OTel + Pixie** — eBPF 풀스택

Prometheus Operator의 ServiceMonitor 예시

apiVersion: monitoring.coreos.com/v1

kind: ServiceMonitor

metadata:

name: my-app

labels:

release: prometheus

spec:

selector:

matchLabels:

app: my-app

endpoints:

- port: metrics

interval: 30s

12. 서비스 메시와 옵저버빌리티

서비스 메시는 사이드카가 모든 트래픽을 가로채기 때문에 본질적으로 **트레이스/메트릭 자동 생성기**다.

- **Istio + Kiali** — Kiali는 Istio 서비스 메시 토폴로지 시각화의 표준

- **Linkerd dashboard** — 단순함이 강점. CNCF Graduated

- **Consul Connect + Consul UI** — HashiCorp 스택

- **Cilium Service Mesh** — eBPF 기반의 사이드카 없는 메시

- **Envoy Admin** — 모든 메시의 데이터플레인. `/stats` 엔드포인트로 1000+ 메트릭

> **사이드카 없는 메시** — Istio Ambient Mode와 Cilium Service Mesh가 2024-2025년에 GA가 되면서 "노드 레벨 데이터플레인"이 표준이 됐다. 옵저버빌리티 관점에서는 사이드카가 사라져도 같은 데이터를 얻을 수 있다는 점이 핵심.

13. DevSecOps와 옵저버빌리티의 통합

런타임 보안과 옵저버빌리티는 같은 데이터를 보지만 다른 질문을 한다.

- **Falco** — eBPF/syscall 기반 런타임 보안 (CNCF Graduated)

- **Tetragon** — Cilium의 보안 자매 프로젝트

- **OPA / Gatekeeper** — 정책 엔진

- **Kubescape** — K8s 보안 스캐너 (CNCF Incubating)

- **Cloud SIEM** — Datadog Cloud SIEM, Elastic Security, Sumo Logic Cloud SIEM

- **CrowdStrike Falcon / Wiz / Lacework** — CSPM/CNAPP 상용

Falco 규칙 예: 컨테이너 안에서 셸이 떴을 때 알람

- rule: Terminal shell in container

desc: A shell was used as the entrypoint/exec point in a container

condition: spawned_process and container and shell_procs

output: "A shell was spawned in a container (user=%user.name container=%container.id)"

priority: WARNING

14. 스토리지 백엔드 — VictoriaMetrics, Mimir, ClickHouse, MinIO

옵저버빌리티 데이터의 양은 폭발적이다. 어디에 얼마나 오래 저장할지가 핵심.

- **VictoriaMetrics** — 메트릭 장기 저장. 매우 높은 압축률

- **Grafana Mimir** — Prometheus 메트릭의 분산 백엔드. S3 우선

- **Grafana Loki** — 로그. S3 우선

- **Grafana Tempo** — 트레이스. S3 우선

- **ClickHouse** — 컬럼 스토어. 로그/트레이스 백엔드로 빠르게 채택 (SigNoz, OpenObserve, Cloudflare)

- **MinIO** — S3 호환 오브젝트 스토리지. 자가 호스팅 옵저버빌리티의 표준 백엔드

- **AWS S3 / GCS / Azure Blob** — 클라우드 옵션

저장 기간 가이드라인:

| ----------- | ---------- | -------- | ------------- |

| 메트릭 | 15일 | 90일 | 13개월+ |

| 로그 | 7일 | 30일 | 1년+ (S3 IA) |

| 트레이스 | 3-7일 | 30일 | 90일+ |

| 프로파일 | 7일 | 30일 | 보통 폐기 |

15. 비용 모델 — SaaS vs Self-Host

옵저버빌리티 비용은 보통 인프라 비용의 5-15%를 먹는다. 큰 규모에서는 30%까지 가는 경우도 흔하다.

**SaaS 가격 (2026년 기준 공시가)**:

- **Datadog APM**: 호스트당 약 35-70 USD/월, 커스텀 메트릭은 별도

- **New Relic**: 사용자당 99 USD/월 + 데이터 GB당 0.30 USD 체감 (실제 모델은 더 복잡)

- **Dynatrace**: DPS(Davis Platform Subscription) 단위, 보통 호스트당 80-200 USD/월

- **Honeycomb**: 이벤트 양 기반, 무료 티어 후 GB당 가격

- **Grafana Cloud Pro**: 사용량 기반, 무료 티어 후 메트릭 시리즈/로그 GB로 부과

**자가호스팅 LGTM 비용 (대략)**:

100 호스트 / 일 1TB 로그 / 일 100GB 트레이스 가정시:

- 컴퓨트: K8s 노드 10대 약 3,000 USD/월

- S3 스토리지: 약 500-800 USD/월 (1년치 보관)

- 운영 인건비: 0.5 FTE 이상 (가장 큰 숨은 비용)

> **결론** — 50 호스트 이하는 SaaS가 거의 항상 싸다. 200 호스트 이상은 자가호스팅이 거의 항상 싸다. 그 사이는 회사 사정에 따라 갈린다. 비용 압박이 심한 한국·일본 회사들은 이 임계점을 빠르게 넘어 자가호스팅으로 가는 추세다.

16. 한국 기업 사례 — NCsoft, Coupang, Naver, Kakao

한국 빅테크의 옵저버빌리티 도입은 2020년경 Datadog 도입기를 거쳐 2024년 이후 점진적 자가호스팅 회귀로 옮겨가는 패턴이 보인다.

- **NCsoft** — Pixie와 eBPF 도입 사례를 KubeCon에서 발표(2023). 게임 백엔드의 마이크로서비스 트레이스에 활용

- **Coupang** — Datadog 대규모 사용자. APM과 인프라 모니터링 통합

- **Naver** — OpenTelemetry 도입. 자체 메트릭/트레이스 백엔드 구축 사례를 DEVIEW에서 공유

- **Kakao** — Grafana 스택 자가호스팅. 메시저 백엔드의 메트릭 가시성에 활용

- **배달의민족(우아한형제들)** — Datadog + 자가호스팅 Grafana 하이브리드

- **카카오뱅크/토스** — 금융 규제 때문에 자가호스팅 비중이 높다. ELK + Grafana

- **당근마켓** — Datadog APM + Sentry 조합

- **라인플러스(한국)** — OpenTelemetry + Grafana

> **공통 패턴** — 한국 회사들은 (1) 초기 빠른 가시성은 Datadog/New Relic으로 시작, (2) 비용이 일정 임계를 넘으면 LGTM 스택으로 옮기되 RUM/Sentry는 남기는 하이브리드 패턴이 흔하다.

17. 일본 기업 사례 — Mercari, LINE Yahoo, CyberAgent

일본 시장은 한국보다 OpenTelemetry와 eBPF 채택이 한 발 앞서 있다는 평가가 있다.

- **Mercari** — Datadog 메이저 유저. OTel 마이그레이션을 SRECon 2024에서 발표

- **LINE Yahoo** — 합병 후 OpenTelemetry 표준화 가속. 자체 메트릭 백엔드

- **CyberAgent** — Cilium 대규모 도입. KubeCon에서 eBPF 발표 다수

- **DeNA** — Datadog + Grafana 하이브리드

- **Rakuten** — Splunk 대규모 사용자. APM은 New Relic

- **PayPay** — AWS 네이티브 옵저버빌리티 + Datadog

- **Smartbank / Kyash** — 핀테크 스타트업의 OTel 도입 사례

- **메루카리 ML팀** — Pyroscope/Parca로 머신러닝 워크로드 프로파일링

> **일본 SRE 문화** — Mercari, CyberAgent를 중심으로 한 SRE 커뮤니티(SRE Lounge, SRE NEXT 컨퍼런스)가 옵저버빌리티 베스트 프랙티스 전파에 큰 역할을 한다. 한국보다 한 박자 빠른 OTel 채택의 배경.

18. SLO/SLI와 에러 버짓 운영

옵저버빌리티의 끝은 **SLO(Service Level Objective)**다. "p99 응답시간이 200ms 이하이고, 가용성은 99.9%다"를 정의하고, 그걸 메트릭으로 모니터링하고, 어겼을 때 에러 버짓을 소진하는 모델이다.

도구:

- **Sloth** — Prometheus 기반 SLO 생성기. YAML로 SLO 정의

- **Pyrra** — Sloth와 비슷한 카테고리의 SLO 컨트롤러

- **OpenSLO** — SLO 정의의 YAML 표준

- **Nobl9** — SLO 전문 SaaS

- **Datadog SLO / Honeycomb SLO** — APM 내장 옵션

Sloth SLO 정의 예

version: prometheus/v1

service: my-api

slos:

- name: requests-availability

objective: 99.9

sli:

events:

error_query: sum(rate(http_requests_total{code=~"5.."}[5m]))

total_query: sum(rate(http_requests_total[5m]))

alerting:

page_alert:

labels:

severity: page

ticket_alert:

labels:

severity: ticket

19. 알림과 인시던트 관리

옵저버빌리티의 마지막 단계는 알림과 인시던트 대응이다.

- **Alertmanager** — Prometheus 생태계 표준

- **Grafana Alerting** — Grafana 통합 옵션 (멀티 데이터소스 지원)

- **PagerDuty** — 인시던트 관리의 SaaS 표준

- **Opsgenie** (Atlassian) — PagerDuty의 경쟁자

- **Incident.io** — 채팅 우선의 신세대 인시던트 관리. Slack 통합 강력

- **FireHydrant, Rootly** — 인시던트 관리 신생 SaaS

- **Better Stack** — Uptime 모니터링 + 인시던트 관리 통합

> **2026년의 흐름** — Slack/Teams가 인시던트 룸의 표준이 됐고, Incident.io 같은 도구는 그 위에서 자동으로 채널을 생성하고, 상태 페이지를 업데이트하고, 포스트모템을 시작한다. PagerDuty도 이 방향으로 빠르게 진화 중.

20. AI-native 옵저버빌리티의 윤곽

2026년의 가장 큰 화두는 **AI가 옵저버빌리티를 어떻게 바꿀 것인가**다.

- **자동 근본 원인 분석(RCA)** — Dynatrace Davis, New Relic AI, Datadog Bits AI

- **자연어 쿼리** — Honeycomb Query Assistant, Grafana LLM, Datadog AI Assistant

- **이상 탐지 자동화** — 모든 메이저 APM이 ML 기반 anomaly detection 제공

- **LLM 옵저버빌리티 자체** — LangSmith, Helicone, Phoenix, Arize, OpenLLMetry. LLM 응답의 latency/cost/quality를 트레이스

- **에이전트 트레이싱** — OTel의 GenAI semantic conventions가 2025년 발표. Agent 도구 호출의 트레이스 표준

> **AI 워크로드의 옵저버빌리티** — LLM은 비결정적이고 비쌌다. "이 사용자 요청이 GPT-4o로 갔는지 Claude 3.5로 갔는지, 토큰을 얼마나 썼는지, 누가 쿼리를 캐싱했는지"가 새로운 골든 시그널이 되고 있다.

21. 도입 로드맵 — 어디서 시작할 것인가

옵저버빌리티 스택을 새로 짠다면, 2026년 기준 추천 순서는 다음과 같다.

1. **메트릭 먼저** — Prometheus + Grafana로 시작. node-exporter, kube-state-metrics

2. **로그를 표준화** — Loki 또는 Elastic. Vector/Fluent Bit으로 수집 통일

3. **트레이스 도입** — Tempo + OTel Collector. 자동 계측부터

4. **eBPF로 가시성 80% 채우기** — Cilium Hubble 또는 Pixie 둘 중 하나

5. **continuous profiling 추가** — Pyroscope를 Grafana에 통합

6. **SLO 정의** — Sloth로 핵심 서비스 3-5개의 SLO를 YAML로

7. **AI/LLM 트레이싱** — LLM 사용한다면 LangSmith 또는 Phoenix를 OTel과 함께

8. **인시던트 관리 자동화** — Incident.io 또는 PagerDuty를 Slack에 통합

**스타트업 (1-20명)**:

- SaaS 풀 활용 — Datadog 또는 New Relic + Sentry + Better Stack

- 학습 곡선을 사지 말고 코드를 짜자

**중규모 (20-200명)**:

- Grafana Cloud + Sentry + Incident.io

- 비용을 보면서 LGTM 자가호스팅으로 점진 이전

**대규모 (200명+)**:

- LGTM 자가호스팅 + 일부 영역(RUM, APM)만 SaaS

- 전담 옵저버빌리티 플랫폼 팀

22. 참고 문헌

- [OpenTelemetry Project](https://opentelemetry.io)

- [OpenTelemetry CNCF Graduation Announcement](https://www.cncf.io/announcements/2024/09/12/cloud-native-computing-foundation-announces-opentelemetry-graduation/)

- [Cilium Project](https://cilium.io)

- [Hubble — Cilium Flow Observability](https://github.com/cilium/hubble)

- [Tetragon — eBPF Security Observability](https://tetragon.io)

- [Pixie — Auto-instrument K8s with eBPF](https://px.dev)

- [Inspektor Gadget](https://www.inspektor-gadget.io)

- [Grafana Pyroscope](https://grafana.com/oss/pyroscope/)

- [Grafana Tempo](https://grafana.com/oss/tempo/)

- [Grafana Loki](https://grafana.com/oss/loki/)

- [Grafana Mimir](https://grafana.com/oss/mimir/)

- [Jaeger 2 Announcement](https://www.jaegertracing.io/docs/2.0/)

- [Prometheus 3.0 Release Notes](https://prometheus.io/blog/2024/11/14/prometheus-3-0/)

- [VictoriaMetrics](https://victoriametrics.com)

- [Quickwit — Cloud-native Search](https://quickwit.io)

- [SigNoz — Open Source Observability](https://signoz.io)

- [Coroot — eBPF Observability](https://coroot.com)

- [Beyla — eBPF Auto-instrumentation](https://grafana.com/oss/beyla-ebpf/)

- [Brendan Gregg — BPF Performance Tools](https://www.brendangregg.com/bpf-performance-tools-book.html)

- [Google SRE Book — Service Level Objectives](https://sre.google/sre-book/service-level-objectives/)

- [Honeycomb — Observability Engineering Book](https://www.oreilly.com/library/view/observability-engineering/9781492076438/)

- [Datadog Pricing](https://www.datadoghq.com/pricing/)

- [Sloth — Prometheus SLO Generator](https://sloth.dev)

- [Falco — Runtime Security](https://falco.org)