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

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

프롤로그 — "AWS VM 30개에 $30K/월 → EKS + Karpenter + Spot으로 $8K/월"

2025년 4월, 당신의 팀은 EC2 온디맨드 30대로 월 $30K를 쓴다.

- **문제**: 트래픽은 밤엔 10%, 낮엔 100%. 그런데 24시간 30대 풀가동

- **해결 1**: EKS로 마이그레이션 → Pod 기반 bin-packing (20% 절감)

- **해결 2**: Karpenter로 노드 자동 스케일링 (30% 절감)

- **해결 3**: Spot Instance 70% + On-demand 30% (50% 절감)

- **결과**: 월 $8K, 73% 절감

네트워크(Ep 14)가 배관이라면, 클라우드 네이티브는 **그 위의 도시**다.

2025년 인프라 표준은 **컨테이너 + Kubernetes + GitOps + eBPF**.

이제 "서버 한 대 SSH로 배포"는 스타트업도 안 한다.

이 글은 Season 2 Ep 15 — **클라우드 네이티브**.

Kubernetes Pod/Service/Ingress/CRD, Serverless 선택 기준, eBPF가 왜 혁명인지, Container Runtime 진화, GitOps 두 가지 플레이어(ArgoCD/Flux), Karpenter와 Spot으로 70% 비용 절감까지.

1부 — 클라우드 네이티브는 무엇인가

CNCF의 정의

**"클라우드 네이티브(Cloud Native)"**는:

- **컨테이너화**(Containerized)

- **동적 오케스트레이션**(Dynamically Orchestrated)

- **마이크로서비스 지향**(Microservices Oriented)

핵심 속성: **탄력성(Elasticity), 관측 가능성(Observability), 선언적 배포(Declarative)**

2025년 CNCF Landscape — 1,700+ 프로젝트

| 카테고리 | 대표 프로젝트 |

|---|---|

| Orchestration | Kubernetes, Nomad |

| Container Runtime | containerd, CRI-O, Kata, Firecracker |

| Service Mesh | Istio, Linkerd, Cilium |

| Observability | Prometheus, OpenTelemetry, Grafana |

| CI/CD | ArgoCD, Flux, Tekton |

| Security | Falco, Kyverno, OPA |

| Storage | Longhorn, Rook, OpenEBS |

| Networking | Cilium, Calico, Envoy |

**2025 Graduated**: Kubernetes, Prometheus, Envoy, etcd, Helm, Fluentd, Jaeger, CoreDNS, containerd, Cilium, Falco, OpenTelemetry(부분)

2부 — Kubernetes 핵심 개념 30분 정리

K8s는 무엇을 해결하는가

문제: 컨테이너 1000개를 어디에 어떻게 띄우지?

죽으면 누가 살리지? 트래픽은 어떻게 분산?

업데이트는? 롤백은? 스케일링은?

해결: Kubernetes — "선언적으로 원하는 상태를 말하면 클러스터가 맞춘다"

핵심 오브젝트 10개

| 오브젝트 | 역할 | 비유 |

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

| **Pod** | 컨테이너 1개+ 실행 단위 | 기본 셀 |

| **Deployment** | Pod 복제본 관리, rolling update | 매니저 |

| **Service** | 안정적 IP/DNS로 Pod 접근 | 전화번호 |

| **Ingress** | 외부 HTTP/HTTPS 라우팅 | 정문 |

| **ConfigMap** | 설정 주입 | 설정 파일 |

| **Secret** | 민감 정보 | 금고 |

| **PersistentVolume** | 영속 스토리지 | 하드디스크 |

| **Namespace** | 논리적 격리 | 방 |

| **StatefulSet** | 순서/이름 보장 Pod (DB) | 줄 |

| **DaemonSet** | 모든 노드에 Pod 1개 | 시큐리티 |

최소 예시 — Deployment + Service

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

replicas: 3

selector:

matchLabels: { app: web }

template:

metadata:

labels: { app: web }

spec:

containers:

- name: web

image: nginx:1.27

ports: [{ containerPort: 80 }]

resources:

requests: { cpu: 100m, memory: 128Mi }

limits: { cpu: 500m, memory: 512Mi }

livenessProbe:

httpGet: { path: /health, port: 80 }

readinessProbe:

httpGet: { path: /ready, port: 80 }

apiVersion: v1

kind: Service

metadata: { name: web }

