✍️ 필사 모드: Kubernetes가 왜 이렇게 복잡한가 심화 가이드 — 아키텍처, Service Mesh, GitOps, Platform Engineering, Ambient Mesh, eBPF, Gateway API까지 (2025)

TL;DR — Kubernetes는 2014년 Google의 Borg 경험에서 탄생해, 2024년 기준 **Fortune 100의 96%**가 사용하는 사실상의 클라우드 OS다. 하지만 그 복잡도는 악명 높고 — 기본 리소스 40여 종, Istio만 추가해도 CRD 60+ 종, 운영자 1명이 이해해야 하는 개념 수백 개. 이 글은 "K8s는 왜 이렇게 복잡한가"라는 원질문에서 출발해, Control Plane 아키텍처, CNI/eBPF/Cilium, Service Mesh 논쟁(Istio Ambient vs sidecar), GitOps 혁명(ArgoCD, Flux), Platform Engineering(Backstage, IDP), Operator 패턴, Karpenter 자동 스케일, WASM 런타임까지 — 2025년 Kubernetes의 전 지형도와 실전 트레이드오프를 추적한다.

Kubernetes의 탄생과 확산

2003년 Google은 Borg라는 자사 클러스터 관리 시스템으로 수십만 머신을 운영하고 있었다. 2014년, Borg 설계자 Joe Beda, Brendan Burns, Craig McLuckie가 오픈소스 버전을 공개 — 이것이 Kubernetes(그리스어 "조타수"). 2015년 CNCF(Cloud Native Computing Foundation)가 설립되며 리누스 토르발즈 이후 가장 큰 오픈소스 프로젝트 중 하나가 된다.

확산 속도:

• 2015: CNCF 창립, 1.0 릴리스
• 2017: AWS EKS 발표 — Docker Swarm/Mesos 패배 확정
• 2019: 대부분 클라우드 업체 관리형 K8s 제공
• 2022: Fortune 500의 85% 도입
• 2024: Fortune 100의 96% 사용, 5.6M 개발자
• 2025: AI/ML 워크로드 집약 (Ray, Kubeflow, Dify)

K8s가 해결한 문제

1. 배포 자동화 — 선언형 YAML로 원하는 상태 기술
2. 자가 치유 — Pod 죽으면 자동 재시작
3. 수평 확장 — HPA/VPA/Karpenter
4. 서비스 디스커버리 — 내장 DNS + Service
5. 롤링 배포 — 다운타임 없는 업데이트
6. 리소스 관리 — CPU/메모리 제한 + 스케줄링
7. 스토리지 추상화 — CSI (Container Storage Interface)
8. 멀티 클라우드 — 동일 YAML이 AWS/GCP/Azure에서 동작

K8s가 새로 만든 문제

1. 인지 부담 폭발 — 40+ 기본 리소스, 수백 개 개념
2. 네트워킹 복잡 — CNI + kube-proxy + Ingress + Service Mesh
3. 보안 복잡 — RBAC, NetworkPolicy, PodSecurity, Secret 관리
4. 디버깅 어려움 — 왜 Pod가 Pending? 왜 502? 원인 추적 지옥
5. 업그레이드 지옥 — 3개월 릴리스 주기, API 변경
6. 비용 통제 어려움 — 리소스 과할당, idle node
7. 한 사람이 다 아는 건 불가능 — 팀 규모 최소 3명 이상 필요

"K8s는 정말 필요한가"라는 질문이 반복되는 이유다. 중소 서비스는 Heroku, Fly.io, Render, Vercel로 충분하다. K8s는 조직 규모, 워크로드 다양성, 멀티 클라우드 요구가 있을 때 가치가 드러난다.

Control Plane 아키텍처

K8s는 Control Plane + Data Plane(Worker Nodes)으로 나뉜다.

Control Plane (제어 평면)
┌─────────────────────────────────────────┐
│  kube-apiserver                          │
│  (모든 변경의 유일한 진입점, REST API)    │
│         ↕                                │
│  etcd (분산 KV 스토어, 클러스터 상태)    │
│         ↕                                │
│  kube-scheduler (Pod → Node 배정)        │
│  kube-controller-manager                 │
│  (ReplicaSet, Deployment, Job ... 루프)  │
│  cloud-controller-manager                │
│  (LoadBalancer, Volume ... 클라우드 통합)│
└─────────────────────────────────────────┘

