서비스 메시 2026 — Istio Ambient / Linkerd 3 / Cilium Mesh / Consul Connect / Kuma 심층 비교 (사이드카는 죽었나)

프롤로그 — "service mesh가 다시 어려워졌다"

2024년 KubeCon EU. 무대 위에서 한 SRE가 농담처럼 말했다. "service mesh를 안다고 말하지 마세요. 2년 전 알던 service mesh는 이제 없어요." 객석에서 웃음이 터졌지만, 진심이 절반쯤 섞여 있었다.

2024-2026년 사이에 일어난 일을 정리하면:

Istio Ambient mode가 1.22에서 GA(2024년) — sidecar 없는 Istio가 가능해졌다.
Linkerd 3 (Buoyant) — 일부 기능을 paid edition으로 옮기며 커뮤니티 강한 반발.
Cilium / Isovalent → Cisco(2024년) — eBPF mesh가 시스코의 우산 아래로.
HashiCorp → IBM(2024년) — Consul Connect의 거버넌스가 바뀌었다.
Open Service Mesh (Microsoft) — 2024년 1월 sunset
AWS App Mesh — 2024년 10월 sunset
Kuma (Kong) — federated multi-zone mesh로 자리 잡음.
Gloo Mesh (solo.io) — multi-cluster Istio 배포의 사실상 표준.
Traefik Mesh — 가벼운 옵션으로 살아남음.

기술적으로 더 흥미로운 건 모델 자체가 갈라졌다는 점이다. 2020년에는 모두가 사이드카(Envoy 옆방살이)였다. 2026년에는 세 모델이 공존한다.

Sidecar 모델 — 전통 Istio, Linkerd 2/3, Consul Connect의 default.
Ambient 모델 (L4 + L7 분리) — Istio Ambient(ztunnel + waypoint), Linkerd의 일부 패턴.
eBPF / proxyless 모델 — Cilium Service Mesh, gRPC-native, JVM 일부.

세 모델은 트레이드오프가 다르고, 우리 팀의 워크로드와 운영 역량에 따라 정답이 달라진다. 이 글은 각 옵션의 2026년 현재 상태, 사이드카 vs ambient vs proxyless 논쟁, 운영 패턴(mTLS·RBAC·traffic shifting·관찰성), 그리고 누가 무엇을 골라야 하는지를 정리한다.

먼저 한 가지만 미리 말해두면: service mesh는 default가 아니다. "Kubernetes를 쓰니까 mesh를 깐다"는 건 2026년에도 여전히 잘못된 추론이다. mesh 없이 잘 사는 팀이 mesh 있는 팀보다 보통 더 행복하다. 다만, 정말로 필요한 팀에게는 잘 고른 mesh가 운영의 결을 바꿔놓는다.

1장 · 2026년 서비스 메시 지도 — 세 모델, 일곱 후보

옵션	모델	거버넌스	2026년 상태
Istio (sidecar)	사이드카	CNCF (졸업)	가장 많이 쓰임. 무거움.
Istio Ambient	L4 + L7 분리	CNCF	1.22 GA(2024). 채택 가속.
Linkerd 2	사이드카 (Rust micro-proxy)	Buoyant	가벼움. 유지보수 모드.
Linkerd 3	사이드카 + 일부 ambient 패턴	Buoyant (paid edition 도입)	커뮤니티 논란.
Cilium Service Mesh	eBPF + Envoy 옵션	Cisco (Isovalent 인수)	빠르게 성장.
Consul Connect	사이드카 (Envoy)	IBM (HashiCorp 인수)	거버넌스 불확실.
Kuma	사이드카 / multi-zone	Kong / CNCF (Sandbox)	federated mesh 강함.
Gloo Mesh	Istio 위 multi-cluster	solo.io (상용)	엔터프라이즈 표준.
Traefik Mesh	DaemonSet 프록시	Traefik Labs	가벼움 / 단순.
Open Service Mesh	사이드카	Microsoft (sunset 2024-01)	종료.
AWS App Mesh	사이드카 (Envoy)	AWS (sunset 2024-10)	종료.

세 모델을 한 줄로 요약하면:

