사이드카 패턴은 끝났다? eBPF와 Cilium이 K8s 네트워크를 집어삼킨 진짜 이유

Posted May 27, 2026

Is the Sidecar Pattern Dead? Why eBPF and Cilium Devoured K8s Networking

18 min read

실무에서 K8s를 운영하다 보면 어느 순간 등골이 서늘해질 때가 있습니다. 배포한 건 내 애플리케이션 하나인데, Pod 안에 들어가 보면 정체불명의 컨테이너들이 바글바글하죠. 트래픽 제어한다고 Envoy 붙고, 모니터링한다고 Datadog 에이전트 붙고, 보안 챙긴다고 또 뭔가 붙고. 결국 내 앱은 메모리를 100MB 쓰는데, 옆에 붙은 사이드카(Sidecar)들이 500MB를 퍼먹다가 OOM(Out of Memory)으로 같이 장렬하게 전사하는 꼴, 한 번쯤 겪어보셨을 겁니다.

솔직히 까놓고 말해서, 사이드카 패턴은 너무 무겁습니다. MSA(Microservices Architecture)가 은탄환인 줄 알았던 시절엔 너도나도 Istio를 올렸지만, 막상 트래픽 스파이크가 튀면 이 프록시들의 CPU Throttling 때문에 레이턴시가 지옥을 맛보게 되죠.

그래서 오늘은 최근 인프라 씬을 말 그대로 ‘집어삼키고’ 있는 기술, eBPF(Extended Berkeley Packet Filter)와 이를 기반으로 한 Cilium에 대해 아주 밑바닥까지 파헤쳐 볼까 합니다. 겉핥기식 장점 말고, 커널 레벨에서 도대체 무슨 짓을 하길래 사이드카를 걷어내고도 성능이 미쳐 날뛰는지 증명해 보겠습니다.

💡 TL;DR (한 마디로 요약하면?) eBPF는 리눅스 커널에 ‘안전한 샌드박스형 커스텀 코드’를 심는 기술입니다. 이를 활용한 Cilium 서비스 메시는 “네트워크 패킷을 유저 스페이스의 프록시(Envoy)로 끌어올리지 않고, 커널 단에서 다이렉트로 꽂아버리는” 아키텍처로 통신 지연을 극단적으로 낮춥니다. 사이드카의 시대는 끝났습니다.

🛠️ Under the Hood: iptables의 늪에서 벗어나 커널로 직행하다

먼저 우리가 쓰던 기존 방식(Istio 같은 사이드카 기반 프록시)이 왜 느린지 뼈때리게 짚고 넘어갑시다. A 서비스에서 B 서비스로 HTTP 요청을 보낸다고 가정해 보죠.

기존 구조에서는 패킷이 내 앱 -> Veth 패치 패널 -> iptables 규칙 칭칭 감김 -> 유저 스페이스의 Envoy(사이드카) -> 다시 커널 -> 다시 iptables -> 이더넷 인터페이스 라는 미친 듯한 핑퐁을 거칩니다. 이 과정에서 발생하는 컨텍스트 스위칭(Context Switching)과 메모리 복사 비용이 트래픽이 몰릴 때 시스템을 뻗게 만드는 주범입니다.

하지만 eBPF는 다릅니다. eBPF 프로그램을 리눅스 커널의 네트워크 스택(TC, XDP 등)에 직접 훅(Hook)으로 걸어버립니다. 유저 스페이스로 패킷을 올릴 필요조차 없습니다. 특히 동일한 노드 내의 Pod 간 통신에서는 sockmap 기능을 통해 네트워크 스택 자체를 우회(Bypass)해 버립니다. A 소켓에서 B 소켓으로 데이터를 쏠 때, TCP/IP 스택을 탈 필요 없이 커널 메모리 단에서 곧바로 데이터를 복사해 넘겨주죠.

백문이 불여일견, 기존 방식과 eBPF 기반 방식의 스펙을 비교해 볼까요?

비교 항목	기존 사이드카 모델 (ex. Istio + iptables)	eBPF 모델 (ex. Cilium Sidecar-less)
패킷 처리 위치	User Space (Envoy Proxy)	Kernel Space (eBPF Hook)
네트워크 홉(Hop)	6 ~ 8단계 (iptables 미로)	1 ~ 2단계 (Direct Socket Bypass)
레이턴시 (p99)	수 밀리초 (트래픽 병목 시 급증)	마이크로초(µs) 단위
리소스 점유율	Pod마다 메모리/CPU 할당 필요 (극심함)	노드당 1개의 데몬셋(DaemonSet)만 필요
보안 및 격리	L7 프록시 설정 오류 시 뚫릴 위험	커널 단위 샌드박스로 강제 격리 (안전함)

