요약
리눅스 7.2 커널은 참여 개발자와 버그 수정이 크게 늘었고, 그 배경에는 LLM이 있습니다.
LWN이 리누스 토르발스가 8월 17일 내놓은 7.2 커널의 개발 통계를 정리했습니다. 병합 커밋을 뺀 커밋은 16,418개로 역대 두 번째였고, 코드는 60만 줄 가까이 늘었습니다.
왜 중요한가
- 버그 찾기에 LLM(대규모 언어 모델)을 쓰는 흐름이 커널 수정 통계에 숫자로 드러나기 시작했습니다.
- 자기 변경을 제대로 이해하지 못한 채 패치를 내는 사람이 늘 수 있다는 우려가 나왔습니다.
- 그러면 아무도 제대로 이해한 적 없는 코드를 나중에 떠안게 될 수 있다고 원문은 경고했습니다.
핵심 내용
- Fixes 태그(이전 커밋의 버그를 고쳤다고 밝히는 표시)가 붙은 커밋은 4,830개로, 오래 평평하다가 최근 급증했습니다.
- AI 도움을 밝히는 Assisted-by 태그는 1,111개로 7.1의 301개보다 크게 늘었습니다.
- 태그를 빼는 개발자가 많고 태그를 지우는 메인테이너도 있어, 실제 AI 사용은 훨씬 많을 것으로 봤습니다.
- 참여 개발자는 2,652명, 처음 기여한 개발자는 613명으로 둘 다 역대 최다였습니다.
- 바뀐 줄 수로는 AMD가 22.4%로 1위였는데, 주로 자동 생성된 amdgpu 헤더 파일 때문이었습니다.
HN 반응
- 에이전트 덕에 버그 수정은 빨라졌지만, 에이전트가 버그를 보고하지 않고 우회해 버린다는 경험담이 이어졌습니다.
- 원문 결론은 오히려 LLM에 비판적이라는 지적과, 비교할 대조군이 없어 LLM의 효과를 단정할 수 없다는 반론이 나왔습니다.
저희 프로젝트에서도 똑같은 걸 느꼈습니다.
에이전트가 버그 수정에 큰 도움이 됩니다. 버그 리포트를 에이전트에게 가리키기만 하면 재현, 디버깅, 수정까지 알아서 합니다. 저희는 "그냥" 리뷰만 하면 됩니다. (가끔 자세한 내용을 더 물어보거나 다른 방식이 좋겠다고 말해 주기도 합니다.) 덕분에 버그 수정이 훨씬 빠르고 자동화되었습니다.
그와 동시에 저희 라이브러리에 들어오는 버그 리포트는 줄어든 것 같습니다. 사용자들이 에이전트로 코딩을 하는데, 에이전트는 버그를 신고하지 않고 어떻게든 우회해서 해결해 버리는 것 같습니다.
그래서 전체적으로 열려 있는 버그 수가 줄고 있습니다. 어쩐지 기분이 좋습니다.
반면 다른 사람들의 에이전트가 만든 PR이 많이 들어오는데, 거대한 코드 덩어리를 그냥 던져 놓은 경우에는 부담스럽습니다. 그런 건 쉽게 리뷰할 수가 없습니다.
네, 저도 확실히 느꼈어요. 제가 하는 프로젝트에서 Opus 5.5가 Smithay에서 버그 하나, Winit에서 또 하나를 찾아냈거든요. 저한테 알려주긴 했는데, 선호하는 해결책은 그냥 로컬에서 우회하는 거였어요. 하긴 에이전트가 알아서 버그를 자동으로 신고하고 다니는 건 우리도 원하지 않죠...
저는 큰 오픈소스 프로젝트를 운영하진 않지만, AI가 만든 PR을 다룰 때는 제 AI에게 같은 걸 구현시킨 다음, 그 PR을 보고 놓친 게 없는지 확인시키는 방식이 제일 좋을 것 같아요. 그러면 적어도 유능한 모델을 쓰고 있다는 건 알 수 있고, 남이 짠 코드를 맹목적으로 받아들일 위험도 줄어듭니다. (물론 시간과 의지가 있으면 코드를 직접 리뷰해야겠지만, 늘 그럴 수 있는 건 아니니까요.)
버그를 우회하는 기본 동작은 좋은 거예요. LLM 이전에도 다들 그렇게 했으니까요. 그래도 좋은 관행은 버그를 신고하는 겁니다. 에이전트에게 찾아낸 버그를 요약에 포함해서 알려 달라고 지시만 추가해 두면, 직접 버그를 확인하고 업스트림에 제대로 신고할 수 있어요.
저는 보통 버그를 신고하고, 우회 코드 옆 주석에 그 링크를 남겨 둡니다.
요즘 Claude는 정말 기막힌 미친 우회책을 내놓더라고요. 예를 들어 API가 노출하지 않는 훅이 갖고 싶다는 이유로(아니면 잠깐 훑어봤을 때 못 찾았다는 이유로) 서브프로세스를 띄워서 stdout/stderr를 붙잡고 info 로그를 문자열 파싱하는 식이에요.
에이전트가 이어 붙여 만드는 것들에서는 의존성의 semver 신뢰성이라는 게 이제 아예 없다고 봐야 할 겁니다. 더 많은 정보나 제어권이 필요하다 싶으면 어떤 방법이든 다 건드려 볼 테니까요.
너무 깨지기 쉽네요.
에이전트가 사람처럼 버그를 만들어 넣을 수도 있죠(지금 개발이 아주 바쁘게 돌아가는 rsync를 보세요). 아마 우리도 LLM도 그런 버그를 쉽게 알아채지 못할 거예요. 재미있는 시절이네요.
그래서요? 사람도 버그를 만들어요. 검증 장치를 구성하기도 귀찮아하는 사람이면 테스트를 전부 손으로 하는 건 더 귀찮아할 겁니다.
rsync는 자금도 인력도 한참 부족합니다. 지금 개발자는 다들 그만두는 바람에 어쩔 수 없이 떠맡은 거고요!
Greg KH가 LLM이 쏟아내는 결과물에 대한 영상을 올렸습니다: https://www.youtube.com/watch?v=NnV_cWeoo5Q , HN 스레드: https://news.ycombinator.com/item?id=49929391
이 영상에서 그가 이런 것들에 어떻게 대응하고 맞서는지, 그리고 버그 리포트만이 아니라 패치를 달라고 요구하는 이야기도 다룹니다.
그가 "맞서는" 이유는 실시간으로 도태되고 있기 때문입니다.
아, 걱정 마세요. 당신이 훨씬 먼저 도태될 테니까요.
그렇지 않습니다. 제가 C++로 다시 쓴 리눅스는 이미 프로덕션에 쓸 수 있는 수준이라, 이론상 이제 리눅스 커널 개발자들에게 의존할 필요가 없습니다. 몇 달 안에 이게 표준이 될 거라고 봅니다.
풍자겠죠, 이거.
네, 리눅스 커널은 C++로 다시 쓰는 게 절실했죠.
에이, 그건 아무것도 아니죠. 저는 리눅스 커널을 C++로 다시 썼는데 템플릿 메타프로그래밍만 썼어요.
그럼 이제 리눅스 커널은 FreePascal로 다시 써야겠네요.
제 B 언어 포팅은 순조롭게 진행 중이에요. C는 실수였어요. /s
저도 커널을 C++로 다시 쓸 수 있어요. Makefile을 고쳐서 .c 파일을 C++로 취급하게 하면 됩니다. 거의 되긴 할 거예요 :)
제목은 "Development statistics for the 7.2 kernel"이고 마지막 문단은 LLM에 매우 비판적인데, 편집된 제목 "Linux bugs fixed per release over time: >2× rise since 2026-04"는 마치 Mythos가 버그를 찾아냈다는 식으로 읽힙니다.
마지막 문단은 이렇습니다.
"리눅스 커널은 연구나 실험이 아니라 프로덕션 용도를 겨냥합니다. 그런데 지금 커널의 개발 프로세스와 커뮤니티를 대상으로 대규모 실험이 진행되고 있습니다."
바로 다음 문장은 이렇습니다.
"이 커뮤니티는 35년 역사 동안 새로운 프로세스와 도구를 여러 번 받아들여 왔고, 이번에도 거의 틀림없이 방법을 찾아낼 것입니다. 하지만 그 흡수 과정이 늘 아무 혼란 없이 진행된 것은 아닙니다."
자세한 내용은 여기 있습니다: https://news.ycombinator.com/item?id=50133642
이런 식의 짧은 소개글의 큰 문제는 대조군이 없다는 점입니다.
자금이 풍부한 주체의 유인이 달라졌기 때문에 과거 수치는 비교 대상으로 타당하지 않습니다. LLM 없이도 같은 규모로 자금을 댄 노력을 들여 패치 수를 끌어올려 봐야, 그 영향을 정량적으로 제대로 측정할 수 있을 겁니다.
기계가 생성하는 amdgpu 헤더 파일이 대체 얼마나 커질 수 있는 걸까요. 이제 한도를 정할 때가 된 것 같습니다.
그러니까 도입된 버그에 대해 생존 분석을 바이브 코딩으로 해볼 만하겠네요. 엄밀한 생존 분석은 아닐 수도 있어요. 버그가 발견되는 사건이 일어나기 전에는 버그가 있다는 것조차 모르니까요... 이 용도로 공개된 데이터셋이 있나요? URL이 있다면요.
7.3으로 올리실 분들께 알려 드립니다. 저는 /dev/input/events가 없어서 슬랙웨어 머신을 7.3-rc7에서 7.2.10으로 다시 내렸습니다. 그 때문에 키보드와 마우스가 콘솔에서만 작동했거든요.
환경에 따라 다를 수 있습니다.
제목을 편집하지 말아 주세요.
(수정: 제목이 고쳐졌습니다)
제출된 제목은 "Linux bugs fixed per release over time: >2× rise since 2026-04"였습니다. 지금은 원래대로 되돌렸습니다.
제출하시는 분들께: 글에서 중요하다고 생각하는 점을 말하고 싶다면 좋습니다. 다만 댓글로 달아 주세요. 그러면 여러분의 의견도 다른 사람들의 의견과 동등한 조건에서 읽힙니다: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang
저 섀도 밴당했어요. 계정은 어떻게 삭제하죠?
밴당하신 게 아닙니다. 다만 댓글 상당수가 사이트 가이드라인을 어겨서 정당하게 신고(flag)를 받은 것입니다.
섀도 밴당하셨다니 안타깝네요.