지난달 클러스터 리소스 리포트를 보다가 눈이 멈춘 숫자가 있었다. Envoy 사이드카가 500개 파드에서 잡아먹고 있던 메모리 — 75GB. 이걸 eBPF 기반 스택으로 교체한 뒤 남은 건 12GB였다. 차액 63GB가 고스란히 워크로드에 돌아갔다.

사이드카 프록시의 청구서

Istio든 Linkerd든, 서비스 메시를 도입하면 파드마다 사이드카 컨테이너가 하나씩 딸려온다. 파드 10개일 땐 무시해도 된다. 500개 넘어가면 상황이 완전히 달라진다. 사이드카 하나당 메모리 약 150MB, 500개면 75GB. CPU 오버헤드까지 합산하면 노드 2~3대를 프록시 전용으로 돌리는 꼴이다.

SDK 계측도 만만찮다. OpenTelemetry SDK를 서비스마다 심으려면 코드 수정이 필요하고, 언어별로 라이브러리가 다르고, 의존성 버전도 따로 관리해야 한다. 마이크로서비스가 50개를 넘는 순간 계측 코드 유지보수만으로도 전담 인력이 생긴다.

커널이 전부 본다

eBPF는 리눅스 커널 안에서 실행되는 샌드박스 프로그램이다. 네트워크 패킷, 시스템 콜, 함수 호출을 커널 레벨에서 직접 관찰한다. 앱 코드 변경 없음. 파드 재시작 없음.

2026년 3월 기준으로 프로덕션에서 검증된 스택은 네 가지가 핵심이다.

  • Cilium + Hubble — CNI를 담당하면서 L3~L7 네트워크 가시성을 제공한다. kube-proxy를 대체하는 동시에 트래픽 모니터링까지 해결하는 조합.

  • Grafana Beyla — HTTP와 gRPC 서비스의 RED 메트릭(Rate, Error, Duration)과 트레이스 스팬을 자동으로 뽑아낸다. Go, Java, Python, Node.js, .NET, Rust, C/C++까지 언어를 가리지 않는다.

  • Pixie — 클러스터 내부에서 APM 수준의 트레이스와 서비스 맵을 자동 생성한다. 텔레메트리가 클러스터 밖으로 나가지 않는다는 게 차별점.

  • Tetragon — 보안 옵저버빌리티 담당. 프로세스 실행, 파일 접근, 네트워크 연결을 런타임에서 감시하고 정책 위반 시 차단까지 한다.

원리는 간단하다. 노드당 하나의 커널 프로그램이 해당 노드 위 모든 파드를 관찰한다. "파드 수 × 사이드카"라는 곱셈 구조가 "노드 수 × 1"로 바뀌는 것. CPU 오버헤드는 노드당 1% 미만이다.

Beyla를 K8s 클러스터에 올리는 건 DaemonSet 하나면 된다:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: beyla
spec:
  template:
    spec:
      hostPID: true
      containers:
      - name: beyla
        image: grafana/beyla:latest
        securityContext:
          capabilities:
            add: ["BPF", "SYS_PTRACE", "NET_RAW"]
        env:
        - name: BEYLA_OPEN_PORT
          value: "80,443,8080"
        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: "http://otel-collector:4317"

이것만 배포하면 80, 443, 8080 포트로 들어오는 모든 HTTP 요청의 지연 시간, 에러율, 처리량이 OTel Collector로 흘러간다.

Beyla → OpenTelemetry, 이게 왜 큰 일인가

올해 가장 주목할 움직임은 Grafana Labs가 Beyla를 OpenTelemetry 프로젝트에 기증한 것이다. 새 이름은 OpenTelemetry eBPF Instrumentation. KubeCon EU 2026에서는 Splunk도 자체 OTel eBPF Instrumentation과 Kubernetes Operator를 발표했다.

핵심은 커널 기반 자동 계측이 벤더 중립 표준이 됐다는 점이다. 이전에는 Beyla를 쓰면 Grafana 생태계에 묶이는 느낌이 있었다. OTel 산하로 들어가면서 Jaeger든 Datadog이든 원하는 백엔드로 텔레메트리를 보낼 수 있는 공식 경로가 열렸다. 대규모 K8s를 운영하는 팀 중 67%가 이미 커널 기반 옵저버빌리티 도구를 하나 이상 사용 중이라는 조사도 있다. 실험이 아니라 표준이 된 거다.

도입 전에 현실 체크

만능은 아니다.

커널 버전이 갈린다. 프로덕션 권장은 리눅스 6.1 이상. Ubuntu 24.04, Amazon Linux 2023, Bottlerocket이면 문제없다. 아직 CentOS 7(커널 3.10)을 돌리고 있다면 이 기술의 절반도 활용 못 한다. CO-RE(Compile Once, Run Everywhere) 지원 여부가 도입 가능과 불가능의 분기점이다.

관찰의 깊이에 한계가 있다. 커널 레벨 관찰은 HTTP 요청, DB 쿼리 같은 외부 경계를 잘 포착한다. 하지만 비즈니스 로직 내부의 커스텀 측정 — "추천 알고리즘 A/B 테스트 소요 시간" 같은 건 여전히 SDK 영역이다. 실무에서 현실적인 답은 하이브리드다. 자동 계측으로 전체 가시성을 깔고, 핵심 비즈니스 경로에만 SDK를 정밀하게 붙인다. 건강검진과 정밀검사를 나눠서 하는 것과 같은 논리다.

보안팀과 먼저 대화하자. 커널 프로그램을 로드하려면 CAP_BPF 또는 CAP_SYS_ADMIN 권한이 필요하다. 보안 정책이 까다로운 조직에서는 이게 첫 번째 걸림돌이 된다. 에이전트 파드에만 예외를 적용하는 OPA Gatekeeper 정책을 미리 준비해서 같이 가져가면 설득이 훨씬 수월하다.

이 기술의 진짜 가치는 결국 "공짜 가시성"이다. 개발팀한테 SDK 붙여달라고 설득할 필요 없이, 인프라팀이 DaemonSet 하나 배포하면 다음 날부터 전 서비스의 응답 시간과 에러율이 대시보드에 올라온다. 63GB 메모리 반환은 그냥 보너스고.