14 · 왜 서비스 메시인가 — 대안 스펙트럼과 손익 분석

이 문서의 자리를 먼저 짚습니다. 01 메시 기초가 답한 질문은 메시가 무엇으로 이뤄져 있고 그 대가가 무엇인지였습니다 — 두 개의 플레인, iptables 가로채기, 네 가지 비용. 그건 메커니즘입니다. 이 문서는 그 앞에 오는 질문을 다룹니다: 같은 문제를 푸는 다른 방법과 비교했을 때 메시가 이기는 조건은 무엇이고 지는 조건은 무엇인가. 01과 겹치는 서술은 링크로 넘기고 여기서는 판단에 필요한 것만 봅니다.

관련 문서: 01 메시 기초 · 06 관측성 · 07 nginx에서 Istio로 · 10 Ambient 이행 심사 · Ambient 도입기 · Envoy 쪽 부품 설명은 12 Envoy가 할 수 있는 것·13 Istio는 Envoy를 어떻게 조립하나

1. 문제의 기원 — 관심사 하나가 서비스 수 × 언어 수만큼 복제된다

메시의 출발점이 “공통 관심사의 중복"이라는 것은 01이 짚었습니다. 여기서는 그 중복의 단가를 봅니다.

Envoy 공식 문서는 이 중복을 분산 아키텍처 일반의 문제로 적습니다 — 그런 아키텍처로 옮길 때 생기는 운영 문제는 대부분 네트워킹과 관측성 두 영역에 뿌리를 둡니다. 같은 문서의 철학 문장은 해법의 방향까지 정해 둡니다: “The network should be transparent to applications. When network and application problems do occur it should be easy to determine the source of the problem.”

istio.io의 정의도 방향이 같습니다 — “A service mesh is an infrastructure layer that gives applications capabilities like zero-trust security, observability, and advanced traffic management, without code changes.” 세 축(트래픽 관리 · 관측성 · 보안)을 코드 수정 없이 인프라 레이어에서 준다고 스스로 정의합니다.

라이브러리 방식이 부러지는 지점

가장 먼저 떠오르는 대안은 공용 라이브러리입니다. 이 비교를 정면으로 프레이밍한 1차 자료는 드문데, Envoy 공식 문서가 그중 하나입니다. 지적하는 마찰은 이렇습니다.

• 언어마다 따로 유지해야 합니다 — Java·C++·Go·PHP·Python 각각의 커뮤니케이션 라이브러리를 별도로 만들고 별도로 올려야 합니다.
• 업그레이드가 앱 배포에 결합됩니다. Envoy를 “각 애플리케이션과 나란히 도는 자체 완결형(self-contained) 프로세스"로 제시하는 이유가 여기입니다 — 언어와 무관한 운용, 그리고 애플리케이션과 분리된 업그레이드.

istio.io 쪽은 같은 결론에 다른 각도로 닿습니다. 아키텍처 문서는 사이드카 프록시 모델의 효용을 재설계나 코드 재작성 없이 기존 배포에 기능을 추가할 수 있다는 취지로 적습니다. “라이브러리 대비"라는 명시적 비교 프레이밍은 Envoy 문서 쪽에서만 확인되고 istio.io 문서 트리에서는 찾지 못했습니다.

실제로 비교해야 할 것은 리드타임이다

기능 유무로 비교하면 라이브러리도 재시도·타임아웃·mTLS를 다 합니다. 차이가 나는 건 정책 하나를 바꾸는 데 걸리는 시간입니다.

라이브러리 방식의 리드타임은 서비스 수에 비례하고 언어가 섞이면 그 앞에 계수가 하나 더 붙습니다. 서비스가 다섯 개면 무시할 만한 계수입니다. 수십 개가 되면 정책 변경 자체가 분기 단위 프로젝트가 됩니다. 메시의 손익이 규모에서 뒤집히는 이유가 이 계수입니다.

2. 대안 스펙트럼 — 관심사를 어디에 놓을 것인가

선택지는 둘로 나뉘지 않고 배치의 스펙트럼을 이룹니다. 왼쪽으로 갈수록 인프라가 가볍고 앱이 무거우며 오른쪽으로 갈수록 반대입니다.

배치는 ① 앱 내 라이브러리, ② API 게이트웨이만, ③ 사이드카 메시, ④ ambient(노드 프록시) 넷입니다. 항목별로 비교하면 이렇습니다.

