AI 안전성 - LLM 기반 버그 탐색이 Linux 커널의 보안과 오픈소스 유지보수에 미치는 영향

https://youtu.be/NnV_cWeoo5Q?si=JemYzradx7IhtyAV

2026.10.1
[Kernel Recipes 2026 - LLM 시대의 보안]

대규모 언어 모델(LLM)의 등장으로 리눅스 커널 개발 생태계가 마주한 변화와 이에 대한 오픈소스 유지보수자들의 대응 방안을 다루고 있습니다. LLM 기반 도구들이 방대한 양의 가짜 버그 리포트와 부정확한 패치를 쏟아내며 개발자들에게 큰 피로감을 주고 있지만, 이를 무조건적인 종말론으로 받아들이기보다 공포에 떨지 말고 이성적으로 대처해야 함을 강조합니다. 나아가 개발자들은 무분별한 텍스트 폭탄에 대해 적극적으로 이의를 제기하고 로컬 모델을 활용해야 하며, 과거 퍼저(fuzzer)의 등장 때처럼 결국 묵묵히 버그를 수정하고 코드 품질을 개선해 나간다면 이 시기를 성공적으로 극복할 수 있음을 역설합니다.

 

영상: Kernel Recipes 2026 — Security in the LLM age
발표자: Greg Kroah-Hartman(Greg KH)
핵심 주제: LLM 기반 버그 탐색이 Linux 커널의 보안과 오픈소스 유지보수에 미치는 영향.[1]

핵심 결론: AI의 버그 탐색 능력을 부정하는 강연이 아닙니다. 발견 건수에 대한 과장과 검증되지 않은 기여는 경계하되, 실제 버그를 재현·수정·배포하는 데 도구를 활용하자는 유지보수자 관점의 강연입니다.

분석 범위: 약 56분의 영어 자막을 기준으로 정리했습니다. 아래 챕터는 공식 챕터 목록이 아니라 발표의 주제 전환에 따라 재구성한 구간입니다. 자동 자막에는 고유명사·기술용어 오인식이 있어, 슬라이드에만 표시된 세부 수치와 외부 연구의 사실관계까지 독립 검증한 분석은 아닙니다.

 

1. 00:10–02:46｜문제 제기: CVE가 늘어도 공포에 빠질 필요는 없다

▶ 해당 구간

주요 내용

발표자는 일반 사용자나 개발자 전체가 아니라, 커널 개발자와 오픈소스 유지보수자를 대상으로 이야기한다고 밝힙니다.

Linux 커널의 CVE 처리 규모가 과거 주당 약 50~55건에서 발표 시점에는 하루 33건 수준으로 증가했다고 설명합니다. 다만 이전에 구축한 처리 도구가 확장성을 확보하고 있어, 처리 체계 자체가 무너진 상황은 아니라고 말합니다.[1]

반복하는 메시지는 “Do not panic”입니다.

분석

이 구간은 다음 두 가지를 분리하도록 요구합니다.

• CVE 등록·처리 건수가 증가했다.
• 실제로 악용 가능한 치명적 취약점이 같은 비율로 증가했다.

전자가 곧 후자를 의미하지는 않습니다. 발견·분류·등록 활동이 강화되면 CVE 수가 증가할 수 있기 때문입니다.

실무 시사점: 보안 현황 보고서에서 CVE 총량만 제시하면 위험을 과대평가하거나 잘못된 우선순위를 설정할 수 있습니다. 실제 사용 구성, 공격 가능 조건, 패치 적용 여부를 함께 봐야 합니다.

 

2. 02:46–10:30｜사례 해부: “79개 버그 발견”이 실제로 의미하는 것

▶ 해당 구간

주요 내용

발표자는 Anthropic의 Mythos 관련 버그 보고를 원자료 수준에서 검토한 경험을 설명합니다. 이전 수정 사례를 찾아 유사한 문제가 다른 코드에도 남아 있는지 탐색하는 접근은 오래전부터 존재했으며, LLM이 이를 효과적으로 수행할 수 있다고 봅니다.[1]

