에이전트가 취약점을 발견할 때

Anthropic의 연구 과학자 Nicholas Carlini는 Claude Code을 Linux 커널 소스에 투입하고 취약점을 찾으라고 지시했어요. 구성은 간단했습니다: 10줄짜리 bash 스크립트와 ASAN 계측 빌드가 포함된 Docker 컨테이너. 소스 파일을 순회하며 모델에 버그를 찾으라고 요청하고 다음 파일로 넘어가는 방식이었습니다.¹³

Michael Lynch의 발표 정리 글에 따르면² 결과는 이랬습니다: NFSv4 LOCK 리플레이 캐시에서 원격 악용 가능한 힙 버퍼 오버플로우가 발견됐어요. 2003년 3월부터 존재했으니 Git보다도 오래된 취약점입니다. 두 NFS 클라이언트가 협력하면 1,024바이트 lock owner ID로 112바이트 버퍼를 오버플로우시켜 민감한 커널 메모리를 읽을 수 있었습니다. Carlini는 같은 스캔에서 최소 4개의 커널 취약점을 추가로 발견했어요. 별도로 같은 방법론을 적용해 Mozilla에 122건의 크래시 입력을 보냈고, 그중 22건이 CVE로 등록됐습니다.³ 그는 아직 검증하고 보고할 시간이 없는 “수백 건의 크래시”가 있다고 밝혔습니다.²

이 취약점들은 유지보수자에게 보고된 확인된 취약점이며, Opus 4.6을 사용하는 에이전트가 발견한 것입니다 — 실무자들이 매일 코드 리뷰, 리팩터링, 기능 개발에 사용하는 바로 그 모델 클래스예요. Carlini는 2026년 4월 [un]prompted AI 보안 컨퍼런스에서 이 결과를 발표했습니다.¹

요약

Carlini의 방법론은 최소한의 구성이었습니다: 소스 파일을 순회하고, Claude에 각 파일의 취약점을 찾으라고 프롬프트하고, ASAN 어설션으로 히트를 검증하는 방식이에요. Opus 4.6은 Opus 4.1(8개월 전 모델)이나 Sonnet 4.5(6개월 전 모델)보다 훨씬 많은 취약점을 발견했으며, 최근 능력 임계점을 넘었음을 시사합니다.² 병목은 이제 AI 발견이 아니라 사람의 검증에 있습니다. 이는 실무자들이 보안 훅을 구축하고, 코드 리뷰를 수행하고, 에이전트 기반 감사를 설계하는 방식에 직접적인 영향을 미칩니다.

핵심 포인트

• 보안 엔지니어: 이 능력은 실재하며 빠르게 향상되고 있어요. 에이전트 기반 코드 리뷰를 운영한다면, PreToolUse 보안 훅이 그 어느 때보다 중요합니다 — Claude을 차단하기 위해서가 아니라, 발견한 것을 어떻게 처리할지 제어하기 위해서예요.
• 하네스 빌더: 검증 병목(“수백 건의 크래시를 아직 검증하지 못했다”)은 하네스 문제입니다. 자동화된 분류, 중복 제거, 심각도 분류가 다음 인프라 레이어예요.
• 그 외 모든 분: 446배 성능 저하를 유발하는 바로 그 모델이 23년간 사람의 리뷰가 놓친 버그도 찾아냅니다. 두 가지 모두 동시에 사실이에요.

방법론

Carlini의 접근법에는 맞춤형 보안 프레임워크도, 파인튜닝된 모델도, 특수한 프롬프트도 필요하지 않았어요. 그는 이를 “10줄짜리 bash 스크립트와 Docker 컨테이너”라고 설명했습니다:³

1. 대상을 ASAN(AddressSanitizer) 계측으로 컴파일
2. 소스 파일을 순회하며 모델로 보안 관련성을 평가
3. 높은 관련성의 파일에 대해 캡처 더 플래그 프레이밍으로 Claude Code에 프롬프트
4. 대상당 여러 패스 실행(코드베이스에 따라 5~20회)
5. 자동화된 비평 에이전트로 공개 전 결과 검증

