WERANA
←목록으로
MSA 전환 후 서비스 간 통신이 안 보인다면? eBPF로 Kubernetes 내부 트래픽 가시화하는 방법
기술 해설

MSA 전환 후 서비스 간 통신이 안 보인다면? eBPF로 Kubernetes 내부 트래픽 가시화하는 방법

WWERANA Security Research Team2026년 4월 28일약 4분

서비스가 수십 개로 늘어나면 정작 내부에서 뭐가 오가는지 아무도 모릅니다. 코드 손 안 대고, 사이드카도 없이 K8s 서비스 간 트래픽을 커널에서 직접 들여다본 과정을 공유합니다.

MSA(Microservices Architecture)로 전환한 기업들이 공통적으로 겪는 문제가 있습니다.

지금 서비스끼리 어떤 데이터를 주고받고 있나요? 누가 누구를 호출하고 있죠? 인증 없이 열린 내부 API는 없나요?

서비스는 계속 늘어나는데, 정작 서비스 간 통신 추적은 되지 않는 경우가 많습니다.

특히 Kubernetes 운영 환경, 클라우드 네이티브 인프라, 마이크로서비스 아키텍처(MSA) 에서는 내부 트래픽이 빠르게 복잡해집니다.

외부 트래픽은 WAF, API Gateway, 방화벽으로 어느 정도 관리됩니다. 하지만 Kubernetes 내부 트래픽, 즉 East-West Traffic 은 여전히 사각지대입니다.

weranaSeeker는 실제 고객 환경을 분석하며 이 문제를 해결해왔고, 결론은 명확했습니다.

내부 서비스 통신 가시화는 eBPF 기반 접근이 가장 현실적입니다.

왜 MSA 환경에서는 내부 트래픽 모니터링이 어려울까?

MSA 구조에서는 수많은 서비스가 서로 API를 호출합니다.

MSA 환경에서는 서비스 수가 늘어날수록 내부 호출 관계가 복잡해집니다.

서비스 수가 증가할수록 Kubernetes 내부 트래픽(East-West Traffic) 구조는 빠르게 복잡해집니다. 출처: iximiuz.com

초기에는 단순하지만 서비스 수가 늘어날수록 빠르게 복잡해집니다.

1. 실제 연결 구조가 문서와 달라집니다

아키텍처 문서에는 A → B만 적혀 있어도, 실제 운영에서는 A → C → D → 외부 시스템까지 연결됩니다.

2. 개발팀도 전체 구조를 알기 어렵습니다

각 팀은 자기 서비스는 잘 압니다. 하지만 전체 호출 흐름까지 실시간으로 파악하기는 어렵습니다.

3. 보안팀은 내부 이동을 놓치기 쉽습니다

외부 공격은 탐지해도, 내부 횡적 이동(Lateral Movement)은 놓치기 쉽습니다.

Istio 같은 서비스 메시가 대안일까?

많은 기업이 Istio, Envoy 기반 서비스 메시를 검토합니다.

장점은 분명합니다.

  • L7 트래픽 분석 가능
  • 세밀한 정책 제어
  • mTLS 적용 가능
  • 트래픽 라우팅 유연성

하지만 실제 운영에서는 부담도 큽니다.

Pod 수만큼 사이드카 증가

서비스가 50개면 사이드카도 50개 이상입니다.

CPU / Memory 사용량 증가

Envoy 프록시가 모든 Pod에 붙으면서 리소스 사용량이 커집니다.

장애 분석 난도 상승

문제가 생기면:

  • 앱 문제인지
  • 프록시 문제인지
  • 메시 정책 문제인지
  • DNS 문제인지

빠르게 판단하기 어려워집니다.

기존 운영 환경 변경 부담

이미 운영 중인 기업에 서비스 메시를 먼저 도입하라고 요구하기는 쉽지 않습니다.

그래서 eBPF를 선택했습니다

eBPF는 Linux 커널 레벨에서 네트워크와 시스템 이벤트를 직접 관찰합니다.

즉,

  • 애플리케이션 코드 수정 없음
  • Pod 재배포 없음
  • 사이드카 불필요
  • 언어 / 프레임워크 무관
  • Kubernetes / VM / Bare Metal 대응 가능

운영 환경을 크게 바꾸지 않고 내부 트래픽 모니터링 이 가능합니다.

사이드카 방식은 Pod마다 Envoy를 주입하고, eBPF 방식은 커널에서 직접 트래픽을 관찰하는 구조 비교

eBPF로 서비스 간 통신 추적은 어떻게 가능할까?

애플리케이션이 소켓으로 데이터를 전송하는 시점을 추적합니다.

예를 들어 tcp_sendmsg 같은 커널 함수 시점에서:

  • HTTP Method
  • URL Path
  • Host Header
  • 일부 인증 Header
  • 호출 방향
  • 연결 메타데이터

등을 식별할 수 있습니다.