그러나 “79개 버그”라는 홍보 수치에는 다음과 같은 문제가 섞여 있었다고 지적합니다.

발표자가 설명한 유형	쟁점
충돌했다는 정보만 있고 유용한 보고가 없는 사례	재현·원인 분석에 필요한 증거 부족
실제로 버그가 아닌 사례	오탐
만들어낸 데이터에 기반한 사례	보고 내용의 신뢰성 문제
이미 다른 사람이 발견·수정한 사례	신규 발견과 기존 정보 재수집의 혼동
악의적 파일시스템 이미지 등을 전제한 사례	위협모델과 공격 권한 검토 필요
중복되거나 실제 수정으로 합쳐지는 사례	보고 건수와 수정 건수의 차이

발표자는 검토 과정에서 20개 수정이 필요하다는 단계를 거쳐, 최종적으로 10개의 실제 버그 수정으로 정리됐다고 설명합니다. 이를 커널 전체의 시간당 패치 반영 규모와 비교해 “약 한 시간의 커널 개발”에 해당한다고 표현합니다.[1]

분석

이 구간의 핵심은 측정 단위의 혼동입니다.

보고 항목 수 ≠ 신규 버그 수 ≠ 보안 취약점 수 ≠ 필요한 패치 수 ≠ 실제 위험 감소량

특히 공개 메일링리스트의 기존 버그를 다시 보고하는 것은 “AI가 새롭게 발견했다”는 주장과 구분해야 합니다.

해석상의 주의

• 자막에서 제시한 세부 분류만으로 79건 전체를 상호 배타적인 집계표로 재구성할 수는 없습니다. 발표자 자신도 숫자의 불일치를 지적합니다.
• “한 시간의 개발”은 전체 커널의 패치 처리량에 비유한 표현이지, 해당 문제를 탐색·검증·수정하는 데 실제 한 시간만 소요됐다는 의미가 아닙니다.
• 특정 보고 사례의 성과를 모든 AI 보안 도구의 성능으로 일반화해서는 안 됩니다.

실무 시사점: 도구 평가에는 단순 발견 건수보다 신규성, 재현성, 위협모델 적합성, 수정 타당성이 필요합니다.

 

3. 10:30–14:16｜진짜 보안 병목: 발견보다 패치 배포가 느리다

▶ 해당 구간

주요 내용

발표자는 문제의 중심을 버그 탐색에서 운영 시스템에 수정사항을 적용하지 않는 관행으로 옮깁니다.

기존의 발견·공개·패치·배포 주기를 설명하며, 과거에는 특정 기준 시점 이후 악용까지 63일이 걸렸으나 이제는 −7일이라는 수치를 언급합니다. 또한 LLM 기반 도구가 작은 문제들을 연결해 공격에 활용할 수 있으므로, 사소해 보이는 버그도 수정해야 한다고 강조합니다.[1]

퍼저가 대량의 버그를 발견했을 때도 개발자들이 하나씩 수정해 왔으며, 이번에도 같은 방식으로 대응할 수 있다고 봅니다. rsync 등에서 도구를 활용해 버그를 정리한 경험도 제시합니다.[1]

분석

강연의 가장 중요한 전환점입니다.

발견 능력이 빨라져도 배포 속도가 그대로라면, 운영 환경의 노출 문제는 해결되지 않습니다.

또한 개별 버그의 심각도가 낮다는 이유만으로 무시하기 어렵습니다. 여러 결함이 조합되면 공격 경로가 형성될 수 있다는 점을 발표자도 인정합니다.

해석상의 주의

• 63일·−7일 수치는 발표자의 인용값입니다. 자막만으로 원자료, 표본, 기준 시점을 확정할 수 없어 일반적인 산업 통계로 사용하기에는 부족합니다.
• “현재 스캐너에서 문제가 나오지 않는다”는 결과는 검사 범위 내 미검출이지, 취약점이 전혀 없다는 증명이 아닙니다.

실무 시사점: 보안 통제는 발견에서 끝나지 않고, 수정 → 배포 → 실행 버전 확인 → 재검증까지 이어져야 합니다.

 

