리눅스 커널에 AI 버그 보고 쇄도, 리뷰어 부족 심각

리눅스 커널의 버그를 찾는 일은 이제 쉬워졌습니다. 하지만 그것을 고치는 일은 전혀 다른 문제입니다. ZDNET가 2026년 11월 12일 전한 바에 따르면, AI 도구가 쏟아내는 버그 보고서와 패치가 너무 많아 이를 검토해야 하는 사람들이 지쳐 가고 있으며, 적어도 널리 알려진 커널 메인테이너 한 명은 대부분의 코드 검토를 중단했습니다.

CVE(Common Vulnerabilities and Exposures, 공통 취약점 식별자)는 문서화된 보안 결함에 붙는 공개 식별 번호입니다. 메인테이너(maintainer)는 커널의 한 부분을 맡아 어떤 패치를 받아들일지 결정하는 사람으로, 자원봉사자일 수도 있고 회사 직원일 수도 있습니다. 리뷰어(reviewer)는 제안된 패치를 읽고 반영 전에 올바른지 확인하는 사람입니다. 스마트폰부터 슈퍼컴퓨터까지 구동하는 운영체제의 핵심인 리눅스 커널은 이런 사람들 소수에 의존합니다.

리눅스 버그 보고서의 홍수는 얼마나 큰가?

ZDNET에 따르면 리눅스 CVE 팀은 2026년 11월 2일까지 하루 평균 27건의 CVE를 보고했습니다. ZDNET는 이 규모를 커널 고유의 원칙으로도 설명합니다. 리눅스에서는 어떤 버그든 보안 버그가 될 수 있다는 것입니다.

Tom's Hardware가 8월 28일자 Phoronix 보도를 전한 바에 따르면, 커널은 한 릴리스당 수정되는 CVE가 2,000건에 가까워지고 있으며, 이는 리눅스 6.x 시대 대부분의 약 500건과 비교됩니다. 안정 커널 메인테이너 Greg Kroah-Hartman이 Kernel Recipes 2026을 위해 준비한 슬라이드에는 리눅스 7.0에서 1,000건 이상, 리눅스 7.2에서 1,500건 이상으로 표시되어 있었습니다. 추세가 이어지면 리눅스 7.3은 2,000건을 넘을 수 있다고 Tom's Hardware는 전했습니다.

Tom's Hardware는 이 급증의 주된 원인을 35년 동안 4,000만 줄 넘게 커진 소스 트리를 AI 도구로 샅샅이 훑는 사람들에게서 찾으며, 커널 품질이 갑자기 떨어진 것은 아니라고 봅니다. 이런 도구는 사람이 좀처럼 다시 들여다보지 않는 외진 부분까지 닿아 가끔 진짜 결함을 찾아냅니다. 올해 리눅스 CVE 기록에는 AI 지원 정적 분석이 찾아내고 이후 Intel Product Security가 확인한 취약점이 이미 명시되어 있습니다.

ZDNET 기사는 기업 쪽 수치도 덧붙입니다. 마이크로소프트의 FORGE Lab은 AI 스캔 시스템 MDASH가 업스트림 리눅스 커널에 대해 59건의 버그 보고서를 냈으며, 그중에는 최소 21년 된 결함도 있다고 밝혔습니다. 연구소에 따르면 이 발견들을 보고서로 만드는 데 4인월 이상이 걸렸는데, 병목은 사람의 노력이었습니다. 버그를 찾는 일과 고치는 일이 극단적으로 불균형하다고도 설명했습니다. 윈도우 쪽에서는 최근 Patch Tuesday에 726건의 CVE가 포함됐고 대부분 AI 기반 발견에서 나왔다고 ZDNET는 지적합니다.

커널 메인테이너들은 왜 지쳐 가는가?

부담은 실명이 거론된 사례에서 드러납니다. ZDNET에 따르면 2026년 11월 10일 ARM 엔지니어이자 커널 메인테이너인 Lorenzo Stoakes가 메모리 관리 코어, misc, reclaim, Rust 관련 섹션의 코드 검토를 그만두었습니다. 리뷰어로서 맡아 오던 영역입니다. 그는 2014년부터 커널에 기여해 왔습니다. AI가 생성한 패치 시리즈의 현재 물량을 감안하면, 자신이 직접 유지보수하는 영역을 제외하고는 일반적인 검토를 제공할 여력이 없다고 썼습니다. 또 AI가 만든 조잡한 결과물이 처음에는 가끔, 다음에는 매주, 그다음에는 며칠마다 나타났고 지금은 눈에 띄는 것의 절반 이상이라고 덧붙였습니다.

ZDNET에 따르면 안정 커널 메인테이너 Greg Kroah-Hartman도 Open Source Summit Europe의 질의응답에서 같은 말을 했습니다. LLM이 생성한 패치의 맹공을 검토할 사람이 충분하지 않고, 메인테이너들은 10년째 지쳐 있다는 것입니다. 요청은 직설적이었습니다. 커널에는 더 많은 리뷰어가 필요하다는 것입니다.

Tom's Hardware는 네트워킹 분야에서 수치가 있는 사례를 듭니다. 리눅스 7.3 네트워킹 풀 리퀘스트에서 메인테이너 Jakub Kicinski는 이번 주기에 처리한 648건의 net-next 패치 중 3분의 1에서 절반이 AI가 주도한 우선순위 낮은 수정, 정리, 설명 보강으로 보인다고 추산했습니다. 그는 팀이 완전히 압도당했다고 썼습니다.

