eBPF (Extended Berkeley Packet Filter) 동적 커널 트레이싱

핵심 인사이트 (3줄 요약)

본질: eBPF (Extended Berkeley Packet Filter)는 리눅스 커널 소스코드를 고치거나 무거운 커널 모듈을 적재(Load)할 필요 없이, **운영체제 커널의 심장부 안에서 사용자가 짠 프로그램(바이트코드)을 안전하게 샌드박싱(Sandboxing)하여 실행시킬 수 있는 마법의 가상 머신(VM)**이다.

가치: 과거 시스템 콜, 네트워크 패킷, 파일 I/O를 추적(Tracing)하려면 무조건 유저 모드와 커널 모드 사이의 '문맥 교환(Context Switch)'이라는 엄청난 비용을 지불해야 했으나, eBPF는 커널 내부에서 데이터를 필터링하고 요약본만 유저에게 전달하여 관측(Observability) 오버헤드를 1% 미만으로 극한 압축해 낸다.

융합: 단순한 네트워크 패킷 필터링 도구에서 출발하여, 현재는 XDP(고속 네트워킹), 보안 차단(Cilium), 실시간 성능 프로파일링(BCC, bpftrace)을 하나로 묶어 클라우드 네이티브(Kubernetes) 환경의 OS 패러다임을 통째로 갈아엎고 있는 '리눅스의 자바스크립트'로 불린다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념:
- 원래 BPF는 1990년대 tcpdump 도구에서 "수만 개의 패킷 중 TCP 80번 포트 패킷만 잡아라"라는 명령을 커널 안에서 빨리 거르기 위해 만든 필터였다.
- 이를 확장(Extended)한 eBPF는 네트워크를 넘어 디스크 I/O, CPU 스케줄러, 시스템 콜 등 **커널의 모든 함수 호출 지점(Hook)**에 이 필터 프로그램을 붙일 수 있게 만든 커널 내장형 미니 운영체제(VM)다.
필요성(문제의식):
- 서버가 갑자기 렉이 걸린다. 원인을 찾기 위해 개발자가 strace(시스템 콜 추적기)를 켰다.
- 그런데 이 strace 자체가 너무 무거워서, 켜는 순간 시스템 전체가 50배 느려지고 서버가 뻗어버렸다. 추적 도구가 오히려 시스템을 암살하는 "관측자 효과(Observer Effect)"가 발생한 것이다.
- 커널 모듈(LKM)로 직접 추적 코드를 짜서 넣자니, 실수로 while(1) 루프를 잘못 짜거나 포인터 에러를 내면 서버 전체가 커널 패닉(블루스크린)으로 죽어버린다.
- 해결책: "커널 안에 절대 죽지 않는 '안전한 실행 공간(Sandbox)'을 만들자. 유저가 짠 코드를 커널에 넣을 때, 커널이 미리 코드를 다 읽어보고 위험한 짓을 안 하는지 검증한 뒤에만 통과시켜 주자!"
💡 비유:
- 기존 트레이싱: 공장(커널)에서 물건이 잘 만들어지는지 보려고, 외부 감사관(유저 프로세스)이 공장 문을 열고 들어가서 컨베이어 벨트를 멈춰 세우고 물건을 하나씩 밖으로 꺼내서 검사하는 방식 (공장이 멈춤).
- eBPF 방식: 공장장(커널)에게 "이 센서(eBPF 코드)를 컨베이어 벨트 위에 살짝 붙여두세요"라고 건네준다. 센서는 공장이 돌아가는 속도를 1도 방해하지 않고, 안에서 불량품 개수만 조용히 세어서 하루에 한 번 감사관의 스마트폰으로 요약 문자만 틱 보내주는 혁명적 관측법이다.
등장 배경:
- 2014년 리눅스 커널 3.18부터 본격적으로 편입되었다. 클라우드와 마이크로서비스 환경이 극도로 복잡해지면서, 컨테이너 외부에서 내부를 들여다볼 수 있는 거의 유일무이한 엑스레이(X-ray) 기술로 급부상했다.

  ┌─────────────────────────────────────────────────────────────┐
  │                 전통적 트레이싱 vs eBPF 기반 트레이싱 구조 비교        │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  [ 전통적 추적 (예: strace, pcap) ] - 극악의 오버헤드                │
  │                                                             │
  │   User Space    [ 추적 프로그램 (strace) ] ◀──(수백만 번의 복사)──┐ │
  │   ───────────────▲───────────────────────────│──────────│
  │   Kernel Space   │ (이벤트 발생마다 멈춤 & 컨텍스트 스위치)       │ │
  │                  │                                         │ │
  │                  └───── [ 커널 로직 (시스템 콜) ] ◀──────────┘ │
  │                                                             │
  │  [ eBPF 추적 (BPF VM 샌드박싱) ] - 오버헤드 1% 미만                 │
  │                                                             │
  │   User Space    [ eBPF 프론트엔드 앱 ] ◀────(1초에 1번 요약맵만 읽음) │
  │   ───────────────│─────────────────────────▲──────────│
  │   Kernel Space   │ (C 코드를 BPF 바이트코드로 컴파일해 밀어넣음)  │ │
  │                  ▼                                         │ │
  │   ┌──────── eBPF 샌드박스 VM ───────────────────────────────┐ │
  │   │ 1. 검증기(Verifier): "루프 없고, 메모리 접근 안전하군. 통과!" │ │
  │   │ 2. JIT 컴파일러: 기계어로 번역하여 빛의 속도로 만듦            │ │
  │   │ 3. BPF Map (공유 메모리): 여기에 통계(Count)만 몰래 쌓음 ───┘ │
  │   └─────────────────────────────────────────────────────┘ │
  │     ▲ (이벤트 발생 시 BPF 코드만 0.001초 실행)                       │
  │   [ 커널의 모든 Hook (kprobe, tracepoint, XDP 등) ]            │
  └─────────────────────────────────────────────────────────────┘

