eBPF 혁명: 계측 없는 보안 및 관찰성

2026년 2월 27일 | 읽기 시간: 13분 37초

소개: 커널을 인프라로

수십 년 동안 관찰성은 애플리케이션에 코드를 추가하는 것을 의미했습니다. 메트릭 라이브러리로 서비스를 계측했고, 호출 경로 전체에 추적 SDK를 뿌렸으며, 모든 호스트에서 로그 수집을 구성했습니다. 가시성의 각 계층은 비용이 들었습니다: 의존성 관리, 성능 오버헤드, 배포 및 유지 관리해야 할 코드 변경. 엔드포인트 하나를 놓치면 맹점이 생겼습니다. 라이브러리를 업그레이드하면 원격 측정 파이프라인을 끊을 위험이 있었습니다.

eBPF는 이 방정식을 근본적으로 변경합니다. 애플리케이션을 계측하는 대신 커널을 계측합니다. 모든 시스템 호출, 모든 네트워크 패킷, 모든 파일 접근, 모든 프로세스 실행은 Linux 커널을 통과합니다 — eBPF는 이를 생성하는 애플리케이션을 수정하지 않고도 이 이벤트를 관찰하고 작용하도록 합니다. 코드 변경 없음. SDK 의존성 없음. 배포 조정 없음.

이것은 사소한 개선이 아닙니다. 이것은 다른 기능의 범주입니다. 모니터링 계층이 커널 수준에서 작동할 때, 애플리케이션이 로그하지 않기로 선택한 것, 서비스 메시로 우회하는 네트워크 연결, 컨테이너 런타임이 알지 못하는 프로세스를 포함하여 모든 것을 볼 수 있습니다.

eBPF 생태계는 2025년을 통해 2026년으로 빠르게 성숙했습니다. 한때 연구 프로젝트 및 전문 도구의 모음이었던 것이 이제 대규모로 프로덕션 인프라가 되었습니다. Cilium은 주요 클라우드 공급자의 네트워킹을 처리합니다. Falco는 Kubernetes 클러스터 전 세계 런타임 보안을 제공합니다. Tetragon은 커널에서 직접 보안 정책을 적용합니다. Coroot와 같은 도구는 eBPF 기반 에이전트로부터 전체 스택 관찰성 — 메트릭, 로그, 트레이스, 지속적 프로파일링을 제공하며 애플리케이션 변경이 필요 없습니다.

이 문서는 eBPF가 무엇인지, 보안과 관찰성을 위해 왜 중요한지, 실제로 이를 도입하는 방법을 설명합니다.

eBPF가 실제로 무엇인가

eBPF는 확장 Berkeley Packet Filter의 약자이지만 이름은 대부분 역사적입니다. 최신 eBPF는 패킷 필터링을 훨씬 넘어 이동했습니다.

핵심에서 eBPF는 커널 이벤트에 대응하여 샌드박스된 프로그램을 실행하는 Linux 커널 내의 가상 머신입니다. 이 프로그램은 시스템 호출, 네트워크 트래픽, 파일 작업, 프로세스 스케줄링 및 본질적으로 모든 커널 수준 활동을 관찰할 수 있습니다 — 커널을 수정하거나 커널 모듈을 요구하지 않고.

보안 모델

eBPF를 실용적으로 만드는 것은 보안 모델입니다. eBPF 프로그램이 실행되기 전에 커널 검증자가 철저히 검사합니다:

무한 루프 없음: 프로그램은 반드시 종료되어야 합니다. 검증자는 무한 실행될 수 있는 프로그램을 거부합니다.
잘못된 메모리 액세스 없음: 모든 포인터 역참조가 검증됩니다. 버퍼 오버플로우는 불가능합니다.
스택 크기 제한: 프로그램은 고정 스택 크기 (512 바이트)를 가져 스택 소진을 방지합니다.
도우미 함수 액세스: 프로그램은 임의의 커널 코드가 아닌 사전 승인된 커널 도우미 함수만 호출할 수 있습니다.
권한 요구사항: eBPF 프로그램 로드에는 적절한 기능 (일반적으로 CAP_BPF 또는 root)이 필요합니다.

이 검증은 실행 시가 아닌 로드 시 발생합니다. 프로그램이 검증자를 통과하면 거의 네이티브 속도로 실행되며 런타임 보안 검사가 없습니다. 결과는 무시할 수 있는 오버헤드를 가진 커널 수준 관찰성입니다 — 일반적으로 포괄적 모니터링의 경우 CPU 영향 1-2% 미만입니다.