4. 14:16–16:09｜학습데이터·저작권 비판과 도구 활용의 분리

▶ 해당 구간

주요 내용

발표자는 AI 기업들이 오픈소스 개발자의 작업물을 학습에 활용하면서 충분한 보상을 제공하지 않는다고 비판합니다. 학습데이터의 적법성과 저작권 문제도 언급합니다.

그러면서도 기업들이 투자해 만든 도구를 오픈소스의 버그 수정에 활용할 수 있다고 주장합니다.[1]

분석

발표자는 서로 다른 문제를 분리합니다.

• 산업·거버넌스 문제: 학습데이터의 권리, 보상, 기업의 책임.
• 엔지니어링 문제: 도구가 실제 코드 개선에 도움이 되는가.

즉, AI 산업의 행태를 비판한다고 해서 모든 기술적 활용까지 거부하는 입장은 아닙니다.

해석상의 주의

이 구간에서 언급한 학습데이터의 20%·80% 비율, 기업 발언, FSF의 목적에 대한 설명은 별도의 원문 확인이 필요합니다. 이를 곧바로 특정 데이터 전체의 위법성이나 확정된 법적 판단으로 인용하면 안 됩니다.

실무 시사점: AI 도입 검토에서도 기술 성능 평가와 데이터·라이선스 적법성 평가를 별도 항목으로 관리해야 합니다.

 

5. 16:09–19:16｜버그 보고서만 받지 말고, 수정 패치를 요구하라

▶ 해당 구간

주요 내용

발표자는 도구로 문제를 찾은 뒤 수정 패치까지 생성하도록 요구하는 방식을 설명합니다.

기업이 “100개 버그를 찾았다”고 전달했지만, 실제 검토에서는 소수의 수정이나 경미한 보강으로 정리된 사례를 제시합니다. 버그 보고서에서 패치 생성으로 넘어가면 오탐 상당수가 드러난다고 설명합니다.[1]

분석

패치 요구는 단순히 유지보수자의 일을 제출자에게 넘기는 것이 아닙니다. 주장을 구체적인 수정안으로 바꾸게 하는 검증 장치입니다.

제출자는 다음을 설명할 수 있어야 합니다.

• 정확히 어느 코드 경로가 문제인가?
• 어떤 조건에서 문제가 발생하는가?
• 변경이 왜 필요한가?
• 변경 후 문제가 해결됐음을 어떻게 확인했는가?

다만 패치가 존재한다고 보고가 참인 것은 아닙니다. 틀린 문제를 고치는 패치나 새로운 결함을 만드는 패치도 가능하기 때문입니다.

실무 시사점: 접수 기준을 “설득력 있는 설명”에서 재현 사례·최소 수정안·시험 결과로 전환할 필요가 있습니다.

 

6. 19:16–24:26｜그럴듯한 AI 패치의 위험: 설명보다 코드와 시험을 보라

▶ 해당 구간

주요 내용

발표자는 대학원생 6명과 수행한 검토 경험을 바탕으로, 생성된 패치 중 절반가량이 잘못됐다고 설명합니다. 적용되지 않거나, 문제를 해결하지 못하거나, 애초에 문제가 없거나, 도달 불가능한 코드 경로를 전제로 한 경우 등이 포함됩니다.[1]

구체적인 예로 mutex_unlock을 mutex_destroy로 바꾸는 잘못된 수정을 지적합니다. 또한 다음 경향을 비판합니다.

• 과도하게 긴 변경 설명.
• 작은 변경에 붙는 불필요하게 많은 주석.
• 플래그·상태값의 불필요한 추가.
• 현재 프로젝트 관행과 맞지 않는 과거 코드 패턴의 재생산.[1]

분석

두 가지 문제가 겹칩니다.

① 설명의 설득력이 정확성을 대신하는 문제
상세한 설명이 있으면 검토자는 충분한 판단과 시험을 거친 패치라고 착각하기 쉽습니다.