[다이어그램 해설] eBPF의 천재성은 'BPF Map(맵)'이라는 특수한 공유 메모리 구조에 있다. 예전에는 이벤트를 모두 잡아서 유저 영역으로 다 넘겨줬다(데이터 덤프). eBPF는 유저가 던져준 코드(예: "파일 읽기 에러가 나면 맵의 카운트 변수만 +1 해라")를 커널 안에 이식한다. 이벤트가 터지면 커널 공간 안에서 즉시 +1 연산이 끝나고 프로그램은 하던 일을 마저 한다. 유저 프로그램은 느긋하게 1초에 한 번씩 저 BPF Map만 쓱 들여다보면 된다. 이렇게 '데이터'를 움직이는 대신 '코드'를 데이터가 있는 커널 쪽으로 움직여 버렸기 때문에 문맥 교환이 완전히 증발해 버린 것이다.

📢 섹션 요약 비유: 경찰이 과속 차량을 잡을 때, 톨게이트를 막고 모든 차를 멈춰 세워 속도계를 일일이 검사하는 게 구형 방식입니다. eBPF는 도로 위에 스마트 과속 단속 카메라(BPF 코드)를 달아두고, 카메라는 차를 멈추지 않게 하면서 과속한 차량 번호만 조용히 경찰서(BPF Map)로 전송하는 가장 세련된 행정망입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

eBPF 3단계 실행 파이프라인 (보안과 성능의 타협점)

커널 안에 남의 코드를 넣는다는 건 서버 자폭 스위치를 넘겨주는 것과 같다. 리눅스는 이를 막기 위해 잔혹한 검문소를 만들었다.

바이트코드 컴파일: 개발자는 보통 C언어나 Python(BCC)으로 코드를 짠다. LLVM/Clang 컴파일러가 이를 eBPF 전용 바이트코드(어셈블리)로 변환한다.
검증기 (Verifier) 🛡️: 커널에 들어가는 순간, 리눅스 커널의 검증기가 코드를 한 줄 한 줄 정적 분석한다.
- "무한 루프(while true)가 있는가?" $\rightarrow$ 있으면 즉각 거부! (커널 멈춤 방지)
- "허가되지 않은 커널 메모리를 침범하는가?" $\rightarrow$ 거부!
- "코드 크기가 4096 명령어를 넘는가?" $\rightarrow$ 거부! (최근엔 한도 늘어남)
JIT (Just-In-Time) 컴파일러 🚀: 검증을 통과한 착한 바이트코드는, 가상 머신에서 해석(Interpret)되는 대신 CPU가 직접 씹어 먹을 수 있는 순수 기계어(Native Machine Code)로 즉시 번역(JIT)되어 커널 훅(Hook)에 찰싹 달라붙는다. 성능 하락이 0에 수렴하는 이유다.