부착점

eBPF 프로그램은 후크 또는 부착점이라는 특정 커널 이벤트에 부착됩니다:

후크 유형	사용 사례	예
kprobes	모든 커널 함수 추적	`sys_open` 모니터링하여 파일 접근 추적
tracepoints	안정적인 커널 추적 이벤트	`sched_process_exec`를 통한 프로세스 생성 추적
XDP	네트워크 패킷 처리	네트워크 스택에 도달하기 전에 악성 패킷 삭제
TC	트래픽 제어	컨테이너 수준에서 네트워크 정책 적용
LSM	Linux Security Module 후크	파일 작업에 보안 정책 적용
uprobe	사용자 공간 함수 추적	특정 애플리케이션 함수 프로파일
perf events	CPU 성능 카운터	지속적 CPU 및 메모리 프로파일링

부착점의 범위가 eBPF를 매우 강력하게 만듭니다. 단일 eBPF 기반 에이전트는 네트워크 트래픽, 파일 접근, 프로세스 실행, DNS 해석, 시스템 호출 패턴을 동시에 모니터링할 수 있습니다 — 전통적으로 5개 또는 6개의 별도 도구를 필요로 했을 통합 보기를 제공합니다.

관찰성을 위한 eBPF: 모든 것을 보기

기존 관찰성은 3가지 기둥이 있습니다: 메트릭, 로그, 트레이스. eBPF는 계측 없이 세 가지를 모두 활성화하고, 네 번째 — 지속적 프로파일링을 추가합니다 — 이는 애플리케이션 수준 접근 방식으로 실용적이지 않습니다.

제로 계측 서비스 맵

eBPF가 커널 수준에서 네트워크 연결을 모니터링할 때, 서비스 메시, 사이드카 프록시 또는 애플리케이션 수준 계측을 우회하는 연결을 포함하여 서비스 간 모든 TCP 및 UDP 연결을 봅니다. 이는 자동 서비스 발견 및 종속성 매핑을 활성화합니다.

Coroot와 같은 도구는 이 기능을 사용하여 모든 서비스 종속성을 보여주는 라이브 토폴로지 맵을 생성합니다. 코드 변경 필요 없음. 사이드카 컨테이너 없음. 서비스당 구성 없음. 에이전트를 배포하면 몇 분 내에 어떤 서비스가 어떤 서비스와 통신하는지, 각 연결의 지연 시간, 모든 경로의 오류율을 볼 수 있습니다.

이는 특히 다음을 위해 가치 있습니다:

레거시 애플리케이션 상당한 노력 없이 계측할 수 없음
타사 서비스 코드를 제어하지 않음
다양한 환경 다른 서비스가 다른 언어와 프레임워크 사용
프로덕션 문제 디버깅 알려지지 않은 종속성이 연쇄 실패를 일으킴

프로토콜 인식 메트릭

eBPF는 단순히 네트워크 연결을 보지 않습니다 — 이는 프로토콜을 이해합니다. 커널 수준에서 패킷 헤더를 파싱함으로써 eBPF 에이전트는 애플리케이션 인식 없이 애플리케이션 계층 메트릭을 추출할 수 있습니다:

HTTP/HTTPS: 요청 메서드, 경로, 상태 코드, 지연 시간 — 액세스 로그에서 얻을 수 있는 것과 동등하지만 모든 서비스에 자동으로 커널 수준에서 캡처됨.

데이터베이스 프로토콜: PostgreSQL, MySQL, Redis, MongoDB 와이어 프로토콜은 쿼리 지연, 오류율, 연결 수를 추출하도록 파싱됩니다. 이는 데이터베이스 모니터링 에이전트를 설치하거나 연결 문자열을 수정할 필요 없이 데이터베이스 성능 메트릭을 얻는다는 의미입니다.

gRPC: gRPC 프레임워크 구성을 수정하지 않고 gRPC 서비스에 대한 메서드 수준 지연 및 오류 추적.

DNS: 모든 DNS 조회에 대한 해석 지연 및 실패율로, DNS 관련 성능 문제를 디버깅하는 것이 애플리케이션 수준 도구로 악명 높기 쉬움.

Kafka: 브로커 독립적 가시성을 제공하는 메시지 파이프라인 성능으로 프로듀서 및 컨슈머 지연 측정.

지속적 프로파일링

