8월 1일 OpenAI의 Astra가 10년 넘게 풀리지 않던 수학 난제 10개를 2,000달러로 풀었습니다. 6일 뒤 같은 모델이 '사람 없이 제로데이를 만들 수 있다'는 이유로 격리됐습니다. 그리고 8월 20일, 2억 4천만 번 다운로드된 Rust 크레이트가 86분간 악성 코드를 배포했습니다. 이 세 사건은 하나의 이야기입니다 — 1988년 모리스 웜부터 시작된 '기계가 취약점을 찾는다'는 계보가 어디까지 왔고, 왜 지금 저울이 기울고 있는지 끝까지 추적합니다.
2026년 8월, 세 개의 뉴스가 따로 지나갔습니다.
8월 1일. OpenAI가 차기 모델 Astra의 내부 버전이 10년 이상 미해결이던 수학·이론전산 문제 10개를 풀었다고 발표했습니다. 미하일 그로모프가 1999년 소픽(sofic) 개념을 제시한 이래 열려 있던 비(非)소픽 군의 최초 명시적 구성, 콘의 강직성 추측 반증, 에르되시 문제 3개. 전부 기계가 검증할 수 있는 Lean 인증서를 달고 나왔습니다. 총 연산 비용은 약 2,000달러였습니다.
8월 7일. 같은 회사가 Astra의 내부 개발을 일시 중단한다고 밝혔습니다. 이유는 이렇습니다 — 이 모델이 사람의 지시 없이 스스로 제로데이를 찾아 익스플로잇을 개발할 수 있는 수준, 즉 자사 Preparedness Framework의 '심각(Critical)' 사이버 임계에 도달했을 가능성을 배제할 수 없다는 것.
8월 20일. 러스트 생태계에서 2억 4,500만 번 다운로드된 크레이트 arrayref의 악성 버전이 crates.io에 올라왔습니다. 빌드 스크립트가 컴파일 도중 원격 바이너리를 받아 실행했습니다. 86분 만에 내려갔지만, 그 사이 cargo build를 돌린 사람은 이미 당한 뒤였습니다.
세 사건은 서로 다른 뉴스처럼 보입니다. 그런데 그 사이에 이런 사실이 하나 더 공개됐습니다. 마이크로소프트 SharePoint를 계정 없이 관리자로 진입할 수 있게 하는 취약점 체인을 Rapid7이 찾아냈는데, 그 작업의 상당 부분이 AI 에이전트로 수행됐고 규모가 이랬습니다.
24일간 · 96개 세션 · 256개 프롬프트 · 약 80,000회의 에이전트 도구 호출
이 글은 이 네 조각을 하나로 꿰맵니다. 다루는 것은 이렇습니다.
미리 결론 한 줄을 놓고 가겠습니다. AI는 취약점 '발견'을 싸게 만들었지만, '대응'은 여전히 사람과 조직의 속도로 움직입니다. 위험의 실체는 능력이 아니라 그 격차입니다.
먼저 Astra가 무엇을 했는지부터 정확히 봅시다. 이 대목을 건너뛰면 8월 7일의 조치가 과잉으로 보입니다.
| 성과 | 내용 | 의미 |
|---|---|---|
| 비소픽 군의 최초 구성 | 1999년 그로모프가 소픽 개념을 도입한 이래 "소픽하지 않은 군이 존재하는가"는 군론의 열린 질문이었다 | 존재 증명이 아니라 명시적 구성이다 |
| 콘의 강직성 추측 반증 | 작용소 대수의 오래된 추측 | 반례를 찾아냈다 |
| 에르되시 문제 3개 해결 | 에르되시 문제 목록의 미해결 항목 | 목록 관리자 토머스 블룸이 "큰 뉴스"라 평가 |
| 단위거리 추측 반증(5월) | 1946년 이래 80년간 버틴 이산기하 문제 | 필즈상 수상자 팀 가워스가 "주저 없이 최고 저널에 추천했을 것"이라 평했고, 이후 가워스·노가 알론 등 수학자 9명이 그 증명을 사람이 따라가기 쉽게 풀어쓴 해설 논문을 냈다 |
| 전부 Lean 인증서 첨부 | 기계 검증 가능한 형식 증명이 함께 나왔다 | "진짜인가"를 사람이 믿어줄 필요가 없다 |
마지막 줄이 중요합니다. 검증이 기계화되어 있으면 "AI가 헛소리를 그럴듯하게 했다"는 반론이 성립하지 않습니다. 그리고 이 사실은 3부에서 "왜 AI가 보안 연구를 잘하는가"의 핵심 단서가 됩니다.
6일 뒤, OpenAI는 Astra의 일부 내부 작업을 멈췄습니다. 내부 평가에서 이 시스템이 예상보다 훨씬 더 사이버 보안 과제에 능숙하다는 것이 드러났기 때문입니다.
OpenAI의 Preparedness Framework에서 사이버 영역의 '심각(Critical)' 등급은 이렇게 정의됩니다.
실제 시스템에서 사람의 지시 없이 스스로 심각한 소프트웨어 취약점을 찾아 익스플로잇하거나, 강하게 방어된 표적에 정교한 사이버 공격을 수행할 수 있는 능력.
OpenAI는 Astra가 이 임계에 도달했다고 단정하지 않았습니다. 표현은 "배제할 수 없다(cannot rule out)"였습니다. 그리고 그 불확실성만으로 다음 조치들이 취해졌습니다.
제품 취소가 아니라 안전장치를 갖출 때까지의 의도적 보류라는 점도 분명히 해둡니다. 그럼에도 이것은 프론티어 랩이 자기 프레임워크 때문에 실물 비용(출시 지연)을 지불한 첫 사례입니다.
같은 기간, 이론이 아니라 실제 공격에서 벌어진 일들입니다.
| 날짜 | 사건 | 숫자 |
|---|---|---|
| 2026.1 · 3월 | Rapid7 Labs가 두 차례 스프린트로 SharePoint를 연구. 상당 부분을 에이전트가 수행 | 24 활동일 · 96세션 · 256프롬프트 · 약 80,000회 도구 호출 |
| 8.11 | 체인의 두 번째 고리 CVE-2026-63520 공개 (SharePoint BCS의 안전하지 않은 .NET 타입 인스턴스화) | CVSS 8.1 |
| 8월 중 | CVE-2026-55040 — 원격 미인증 공격자가 임의 사용자(관리자 포함)의 신원을 가질 수 있는 인증 우회. 위 RCE와 엮으면 미인증 원격 코드 실행 | CVSS 9.1 |
| PoC 공개 직후 | 공개된 PoC를 이용한 실제 공격 관측, KEV 등재 | 공개 후 약 24시간 |
| 8.20 | crates.io 공급망 공격 — 아래에서 자세히 | 86 / 90 / 107분 |
이 사건은 별도로 뜯어볼 가치가 있습니다. 왜냐하면 AI와 무관해 보이지만 실은 같은 이야기의 다른 얼굴이기 때문입니다.
무슨 일이 있었나:
| 항목 | 내용 |
|---|---|
| 침해된 계정 | 러스트 커뮤니티에서 BurntSushi로 알려진 앤드루 갤런트. ripgrep의 저자이며 널리 쓰이는 크레이트를 다수 관리한다. 러스트 보안 대응팀은 본인의 악의가 아니라 계정·기기 침해로 판단했다. |
| 악성 배포본 | arrayref@0.3.10, internment@0.8.7, append-only-vec@0.1.9 |
| 수법 | 타이포스쿼트 의존성 proc-macro1을 추가. 그 크레이트의 build.rs가 base64로 숨긴 주소를 복원해 TLS 인증서 검증 없이 2단계 바이너리를 내려받아 컴파일 도중 실행했다. |
| 결정적 신호 | proc-macro1은 arrayref 10년 역사상 처음 추가된 의존성이었다 |
| 노출 규모 | arrayref 누적 다운로드 2억 4,500만회(최근 90일 5,370만), 이를 의존하는 크레이트 403개. 러스트가 설치된 환경의 약 3/4에서 발견된다. |
| 대응 속도 | 각각 86분 · 90분 · 107분 만에 삭제 |
| 배후 | Wiz는 이 캠페인이 북한 연계 활동과 상당 부분 겹친다고 분석했다 |
86분은 훌륭한 대응 속도입니다. 러스트 보안팀은 잘했습니다. 그런데도 이 사건이 무서운 이유는 따로 있습니다.
의존성을 설치하는 행위 자체가 곧 코드 실행입니다. 러스트의
build.rs, npm의postinstall, 파이썬의setup.py가 전부 그렇습니다. 여러분이cargo build를 누르는 순간, 의존성 트리 어딘가의 남의 코드가 여러분의 기계에서 돕니다. 리뷰 없이, 승인 없이.
그 86분 안에 CI가 돌았다면, 그 CI에 있던 토큰은 이미 나갔습니다.
"기계가 스스로 취약점을 찾는다"는 아이디어는 2026년에 생긴 게 아닙니다. 40년 가까이 단계적으로 쌓여 온 계보가 있고, 각 단계가 무엇을 못 했는지를 알아야 지금이 왜 다른지 보입니다.
코넬 대학원생 로버트 모리스가 만든 웜이 인터넷에 연결된 컴퓨터의 상당수를 마비시켰습니다. 의도는 규모 측정이었지만 결과는 최초의 대규모 인터넷 사고였습니다. 여기서 확립된 것은 하나입니다 — 공격은 자동화될 수 있다. 사람이 한 대씩 손으로 뚫지 않아도 됩니다.
바턴 밀러 연구팀이 유닉스 유틸리티에 무작위 입력을 쏟아부었더니 상당수가 크래시했습니다. 퍼징(fuzzing)의 탄생입니다. 이후 AFL, libFuzzer, OSS-Fuzz로 이어지며 대규모 자동 발견의 주력이 됩니다.
퍼징의 강점과 한계는 명확합니다.
| 퍼징이 잘하는 것 | 퍼징이 못하는 것 |
|---|---|
| 메모리 안전성 버그 — 크래시가 곧 신호다 | 크래시하지 않는 취약점 — 인증 우회, 권한 상승, 로직 결함 |
| 대량 반복. 사람의 도메인 지식이 필요 없다 | 코드의 의미를 이해하지 못한다 |
| 회귀 방지에 탁월 | "이 토큰 검증 함수가 무엇을 빠뜨렸나"는 물을 수 없다 |
이 오른쪽 칸이 35년간 사람 연구자의 영역으로 남아 있었습니다. 그리고 SharePoint의 CVE-2026-55040이 정확히 오른쪽 칸에 속하는 취약점입니다.
DEF CON 24에서 기계 7대가 서로의 소프트웨어에서 취약점을 찾고, 익스플로잇을 만들고, 패치까지 자동으로 수행하는 대회가 열렸습니다. Mayhem이 우승했습니다. "기계가 스스로 찾고 고친다"의 첫 공개 증명입니다.
다만 한계도 분명했습니다. 단순화된 환경, 특수 제작된 바이너리, 메모리 안전성 버그 중심. 현실의 수백만 줄 코드베이스와는 거리가 있었습니다.
구글 딥마인드와 프로젝트 제로가 만든 LLM 에이전트 Big Sleep이 SQLite에서 실제 취약점을 찾아냈습니다. 구글은 이것을 "AI 에이전트가 실제 소프트웨어에서 발견한 최초의 취약점"이라고 주장했습니다.
중요한 것은 종류입니다. 이미 OSS-Fuzz가 SQLite를 오랫동안 퍼징하고 있었는데도 남아 있던 버그였습니다.
더 결정적인 사건은 그다음이었습니다. Big Sleep이 SQLite에서 CVE-2025-6965를 찾아냈는데, 구글의 설명에 따르면 이 취약점은 "위협 행위자만 알고 있었고 악용 위험에 처해 있던" 것이었습니다.
"우리가 아는 한, AI 에이전트가 실제 악용 시도를 직접 저지한 최초의 사례입니다."
방어 쪽이 처음으로 선제 점수를 낸 순간입니다. 이 사실은 4부의 균형 논의에서 다시 나옵니다.
2016년 CGC의 직계 후속인 DARPA AI 사이버 챌린지(AIxCC) 결승이 DEF CON 33에서 끝났습니다. 일곱 팀이 LLM을 결합한 사이버 추론 시스템(CRS)으로 오픈소스의 취약점을 자동으로 찾고 패치했습니다.
한 해 만에 발견율이 37%에서 86%로, 패치율이 25%에서 68%로 올랐습니다. 그리고 합성 문제만 푼 게 아닙니다. 결승에서 실제(비합성) 취약점 18건(C 6건, 자바 12건)을 찾아냈고 그중 11건에 패치를 제출했습니다.
우승은 조지아텍·KAIST·POSTECH·삼성리서치 연합인 Team Atlanta(ATLANTIS, 400만 달러), 2위 Trail of Bits(Buttercup, 300만 달러), 3위 Theori(150만 달러)였습니다. 한국 연구진이 1·3위에 있다는 점은 기억해 둘 만합니다.
그리고 결정적으로, 결승 진출 시스템은 전부 오픈소스로 공개됐습니다. 5부에서 이걸 어떻게 쓸지 이야기합니다.
같은 해 9월, 중국 국가 연계로 지목된 그룹(GTG-1002)이 Claude Code를 탈옥해 다단계 침투의 80~90%를 자동화한 캠페인이 적발됐습니다. 정찰, 취약점 발견, 익스플로잇, 자격증명 수집, 데이터 반출까지 AI가 수행했고, 표적은 약 30곳이었습니다. 사람은 전략적 결정 지점에만 개입했습니다.
우회 방법이 인상적입니다. "우리는 인가된 방어 테스트를 하는 중"이라고 AI를 사회공학적으로 설득했습니다.
| 시기 | 누가 자동화됐나 | 한계 |
|---|---|---|
| 1988 | 확산(공격) | 발견은 사람이 |
| 1990~ | 발견(퍼징) | 크래시하는 버그만 |
| 2016 CGC | 발견+패치 | 장난감 환경 |
| 2024 Big Sleep | 의미 이해 기반 발견 | 사례 단위 |
| 2025 AIxCC | 실제 코드에서 발견+패치, 규모 확보 | 대회 조건 |
| 2025 GTG-1002 | 침투 전 과정(공격) | 탈옥 필요 |
| 2026.8 | Rapid7: 실제 엔터프라이즈 제품에서 논리 취약점 체인 발견 Astra: 지시 없이 가능할지도 모른다는 판정 | — |
계보의 각 칸이 하나씩 채워지다가, 2026년 8월에 마지막 칸의 '한계' 열이 비었습니다.
여기서 기술적인 질문에 답해야 합니다. 35년간 퍼징이 못 하던 것을 LLM 에이전트는 왜 하는가?
퍼저의 세계관에서 "취약점"은 프로그램이 죽는 것입니다. 그래서 죽지 않는 취약점은 존재하지 않는 것과 같습니다.
LLM 에이전트는 코드를 읽습니다. JWT 토큰 검증 함수를 보고 "서명은 확인하는데 발급자는 확인하지 않는군"이라고 추론할 수 있습니다. 이건 입력을 무작위로 흔들어서는 절대 나오지 않는 발견입니다.
SharePoint의 CVE-2026-55040(인증 우회, CVSS 9.1)이 정확히 이 유형입니다. 어떤 입력을 넣어도 프로그램은 죽지 않습니다. 다만 당신을 관리자로 인정할 뿐입니다.
Rapid7의 숫자를 다시 봅시다. 약 80,000회의 도구 호출.
취약점 연구의 본질은 99%의 헛수고와 1%의 발견입니다. 코드를 읽고, 가설을 세우고, 시도하고, 틀리고, 다시 읽습니다. 사람 연구자에게 이 헛수고는 비싸고 지칩니다. 그래서 대부분의 연구는 "여기까지"에서 멈춥니다.
에이전트에게 헛수고는 토큰 비용입니다. 멈추는 지점이 인내심이 아니라 예산으로 결정됩니다.
이것이 이 사건들의 가장 중요한 기술적 함의입니다. 모델이 사람 연구자보다 똑똑해서가 아닙니다. 덜 똑똑해도 1,000배 더 오래 붙어 있을 수 있으면 결과가 뒤집힙니다.
이 블로그에서 에이전트에게 맡겨도 되는 작업의 다섯 조건을 다룬 적이 있습니다. 첫 번째 조건이 "결과가 맞는지 기계가 판정할 수 있는가"였습니다.
보안 연구는 이 조건을 완벽하게 만족합니다.
| 조건 | 취약점 헌팅에서 |
|---|---|
| 검증 함수 | 익스플로잇이 동작하면 참이다. 논쟁의 여지가 없다. |
| 정답의 명확성 | "셸을 얻었는가"는 예/아니오다 |
| 반복성 | 수천 개의 함수, 수만 개의 입력 경로 |
| 되돌리기 비용 | 테스트 환경에서 실패는 공짜다 |
| 사람의 위치 | 연구자가 가설의 방향과 루프를 설계한다 |
같은 이유로 Astra의 수학 성과도 설명됩니다. Lean 인증서가 검증 함수입니다. 증명이 통과하면 참이고, 안 되면 거짓입니다. 사람의 승인이 필요 없습니다.
핵심: AI가 뛰어난 영역은 "어려운 영역"이 아니라 "기계가 정답을 채점할 수 있는 영역"입니다. 수학 증명과 익스플로잇 개발은 이 기준에서 같은 종류의 문제입니다. 그래서 8월 1일과 8월 7일은 같은 능력의 두 얼굴입니다.
AIxCC 결승 시스템들이 보여준 구조는 순수 LLM도 순수 퍼저도 아닙니다.
각 부품의 약점을 다른 부품이 덮습니다. LLM은 환각하지만 퍼저가 거릅니다. 퍼저는 의미를 모르지만 LLM이 겨냥해 줍니다. 이 조합이 발견율을 한 해 만에 37%에서 86%로 끌어올린 구조입니다.
과장하지 않기 위해 반대쪽도 적어 둡니다. 2026년 8월 기준으로 자동화가 아직 못 하거나 잘 못하는 영역이 분명히 있습니다.
| 한계 | 내용 |
|---|---|
| 완전하지 않다 | AIxCC 결승의 발견율은 86%지 100%가 아니다. 그리고 찾은 것 중 68%만 패치했다. 나머지는 사람이 해야 한다. |
| 대회 조건이었다 | "이 코드베이스에 취약점이 있다"는 전제가 주어진 상태였다. 실무의 신호 대 잡음비는 훨씬 나쁘고, 오탐 홍수가 현실의 첫 번째 장벽이다. |
| 패치가 기능을 깨뜨린다 | 자동 패치의 채점 기준은 "기존 테스트 통과"다. 테스트가 부실한 코드베이스에서는 통과해도 깨진다. 테스트 커버리지가 자동 패치의 전제 조건이다. |
| 비즈니스 로직은 여전히 어렵다 | "이 할인 쿠폰을 두 번 쓸 수 있다"는 취약점은 코드만 봐서는 판단할 수 없다. 코드 바깥의 의도를 알아야 한다. |
| 분산 상태 취약점 | 여러 서비스에 걸친 경합·순서 의존 결함은 한 저장소를 읽어서 나오지 않는다 |
| 공짜가 아니다 | 80,000회 도구 호출에는 실제 비용이 든다. 다만 숙련 연구자 24일보다 싸다면 경제성은 이미 넘어섰다는 뜻이기도 하다. |
즉 지금의 상태는 "AI가 사람 연구자를 대체했다"가 아니라 "사람 연구자 한 명이 감당하는 범위가 수십 배로 늘었다"입니다. 그리고 그건 공격자 쪽에서도 똑같이 일어났습니다.
이제 진짜 질문입니다. AI는 공격자와 방어자 중 누구에게 더 유리한가?
| 방어가 유리하다는 논거 | 공격이 유리하다는 논거 |
|---|---|
| 방어자는 소스 코드를 가지고 있다. AI에게 훨씬 유리한 조건. | 방어자는 전부 막아야 하고 공격자는 하나만 뚫으면 된다. 비대칭은 그대로. |
| Big Sleep처럼 악용 전에 선제 차단이 가능해졌다 | 진입 장벽이 무너졌다. 숙련 연구자만 하던 일을 예산만 있으면 한다. |
| AIxCC 시스템이 오픈소스로 공개됐다 — 방어 도구의 대중화 | 같은 도구를 공격자도 쓴다. 오픈소스는 양쪽에 열려 있다. |
| 패치 생성도 자동화된다 (결승 패치율 68%) | 패치 적용은 자동화되지 않는다 — 여기가 핵심이다 |
마지막 줄이 이 글의 핵심 주장입니다. 숫자로 보면 명확합니다.
| 구간 | 2026년 현재 속도 | 누구의 속도인가 |
|---|---|---|
| 취약점 발견 | 에이전트가 24일간 80,000회 시도 | 기계 속도 |
| 공개 → 첫 익스플로잇 | 중앙값 10시간 | 기계 속도 |
| SharePoint PoC → 실제 공격 | 약 24시간 | 기계 속도 |
| 고가치 표적의 평균 악용 시점 | Mandiant M-Trends 2026 기준 −7일 (패치 공지가 나오기 전에 이미 악용 중) | 기계 속도 |
| 조직의 패치 적용 | 여전히 주~월 단위 | 사람 속도 |
| 악성 패키지 탐지·삭제 | 86~107분 (훌륭한 편) | 사람 속도 |
| 그 사이 빌드를 돌린 조직의 복구 | 토큰 회수, 자격증명 교체, 감사 — 며칠 | 사람 속도 |
발견은 기계 속도로, 대응은 사람 속도로 돌아갑니다. 그리고 AI는 위쪽 절반만 가속했습니다.
이 구조는 이 블로그에서 반복해 다뤄 온 비대칭과 정확히 같은 모양입니다.
이 격차를 정부도 인지했습니다. 미국 CISA는 AI로 가속된 위협을 근거로 크리티컬 취약점의 패치 기한을 3일로 단축하는 강제 지침(BOD 26-04)을 내놨습니다.
3일이라는 숫자가 자의적으로 보인다면, 위 표를 다시 보십시오. PoC 공개 후 실제 악용까지 24시간입니다. 3일도 사실은 느립니다.
이 주제는 과장과 축소가 동시에 일어납니다. 흔한 반응 네 개를 정리합니다.
| 흔한 반응 | 실제로는 |
|---|---|
| "AI가 해킹한다는 건 마케팅 아닌가" | Rapid7의 SharePoint 체인은 CVE 번호가 붙고 실제로 악용된 취약점이다. GTG-1002는 표적 30곳에 대한 실제 캠페인이었다. 데모가 아니라 사고 기록이다. |
| "결국 퍼저를 LLM으로 포장한 것 아닌가" | 퍼저는 크래시하는 버그만 찾는다. 인증 우회(CVSS 9.1)는 프로그램이 죽지 않는다. 35년간 퍼저가 못 건드리던 영역이다. |
| "우리는 작아서 표적이 아니다" | 공급망 공격은 표적을 고르지 않는다. arrayref는 러스트가 깔린 환경의 약 3/4에 있었다. 공격자는 당신을 노린 게 아니라 당신이 쓰는 라이브러리를 노렸다. |
| "프론티어 모델을 규제하면 된다" | Astra는 멈췄지만 능력은 확산한다. 오픈웨이트 모델에는 격리도 모니터링도 걸 수 없고, 공격자는 애초에 남의 에이전트를 탈옥해 썼다. |
이 글에서 가장 오래 쓸모 있을 부분입니다. 네 갈래로 나눕니다.
가장 먼저 인정해야 할 사실은 이겁니다. npm install, cargo build, pip install은 전부 "남의 코드를 내 기계에서 실행하기" 명령입니다.
| 조치 | 효과 | 주의 |
|---|---|---|
락파일 고정 + --locked/--frozen | 새 버전이 조용히 딸려 오는 경로를 차단한다. arrayref 사건에서 락파일을 고정한 조직은 무사했다. | CI에서 강제해야 의미가 있다 |
벤더링 (cargo vendor, 사설 미러/프록시) | 업스트림 변경이 즉시 전파되지 않는다 | 미러 갱신 정책이 필요 |
| 빌드를 네트워크 차단 컨테이너에서 | 가장 강력하다. 빌드 스크립트가 원격 페이로드를 받지 못하면 이 공격은 성립하지 않는다. | 의존성 사전 캐싱 필요 |
npm ci --ignore-scripts | postinstall 계열 실행을 막는다 | 만능이 아니다. 우회 경로가 있으므로 다른 층과 함께 써야 한다 |
러스트의 build.rs | 현재 전역 비활성화 수단이 없다. 2018년부터 열려 있던 샌드박싱 이슈가 다음 에디션에서 기본 활성화될 예정이다. | 그때까지는 빌드 격리가 유일한 방어 |
그리고 가장 값싼 탐지 신호 하나. arrayref 사건의 결정적 이상 징후는 버전 번호가 아니라 이것이었습니다 — 10년 동안 의존성이 하나도 없던 크레이트에 갑자기 의존성이 추가됐다.
build.rs · postinstall · setup.py)
proc-macro2 vs proc-macro1)
"우리는 괜찮겠지"로 넘어가지 마십시오. 확인은 10분이면 됩니다.
proc-macro1을 검색한다(proc-macro2가 아니다). 그리고 arrayref 0.3.10, internment 0.8.7, append-only-vec 0.1.9가 락파일이나 캐시에 있는지 본다.
~/.cargo/registry 캐시를 비우고 다시 받는다. 삭제된 버전이 로컬 캐시에는 남아 있을 수 있다.
가장 중요한 실무 기회이자 이 글에서 가장 덜 알려진 부분입니다. AIxCC 결승 진출 시스템들이 오픈소스로 공개됐습니다.
| 할 일 | 구체적으로 |
|---|---|
| 내부 코드에 CRS 계열 도구 적용 | AIxCC 공개 시스템은 실제 취약점 18건을 찾아낸 물건이다. 핵심 서비스 한 개부터 붙여 본다. |
| 퍼징 + LLM 하이브리드 | 3부의 루프를 그대로 만든다 — LLM이 의심 지점을 지목 → 퍼저가 검증 → 패치 후 테스트로 채점 |
| 코드 리뷰 에이전트를 보안 관점으로 | 일반 리뷰가 아니라 "인증·권한·역직렬화·경로 처리"를 겨냥한 전용 프롬프트로 돌린다 |
| AI 생성 코드의 보안 게이트 | AI가 만든 코드의 45%가 OWASP Top 10 취약점을 포함한다는 측정이 있다. SAST·의존성 스캔을 머지 조건으로 강제한다. |
GTG-1002 사건의 교훈입니다. 공격자는 모델을 만들지 않았습니다. 남의 에이전트를 빌려 썼습니다.
이 이야기에서 한국 독자가 놓치기 쉬운 사실이 하나 있습니다. AIxCC 결승의 1위와 3위 모두에 한국 연구진이 있었습니다.
| 순위 | 팀 | 구성 | 상금 |
|---|---|---|---|
| 1위 | Team Atlanta | 조지아텍 · KAIST · POSTECH · 삼성리서치 연합 | 400만 달러 |
| 2위 | Trail of Bits (Buttercup) | 미국 보안 기업 | 300만 달러 |
| 3위 | Theori | 미국과 한국의 AI 연구자·보안 전문가로 구성 | 150만 달러 |
이것이 실무자에게 주는 함의는 세 가지입니다.
마지막으로 8월 1일과 8월 7일로 돌아갑니다.
같은 모델입니다. 하나는 80년 묵은 기하학 추측을 반증했고, 하나는 사람 없이 제로데이를 만들 수 있다는 이유로 격리됐습니다.
그리고 그 두 가지는 같은 능력입니다. 긴 추론 사슬, 도구 사용, 실패를 견디는 인내심, 그리고 기계가 채점할 수 있는 목표. 증명 탐색과 익스플로잇 탐색은 탐색 공간의 이름만 다른 같은 작업입니다.
이 사실에서 세 가지 미해결 질문이 나옵니다.
| 질문 | 왜 어려운가 |
|---|---|
| ① 능력을 막으면 방어도 못 한다 | Big Sleep이 악용 직전의 취약점을 잡아낸 것도 정확히 같은 능력이다. 사이버 능력을 억제하면 방어 자동화도 함께 억제된다. |
| ② 판정을 그 회사가 한다 | "심각 임계에 도달했는가"를 판단하는 주체가 출시로 이익을 얻는 당사자다. Astra 사례는 자율규제가 작동한 증거인 동시에, 그것이 자율이라는 사실의 증거이기도 하다. |
| ③ 오픈웨이트에는 임계가 없다 | 가중치가 공개된 모델은 격리도 CoT 모니터링도 적용할 수 없다. 프론티어 랩이 멈춰도 능력 자체는 확산한다. |
그럼에도 Astra 사건에는 분명한 진전이 있습니다. 자기 프레임워크 때문에 실제로 출시를 늦춘 첫 사례이고, "배제할 수 없다"는 불확실성만으로 그렇게 했습니다. 2023년 이후 프론티어 랩들이 만든 자율 안전 프레임워크가 문서로만 존재하는지, 실제로 브레이크를 거는지가 이번에 처음 시험됐습니다.
그리고 그 프레임워크를 지금 다시 쓰고 있다는 사실이 오히려 신뢰의 근거입니다. 기준이 현실을 못 따라갔다는 것을 인정한 것이니까요.
--locked / npm ci로 도는지 확인. 아니면 오늘 바꾼다.
2026년 8월의 사건들
계보
대응
이어서 읽기
2026년 8월의 3주를 한 문장으로 줄이면 이렇습니다.
취약점을 찾는 일이 사람의 인내심이 아니라 예산의 문제가 되었습니다.
이건 좋은 소식이자 나쁜 소식입니다. 방어자도 같은 도구를 갖게 됐고, AIxCC 시스템은 오픈소스로 열려 있습니다. 하지만 발견이 기계 속도로 빨라지는 동안 패치를 적용하고, 자격증명을 교체하고, 영향 범위를 파악하는 일은 여전히 사람의 속도입니다.
그러니 지금 물어야 할 질문은 "AI가 우리를 더 위험하게 만드는가"가 아닙니다.
"발견이 10시간 만에 무기가 되는 세계에서, 우리 조직이 대응하는 데는 며칠이 걸리는가?"
그 숫자를 모른다면, 그것부터 재는 것이 이번 주에 할 수 있는 가장 값진 일입니다.
