리누스 토르발즈의 한탄: AI가 만들어낸 가짜 버그 리포트, 리눅스 보안 메일링 리스트를 마비시키다

리눅스 커널의 아버지가 화가 났어요

리누스 토르발즈(Linus Torvalds)가 또 한 번 강한 어조로 입을 열었어요. 이번에 그가 지적한 건 다름 아닌 'AI를 활용한 자동 버그 헌터(bug hunter)'들이에요. 그는 리눅스 커널 보안 메일링 리스트가 "거의 관리 불가능한 상태"가 되어버렸다고 토로했는데요, 이게 무슨 말이냐면 진짜 보안 취약점을 찾아내는 진지한 리포트보다, AI 도구로 자동 생성된 의심스러운 '버그 같아 보이는' 리포트가 훨씬 더 많이 쏟아져 들어오고 있다는 거예요.

리눅스 커널은 워낙 거대한 프로젝트라 보안 이슈가 발견되면 linux-security 같은 비공개 메일링 리스트로 먼저 보고가 들어가요. 그러면 핵심 메인테이너들이 검토하고 패치를 만들어서 공개 전에 조용히 수정하는 흐름이거든요. 그런데 요즘은 이 메일링 리스트가 '이런 곳에 use-after-free가 있는 것 같은데요?' 같은 AI 생성 리포트로 가득 차서, 정작 진짜 위협을 분류할 시간이 모자란다는 거예요.

도대체 무슨 일이 벌어지고 있는 걸까

요즘 GPT 계열 모델이나 Claude 같은 LLM에 소스 코드를 던지고 "여기 보안 취약점 찾아줘"라고 시키면, 모델은 거의 무조건 뭔가를 찾아내요. 문제는 그게 진짜인지 아닌지 확신할 수 없다는 거죠. 모델은 '그럴듯한 답변'을 만들어내는 데 특화되어 있어서, 실제로는 안전한 코드인데도 위험해 보이는 시나리오를 만들어 설명할 수 있거든요. 이걸 우리는 흔히 할루시네이션(hallucination, 환각)이라고 부르는데, 보안 영역에서는 이게 정말 골치 아픈 문제예요.

AI 도구로 무장한 사람들 중 일부는 버그 바운티(bug bounty, 취약점을 신고하면 보상금을 주는 제도)를 노리기도 해요. 어떤 사람은 그저 명예나 CVE 번호 하나 받고 싶어서 무차별적으로 리포트를 보내기도 하고요. 결과적으로 메인테이너들은 가짜 리포트 100개를 분석해서 진짜 하나를 골라내야 하는 처지가 되었어요. 토르발즈는 이런 상황을 두고 "신호 대 잡음 비율(signal-to-noise ratio)이 무너졌다"라고 표현했는데, 잡음이 너무 많아서 진짜 신호를 못 듣는 라디오 같은 상태가 된 거죠.

다른 오픈소스 프로젝트도 같은 고민 중

이 문제는 사실 리눅스만의 일이 아니에요. 작년에 curl 프로젝트의 메인테이너 다니엘 스텐버그(Daniel Stenberg)도 비슷한 불만을 공개적으로 터뜨렸어요. HackerOne 같은 버그 바운티 플랫폼으로 들어오는 리포트의 상당수가 AI가 만든 가짜라서, 메인테이너 한 명이 일주일에 수십 시간을 검증에 쓰고 있다는 얘기였죠. 파이썬 재단이나 OpenSSL 같은 곳에서도 비슷한 신호가 감지되고 있어요.

반대편엔 또 다른 그림도 있어요. 구글의 Big Sleep 프로젝트나 OSS-Fuzz-Gen은 AI를 활용해서 실제로 진짜 취약점을 찾아내는 데 성공하고 있거든요. 즉, AI 자체가 문제가 아니라 '어떻게 쓰느냐'가 핵심이라는 거예요. 잘 설계된 파이프라인 안에서 AI가 후보를 추리고, 실제 PoC(Proof of Concept, 개념 증명) 코드까지 만들어 검증한 후에 사람에게 전달되면 굉장히 유용하지만, 그냥 "코드 보고 버그 찾아줘"를 그대로 메일로 보내면 잡음만 되는 거죠.

한국 개발자에게 이게 왜 중요할까

오픈소스에 기여하고 싶은 분들이라면 이 흐름을 꼭 알고 계셔야 해요. AI 도구를 활용해 취약점을 찾는 건 좋지만, 보고하기 전에 반드시 직접 재현 가능한 PoC를 만들고, 영향 범위를 분석하고, 메인테이너 입장에서 검토하기 편한 형태로 정리해서 보내야 해요. 그렇지 않으면 의도와 상관없이 메인테이너들의 시간을 빼앗는 사람이 되어버리거든요.

또 사내에서 LLM으로 코드 리뷰나 보안 점검 자동화를 도입하려는 팀이라면, 결과를 그대로 신뢰하지 말고 정적 분석 도구와 교차 검증하거나, 실제 익스플로잇 가능 여부를 자동으로 테스트하는 단계를 꼭 넣어야 해요. 신호와 잡음을 구분하는 필터를 처음부터 설계에 포함시키는 거죠.