관심사가 사는 곳

• ① 앱 내 라이브러리: 앱 프로세스 안
• ② API 게이트웨이만: 클러스터 경계 한 지점
• ③ 사이드카 메시: 파드마다 붙는 프록시
• ④ ambient(노드 프록시): 노드마다 ztunnel + 필요한 곳에만 waypoint

커버 범위

• ① 앱 내 라이브러리: 그 라이브러리를 쓰는 서비스 사이만
• ② API 게이트웨이만: 남북만 — 동서 호출은 지나지 않습니다
• ③ 사이드카 메시: 남북·동서 전부
• ④ ambient(노드 프록시): 남북·동서 전부, 단 L7은 waypoint가 있는 구간만

언어 의존

• ① 앱 내 라이브러리: 언어마다 별도 구현
• ② API 게이트웨이만: 없음
• ③ 사이드카 메시: 없음
• ④ ambient(노드 프록시): 없음

업그레이드 결합

• ① 앱 내 라이브러리: 앱 재빌드·재배포에 결합
• ② API 게이트웨이만: 게이트웨이만 갈면 됩니다
• ③ 사이드카 메시: 앱 코드와 분리 (프록시 갱신 시 파드 재시작)
• ④ ambient(노드 프록시): 앱 코드와 분리, 갱신 단위가 노드

운영 비용

• ① 앱 내 라이브러리: 별도 인프라 없음. 대신 언어 수만큼의 유지보수
• ② API 게이트웨이만: 컴포넌트 하나
• ③ 사이드카 메시: 프록시 N개 + 컨트롤 플레인 (02·09)
• ④ ambient(노드 프록시): 프록시 수는 줄고 장애 격리 단위가 노드·네임스페이스로 커집니다

더 볼 곳

• ① 앱 내 라이브러리: —
• ② API 게이트웨이만: 07
• ③ 사이드카 메시: 01~09
• ④ ambient(노드 프록시): 10 · Ambient 도입기

②와 ③ 사이의 칸이 실무에서 가장 자주 오해됩니다. 게이트웨이는 클러스터 경계 한 지점만 덮습니다. 그 경계를 지나지 않는 트래픽에는 게이트웨이가 건 정책도, 게이트웨이가 만든 지표도 존재하지 않습니다.

그러니 “게이트웨이만으로 충분한가"는 동서 트래픽의 양과 다양성을 세면 답이 나오는 질문입니다. 서비스 간 호출이 한두 쌍뿐이면 ②로 끝납니다. 호출 그래프가 촘촘하면 ②는 메시를 대신하지 못하고 메시의 부분집합에 머뭅니다.

3. 이점을 우리 챕터에 매핑 — 증거는 어디 있나

공식 문서의 자기 정의(§1)는 주장이지 증거가 아닙니다. 우리가 실제로 얻은 것은 우리 문서에 남아 있으니 이점 목록 대신 증거의 위치로 적습니다.

• 관측성이 앱 무수정으로 나온다 — 06 — 서비스마다 제각각이던 지표가 동일 스키마로 통일됐고 response_flags·connection_security_policy 같은 표준 라벨 차원이 생겼습니다. 대시보드를 서비스별로 새로 짜지 않습니다.
• 설정이 선언적 리소스로 정리된다 — 07 — nginx.conf 한 파일의 절차적 설정이 관심사별 CRD로 나뉘었습니다. 얻은 것은 분리, 잃은 것은 “이 동작이 어디서 정의됐나"의 국소성.
• 장애를 층으로 나눠 볼 수 있다 — 05 — 간헐적 5xx의 홉을 짚어준 나침반이 Envoy response flag였습니다. 앱 로그만 있었다면 “앱은 멀쩡한데 클라이언트는 실패"에서 조사가 멈춥니다.
• mTLS를 코드 변경 없이 전면 적용 — 01 + 06 — 적용은 [01]의 자동 mTLS, 커버리지 측정은 [06]의 connection_security_policy="none" 한 줄. istio.io도 mTLS 암호화·정책 관리·접근 제어를 메시가 제공하는 통제 항목으로 명시합니다.

위 목록의 세 번째 항목은 양면입니다. 프록시가 단서를 준 것도 맞지만 조사해야 할 층을 하나 늘린 것도 프록시입니다. 그 계산이 다음 절입니다.

4. 비용의 정직한 계산

데이터 플레인 — 프록시 단가와 지연