Data Plane (Worker Nodes)
┌────────────┬────────────┬────────────┐
│ Node 1     │ Node 2     │ Node 3     │
│ kubelet    │ kubelet    │ kubelet    │
│ kube-proxy │ kube-proxy │ kube-proxy │
│ container  │ container  │ container  │
│ runtime    │ runtime    │ runtime    │
│ (containerd│(containerd │(containerd │
│  /CRI-O)   │  /CRI-O)   │  /CRI-O)   │
│ Pods...    │ Pods...    │ Pods...    │
└────────────┴────────────┴────────────┘

etcd — 모든 상태의 유일한 진실

etcd는 Raft 컨센서스 기반 분산 KV 스토어. 보통 3-5대. 모든 K8s 객체가 여기 저장.

• 버전: 홀수(3, 5, 7, ...) 유지 — 장애 허용 = (n-1)/2
• 크기 제한: 기본 2GB, 최대 8GB
• 성능: ~10000 writes/sec, 디스크 I/O 민감
• 백업 필수 — etcdctl snapshot save

주의: etcd 장애 = 클러스터 다운. 그래서 관리형 K8s(EKS, GKE)는 Control Plane을 클라우드 사업자가 운영.

API Server — 모든 변경의 문지기

모든 kubectl 명령, 컨트롤러, kubelet 호출이 여기로 향함. 인증 → 인가 → admission control → etcd 저장의 파이프라인.

Scheduler — Pod가 어느 Node에 가는가

2단계:

1. Filter — nodeSelector, affinity, taint/toleration, 리소스 맞는 노드만
2. Score — 남은 노드 중 최적 선택 (LeastRequested, 이미지 locality, ...)

Pod Topology Spread Constraints, PriorityClass 등으로 세밀 제어 가능.

Controller Manager — 무한 Reconciliation Loop

for {
    desired := getDesiredState()  // YAML에서
    current := getCurrentState()  // 실제 상태
    if desired != current {
        reconcile(desired, current)
    }
    sleep(resyncPeriod)
}

이 level-triggered 패턴이 K8s의 핵심 철학 — "명령형 if-then 대신 상태 선언".

Pod — 최소 배포 단위

Pod는 1개 이상의 컨테이너 묶음. 같은 네트워크 namespace와 볼륨 공유.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: my-app:1.0
    resources:
      requests: { cpu: 100m, memory: 128Mi }
      limits:   { cpu: 500m, memory: 512Mi }
    readinessProbe:
      httpGet: { path: /healthz, port: 8080 }
      initialDelaySeconds: 5
    livenessProbe:
      httpGet: { path: /healthz, port: 8080 }
      periodSeconds: 10
  - name: sidecar  # 같은 Pod의 부 컨테이너
    image: log-shipper:2.0

requests vs limits 차이:

• requests — 스케줄러가 보장하는 최소 리소스
• limits — 컨테이너가 넘을 수 없는 상한

OOMKilled(메모리 초과 시 강제 종료), CPU throttling(CPU 초과 시 느려짐) — 이 둘이 가장 흔한 장애 원인.

Probe 3종

• startupProbe — 느린 앱 초기화 (JVM) 보호. 성공하면 이후 다른 probe 활성화
• livenessProbe — "죽었나?" 실패 시 재시작
• readinessProbe — "트래픽 받을 준비?" 실패 시 Service endpoint에서 제외

흔한 실수: liveness를 DB 연결까지 확인하게 만들면, DB 지연으로 전체 Pod 재시작 → 폭주.

Deployment, StatefulSet, DaemonSet, Job

Deployment — Stateless 앱

apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
  replicas: 3
  selector: { matchLabels: { app: web } }
  template:
    metadata: { labels: { app: web } }
    spec:
      containers:
      - name: web
        image: web:v2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 업데이트 중 최대 +1 Pod
      maxUnavailable: 0  # 다운 허용 0

StatefulSet — 정체성 있는 Pod

• 이름이 고정 (web-0, web-1, web-2)
• 순차 배포 / 역순 삭제
• 각 Pod별 영구 볼륨
• 사용처: DB, Kafka, Redis cluster

