eBPF를 써 본 사람이라면 누구나 겪는 일이 있습니다. Verifier가 프로그램을 거부하는데, 에러 메시지는 아무 잘못도 없어 보이는 줄을 가리킵니다. 2026년 7월에 나온 논문 하나가 이 답답함을 처음으로 수치화했습니다. 저자들은 Stack Overflow, GitHub 이슈, 수정 커밋, 커널 셀프테스트에서 후보 936건을 모아 커널 6.15.11 + clang 18이라는 고정 툴체인에서 재현했고, 실제로 거부된 235건을 분석했습니다. 결론은 이렇습니다 — 거부의 47%는 EINVAL 하나만 돌려주고, 가장 흔한 에러 문자열 하나가 서로 다른 근본 원인 9가지에 대응하며, 원인 12종 중 10종이 eBPF 고유 지식을 요구합니다. 게다가 거부의 19%는 소스가 옳은데도 컴파일러/환경/verifier 때문에 튕깁니다. 핵심 진단은 에러가 검증이 멈춘 지점을 가리킬 뿐, 프로그램이 verifier가 요구한 증명을 잃은 지점은 가리키지 않는다는 것입니다. 이 글은 그 격차의 구조, 저자들이 내놓은 도구 bpfix가 무엇을 복원하는지, LLM 수리 벤치마크 75문제의 결과, 그리고 이 수치를 어디까지 믿어야 하는지를 정리합니다.