AI 코드 감사는 어디까지 유효한가: Cloudflare CIRCL 사례가 보여준 현실
2026-07-08
요즘 AI가 코드를 읽고, 버그를 찾고, 심지어 보안 취약점까지 발견할 수 있다는 이야기는 더 이상 낯설지 않다. 하지만 막상 현업의 시선으로 보면 질문은 조금 더 현실적이다. 정말 믿을 만한가, 그리고 어디까지 맡길 수 있는가.
이 질문에 꽤 구체적인 답을 던져주는 사례가 있다. 바로 Cloudflare의 암호 라이브러리 CIRCL을 대상으로 한 AI 감사 결과다. 단순히 “AI가 뭔가 수상한 코드를 지적했다”는 수준이 아니라, 실제로 7건의 취약점이 확인되었고 업스트림에서 모두 수정되었다는 점이 인상적이다. 특히 암호 구현처럼 작은 실수 하나가 치명적인 결과로 이어질 수 있는 영역에서 이런 결과가 나왔다는 사실은, AI 코드 감사의 효용을 다시 보게 만든다.
다만 이 사례가 흥미로운 이유는 AI의 승리담처럼 단순하게 정리되지 않기 때문이다. 오히려 이 이야기는 AI가 유용해진 지점과 여전히 인간이 반드시 개입해야 하는 지점을 함께 보여준다.
암호 구현에서 AI가 실제로 의미 있었던 이유
보안 취약점 탐지는 원래도 어려운 일이다. 그런데 암호 라이브러리는 그중에서도 특히 까다로운 분야에 속한다. 일반적인 애플리케이션 버그와 달리, 암호 코드는 다음과 같은 특성을 갖는다.
- 수학적 전제와 구현 세부가 강하게 얽혀 있다
- 겉보기에는 정상 동작해도 보안 속성이 무너질 수 있다
- 성능 최적화, 정밀도, 예외 처리 같은 작은 차이가 치명적 결과를 만든다
- 검증 자체가 고비용이다
이런 영역에서는 단순 정적 분석이나 테스트만으로는 놓치는 문제가 많다. 그래서 이번 사례가 더 의미 있다. AI 감사 파이프라인이 CIRCL에서 실제 취약점 7건을 찾아냈다는 것은, 적어도 AI가 “그럴듯한 경고를 많이 뿌리는 도구”를 넘어 실질적인 탐지 보조 수단으로 올라오고 있다는 신호로 읽힌다.
특히 알려진 이슈로 언급된 사례들은 가볍지 않다.
- 임계치 RSA에서 float64 정밀도 손실 문제
- CP-ABE의 AND-share 버그로 인한 접근 제어 붕괴
이런 문제는 단순 문법 오류나 널 포인터 수준이 아니라, 보안 모델 자체를 흔들 수 있는 구현 결함에 가깝다. 즉 AI가 찾은 것이 “자잘한 냄새 코드”가 아니라, 실제 운영 환경에서 의미 있는 위험으로 이어질 수 있는 문제였다는 점이 중요하다.
중요한 건 AI가 코드를 읽었다는 사실이 아니라, 검증 비용이 매우 높은 영역에서 실제 취약점을 찾아냈다는 점이다.
“AI가 찾았다”보다 더 중요한 건 파이프라인이었다
이 사례를 볼 때 흔히 모델 이름에 먼저 눈이 간다. Opus 4.6, GPT-5.3, 그리고 전문가 유지 스킬 조합. 물론 어떤 모델을 썼는지는 중요하다. 하지만 더 본질적인 포인트는 단일 모델의 천재성보다 감사 파이프라인의 설계에 있다.
설명에 따르면 zkao 에이전트가 먼저 후보를 탐지하고, 이후 인간이 검증하고 공개 절차를 수행했다. 이 흐름은 AI 코드 감사가 실제 현업에서 어떻게 자리 잡아야 하는지를 꽤 잘 보여준다.
핵심은 대략 이런 구조다.
- AI는 넓게 훑으며 의심 지점 후보를 빠르게 발굴한다
- 여러 추론 경로와 스킬 조합으로 놓치기 쉬운 패턴을 끌어올린다
- 인간 전문가는 그중에서
- 재현 가능성을 확인하고
- 실제 취약점 여부를 판정하고
- 심각도를 평가하고
- 공개 및 수정 프로세스를 책임진다
이 구조를 보면 AI는 감사자를 대체한다기보다, 감사자의 탐색 비용을 크게 줄여주는 증폭기에 가깝다. 특히 코드베이스가 크고, 도메인 지식이 깊게 필요한 프로젝트일수록 이 장점은 더 커진다.
반대로 말하면, AI 코드 감사의 성패는 모델 성능만으로 결정되지 않는다.
- 어떤 범위를 읽게 할 것인가
- 어떤 힌트와 컨텍스트를 줄 것인가
- 후보를 어떤 기준으로 필터링할 것인가
- 인간 검증 단계와 어떻게 연결할 것인가
이런 운영 설계가 빠지면, AI는 쉽게 그럴듯한 오탐지 생성기가 된다. 이번 사례는 AI가 강력하다는 증거이면서 동시에, 잘 설계된 인간-기계 협업이 있어야만 결과가 나온다는 증거이기도 하다.
현실적인 효용은 “완전 자동화”가 아니라 “검증 우선순위화”에 있다
AI 코드 감사를 둘러싼 기대 중에는 종종 과장이 섞인다. 마치 AI가 저장소를 통째로 읽고 알아서 취약점을 찾아내고, 인간은 승인만 하면 되는 것처럼 말이다. 하지만 실제로는 그렇게 단순하지 않다.
이번 사례가 보여주는 현실적 효용은 오히려 더 소박하고, 그래서 더 설득력 있다. AI의 가장 큰 가치는 완전 자동화보다 다음에 있다.
- 검토 우선순위를 정해준다
- 사람이 놓칠 수 있는 이상 징후를 먼저 끌어올린다
- 도메인 특화 코드에서도 탐색 범위를 넓혀준다
- 전문가가 깊게 볼 만한 지점을 압축해준다
보안 감사에서 가장 비싼 자원은 대개 전문가의 집중력과 시간이다. AI가 이 자원을 아껴준다면, 그 자체로 이미 큰 가치가 있다. 특히 암호 구현처럼 코드 한 줄을 이해하기 위해 배경 지식과 맥락이 많이 필요한 분야에서는 더욱 그렇다.
여기서 중요한 건 성능 평가 방식도 달라져야 한다는 점이다. 단순히 “몇 건 찾았나”만 볼 것이 아니라, 다음 질문이 함께 따라와야 한다.
- 찾은 이슈가 얼마나 실제 위험에 가까운가
- 오탐과 미탐의 패턴은 무엇인가
- 모델이 어떤 추론 경로를 통해 결론에 도달했는가
- 인간 검증 단계에서 어떤 후보가 살아남는가
즉 AI 감사의 품질은 탐지율만이 아니라, 심각도 판단 가능성과 추론 패턴의 해석 가능성까지 포함해서 봐야 한다. 이번 사례가 의미 있는 이유도 여기에 있다. 단순히 “7건 발견”이라는 숫자보다, AI가 어떤 식으로 보안 검토 과정에 들어와 실무적 가치를 만들었는가를 보여주기 때문이다.
그래도 마지막 책임은 인간에게 남는다
이 사례를 보고 “이제 보안 감사도 AI에게 맡기면 되겠다”라고 결론 내리면 오히려 핵심을 놓치게 된다. 이번 결과는 AI의 가능성을 강하게 보여주지만, 동시에 최종 보고서는 인간 검증이 필요했다는 사실도 분명히 말해준다.
이 지점은 매우 중요하다. 보안 취약점은 단순한 정답 맞히기 문제가 아니다.
- 이 현상이 정말 exploitable한가
- 실제 배포 환경에서 위험도가 어느 정도인가
- 라이브러리 사용자에게 어떤 영향을 주는가
- 수정 시 다른 보안 속성을 해치지 않는가
이런 판단은 아직까지 인간 전문가의 책임 영역에 훨씬 가깝다. 특히 암호 라이브러리처럼 “겉보기 수정”이 또 다른 취약점을 만들 수 있는 분야에서는 더 그렇다.
그래서 AI 코드 감사의 현실적인 위치는 아마도 이쯤일 것이다.
AI는 감사의 시작점을 넓혀주고, 인간은 결론의 책임을 진다.
이 문장이 지금 시점의 균형을 가장 잘 설명하는 것 같다. AI는 분명 유용해졌다. 그리고 어떤 영역에서는 이미 기대 이상으로 유효하다. 하지만 그 유효함은 인간을 지우는 방식이 아니라, 인간 전문가의 판단을 더 멀리 닿게 만드는 방식으로 나타난다.
마무리하자면, Cloudflare CIRCL 사례는 AI 코드 감사에 대해 지나치게 낙관할 필요도, 반대로 냉소할 필요도 없다는 점을 잘 보여준다. 실제 취약점을 찾아낼 수 있을 만큼 충분히 쓸모 있어졌지만, 아직 스스로 책임질 수 있을 만큼 완결되지는 않았다. 어쩌면 이 어중간함이야말로 지금 AI 보안 도구의 가장 정확한 현실일지 모른다.
그래서 앞으로 더 중요해질 것은 “AI가 할 수 있느냐”보다 AI를 어떤 절차와 기준 속에 넣어야 제대로 쓸 수 있느냐일 것이다. 기술 자체보다 운영 방식이 더 중요해지는 순간이 이미 시작된 셈이다.