AI가 찾은 CIRCL 버그, 보안감사의 새 분업

일곱 개 버그와 더 중요한 한 가지

zkSecurity의 2026년 7월 7일 글은 AI 감사 파이프라인을 Cloudflare의 CIRCL 암호학 라이브러리에 적용해 7개의 실제 버그를 확인했고 모두 upstream에서 수정됐다고 밝혔다. 대상은 Cloudflare CIRCL이다. CIRCL은 Go로 작성된 암호 프리미티브 모음이며, 포스트양자 암호와 타원곡선 암호 실험 배포를 목표로 한다.

이 사례에서 가장 중요한 문장은 "AI가 최종 보고서를 썼다"가 아니다. zkSecurity는 AI가 후보 finding을 만들었고, 사람이 exploitability를 확인하고 PoC를 줄이고 disclosure를 처리했다고 설명한다. 즉 AI 감사의 현실적인 모델은 완전 자동 보안 연구자가 아니라 후보 생성 엔진과 검증자의 분업이다. 이 구분이 흐려지면 보안팀은 과대광고와 무용론 사이를 오가게 된다.

버그 목록은 다양하다. threshold RSA의 float64 정밀도 손실, qndleq의 공격자 제어 보안 파라미터, BLS aggregate 검증의 메시지 중복 확인 누락, DLEQ soundness break, HPKE PSK 검증 우회, int64 Lagrange 계수 오버플로, CP-ABE access-control break가 포함됐다. Agenthub의 Mythos 이후 CVE 급증 분석, Deptrust 에이전트 의존성 보안, Codex 민감 파일 제외 분석과 이어지는 흐름이다.

AI가 잘한 것과 못한 것

이번 글에서 흥미로운 지점은 AI의 severity 판단이 흔들렸다는 점이다. 예를 들어 BLS aggregate 검증의 메시지 distinctness 누락은 rogue key attack으로 이어질 수 있는 중대한 패턴인데, AI는 medium으로 낮게 봤고 Cloudflare는 high로 확인했다. 반대로 일부 문제는 AI가 critical로 봤지만 실제 운영 조건에서는 low로 평가됐다. 후보 발견과 위험 평가가 다른 능력이라는 뜻이다.

AI는 특정 패턴을 빠르게 훑고, 수학적 경계와 직렬화 경계가 만나는 지점을 찾아내는 데 강점을 보였다. DLEQ의 sign collision처럼 단일 라인이 아니라 대수적 성질과 big.Int 직렬화가 결합된 문제를 찾은 것은 의미가 크다. 하지만 "실제 배포에서 얼마나 공격 가능한가"는 코드 밖 맥락을 요구한다. 사용 빈도, 파라미터 범위, API 계약, bounty policy, 대체 방어를 모두 봐야 한다.

암호학 코드는 에이전트에게 어려운 시험대다

암호학 라이브러리는 AI 보안감사에 좋은 시험대다. 버그가 있으면 영향이 크고, 사소한 타입 선택이나 직렬화 방식이 보안성을 깰 수 있으며, 단순 린터로 잡기 어려운 수학적 전제가 많다. Cloudflare의 CIRCL 소개 글은 이 라이브러리가 실험적이고 고급 암호 구현을 제공한다고 설명했고, GitHub README도 생산 환경에서는 주의가 필요하다고 밝힌다.

그렇다고 AI가 암호학자를 대체한다는 결론은 성급하다. 이번 사례 자체가 인간 검증의 필요성을 보여준다. 특히 암호학 취약점은 "컴파일된다"와 "공격 가능하다" 사이에 큰 간극이 있다. 잘못된 PoC는 maintainer 시간을 낭비하고, 과장된 severity는 신뢰를 떨어뜨린다. AI 보안 도구는 발견 수를 자랑하기보다 재현 가능성, 중복 제거, severity 보정, patch quality를 지표로 삼아야 한다.

HackerOne의 Cloudflare 프로그램처럼 공개된 버그바운티 절차가 있는 생태계에서는 이 분업이 더 중요해진다. AI가 후보를 대량 생성하면 triage 병목이 생긴다. 따라서 보안팀은 "AI가 찾은 것"을 바로 보고하지 말고, 최소 재현 코드와 영향 범위를 사람이 확인하는 내부 게이트를 둬야 한다.

한국 보안팀이 배워야 할 운영 모델

한국 기업의 보안팀은 이번 사례를 도구 구매 신호로만 읽으면 안 된다. 진짜 변화는 보안감사의 cadence다. 전통적 감사는 릴리스 전 또는 연 1회에 몰렸다. AI 에이전트형 감사는 코드가 바뀔 때마다 후보를 계속 던진다. 문제는 발견량이 늘어나는 만큼 검증과 패치 역량도 같이 늘어야 한다는 점이다.

첫 번째로 필요한 것은 스코프 제한이다. 결제, 인증, 암호화, 권한, 데이터 삭제처럼 고위험 모듈을 먼저 지정한다. 두 번째는 후보 품질 기준이다. 재현 명령, 영향 설명, false positive 가능성, 관련 커밋을 요구한다. 세 번째는 maintainer와 보안팀의 SLA다. AI가 매일 수십 개 후보를 만들 수 있어도 패치 병목이 풀리지 않으면 위험은 줄지 않는다.

개발자 교육도 달라진다. AI가 버그 후보를 찾아주면 개발자는 보안의 기본을 몰라도 된다는 생각은 위험하다. 오히려 후보를 판별하기 위해 더 많은 보안 문해력이 필요하다. cryptography, serialization, concurrency, dependency security 같은 영역의 기본 교육이 중요해진다.

자주 묻는 질문

Q1: AI가 보안감사를 자동화할 수 있나요?

A: 후보 탐색은 강하게 자동화될 수 있다. 하지만 exploitability 판단, severity 보정, disclosure는 아직 인간 검증이 중요하다.

Q2: 이번 버그들은 모두 심각했나요?

A: 아니다. AI 평가와 Cloudflare 확인 severity 사이에 차이가 있었다. 일부는 낮게, 일부는 높게 평가됐다.

Q3: 암호학 코드에도 AI가 효과적인가요?

A: 패턴 탐색과 경계 조건 발견에는 효과를 보였다. 다만 수학적 타당성과 실제 공격 가능성은 전문가 검증이 필요하다.

Q4: 기업은 어떤 방식으로 도입해야 하나요?

A: 전체 코드에 무작정 돌리기보다 고위험 모듈부터 시작하고, 재현 가능한 후보만 triage하는 절차를 만들어야 한다.

Q5: 보안팀의 병목은 어디로 이동하나요?

A: 발견에서 검증과 패치로 이동한다. AI가 후보를 많이 만들수록 maintainer 시간과 triage 품질이 핵심 병목이 된다.