작업량은 커널이 무엇을 남겨 두는지도 바꾸고 있습니다. Tom's Hardware에 따르면 개발자 Andrew Lunn은 4월에 ISA와 PCMCIA 시대 하드웨어용 오래된 네트워크 코드 약 28,000줄을 제거하자고 제안했습니다. AI와 퍼징 도구가 결함을 찾기 시작했고, 아무도 그 하드웨어를 쓰지 않더라도 메인테이너가 고쳐야 한다고 느꼈기 때문입니다. 리눅스 7.3은 오래된 SGI와 IBM 드라이버 코드를 제거하고 있으며, FreeVxFS 파일 시스템 드라이버도 메인테이너가 낡은 호환성 코드가 주로 자동 버그 검사기의 먹잇감이 되고 있다고 말한 뒤 삭제되었습니다.

커널 커뮤니티는 AI를 거부하는가?

그렇지 않으며, Tom's Hardware도 이 점을 분명히 합니다. Kroah-Hartman 본인도 로컬에서 실행하는 AI 지원 퍼징 도구로 커널 버그를 찾아냈습니다. 불만은 검증되지 않은 AI 산출물을 사람에게 떠넘겨 확인하게 하는 데 있습니다. Tom's Hardware에 따르면 그는 최근 정당한 보안 수정을 제외하고 LLM이 생성한 패치를 커널 staging 서브시스템에서 금지했으며, 갱신된 커널 지침은 사람의 검증 없이 제출된 AI 생성 보고서가 메인테이너의 시간을 낭비할 수 있다고 경고합니다. 팀은 또 여러 프런티어 모델에 접근할 수 있게 되어 패치 검토와 환각으로 생긴 결과 걸러내기에 활용하고 있습니다.

수정이 보고서를 따라잡기 시작했는가?

초기 신호는 있지만 결정적이지는 않습니다. ZDNET에 따르면 Linus Torvalds는 Linux Kernel Mailing List의 메시지에서 리눅스 7.4-rc2의 새 코드 상당수가 AI 수정에서 비롯됐다고 썼습니다. 적어도 BPF 쪽에서는 수정이 이제 새 보고서보다 빨리 들어오고 있고, 다른 대부분의 영역은 아직 그 단계에 이르지 못했으며, 흐름이 바뀌기 시작했다는 신호일 수 있다고 말했습니다. 다만 너무 기대하지는 말라는 조언이었습니다.

Kroah-Hartman은 그만큼 낙관적이지 않습니다. 그는 ZDNET에 프로젝트가 가까워지고 있지만 아직 거기까지는 아니라고 말했고, 사람이 승인한 AI 수정이 AI 버그 보고서를 앞지르는 시점을 추정하는 것은 거부했습니다. cURL 프로젝트의 창시자이자 저품질 AI 보고서를 공개적으로 비판해 온 Daniel Stenberg는 ZDNET에 지금까지는 자신의 프로젝트가 홍수를 꽤 잘 관리하고 있다고 본다고 말했습니다. 다만 그 주에 누가 새 발견을 보내느냐에 따라 물량이 오르내린다고 했습니다.

• 하루 27건의 CVE: ZDNET에 따른 2026년 11월 2일까지 리눅스 CVE 팀의 평균.
• 커널 릴리스당 2,000건에 가까운 CVE: 6.x 시대 대부분은 약 500건, Tom's Hardware에 따름.
• 리눅스 7.3 주기의 네트워킹 패치 648건 중 3분의 1에서 절반이 우선순위 낮은 AI 주도 작업으로 판단됨, 메인테이너 Jakub Kicinski에 따름.

기업에는 무엇이 달라지는가?

서버, 컨테이너, 네트워크 장비, 임베디드 기기에서 리눅스를 운영하는 한국 기업에 주는 실무적 교훈은, 커널 보안 권고의 수는 계속 늘겠지만 각 수정 뒤에 있는 사람은 여전히 부족하다는 점입니다. CVE 수만으로는 위험을 거의 알 수 없습니다. 새 항목 상당수가 외진 드라이버에 관한 것이기 때문입니다. 중요한 것은 그중 어떤 것이 실제로 쓰는 하드웨어와 커널 구성에 영향을 주느냐입니다.

여기서 세 가지 습관이 나옵니다. 사용하는 배포판이 내놓는 안정 커널 업데이트를 추적하고 적용까지 걸리는 시간을 줄이십시오. 활성화한 커널 기능과 드라이버의 목록을 관리해 권고를 빠르게 분류할 수 있게 하십시오. 그리고 팀이 AI의 도움으로 버그 보고서를 제출한다면 먼저 사람이 각 문제를 재현하게 하십시오. 메인테이너들의 지침 자체가 검증되지 않은 보고서는 시간을 낭비시킨다고 말하기 때문입니다. 리눅스에 의존하는 기업은 리뷰 시간을 자금이나 인력으로 제공해 직접 도울 수도 있습니다. Kroah-Hartman에 따르면 그것이 가장 부족한 자원입니다.

한 가지 단서가 있습니다. 취재원들은 수정이 보고서를 언제 앞지를지 밝히지 않았고, BPF에 대한 Torvalds의 관찰도 고무적이지만 그 영역에 한정된다고 설명됩니다. 현재 시기는 자리 잡은 추세가 아니라 패치가 몰리는 바쁜 계절로 보는 편이 적절합니다.