eBPF 훅(Hook) 포인트의 무한한 세계

eBPF 코드는 도대체 커널의 어디에 붙일 수 있는가? 거의 모든 곳이다.

Hook 종류	설명 및 활용 예시	성능 오버헤드
kprobes / kretprobes	커널 내의 모든 C 함수 시작점(kprobe)과 끝점(kretprobe)에 동적으로 낚싯바늘을 건다. (예: `tcp_sendmsg` 함수 호출 추적)	약간 있음 (동적 트레이싱)
Tracepoints	커널 개발자들이 "여긴 중요해"라며 소스 코드에 미리 하드코딩으로 박아둔 정적(Static) 마커. kprobe보다 안정적이다.	매우 적음
uprobes	커널이 아니라, 사용자 공간 애플리케이션(Node.js, Go 앱 등)의 특정 함수에 낚싯바늘을 건다.	약간 있음
XDP (eXpress Data Path)	네트워크 랜카드(NIC) 드라이버가 패킷을 받아 커널로 올리기도 전인 최하단 바닥에 코드를 꽂는다.	거의 0 (빛의 속도)

📢 섹션 요약 비유: 수술실(커널)에 CCTV를 설치하려는데, 의사가 실수로 카메라 전선을 메스(칼)로 잘라서 환자가 죽으면 안 되잖아요? 그래서 병원장(검증기)이 카메라가 수술을 절대 방해하지 않고 100% 안전하다는 걸 검사한 뒤에만, 의사 머리, 손, 수술 도구(다양한 Hook) 등 원하는 모든 곳에 렌즈를 달아주는 구조입니다.

Ⅲ. 융합 비교 및 다각도 분석

커널 모듈 (LKM) vs eBPF 아키텍처 비교

과거에는 커널의 행동을 바꾸거나 관측하려면 무조건 C언어로 커널 모듈(*.ko)을 짜서 넣어야 했다.

비교 항목	LKM (Loadable Kernel Module)	eBPF (Extended BPF)
안전성 (Safety)	위험. 널 포인터 역참조 하나만 내도 커널 패닉(블루스크린) 발생.	100% 안전. 검증기(Verifier)가 위험한 코드를 애초에 커널 진입 불가로 막아냄.
버전 호환성	리눅스 커널 버전이 바뀌면 매번 다시 컴파일(Rebuild)해야 함.	CO-RE (Compile Once, Run Everywhere) 기술 지원으로 한 번 짜면 모든 버전에서 돎.
업데이트 중단 여부	모듈을 교체(`rmmod`, `insmod`)할 때 연결이 끊기거나 서버 멈춤.	시스템이나 트래픽이 흐르는 중간에 실시간(On-the-fly)으로 훅을 뗐다 붙였다 가능.
용도	무거운 디바이스 드라이버, 파일 시스템 제작	관측(Observability), 보안 필터링, 초고속 네트워킹

과목 융합 관점

네트워크 (XDP & DPDK): 100Gbps 트래픽을 감당하기 위해 유저가 커널을 우회(Bypass)해서 NIC 메모리를 직접 읽는 DPDK가 대세였다. 그런데 DPDK는 유저 앱이 폴링(무한 루프)하느라 CPU 코어 1개를 통째로 100% 낭비해야 했다. eBPF의 최강 폼인 XDP는 커널을 우회하지 않고, 아예 패킷이 NIC 큐에 닿자마자 실행되는 바닥에 eBPF 훅을 걸어버린다. 앱이 아니라 커널 바닥에서 패킷을 즉시 Drop 시키거나 라우팅해 버리므로 CPU 낭비 없이 디도스(DDoS) 공격 1,000만 패킷을 방어하는 기적을 쓴다. (Cloudflare가 이 기술로 디도스를 막는다).
보안 및 컨테이너 (Cilium & Tetragon): 기존 쿠버네티스의 네트워크(iptables 기반)는 규칙이 1만 개가 넘어가면 선형 탐색 병목으로 네트워크가 멈췄다. Cilium은 iptables를 다 찢어버리고 통신 통제를 eBPF 해시 맵으로 교체해 O(1)의 속도를 달성했다. 게다가 컨테이너 내부의 해커가 /etc/passwd 파일을 읽으려고 시스템 콜을 부르는 순간, eBPF 보안 훅(Tetragon)이 그 시스템 콜을 커널단에서 즉각 차단하고 프로세스를 사살(Kill)하는 제로 트러스트 런타임 보안의 완성형이 되었다.
📢 섹션 요약 비유: LKM이 병에 걸린 환자(OS)의 배를 가르고 장기를 직접 교체하는 위험한 개복 수술이라면, eBPF는 환자 몸에 칼을 대지 않고 혈관 속에 나노 로봇(바이트코드)을 투입해 암세포(비정상 트래픽)만 타격하고 나오는 최첨단 비침습적 수술입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오 및 트러블슈팅