사이드카 — 워크로드 옆에 Envoy(또는 micro-proxy) Pod를 한 개 더 띄운다. 가장 검증되었지만, 메모리·CPU·시작 시간·디버깅 복잡도가 모두 비싸다.
Ambient — 노드별로 L4 프록시(ztunnel)를 두고, L7 정책이 필요한 네임스페이스에만 별도 waypoint proxy를 띄운다. 사이드카의 비용을 큰 폭으로 낮춘다.
eBPF / proxyless — 커널 단의 eBPF로 정책·암호화·관찰성을 구현. 데이터플레인 프록시 없이도 mTLS·정책 일부가 가능. L7 기능이 필요하면 Envoy로 보낸다.

세 모델은 다른 트레이드오프를 갖는다. 사이드카는 "성숙하지만 비싸다", ambient는 "운영이 더 단순하지만 새 컴포넌트가 추가된다", eBPF는 "가볍지만 커널·OS·CNI 의존이 크다". 정답이 없다.

2장 · Istio Ambient (2024 GA) — ztunnel + waypoint

Istio Ambient mode는 2022년 alpha에서 시작해 2024년 1.22에서 GA가 됐다. 핵심 아이디어는 데이터플레인을 두 층으로 나눈다는 것이다.

[Pod A] ────► [ztunnel (Node 데몬셋)] ──mTLS──► [ztunnel] ────► [Pod B]
                  L4 (TCP·HBONE 터널)

L7이 필요할 때만:

[Pod A] → [ztunnel] → [waypoint proxy (네임스페이스/서비스 단위)] → [ztunnel] → [Pod B]
                          L7 (HTTP route, RBAC, traffic shifting)

ztunnel: Rust로 새로 짠 노드 데몬셋. 모든 노드에 하나씩 떠서 자기 노드의 Pod 트래픽을 HBONE(HTTP-Based Overlay Network Environment, HTTP/2 over mTLS) 터널로 노드 간에 전달한다. L4만 한다 — TLS·인증·간단한 mTLS만.
waypoint proxy: L7 정책(HTTP route, header-based routing, RBAC, retry, mirror)이 필요한 네임스페이스나 service account에 한해서 별도 Envoy Pod를 띄운다. ztunnel은 L7이 필요한 트래픽을 waypoint로 우회시킨다.

왜 이게 의미 있나?

메모리·CPU 절감: Pod 100개에 사이드카 100개 대신, 노드 10개에 ztunnel 10개 + waypoint 2-3개. 사이드카 한 개당 50-200MB의 Envoy 메모리를 안 쓴다.
시작 시간: 사이드카는 Pod 시작 시점에 같이 떠야 하니, Pod 시작 시간이 늘어났다. Ambient는 노드 데몬셋이 미리 떠 있으니 Pod 시작이 빠르다.
앱 + 사이드카 커플링 제거: 사이드카 OOM이 앱을 죽이거나, 사이드카 버전이 앱 lifecycle을 잡는 일이 사라진다.
L4 vs L7 분리: L7이 필요 없는 워크로드(많다 — 단순 gRPC backend, queue worker 등)는 ztunnel만으로 끝.

왜 모두가 Ambient로 가지 않나?

새 컴포넌트 두 개(ztunnel, waypoint)의 운영 학습.
CNI/네트워크 의존성: ambient는 iptables 외에 새로운 netfilter 룰을 깐다. 어떤 CNI(특히 Cilium 일부 버전)와 충돌한 사례가 있다.
GA가 됐어도 일부 기능은 sidecar 전용: 특정 EnvoyFilter, WASM 확장 등은 ambient에서 아직 제한적.
마이그레이션 비용: 이미 sidecar로 잘 돌고 있는 클러스터에서 ambient로 옮기는 작업 자체가 크다.

2026년 현재의 권고는 신규 클러스터는 ambient를, 기존 sidecar 클러스터는 점진 마이그레이션. Solo.io의 Gloo 같은 상용 디스트로가 ambient 마이그레이션 도구를 빠르게 채워 넣고 있다.

3장 · Istio sidecar (전통) — 여전히 많은 곳

ambient가 GA 됐다고 해서 sidecar Istio가 죽은 건 아니다. 2026년 현재 운영 중인 Istio 클러스터의 대다수는 여전히 sidecar다. 이유는 단순하다 — "잘 돌고 있는 걸 굳이 옮기지 않는다."