② 과거 코드가 현재의 권장 패턴과 다른 문제
학습된 사례가 많아도, 프로젝트가 이후에 개선한 규칙이나 보안 관행을 정확히 반영한다는 보장은 없습니다.

따라서 검토의 중심은 다음이어야 합니다.

수정 필요성 → 코드 의미 → 실제 도달 가능성 → 재현·회귀시험

해석상의 주의

“절반이 틀렸다”는 수치는 발표자의 검토 경험입니다. 전체 패치 수, 모델, 프롬프트, 선정 방식이 자막에서 충분히 제시되지 않아, 모든 LLM의 일반 오류율로 사용할 수는 없습니다.

실무 시사점: 장문의 설명은 시험 증거를 대체할 수 없습니다. “어떻게 시험했는가?”를 필수 질문으로 삼아야 합니다.

 

7. 24:26–26:51｜정보 유출과 오탐: 성능 외에 고려해야 할 비용

▶ 해당 구간

주요 내용

발표자는 비공개 보안 정보를 외부 AI 서비스에 업로드하지 말라고 강하게 경고합니다. 또한 Coverity의 경험을 인용하며, 개발자들이 높은 오탐률을 가진 도구를 지속적으로 사용하기 어렵다고 설명합니다.[1]

분석

AI 보안 도구의 비용은 사용료나 토큰 비용에 국한되지 않습니다.

• 틀린 보고를 읽고 분류하는 시간.
• 중복 여부를 확인하는 시간.
• 재현 환경을 구축하는 비용.
• 비공개 취약점과 소스코드의 외부 전송 위험.
• 반복적인 오탐으로 인한 검토 피로.

따라서 발견량이 증가했다는 사실만으로 순효익이 증가했다고 판단할 수 없습니다.

해석상의 주의

발표자의 “업로드하면 유출된다”는 표현은 강한 보안 경고로 읽어야 합니다. 모든 서비스·계약·배포 방식에서 입력 내용이 반드시 다른 사용자에게 공개된다는 보편적 사실로 단정해서는 안 됩니다.

실무 시사점: 외부 서비스 사용 여부는 데이터 보관, 학습 사용, 접근권한, 계약, 전송 정책을 확인해 결정해야 합니다. 로컬 모델도 원격 텔레메트리나 도구의 외부 통신을 별도로 점검해야 합니다.

 

8. 26:51–29:06｜대응 체계: 위협모델 문서화와 제출 품질 기준

▶ 해당 구간

주요 내용

발표자는 다음 대응을 소개합니다.

• 서브시스템별 위협모델 문서화.
• 보안 보고에 해당 유지보수자 포함.
• LLM 기반 보고에 수정 패치 요구.
• 전담 보안 인력 확보.
• OpenSSF·Alpha-Omega의 지원 활용.[1]

분석

핵심은 AI 도입보다 먼저 판정 기준과 책임체계를 정비하는 것입니다.

위협모델이 없으면 도구는 “코드가 충돌할 수 있다”는 사실만으로 보안 취약점이라고 주장하기 쉽습니다. 위협모델은 다음을 명확히 합니다.

• 공격자가 이미 가진 권한.
• 신뢰하는 입력·장치·구성.
• 보호해야 할 자산.
• 문제가 성립하는 운영 조건.
• 보안 이슈와 일반 품질 이슈의 경계.

실무 시사점: 저장소에 코딩 규칙만 둘 것이 아니라, 위협모델·지원 환경·보고 기준·시험 기준도 함께 관리해야 합니다.

 

9. 29:06–34:07｜실행 전략: 로컬 활용, 실제 수정, 불필요한 코드 삭제

▶ 해당 구간

주요 내용

발표자의 실행 권고는 다음과 같습니다.

• 잘못된 보고에는 설명과 증거를 요구한다.
• 공포를 활용한 마케팅에 휘둘리지 않는다.
• 로컬 모델과 오픈소스 에이전트를 활용한다.
• 비공개 자료를 외부에 보내지 않는다.
• 실제 버그는 수정한다.
• 사용하지 않는 드라이버·프로토콜·서브시스템은 삭제할 수 있다.[1]