DaemonSet — 노드마다 1 Pod

• 모든 노드(또는 nodeSelector에 맞는 노드)에 1개씩
• 사용처: 로그 수집(Fluent Bit), 모니터링 에이전트, CNI plugin

Job / CronJob — 배치/스케줄 작업

• Job — 완료될 때까지 실행
• CronJob — cron 표현식 스케줄

Service — 내부 로드 밸런서

Pod는 IP가 변하지만 Service는 안정적인 DNS/IP 제공.

apiVersion: v1
kind: Service
metadata: { name: web-svc }
spec:
  selector: { app: web }
  ports: [{ port: 80, targetPort: 8080 }]
  type: ClusterIP   # 기본 — 클러스터 내부만
  # type: NodePort     — 각 노드의 특정 포트로 노출
  # type: LoadBalancer — 클라우드 LB 생성

Service는 kube-proxy가 iptables 또는 IPVS 규칙으로 구현. Cilium은 eBPF로 대체.

Ingress — HTTP L7 라우팅

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /users
        pathType: Prefix
        backend: { service: { name: user-svc, port: { number: 80 } } }

Ingress 컨트롤러 선택지: NGINX Ingress, Traefik, HAProxy, AWS ALB Controller, GKE Ingress.

Gateway API — Ingress의 후계자

2023년 GA. Ingress의 한계(L7 제한, 다중 테넌시 어려움)를 해결.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: { name: api-route }
spec:
  parentRefs:
  - name: my-gateway
  hostnames: ["api.example.com"]
  rules:
  - matches: [{ path: { type: PathPrefix, value: /users } }]
    backendRefs:
    - name: user-svc
      port: 80

장점: 역할 분리(Gateway는 인프라 팀, HTTPRoute는 앱 팀), 표준 L7, TCP/UDP 지원, traffic splitting.

CNI — Container Network Interface

모든 Pod에 고유 IP를 주고 서로 통신 가능하게. CNI plugin이 구현.

주요 CNI

eBPF — 커널 안의 작은 VM

eBPF(extended Berkeley Packet Filter)는 리눅스 커널에서 검증된 바이트코드를 실행하는 샌드박스. 2014년 도입, 2020년대 폭발.

• Cilium — L7까지 eBPF로 처리, kube-proxy 대체
• Falco — eBPF 기반 보안 감사
• Pixie — eBPF 기반 K8s observability
• Tetragon — eBPF 실시간 런타임 보안

eBPF는 컨테이너 런타임, 네트워킹, observability를 재정의 중. 2024년 CNCF Graduated project.

Service Mesh — sidecar vs Ambient 논쟁

Service Mesh는 마이크로서비스 간 통신 관리 계층: mTLS, retry, circuit breaker, traffic splitting, observability.

Sidecar 패턴 (Istio, Linkerd 전통)

각 Pod에 Envoy/proxy 컨테이너 추가.

Pod {
  App Container
  Envoy Sidecar  ← 모든 in/out 트래픽 intercept
}

장점: 앱 변경 없음, 언어 무관. 단점: 리소스 2배, Pod당 수백MB 메모리, 업그레이드 어려움.

Ambient Mesh (Istio 2022-2024)

Sidecar 없애고 노드 단위 ztunnel + Waypoint Proxy로 대체.

Node {
  ztunnel (L4: mTLS, observability)
  Pod A, Pod B, Pod C  ← sidecar 없음
}

+ Waypoint (L7 기능 필요 시 namespace당 배포)

장점: 리소스 절약, 점진적 도입 가능, 업그레이드 Pod 재시작 불필요. 단점: 2024년 GA, 아직 성숙도 낮음.

주요 Service Mesh

Service Mesh는 정말 필요한가

2024-2025 현장에서 답은 "대부분은 필요 없다"로 수렴. 이유:

• Ingress Controller + NetworkPolicy로 80% 해결
• Observability는 OpenTelemetry로 가능
• mTLS는 cert-manager + SPIFFE로 가능
• Service Mesh 학습/운영 비용이 이득 초과

도입 기준: 마이크로서비스 50+ 이상, 멀티 팀 독립 배포, 엄격한 zero-trust 요구.

GitOps — 배포의 선언형 혁명