sidecar Istio의 장점은 여전하다:

가장 많은 사례·문서·블로그. 문제가 생기면 검색하면 답이 나온다.
모든 기능이 다 된다. EnvoyFilter, WASM extension, 모든 telemetry v2 기능.
다른 ingress/egress와의 통합 사례가 가장 풍부하다.

단점도 여전하다:

메모리·CPU 비용 — Envoy 사이드카 한 개당 평균 50-200MB.
Pod 시작 시간 증가 — 사이드카가 ready 될 때까지 앱이 트래픽을 못 받는다(holdApplicationUntilProxyStarts).
앱 + 사이드카 lifecycle 결합 — 사이드카 OOM이 앱 트래픽을 끊는다.
Istio control plane(istiod) 부담 — Pod 수가 많아질수록 xDS 푸시 비용 증가.

언제 sidecar Istio가 정답인가?

이미 운영하고 있고 잘 돌고 있을 때(가장 흔한 케이스).
특정 sidecar 전용 EnvoyFilter나 WASM이 핵심 기능일 때.
Ambient를 채택할 만큼 팀이 새 컴포넌트를 다룰 여유가 없을 때.

권고: 새로 시작하면 ambient를, 이미 sidecar면 마이그레이션은 천천히. 가장 흔한 실수는 "ambient가 GA 됐다니까 바로 옮긴다" — 운영 학습 곡선이 크다.

4장 · Linkerd 3 — Buoyant의 유료화 결정 (2024)

Linkerd는 2017년부터 "사이드카지만 가볍다"를 무기로 사이드카 진영의 minimalist를 자처해 왔다. Rust로 짠 linkerd2-proxy(이제 linkerd-proxy)는 Envoy보다 메모리·CPU가 훨씬 적었다 — 사이드카 한 개당 10-30MB 정도.

그러던 2024년, Buoyant(Linkerd 모회사)는 stable release(production-ready 빌드)를 paid edition으로 옮긴다고 발표했다. 무료로 받을 수 있는 건 edge release(주간 빌드)뿐이고, production에서 stable channel을 쓰려면 Buoyant Enterprise 라이선스가 필요해졌다.

커뮤니티의 반응은 격렬했다:

"오픈소스 mesh의 황금기가 끝났다."
"이건 사실상 source-available로의 후퇴다."
"그래도 Linkerd는 매우 작은 회사가 유지하는데, 어떻게 무한히 무료일 수 있나?"
"CNCF graduation 프로젝트가 이래도 되나?"

Linkerd 3의 기술적 변화:

사이드카는 그대로 Rust micro-proxy. 여전히 가볍다.
일부 ambient-스타일 패턴(서비스 단위 정책 위임)을 도입.
multi-cluster mTLS와 federated 인증서 관리 강화.
policy 리소스가 더 풍부해짐(L7 RBAC 등).

2026년 현재의 시선:

기술적으로는 여전히 매력적. 사이드카지만 가장 가벼움.
운영 측면에서 정말로 단순하다. Istio처럼 수십 개의 CRD를 외울 일이 없다.
그러나 production stable 빌드의 paid 정책 때문에, CNCF 졸업 프로젝트라는 안심을 깎아먹었다.
edge channel은 자유롭게 쓸 수 있지만, 엔터프라이즈가 unsupported channel을 쓰는 건 정치적으로 어렵다.

선택 기준:

가볍고 단순한 sidecar mesh를 원하고, Buoyant Enterprise 비용을 감내할 수 있다면 여전히 좋은 선택.
"vendor lock-in"이 두렵다면 Istio Ambient나 Cilium Service Mesh로 우회 가능.
작은 팀이 빠르게 mTLS만 받고 싶다면, 여전히 가장 깔끔한 옵션 중 하나.

5장 · Cilium Service Mesh — eBPF + Cisco 인수 (2024)

Cilium은 원래 CNI(Container Network Interface)로 시작했지만, eBPF 기반의 강력함을 무기로 Service Mesh 영역으로 확장했다. 2022년 OSS로 service mesh 기능을 공식화했고, 2023-2024년에 본격적으로 production 채택이 늘었다.

