12만 5,000건의 커널 취약점 데이터를 바탕으로 취약점을 누가, 언제 도입하는지와 ‘슈퍼 리뷰어’가 버그 발견 속도에 미치는 영향을 분석하고, 평균 버그 수명을 줄이기 위한 실무적 개선안을 제시한다.
pebblebed ventures기억하자: 비상시에는 먼저 패닉에 빠지고, 그다음에 절차를 따르자.
2026년 1월 23일•작성: Jenny Guanni Qu
커널 취약점 분석의 파트 2. 파트 1에서는 버그 수명과 VulnBERT를 다뤘다. 이 글은 사람의 측면을 파고든다. 누가 취약점을 도입하는지, 언제 도입하는지, 그리고 우리가 무엇을 할 수 있는지.
Part 1에서 나는 12만 5,000개의 커널 버그를 분석했고, 평균적으로 2.1년 동안 숨어 있으며 경쟁 상태(race condition)는 다른 버그 유형보다 2배 이상 오래 살아남는다는 사실을 발견했다. 나는 커밋 시점에 이를 잡아내기 위해 VulnBERT를 만들었다.
하지만 그 분석은 버그를 추상적인 데이터 포인트로만 취급했다. 이번에는 다른 질문을 던졌다: 버그가 있는 코드를 쓰는 사람은 누구인가? 그들은 언제 그것을 쓰는가? 그리고 누구는 다른 누구보다도 더 빨리 버그를 잡아내는 슈퍼 리뷰어인가?
답은 놀라웠다. 주말 커밋은 실제로 취약점을 도입할 가능성이 더 낮지만, 수정까지는 45% 더 오래 걸린다. Intel이 가장 많은 버그를 기여하는데, 그 이유는 가장 많은 코드를 기여하기 때문이다. 그리고 117명의 “슈퍼 리뷰어”가 다른 모든 사람보다 거의 2배 빠르게 버그를 잡아낸다.
이 결과는 평균 버그 수명을 35% 줄일 수 있는 구체적인 프로세스 개선 방향을 가리킨다.
| 한눈에 보는 핵심 결과 | |
|---|---|
| 117 | 평균보다 47% 더 빠르게 버그를 잡는 슈퍼 리뷰어 |
| 0.88 years | 자기 수정 수명(타인 수정은 2.59 years) |
| -8% | 주말 커밋은 취약할 가능성이 더 낮음 |
| +45% | 하지만 주말 버그는 수정에 더 오래 걸림(리뷰 커버리지) |
| 5.0 years | 경쟁 상태의 평균 수명(데드락의 2배) |
| ~35% | 프로세스 개선으로 가능한 추정 감소폭 |
모든 버그 수정자가 같은 것은 아니다. 최소 50개 이상의 버그를 수정한 사람들을 순위로 세워 보니, 명확한 패턴이 드러났다. 어떤 사람들은 다른 사람들보다 일관되게 더 빨리 버그를 찾아낸다.
나는 슈퍼 리뷰어를 다음 조건을 만족하는 사람으로 정의했다:
117명이 이 기준을 충족한다. 그리고 영향은 극적이다:
| 지표 | 값 |
|---|---|
| 전역 평균 버그 수명 | 2.1 years |
| 슈퍼 리뷰어 평균 | 1.1 years |
| 차이 | 47% 더 빠름 |
상위 20 버그 수정자. 초록 = 슈퍼 리뷰어(100+ 수정, 평균보다 20% 빠름). 산점도는 규모 대 속도를 보여주며, 슈퍼 리뷰어는 오른쪽 아래(높은 물량, 낮은 수명)에 군집한다.
상위 10명의 슈퍼 리뷰어:
| 순위 | 이름 | 수정한 버그 수 | 평균 수명 |
|---|---|---|---|
| 1 | Arnd Bergmann | 2,786 | 1.2 years |
| 2 | Dan Carpenter | 2,707 | 1.7 years |
| 3 | Chris Wilson | 1,242 | 0.5 years |
| 4 | Geert Uytterhoeven | 1,089 | 1.5 years |
| 5 | Colin Ian King | 787 | 1.5 years |
| 6 | Takashi Iwai | 762 | 1.3 years |
| 7 | Johannes Berg | 603 | 1.4 years |
| 8 | Jakub Kicinski | 546 | 1.5 years |
| 9 | Nathan Chancellor | 544 | 1.5 years |
| 10 | Ville Syrjälä | 522 | 0.8 years |
Chris Wilson은 특별하다: 1,242건을 평균 0.5년으로 수정한다. 전역 평균보다 4배 빠르게 버그를 찾아내는 셈이다. Ville Syrjälä도 평균 0.8년으로 비슷하다.
Dan Carpenter에 대한 메모: Dan은 2,707건의 버그를 수정했을 뿐 아니라, 이 전체 분석을 가능하게 만든 Fixes: 태그 관례를 만들었다. 커널 개발자가 버그를 수정할 때, 수정 커밋을 도입 커밋에 연결하기 위해 Fixes: abc123def ("original commit subject") 같은 줄을 추가한다. 이 단순한 관례는 이제 표준 관행이 되었고, 우리가 분석하는 12만 5,000쌍 데이터셋을 만들어냈다. Dan은 거의 누구보다 많은 버그를 고쳤을 뿐 아니라, 우리가 이를 추적할 수 있게 해주는 시스템을 만들었다.
그들은 무엇이 다른가? 수정 패턴을 보면:
슈퍼 리뷰어(초록)는 더 다양한 저자의 버그를 수정하고, drivers/gpu에 집중하며, 지난 10년 동안 커버리지가 15%에서 30%로 증가했다.
커버리지 추세는 고무적이다: 2010년에는 슈퍼 리뷰어가 약 15%의 버그를 수정했다. 2020-2024년에는 약 30%로 상승했다. 슈퍼 리뷰어가 많을수록 전체 커널의 버그 발견 속도는 더 빨라진다.
다음 결과는 코드 소유권을 바라보는 방식을 바꿔야 한다:
| 수정 유형 | 평균 수명 |
|---|---|
| 자기 수정(같은 저자) | 0.88 years |
| 다른 사람이 수정 | 2.59 years |
원 작성자가 고친 버그는 3배 더 빨리 발견된다.
왼쪽 아래: 자기 수정(초록)은 교차 수정(빨강)보다 수명이 극적으로 짧다. 오른쪽 아래: 기업 간 상위 교차 수정 관계.
자기 수정 비율은 29.7%로, 거의 3분의 1의 버그가 결국 도입자에 의해 수정된다. 이 개발자들은 조직 내 지식을 갖고 있다. 코드의 불변 조건을 이해하고, 뭔가 이상하다고 느낄 때 알아차리며, 자신의 서브시스템을 계속 지켜본다.
시사점: 코드 소유권은 중요하다. 개발자들이 자신의 코드를 장기적으로 소유하고 유지하도록 장려한다면(한 번 던져놓고 끝내는 기여가 아니라), 버그 수명을 크게 줄일 수 있다.
누가 버그를 도입하는지 이야기하기 전에, 애초에 누가 커널을 쓰는지부터 보자. 나는 140만 개의 커밋을 분석해 기업 지형을 매핑했다.
Linux 커널의 기업 생태계. Intel이 8.4%의 커밋으로 지배적이지만, 독립 기여자가 여전히 전체 개발의 50%를 차지한다.
수치는 인상적이다:
| 조직 | 커밋 수 | 비중 |
|---|---|---|
| Independent/Personal | 706,224 | 50.1% |
| Intel | 118,073 | 8.4% |
| Red Hat | 71,891 | 5.1% |
| Linux Foundation | 49,696 | 3.5% |
| Linaro | 43,192 | 3.1% |
| SUSE | 42,018 | 3.0% |
| AMD | 41,250 | 2.9% |
| 39,118 | 2.8% |
커널의 절반은 여전히 개인이 만든다: gmail.com, 개인 도메인, 대학 이메일을 쓰는 사람들이다. “기업이 장악했다”는 내러티브는 과장되어 있다. 기업들의 기여가 큰 것은 사실이지만, 커널은 여전히 진정한 협업 프로젝트다.
기업 비중은 2005년 약 25%에서 오늘날 약 55%로 늘었지만, 독립 기여자는 여전히 엄청나게 중요하다.
추세는 실제다. 2005년 이후 기업 기여 비중은 커밋 점유율 기준으로 2배가 되었다. 하지만 이는 자원봉사자를 대체해서가 아니라, 커널 개발의 _총량_이 늘어난 것을 반영한다. 독립 기여자 수는 비교적 안정적으로 유지되어 왔다.
Intel의 지배력은 2016년경 11%로 정점을 찍었고, 9-10% 수준에서 안정화되었다. AMD의 점유율은 2020년 이후 극적으로 증가했다.
Intel의 여정은 흥미롭다. i915 GPU 드라이버 개발에 힘입어 2016년경 점유율 11%로 정점을 찍었다. 이후 9-10% 수준에서 안정화된 반면, AMD는 거의 0에 가까운 수준에서 약 5%까지 성장했는데, 이는 AMD의 CPU·GPU 부활을 반영한다.
작성자 이메일을 조직에 매핑했을 때:
| 조직 | 도입한 버그 수 |
|---|---|
| Intel | 14,000 |
| Independent (gmail.com) | 10,000 |
| Red Hat | 7,000 |
| kernel.org maintainers | 6,000 |
| Linaro | 5,500 |
| 5,000 | |
| AMD | 4,000 |
Intel의 우세는 코드 품질이 아니라 기여 물량을 반영한다. 그들은 거대한 드라이버 서브시스템(i915 GPU, 네트워킹, 플랫폼 코드)을 유지한다. 결함률이 같아도 코드가 많으면 버그도 많다.
사실 Intel의 버그 비율은 대략 커밋 점유율에 비례한다. 그들은 커밋의 8.4%를 기여하고 버그의 약 11%를 차지하는데, 약간 높긴 하지만 극적이지는 않다. 이 차이는 단순한 패치보다 드라이버 코드가 더 복잡하다는 점을 반영할 수 있다.
기업 간 수정 패턴은 많은 것을 말해준다:
| 관계 | 수정 수 |
|---|---|
| Mellanox → NVIDIA | 600+ |
| Independent → kernel.org | 500+ |
| Intel → Red Hat | 420+ |
| Red Hat → Google | 400+ |
Mellanox → NVIDIA는 타당하다. NVIDIA가 Mellanox를 인수했기 때문에 코드베이스를 이어받았다. Independent → kernel.org는 유지관리자가 커뮤니티 기여를 정리하는 모습을 보여준다. Intel ↔ Red Hat 관계는 공유 인프라(가상화, 네트워킹)에서의 협업을 반영한다.
나는 야간 커밋이 더 버그가 많을 것이라 예상했다. 데이터는 더 미묘한 이야기를 들려줬다.
시간대별 취약점 도입 ‘비율’. 주말 커밋은 실제로 취약할 가능성이 더 낮다. 하지만 취약점이 생기면 그 버그를 찾는 데 더 오래 걸린다.
직관에 반하는 결과: 주말 커밋은 취약점 도입률이 더 낮다:
| 기간 | 취약점 비율 |
|---|---|
| 평일 평균 | 8.94% |
| 주말 평균 | 8.25% |
| 차이 | -8% 더 적은 버그 |
하지만 주말 이야기는 더 복잡하다. 요일별 전체 분해는 다음과 같다:
| 요일 | 취약점 비율 |
|---|---|
| Monday | 9.14% |
| Tuesday | 8.96% |
| Wednesday | 8.37% |
| Thursday | 9.11% |
| Friday | 9.15% |
| Saturday | 9.55% (최고) |
| Sunday | 6.99% (최저) |
Saturday가 사실상 가장 위험한 날이고, Sunday는 놀라울 정도로 안전하다. 주말 평균이 좋아 보이는 것은 Sunday의 낮은 비율(6.99%)이 Saturday의 높은 비율(9.55%)을 끌어내리기 때문이다.
왜 이런 차이가 날까? Saturday는 개발자들이 주말이 본격적으로 시작되기 전에 무언가를 끝내려고 서두르는 주간 마감 푸시를 포착할 수 있다. 반대로 Sunday 기여자들은 마감 압박 없이 의도적이고 집중된 작업을 한다. 일요일에 코딩하는 것을 선택하는 것이지, 금요일 마감에 쫓기는 것이 아니다.
하지만 함정이 있다. 주말 커밋이 실제로 버그를 도입했을 때, 그 버그는 고치는 데 훨씬 더 오래 걸린다:
| 기간 | 버그 수명 |
|---|---|
| Monday-Friday | 1.97 years |
| Saturday-Sunday | 2.87 years |
| 차이 | +45% 더 김 |
주말 커밋은 취약점을 도입할 가능성이 8% 낮지만, 도입된 버그는 수정에 45% 더 오래 걸린다.
무슨 일이 벌어지고 있나? 두 가지(실제로는 세 가지) 효과:
최고 위험 구간은 주말이 아니라 UTC 오전 5시다. 이때 취약점 비율이 32%로 치솟는데, UTC 오전 11시의 최저치 5.1%보다 6배 이상이다. 이는 미주 지역의 심야 코딩 또는 유럽의 매우 이른 아침과 대응된다.
왼쪽 위: 시간대별 패턴에서 심야/이른 아침 커밋이 가장 높은 취약점 비율을 보인다. 월별 패턴은 4월 머지 윈도우 피크를 보여준다.
월별 패턴도 흥미롭다: 4월이 가장 높은 취약점 비율(9.64%)을 보인다. 이는 Linux 커널 머지 윈도우와 상관된다. 머지 윈도우가 열리면 큰 기능 브랜치들이 들어오고, 윈도우가 닫히기 전에 코드를 머지하려는 서두름이 더 많은 버그로 이어진다.
파트 1의 이 결과는 전체 시각화를 보면 더 두드러진다:
오른쪽 패널: 평균 수명으로 정렬한 버그 유형. 경쟁 상태(5.0 years)는 데드락(2.4 years)보다 발견하기가 압도적으로 어렵다.
| 버그 유형 | 개수 | 평균 수명 |
|---|---|---|
| race-condition | 1,194 | 5.0 years |
| info-leak | 71 | 4.5 years |
| integer-overflow | 299 | 4.2 years |
| use-after-free | 2,978 | 3.3 years |
| memory-leak | 2,860 | 3.2 years |
| null-deref | 4,969 | 2.5 years |
| deadlock | 1,691 | 2.4 years |
경쟁 상태는 데드락보다 2배 오래 살아남는다. 데드락은 결국 시스템을 멈추게 해서 누군가 알아차리기 때문일 수 있다. 경쟁 상태는 상태를 조용히 오염시켜 실제 버그와 먼 곳에서 실패를 유발할 수 있다.
이는 ML 접근을 뒷받침한다. 전통적인 퍼저는 비결정적인 경쟁 상태를 다루기 어렵다. 코드 구조로 학습한 모델은 실행되기 전부터 의심스러운 패턴을 표시할 수 있다.
또 다른 주목점: "unknown"이 개수(68,000 버그)를 지배한다. 우리의 버그 유형 분류기가 신호를 놓치고 있다. 이 분류를 개선하면 더 정밀한 표적 탐지가 가능해질 수 있다.
어떤 서브시스템은 활발한 유지관리자가 있는 번화한 도시다. 다른 서브시스템은 유령 도시다:
왼쪽: 개수 기준 상위 서브시스템. 오른쪽: 평균 수명 기준 서브시스템(n≥100). 빨강 = 더 오래 숨음, 초록 = 더 빨리 발견.
| 서브시스템 | 평균 수명 | 표본 크기 |
|---|---|---|
| drivers/can | 4.2 years | 447 |
| networking/sctp | 4.0 years | 279 |
| fs/ext4 | 3.7 years | 405 |
| networking/ipv4 | 3.4 years | 1,687 |
| usb | 3.3 years | 2,519 |
CAN 버스 드라이버가 최상단이다. 이들은 자동차 및 산업 시스템에서 사용된다. 유지관리자가 적게 지켜보는 중요한 인프라다. SCTP는 비슷한 역학을 가진 틈새 네트워킹 프로토콜이다.
반면 gpu/i915(Intel 그래픽)는 평균 약 1.4년 안에 버그가 발견된다. 전용 퍼징 인프라가 있고 Chris Wilson, Ville Syrjälä 같은 활발한 슈퍼 리뷰어가 있다.
시사점: 관심이 낮은 서브시스템을 우선적으로 스캔해야 한다. 4년 동안 방치되는 drivers/can의 취약점이, 6개월 안에 잡히는 gpu/i915의 취약점보다 더 위험하다.
서브시스템마다 버그 패턴이 다르다. 특화 모델을 학습해야 할까?
왼쪽 위: 버그 유형 분포는 서브시스템마다 다르다. 오른쪽 위: 고유성 점수(전역 분포와의 발산). 높을수록 더 다름 = 특화 모델의 이점을 볼 수 있음.
| 서브시스템 | 고유성 | 권장 |
|---|---|---|
| arch/arm64 | 0.46 | 특화 모델 |
| networking | 0.37 | 특화 모델 |
| tools | 0.33 | 특화 모델 |
| gpu/i915 | 0.27 | 일반 모델로 충분 |
| drivers/net | 0.20 | 일반 모델로 충분 |
arch/arm64와 networking이 가장 독특한 버그 패턴을 가진다. 버그 유형 분포가 전역 평균에서 크게 벗어나므로, 네트워킹 전용 데이터로 학습한 특화 VulnBERT가 네트워킹 커밋에서는 일반 모델보다 더 나을 수 있음을 시사한다.
왼쪽 아래 패널은 서브시스템별 수명 분산을 보여준다. 네트워킹은 평균 수명도 높고 분산도 높아 예측이 어렵다. 특화 모델이 도움이 될 수 있다.
기대 개선: 특화 서브시스템에서 리콜 5-15% 증가.
문장 변환기(sentence transformer)로 10,000개의 커밋 메시지를 임베딩하고 UMAP으로 시각화했다:
비슷한 일을 하는 커밋은 함께 군집한다. 오른쪽 위: 수명으로 색칠. 어떤 의미 영역은 체계적으로 더 오래 숨는 버그(빨강)를 가진다.
모델은 별도로 알려주지 않아도, 특정 종류의 커밋이 더 오래 숨는 버그를 시사한다는 것을 학습했다:
| 클러스터 | 평균 수명 | 예시 커밋 |
|---|---|---|
| Cluster 2 (최장) | 2.4 years | "afs: Handle lock rpc ops failing...", "NFSv4: Fix free of uninitialized..." |
| Cluster 8 (최단) | 1.2 years | "drm/i915/gt: Cancel the preemption timeout...", "drm/radeon: Fix spurious unplug..." |
"race", "refcount", "use-after-free"를 언급하는 커밋은 함께 군집하고 수명이 더 길다. "typo", "warning", "build"에 관한 커밋은 별도로 군집하며 빨리 수정된다.
이는 커밋 메시지 내용이 예측적이라는 뜻이다. “이건 경쟁 상태 수정처럼 보인다”를 이해하는 모델은 원래 버그가 아마도 찾기 어려웠을 것이라고 추론할 수 있다.
╔══════════════════════════════════════════════════════════════════════════════╗
║ KERNEL VULNERABILITY ANALYSIS: KEY RECOMMENDATIONS ║
╚══════════════════════════════════════════════════════════════════════════════╝
┌──────────────────────────────────────────────────────────────────────────────┐
│ 1. SUPER-REVIEWER PROGRAM │
├──────────────────────────────────────────────────────────────────────────────┤
│ FINDING: 117 super-reviewers catch bugs 47% faster than average. │
│ ACTION: Route high-risk commits to super-reviewers first. │
│ EXPECTED IMPACT: 20-30% reduction in bug lifetime for reviewed commits. │
└──────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│ 2. COMMIT MESSAGE QUALITY GATE │
├──────────────────────────────────────────────────────────────────────────────┤
│ FINDING: Sparse commits (<30 chars) have ~20% longer-lived bugs. │
│ ACTION: Flag commits with quality_score < 40 for mandatory extra review. │
│ EXPECTED IMPACT: Catch 10-15% more bugs before merge. │
└──────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│ 3. SUBSYSTEM-SPECIFIC MODELS │
├──────────────────────────────────────────────────────────────────────────────┤
│ FINDING: Subsystems have distinct bug patterns (divergence up to 0.46). │
│ ACTION: Train specialized VulnBERT for: networking, drivers │
│ EXPECTED IMPACT: 5-15% recall improvement in specialized subsystems. │
└──────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│ 4. TEMPORAL CI/CD TUNING │
├──────────────────────────────────────────────────────────────────────────────┤
│ FINDING: Weekend commits have +45% longer lifetimes. │
│ ACTION: Dynamic thresholds - stricter during merge windows and weekends. │
│ EXPECTED IMPACT: 15-20% reduction in escaped bugs during high-risk periods. │
└──────────────────────────────────────────────────────────────────────────────┘
╔══════════════════════════════════════════════════════════════════════════════╗
║ COMBINED EXPECTED IMPACT ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ Current average bug lifetime: 2.1 years ║
║ With all recommendations: ~1.4 years (estimated 35% reduction) ║
╚══════════════════════════════════════════════════════════════════════════════╝
모든 결과를 결합하면:
| 권고 | 결과 | 기대 효과 |
|---|---|---|
| 슈퍼 리뷰어 라우팅 | 117명의 슈퍼 리뷰어가 평균보다 47% 더 빠르게 버그를 잡음 | 라우팅된 커밋에서 20-30% 감소 |
| 커밋 품질 게이트 | 빈약한 커밋(<30 chars)은 -20% 더 오래 숨는 버그를 가짐 | 머지 전 10-15% 더 많은 버그 포착 |
| 서브시스템 특화 모델 | 고유성 최대 0.46 | 리콜 5-15% 개선 |
| 시간대 기반 CI 튜닝 | 주말 커밋은 +45% 더 긴 수명 | 고위험 기간 동안 15-20% 감소 |
종합 추정: 평균 버그 수명 2.1 years → ~1.4 years (35% 감소).
커널 유지관리자를 위해:
보안 팀을 위해:
연구자를 위해:
이 분석은 git 커밋 히스토리에 기반하지만, 커널 개발은 실제로 더 오래된 시스템인 이메일에서 이루어진다.
Linux Kernel Mailing List(LKML)는 하루에 대략 1,400개의 메시지를 받는다. 패치, 리뷰, 논쟁, 그리고 플레임 워까지. 개발자들은 이메일로 패치를 제출하고(종종 git send-email을 사용), 유지관리자는 인라인으로 리뷰하며, 최종적으로 수락된 버전만 git에 커밋된다. 리뷰 논의, 여러 번의 패치 반복, 거절된 제출물은 모두 lore.kernel.org의 메일링 리스트 아카이브에만 존재한다.
즉, 우리의 데이터셋은 프로세스가 아니라 결과를 포착한다:
| 우리가 보는 것 | 우리가 보지 못하는 것 |
|---|---|
| 최종 커밋된 패치 | 거절된 패치 시도 |
| 버그 수정 커밋 | 문제를 머지 전에 잡아낸 리뷰 논의 |
Fixes: 태그 관계 | 수락 전 여러 번의 반복 |
| author/committer 타임스탬프 | 이메일 리뷰에 소요된 시간 |
이 분석에 대한 함의:
메일링 리스트 워크플로는 GitHub 스타일 PR에 비해 낡았다고 비판받기도 하지만, 놀라울 정도로 잘 확장된다. 커널은 20년 이상에 걸쳐 수천 명의 기여자로부터 140만 건 이상의 커밋을 받아들였다. 연구자에게 lore.kernel.org는 전체 개발 역사를 검색 가능한 형태로 제공하지만, 이메일 스레드를 git 커밋과 상관시키는 일은 여전히 어렵다.
향후 연구에서는 메일링 리스트 아카이브를 직접 마이닝하여 리뷰 강도와 버그 비율에 대한 영향을 측정할 수 있을 것이다.
메일링 리스트 워크플로에 대한 유익한 논의를 제공해준 Nikolai Kondrashov(Red Hat CKI)에게 감사한다.
모든 분석 스크립트와 시각화는 다음에서 확인할 수 있다:
Dataset:huggingface.co/datasets/pebblebed/kernel-vuln-dataset
Repository:github.com/quguanni/kernel-archaeology
파트 1: Kernel bugs hide for 2 years on average. Some hide for 20.
© 2026 Pebblebed · San Francisco, CA