사용되지 않는 드라이버를 고치려다가 약 3,000줄을 삭제한 사례를 긍정적으로 평가합니다. 앞으로 일정 기간 부담은 크겠지만, 퍼저에 대응했듯 이 과정을 거치면 코드가 개선될 것이라는 전망입니다.[1]

분석

보안 개선은 코드 추가만으로 이루어지지 않습니다.

사용하지 않는 기능을 제거하면 공격면과 유지보수 범위를 줄일 수 있습니다. 이는 AI가 찾아낸 모든 문제에 패치를 덧붙이는 방식과 다른 접근입니다.

또한 로컬 도구의 가치는 모델 자체의 성능뿐 아니라, 프로젝트의 최신 규칙과 검토 절차를 연결하는 데 있습니다.

해석상의 주의

발표자가 언급한 12~18개월은 불확실성을 인정한 전망이며, 검증된 해결 일정은 아닙니다.

실무 시사점: AI 도구 도입 계획에 기능 정리·레거시 제거·공격면 축소를 함께 포함하는 것이 합리적입니다.

 

10. 34:23–43:44｜질의응답: 유지보수 부담과 인간 기여자의 책임

▶ 해당 구간

주요 내용

질의응답에서는 AI가 만든 장문의 보고서를 유지보수자가 해석해야 하는 비대칭적 부담이 집중적으로 논의됩니다.

신규 기여자에게는 다음을 권고합니다.

• 한꺼번에 많은 패치를 보내지 않는다.
• 무엇을 했고 어떻게 시험했는지 보여준다.
• 검토 의견과 이메일에 응답한다.
• 잘못됐을 때 다시 수정할 책임을 진다.[1]

발표자는 staging 영역에서 하드웨어를 갖고 패치를 시험했음을 입증하지 못하는 LLM 기여를 제한한다고 설명합니다. 참석자는 AI 사용 공개, 시험 수준 표시 등을 제안합니다. 긴 변경 설명을 인간이 이해하고 다시 작성해야 한다는 논의도 이어집니다.[1]

분석

이 구간에서 말하는 신뢰는 단순한 신원 확인이 아닙니다.

“정답을 제출하는 사람인가?”보다 “오류가 발생했을 때 설명하고 수정할 사람인가?”가 중요합니다.

AI가 작성한 문장을 그대로 전달하는 사람은 기술적 책임의 연결고리가 되기 어렵습니다.

해석상의 주의

작성자·Signed-off-by 처리에 관한 강경한 발언은 토론 중 제시된 개인 의견입니다. 이를 확정된 커널 공통 정책으로 해석해서는 안 됩니다.

실무 시사점: AI 사용 공개와 별개로 시험 증거, 변경 이해도, 후속 대응 책임을 확인해야 합니다.

 

11. 43:44–50:09｜유용한 AI 활용과 공개·검증의 현실적 한계

▶ 해당 구간

주요 내용

참석자들은 AI가 테스트 작성, 반복 코드 작성, 가상머신 기반 시험, 실제 노트북의 오디오 문제 해결 등에 유용할 수 있다고 인정합니다.[1]

다른 참석자는 기여 수준을 다음과 같이 구분한 사례를 소개합니다.

• 실제 시험까지 수행한 경우.
• 문서를 읽은 경우.
• AI 출력만 읽은 경우.

공개 가능한 AI 대화 이력도 제안하지만, 발표자는 대규모 커널 프로젝트에서 모든 대화 로그를 검토하는 것은 현실적으로 어렵다고 답합니다. 우선 AI 도움을 받았다는 사실을 표시하고 코드 자체를 검토하는 접근을 선호합니다.[1]

분석

강연은 결국 AI 사용 여부에 따른 일괄 승인·거부를 지지하지 않습니다.

• 실제 장치에서 문제가 해결됐고 시험됐다면 유용한 기여일 수 있습니다.
• 핵심 코드의 의미를 이해하지 못한 채 대량 제출했다면 부담이 됩니다.
• 생성 과정 전체를 공개해도 결과 코드의 타당성이 자동으로 입증되지는 않습니다.