실제 작동 원리를 코드로 볼까요? Cilium이 커널에 주입하는 eBPF C 코드의 핵심 로직을 의사코드(Pseudocode)로 간소화해 봤습니다.

  
// 커널의 Socket Operations 훅(Hook)에 부착되는 eBPF 프로그램
SEC("sockops")
int bpf_sockmap(struct bpf_sock_ops *skops) {
    // TCP 연결이 수립(ESTABLISHED)되었는지 확인
    if (skops->op == BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB ||
        skops->op == BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) {

        // 출발지 IP/Port와 목적지 IP/Port를 기반으로 eBPF Map에 소켓 정보 저장
        bpf_sock_hash_update(skops, &sock_map, &skops->local_ip4, BPF_ANY);
        // 🚀 핵심 포인트: 이후 통신은 TCP/IP 스택을 우회하고 Map을 통해 다이렉트로 쏴버림!
    }
    return 0;
}

보이시나요? bpf_sock_hash_update 하나로 커널은 “아, 얘네 둘이 통신하는구나? 앞으로는 복잡한 라우팅 테이블 다 씹고 그냥 여기로 직통 연결해 줘”라고 판단합니다. 현업에서 이 구조를 처음 뜯어봤을 때, 솔직히 소름이 돋더라고요. “와, 이렇게 하면 레이턴시가 안 나오는 게 이상하지” 싶었죠.

🎯 Pragmatic Use Cases: 실전에서 어떻게 써먹을 것인가?

그렇다면 이 미친 성능의 아키텍처를 현업에서 어떻게 활용할 수 있을까요? 단순한 마이그레이션이 아니라, 기존 기술로는 해결하기 어려웠던 Pain point를 해결하는 시나리오 두 가지를 제시합니다.

1. 대규모 트래픽 스파이크가 발생하는 이벤트 방어전 (예: 블랙 프라이데이) 이커머스나 대규모 트래픽 도메인에 계신 분들이라면 트래픽이 평소 대비 10배~50배씩 튀는 이벤트를 겪어보셨을 겁니다. 이때 기존 사이드카 모델은 프록시(Envoy)의 워커 스레드가 CPU를 선점하면서 애플리케이션 자체가 CPU Starvation(기아 상태)에 빠집니다. 결국 HPA(Horizontal Pod Autoscaler)가 작동하기도 전에 Pod가 죽어버리죠. Cilium을 도입하면 네트워크 제어가 커널 레벨에서 처리되므로 유저 스페이스의 CPU 경합이 대폭 줄어듭니다. 제가 과거 분석했던 대형 커머스 인프라 전환 사례를 보면, 초당 10만 건 이상의 HTTP 트래픽이 몰리는 상황에서 p99 네트워크 지연 시간을 기존 15ms에서 1.2ms 이하로 약 10배 이상 단축시켰습니다. 클러스터 전체의 메모리 사용량도 30% 넘게 줄일 수 있었고요. 이것만으로도 클라우드 비용(AWS EC2, EKS 노드 등)을 수천만 원 아낄 수 있는 명분이 됩니다.

2. 레거시 DB 쿼리의 Transparent Tracing (코드 수정 제로!) 기획팀이나 DBA가 “현재 병목이 발생하는 DB 쿼리가 정확히 뭔지 다 뽑아주세요”라고 요청하면 개발자들은 한숨부터 쉽니다. 애플리케이션 코드에 무거운 APM 툴을 덕지덕지 붙이거나, JDBC 드라이버를 래핑(Wrapping)해야 하니까요. 이 과정에서 사이드 이펙트가 발생할 확률도 높죠. 하지만 eBPF 기반의 가시성 툴(Cilium의 Hubble)을 쓰면 코드를 단 한 줄도 건드릴 필요가 없습니다. MySQL이나 PostgreSQL의 통신 패킷(Wire protocol)을 커널 단에서 읽어들여 L7 레벨의 쿼리를 캡처해 냅니다.

  
# eBPF 기반의 L7 가시성 및 보안 정책 예시 (CiliumNetworkPolicy)
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule-capture-mysql-queries"
spec:
  endpointSelector:
    matchLabels:
      app: backend-api
  egress:
  - toEndpoints:
    - matchLabels:
        app: database
    toPorts:
    - ports:
      - port: "3306"
        protocol: TCP
      rules:
        l7proto: mysql
        l7:
        - queryAction: "select"
          # Select 쿼리만 통과시키고 실시간으로 메트릭 화, 코드 수정 불필요!

이런 식으로 정책만 던져주면 애플리케이션은 자기가 감시당하는 줄도 모른 채 묵묵히 제 할 일을 하고, 인프라 팀은 쿼리 지연율을 그라파나(Grafana) 대시보드에 우아하게 띄울 수 있습니다.