캡처 더 플래그 프레이밍이 중요합니다. 모델에게 “이 코드에 버그가 있다”고 말하면 “이 코드에 문제가 있는지 검토해라”와는 다른 모드가 활성화돼요. 개발자들도 일상 업무에서 같은 패턴을 경험합니다 — Claude은 문제가 있을 수 있는지 물을 때보다 문제가 있다고 말할 때 더 많은 문제를 발견합니다.²

스캔 비용은 사람-개월이 아니라 API 토큰으로 측정돼요. Carlini는 상용 에이전트 CLI를 사용해 5건의 확인된 Linux 커널 취약점과 22건의 Firefox CVE를 발견했습니다.³ 여러분의 유닛 테스트를 작성하고 임포트를 정리하는 바로 그 도구입니다.

능력 임계점

가장 주목할 만한 발견은 모델 세대 간 격차예요. Carlini는 이전 모델로 결과를 재현하려 했습니다:²

• Opus 4.6 (발표 약 2개월 전 출시): 힙 오버플로우와 다수의 추가 취약점 발견
• Opus 4.1 (8개월 전): 극소수만 발견
• Sonnet 4.5 (6개월 전): 극소수만 발견

모델 세대 간에 어떤 임계점이 돌파됐어요. 복잡한 코드베이스를 컨텍스트에 유지하고, 함수 경계를 넘나드는 데이터 흐름을 추론하며, 미묘한 명세 불일치를 식별하는 능력이 점진적으로 개선된 것이 아니라 갑자기 출현한 것으로 보입니다.

Carlini는 이렇게 말했어요: “저는 이런 취약점을 직접 찾아본 적이 한 번도 없습니다. 이건 정말, 정말, 정말 어려운 일이에요. 이 언어 모델들을 쓰니 여러 건을 찾았습니다.”²

역설

성능 저하를 유발하는 바로 그 에이전트 아키텍처가 — 3배에서 446배 느려지는 함수 118개 — 수십 년간 전문가의 리뷰가 놓친 보안 취약점도 찾아냅니다. 이것은 같은 능력 프로필의 상호 보완적인 측면이에요. 취약점 연구는 근본적으로 알려진 클래스(버퍼 오버플로우, use-after-free, 정수 부호 문제)에 대한 패턴 매칭이며, 이는 LLM의 강점입니다.⁴ 성능 최적화는 그 반대를 요구해요: 특정 실행 컨텍스트, 캐시 동작, 알고리즘 복잡도에 대한 추론이 필요합니다. 모델은 수백만 줄의 코드에서 버퍼 오버플로우를 인식하지만, 여러분의 접근 패턴에서 해시 맵이 정렬된 배열보다 느리다는 것은 알려주지 못해요. 하네스를 그에 맞게 설계하세요 — 결과를 플래그하는 보안 훅, 커밋 전에 측정하는 성능 훅.

검증 병목

Carlini의 가장 의미심장한 고백이 있어요: “Linux 커널에 너무 많은 버그를 찾았는데 아직 검증하지 못해서 보고할 수 없습니다.”²

병목이 발견에서 분류로 이동했습니다. 잠재적 취약점을 찾는 것이 이제 그것이 실재하는지 확인하는 것보다 저렴해요. 이는 보안 팀에 새로운 인프라 문제를 만들어냅니다:

발견은 자동화됐어요. 에이전트가 코드베이스를 몇 시간 만에 스캔할 수 있습니다.

검증은 수동이에요. 각 잠재적 취약점에 개념 증명, 영향 평가, 책임 있는 공개 프로세스가 필요합니다.

분류가 공백이에요. 수백 건의 에이전트 생성 결과를 실제 취약점, 오탐, 저위험 노이즈로 분류하는 작업에는 아직 좋은 도구가 없습니다.

이것은 에이전트 기반 코드 리뷰에서 보는 것과 같은 패턴이에요: 에이전트가 사람이 평가할 수 있는 속도보다 빠르게 원시 출력을 생성합니다. 가치는 생성에 있는 것이 아니라 — 출력을 처리하고, 필터링하고, 라우팅하는 인프라에 있어요.

