2003년 3월, 누군가가 리눅스 커널에 코드 한 줄을 커밋했어요. Git도 없던 시절이에요. 그 코드는 23년 동안 수천 명의 커널 개발자, 수십 개의 퍼징 도구, 무수한 정적 분석을 전부 통과하며 조용히 살아남았거든요.
2026년, Anthropic의 연구 과학자 Nicholas Carlini가 Claude Code에게 리눅스 커널 소스를 던져주고 이렇게 물었습니다. “보안 취약점 어디 있어?”
그리고 Claude가 진짜 찾아냈어요.
23년 묵은 버그의 정체
문제는 리눅스의 NFS(Network File System) 드라이버에 있었어요. NFS는 네트워크를 통해 파일 시스템을 공유하는 프로토콜인데, 이 프로토콜의 파일 잠금(lock) 처리 로직에 힙 오버플로우가 숨어 있었습니다.
공격 시나리오는 이렇습니다.
두 대의 NFS 클라이언트가 협력해요. 클라이언트 A가 파일 잠금을 요청하면서 owner ID를 1,024바이트로 설정합니다. NFS 프로토콜상 완전히 합법적인 크기예요. 그다음 클라이언트 B가 같은 파일에 잠금을 요청하면, 서버는 “이미 A가 잠갔으니 안 돼”라는 거부 응답을 생성하죠.
여기서 터지는 거예요.
거부 응답에는 기존 잠금의 owner ID가 포함되는데, 서버가 이 응답을 쓰는 버퍼는 고작 112바이트입니다. 1,024바이트짜리 owner ID를 112바이트 버퍼에 쓰면? 나머지 912바이트가 커널 메모리를 덮어씁니다. 공격자가 원격에서 커널 메모리를 읽을 수 있게 되는 거예요.
‘이게 왜 23년 동안 안 잡혔지?’ 싶잖아요. 이유가 있어요.
이 버그를 발견하려면 NFS 프로토콜의 잠금 메커니즘, owner ID의 가변 길이 규격, 서버 측 응답 버퍼 크기 — 이 세 가지를 동시에 이해해야 합니다. 기존 퍼징 도구는 프로토콜 수준의 의미를 이해하지 못하고, 정적 분석 도구는 프로토콜 규격과 구현 사이의 불일치를 잡아내지 못했어요. 인간 리뷰어도 마찬가지였죠. 각각의 코드 조각만 보면 전부 정상이거든요.
Claude는 어떻게 찾았나
Carlini의 방법은 놀라울 정도로 단순했어요.
커널 소스 파일을 하나씩 순회하는 스크립트를 만들고, Claude Code에게 각 파일을 보면서 보안 취약점을 찾으라고 시켰습니다. 특별한 힌트도, 공격 시나리오 시나리오 가이드도 없었어요. 그냥 “여기 취약점 있어?”라고 물었을 뿐이에요.
근데 Claude Opus 4.6이 해낸 건, 코드를 단순히 패턴 매칭한 게 아니에요. NFS 프로토콜의 의미를 이해한 거예요. owner ID가 가변 길이라는 프로토콜 규격을 알고, 서버 응답 버퍼 크기와 비교해서 오버플로우 가능성을 추론했습니다. Claude가 직접 작성한 버그 리포트에는 공격 체인을 설명하는 ASCII 다이어그램까지 포함되어 있었거든요.
여기서 재밌는 건 모델 간 차이예요. Carlini가 같은 실험을 이전 모델로도 돌려봤는데, 8개월 전에 나온 Opus 4.1이나 6개월 전의 Sonnet 4.5는 이 취약점을 찾지 못했습니다. Opus 4.6만이 프로토콜 수준의 추론을 해낸 거예요.
몇 달 사이에 이 정도 격차라니. 솔직히 좀 무섭더라고요.
이게 끝이 아니었다
NFS 버그는 시작일 뿐이었어요. Carlini가 Claude Code로 발견한 리눅스 커널 취약점만 5개예요. NFS 힙 오버플로우 외에도 io_uring의 out-of-bounds read, ksmbd SMB 서버 구현의 버그 2건이 커널 메인테이너에게 보고되거나 이미 수정됐습니다.
근데 더 큰 그림이 있어요.
Anthropic은 Opus 4.6으로 오픈소스 소프트웨어 전반에서 500개 이상의 고위험 제로데이 취약점을 발견했다고 밝혔습니다. 500개요. Firefox에서만 2주 만에 22개를 찾았는데, 그중 14개가 고위험(high-severity)으로 분류됐어요. 이게 어느 정도냐면, 2025년 한 해 동안 패치된 Firefox 고위험 버그의 약 20%에 해당하는 수치입니다.
Mozilla는 이 결과를 검증하고 Firefox 148에 수정 사항을 반영했어요. Anthropic과 Mozilla가 공식 파트너십까지 맺었습니다.
FreeBSD 커널에서는 아예 원격 커널 익스플로잇(RCE)을 작성하기까지 했고, Vim과 Emacs 같은 베테랑 프로젝트에서도 취약점이 나왔어요.
90분, 라이브 데모에서 벌어진 일
2026년 3월, 샌프란시스코에서 열린 [un]prompted AI 보안 컨퍼런스. Carlini가 무대에서 라이브 데모를 했습니다.
타겟은 Ghost CMS였어요. GitHub 스타 5만 개짜리 오픈소스 퍼블리싱 플랫폼인데, 역사상 단 한 번도 크리티컬 보안 취약점이 보고된 적이 없는 프로젝트예요.
Carlini가 터미널을 열고 Claude를 풀어놨습니다. 90분 뒤, Claude는 Ghost의 Content API에서 블라인드 SQL 인젝션을 독립적으로 발견하고 익스플로잇까지 완료했어요. 인증 없이 관리자 데이터베이스를 뚫고, 새 어드민 계정을 만들어 전체 시스템을 장악하는 시나리오까지요.
청중석이 조용해졌다고 해요.
같은 세션에서 리눅스 커널의 NFSv4 데몬에서도 스택 버퍼 오버플로우를 찾아냈습니다. 앞서 설명한 23년 묵은 그 버그예요.
‘이걸 사람한테 시키면 얼마나 걸릴까?’ — 아마 보안 전문가 한 명이 몇 주에서 몇 달은 매달려야 할 작업이에요. 그걸 90분 만에, 라이브로.
보안 업계의 온도차
이 소식에 보안 업계는 둘로 나뉘었어요.
방어 측 연구자들은 흥분했습니다. 오픈소스 프로젝트 대부분은 소규모 팀이나 자원봉사자가 유지보수하잖아요. 전담 보안 인력이 없는 프로젝트가 대부분인데, AI가 그 갭을 메울 수 있다는 거예요. Anthropic도 “오픈소스부터 시작하는 이유가 바로 이것”이라고 밝혔고요.
근데 불편한 진실도 있어요.
보안 연구자 Guy Arazi는 꽤 날카로운 지적을 했습니다. “500개 취약점을 찾았다고 했는데, 실제로 수정된 건 2~3개뿐이다. 수정 안 됐다는 건 제대로 된 게 아니라는 뜻”이라고요. 발견 속도는 폭발적으로 빨라졌는데, 패치는 여전히 사람이 해야 하거든요. 발견과 수정 사이의 격차가 벌어지는 거예요.
Kevin Mandia, Alex Stamos 같은 업계 거물들은 더 근본적인 우려를 내놨어요. AI가 취약점을 찾는 능력이 이 속도로 발전하면, 같은 기술을 공격자도 쓸 수 있다는 거예요. 방어자에게는 조직, 협의, 패치 배포라는 절차가 있지만, 공격자에게는 그런 제약이 없잖아요.
Anthropic 스스로도 이 점을 인정했습니다. “프론티어 모델의 취약점 발견 능력과 익스플로잇 작성 능력 사이의 격차가 오래 유지될 것 같지 않다”고 경고했어요.
그래서 이게 왜 중요한가
솔직히 말하면, AI가 코드에서 버그를 찾는다는 것 자체는 새로운 이야기가 아니에요. 정적 분석 도구는 수십 년 전부터 있었고, 퍼징도 구글의 OSS-Fuzz가 수만 개의 버그를 찾아왔잖아요.
근데 이번 건 질적으로 달라요.
기존 도구는 패턴을 찾습니다. “버퍼 크기보다 큰 값을 쓰는 코드”를 탐지하는 식이죠. Claude가 한 건 프로토콜의 의미를 이해한 거예요. owner ID가 1,024바이트까지 가능하다는 프로토콜 규격을 알고, 그걸 처리하는 서버 코드의 버퍼가 112바이트라는 걸 연결해서 추론한 거거든요. 이건 코드 검색이 아니라 코드 이해예요.
Claude Code의 다른 기능이 궁금하다면, 코딩 도구로서의 면모도 상당합니다. 하지만 보안 연구 도구로서 보여준 이번 성과는 차원이 다르더라고요.
여기서 한 가지 생각해볼 게 있어요. AI 보안 연구의 현실적인 병목은 발견이 아니라 대응입니다. 500개를 찾아도 패치할 인력이 없으면 오히려 위험해지거든요. 취약점 정보가 쌓이는 속도가 수정 속도를 앞지르면, 그 정보는 방패가 아니라 공격 카탈로그가 됩니다.
업계 표준인 90일 공개 기한(disclosure window)도 재검토가 필요하다는 목소리가 나오고 있어요. AI가 하루에 수백 개를 찾는 시대에 90일이라는 숫자가 아직 유효한지 — 이건 기술 문제가 아니라 거버넌스 문제예요.
AI가 보안을 바꾸는 속도
Anthropic의 METR 벤치마크 데이터에 따르면, AI의 복잡한 자율 작업 수행 능력은 지수적으로 성장하고 있어요. 취약점 연구는 정확히 그 “복잡한 자율 작업”에 해당하고요.
8개월 전 모델은 못 찾던 걸, 지금 모델은 찾습니다. 6개월 뒤에는 또 어떤 게 가능해질지 모르겠어요.
확실한 건 하나 있어요. 23년 동안 모든 인간과 모든 도구를 피해 살아남았던 버그가 AI한테는 잡혔다는 것. 이건 단순한 기술 데모가 아니라, AI 코딩 도구의 역할이 코드 작성에서 코드 보안까지 확장되고 있다는 신호예요.
보안 연구의 판이 바뀌고 있습니다. 그 속도가 생각보다 빠를 뿐이에요.