시나리오 — 마이크로서비스(MSA) 환경의 미친 레이턴시 추적: 수십 개의 컨테이너가 얽힌 K8s 환경에서 특정 API 응답이 가끔 1초 넘게 튄다. 앱 로그에는 정상으로 찍히고, CPU도 널널하다. 도대체 네트워크 스택에서 지연된 건지, 디스크 I/O 큐에서 막힌 건지 알 길이 없다.
- 원인 분석: 애플리케이션 코드는 정상이지만, 호스트(Node)의 TCP/IP 스택이나 블록 스토리지 디스패치 레이어에서 병목이 걸린 것이다. 기존 도구로는 이 마이크로 구간의 지연을 측정할 수 없다.
- 아키텍트 판단 (BCC / bpftrace 툴셋 도입): eBPF 기반의 프로파일링 도구인 bpftrace를 Node 호스트에 투입한다. bpftrace -e 'kprobe:tcp_sendmsg { @start[tid] = nsecs; } kretprobe:tcp_sendmsg /@start[tid]/ { @ms = (nsecs - @start[tid]) / 1000000; delete(@start[tid]); }' 같은 한 줄의 스크립트만으로, 커널의 TCP 전송 함수가 호출되고 끝날 때까지의 정확한 밀리초 단위 지연 시간의 히스토그램(분포도)을 뽑아낸다. 이를 통해 TCP 재전송 타임아웃인지 디스크 지연인지 핀포인트로 범인을 검거한다.
시나리오 — 디도스(DDoS) 공격 시 iptables 룰 한계로 인한 셧다운: 초당 500만 개의 악성 SYN 플러딩 공격 패킷이 들어온다. 방화벽(iptables)에 차단 IP 룰을 수만 개 등록했더니, 서버가 정상 트래픽조차 처리하지 못하고 CPU 100% (SoftIRQ)를 치며 마비되었다.
- 원인 분석: iptables (Netfilter)는 커널 네트워크 스택의 상당히 위쪽에 있다. 패킷이 랜카드 $\rightarrow$ 커널 메모리 할당(sk_buff 구조체 생성) $\rightarrow$ 라우팅 판단을 다 거친 뒤에야 비로소 iptables 규칙(List 순차 검색)에 부딪혀 드롭(Drop)된다. 쓰레기 패킷 하나 버리겠다고 커널이 너무 많은 정성(메모리와 CPU)을 쏟아부어 과로사한 것이다.
- 아키텍트 판단 (XDP Drop 도입): 방화벽을 iptables에서 eBPF XDP로 전면 전환한다. XDP는 패킷이 메모리 구조체(sk_buff)로 조립되기도 전인 랜카드 드라이버의 생바닥에서 eBPF 코드를 실행한다. 차단 IP 목록은 eBPF 맵(해시 테이블, O(1))에 넣는다. 악성 패킷이 랜카드에 닿자마자 CPU 코어 1개가 1클럭 만에 패킷을 갈기갈기 찢어버린다(XDP_DROP). 서버의 CPU 사용률은 거짓말처럼 5% 미만으로 떨어지고 500만 패킷 방어에 성공한다.

  ┌───────────────────────────────────────────────────────────────────┐
  │                 리눅스 네트워크 스택과 eBPF XDP 패킷 파괴의 층위 차이        │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [일반 방화벽 iptables의 깊은 방어선 (CPU 피로도 높음)]                  │
  │   [물리적 랜카드(NIC)] ──▶ 메모리 할당(sk_buff) ──▶ TCP/IP 스택 파싱    │
  │   ──▶ iptables 룰 1만 개 순차 탐색 ──▶ "아, 이거 악성 패킷이네. 버려!"     │
  │   (※ 버리기까지 너무 많은 CPU 연산과 램이 소모됨)                       │
  │                                                                   │
  │   [eBPF XDP의 극단적 선제 방어선 (CPU 낭비 제로)]                       │
  │   [물리적 랜카드(NIC)]                                              │
  │           │  ◀── [ eBPF XDP Hook ] 패킷이 닿자마자 0.001초 만에 검사 │
  │           ▼                                                      │
  │     "악성이다! 버려!" ──▶ XDP_DROP (커널 스택 구경도 못하고 즉시 소멸)    │
  │                                                                   │
  │   ▶ 아키텍트의 무기: 방어선은 최대한 적군(인터넷)과 가까운 최전방에 쳐야,       │
  │                    아군(커널)의 물자(CPU/RAM)가 낭비되지 않는다.         │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이것이 클라우드 네이티브 네트워크의 패러다임을 바꾼 그림이다. 성능 최적화의 1원칙은 "쓸데없는 일은 최대한 빨리 포기하는 것(Fail Fast)"이다. eBPF XDP는 리눅스 커널의 거대한 공룡 같은 네트워크 스택을 100% 우회하여, 하드웨어 바로 위에서 C 코드를 실행하게 해준다. 클라우드 벤더(AWS, Google)들은 이 XDP 계층에서 디도스 차단, 로드 밸런싱, NAT(네트워크 주소 변환)를 모조리 끝내버린 뒤 깨끗한 패킷만 컨테이너로 올려보내는 초효율 아키텍처를 완성했다.