2017년 Weaveworks가 제안. "Git은 프로덕션의 유일한 진실". 파이프라인이 아니라 풀(pull) 기반 동기화.

[Developer] → [Git PR] → [Merge] 
                             ↓
[ArgoCD/Flux Controller] ← git poll
                             ↓
       (diff 감지)
                             ↓
[K8s Apply]

ArgoCD

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata: { name: my-app }
spec:
  project: default
  source:
    repoURL: https://github.com/org/repo
    path: k8s/overlays/prod
    targetRevision: HEAD
  destination:
    server: https://kubernetes.default.svc
    namespace: prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

• 웹 UI 제공, 여러 앱 한눈에
• App of Apps 패턴
• Rollback = git revert

Flux

• CNCF Graduated
• Helm, Kustomize, OCI artifacts 지원
• 경량화 (UI 없음, fluxcd CLI)
• 2024년 Flagger 통합으로 progressive delivery

GitOps가 해결한 문제

• "프로덕션에 뭐가 배포됐는지 몰라" → git이 진실
• "kubectl 누가 뭘 바꿨지?" → 직접 변경 자동 되돌림 (drift detection)
• "rollback 어떻게?" → git revert

Helm vs Kustomize vs Jsonnet

매니페스트 관리 도구 3대장.

Helm

• 템플릿 엔진 (Go template)
• Chart 패키징, Helm Hub 생태계
• values.yaml로 환경별 오버라이드

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: "{"{"}}{"{"} .Release.Name {"}"}{"}"}"
spec:
  replicas: "{"{"}}{"{"} .Values.replicas {"}"}{"}"}"

장점: 광대한 생태계 (nginx, redis, postgres 공식 chart). 단점: 템플릿 지옥, 디버깅 어려움.

Kustomize

• 오버레이 패턴, 템플릿 없이 patch
• kubectl 내장

# base/deployment.yaml — 공통
# overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
patches:
  - patch: |-
      - op: replace
        path: /spec/replicas
        value: 10
    target: { kind: Deployment }

장점: 템플릿 없이 순수 YAML, 디버깅 쉬움. 단점: Helm 생태계 부재.

Jsonnet / CUE / KCL

• JSON/YAML을 프로그래밍 언어로 생성
• Grafana, Databricks 사용
• CUE는 Google 내부 구성 언어에서 유래
• KCL(Kusion)은 2024년 CNCF Sandbox 진입, Kubernetes 특화

Operator 패턴 — CRD로 K8s 확장

DB, Kafka, Cert-Manager 같은 stateful 앱을 K8s에 통합하는 표준 방식.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata: { name: postgresqls.db.acme.io }
spec:
  group: db.acme.io
  versions: [{ name: v1, served: true, storage: true, schema: {...} }]
  scope: Namespaced
  names: { plural: postgresqls, singular: postgresql, kind: PostgreSQL }

이제 사용자는:

apiVersion: db.acme.io/v1
kind: PostgreSQL
metadata: { name: my-db }
spec:
  version: "16"
  replicas: 3
  storage: 100Gi

Operator(컨트롤러)가 이를 실제 StatefulSet, Service, PVC, ConfigMap으로 변환 + 백업/장애 대응.

유명한 Operator

• Prometheus Operator — 모니터링
• cert-manager — TLS 자동화
• CloudNativePG, Zalando PG Operator — PostgreSQL
• Strimzi — Kafka
• Elastic Operator — Elasticsearch
• Istio Operator — Istio 설치
• ArgoCD Operator — ArgoCD 관리
• Crossplane — 클라우드 리소스를 K8s 리소스로

OperatorHub.io

600+ 공식 operator. "K8s Native"의 대부분 뜻하는 것.

Platform Engineering — 플랫폼 팀의 부상

Platform Engineering은 2022-2023년 급부상. "개발자 생산성을 제품으로 다루는 팀".

왜 Platform Engineering인가

• DevOps "you build it, you run it"이 너무 큰 부담
• 모든 팀이 K8s, Terraform, Argo, 모니터링을 전문가 수준으로 다 할 수 없음
• Internal Developer Platform (IDP) — 사내 Heroku 같은 추상화 제공

Backstage (Spotify, 2020 CNCF 기증)