spec:

selector: { app: web }

ports: [{ port: 80, targetPort: 80 }]

type: ClusterIP

`kubectl apply -f` — 선언적 배포. "3개 있어야 해" → 클러스터가 유지.

스케줄링 — 어느 노드에 Pod를 둘까

spec:

nodeSelector: { disktype: ssd }

affinity:

nodeAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

- matchExpressions:

- key: topology.kubernetes.io/zone

operator: In

values: [us-east-1a, us-east-1b]

podAntiAffinity:

preferredDuringSchedulingIgnoredDuringExecution:

- weight: 100

podAffinityTerm:

labelSelector: { matchLabels: { app: web } }

topologyKey: kubernetes.io/hostname

tolerations:

- key: spot

operator: Equal

value: "true"

effect: NoSchedule

**규칙**:

- `nodeSelector`: 단순 매칭

- `nodeAffinity`: 복잡한 조건 (required/preferred)

- `podAntiAffinity`: "같은 노드에 같은 앱 두지 마라" (HA)

- `taints + tolerations`: "이 노드는 특수 목적"

Resource Request vs Limit — 가장 많이 실수하는 것

Request: 스케줄러가 "이만큼 있어야 해" → 빈 노드 찾기

Limit: 컨테이너가 넘으면 → CPU는 throttle, 메모리는 OOM Kill

규칙:

- Request는 항상 설정 (없으면 0으로 간주 → 과밀집)

- Limit은 CPU는 보통 안 둠(throttle이 성능 저하), Memory는 반드시

- Request = Limit → Guaranteed QoS (최우선)

HPA + VPA + Cluster Autoscaler

- **HPA (Horizontal)**: Pod 개수 조정. CPU/Memory/Custom 지표

- **VPA (Vertical)**: Pod 하나의 request/limit 조정

- **CA (Cluster Autoscaler)**: 노드 개수 조정

- **Karpenter**: AWS/Azure용 "CA 킬러" — 50% 빠름, Spot 친화적

3부 — CRD와 Operator 패턴

CRD — Kubernetes API를 확장하는 법

apiVersion: apiextensions.k8s.io/v1

kind: CustomResourceDefinition

metadata:

spec:

group: example.com

names:

kind: Database

plural: databases

scope: Namespaced

versions:

- name: v1

served: true

storage: true

schema:

openAPIV3Schema:

type: object

properties:

spec:

type: object

properties:

engine: { type: string, enum: [postgres, mysql] }

storage: { type: string }

이제 이런 리소스 생성 가능

apiVersion: example.com/v1

kind: Database

metadata: { name: prod-db }

spec:

engine: postgres

storage: 100Gi

Operator — "관리 지식을 코드로"

**정의**: CRD + Controller(지속 감시 + reconcile 루프)

**예시**: Postgres Operator가 "Database" CRD를 보면 → StatefulSet + PVC + Secret 자동 생성, 백업, 업그레이드

**2025 유명 Operator**:

- **Postgres**: Zalando, Crunchy, CloudNativePG

- **MySQL**: Oracle Operator, Percona

- **Kafka**: Strimzi

- **Redis**: Redis Enterprise, Spotahome

- **ArgoCD, cert-manager, external-secrets**

Kubebuilder로 Operator 작성

// controllers/database_controller.go

