eBPF 정리: 커널을 다시 컴파일하지 않고 확장하는 기술
최근 몇 년 사이 Cilium, Falco, Pixie, Katran 같은 인프라 도구의 소개 페이지마다 eBPF라는 단어가 등장합니다. 결론을 먼저 적으면, eBPF는 커널을 다시 컴파일하거나 모듈을 설치하지 않고, 검증된 작은 프로그램을 실행 중인 커널 안에서 안전하게 돌리는 기술입니다. “커널의 프로그래밍 가능화"라고 부를 수 있고, 관측·네트워킹·보안 도구들이 지난 10년 사이 기반을 eBPF로 옮겼습니다. 이 글은 그 원리와 지형을 정리합니다.
문제: 커널 안에서 일어나는 일을 보고 싶다 #
시스템의 진실은 커널 안에 있습니다. 어떤 프로세스가 어떤 파일을 여는지, 패킷이 어디서 버려지는지, 디스크 I/O가 어디서 지연되는지는 커널만 알고 있습니다. 그런데 커널 안을 들여다보거나 동작을 바꾸는 전통적 방법은 둘 다 문제가 있었습니다.
- 커널 모듈: 무엇이든 할 수 있지만, 버그 하나가 커널 패닉이 됩니다. 모듈 하나 때문에 서버 전체가 죽는 위험을 프로덕션에서 감수하기 어렵습니다.
- 유저스페이스 도구: 안전하지만 느리고 제한적입니다. 예를 들어 패킷을 유저스페이스로 복사해 와서 검사하는 방식은 복사 비용 자체가 병목이 됩니다.
eBPF는 세 번째 길입니다. 작은 프로그램을 커널 안 가상 머신에서 실행하되, 로드 전에 검증기(verifier)가 안전성을 정적으로 증명합니다. 커널의 속도와 시야를 얻으면서 모듈의 위험은 지지 않는 구조입니다.
동작 원리: 검증기라는 문지기 #
eBPF 프로그램의 수명 주기는 이렇습니다.
- 프로그램(보통 C로 작성해 바이트코드로 컴파일)을 커널에 로드합니다.
- 검증기가 모든 실행 경로를 검사합니다. 종료가 보장되지 않는 루프, 허용 범위 밖의 메모리 접근, 초기화되지 않은 값 사용이 있으면 로드 자체가 거부됩니다. 이 문지기 덕분에 “커널 안에서 도는데 커널을 죽일 수 없는” 구조가 성립합니다.
- 통과한 프로그램은 JIT 컴파일되어 네이티브 속도로 실행됩니다.
- 훅(hook)에 연결됩니다. 특정 커널 이벤트가 일어날 때마다 프로그램이 호출되는 구조입니다.
- 수집한 데이터는 맵(map)이라는 커널 내 자료구조에 쌓이고, 유저스페이스 도구가 이것을 읽어 갑니다.
훅 지점이 곧 활용처의 지도가 됩니다.
| 훅 | 언제 불리나 | 대표 용도 |
|---|---|---|
| kprobe / kretprobe | 거의 모든 커널 함수의 진입·복귀 | 임의 지점 트레이싱 |
| tracepoint | 커널이 공식 제공하는 안정적 계측점 | 시스템 콜, 스케줄러, I/O 추적 |
| uprobe | 유저스페이스 함수 | 애플리케이션 함수 추적 |
| XDP | NIC 드라이버, 네트워크 스택 진입 전 | 초고속 패킷 필터·로드밸런싱 |
| tc / socket | 네트워크 스택 각 단계 | 트래픽 제어, 정책 |
| LSM | 보안 결정 지점 | 런타임 보안 정책 |
무엇에 쓰이나: 세 갈래 #
관측(observability)이 가장 접하기 쉬운 갈래입니다. 기존 방식은 애플리케이션에 계측 코드를 넣거나 샘플링 프로파일러를 붙여야 했지만, eBPF는 커널 이벤트에서 직접 데이터를 뽑으므로 대상 프로세스를 수정하지도, 재시작하지도 않고 시스템 전체를 볼 수 있습니다. “어떤 프로세스가 어떤 파일을 여는가”, “TCP 재전송이 어디서 나는가”, “디스크 지연의 분포는 어떤가” 같은 질문이 원라이너로 풀립니다. 서버가 느려요류의 진단에서 표준 도구들이 답을 못 줄 때 꺼내는 다음 층의 도구입니다.
네트워킹은 eBPF가 산업을 바꾼 갈래입니다. XDP는 패킷이 커널 네트워크 스택에 들어가기도 전, NIC 드라이버 수준에서 eBPF 프로그램을 돌립니다. 초당 수백만 패킷의 필터링·전달이 가능해서, DDoS 방어와 L4 로드밸런서가 이 위에 세워졌습니다. Kubernetes 쪽에서는 Cilium이 iptables 체인 대신 eBPF로 파드 네트워킹·정책·로드밸런싱을 구현해 CNI의 사실상 표준 축이 됐습니다.
보안은 시스템 콜과 커널 이벤트를 실시간 관찰해 정책 위반을 탐지·차단하는 갈래입니다. Falco, Tetragon 같은 런타임 보안 도구가 “컨테이너가 갑자기 셸을 실행했다”, “예상 밖 경로에 쓰기를 했다"를 잡아내는 기반이 eBPF입니다.
직접 만져 보기: 도구의 사다리 #
eBPF를 쓰기 위해 C와 커널을 알아야 하는 것은 아닙니다. 사다리가 있습니다.
- bpftrace: awk를 닮은 원라이너 언어입니다. 학습 비용 대비 효용이 가장 큰 진입점입니다.
- bcc 도구 모음: execsnoop(프로세스 실행 추적), opensnoop(파일 열기), biolatency(디스크 지연 히스토그램), tcpretrans(TCP 재전송) 등 이미 만들어진 도구 수십 개가 패키지로 설치됩니다. 대부분의 운영 질문은 이 기성 도구로 끝납니다.
- libbpf + CO-RE: 자체 도구·제품을 만드는 단계입니다. CO-RE(Compile Once, Run Everywhere)가 커널 버전마다 다시 컴파일하던 고통을 크게 줄였습니다.
# bpftrace 원라이너: 지금 시스템에서 열리는 파일을 실시간으로
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'현실적 제약 #
- 권한: eBPF 로드는 기본적으로 root(또는 CAP_BPF 등 세분화된 능력)가 필요합니다. 아무 프로세스나 커널을 계측할 수 있다면 그 자체가 보안 구멍이기 때문입니다.
- 커널 버전: 기능이 커널 버전에 강하게 묶여 있습니다. 최신 기능일수록 최신 커널이 필요하므로, 오래된 배포판에서는 도구가 요구하는 커널 버전 확인이 첫 단계입니다.
- 관리형 환경: 컨테이너 안에서의 eBPF는 호스트 커널 권한 문제와 얽히고, 일부 관리형 서비스에서는 제한됩니다. 노드 데몬(DaemonSet) 형태로 배포하는 것이 표준 패턴인 이유입니다.
- 만능은 아닙니다: 검증기의 제약(프로그램 크기, 복잡도) 안에서 동작하므로, 복잡한 로직은 여전히 유저스페이스와의 협업으로 설계합니다.
정리 #
- eBPF는 검증된 작은 프로그램을 커널 안에서 안전하게 돌리는 기술입니다. 모듈의 위험 없이 커널의 시야와 속도를 얻습니다.
- 안전의 핵심은 검증기입니다. 종료가 증명되지 않거나 메모리 접근이 위험한 프로그램은 로드 자체가 거부됩니다.
- 활용은 관측(무수정·무재시작 계측), 네트워킹(XDP, Cilium), 보안(Falco 등 런타임 탐지)의 세 갈래입니다.
- 입문은 bpftrace 원라이너와 bcc 기성 도구로 충분하고, 제품을 만들 때 libbpf + CO-RE로 넘어갑니다.
- root 권한과 커널 버전 의존이 현실적 제약이므로, 도입 검토는 “우리 커널에서 이 도구가 도는가"부터 시작합니다.