2024년 Cisco가 Isovalent(Cilium 모회사)를 인수했다. eBPF 시장에서 Cisco의 영향력이 단숨에 커졌고, Cilium의 엔터프라이즈 디스트리뷰션 — Isovalent Cilium Enterprise — 의 미래가 시스코의 보안·네트워킹 제품군에 통합되는 방향으로 가고 있다.

Cilium Service Mesh의 모델:

L4 mTLS + 정책: eBPF만으로 동작. 사이드카·waypoint 없이 노드 커널에서 처리.
L7 기능(HTTP routing, gRPC, Kafka filter): 노드별 Envoy(데몬셋) 또는 ingress gateway 형태. 사이드카 아님.
관찰성: Hubble로 L3/L4/L7 가시성. eBPF로 캡처하므로 sidecar 없이도 매우 풍부.
Network Policy 통합: CiliumNetworkPolicy로 L3-L7을 한 곳에서.

왜 eBPF mesh가 매력적인가?

사이드카 0개 — 메모리·CPU·시작 시간 모두 절감.
L4는 커널에서 처리 — context switch 없이 빠르다.
mesh + CNI가 하나 — 두 컴포넌트를 따로 관리할 필요 없다.
Hubble 관찰성 — 모든 트래픽이 eBPF로 캡처되므로 sampling 없이 본다.

현실적 한계:

커널 의존성: 새 기능은 새 커널이 필요하다. 5.x 후반 또는 6.x 추천.
L7 기능은 결국 Envoy — 사이드카가 없을 뿐, Envoy 자체는 어딘가에 떠 있다.
운영 학습: eBPF·iptables·CNI·NetworkPolicy의 인터랙션이 복잡.
Istio API 호환 부족: Istio에 익숙한 팀에게는 운영 패턴이 다르다.

2026년 시점의 권고:

신규 클러스터를 깐다면 Cilium은 CNI로 쓸 가치가 충분하다(많은 클라우드의 권장 CNI).
Cilium Service Mesh는 "Cilium CNI를 이미 쓰고 있다면" 자연스러운 확장.
시스코 인수 이후의 라이선스/거버넌스 변화를 주시할 것.

6장 · Consul Connect — HashiCorp → IBM 인수 (2024)

Consul은 2014년부터 HashiCorp의 service discovery·KV store로 시작했고, Consul Connect로 service mesh 영역에 진입했다. VM과 Kubernetes를 동시에 다루는 mesh라는 점이 가장 큰 차별점이었다 — Istio·Linkerd가 Kubernetes-first인 반면, Consul은 처음부터 VM·bare-metal까지 mesh로 묶을 수 있었다.

2024년 IBM이 HashiCorp 인수. Terraform·Vault·Consul·Nomad 등 HashiCorp의 모든 제품이 IBM 우산 아래로 들어갔다. 거버넌스·라이선스(이미 2023년 BSL로 변경) 모두에 영향이 갔다.

Consul Connect의 강점(여전히):

하이브리드 환경: VM + Kubernetes + bare-metal을 한 mesh로.
multi-datacenter / WAN federation: 일찍부터 잘 지원.
Vault 통합: Consul Connect의 CA를 Vault로 위임 가능.
Service mesh + service discovery + KV: 통합 플랫폼.

약점·우려:

BSL 라이선스(2023): 이미 자유 OSS가 아님 — 경쟁 SaaS 제공이 제한됨.
IBM 인수 후 로드맵 불확실성: 일부 사용자는 OpenTofu류의 fork(Consul용은 아직 미성숙)를 우려.
Kubernetes-only 환경에서는 Istio/Linkerd 대비 매력이 떨어진다.

언제 Consul Connect가 정답인가?

VM과 Kubernetes를 동시에 다루는 하이브리드 환경.
이미 HashiCorp 스택(Terraform·Vault·Nomad)을 깊게 쓰고 있는 조직.
multi-region / multi-datacenter mesh가 핵심.

언제 피하는가?

순수 Kubernetes-only이고, vendor lock-in이 부담스러울 때.
라이선스 변경에 민감한 OSS-first 조직.

7장 · Kuma (Kong) — federated mesh

Kuma는 Kong에서 2019년에 만들어 2020년 CNCF Sandbox로 기증된 mesh다. 기술적으로는 Envoy 기반 사이드카 mesh지만, 가장 큰 특징은 multi-zone / federated 모델이다.

