"업계에서 가장 거품 낀 기술?" 엔지니어가 직접 털어놓는 '서비스 메시'의 실체

요약 이 글은 백엔드 및 클라우드 네이티브 생태계에서 과도한 마케팅과 함께 거대한 '괴혼(Katamari)' 눈덩이처럼 부풀려진 '서비스 메시(Service Mesh)' 기술의 실체를 다룹니다. 저자는 클라우드 네이티브 트렌드 속에서 양산된 수많은 콘텐츠가 실속 없는 과장(fluff)에 가깝다고 지적하면서도, 소음을 걷어내면 엔지니어링 관점에서 분명한 가치가 존재한다고 설명합니다. 서비스 메시는 애플리케이션 코드를 직접 수정하는 대신 플랫폼 계층에 투명하게 보안, 신뢰성, 관측 가능성(Observability) 기능을 주입하는 소프트웨어 계층입니다. 구조적으로는 서비스 인스턴스 바로 옆에 배치되는 프록시 모음인 '데이터 플레인(Data Plane)'과 이 프록시들을 조율하고 운영자용 API를 제공하는 관리 프로세스인 '컨트롤 플레인(Control Plane)'으로 나뉩니다. 데이터 플레인 프록시는 HAProxy나 NGINX와 유사한 L7 지원 TCP 프록시로, 서비스 간(East-West) 트래픽을 가로채 제어하는 역할을 합니다. 이는 외부 트래픽을 클러스터 내부로 유입시키는 API 게이트웨이나 인그레스(Ingress)와는 초점이 다릅니다. Linkerd의 경우 자체 제작한 경량 Rust 프록시를 사용하며, Envoy 역시 널리 쓰이는 구현체입니다. 이러한 아키텍처는 마이크로서비스 환경에 특화되어 있으며, 각 서비스 인스턴스마다 사이드카 형태로 프록시가 배치되기 때문에 수백~수천 개의 프록시가 실행될 수 있습니다. 이에 따라 통신 시 홉(hop)이 추가되어도 성능 저하가 없도록 프록시가 극도로 빠르고 가벼워야 한다는 구조적 요구사항이 발생합니다. 저자는 서비스 메시가 모든 문제를 해결하는 은총알은 아니지만, 분산 시스템의 네트워크 복잡성을 다루는 데 있어 명확한 가치를 지닌 인프라 기술이라고 요약합니다.