Platform Engineering의 UI 표준.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: user-service
  annotations:
    github.com/project-slug: org/user-service
    sentry.io/project-slug: user-service
spec:
  type: service
  lifecycle: production
  owner: team-platform
  system: user-management

• Software Catalog — 사내 서비스/API/라이브러리 목록
• Scaffolder — 템플릿 기반 서비스 생성
• TechDocs — Markdown 기반 문서 자동 배포
• Integrations — GitHub, PagerDuty, Prometheus, ArgoCD, ...

Humanitec, Port, Cortex, Mia-Platform

Backstage의 SaaS 대안들. 2024-2025년 IDP 시장 폭발.

Platform as Product 철학

• 내부 사용자를 '고객'으로
• OKR, NPS 측정
• 기능은 adoption으로 검증
• 문서화와 DX가 성공의 80%

Autoscaling — HPA, VPA, Karpenter

HPA (Horizontal Pod Autoscaler)

Pod 수를 늘이고 줄임. CPU/메모리/커스텀 메트릭 기반.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: web-hpa }
spec:
  scaleTargetRef: { kind: Deployment, name: web }
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }

KEDA (Kubernetes Event-Driven Autoscaling) — Kafka 랙, SQS depth, Prometheus 쿼리 등 60+ 스케일러.

VPA (Vertical Pod Autoscaler)

Pod의 requests/limits 자동 조정. 재시작 필요해서 권장 모드만(recommend) 쓰는 경우 많음.

Cluster Autoscaler vs Karpenter

Cluster Autoscaler — 전통적, node group 기반, 느림. Karpenter (AWS, 2021) — just-in-time 노드 프로비저닝, 수초 내, 비용 최적화 자동.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata: { name: default }
spec:
  template:
    spec:
      requirements:
      - key: "karpenter.sh/capacity-type"
        operator: In
        values: ["spot", "on-demand"]  # Spot 우선
      - key: "kubernetes.io/arch"
        operator: In
        values: ["amd64", "arm64"]
  limits: { cpu: "1000" }
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h

Karpenter로 비용 30-50% 감소 사례 흔함.

비용 최적화 — 2024 핵심 이슈

K8s의 보이지 않는 비용 문제:

• 과도한 requests → 유휴 리소스 다량
• idle node → 시간당 돈
• PVC 미사용 → 스토리지 비용
• 로그/메트릭 보관 → 관찰 도구 비용

도구

• OpenCost — CNCF 프로젝트, 네임스페이스/워크로드별 비용
• Kubecost — OpenCost의 상업 버전, UI 강력
• Cast.ai — 자동 최적화 SaaS
• Spot.io (NetApp) — Spot 인스턴스 자동 관리
• Datadog Cost Management — APM + 비용 통합

체크리스트

1. Karpenter + Spot 70% 이상
2. Right-sizing (VPA recommend + 수동 조정)
3. HPA + PodDisruptionBudget
4. 미사용 PVC, namespace 정리
5. 개발/스테이징 nightly shutdown
6. Prometheus 메트릭 cardinality 감소

Observability — 3 pillars + eBPF

Metrics (Prometheus + Grafana)

• 표준 조합. 서비스별 exporter, PromQL
• Thanos, Cortex, Mimir로 장기 저장
• VictoriaMetrics (대안, 성능 강점)

Logs (Loki, Elastic, Datadog)

• Loki: Grafana Labs, 라벨 기반 저장 (저비용)
• Elastic: 전문 검색 강점
• Vector (Datadog), Fluent Bit: 로그 수집

Traces (OpenTelemetry + Jaeger/Tempo)

• OpenTelemetry가 2024년 de facto 표준
• 언어별 SDK + Collector
• Tempo, Jaeger, Zipkin, Datadog, Honeycomb 백엔드

Continuous Profiling (2024 주류화)

• Parca, Pyroscope, Grafana Cloud Profiling — eBPF로 CPU/메모리 프로파일링
• "왜 이 Pod가 CPU를 많이 쓰는지" 런타임 확인

2025년 Kubernetes 트렌드

WASM 런타임

• SpinKube (Fermyon, CNCF Sandbox) — WASM을 K8s 1차 시민으로
• wasmCloud — 분산 WASM 액터 모델
• Kwasm — kubelet에 WASM 런타임 주입
• 장점: 콜드 스타트 수 ms, 샌드박싱 강력, 언어 무관