하네스 빌더에게 이는 다음 고가치 훅이 보안 스캐너가 아니라는 뜻이에요. 보안 분류 시스템이 필요합니다: 중복 제거, 심각도 분류, 오탐 필터링, 자동 개념 증명 생성. 에이전트 출력을 제어하는 거버넌스 훅이 스캐닝 기능 자체보다 더 중요합니다.

실무자를 위한 시사점

프로덕션 코드베이스에서 Claude Code을 실행하고 있다면, 이미 실제 취약점을 찾을 수 있는 시스템을 운영하고 있는 것이에요. 문제는 능력의 존재 여부가 아니라 — 에이전트가 발견한 것을 처리할 수 있도록 하네스가 설계되어 있느냐입니다.

세 가지 실질적인 조치:

리뷰 파이프라인에 보안 스캔을 추가하세요. Write/Edit에 대한 PostToolUse 훅으로 변경된 파일에 대상 보안 스캔을 트리거할 수 있어요. 훅은 stdin에서 파일 경로를 읽습니다(Claude Code은 이벤트 JSON을 stdin으로 훅에 전달합니다):

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking — runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

이것은 시작점이지 프로덕션용이 아닙니다 — 중복 제거, 심각도 필터링, 속도 제한을 추가해야 해요. 하지만 핵심 패턴은 Carlini의 방법론과 일치합니다: 대상 프롬프트로 파일을 순회하는 루프.³

분류 인프라를 구축하세요. 심각도 분류 없는 원시 취약점 결과는 노이즈예요. 에이전트가 스캔당 50건의 결과를 생성한다면, 사람이 목록을 보기 전에 자동화된 중복 제거와 우선순위 점수가 필요합니다. 이것은 모델 문제가 아니라 하네스 문제예요.

역설을 받아들이세요. 성능 가드레일이 필요한 바로 그 모델이 보안 패턴 매칭에서는 진정으로 뛰어나요. 강점을 활용하고 약점을 보완하도록 하네스를 설계하세요. 스캔하는 보안 훅. 측정하는 성능 훅. 검증하는 품질 훅. 각각이 다른 것들이 놓치는 부분을 커버합니다.

23년 된 Linux 취약점은 숨어있지 않았어요. 수천 명의 엔지니어가 읽은 파일에 그대로 있었습니다. 모델이 찾은 이유는 대규모 패턴 매칭이 바로 이 시스템들이 하는 일이기 때문이에요. 교훈은 에이전트가 보안에서 사람보다 뛰어나다는 것이 아닙니다. 교훈은 에이전트가 다른 표면을 커버한다는 것이며 — 양쪽을 조율하는 하네스가 그 조합을 신뢰할 수 있게 만든다는 것이에요.

출처

자주 묻는 질문

Claude Code으로 Carlini의 접근법을 재현할 수 있나요?

방법론은 팟캐스트 인터뷰에 문서화되어 있어요.³ 핵심 루프: ASAN으로 컴파일하고, 소스 파일을 순회하고, 캡처 더 플래그 프레이밍으로 Claude에 프롬프트하고, 히트를 검증합니다. Carlini는 Opus 4.6이 이전 모델보다 훨씬 많은 취약점을 발견했다고 보고했으며 — 다른 모델 세대의 결과는 다를 수 있어요.

AI 에이전트가 보안 버그 발견에서 사람보다 뛰어난 건가요?

아닙니다. 에이전트가 다른 표면을 커버한다는 의미예요. 에이전트는 대규모 코드베이스에서 알려진 취약점 클래스에 대한 패턴 매칭에 뛰어나요. 사람은 새로운 공격 벡터, 비즈니스 로직 결함, 컨텍스트 의존적 보안 속성을 이해하는 데 뛰어납니다. 두 가지의 조합이 어느 한쪽보다 강력해요.

공격자가 이 능력을 사용하는 것에 대해 걱정해야 하나요?

Carlini는 “큰 파도가 오고 있다”고 명시적으로 경고했어요. 방어자가 취약점을 찾는 데 도움이 되는 바로 그 능력을 공격자도 사용할 수 있습니다. 비대칭성이 있다면, 방어자는 분류와 패치를 자동화할 수 있는 반면 공격자는 여전히 익스플로잇을 개발해야 한다는 것이지만 — 발견 격차는 좁아지고 있어요.