eBPF 무계측 수집은 SDK 계측을 대체할 만큼 가벼운가?
결론부터 말하면 "대체"가 아니라 "분업"이다. eBPF는 CPU 오버헤드 면에서 전통 APM 에이전트보다 뚜렷하게 낮은 값을 보이지만, 애플리케이션 내부 컨텍스트는 여전히 SDK 계측 없이는 잡히지 않는다. 즉 baseline coverage는 eBPF, business context는 SDK라는 역할 분리가 실측 수치가 가리키는 방향이다.
- Beyla 계열 eBPF 계측은 CPU 오버헤드 2% 미만, 전통 APM 에이전트는 10~50%로 소개된다(2차 요약 수치, 재검증 필요).OpenTelemetry 공식 문서
- Kubernetes 환경 벤치마크에서 eBPF는 초당 약 280만 네트워크 이벤트를 CPU 2.4%로 처리했다는 보고가 있다.
- eBPF는 HTTP/gRPC/SQL 같은 프로토콜 메타데이터는 잘 잡지만 user ID·feature flag 같은 앱 내부 상태는 SDK 없이 못 본다.
- "오버헤드가 낮다"와 "카디널리티 비용이 낮다"는 다른 얘기다 — 비즈니스 태그를 붙이는 순간 저장·질의 비용은 다시 올라간다.
CPU 오버헤드 격차는 숫자로 얼마나 벌어지나?
격차는 자릿수 단위로 벌어지지만 조건이 다르다는 전제가 붙는다. eBPF 기반 자동 계측은 커널 훅에서 데이터를 요약해 유저 공간으로 넘기는 구조라 프로세스 내부에 코드를 심는 SDK보다 근본적으로 적은 컨텍스트 스위칭을 유발한다. Loft.sh 벤치마크를 인용한 2025년 리뷰는 40Gbps 라인레이트에서 eBPF 기반 네트워크 모니터링이 CPU 3~5%였던 반면, 동일 처리량에서 전통 패킷 캡처는 15~20%였다고 요약한다. 다만 이 수치는 원 논문의 하드웨어·버전이 본문 요약만으로 완전히 드러나지 않아 "2차 요약에서 확인된 값"이라는 단서를 달아야 한다.
두 방식이 보는 데이터 범위는 같은가?
같지 않다. eBPF는 커널이 관찰할 수 있는 흐름·프로토콜 단위 데이터에 강하고, SDK는 함수 호출부터 애플리케이션 상태까지 세밀하게 잡는다. eBPF 공식 문서도 구조적 장점으로 "커널 내부 데이터 수집 후 유저 공간 전송량 축소"를 들지만 특정 CPU·지연 수치는 제시하지 않는다. Cilium 계열 사례에서는 연결당 150개 이상의 네트워크 메트릭을 수집하면서도 눈에 띄는 성능 저하 없이 하루 약 4,500만 연결을 관측했다는 보고가 있는데, 이 역시 네트워크 계층 메트릭이지 애플리케이션 비즈니스 지표는 아니다.
카디널리티·저장 비용은 어느 쪽이 유리한가?
기본값은 eBPF가 유리하지만 조건부다. eBPF는 흐름·프로토콜 중심의 저카디널리티 데이터를 우선 수집하고 애플리케이션 태그는 선택적으로 붙이는 구조라, 별도 조치 없이도 카디널리티 폭증을 피하기 쉽다. 그러나 실무에서 필요한 건 대개 "user_id별 에러율" 같은 고카디널리티 비즈니스 태그이고, 이걸 붙이는 순간 eBPF든 SDK든 저장·질의 비용은 동일한 압력을 받는다. 이 부분은 확인된 수치보다는 구조적 설명에서 도출한 추론에 가깝다.
수치를 한 표로 정리하면 어떻게 보이나?
| 항목 | eBPF 무계측 | 전통 SDK/APM |
|---|---|---|
| CPU 오버헤드 | 2% 미만 (Beyla, 2차 요약) | 10~50% |
| K8s 네트워크 이벤트 | 초당 280만 건, CPU 2.4% | 별도 보고 없음 |
| 고처리량 캡처 대비 | 3~5% (40Gbps대) | 패킷캡처 기준 15~20% |
| 프로토콜 메타데이터(HTTP/gRPC/SQL) | 자동 수집 | 수동/자동 혼재 |
| user ID·feature flag 등 앱 컨텍스트 | 미수집(추가 계측 필요) | 수집 가능 |
SDK 계측에서 eBPF로 옮기면 실제로 드는 비용은 무엇인가?
전환 비용은 CPU가 아니라 커버리지 재구성 작업에서 발생한다. eBPF로 옮긴다고 SDK를 완전히 뗄 수는 없다 — 비즈니스 태그가 필요한 지점은 여전히 코드 계측이 필요하므로 두 파이프라인을 병행 운영하는 부담이 생긴다. 또한 2025년 논문 "Eliminating eBPF Tracing Overhead on Untraced Processes"가 지적하듯, eBPF 추적이 계측 대상이 아닌 프로세스에도 간접 오버헤드를 유발할 수 있다는 문제가 여전히 연구 중이다. 커널 버전 호환성 점검, 프로브 유지보수, 카디널리티 룰 설계까지 더하면 "CPU는 줄었지만 운영 표면은 늘었다"는 게 현실적인 전환 비용이다.
그래서 무엇을 기준으로 골라야 하는가?
정답은 워크로드 성격에 따라 갈린다. 레거시·다언어 서비스에서 재배포 없이 서비스맵과 기본 지연·에러율을 넓게 확보해야 한다면 eBPF 무계측 쪽이 CPU 비용 대비 커버리지 확장에 유리하다. 반대로 사용자 세그먼트·feature flag별 세밀한 비즈니스 지표가 목표라면 SDK 계측 없이는 애초에 데이터가 존재하지 않으므로 선택의 여지가 없다. 대부분의 관측성 파이프라인은 결국 eBPF로 baseline을 깔고 SDK로 고카디널리티 지점만 국소적으로 덧붙이는 혼합 구조로 수렴한다.
핵심 정리
- eBPF 무계측 수집은 CPU 오버헤드에서 전통 APM 대비 자릿수 단위로 낮다(2% 미만 vs 10~50%, 2차 요약 기준).
- 낮은 오버헤드는 "가시성 범위 축소"라는 대가를 동반한다 — 프로토콜 메타데이터는 자동, 앱 컨텍스트는 여전히 SDK 필요.
- 카디널리티 비용은 eBPF가 구조적으로 유리하지만, 비즈니스 태그를 붙이는 순간 이점은 줄어든다.
- 전환 비용은 CPU가 아니라 이중 파이프라인 유지·커널 호환성·프로브 관리에서 발생한다.
- 2026년 기준으로도 "완전 대체"보다는 "eBPF baseline + SDK 국소 계측"의 혼합 구조가 근거상 안전한 판단이다.
참고 자료
더 알아보기
관측성 파이프라인 설계: 메트릭·로그·트레이스 수집의 실제 — 이 주제의 종합 가이드