Kuma의 아키텍처:

global control plane(글로벌 정책 관리) + zone control plane(각 클러스터/리전).
한 mesh가 여러 클러스터·여러 클라우드·VM을 횡단할 수 있다.
Universal mode(VM/bare-metal)와 Kubernetes mode 모두 지원.

다른 mesh 대비 강점:

multi-zone이 first-class: Istio·Linkerd의 multi-cluster보다 운영 모델이 단순.
policy → mesh 단위로 fan-out: 한 곳에서 정책을 정의하면 모든 zone에 전파.
Kong API Gateway와의 통합: API 게이트웨이까지 mesh의 일부로.

약점:

Istio만큼 광범위한 도큐먼트/사례가 부족.
일부 L7 고급 기능은 Istio 대비 늦게 들어옴.
Kong의 상용화 전략에 따라 OSS feature set이 영향받을 가능성.

언제 Kuma인가? multi-cluster / multi-cloud / hybrid 환경에서 운영 단순함이 핵심일 때. 특히 이미 Kong API Gateway를 쓰고 있으면 자연스럽다.

8장 · Gloo Mesh (solo.io) — multi-cluster Istio

solo.io의 Gloo Mesh는 Istio 위에 얹은 상용 multi-cluster 컨트롤 플레인이다. Istio 자체는 단일 클러스터 운영은 잘 되지만, 여러 클러스터를 한 mesh로 묶는 작업(다중 클러스터 federation, 공통 인증서, cross-cluster service discovery)은 운영적으로 복잡하다. Gloo Mesh는 그 부분을 상용 제품으로 추상화한다.

Gloo Mesh가 해결하는 문제:

multi-cluster Istio federation의 자동화: 인증서·trust domain·east-west gateway 셋업이 GUI/CLI로 단순화.
글로벌 정책 관리: 정책을 한 곳에서 정의 → 모든 클러스터로 전파.
VirtualService·DestinationRule의 abstraction: 더 높은 수준의 RouteTable·VirtualGateway CRD.
Ambient 마이그레이션 지원: solo.io가 ambient 진영의 핵심 contributor 중 하나.

누가 쓰나: 대형 엔터프라이즈, 특히 multi-cluster Istio가 핵심인 곳. 금융권·통신사·일부 빅테크 SRE 조직.

대안: OSS Istio + 직접 multi-cluster 셋업(가능하지만 운영 비용 큼) 또는 Cilium ClusterMesh.

9장 · Traefik Mesh — 가벼운 옵션

Traefik Mesh(이전 Maesh)는 DaemonSet 기반의 경량 mesh다. 사이드카 모델이 아니라 노드별 프록시(Traefik 자체) 하나가 그 노드의 트래픽을 처리한다. 모델적으로는 ambient의 ztunnel에 가깝다 — 단, 만들어진 시기는 훨씬 이르다(2019).

장점:

사이드카 없음 — 메모리·시작 시간 부담 적음.
운영 단순함 — Traefik에 익숙한 팀에게는 학습 비용 작음.
SMI(Service Mesh Interface) 호환 — 표준 API.

약점:

L7 정책의 풍부함이 Istio 수준은 아님.
mTLS·복잡한 RBAC은 다른 mesh보다 단순한 편.
커뮤니티 규모가 Istio·Linkerd·Cilium보다 작다.

언제 Traefik Mesh인가? 작은 클러스터, 단순한 트래픽 정책만 필요한 곳, 이미 Traefik ingress를 쓰는 곳.

10장 · OSM / AWS App Mesh 종료의 의미

Open Service Mesh (Microsoft) — 2024년 1월 sunset. AWS App Mesh — 2024년 10월 sunset.

두 mesh의 종료는 업계에 신호를 남겼다.

OSM의 종료가 시사하는 것:

Microsoft가 직접 만든 mesh보다 Istio·Cilium의 채택을 따라가는 게 합리적이라는 판단.
AKS(Azure Kubernetes Service)는 이제 Istio add-on을 기본으로 권한다.
mesh를 클라우드 벤더가 자체 빌드하는 모델의 한계 — 커뮤니티 모멘텀을 따라가지 못함.

App Mesh의 종료가 시사하는 것:

AWS도 자체 mesh를 포기. AWS Cloud Map + ALB/NLB + EKS 위의 OSS mesh(Istio/Linkerd) 패턴으로 회귀.
EKS 고객들이 App Mesh보다 Istio/Linkerd/Cilium을 더 많이 채택했음을 인정한 결정.
AWS는 대신 App Mesh를 deprecate 하고 마이그레이션 가이드를 제공하는 방식으로 정리.

전체 교훈:

mesh는 OSS 커뮤니티 + CNCF 우산이 강한 곳에 집중된다 — Istio, Linkerd, Cilium, Kuma.
클라우드 벤더 자체 mesh는 살아남기 어렵다 — Google조차도 ASM(Anthos Service Mesh)을 Istio 기반으로 만든다.
mesh의 가치는 portability — 한 mesh로 여러 클라우드를 묶는 게 핵심. 벤더 종속 mesh는 그 가치와 충돌.

11장 · mTLS / RBAC / Traffic shifting / 관찰성 패턴

어떤 mesh를 골라도 결국 운영해야 할 패턴은 비슷하다. 핵심 4가지.

11.1 mTLS — 가장 자주 쓰는 이유

mesh를 까는 가장 흔한 이유. zero-trust 네트워크의 첫걸음이다.

STRICT mode: 모든 mesh 내부 트래픽은 mTLS만 허용. 외부에서 들어오는 평문은 거절.
PERMISSIVE mode: mTLS와 평문 둘 다 허용. 마이그레이션 단계에서 사용.
CA 관리: Istio는 istiod가 CA, Cilium은 SPIRE 통합, Consul은 Vault 위임.

운영 팁:

점진 도입: PERMISSIVE → STRICT 순. 한 번에 STRICT로 가면 미식별 평문 트래픽 때문에 사고 난다.
외부 통합: 데이터베이스·Kafka·외부 API는 mesh 밖. egress gateway로 정책을 별도로 짠다.
인증서 회전: 7일이 default. 너무 짧게 잡으면 control plane 부하 증가.

11.2 RBAC — 누가 누구를 부르나

AuthorizationPolicy(Istio), Server/ServerAuthorization(Linkerd), CiliumNetworkPolicy(Cilium)로 표현.

# Istio 예시 — frontend ServiceAccount만 backend의 /api 호출 가능
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: backend-policy
spec:
  selector:
    matchLabels:
      app: backend
  rules:
    - from:
        - source:
            principals: ['cluster.local/ns/default/sa/frontend']
      to:
        - operation:
            paths: ['/api/*']

운영 팁:

default-deny → allow 룰: zero-trust 원칙.
principal은 ServiceAccount 기반으로 짜라 — 네임스페이스·라벨 기반은 변경에 취약.
L7 정책을 너무 세밀하게 짜지 마라 — 코드 변경 때마다 정책 변경 부담.

11.3 Traffic shifting — canary / blue-green / A/B

mesh의 킬러 기능. weighted routing으로 새 버전을 점진 노출.

# Istio — v1에 90%, v2에 10%
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: payment
spec:
  hosts: ['payment']
  http:
    - route:
        - destination: { host: payment, subset: v1 }
          weight: 90
        - destination: { host: payment, subset: v2 }
          weight: 10

운영 팁:

Argo Rollouts / Flagger와 결합: 자동 progressive delivery.
메트릭 기반 자동 rollback: error rate·latency가 임계치 넘으면 자동 복구.
header-based routing으로 내부 dogfood: 특정 헤더 가진 요청만 v2로 — 직원 트래픽 먼저 검증.

11.4 관찰성 — golden signals

mesh가 자동으로 캡처하는 4가지:

트래픽(traffic): RPS, byte/sec
에러(errors): 5xx 비율, gRPC error code
지연(latency): p50, p95, p99
포화(saturation): 큐 길이, connection pool

대시보드:

Istio: Kiali(서비스 그래프) + Grafana(메트릭) + Jaeger/Tempo(트레이싱).
Linkerd: 자체 viz extension(가벼움).
Cilium: Hubble UI(eBPF 기반, 매우 풍부).

운영 팁:

trace sampling은 1-5%: 100%는 백엔드(Tempo/Jaeger) 부담이 크다.
메트릭 cardinality 관리: pod label을 그대로 메트릭에 박지 마라(Prometheus 폭발).
서비스 그래프는 발견용: 평소엔 안 보다가, 사고 났을 때 가장 빠른 도구.

12장 · 사이드카 vs ambient vs proxyless 논쟁

2024-2026년 가장 격렬했던 mesh 논쟁. 한 줄 요약:

사이드카: 검증되었지만 비싸다.
Ambient: 비용을 줄이지만 새 컴포넌트가 추가된다.
eBPF / proxyless: 가장 가볍지만 커널·CNI 의존이 크다.

사이드카의 입장 (Istio sidecar, Linkerd 2/3)

모든 기능이 다 된다 — EnvoyFilter, WASM, telemetry v2.
isolation이 강하다 — 한 Pod의 mesh 설정이 다른 Pod에 영향 없음.
debugging이 직관적이다 — 어느 Pod의 어느 사이드카를 보면 됨.
비용? "메모리 100MB는 클라우드 인스턴스에 비하면 작다."

Ambient의 입장 (Istio Ambient)

메모리·시작 시간 대폭 감소 — Pod 100개 × 100MB = 10GB가 사라진다.
앱 + 사이드카 lifecycle decoupling — 사이드카 업데이트 ≠ 앱 재시작.
L4와 L7 분리 — L7 정책이 필요한 곳에만 waypoint.
단점? "새 컴포넌트 두 개 운영. 그래도 사이드카보다는 낫다."

eBPF / proxyless의 입장 (Cilium)

사이드카·waypoint·ztunnel 다 없다 — 노드 커널이 처리.
L4 mTLS·정책은 커널에서 — 가장 가볍다.
Hubble으로 sampling 없이 본다 — 관찰성이 풍부.
단점? "L7 기능은 결국 Envoy가 필요. 커널 의존이 크다."

2026년의 합의 (느슨하지만)

새 클러스터 → ambient (Istio) 또는 eBPF (Cilium). 사이드카는 신규에 권하지 않음.
기존 sidecar 클러스터 → 운영팀의 여유에 따라 점진 ambient 마이그레이션.
CNI를 새로 고르는 중 → Cilium은 강력한 후보. Cilium을 골랐다면 Cilium Service Mesh도 자연스러움.
하이브리드(VM+K8s) → Consul Connect 또는 Kuma.

논쟁은 끝나지 않았다. 단, 사이드카-only 시대는 끝났다.

13장 · 한국 / 일본 사례 — 토스, 카카오, Mercari, Cybozu

토스 — Istio + 점진적 ambient 실험

토스는 PG·증권·뱅킹을 한 K8s 위에서 운영한다. 보안·감사 요건 때문에 mTLS는 필수였고, Istio sidecar로 시작했다. 2024-2025년부터 ambient mode를 신규 클러스터에 한해 도입, 점진적으로 sidecar 클러스터를 마이그레이션 중이다.

핵심 선택 이유:

금융 감사 요건: mTLS, audit log, RBAC을 mesh로 일원화.
multi-cluster 가시성: Kiali + Grafana + Tempo 조합.
신규는 ambient: Pod 메모리 절감 효과가 천 단위 Pod 운영에서 큼.

카카오 — Istio + 자체 control plane 도구

카카오는 대규모 마이크로서비스 인프라에 Istio sidecar 기반. 자체 control plane 도구(VirtualService·DestinationRule을 더 안전하게 관리하는 GitOps 레이어)를 만들어 운영팀과 개발팀의 정책 변경 마찰을 줄였다.

핵심 패턴:

canary는 자체 progressive delivery 도구로: Argo Rollouts 기반.
mTLS는 STRICT, RBAC은 default-deny.
trace sampling은 1%, error trace는 100%.

Mercari (일본) — Istio + Cloud Run/GKE 하이브리드

Mercari는 GKE 기반 Istio sidecar로 시작. 일부 워크로드는 Cloud Run으로 옮기면서 mesh 외부 호출이 늘었고, ingress/egress gateway 패턴으로 외부 통합을 깔끔하게 정리했다.

기술 블로그 공개 사례:

mTLS는 모든 service-to-service에 의무화.
Backstage + Istio CRD 통합으로 정책 변경을 PR 기반 워크플로우에.
gRPC + Envoy gRPC-Web filter — 프런트엔드 통합.