func (r *DatabaseReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {

var db examplev1.Database

if err := r.Get(ctx, req.NamespacedName, &db); err != nil {

return ctrl.Result{}, client.IgnoreNotFound(err)

}

// 원하는 상태: StatefulSet 있어야 함

sts := &appsv1.StatefulSet{ObjectMeta: metav1.ObjectMeta{Name: db.Name, Namespace: db.Namespace}}

_, err := ctrl.CreateOrUpdate(ctx, r.Client, sts, func() error {

sts.Spec = buildPostgresStatefulSet(&db)

return ctrl.SetControllerReference(&db, sts, r.Scheme)

})

return ctrl.Result{RequeueAfter: 30 * time.Second}, err

}

**Reconcile Loop**: "현재 상태 → 원하는 상태" 차이를 계속 좁힌다.

4부 — Serverless vs Container vs VM

3가지 모델 비교

| 항목 | VM | Container | Serverless |

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

| Cold start | 수 분 | 초 | ms ~ 초 |

| 과금 | 시간당 | 시간당 | 실행 시간 |

| 상태 | 가능 | 가능 (PV) | 무상태 원칙 |

| 운영 부담 | 높음 | 중간 | 낮음 |

| 유연성 | 높음 | 높음 | 제한적 |

Serverless 2025 랜드스케이프

| 제공자 | 특징 | 적합 사용처 |

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

| **AWS Lambda** | 15분 max, Layer, provisioned concurrency | 이벤트 처리, API |

| **Cloudflare Workers** | V8 isolate, 5ms cold start, 전 세계 edge | Edge 로직, API |

| **Vercel Functions** | Next.js 통합, Edge runtime | 프론트 백엔드 |

| **GCP Cloud Run** | 컨테이너 기반 서버리스, 1GB 이미지 OK | 컨테이너 워크로드 |

| **Fly.io** | 지역 배포, postgres 통합 | 풀스택 앱 |

| **Modal** | GPU 서버리스, Python 친화 | ML 추론, 배치 |

선택 기준

선택 A: Serverless (Lambda, Workers, Cloud Run)

조건:

- 이벤트 기반 (HTTP, S3 upload, DB 변경)

- 트래픽 불규칙

- Stateless

- 운영 인력 최소화

선택 B: Container (Kubernetes, Nomad)

조건:

- 상시 실행

- 복잡한 워크로드 (GPU, large memory)

- 운영 팀 있음

- Stateful 가능

선택 C: VM

조건:

- 특수 하드웨어

- 레거시 앱

- 규정 (강한 격리 필요)

5부 — eBPF 혁명

eBPF는 무엇인가

eBPF = Extended Berkeley Packet Filter

"커널 안에서 샌드박스 프로그램 실행" — 재컴파일 없이

원래 패킷 필터(tcpdump의 BPF) → 2014년 eBPF로 확장 → 2020년대 폭발

**쓰이는 곳**:

- **네트워킹**: Cilium (L3-7 네트워킹 + Service Mesh)

- **보안**: Falco (런타임 위협 탐지), Tetragon

- **관측**: Pixie (무계측 관측), Parca (continuous profiling)

- **스토리지**: 일부 드라이버

- **LLVM + BTF**: 커널 버전 불문 실행 (CO-RE)

Cilium — eBPF 기반 CNI + Service Mesh

기능:

- CNI (Pod 네트워킹)

- NetworkPolicy (L3-7 규칙)

- Service Mesh (mTLS 지원, 사이드카 없음)

- Load Balancing (XDP 가속)

- Observability (Hubble)

**사이드카 없는 Service Mesh**: Istio의 사이드카 per Pod → 메모리 50MB+ per Pod.

Cilium은 노드에 eBPF 프로그램 하나 → **메모리 90% 절감**.

Falco — 런타임 위협 탐지

falco rule

- rule: Shell in Container

desc: Shell 프로세스가 컨테이너에서 실행됨

condition: container and (proc.name in (bash, sh))

output: "Shell in container (user=%user.name container=%container.id)"

priority: WARNING

**원리**: eBPF로 syscall 훅 → 규칙 매칭 → 알림

Pixie — 무계측 관측

에이전트 설치 → 모든 HTTP, gRPC, MySQL 트래픽 자동 관측

별도 코드 변경 X

eBPF로 TLS 이전에 HTTP 디코드 (암호화되기 전 가로챔)

6부 — Container Runtime 진화

계층 구조

kubelet

↓ CRI (Container Runtime Interface)

containerd / CRI-O

↓ OCI (Open Container Initiative)

runc / crun / Kata / gVisor / Firecracker

주요 런타임 비교

| 런타임 | 격리 | 성능 | 사용처 |

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

| **runc** | Linux namespace + cgroup | 최고 | 기본 |

Firecracker — Lambda의 비밀

Amazon이 Lambda/Fargate용으로 제작

Rust로 작성, 초경량 VMM

Boot time: 125ms

Memory: 5MB 오버헤드

Use: AWS Lambda, Fly.io, Koyeb, Modal

**왜 중요한가**: "컨테이너의 속도 + VM의 격리"를 동시에. 멀티테넌트 서버리스의 기반.

WebAssembly Runtime (2024-2025 부상)

wasmtime, wasmer, spin (Fermyon)

Container보다 작고 빠름 (KB 수준 바이너리)

크로스 아키텍처 (ARM/x86 공통)

Cold start ms 단위

한계: 시스템 콜 제한, 기존 앱 마이그레이션 어려움

**Runwasi** — Kubernetes에서 Wasm 직접 실행 (containerd shim).

7부 — GitOps 워크플로우

GitOps 원칙 (Weaveworks, 2017)

1. 선언적 (Declarative): YAML이 원하는 상태

2. 버전 관리 (Versioned): Git이 Single Source of Truth

3. 자동 적용 (Automated): Agent가 Git → 클러스터 sync

4. 지속 조정 (Continuously Reconciled): drift 감지 시 복원

**Push 모델 (구식)**: CI가 `kubectl apply` → 클러스터 외부에서 접근

**Pull 모델 (GitOps)**: 클러스터 안 Agent가 Git 폴링 → 더 안전

ArgoCD vs Flux

| 항목 | ArgoCD | Flux |

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

| UI | 강력 | 없음 (CLI) |

| 멀티 클러스터 | ApplicationSet | Flux의 Fleet |

| Helm 지원 | 기본 | 기본 |

| Kustomize | 기본 | 기본 |

| ApplicationSet | generator 기반 동적 생성 | N/A |

| 학습 곡선 | 중간 | 높음 (더 CLI 중심) |

| 2025 추세 | **지배적** | 유지 |

ArgoCD 최소 예시

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

namespace: argocd

spec:

project: default

source:

repoURL: https://github.com/myorg/infra

targetRevision: main

path: apps/web/overlays/prod

destination:

server: https://kubernetes.default.svc

namespace: web-prod

syncPolicy:

automated:

prune: true

selfHeal: true

syncOptions:

- CreateNamespace=true

**특징**:

- `automated.prune`: Git에서 삭제된 리소스 클러스터에서도 제거

- `automated.selfHeal`: 클러스터 drift 시 복원

- Image updater → ECR/Docker Hub 새 이미지 감지 → Git PR

GitOps 폴더 구조 (Kustomize)

infra/

├── base/

│ └── web/

│ ├── deployment.yaml

│ ├── service.yaml

│ └── kustomization.yaml

└── overlays/

├── dev/

│ ├── kustomization.yaml

│ └── replicas-patch.yaml

├── staging/

└── prod/

**원칙**: base는 공통, overlays는 환경별 patch.

8부 — Helm vs Kustomize vs Timoni

Helm (2015-) — 템플릿 기반

values.yaml

replicas: 3

image:

repository: nginx

tag: "1.27"

templates/deployment.yaml

spec:

replicas: {{ .Values.replicas }}

template:

spec:

containers:

- image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

**장점**: 생태계 가장 큼 (Artifact Hub 15,000개+), 릴리즈 관리

**단점**: Go 템플릿 문자열 조작 → 복잡해지면 지옥

Kustomize (2018-) — Patch 기반

base/deployment.yaml (순수 YAML)

spec:

replicas: 3

template:

spec:

containers:

- image: nginx:1.27

overlays/prod/kustomization.yaml

resources:

- ../../base

patches:

- path: replicas-patch.yaml

**장점**: 순수 YAML, 템플릿 언어 없음, kubectl 내장

**단점**: 복잡한 동적 생성 어려움

Timoni (2023-) — CUE 기반 신기술

// CUE로 타입 검증 + 제약 가능

#WebApp: {

replicas: int & >=1 & <=100

image: string

resources: {

requests: cpu: string

limits: memory: string

}

**특징**: 강한 타입, 검증 내장, Helm의 "문자열 조작" 문제 없음

**2025 현실**: 점진적 채택. Helm 생태계가 너무 커서 완전 대체는 시간 걸림

9부 — Kubernetes 비용 최적화

비용 구조 파악

클러스터 비용 = 노드(VM) + LB + 스토리지 + 네트워크 송출 + 관리형 제어 plane

→ 대부분 노드 비용

절감 전략 6가지

1. Right-sizing

VPA recommender 모드

kubectl apply -f vpa-recommender.yaml

실제 사용 대비 request 권장치 확인

kubectl describe vpa web

**발견**: 대부분 팀이 request를 2-3x 과할당. VPA로 반절 가능.

2. Karpenter — Cluster Autoscaler의 진화

apiVersion: karpenter.sh/v1beta1

kind: NodePool

metadata: { name: default }

spec:

template:

spec:

requirements:

- key: node.kubernetes.io/instance-type

operator: In

values: [m5.large, m5.xlarge, m6i.large, c5.large]

- key: karpenter.sh/capacity-type

operator: In

values: [spot, on-demand]

nodeClassRef: { name: default }

disruption:

consolidationPolicy: WhenUnderutilized

expireAfter: 720h # 30일 후 교체

**장점**: Pod 요구사항 보고 **최적 인스턴스 타입 즉시 프로비저닝**. Spot 친화적.

**효과**: Cluster Autoscaler 대비 30-50% 비용 절감.

3. Spot Instance (70% 절감)

**주의**: Spot은 언제든 회수. Graceful shutdown + PodDisruptionBudget 필수.

apiVersion: policy/v1

kind: PodDisruptionBudget

metadata: { name: web-pdb }

spec:

minAvailable: 2

selector: { matchLabels: { app: web } }

4. HPA로 유휴 시간 줄이기

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata: { name: web }

spec:

scaleTargetRef: { kind: Deployment, name: web }

minReplicas: 2

maxReplicas: 50

metrics:

- type: Resource

resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }

behavior:

scaleDown:

stabilizationWindowSeconds: 300

5. KEDA — 이벤트 기반 스케일

apiVersion: keda.sh/v1alpha1

kind: ScaledObject

spec:

scaleTargetRef: { name: worker }

minReplicaCount: 0 # idle 시 0

maxReplicaCount: 20

triggers:

- type: kafka

metadata:

bootstrapServers: kafka:9092

consumerGroup: workers

topic: jobs

lagThreshold: "10"

**장점**: 0으로 스케일 가능. 큐 길이, HTTP, DB 트리거. 야간 비용 0.

6. FinOps 도구

- **OpenCost**: 네임스페이스별 비용 분배

- **Kubecost**: 상용 버전 + 권장

- **CNCF Kepler**: 에너지 측정

10부 — Kubernetes 보안 체크리스트

10대 영역

1. **RBAC 최소 권한** — `cluster-admin` 절대 일반 서비스에 X

2. **NetworkPolicy** — 기본 deny + 명시적 허용

3. **Pod Security Standards** — `restricted` 프로파일

4. **이미지 스캔** — Trivy, Grype (CI + admission)

5. **Signed Images** — Cosign + Sigstore

6. **Secrets 관리** — External Secrets Operator + Vault/AWS SM

7. **Runtime Security** — Falco, Tetragon