AI/ML 워크로드

• KubeRay — Ray(분산 AI 프레임워크) K8s Operator
• Kubeflow — ML 파이프라인
• Volcano — 배치 + gang scheduling (GPU 공유)
• NVIDIA GPU Operator — GPU driver + 런타임 자동화

CRD as API

• Crossplane — AWS/GCP 리소스도 K8s manifest로
• Terraform Controller, Atlas — 선언형 클라우드 리소스

Confidential Containers

• TEE(Intel SGX, AMD SEV)로 암호화된 컨테이너
• 헬스케어, 금융 규제 대응

대안 — K8s가 과한 경우

"K8s가 과했다"는 후기는 2023-2024년 여럿 — 37signals의 HEY 탈 K8s 회자됨.

실전 운영 체크리스트 (2025)

1. 관리형 사용 — EKS, GKE, AKS 우선. 자체 운영은 팀 10명+일 때만
2. 버전 전략 — 최신 -1, -2 유지, 6개월마다 업그레이드
3. RBAC 최소 권한 — view/edit/admin 기본 롤 활용
4. NetworkPolicy 기본 deny — 기본 egress 차단
5. PodSecurityStandard — restricted 프로필 기본
6. Secret 관리 — External Secrets + Vault/AWS Secrets Manager
7. Backup — Velero + etcd snapshot
8. GitOps — ArgoCD 또는 Flux, kubectl apply 금지
9. Monitoring — Prometheus + Grafana + Loki
10. Cost — Kubecost/OpenCost + Karpenter + Spot
11. Platform Eng. — Backstage IDP 구축 (팀 50명+일 때)
12. Disaster Recovery — multi-region 또는 multi-cluster 훈련 분기별

10가지 흔한 안티패턴

1. latest 태그 — 롤백 불가, 재현 불가
2. 리소스 requests 없음 — 스케줄러 오판, QoS BestEffort
3. liveness에 DB 포함 — 폭주 재시작
4. Node SSH 직접 변경 — drift, GitOps 원칙 파괴
5. Namespace 없이 default에 모두 — 권한/격리 파괴
6. ClusterRoleBinding 남발 — 권한 과도
7. LoadBalancer Service 서비스마다 — 클라우드 LB 수십 개 = 비용 폭탄
8. 모든 것을 Operator로 — 오버엔지니어링, 유지보수 부담
9. Service Mesh 먼저, 필요 확인 나중 — 복잡도 2-3배 증가
10. CRD 난립 — CRD 50+ 되면 누구도 전체 이해 불가

다음 글 예고 — "관측 가능성(Observability)의 현재" — Prometheus, OpenTelemetry, eBPF, Continuous Profiling 심화

K8s를 다뤘으니 그 다음은 **"그래서 시스템이 지금 뭐 하고 있는지 어떻게 아는가"**다. 2024-2025년 관측 가능성(Observability)은 혁명의 한복판에 있다. OpenTelemetry 1.0 GA, eBPF 기반 agentless 프로파일링, Continuous Profiling의 주류화, Datadog vs Grafana vs Honeycomb vs New Relic의 경쟁 구도가 완전히 재편됐다.

다음 글에서는:

• 3 pillars + profiling — Metrics, Logs, Traces, Continuous Profiling
• Prometheus 깊이 — PromQL, cardinality 지옥, Thanos/Cortex/Mimir
• OpenTelemetry 1.0 — 왜 de facto 표준이 됐나
• 분산 트레이싱 — span propagation, W3C trace-context
• eBPF Observability — Pixie, Parca, Pyroscope, Beyla
• Structured Logging — Loki, Elastic, Vector, Fluent Bit
• SLO/SLI/Error Budget — Google SRE의 대중화
• Alerting 철학 — page-worthy vs dashboard
• Chaos Engineering — Litmus, Chaos Mesh, Gremlin
• 상업 SaaS 비교 — Datadog, Honeycomb, Grafana Cloud, New Relic 2025 시점

을 다룬다. '모르는 것을 알게 되는 기술', 현대 시스템 운영의 가장 중요한 역량을 원리부터 실전까지 추적한다.