..

mesh series: why do we use a service mesh?

Overview

이전 글에서 이번 시리즈의 출발점을 정리했다.
요구사항은 명확하다.

“외부 인입뿐 아니라, 클러스터 내부 서비스 간 통신도 443 기반으로 보호해야 한다.”

가장 먼저 떠오르는 방법은 각 애플리케이션이 직접 HTTPS 서버가 되는 방식이다.
하지만 마이크로서비스 환경에서는 이 접근이 빠르게 한계에 부딪힌다. 이번 글에서는 왜 내부 통신 보안을 애플리케이션이 아니라 Service Mesh가 담당해야 하는지 정리한다.

가장 단순한 접근: 애플리케이션이 직접 TLS를 처리한다

직접 구현 방식은 아래와 같다.

  • 각 서비스가 HTTPS 서버로 동작
  • 서비스별 인증서 발급 및 배포
  • 클라이언트도 HTTPS로 호출
  • 통신 시 인증서 검증 로직 수행

겉으로는 단순하지만, 서비스 수가 늘어나는 순간 운영 복잡도가 급격히 커진다.

왜 애플리케이션이 직접 처리하면 어려운가

첫 번째 문제는 인증서 관리 비용이다.

  • 서비스마다 인증서 필요
  • 만료 주기 관리 필요
  • 배포 시점마다 키와 인증서 동기화 필요
  • 키 유출 리스크 증가

서비스가 많아질수록 발급, 교체, 배포, 만료 대응이 모두 운영 부담으로 바뀐다.

두 번째 문제는 개발자 책임의 확장이다.

TLS는 단순히 스위치를 켜는 일이 아니다.

  • 인증서 검증 로직
  • Hostname Validation
  • Cipher Suite 설정
  • TLS 버전 관리

이 책임을 각 애플리케이션이 직접 가지면, 개발자는 비즈니스 로직 외에 통신 보안 설정까지 떠안게 된다.

세 번째 문제는 기술 스택별 편차다.

  • Java 서비스와 Node.js 서비스의 TLS 설정 방식은 다르다.
  • 프레임워크마다 기본값과 보안 옵션도 다르다.
  • 결국 조직 전체 보안 수준은 가장 약한 서비스에 맞춰질 가능성이 높다.

네 번째 문제는 가시성 부족이다.
애플리케이션 내부에서 TLS를 처리하면 다음을 바로 확인하기 어렵다.

  • 실제로 암호화가 되고 있는지 확인하기 어려움
  • 어느 구간이 TLS로 보호되는지
  • 장애가 발생한 지점이 애플리케이션인지 네트워크인지
  • 정책이 전체 서비스에 일관되게 적용되었는지

즉, 보안은 들어갔지만 운영과 검증이 어려운 구조가 된다.

관점의 전환: 보안을 네트워크 계층으로 내리면?

이 지점에서 질문이 바뀐다.

“TLS를 애플리케이션이 아니라 네트워크 계층이 대신 처리하면 안 될까?”

이 발상에서 출발하는 것이 Service Mesh다. Istio 환경에서는 각 Pod 옆의 Sidecar Proxy(Envoy)가 애플리케이션을 대신해 통신 보안을 담당한다.

즉, 흐름은 아래처럼 바뀐다.

App A → Sidecar A → mTLS → Sidecar B → App B

애플리케이션은 기존처럼 HTTP 요청을 보내고, 실제 네트워크 구간은 Sidecar가 mTLS로 처리한다.

왜 Service Mesh가 더 적합한가

Service Mesh가 적합한 이유는 명확하다.

첫 번째는 인증서 관리 자동화다.

  • Istiod가 인증 기관(CA) 역할을 수행
  • Sidecar에 인증서를 자동 발급
  • 짧은 주기의 인증서를 자동 갱신

개발자가 인증서를 직접 다루지 않아도 된다.

두 번째는 코드 변경 최소화다.

  • 기존 애플리케이션 호출 구조 유지
  • 서비스 코드 수정 없이 보안 정책 반영 가능

보안 요구사항이 들어와도 비즈니스 코드에 연쇄 수정이 퍼지지 않는다.

세 번째는 정책의 일관성이다.

  • 언어와 프레임워크가 달라도 동일한 보안 정책 적용 가능
  • 서비스별 편차가 아니라 플랫폼 수준에서 통제 가능

조직 전체 보안 수준을 일정하게 유지할 수 있다.

네 번째는 관측 가능성이다.

  • 어느 트래픽이 암호화되었는지 확인 가능
  • 메트릭, 로그, 트레이싱 연계 가능
  • 장애 원인 추적이 쉬워짐

즉, 보안이 단순한 설정값이 아니라 관찰 가능한 동작으로 바뀐다.

핵심 비교

  • TLS 적용 위치: 애플리케이션 직접 TLS는 앱이 처리하고, Service Mesh는 Sidecar Proxy가 처리한다.
  • 인증서 관리: 애플리케이션 직접 TLS는 수동 관리가 필요하고, Service Mesh는 자동화할 수 있다.
  • 코드 수정: 애플리케이션 직접 TLS는 코드 변경이 필요하지만, Service Mesh는 거의 필요 없다.
  • 보안 정책 일관성: 애플리케이션 직접 TLS는 서비스별 편차가 생기기 쉽고, Service Mesh는 일관되게 적용할 수 있다.
  • 운영 난이도: 애플리케이션 직접 TLS는 높고, Service Mesh는 상대적으로 낮다.
  • 관측 가능성: 애플리케이션 직접 TLS는 낮고, Service Mesh는 높다.

Conclusion

이번 요구사항의 핵심은 단순히 “HTTPS를 적용하자”가 아니다.
정확히는 “내부 통신 보안을 개발자 코드가 아니라 플랫폼 레이어에서 일관되게 처리하자”에 가깝다.

  • 개발자는 기존 애플리케이션 흐름에 집중한다.
  • Sidecar는 통신 구간의 보안을 책임진다.
  • 운영자는 중앙에서 정책을 통제하고 검증할 수 있다.

그래서 내부 443 요구사항 앞에서 중요한 선택은 “TLS를 넣을까 말까”가 아니라, “누가 그 책임을 질 것인가”다. 그 답이 바로 Mesh다.

Next Step

다음 포스트에서는 Envoy는 어떻게 내 트래픽을 가로채는가: Sidecar와 Transparent Proxy의 실제 구조를 다룬다. 왜 Service Mesh가 더 적합한지 이해했다면, 이제 다음 질문은 자연스럽다.
애플리케이션은 평소처럼 요청했을 뿐인데, 실제 네트워크에서는 Envoy가 어떻게 그 흐름을 대신 통제할 수 있는지 구체적으로 살펴본다.