Istio 공식 Performance and Scalability 문서가 벤치마크 수치를 직접 공개합니다. HTTP 1,000 req/s · 1KB payload 조건, 문서 내 Istio 1.24 기준 벤치마크입니다.

사이드카 값은 파드 수에 1:1로 곱해집니다. 이 곱셈 때문에 Ambient 도입기 01에서 4,000 파드짜리 계산이 나왔습니다. 그 팀이 사이드카를 건너뛴 이유도 여기입니다. 우리처럼 이미 사이드카로 도는 클러스터에서는 같은 곱셈이 02의 리소스 최적화 과제로 나타났습니다.

지연도 공식 문서가 인정합니다 — “Since Istio adds a sidecar proxy or ztunnel proxy on the data path, latency is an important consideration.” P90/P99 지연 벤치마크도 sidecar · ambient L4 · ambient L4+L7 세 배포 모드별로 제시합니다. 문서의 절대값을 우리 SLO에 그대로 옮기면 안 됩니다. 01이 말한 “요청당 프록시 홉 2회"가 우리 꼬리 지연의 어디를 먹는지는 우리 트래픽으로 재야 합니다.

컨트롤 플레인 — 운영 항목이 하나 늘어난다

프록시를 앱 밖에 두면 그 프록시에 설정을 내려보내는 컴포넌트가 생깁니다. 02가 그 부하를 프록시 수 × 변경 빈도 × 설정 범위의 곱으로 정리했습니다. 09는 그 컴포넌트를 스케일할 때 xDS 커넥션이 자동으로 재분배되지 않는다는 함정을 다뤘습니다. 둘 다 라이브러리 방식에는 아예 없는 항목입니다.

공식 문서도 기본값 그대로 규모를 키우면 안 된다고 인정합니다 — 대규모 배포에서는 configuration scoping이 강력히 권장된다고 성능 문서가 적습니다. istio.io가 ‘운영 복잡성(operational complexity)‘이라는 표현을 그대로 써서 메시의 비용으로 인정하는 대목은 성능 문서 밖에서 확인하지 못했습니다.

인지 비용 — 조사해야 할 층이 늘어난다

수치로 잡히지 않지만 실제로 가장 비싼 항목입니다. 11에서 보듯 요청 하나에 L7 파싱 지점이 여러 곳 생기고 05처럼 5xx가 나면 주인을 먼저 가리는 절차가 조사 앞에 붙습니다. 08의 EnvoyFilter는 이 비용의 극단 — 저수준 탈출구는 업그레이드에 취약하고 리뷰하기도 어렵습니다.

메시가 대체하지 못하는 것

가장 자주 과대평가되는 칸입니다. Istio 공식 트래픽 관리 개념 문서가 경계를 직접 긋습니다. 실패 복구 기능은 애플리케이션에 “completely transparent” 하지만 그 실패를 다루는 책임까지 가져가지는 않습니다.

메시는 네트워크 수준 복원력(재시도·타임아웃·서킷브레이킹)을 앱 밖으로 빼줍니다. 대신 비즈니스 수준 폴백은 못 가져갑니다. 라이브러리를 걷어냈다고 앱이 네트워크 실패를 몰라도 되지는 않습니다. 라이브러리 대비 절감폭을 계산할 때 이 칸을 빼먹으면 이득이 과대 계상됩니다.

5. 언제 안 쓰는 게 맞나

앞의 손익표를 뒤집으면 채택하지 않을 조건이 나옵니다.

서비스 수가 적을 때는 §1의 리드타임 계수도 함께 작습니다. 단일 언어·단일 팀이라면 업그레이드 결합도 팀 안에서 조율할 수 있습니다. 라이브러리의 약점이 그만큼 더 줄어듭니다.

마지막 줄은 메시를 실제로 도입한 팀도 인정합니다. 채널코퍼레이션 DevOps팀은 도입 기록에서 개별 기능만 놓고 보면 서비스 메시가 필수는 아니라고 적었습니다. 그럼에도 도입한 근거로는 기능 하나 대신 늘어날 서비스 규모와 인프라 확장성을 들었습니다. 그 저울질의 전문은 Ambient 도입기 01에 있습니다.

이 인정을 뒤집으면 채택 조건이 됩니다. 지금 필요한 기능이 하나인가, 3년 뒤에 셋 이상이 필요해질 규모인가. 하나라면 그 기능의 전용 도구가 이깁니다.