eBPF 기반 관찰성의 아마도 가장 과소 평가되는 기능은 지속적 프로파일링입니다. 기존 프로파일링은 특정 프로세스에 프로파일러를 부착하고, 일정 기간 실행하고, 출력을 분석해야 합니다. 이는 프로덕션 사용에 너무 방해가 되고 자원 집약적입니다.

eBPF 기반 프로파일링은 다르게 작동합니다. perf 이벤트에 부착하고 고정 간격으로 모든 프로세스에서 CPU 스택 추적을 샘플링합니다. 오버헤드는 최소입니다 — 일반적으로 CPU의 1% 미만 — 프로덕션에서 지속적으로 실행하는 것이 가능합니다.

실질적 가치는 의미 있습니다. 서비스가 지연 스파이크를 경험할 때, 프로파일러가 부착된 문제를 재현할 필요가 없습니다. 프로파일링 데이터는 이미 있으며 사건 중에 CPU 시간이 소비된 정확한 위치를 보여주는 화염 그래프로 캡처됩니다. 이는 성능 디버깅을 반응적 조사에서 회고적 분석으로 변환합니다.

보안을 위한 eBPF: 첫 응답자로서의 커널

관찰성은 이야기의 절반입니다. eBPF는 런타임 보안을 위해 동등하게 변형적이며, 관찰성과 보안이 단일 커널 수준 에이전트로 수렴되는 것이 현대 인프라의 가장 중요한 아키텍처 변화 중 하나입니다.

런타임 위협 탐지

기존 보안 모니터링은 로그 분석에 의존합니다 — 애플리케이션 로그, 감사 로그, 시스템 로그에서 침해 지표를 검토합니다. 이 접근 방식은 기본적 제한이 있습니다: 공격자가 로그를 수정하거나 억압할 수 있으며, 애플리케이션이 보안 관련 이벤트를 로그하지 않을 수 있으며, 로그 배송은 이벤트와 탐지 사이에 지연을 도입합니다.

eBPF 기반 보안 모니터링은 다른 수준에서 작동합니다. 시스템 호출 및 커널 이벤트로 후킹함으로써, 이는 로그가 억압할 수 없는 활동을 관찰합니다:

프로세스 실행: 컨테이너 breakout 익스플로잇에 의해 시작된 것을 포함하여 시스템에서 생성된 모든 프로세스
파일 접근: 열린, 읽은, 쓴 또는 삭제된 모든 파일로, /etc/shadow 또는 암호화 키와 같은 민감한 경로 접근 포함
네트워크 연결: 애플리케이션 수준 네트워크 정책을 우회하는 것을 포함한 모든 아웃바운드 연결
권한 에스컬레이션: 프로세스 기능, 사용자 ID 또는 보안 컨텍스트를 수정하는 시스템 호출
커널 모듈 로드: rootkit 설치를 나타낼 수 있는 커널 모듈 로드 시도

정책 적용

탐지는 가치 있지만 예방이 더 낫습니다. eBPF LSM (Linux Security Module) 후크는 커널에서 직접 보안 정책을 적용할 수 있도록 활성화하여 권한 없는 조치가 적용되기 전에 차단합니다.

Cilium 팀에서 개발한 Tetragon이 이 공간의 선도적 도구입니다. 이는 제공합니다:

프로세스 실행 정책: 컨테이너에서 어떤 바이너리가 실행될 수 있는지 정의합니다. Go 바이너리만 실행해야 하는 컨테이너 내에서 셸이 생성되면 Tetragon은 실행을 차단하고 알림을 생성할 수 있습니다.

네트워크 정책: 포드가 커널 수준에서 연결할 수 있는 대상을 적용하여 잠재적 컨테이너 런타임 취약점을 우회합니다.

파일 접근 정책: 프로세스가 접근할 수 있는 파일 및 디렉토리를 제한하여 파일 시스템 권한을 넘어 심층 방어를 제공합니다.

기능 제한: 시스템 호출이 완료되기 전에 정책이 적용되므로 컨테이너 런타임이 이를 부여하더라도 프로세스가 실행할 수 있는 Linux 기능을 제한합니다.

커널에서 적용이 발생하므로 애플리케이션 수준 익스플로잇으로 우회할 수 없습니다. 컨테이너 내 코드 실행을 얻은 공격자는 여전히 eBPF 정책이 차단하는 조치를 수행할 수 없습니다. 왜냐하면 정책이 시스템 호출이 완료되기 전에 적용되기 때문입니다.

네트워크 보안