8. **Admission Controllers** — Kyverno, OPA Gatekeeper

9. **etcd 암호화** — at-rest encryption

10. **Audit Logging** — API server audit → SIEM

NetworkPolicy 최소 예시

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata: { name: deny-all }

spec:

podSelector: {}

policyTypes: [Ingress, Egress]

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata: { name: allow-web-to-api }

spec:

podSelector: { matchLabels: { app: api } }

ingress:

- from:

- podSelector: { matchLabels: { app: web } }

ports:

- protocol: TCP

port: 8080

Pod Security

apiVersion: v1

kind: Namespace

metadata:

labels:

pod-security.kubernetes.io/enforce: restricted

pod-security.kubernetes.io/enforce-version: latest

**restricted 프로파일 규칙**:

- root 금지

- privileged 금지

- hostNetwork/hostPID 금지

- runAsNonRoot 필수

- readOnlyRootFilesystem 권장

11부 — 멀티클러스터 전략

왜 멀티클러스터?

- **HA**: 리전 장애 대응

- **규정**: 지역별 데이터 주권

- **블루/그린**: 전체 클러스터 단위 배포

- **Blast Radius**: 하나 망가져도 다른 클러스터 영향 X

도구들

| 도구 | 역할 |

|---|---|

| **Cluster API** | 클러스터 자체를 K8s 리소스로 관리 |

| **Karmada, OCM** | 멀티클러스터 스케줄링 |

| **Cilium Cluster Mesh** | 클러스터 간 Service 투명 연결 |

| **ArgoCD ApplicationSet** | 여러 클러스터에 앱 배포 |

| **Crossplane** | K8s API로 AWS/GCP 리소스까지 관리 |

12부 — Observability Stack in Kubernetes

표준 스택 (2025)

| 카테고리 | 도구 |

|---|---|

| Metrics | Prometheus + Grafana |

| Logs | Loki + Grafana |

| Traces | Tempo + Grafana |

| Continuous Profiling | Pyroscope + Grafana |

