LLM이 찾아낸 '가짜 취약점' 때문에 리눅스 커널 코드가 삭제되고 있다

AI가 보안을 돕는다고요? 오히려 혼란을 만들고 있습니다

요즘 GPT-4나 Claude 같은 대형 언어 모델(LLM)이 코드 리뷰나 보안 분석에 쓰이는 일이 부쩍 늘었죠. "AI가 사람 대신 취약점을 찾아준다"는 이야기, 한 번쯤 들어보셨을 거예요. 그런데 리눅스 커널 세계에서 조금 당황스러운 일이 벌어지고 있어요. LLM이 생성한 보안 리포트를 근거로 실제 커널 코드가 삭제되는 상황이 반복되고 있거든요. 문제는 그 리포트들 중 상당수가 실제로는 취약점이 아닌데 AI가 취약점처럼 그럴싸하게 써낸 것이라는 점이에요.

리눅스 커널은 전 세계 거의 모든 서버, 안드로이드폰, 임베디드 기기에서 돌아가는 운영체제의 심장이에요. 여기에 보안 이슈가 생기면 파장이 어마어마하죠. 그래서 커널 메인테이너들은 CVE(보안 취약점 식별 번호)가 올라오면 아주 신중하게 검토하는데, 최근에는 이 검토 과정 자체가 AI가 쏟아내는 '허위 리포트'로 몸살을 앓고 있어요.

어떻게 된 일일까요

이번에 LWN에 올라온 기사는 구체적인 사례를 보여줍니다. 누군가가 LLM을 써서 "이 함수는 취약점이 있다"는 주장을 커널 메일링 리스트에 보내요. 이 리포트는 겉보기에 아주 논리적이고 설득력 있게 쓰여 있어요. 함수명, 라인 번호, 공격 시나리오까지 구체적이죠. 그래서 메인테이너가 자세히 들여다보는데, 막상 코드를 따라가 보면 그 취약점은 실제로는 존재하지 않거나, AI가 코드 흐름을 오해한 것인 경우가 많다고 해요.

그런데 더 흥미로운 건, 이런 허위 리포트를 받고 나서 메인테이너가 "이 코드는 어차피 쓰임새가 애매하니까 그냥 삭제하자"고 결정하는 경우가 생기고 있다는 거예요. 취약점이 진짜여서가 아니라, 검토 비용이 너무 크고 방어하기 귀찮으니까 제거하는 것이 합리적이라는 거죠. 이렇게 되면 AI 리포트가 간접적으로 커널 코드의 형태를 바꾸고 있는 셈입니다.

이게 왜 문제냐면요, LLM은 기본적으로 그럴듯한 텍스트를 생성하는 도구이지, 논리적 정답을 보장하는 도구가 아니에요. 커널처럼 메모리 관리, 동기화, 하드웨어 인터페이스가 복잡하게 얽힌 코드에서는 "여기 race condition(여러 스레드가 동시에 접근해서 생기는 버그)이 있어 보인다"는 주장을 AI가 아주 설득력 있게 써내지만, 실제로 락(lock)이 걸려 있거나 다른 함수에서 이미 처리되고 있어서 문제가 없는 경우가 태반이에요. 사람이 일일이 반증하려면 몇 시간씩 걸리는데, AI는 같은 품질의 리포트를 1분에 수십 개씩 찍어낼 수 있잖아요.

오픈소스 커뮤니티의 딜레마

비슷한 일이 curl 프로젝트에서도 몇 달 전에 있었어요. curl 메인테이너인 Daniel Stenberg가 "AI가 만든 쓰레기 보안 리포트 때문에 시간을 너무 많이 버리고 있다"며 공개적으로 불평했죠. HackerOne 같은 버그바운티 플랫폼에서 상금을 노리고 AI로 대량 생성한 리포트를 제출하는 사람들이 실제로 있거든요. 허위 신고라도 일단 메인테이너가 검토는 해야 하니까, 공격자 입장에서는 DoS(서비스 거부 공격)에 가까운 효과를 내는 거예요. 다만 이건 악의적인 공격이라기보단 '보상 시스템의 허점을 파고드는 행위'에 가깝습니다.

커널의 경우는 조금 결이 달라요. 여기는 버그바운티가 없고, 대부분 선의의 기여자들이 AI 도구를 '보조 수단'으로 쓰다가 검증 없이 제출하는 경우가 많대요. 그러니까 악의보다는 "AI가 찾아줬으니 맞겠지"라는 과신이 문제인 거죠. Greg Kroah-Hartman 같은 핵심 메인테이너들은 이런 흐름에 대해 상당히 비판적인 입장을 내놓고 있고, 일부는 아예 "AI 생성으로 의심되는 리포트는 기본적으로 거부하겠다"는 정책까지 고민하고 있다고 해요.

한국 개발자에게 주는 시사점

이 상황은 우리에게 꽤 중요한 교훈을 줘요. 요즘 한국 기업들도 사내 보안팀에서 LLM을 써서 코드 감사를 자동화하는 시도가 늘고 있거든요. 그런데 이번 커널 사례는 "AI가 찾은 취약점을 그대로 이슈로 올리면 안 된다"는 걸 분명히 보여줘요. 반드시 사람이 코드 흐름을 따라가면서 재현 시나리오를 검증해야 하고, 가능하면 실제 PoC(개념 증명 코드)까지 확인하는 단계를 거쳐야 합니다.

또 하나 생각해 볼 지점은 오픈소스에 기여할 때의 에티켓이에요. Claude나 GPT로 코드를 분석해보는 건 좋지만, 그 결과를 그대로 메인테이너에게 전달하는 건 민폐가 될 수 있어요. 특히 메인테이너가 소수인 프로젝트일수록 허위 리포트 한 건이 몇 시간의 개발 시간을 앗아갈 수 있거든요. AI는 '가설 생성기'로만 쓰고, 검증은 본인이 책임진다는 태도가 필요해요.

마무리

LLM이 보안 분야에서 유용하지 않다는 뜻은 절대 아닙니다. 오히려 패턴 매칭이나 초기 탐색에는 정말 강력한 도구예요. 다만 "AI의 출력은 초안이고, 판단은 사람이 한다"는 원칙이 없으면 오히려 커뮤니티 전체에 부담을 주는 역효과가 난다는 게 이번 이슈의 핵심입니다.

여러분은 어떻게 생각하시나요? AI가 만든 보안 리포트를 받았을 때, 메인테이너가 거부할 수 있는 명확한 정책이 필요할까요? 아니면 검증 과정을 AI로 다시 자동화하는 게 현실적인 방향일까요?