6. 결론 축 — 기능 묶음이 아니라 배치 결정

메시를 “재시도 + mTLS + 관측성 + 카나리 패키지"로 읽으면 도입 판단이 기능 체크리스트가 됩니다. 그러면 §5의 인정대로 어느 칸에서도 메시가 유일한 답이 아니고 판단이 나지 않습니다.

실제 결정은 다른 질문입니다 — 이 공통 관심사를 어느 레이어에 배치할 것인가. 앱 프로세스 안인가, 클러스터 경계 한 지점인가, 파드마다인가, 노드마다인가. 이 질문에는 보편적인 정답이 없고 곱셈의 항이 답을 정합니다.

• 서비스 수 × 언어 수가 커지면 관심사를 앱 안에 두는 비용이 먼저 폭발합니다. 우리가 그 벽에서 메시를 골랐습니다. 그 이후의 기록이 01~09입니다.
• 파드 수가 커지면 관심사를 파드마다 두는 비용이 폭발합니다. 채널팀이 그 벽에서 ambient를 골랐습니다(Ambient 도입기). 우리가 그 벽에 닿았을 때 무엇을 다시 심사해야 하는지가 10입니다.

두 팀은 같은 스펙트럼 위의 다른 칸을 골랐을 뿐 다른 판단을 한 게 아닙니다. 도입 검토서를 쓴다면 기능 목록보다 이 곱셈의 항 — 서비스 수, 언어 수, 파드 수, 동서 호출 밀도 — 을 먼저 세는 편이 빠릅니다.

이 문서에서 가져갈 것

• 비교는 리드타임과 커버 범위로 합니다. 기능 유무는 기준이 못 됩니다 — 라이브러리도 기능은 다 합니다. 그런데 정책 변경 리드타임이 서비스 수 × 언어 수에 비례하고 게이트웨이는 동서 구간을 덮지 못합니다.
• 이점을 주장하려면 증거의 위치를 대야 합니다. 우리 쪽 증거는 [06](관측성 통일) · [07](설정의 선언화) · [05](장애 층 분리) · [01]+[06](mTLS 적용과 커버리지 측정)에 있습니다.
• 청구서는 세 줄입니다 — 프록시 단가(벤치마크 조건에서 사이드카당 약 0.20 vCPU · 60 MB)와 지연, 컨트롤 플레인 운영([02]·[09]), 그리고 수치로 안 잡히는 인지 비용([05]·[08]·[11]).
• 폴백은 여전히 앱 몫입니다. 공식 문서가 명시하는 이 경계를 빼먹으면 라이브러리 대비 절감폭이 과대 계상됩니다.

소스

• Istio 공식 문서 — What is a service mesh? (메시의 자기 정의: zero-trust 보안 · 관측성 · 고급 트래픽 관리를 코드 수정 없이, mTLS·정책 관리·접근 제어 포함): https://istio.io/latest/about/service-mesh/
• Envoy 공식 문서 — What is Envoy (언어별 커뮤니케이션 라이브러리 유지 문제, self-contained 프로세스로서의 사이드카 논거, “The network should be transparent to applications” 철학, 분산 아키텍처 문제의 두 뿌리): https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy
• Istio 공식 문서 — Performance and Scalability (사이드카 0.20 vCPU/60MB · waypoint 0.25 vCPU/60MB · ztunnel 0.06 vCPU/12MB, 배포 모드별 P90/P99 지연 벤치마크, configuration scoping 권고): https://istio.io/latest/docs/ops/deployment/performance-and-scalability/ — 문서 내 벤치마크는 Istio 1.24 기준으로 명시돼 있습니다. 인용 시점의 최신 안정 릴리스와 다를 수 있으므로 도입 검토에 쓸 때는 해당 버전 문서를 다시 확인할 것.
• Istio 공식 문서 — Traffic Management (실패 복구는 앱에 투명하지만 폴백은 앱 책임, 풀 전체 실패 시 Envoy가 503 반환): https://istio.io/latest/docs/concepts/traffic-management/
• Istio 공식 문서 — Deployment Architecture (사이드카 프록시 모델을 기존 배포에 코드 재작성 없이 적용): https://istio.io/latest/docs/ops/deployment/architecture/
• 채널코퍼레이션 기술 블로그 원문 목록은 Ambient 도입기의 참조 블록에 있습니다.