| eBPF 관측 | Pixie, Parca |

| All-in-one | Grafana LGTM stack |

kube-prometheus-stack 한 번에 설치

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm install monitoring prometheus-community/kube-prometheus-stack \

--namespace monitoring --create-namespace

**포함**: Prometheus + Grafana + AlertManager + Node Exporter + kube-state-metrics + 기본 대시보드 30개

13부 — 6개월 로드맵

**1개월차**: Kubernetes 기본 — Pod, Deployment, Service, Ingress. minikube/kind로 로컬 실습

**2개월차**: Helm/Kustomize로 앱 패키징. ConfigMap, Secret, Volume 다루기

**3개월차**: GitOps — ArgoCD 설치, 앱 동기화, 멀티 환경(dev/staging/prod) 구성

**4개월차**: HPA, VPA, Karpenter로 자동 스케일링. Spot + PDB 조합

**5개월차**: Cilium CNI 교체, NetworkPolicy, eBPF 관측 (Hubble, Pixie)

**6개월차**: Operator 작성 (Kubebuilder). CRD + Reconcile 루프

14부 — 체크리스트 12개

- [ ] 모든 Deployment에 resources.requests/limits 설정

- [ ] liveness + readiness probe 설정

- [ ] HPA 또는 KEDA로 자동 스케일링

- [ ] PodDisruptionBudget 설정

- [ ] NetworkPolicy 기본 deny

- [ ] Pod Security restricted 프로파일

- [ ] RBAC 최소 권한

- [ ] Secrets는 External Secrets Operator

- [ ] 이미지 스캔 (Trivy) + Cosign 서명

- [ ] GitOps (ArgoCD/Flux)로 배포

- [ ] kube-prometheus-stack 설치

- [ ] Karpenter + Spot으로 비용 최적화

15부 — 안티패턴 10가지

1. **Resource request/limit 없음** → 노드 과밀집, OOM Kill 폭탄

2. **liveness probe 없음** → 죽은 Pod 살아있다고 인식

3. **cluster-admin 남발** → 보안 사고의 시작

4. **`latest` 태그 사용** → 재현 불가, 롤백 지옥

5. **Secret을 ConfigMap에 저장** → Git에 평문 노출

6. **kubectl apply 수동** → GitOps 없는 환경, drift 폭발

7. **NetworkPolicy 없음** → 기본 allow-all, 수평 이동 공격 쉬움

8. **HPA 없이 고정 replica** → 트래픽 spike 처리 못함

9. **PodDisruptionBudget 없음** → 노드 교체 시 전체 다운

10. **Spot 쓰면서 graceful shutdown 없음** → 데이터 손실

마무리 — "선언적 + 자동화 + 관측 가능"

2025년 클라우드 네이티브는 **선언적 + 자동화 + 관측 가능**으로 요약된다.

- **선언적**: 원하는 상태를 YAML로 → 클러스터가 맞춤

- **자동화**: GitOps로 배포, Karpenter로 스케일, Falco로 보안

- **관측 가능**: Prometheus + Tempo + Loki로 3 pillars

Kubernetes가 어렵다? 맞다. 하지만:

- 10년 전 VM 수동 관리 시절로 돌아갈 수 없다

- 2000개 CNCF 프로젝트가 불편한 부분을 해결 중

- eBPF가 **사이드카 없는 Service Mesh**로 단순화 중

- Wasm이 **컨테이너보다 가벼운 서버리스**로 진화 중

다음 글은 Season 2 Ep 16 — **프론트엔드 아키텍처 완전 가이드**.

React Server Components, Signals, Islands, 그리고 "프레임워크 전쟁 2025" 승자는?

도시가 섰으니, 이제 **시민이 쓰는 UI**를 만들 차례다.

다음 글 예고 — "프론트엔드 아키텍처 완전 가이드: RSC·Signals·Islands·Meta Frameworks"

Season 2 Ep 16은 UI 레이어의 2025 정리:

- React Server Components 실전

- Signals (Solid, Svelte 5 Runes, Angular 18)

- Islands Architecture (Astro, Fresh)

- Meta Framework 비교 (Next, Remix, Nuxt, SvelteKit)

- State Management 2025 (Zustand, Jotai, TanStack Query)

- Bundler 전쟁 (Vite, Turbopack, Rspack)

UI는 어디로 가는가. 다음 글에서.