실무 시사점: 공개 기준은 조직 규모와 위험도에 맞춰야 합니다. 대화 로그 수집 자체를 목표로 삼기보다, 검증에 필요한 증거를 최소한으로 확보하는 것이 중요합니다.

 

12. 50:18–56:40｜마지막 쟁점: 생산성, 신규 결함, 보안 지원

▶ 해당 구간

주요 내용

마지막 질의응답은 세 가지 질문으로 수렴합니다.

① 패치가 늘면 생산성도 높아지는가?
발표자는 더 많은 패치를 처리한다고 해서 자신이 더 생산적이라고 느끼지는 않는다고 답합니다.[1]

② 소규모 유지보수자가 보안 보고를 감당할 수 있는가?
익숙하지 않은 보고를 받았거나 처리에 어려움이 있다면 보안팀에 도움을 요청하라고 권고합니다.[1]

③ AI가 새 버그를 더 많이 넣고 있지는 않은가?
발표자는 자신이 본 자료에서는 아직 신규 버그 증가를 확인하지 못했다고 말합니다. 다만 규모가 큰 코드베이스이므로 더 긴 관측이 필요하다는 취지입니다.[1]

분석

마무리의 핵심은 처리량과 성과를 구분하는 것입니다.

• 패치 수 증가가 품질 향상의 충분한 증거는 아닙니다.
• 발견된 버그 수 증가가 신규 결함 유입 증가의 증거도 아닙니다.
• 검토 부담을 포함한 전체 효과를 측정해야 합니다.

실무 시사점: AI 개발 도구의 효과는 생성량보다 검증을 통과한 수정, 운영 적용, 회귀 결함, 검토 시간으로 평가해야 합니다.

 

종합 해석: 이 강연에서 가져올 핵심 5가지

핵심 메시지	실무적 의미
발견 건수를 성과로 착각하지 말 것	신규성·중복·오탐·위협모델 적합성을 구분
패치 존재와 패치 정확성은 다르다	재현시험·회귀시험·코드 의미 검토 필요
진짜 병목은 운영 반영일 수 있다	패치 배포와 실행 버전 확인까지 추적
AI는 검토 비용도 발생시킨다	유지보수자 시간과 후속 대응을 성과 평가에 포함
도구를 쓰더라도 책임은 인간에게 남는다	변경 설명·시험 증거·오류 수정 책임 확보

감리·품질관리 관점의 적용 제안

아래는 발표 내용을 바탕으로 한 분석자 권고이며, 강연에서 그대로 제시한 공식 체크리스트는 아닙니다.

우선순위	검토 항목	요구할 증거
높음	AI가 주장한 문제가 실제로 존재하는가	발생 조건, 재현 절차, 오류 로그
높음	수정이 문제를 해결하고 부작용을 만들지 않는가	수정 전·후 시험, 회귀시험, 검토 기록
높음	비공개 자료가 허용된 범위에서 처리되는가	전송 정책, 서비스 계약, 보관·학습 사용 설정
높음	수정사항이 운영 환경에 실제 적용됐는가	배포 이력, 실행 버전, 적용 후 확인
중간	신규 발견과 기존 보고를 구분했는가	기존 이슈·CVE·커밋 대조 기록
중간	인간 검토자와 제출자의 책임이 명확한가	AI 사용 표시, 승인자, 후속 대응 담당자
중간	도구가 프로젝트의 최신 기준을 따르는가	위협모델, 코딩 규칙, 지원 구성, 검토 지침
후순위	유지할 필요가 없는 코드가 남아 있는가	사용 현황, 제거 영향 분석, 지원 종료 계획

최종 판단: 이 영상은 “AI 보안 도구는 쓸모없다”는 주장이 아니라, AI가 만든 주장에 증거를 요구하고, 검증 비용을 제출자와 도구 제공자도 부담하며, 실제 운영 보안 개선까지 연결하라는 강연으로 읽는 것이 정확합니다.

출처

[1] https://www.youtube.com/watch?v=NnV_cWeoo5Q — Kernel Recipes 2026 - Security in the LLM age