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

리눅스 커널 유지보수자가 본 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가 썼을까? 조사에서도 같은 패턴이 나타났다. AI가 작성한 코드 비중을 세는 건 쉽다. 하지만 그 코드가 실제로 동작하고, 안전하고, 유지보수 가능한지 확인하는 건 전혀 다른 일이다.

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

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

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

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

쉽게 풀어보면

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

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

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

나에게 미치는 영향

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

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

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

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

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

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

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