⚖️ Honest Review & Trade-offs: 과연 완벽한 은탄환일까?

지금까지 극찬을 쏟아냈지만, 10년 차 시니어의 깐깐한 시선으로 볼 때 세상에 공짜는 없고 당연히 한계와 트레이드오프(Trade-off)가 존재합니다. 실무 도입 시 반드시 고려해야 할 ‘불편한 진실’들을 까발려보죠.

1. 커널 버전에 대한 무자비한 종속성 eBPF의 고급 기능들(예: BPF 트램폴린, Ring 버퍼, 최신 XDP 기능 등)을 제대로 쓰려면 리눅스 커널 5.x 이상(권장 5.10 이상)이 필수적입니다. 만약 사내 레거시 인프라가 여전히 CentOS 7(커널 3.10)이나 오래된 RHEL 기반이라면? 당장 도입은 꿈도 꾸지 마세요. 무조건 OS 전면 업그레이드부터 해야 하는 거대한 마이그레이션 프로젝트가 됩니다.

2. “tcpdump로 안 찍혀요!” - 디버깅의 패러다임 전환 운영 환경에서 가장 뼈아픈 부분입니다. 장애가 났을 때 tcpdump나 Wireshark로 패킷을 까보는 것에 익숙한 네트워킹 엔지니어들은 eBPF 환경에서 멘탈이 나갑니다. 패킷이 TCP/IP 스택을 정직하게 타지 않고 커널의 맵(Map)을 통해 순간이동(?) 해버리기 때문에, 기존 툴킷으로는 패킷의 행방이 보이지 않거든요. 반드시 Cilium의 전용 툴인 Hubble을 배워야만 하며, 이는 팀 전체에 새로운 러닝 커브를 강제합니다. 도구가 바뀌면 트러블슈팅 매뉴얼도 전부 새로 써야 한다는 뜻입니다.

3. 완전한 L7 제어의 한계와 프록시의 귀환 Cilium이 L4(TCP/UDP) 레이어에서는 앞서 말한 미친듯한 퍼포먼스를 보여주지만, 복잡한 L7(HTTP/gRPC) 라우팅(예: HTTP 헤더 기반 카나리 배포, 복잡한 재시도 로직, mTLS 페이로드 검증 등)을 수행하려면 한계가 있습니다. 현재 기술력으로는 결국 내부적으로 노드 단위의 Envoy 프록시(DaemonSet 형태)를 띄워서 처리하도록 설계되어 있습니다. 즉, Pod 내부의 ‘사이드카’는 없앴을지언정 클러스터 내에서 ‘프록시’ 자체를 100% 멸종시키진 못했다는 뜻이죠. 무거운 L7 기능을 남발하면 eBPF의 성능적 이점을 많이 갉아먹게 됩니다.

🚀 Closing Thoughts: 그래서 우리는 무엇을 준비해야 할까?

솔직히 처음 eBPF 기반의 네트워크 아키텍처 논문을 접했을 땐 “굳이 커널 영역까지 건드려서 클러스터 전체의 안정성을 떨어뜨릴 리스크를 져야 하나?”라는 보수적인 의구심이 컸습니다. 하지만 K8s가 단순히 컨테이너를 띄워주는 오케스트레이션을 넘어 ‘분산 클라우드 운영체제(OS)’로 진화한 2026년 현재, 유저 스페이스에서 패킷을 돌려막기 하던 기존의 네트워킹 방식은 명백히 유통기한이 끝났습니다.

사이드카 패턴은 마이크로서비스로 넘어가는 과도기적 산물, 혹은 기술적 부채에 가깝습니다. 앞으로 K8s 클러스터에서 비즈니스 로직(애플리케이션 컨테이너) 외에 별도의 무거운 프록시를 억지로 욱여넣는 일은 점점 ‘레거시’ 취급을 받게 될 것입니다.

현업 백엔드 개발자와 인프라 엔지니어라면 이제 추상화된 K8s YAML 파일 뭉치에서 잠시 눈을 돌려, 리눅스 커널과 네트워크 스택의 본질을 다시 들여다봐야 할 때입니다. 겉보기엔 우아해 보이는 MSA와 클라우드 네이티브의 이면에는, 결국 0과 1의 네트워크 패킷을 얼마나 영리하고 비용 효율적으로 나르느냐는 흙먼지 날리는 진흙탕 싸움이 자리 잡고 있으니까요.

여러분은 언제까지 무거운 사이드카에 귀중한 서버 리소스와 클라우드 비용을 헌납하시겠습니까? 이제 두려움을 버리고 커널의 심연으로 직접 뛰어들 시간입니다.

References

https://cilium.io/
https://ebpf.io/
https://github.com/cilium/cilium

Tech

This post is licensed under CC BY 4.0 by the author.