안티패턴

운영 서버에 검증되지 않은 복잡한 무한 eBPF 루프 코드 주입: BPF Verifier(검증기)가 과거에는 무한 루프를 원천 금지했지만, 최신 커널(5.3+)에서는 Bounded Loop(제한된 루프)를 허용하기 시작했다. 이를 악용(?)하여 경험 없는 개발자가 컨테이너의 모든 네트워크 페이로드를 문자열로 딥 인스펙션(DPI)하겠다고 복잡한 루프 코드를 짜서 운영계 커널에 꽂는 행위. Verifier를 통과했다 하더라도, 패킷 1개당 1,000 클럭씩 소모하는 무거운 BPF 코드가 꽂히면 결국 인터럽트 처리 지연(Latency)이 터져 서버 전체의 네트워킹이 박살 난다. eBPF는 만능이 아니라 마이크로초 단위의 "가벼운 찔러보기(Poke)" 도구여야 한다.
📢 섹션 요약 비유: 검문소(eBPF 훅)를 국경선 맨 앞(XDP)으로 당겨서 간첩을 입국 전에 돌려보내는 건 환상적입니다. 하지만 그 앞마당 검문소에서 수백만 명의 여권만 보는 게 아니라 가방을 다 뜯어보고 일기장까지 읽게(무거운 로직) 시키면, 국경 전체의 교통이 마비되어 무역이 망하는 안티패턴이 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	레거시 트레이싱/방화벽 도구 (strace, iptables)	eBPF / XDP 기반 프레임워크 (Cilium, BCC)	개선 효과
정량 (관측 오버헤드)	CPU 오버헤드 30% 이상, 프로덕션 사용 불가	런타임 오버헤드 1% 미만 보장	라이브(Live) 상용 서버의 무중단 실시간 프로파일링
정량 (패킷 드롭 스루풋)	단일 코어당 최대 수십만 pps 처리 한계	단일 코어당 수천만 pps (XDP) 처리	DDoS 방어 및 L4 로드밸런싱 하드웨어 장비 대체
정성 (안전성 및 유연성)	커널 모듈 패닉 위험, 리부팅 동반	Verifier 보장 완벽 샌드박싱 및 실시간 핫플러그	시스템 재부팅 0초, 패닉 위험 0%의 무한 확장성

미래 전망

Cilium과 Kube-proxy의 종말: 쿠버네티스의 기본 네트워킹인 Kube-proxy(iptables 기반)는 서비스가 1만 개로 늘어나면 라우팅 업데이트에 수 분이 걸린다. 이를 완전히 걷어내고 통신, 로드밸런싱, 암호화(WireGuard)를 모조리 eBPF 해시맵으로 대체해버린 Cilium이 사실상 차세대 K8s CNI(컨테이너 네트워크 인터페이스)의 세계 표준으로 천하통일을 이루고 있다.
eBPF 기반 스케줄러 (sched_ext): 리눅스 커널의 보수적인 프로세스 스케줄러(CFS)마저 eBPF의 침공을 받았다. 게임 회사는 게임에 맞는 스케줄러를, AI 회사는 GPU에 특화된 스케줄러를 커널 소스 수정 없이 eBPF 코드로 런타임에 갈아 끼우는 '플러그인 스케줄러' 시대가 커널 6.11부터 본격적으로 개막했다. OS는 뼈대만 제공하고, 모든 정책(Policy)은 유저가 eBPF로 주입하는 "사용자 정의 운영체제(User-Defined OS)"의 최종 흑막이다.

