LabHub

블로그

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

2026-05-16 · 33 분 읽기 · #service-mesh#istio#linkerd#cilium#consul#kuma#gloo-mesh#traefik-mesh#sidecar#ambient#ztunnel#waypoint#mtls#envoy#deep-dive

한국어English日本語

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

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

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

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

  1. Sidecar 모델 — 전통 Istio, Linkerd 2/3, Consul Connect의 default.
  2. Ambient 모델 (L4 + L7 분리) — Istio Ambient(ztunnel + waypoint), Linkerd의 일부 패턴.
  3. 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 AmbientL4 + L7 분리CNCF1.22 GA(2024). 채택 가속.
Linkerd 2사이드카 (Rust micro-proxy)Buoyant가벼움. 유지보수 모드.
Linkerd 3사이드카 + 일부 ambient 패턴Buoyant (paid edition 도입)커뮤니티 논란.
Cilium Service MesheBPF + Envoy 옵션Cisco (Isovalent 인수)빠르게 성장.
Consul Connect사이드카 (Envoy)IBM (HashiCorp 인수)거버넌스 불확실.
Kuma사이드카 / multi-zoneKong / CNCF (Sandbox)federated mesh 강함.
Gloo MeshIstio 위 multi-clustersolo.io (상용)엔터프라이즈 표준.
Traefik MeshDaemonSet 프록시Traefik Labs가벼움 / 단순.
Open Service Mesh사이드카Microsoft (sunset 2024-01)종료.
AWS App Mesh사이드카 (Envoy)AWS (sunset 2024-10)종료.

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

세 모델은 다른 트레이드오프를 갖는다. 사이드카는 "성숙하지만 비싸다", 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)

왜 이게 의미 있나?

왜 모두가 Ambient로 가지 않나?

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

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

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

sidecar Istio의 장점은 여전하다:

단점도 여전하다:

언제 sidecar Istio가 정답인가?

권고: 새로 시작하면 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 라이선스가 필요해졌다.

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

Linkerd 3의 기술적 변화:

2026년 현재의 시선:

선택 기준:

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의 모델:

왜 eBPF mesh가 매력적인가?

현실적 한계:

2026년 시점의 권고:

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의 강점(여전히):

약점·우려:

언제 Consul Connect가 정답인가?

언제 피하는가?

7장 · Kuma (Kong) — federated mesh

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

Kuma의 아키텍처:

다른 mesh 대비 강점:

약점:

언제 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가 핵심인 곳. 금융권·통신사·일부 빅테크 SRE 조직.

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

9장 · Traefik Mesh — 가벼운 옵션

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

장점:

약점:

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

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

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

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

OSM의 종료가 시사하는 것:

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

전체 교훈:

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

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

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

11.1 mTLS — 가장 자주 쓰는 이유

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

운영 팁:

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/*']

운영 팁:

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

운영 팁:

11.4 관찰성 — golden signals

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

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

대시보드:

운영 팁:

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

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

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

Ambient의 입장 (Istio Ambient)

eBPF / proxyless의 입장 (Cilium)

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

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

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

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

토스 — Istio + 점진적 ambient 실험

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

핵심 선택 이유:

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

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

핵심 패턴:

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

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

기술 블로그 공개 사례:

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월 기준):

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

참고 / References

원문 보기: https://www.youngju.dev/blog/culture/2026-05-16-service-mesh-2026-istio-ambient-linkerd-3-cilium-mesh-consul-connect-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다