Cybozu (일본) — Linkerd 2/3 채택, 가벼움 우선

Cybozu(kintone 등)는 OSS-friendly한 엔지니어링 문화로 유명. Linkerd를 선택한 이유는 단순함. Istio의 복잡성을 감내하기보다, Linkerd의 가벼운 운영 패턴을 선호.

2024년 Buoyant 유료화 발표 이후 평가를 다시 했으나, edge channel + 일부 community 빌드로 운영을 유지하는 방향을 검토 중이라는 후문(공식 발표 없음 — 커뮤니티 추정).

14장 · 누가 무엇을 골라야 하나 — 결정 트리

Q1. mesh가 정말로 필요한가?
├── 아니오 (mTLS만 필요) → cert-manager + 앱 라이브러리 mTLS / SPIFFE/SPIRE 직접
├── 아니오 (trace만 필요) → OTel SDK + Tempo/Jaeger
└── 예 → 다음

Q2. 환경은?
├── 순수 K8s, 단일 클러스터
│   ├── 신규 → Istio Ambient or Cilium Service Mesh
│   └── 기존 sidecar → 점진 마이그레이션
├── 순수 K8s, 다중 클러스터
│   ├── OSS만 → Cilium ClusterMesh or Kuma
│   └── 엔터프라이즈 지원 필요 → Gloo Mesh (solo.io)
├── 하이브리드 (VM + K8s)
│   └── Consul Connect or Kuma (Universal mode)
└── 매우 작은 클러스터, 단순 정책
    └── Traefik Mesh

Q3. 팀 역량은?
├── 운영 인력이 작다 → Linkerd 3 (가벼움, 유료 수용 가능 시) or Traefik Mesh
├── 운영 인력이 많다 → Istio Ambient (full feature)
└── eBPF 경험이 있다 → Cilium Service Mesh

Q4. CNI는?
├── Cilium 쓰는 중 → Cilium Service Mesh가 자연스러움
├── Calico/기타 → Istio Ambient / Linkerd
└── 클라우드 default CNI → 그것이 호환되는지부터 확인

한 줄 권고 (2026년 5월 기준):

일반 신규 K8s: Istio Ambient 또는 Cilium Service Mesh.
작은 팀, 단순함 우선: Linkerd 3 (유료 정책 수용 가능 시) 또는 Traefik Mesh.
하이브리드(VM+K8s): Consul Connect 또는 Kuma.
멀티 클러스터 엔터프라이즈: Gloo Mesh.

가장 중요한 메타-권고: mesh를 까기 전에, mesh 없이 살 수 있는지 한 번 더 물어라. 정말로 mesh가 필요한 팀은 생각보다 적다.

참고 / References

Istio Ambient Mode — https://istio.io/latest/docs/ops/ambient/
Istio 1.22 Release Notes (Ambient GA) — https://istio.io/latest/news/releases/1.22.x/announcing-1.22/
Linkerd by Buoyant — https://linkerd.io/
Buoyant stable release policy change (2024) — https://buoyant.io/blog/changes-to-stable-distribution
Cilium Service Mesh — https://cilium.io/use-cases/service-mesh/
Isovalent acquired by Cisco (2024) — https://www.isovalent.com/blog/post/welcome-isovalent-cisco/
HashiCorp + IBM (2024) — https://www.hashicorp.com/blog/hashicorp-joins-ibm
Consul Connect — https://developer.hashicorp.com/consul/docs/connect
Kuma — https://kuma.io/
Gloo Mesh (solo.io) — https://www.solo.io/products/gloo-mesh/
Traefik Mesh — https://traefik.io/traefik-mesh/
Open Service Mesh sunset announcement — https://github.com/openservicemesh/osm
AWS App Mesh end-of-support — https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html
CNCF Service Mesh Landscape — https://landscape.cncf.io/?group=projects-and-products&view-mode=card#orchestration-management--service-mesh
Envoy Proxy — https://www.envoyproxy.io/
SPIFFE/SPIRE — https://spiffe.io/
Service Mesh Interface (SMI) — https://smi-spec.io/
Mercari Tech Blog (service mesh) — https://engineering.mercari.com/en/
Cybozu Tech Blog — https://blog.cybozu.io/