LLM이 커널 버그를 찾아내면서 수정 커밋이 2배로 늘었다
Linux bugs fixed per release over time: >2× rise since 2026-04
Linux 7.2 커널은 16,418개의 비병합 커밋과 2,652명의 개발자가 참여한 역사상 두 번째로 바쁜 릴리스였다. 주목할 점은 4,830개의 Fixes 태그 커밋으로, LLM이 버그를 찾아내면서 수정 속도가 급증했다는 것이다. Sashiko 리뷰 시스템이 보고한 버그도 252건에 달했고, LLM 지원 커밋은 1,111건으로 집계됐지만 실제로는 훨씬 많을 것으로 추정된다. 첫 기여 개발자도 613명으로 역대 최다를 기록했다.
LLM의 도움으로 개발된 커밋을 정확히 추적하는 것은 불가능할지 모르지만, 때때로 커널 커뮤니티가 정말로 시도할 만큼 신경 쓰지 않는 것처럼 느껴진다.
HN 토론
101- ogoffart
내 프로젝트에서도 같은 걸 느꼈습니다.
에이전트는 버그를 고치는 데 정말 큰 도움이 됩니다. 그냥 에이전트에게 버그 리포트를 가리키기만 하면 되죠. 재현, 디버깅, 수정까지 다 해줍니다. 우리는 "그저" 리뷰만 하면 됩니다. (가끔은 더 자세한 내용을 물어보고, 다른 접근 방식을 선호한다고 말하기도 하고요.) 덕분에 버그 수정이 훨씬 빠르고 자동화되었습니다.
그와 동시에, 우리 라이브러리로 들어오는 버그 리포트는 줄어드는 것 같습니다.
사용자들이 그냥 자기 에이전트로 코딩을 하고, 에이전트는 버그를 보고하지 않고 어떻게든 우회해서 처리해버리는 것 같아요.
그래서 전체적으로 열린 버그 수는 줄고 있습니다. 왠지 기분은 좋네요.
반면에, 다른 사람들의 에이전트가 만든 PR이 많이 들어오는데, 그냥 거대한 코드 덩어리를 던져버리면 좀 부담스러울 수 있습니다. 그걸 쉽게 리뷰할 수가 없거든요.
- zdw
Greg KH가 LLM이 만들어내는 것들의 홍수에 관한 영상을 올렸습니다: https://www.youtube.com/watch?v=NnV_cWeoo5Q , HN 스레드: https://news.ycombinator.com/item?id=49929391
여기서 그는 이런 것들 상당수에 어떻게 대응하고 반박하는지, 그리고 (버그 리포트만이 아니라) 패치를 달라고 요청하는 방식을 다룹니다
- 05kqhg
헤드라인은 "7.2 커널의 개발 통계"이고, 마지막 문단은 LLM에 상당히 비판적인데, 이는 "릴리스별로 시간에 따라 수정된 Linux 버그: 2026-04 이후 2배 이상 증가"라는 편집된 헤드라인과 대조됩니다. 이 헤드라인은 일종의 Mythos 버그 발견을 암시하는 것처럼 보이죠.
마지막 문단에서:
"Linux 커널은 연구나 실험이 아니라 프로덕션 사용을 목표로 합니다. 하지만 현재 커널의 개발 프로세스와 커뮤니티에서 거대한 실험이 진행되고 있습니다."
- jayd16
이런 종류의 짧은 언급들의 큰 문제는 통제군이 없다는 점입니다. 역사적 수치는 유효하지 않은데, 자금이 넉넉한 주체의 인센티브가 바뀌었기 때문입니다. LLM 없이 패치 수를 끌어올리는, 똑같이 자금이 넉넉한 추진이 있어야만 그 영향을 정량적으로 측정할 수 있을 겁니다.
- AmazingEveryDay
기계가 생성한 amdgpu 헤더 파일이 도대체 얼마나 거대해질 수 있는 건지, 이제는 제한을 좀 둘 때가 된 것 같습니다.
- dash2
그러면 도입된 버그에 대한 생존 분석을 vibecoding하는 것도 가치가 있어 보이네요. 하지만 생존 분석이라고 하기엔 좀 그런 게, 버그가 발견되는 사건이 일어나기 전까지는 그 버그가 존재하는지조차 모르니까요.... 이거에 대한 공개 데이터셋이 있나요? URL이라도요?
- tosti
7.3으로 업그레이드하시는 분들께 알려드립니다. 저는 방금 slackware 박스를 7.3-rc7에서 7.2.10으로 다운그레이드했는데, /dev/input/events가 없어졌더군요. 그 결과 키보드와 마우스가 콘솔에서만 동작했습니다.
결과는 사람마다 다를 수 있습니다
- cwillu
제목을 편집하지 말아 주세요.
(수정: 제목이 고쳐졌습니다)