# 리눅스 커널 수장 "AI가 찾은 취약점 79개 중 진짜는 몇 개일까"

> 리눅스 커널 리더가 AI 보안 도구의 '찾기' 성과보다 '검증' 비용을 경고했습니다.

- 매체: AI 브리핑
- 담당: 리서치 데스크
- 분야: 연구
- 발행: 2026-10-03T02:33:44.383Z
- 원문 주소(웹): https://ai-news-1c0.pages.dev/posts/2026-10-03-%EB%A6%AC%EB%88%85%EC%8A%A4-%EC%BB%A4%EB%84%90-%EC%88%98%EC%9E%A5-ai%EA%B0%80-%EC%B0%BE%EC%9D%80-%EC%B7%A8%EC%95%BD%EC%A0%90-79%EA%B0%9C-%EC%A4%91-%EC%A7%84%EC%A7%9C%EB%8A%94-%EB%AA%87-%EA%B0%9C%EC%9D%BC%EA%B9%8C/
- 태그: 리눅스, 보안, LLM, 그렉크로아하트만, Mythos, 취약점검증

---

## 리눅스 커널 유지보수자가 본 AI 보안의 현실

그렉 크로아하트만(Greg Kroah-Hartman)은 리눅스 커널 안정 버전 유지보수자다. 그가 최근 발표한 영상 "LLM 시대의 보안"에서 던진 메시지는 단순하다. **AI가 취약점을 '찾아내는' 속도보다, 사람이 그것을 '검증하고 고치는' 속도가 병목이라는 것.**

발표에 따르면 AI 보안 도구 Mythos가 리눅스 커널에서 보고한 취약점은 79개였다. 하지만 이 중 상당수는 오탐(false positive), 중복, 이미 수정된 문제였다. 크로아하트만은 "숫자 경쟁은 의미 없다. 실제 버그를 걸러내는 비용이 문제"라고 말했다.

## Mythos의 79개, 그리고 커널 프로세스의 차이

해커뉴스 댓글에서는 리눅스 커널의 CVE 부여 방식을 짚는다. **커널은 악용 가능성이 낮아도, DoS(서비스 거부) 가능성만 있어도 CVE를 부여한다.** 이 정책 때문에 "79개 발견"이라는 숫자만 보면 위험도가 과장돼 보인다.

한 댓글러는 "크로아하트만은 LLM이 영원히 오탐을 낼 거라고 말한 게 아니라, 지금 당장은 오탐이 너무 많아 유지보수자가 감당 못 한다는 뜻"이라고 정리했다. 발표문만 보면 'AI 한계'로 읽히지만, 현장 맥락은 '도구와 프로세스 불일치'에 가깝다.

## F-Droid 조사와 겹치는 교훈

본지가 18일 전 다룬 [F-Droid 앱 102개 중 얼마나 AI가 썼을까?](/posts/2026-09-15-f-droid-앱-102개-중-얼마나-ai가-썼을까-한-개발자의-직접-조사/) 조사에서도 같은 패턴이 나타났다. AI가 작성한 코드 비중을 세는 건 쉽다. 하지만 그 코드가 **실제로 동작하고, 안전하고, 유지보수 가능한지** 확인하는 건 전혀 다른 일이다.

당시 개발자는 "AI가 쓴 코드라고 다 나쁘진 않다. 하지만 검증 없이 합치면 기술 부채만 쌓인다"고 했다. 크로아하트만의 경고와 정확히 맞닿는다.

## 한국 기업이 당장 확인해야 할 것

국내 대기업 다수가 AI 코딩 어시스턴트(깃허브 코파일럿, 커서 등)를 도입했거나 검토 중이다. 이 도구들은 "취약점 자동 탐지"를 마케팅 포인트로 내세운다. 하지만 **탐지 알림이 개발자 이메일함에 쌓이면, 그걸 누가 검토하나?**

보안 팀 인력이 늘지 않은 상태에서 알림만 늘어나면, 진짜 취약점은 묻히고 가짜 알림에 시간만 쓴다. 크로아하트만이 지적한 '병목'이 한국 현장에서도 그대로 재현될 가능성이 크다.

## 쉽게 풀어보면

그렉 크로아하트만은 리눅스 커널의 '최종 품질 관리자'다. 그가 한 말을 뷔페에 비유하면 이렇다.

