eBPF — 커널을 다시 쓰지 않고 리눅스를 확장하는 기술

요즘 클라우드 네이티브 인프라 이야기를 듣다 보면 eBPF라는 단어가 빠지지 않는다. 관측성 도구, 네트워킹 계층, 보안 런타임까지 죄다 "eBPF 기반"을 내세운다. eBPF는 한 줄로 말하면, 커널을 다시 컴파일하거나 모듈을 새로 설치하지 않고도 리눅스 커널 안에서 안전하게 프로그램을 실행하는 기술이다.

처음 이 개념을 접했을 때 나는 반신반의했다. 커널 안에서 코드를 돌린다는 말이 위험하게 들렸기 때문이다. 그런데 구조를 뜯어보니, 오히려 "안전하게 돌리기 위한 장치"가 이 기술의 핵심이었다.

커널 안에서 코드를 돌린다는 것

전통적으로 리눅스 커널의 동작을 바꾸려면 두 가지 길밖에 없었다. 커널 소스를 고쳐 다시 빌드하거나, 커널 모듈을 작성해 적재하는 것이다. 둘 다 위험하고 느리다. 잘못 짠 모듈 하나가 시스템 전체를 멈춰 세울 수 있다.

eBPF는 다른 길을 냈다. 작은 프로그램을 커널에 올리기 전에 검증기(verifier)가 먼저 훑는다. 무한 루프는 없는지, 접근하면 안 되는 메모리를 건드리지는 않는지 확인한 뒤에야 실행을 허락한다. 그래서 커널을 건드리면서도 시스템을 위태롭게 하지 않는다. 이 "검증 후 실행" 모델이 eBPF의 신뢰를 떠받치는 기둥이다.

이 프로그램들은 특정 이벤트에 훅(hook)으로 걸린다. 네트워크 패킷이 도착하는 순간, 특정 시스템 콜이 불리는 순간, 함수가 진입하거나 반환하는 순간 같은 지점에 붙어 그때그때 실행된다. 수집한 데이터는 맵(map)이라는 공유 자료구조를 통해 사용자 공간의 도구로 전달된다. 애플리케이션은 자신이 관찰당하고 있다는 사실조차 모른 채 평소대로 돌아간다. 이 "가로채되 방해하지 않는" 성질이 관측성 도구가 eBPF에 열광하는 이유다.

어디에 쓰이나

관측성

가장 먼저 빛을 본 영역이다. 애플리케이션에 에이전트를 심거나 코드를 계측하지 않아도, 커널 지점에 프로그램을 걸어 시스템 콜·네트워크 연결·지연 시간을 그대로 뽑아낸다. 사이드카를 붙일 필요가 없으니 오버헤드가 작고, 언어에 상관없이 동일하게 관찰된다는 점이 매력이다.

네트워킹

쿠버네티스 네트워크 플러그인 상당수가 eBPF로 옮겨갔다. 패킷을 커널 초입에서 처리하니 iptables 규칙을 길게 늘어놓던 방식보다 빠르고, 규모가 커져도 성능이 잘 무너지지 않는다. 서비스 로드밸런싱과 네트워크 정책을 같은 계층에서 처리하는 그림이다.

보안

런타임에서 프로세스 실행, 파일 접근, 네트워크 시도를 실시간으로 관찰하고 정책에 어긋나면 차단한다. 컨테이너 안에서 벌어지는 일을 커널 시야로 지켜보기 때문에, 애플리케이션이 우회하기 어렵다.

과장은 걸러 듣자

eBPF가 만능은 아니다. 커널 버전 의존성이 있어 오래된 환경에서는 기능 제약이 따르고, 프로그램을 잘못 얹으면 오버헤드가 생길 수 있다. 검증기가 까다로워 복잡한 로직을 짜기가 쉽지 않다는 점도 현실적인 벽이다. 그럼에도 "앱을 고치지 않고 시스템을 관찰·제어한다"는 명제 자체가 워낙 강력해서, 클라우드 네이티브 스택의 바닥 기술로 계속 퍼져 나가는 중이다.

자주 묻는 질문

eBPF와 기존 BPF는 어떻게 다른가요?

초창기 BPF는 패킷 필터링 정도에 쓰이던 좁은 기능이었다. eBPF는 이를 크게 확장해 다양한 커널 이벤트에 프로그램을 걸 수 있게 만든 것으로, 사실상 별개의 기술이라고 봐도 무방하다.

eBPF를 쓰려면 커널을 새로 빌드해야 하나요?

아니다. 오히려 그 반대다. 재컴파일 없이 실행 중인 커널에 프로그램을 올리는 것이 핵심 가치다. 다만 기능마다 요구하는 최소 커널 버전이 있다.

직접 eBPF 프로그램을 짜야 하나요?

대부분은 그럴 필요가 없다. 관측성·네트워킹·보안 도구들이 eBPF를 내부에서 쓰고, 사용자는 상위 인터페이스만 다룬다. 저수준 개발은 특수한 요구가 있을 때만 하면 된다.