프로그래밍공부(Programming Study)/CS-운영체제(OS)

eBPF hook 종류 (kprobe, tracepoint, uprobe)

Chann._.y 2026. 4. 9.

728x90

앞 글에서 eBPF가 내부적으로 어떻게 동작하는지 봤다.

VM 위에서 실행되고
verifier가 검사하고
map으로 데이터 주고받는다

여기까지 보면 자연스럽게 이런 질문이 나온다.

“그래서 이걸 어디에 붙이는 건데?”

eBPF는 그냥 실행되는 게 아니라
어떤 이벤트에 붙어서 실행된다고 했었다.

이때 등장하는 개념이 hook이다.

hook은 “끼어드는 지점”이다

이걸 너무 어렵게 생각할 필요 없다.

특정 순간에 내가 만든 코드를 같이 실행시키는 지점

예를 들면 이런 느낌이다.

함수 호출
 ↓
(여기서 끼어듦)
 ↓
원래 함수 계속 실행

즉,

원래 흐름은 그대로 두고, 중간에 살짝 관찰한다

대표적으로 많이 쓰는 3가지

실무에서 거의 항상 나오는 게 이 3개다.

kprobe
tracepoint
uprobe

이 셋만 구분해도 80%는 해결된다.

kprobe — 커널 함수에 직접 붙는다

이건 가장 직관적이다.

커널 함수에 직접 hook을 건다

예

sys_execve
tcp_sendmsg
do_sys_open

느낌

커널 함수 시작
 ↓
kprobe 실행
 ↓
원래 함수 실행

장점

어디든 붙일 수 있다
자유도가 높다

단점

내부 구현에 의존적이다
커널 버전 바뀌면 깨질 수 있다

👉 즉,

강력하지만 안정적이지는 않다

tracepoint — 미리 정의된 이벤트

이건 kprobe보다 한 단계 “공식적인 방식”이다.

커널이 미리 만들어둔 관찰 지점

예

syscalls:sys_enter_execve
sched:sched_switch
net:net_dev_queue

느낌

이벤트 발생
 ↓
tracepoint
 ↓
eBPF 실행

장점

안정적이다
커널 버전 영향 적음

단점

정해진 것만 쓸 수 있다
자유도가 낮다

👉 정리하면

안정적인 대신, 선택지가 제한됨

uprobe — 사용자 프로그램에 붙는다

이건 방향이 완전히 다르다.

커널이 아니라 사용자 프로그램에 붙는다

예

malloc
free
read

느낌

사용자 함수 호출
 ↓
uprobe 실행
 ↓
원래 함수 실행

장점

애플리케이션 분석 가능
코드 수정 없이 추적 가능

단점

바이너리 의존적
심볼 필요

👉 이건 사실상

“프로그램 내부를 들여다보는 도구”

한 번에 정리하면

종류대상특징

kprobe	커널 함수	자유롭지만 불안정
tracepoint	커널 이벤트	안정적
uprobe	사용자 함수	앱 분석

실제로는 이렇게 생각하면 편하다

내부 깊게 보고 싶다 → kprobe
안정적으로 보고 싶다 → tracepoint
코드 레벨 보고 싶다 → uprobe

여기까지 이해하면 중요한 게 하나 보인다

이제 eBPF가 왜 강력한지 보인다.

커널 내부도 볼 수 있고
사용자 코드도 볼 수 있고
이벤트 기반으로 전부 추적 가능

👉 즉,

시스템 전체를 한 번에 관찰할 수 있다

다음 글로 이어지는 질문

이제 자연스럽게 이런 생각이 든다.

“그래서 실제로는 어떻게 분석하는데?”