**AI가 "이 접시엔 상한 음식이 79개 있습니다"라고 접시 번호를 붙여 가져왔다. 그런데 막상 확인해 보니 상한 건 10개, 나머지는 멀쩡하거나 이미 치워진 접시였다. 품질 관리자는 79개 접시를 일일이 열어봐야 한다. 접시 수(발견 건수)가 늘어나면 관리자는 정작 상한 음식을 걸러낼 시간이 없다.**

핵심은 **'발견'이 아니라 '검증'**이다. AI가 수천 개 의심 지점을 띄워도, 사람이 "이건 진짜다"라고 확인하기 전엔 패치도 릴리스도 안 된다. 이 병목은 AI 모델이 좋아져도 쉽게 풀리지 않는다. 검증엔 문맥 이해와 의도 파악이 필요하기 때문이다.

## 나에게 미치는 영향

**개발자·보안 담당자라면:** AI 도구가 띄운 '취약점 의심 알림'을 무조건 믿지 마라. **같은 알림이 중복인지, 이미 패치된 버전인지, 실제 악용 가능한지** 1차 필터링 규칙을 팀 내에서 정해두라. 깃허브 디펜던봇(Dependabot) 알림처럼 '자동 승인'하지 말고, 심각도·악용 가능성·코드베이스 연관성을 사람이 한 번 봐야 한다.

**기획자·의사결정자라면:** "AI가 보안 취약점 N개를 찾았습니다"라는 보고서에 속지 마라. **검증 인력과 시간을 별도 예산으로 잡아야 한다.** 도구 도입 비용의 2~3배를 검증·대응 프로세스 구축에 써야 실효성이 있다.

**일반 사용자라면:** 리눅스 커널은 안드로이드폰, 서버, 임베디드 기기 밑바닥에 깔려 있다. 이 기반 소프트웨어의 보안 패치가 늦어지면 내 기기도 위험해진다. **AI가 빨리 찾는다고 패치가 빨라지는 건 아니다.** 유지보수자가 검증할 여유가 있어야 패치가 나온다.

## 남은 쟁점: 지속 학습 없는 LLM의 한계

해커뉴스 한 댓글은 "사람 뇌엔 컨텍스트 윈도우가 없다. 새 입력이 들어오면 계속 재구성된다. AI 업계는 이를 '지속 학습(continuous learning)'이라 부르며 현재 AI가 가장 부족한 부분으로 꼽는다"고 적었다.

크로아하트만 발표엔 이 대목이 빠졌다. 하지만 **코드베이스 전체 문맥을 유지하며 '이 함수가 저 모듈과 어떻게 엮이는지' 아는 능력**이야말로 오탐을 줄이는 열쇠다. 현재 LLM은 파일 단위·함수 단위 분석에 그친다. 커널 같은 거대 프로젝트에서 시스템 레벨 버그를 잡으려면, 아직 사람의 시스템 이해가 필수다.

이 간극이 좁혀지기 전까진, **AI는 '의심스러운 곳 표시기' 이상도 이하도 아니다.** 표시한 곳을 걸러내는 건 여전히 사람 몫이다. 그 비용을 누가, 어떻게 감당할지 — 그게 지금 보안 팀이 풀어야 할 숙제다.

---

## 출처

- [Hacker News] Greg Kroah-Hartman – Security in the LLM Age [video] — https://news.ycombinator.com/item?id=49929391
- [GeekNews] 리눅스 커널 개발자 Greg Kroah-Hartman, LLM 시대의 보안 [영상] — https://news.hada.io/topic?id=34683

## 집필 방식 고지

이 기사는 위 원문과 커뮤니티 반응을 바탕으로 AI의 도움을 받아 작성했으며, 발행 전 사람이 확인했습니다.
인용 시 출처를 "AI 브리핑"으로 표기하고 https://ai-news-1c0.pages.dev/posts/2026-10-03-%EB%A6%AC%EB%88%85%EC%8A%A4-%EC%BB%A4%EB%84%90-%EC%88%98%EC%9E%A5-ai%EA%B0%80-%EC%B0%BE%EC%9D%80-%EC%B7%A8%EC%95%BD%EC%A0%90-79%EA%B0%9C-%EC%A4%91-%EC%A7%84%EC%A7%9C%EB%8A%94-%EB%AA%87-%EA%B0%9C%EC%9D%BC%EA%B9%8C/ 로 연결해 주세요.