가장 광범위하게 배포된 eBPF 기반 네트워킹 도구인 Cilium이 Kubernetes 환경에서 네트워크 보안이 어떻게 작동하는지를 재정의했습니다. 기존 네트워크 정책은 IP 주소 및 포트 수준에서 작동합니다. Cilium의 eBPF 기반 정책은 ID 및 API 수준에서 작동합니다:

ID 기반 정책: 정책이 IP 주소 할당을 추적할 필요 없이 Kubernetes 레이블 및 서비스 ID를 참조합니다
L7 필터링: HTTP, gRPC, Kafka 인식 정책은 포트가 아닌 특정 API 엔드포인트 접근을 제한할 수 있습니다
투명한 암호화: 애플리케이션 변경 없이 eBPF를 통한 커널에서 구현된 노드 간 WireGuard 기반 암호화
대역폭 관리: 커널 수준에서 적용된 포드별 대역폭 제한

eBPF 도구 생태계

eBPF 생태계는 각각 특정 영역을 처리하는 몇 가지 주요 프로젝트 주위에서 통합되었습니다.

네트워킹 및 보안

도구	목적	관리자
Cilium	Kubernetes 네트워킹, 네트워크 정책, 서비스 메시	Isovalent (Cisco)
Tetragon	런타임 보안 적용	Isovalent (Cisco)
Falco	런타임 위협 탐지	Sysdig / CNCF
Calico eBPF	eBPF 데이터패스를 가진 Kubernetes 네트워킹	Tigera

관찰성

도구	목적	관리자
Coroot	전체 스택 관찰성 (메트릭, 로그, 트레이스, 프로파일링)	Coroot
Hubble	Cilium용 네트워크 관찰성	Isovalent (Cisco)
Pixie	Kubernetes 관찰성	New Relic / CNCF
Parca	지속적 프로파일링	Polar Signals
Grafana Beyla	HTTP 및 gRPC용 자동 계측	Grafana Labs

추적 및 디버깅

도구	목적	관리자
bpftrace	eBPF용 고수준 추적 언어	IO Visor
BCC	BPF Compiler Collection 툴킷	IO Visor
bpftool	eBPF 프로그램 관리 유틸리티	Linux 커널

실질적 도입: 시작하기

eBPF를 도입하려면 깊은 커널 지식이 필요하지 않습니다. 현대 eBPF 도구는 복잡성을 추상화하고 익숙한 인터페이스를 제공합니다 — 대시보드, 알림, 정책 정의.

관찰성으로 시작

가장 낮은 위험 진입점은 관찰성입니다. Coroot 또는 Grafana Beyla와 같은 eBPF 기반 에이전트를 기존 모니터링 스택 옆에 배포하세요. 에이전트는 애플리케이션 변경을 요구하지 않습니다 — 권한 있는 컨테이너 또는 DaemonSet으로 실행되고 즉시 메트릭 수집을 시작합니다.

Kubernetes 환경의 경우:

# Helm으로 Coroot 배포
helm repo add coroot https://coroot.github.io/helm-charts
helm repo update coroot
helm install -n coroot --create-namespace coroot-operator coroot/coroot-operator
helm install -n coroot coroot coroot/coroot-ce

# 대시보드 접근
kubectl port-forward -n coroot service/coroot-coroot 8080:8080

몇 분 내에 서비스 맵, HTTP 및 데이터베이스 연결에 대한 지연 메트릭, 리소스 사용률 데이터를 볼 것입니다 — 애플리케이션의 계측 변경 없이 캡처됨.

보안 적용 추가

관찰성이 제자리에 있으면 다음의 자연스러운 단계는 보안 적용입니다. Tetragon은 단계적 경로를 제공합니다:

단계 1: 감사 모드. 감사 모드에서 Tetragon을 정책과 함께 배포하세요. 이는 이들을 차단하지 않고 정책 위반을 기록하여 적용 전에 애플리케이션 동작을 이해하고 정책을 개선할 시간을 줍니다.

단계 2: 알림 모드. Tetragon 이벤트를 알림 시스템에 연결하세요. 의심스러운 활동 발생 시 알림을 받습니다 — 예상치 못한 프로세스, 무단 네트워크 연결, 민감한 파일 접근.

단계 3: 적용 모드. 감사 모드에서 검증된 정책의 적용을 활성화하세요. 가장 중요한 제한으로 시작하세요 — 예를 들어 컨테이너 breakout 예방 — 그리고 점차 범위를 확대하세요.

커널 요구사항

eBPF 기능은 Linux 커널 버전에 따라 다릅니다. 최신 eBPF 관찰성 및 보안 도구의 경우:

기능	최소 커널	권장
기본 eBPF	4.4	5.10+
BTF 지원	5.2	5.10+
LSM 후크	5.7	5.15+
BPF 토큰	6.9	6.9+
Ring buffer	5.8	5.10+

대부분의 클라우드 제공자 관리 Kubernetes 서비스 (EKS, GKE, AKS)는 모든 최신 eBPF 기능을 지원하는 커널을 실행합니다. 온프레미스 배포는 최적의 호환성을 위해 커널 5.10 이상을 목표로 해야 합니다.

성능 고려 사항

eBPF 모니터링은 최소한의 오버헤드를 추가하지만 "최소"는 "영"이 아닙니다:

CPU 오버헤드: 일반적으로 포괄적 모니터링 (네트워크, 프로세스, 파일, 프로파일링)의 경우 1-2%
메모리 사용: 대성 및 활동에 따라 노드당 에이전트의 경우 50-200 MB
네트워크 오버헤드: 메트릭 및 이벤트가 중앙 서버로 배송됨; 대역폭 사용은 클러스터 크기 및 활동에 따라
저장소: ClickHouse (Coroot에서 사용) 또는 Prometheus (많은 도구에서 사용)는 서비스 수 및 보관 기간에 비례하는 저장소가 필요합니다

대부분의 환경에서 이 오버헤드는 얻은 가시성에 비해 무시할 수 있습니다. 그러나 고주파 트레이딩 시스템, 실시간 오디오/비디오 처리 및 기타 지연 중요 워크로드는 프로덕션 배포 전에 eBPF 도구를 신중하게 벤치마크해야 합니다.

보안과 관찰성의 수렴

eBPF 생태계에서 가장 의미 있는 추세는 보안과 관찰성이 통합 플랫폼으로 수렴되는 것입니다. 역사적으로 이들은 다른 규율이었습니다: 다른 도구, 다른 팀, 다른 예산. eBPF는 기술적 경계를 지웁니다.

단일 커널 수준 에이전트가 네트워크 연결, 프로세스 실행, 파일 접근, 시스템 호출 패턴을 캡처할 때, 동일 데이터는 두 가지 목적을 제공합니다:

관찰성: "마지막 배포 후 서비스 A의 데이터베이스 지연이 200ms 증가"
보안: "예상치 못한 프로세스가 서비스 A의 컨테이너에서 생성되었고 미지의 IP로 아웃바운드 연결을 만들었습니다"

두 관찰이 동일한 eBPF 데이터 소스에서 나옵니다. 차이점은 데이터가 분석되고 어떤 조치가 트리거되는지입니다. 이 수렴은 에이전트 확산을 감소시킵니다 (3개 또는 4개 대신 하나), 데이터 중복을 제거하고, 실시간으로 보안 이벤트를 성능 영향과 연결하는 상관 관계를 활성화합니다 — 이전에는 불가능했던 관점.

Coroot와 같은 도구는 이미 이 수렴을 체현합니다. 관찰성 대시보드를 SLO 추적 및 이상 탐지와 함께 제공합니다. Cilium과 Tetragon은 함께 단일 플랫폼으로부터 네트워킹, 관찰성, 보안 적용을 제공합니다. 이 수렴이 생태계가 성숙함에 따라 가속화될 것으로 예상하세요.

결론: 새로운 인프라 계층

eBPF는 Linux 커널 기능에서 기초 인프라 계층으로 이동했습니다. 대부분의 주요 클라우드 공급자의 Kubernetes 제공에서 네트워킹을 구동하는 기술입니다. 기존 APM 에이전트를 대체한 관찰성 플랫폼을 구동합니다. 런타임에 컨테이너를 보호하는 보안 정책을 적용합니다.

엔지니어링 팀의 경우 실질적 중요성은 명확합니다: Linux 워크로드를 실행 중이라면 — 특히 Kubernetes에서 — eBPF 기반 도구는 인프라 스택의 일부여야 합니다. 코드 변경 없이 얻을 수 있는 관찰성은 놀랍습니다. 애플리케이션 수정 없이 추가할 수 있는 보안 적용은 변형적입니다. 그리고 두 기능이 통합 플랫폼으로 수렴되는 것은 별도 도구 스택이 할 수 없는 방식으로 작업을 단순화합니다.

관찰성으로 시작하세요. 점차적으로 보안 적용을 추가하세요. 애플리케이션이 해 오던 작업을 커널이 수행하도록 하세요. 그 결과 가치가 있을 것입니다.