커널 관리자가 LLM 이야기를 꺼낸 이유
그렉 크로아하트만(Greg Kroah-Hartman, 줄여서 GKH)은 리눅스 커널 stable 브랜치 관리자예요. stable 브랜치는 새 기능 개발과는 별개로, 이미 출시된 커널 버전에 버그 수정만 골라서 계속 반영하는 유지보수 라인이에요. 안드로이드폰, 서버, 공유기 같은 수많은 기기가 결국 이 라인에서 나온 커널을 쓰고 있으니, 리눅스 보안 패치가 지나가는 관문을 지키는 사람이라고 보시면 돼요.
그런 그가 'LLM 시대의 보안'을 주제로 발표를 했어요. 지금 이 주제가 중요한 이유는 간단해요. AI가 코드를 쓰는 데서 그치지 않고 버그를 찾고, 신고하고, 공격 코드를 만드는 일까지 하기 시작했거든요. 오픈소스 보안의 최전선에 있는 사람이 이 변화를 어떻게 보는지는 우리 모두에게 의미가 있어요.
배경 1: 커널이 직접 CVE를 발급하기 시작했어요
맥락을 이해하려면 2024년으로 돌아가야 해요. 리눅스 커널 프로젝트는 2024년 2월에 CNA(CVE Numbering Authority)가 됐어요. CVE는 보안 취약점마다 붙는 고유 번호이고, CNA는 이 번호를 직접 발급할 수 있는 조직이에요.
커널 팀의 입장은 꽤 급진적이었어요. 커널에서는 상황에 따라 거의 모든 버그가 보안 문제가 될 수 있다는 거예요. 그래서 보안 문제일 가능성이 있는 수정에는 폭넓게 CVE를 붙이기 시작했고, 커널 CVE가 한 해 수천 개 수준으로 늘었어요. 보안 스캐너를 돌리던 회사들은 갑자기 쏟아지는 CVE 목록 앞에서 난감해졌고요.
그렉이 여러 자리에서 일관되게 해온 조언이 있어요. CVE를 하나씩 골라서 패치하려 하지 말고, 최신 stable 커널로 꾸준히 업데이트하라는 거예요. 수천 개 중에 우리 제품에 해당하는 걸 사람이 일일이 판단하는 건 현실적으로 불가능하니까요.
배경 2: AI가 버그 리포트를 쏟아내기 시작했어요
여기에 LLM이 끼어들어요. 처음 나타난 건 이른바 'AI 슬롭(slop)' 리포트였어요. 그럴듯해 보이지만 실제로는 근거가 없는 AI 생성 결과물을 슬롭이라고 불러요. curl 프로젝트의 다니엘 스텐베리(Daniel Stenberg)는 AI가 지어낸 가짜 취약점 신고 때문에 메인테이너들의 시간이 낭비된다고 공개적으로 지적했고, 결국 버그 바운티 운영 방식까지 바꿔야 했어요.
그런데 흐름이 한쪽으로만 가지는 않았어요. 구글의 Big Sleep 프로젝트는 AI 에이전트로 SQLite의 실제 취약점을 찾아냈어요. 2025년에는 한 보안 연구자가 OpenAI의 o3 모델로 리눅스 커널 SMB 서버 구현(ksmbd)에서 제로데이 취약점을 찾아내기도 했고요. 최근 커널 메인테이너들 사이에서도 AI 도구가 찾아낸 리포트 중에 진짜 버그가 눈에 띄게 늘었다는 이야기가 나와요.
결국 LLM은 잡음 생성기이면서 강력한 버그 탐지기이기도 해요. 이 양면성이 LLM 시대 보안의 핵심이에요.
공격자 쪽에서 보면
더 무서운 건 공격 쪽의 변화예요. 예전에는 패치 커밋을 보고 어떤 취약점을 고친 건지 거꾸로 추적해서 공격 코드를 만들려면 숙련된 전문가가 꽤 오래 매달려야 했어요. 이 작업을 패치 디핑(patch diffing)이라고 불러요. 이제는 LLM이 수정 전후 코드를 비교해서 어떤 버그였는지 설명해주고, 재현 코드 초안까지 만들어주는 게 가능해지고 있어요.
그러면 패치가 공개된 뒤 실제 공격이 나오기까지 걸리는 시간이 점점 짧아져요. 그렉이 오래전부터 해온 최신 stable로 업데이트하라는 조언이 LLM 시대에 오히려 더 무게를 갖게 된 이유예요. 업데이트를 미루는 기간이 곧 공격에 노출되는 기간이니까요.
한국 개발자에게 주는 시사점
임베디드·IoT·안드로이드 기기를 만드는 회사가 가장 직접적인 영향을 받아요. 오래된 커널에 자체 패치를 잔뜩 얹어서 몇 년씩 쓰는 관행은 점점 위험해지고 있어요. CVE 개수에 흔들리기보다는 stable 업데이트를 정기적으로 반영할 수 있는 빌드·테스트 체계를 갖추는 게 근본적인 해법이에요.
유럽에 제품을 수출하는 팀이라면 EU 사이버 복원력법(CRA)도 같이 봐야 해요. CRA는 디지털 제품 제조사에 취약점 대응 의무를 지우는 법이에요. 실제로 악용되는 취약점을 보고할 의무는 2026년 9월부터 이미 적용되기 시작했고, 전면 시행은 2027년 12월이에요. 그렉도 이 법이 오픈소스와 제조사에 미칠 영향에 대해 꾸준히 의견을 내온 사람이에요.
오픈소스에 기여하는 개발자라면, AI로 찾은 버그는 반드시 직접 재현하고 검증한 다음에 신고해주세요. 검증 안 된 AI 리포트는 대부분 자원봉사로 일하는 메인테이너들의 시간을 갉아먹거든요.
마무리
LLM 때문에 버그를 찾는 속도와 공격하는 속도가 둘 다 빨라졌어요. 이런 상황에서 버티려면 결국 빠르게 업데이트할 수 있는 체계가 있어야 해요.
여러분 팀은 커널이나 오픈소스 라이브러리의 보안 업데이트를 얼마나 자주 반영하고 계세요? AI 코드 리뷰나 취약점 탐지 도구를 실무에서 써보셨다면 진짜 버그와 잡음이 어느 정도 비율이었는지도 나눠주세요.
🔗 출처: Hacker News