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가 해결한 문제

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

K8s가 새로 만든 문제

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

Filter — nodeSelector, affinity, taint/toleration, 리소스 맞는 노드만
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

CNI	방식	특징
Flannel	VXLAN overlay	가장 단순, 시작용
Calico	BGP routing	NetworkPolicy 강점, 대규모
Cilium	eBPF	성능 최강, observability
Weave Net	VXLAN	가장 오래됨
AWS VPC CNI	AWS ENI 직접	EKS 기본
Azure CNI	Azure VNet	AKS 기본
GKE Dataplane V2	Cilium 기반	GKE 기본

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

Mesh	제공자	특징
Istio	Google/IBM	기능 최다, 복잡도 최고, Ambient 신규
Linkerd	Buoyant	단순, 성능 좋음, Rust로 쓰인 데이터 플레인
Consul Connect	HashiCorp	멀티 플랫폼(VM+K8s)
Cilium Service Mesh	Isovalent	eBPF 기반, sidecar 없음
Kuma	Kong	엔터프라이즈

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 + 비용 통합

체크리스트

Karpenter + Spot 70% 이상
Right-sizing (VPA recommend + 수동 조정)
HPA + PodDisruptionBudget
미사용 PVC, namespace 정리
개발/스테이징 nightly shutdown
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가 과한 경우

도구	적합한 경우
Heroku	초기 스타트업, < 20 서비스
Fly.io	Edge + 지역 배포, WebSocket 워크로드
Render	Heroku 유사, Postgres 내장
Railway	PaaS, 심플
Vercel/Netlify	프론트엔드 + Serverless
AWS ECS/Fargate	AWS 중심 + K8s 복잡도 피함
Cloud Run (GCP)	요청 기반 과금, HTTP만
Nomad (HashiCorp)	비컨테이너 + VM 워크로드

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

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

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

10가지 흔한 안티패턴

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

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