참고 표준

eBPF ISA (Instruction Set Architecture): 리눅스 재단(eBPF Foundation)이 관리하는 범용 가상 머신 명령어 셋 표준. 이제 리눅스를 넘어 윈도우(eBPF for Windows)와 BSD까지 도입 중이다.
CO-RE (Compile Once – Run Everywhere): 리눅스 커널의 자료구조(Struct) 배치가 버전마다 달라서 eBPF 코드가 깨지는 문제를 막기 위해, 커널의 BTF(BPF Type Format) 디버그 정보와 결합하여 어떤 커널 버전에서든 알아서 오프셋을 재조정해 돌아가게 만든 혁명적인 호환성 표준.

eBPF 동적 커널 트레이싱 프레임워크는 리눅스가 30년 역사상 이룩한 가장 위대한 발명품 중 하나로 평가받는다. 무겁고 위험한 쇳덩어리였던 '운영체제 커널'의 배를 가르지 않고도, 그 안에 수만 개의 스마트 센서와 혈관 우회로(XDP)를 자유자재로 설치할 수 있게 만들었다. 이것은 단순한 성능 최적화를 넘어, 클라우드 엔지니어들이 거대한 인프라의 내부 장기(네트워크, 메모리, 스케줄링)를 나노초 단위로 꿰뚫어 보고 심장 박동을 통제할 수 있게 해 준 신의 현미경이자 메스(Scalpel)다.

📢 섹션 요약 비유: 두꺼운 강철 잠수함(운영체제 커널)에 구멍(취약점/모듈)을 뚫어 밖을 보려다 물바다가 되어 가라앉았던 과거에서 벗어나, 잠수함 외벽에 수만 개의 초정밀 투명 유리창과 로봇 팔(eBPF 훅)을 달아 잠수함의 내구성을 100% 유지하면서도 심해(시스템 성능)를 완벽하게 지휘하고 조종하는 심해 탐사의 혁명입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
커널 모듈 (LKM)	과거 eBPF의 역할을 대신했던 무겁고 위험한 통로로, 사소한 널 포인터 에러가 전체 시스템을 블루스크린(패닉)으로 몰고 가는 구시대의 유물이다.
XDP (eXpress Data Path)	eBPF가 랜카드 하드웨어 칩 직후에 꽂아 넣은 궁극의 네트워크 최전방 훅으로, iptables를 우회해 천만 패킷을 썰어버리는 무기다.
문맥 교환 (Context Switch)	관측(Tracing) 도구들이 커널에서 유저로 이벤트를 퍼 올릴 때 시스템을 마비시키는 원흉이며, eBPF는 커널 안에서 결과를 요약(맵)하여 이를 멸종시켰다.
Cilium / Tetragon	eBPF를 뼈대로 삼아 쿠버네티스의 낡은 iptables 네트워킹을 갈아엎고 런타임 보안까지 제압해 버린 현대 클라우드의 최고 존엄 오픈소스다.
시스템 콜 (System Call)	해커(루트킷)가 시스템을 장악하기 위해 지나는 길목으로, eBPF 훅을 여기 걸어두면 해커의 모든 은밀한 파일/네트워크 조작을 초기에 차단할 수 있다.

👶 어린이를 위한 3줄 비유 설명

자동차 공장(운영체제)이 잘 돌아가나 보려고 1분마다 공장장(트레이싱 도구)이 기계를 전부 세우고 일일이 불량품을 세어보면 공장이 망하겠죠?
eBPF 마법은 공장 기계를 1초도 멈추지 않고, 컨베이어 벨트 위에 아주아주 작고 안전한 '투명 센서'들을 찰싹 붙여놓는 기술이에요.
이 센서들은 공장 속도에 전혀 방해를 주지 않고 "오늘 불량품 3개!"라고 요약 노트(BPF Map)에만 몰래 적어두기 때문에, 컴퓨터를 엄청 빠르고 안전하게 관리할 수 있답니다!