예:

  • POST /internal/charge
  • GET /user/profile
  • Authorization: Bearer ...

그리고 PID, Container ID, Pod, Namespace와 연결하면:

어떤 서비스가 어떤 서비스로 어떤 API를 호출했는지

자동으로 추적됩니다.

즉, Kubernetes 내부 트래픽 가시화 가 가능합니다.

tcp_sendmsg kprobe 지점에서 eBPF가 HTTP 헤더를 읽어 ring buffer에 기록하는 흐름

실제 고객 환경에서 자주 발견된 문제 3가지

1. 인증 없이 열린 내부 API

가장 흔한 사례입니다.

개발 편의를 위해 내부 API를 열어두고 운영까지 유지되는 경우가 많습니다.

예:

/internal/*
/admin/*
/batch/*

실제 고객사에서는 /internal/charge API가 인증 없이 호출되고 있었습니다.

2. 설계 문서에 없는 신규 연결

정상 통신 패턴을 학습한 뒤, 새로운 연결이 생기면 탐지할 수 있습니다.

예:

  • 배치 서비스 → 결제 서비스 직접 호출
  • 관리자 서비스 → DB 우회 접근
  • 신규 Pod → 민감 API 접근

운영 브랜치에 테스트 코드가 반영되어 이런 사례가 발생하기도 합니다.

3. 평문 HTTP 통신 구간 존재

서비스 수가 많아질수록 TLS 누락 구간이 생깁니다.

한 고객 환경에서는 서비스 28개 중 6개가 평문 HTTP 통신 중이었습니다.

주요 원인:

  • 레거시 시스템 연동
  • 임시 설정 유지
  • 인증서 갱신 누락
  • 내부망이라 괜찮다는 인식

아래는 Cilium Hubble의 서비스 간 트래픽 흐름이 어떻게 시각화되는지 보여주는 참고 예시이고, 벨루나는 서비스맵에 위협을 보여줍니다.

Cilium Hubble UI — K8s 서비스 간 트래픽 흐름 시각화 예시 출처: Cilium Project — Apache 2.0 License

eBPF도 한계는 있습니다

TLS 내부 페이로드는 기본적으로 보이지 않습니다

암호화 이후 패킷은 본문 해석이 어렵습니다.

gRPC 분석은 더 복잡합니다

gRPC는 HTTP/2 기반 멀티플렉싱 구조라 분석 난도가 높습니다.

L7 분석 시 약간의 CPU 오버헤드가 있습니다

하지만 일반적인 사이드카 방식보다 낮은 편입니다.

현재 가능한 기능 정리

기능 지원 여부
L4 연결 탐지 ✅
HTTP 헤더 식별 ✅
서비스 토폴로지 자동 생성 ✅
신규 연결 탐지 ✅
TLS 사용 여부 식별 ✅
gRPC 메서드 분석 진행 중
TLS 내부 페이로드 분석 로드맵

왜 지금 내부 트래픽 가시화가 중요할까?

최근 공격은 외부 침투보다 내부 이동에 집중됩니다.

  • 탈취 계정 사용
  • 정상 서비스 위장
  • 내부 API 호출
  • DB 측면 이동
  • 평문 구간 스니핑

즉, East-West Traffic Visibility 가 없으면 침해 이후 움직임을 놓치기 쉽습니다.

weranaSeeker가 제공하는 기능

weranaSeeker는 eBPF 기반으로 다음 기능을 제공합니다.

  • Kubernetes 서비스 호출 흐름 분석
  • 숨겨진 내부 API 식별
  • 신규 비정상 연결 탐지
  • 평문 통신 탐지
  • 서비스 맵 자동 생성
  • 서비스 간 통신 추적 리포트 제공

30일 무료 POC 진행 중입니다

현재 Kubernetes 내부 통신이 어디까지 파악되는지 직접 검증해보실 수 있습니다.

✔ 서비스 호출 관계 자동 분석 ✔ 평문 통신 구간 탐지 ✔ 숨겨진 내부 API 식별 ✔ 운영 영향도 측정

실제 고객 환경에 적용하여 결과를 함께 확인하는 방식으로 진행합니다.

결론: MSA 시대에는 내부 가시성이 경쟁력입니다

서비스 수가 늘어날수록 장애 원인 분석, 보안 대응, 운영 효율은 더 어려워집니다.

이제는 외부 방어만이 아니라 내부 트래픽 가시화 가 필요한 시점입니다.

MSA 환경에서 서비스 간 통신이 보이지 않는다면, eBPF는 가장 현실적인 선택지가 될 수 있습니다.

참고 자료

다음은 이 글의 기술적 내용을 뒷받침하는 외부 자료입니다.

eBPF 공식 및 생태계

L7 트래픽 가시성

서비스메시와 eBPF

K8s L7 네트워크 정책

eBPF 보안 주의사항

←목록으로