Linux 7.2 커널 개발 통계

내 프로젝트에서도 비슷한 변화를 느낌. 에이전트 덕분에 버그 수정이 훨씬 빨라짐. 버그 보고서를 주면 재현부터 디버깅, 수정까지 처리하므로, 우리는 검토하고 필요하면 추가 설명이나 다른 접근법을 요청하면 됨.
동시에 라이브러리에 들어오는 버그 보고도 줄어드는 듯함. 사용자들이 에이전트로 코딩하고, 에이전트는 버그를 보고하는 대신 어떻게든 우회하기 때문으로 보임. 미해결 버그 수가 줄어드니 기분은 좋음.
반면 다른 사람의 에이전트가 만든 PR이 많이 들어오는데, 대규모 코드를 한꺼번에 제출하면 감당하기 벅차고 검토하기도 어려움.

나도 확실히 체감함. 작업 중인 프로젝트에서 Opus 5.5가 Smithay와 Winit의 버그를 하나씩 발견했는데, 알려주기는 했지만 선호하는 해결책은 로컬에서 우회하는 것이었음. 그렇다고 에이전트가 멋대로 버그를 자동 보고하기를 바라는 것도 아님.
대형 오픈소스 프로젝트를 운영하지는 않지만, AI PR을 받는다면 내 AI로 같은 기능을 먼저 구현한 뒤 PR을 참고해 빠뜨린 부분을 확인시키고 싶음. 적어도 성능을 신뢰하는 모델을 쓰고, 남의 코드를 무작정 받아들이는 위험을 줄일 수 있음. 물론 시간과 의지가 있다면 직접 검토해야겠지만, 항상 가능한 것은 아님.

에이전트가 버그를 보고하지 않고 우회하는 건 꽤 안타까움. 도메인에 대한 이해를 개선하고, Naur가 말한 이론 구축을 수행하며, 더 완성도 높은 API를 제공할 기회를 놓치게 됨.

에이전트도 사람처럼 버그를 새로 만들 수 있음. 최근 개발이 매우 활발해진 rsync를 보면 됨. 다만 우리도 LLM도 그런 버그를 쉽게 알아채지 못할 가능성이 큼.

원문 제목은 7.2 커널 개발 통계이며, 마지막 문단은 LLM에 상당히 비판적임. 반면 임의로 바꾼 제목인 ‘릴리스별 Linux 버그 수정 추이: 2026년 4월 이후 2배 이상 증가’는 Mythos가 버그를 찾아낸 결과인 듯한 인상을 줌.
마지막 문단은 “Linux 커널은 연구나 실험이 아니라 실서비스 사용을 목표로 함. 하지만 현재 커널 개발 절차와 커뮤니티를 대상으로 거대한 실험이 진행되고 있음.”이라고 적혀 있음.

바로 다음 문장도 함께 봐야 함. “이 커뮤니티는 35년 역사 동안 새로운 절차와 도구를 여러 차례 받아들였으며, 이번에도 거의 확실히 방법을 찾을 것임. 다만 그 과정이 언제나 순탄했던 것은 아님.”

이런 짧은 분석의 핵심 한계는 대조군이 없다는 것임. 자금력이 풍부한 주체의 유인이 달라졌으므로 과거 수치를 그대로 비교 기준으로 삼을 수 없음. LLM의 영향을 정량적으로 측정하려면 동등한 자금을 투입해 LLM 없이 패치 수를 늘리는 시도와 비교해야 함.

기계가 생성하는 amdgpu 헤더 파일은 대체 얼마나 커질 수 있는 걸까? 이제 크기에 제한을 둘 때가 된 듯함.

7.3 업그레이드를 고려한다면 주의가 필요함. 내 Slackware 시스템에서는 /dev/input/events가 사라져 키보드와 마우스가 콘솔에서만 작동했고, 결국 7.3-rc7에서 7.2.10으로 다운그레이드함. 환경에 따라 결과는 다를 수 있음.

새로 유입된 버그에 대한 생존 분석을 바이브 코딩으로 만들어볼 만해 보임. 다만 발견이라는 사건이 발생하기 전에는 버그의 존재조차 모르니, 일반적인 생존 분석과는 다름. 여기에 쓸 공개 데이터셋과 URL이 있을까?