클라우드플레어가 대규모언어모델(LLM)에 종속되지 않는 보안 취약점 탐지 하네스 아키텍처를 공개했다. 프론티어 AI 모델로 엔터프라이즈 코드베이스의 보안 취약점을 찾되, 특정 모델에 의존하지 않고 여러 모델을 교차 검증하는 방식으로 오탐을 줄인다는 접근방식이다.

클라우드플레어는 지난 18일 공개한 블로그 포스트 '취약점 하네스 구축하기(Build your own vulnerability harness)'에서 약 6주에 걸쳐 개발한 시스템 구조를 상세히 설명했다. 자체 코드베이스 128개 저장소를 스캔하며 얻은 실제 경험을 바탕으로 한 문서다.

단일 모델 신뢰도 절반에 불과... 교차 검증 필수

클라우드플레어의 실측 결과에 따르면, 프론티어 AI 모델 1개가 한 번에 찾는 취약점은 여러 번 실행했을 때 발견되는 전체 버그의 약 절반 수준이다. 더욱이 찾은 버그들도 단순하고 명백한 것들에 편중되는 경향을 보였다.

"단일 모델은 항상 동일한 렌즈로 코드를 분석한다"고 클라우드플레어는 진단했다. 즉, 한 모델의 인식 틀에 갇히면 특정 유형의 취약점은 절대 발견되지 않을 수 있다는 뜻이다. 따라서 초기 발견에는 A 모델을, 검증에는 완전히 다른 B 모델을 사용하는 식으로 다양한 모델을 조합해야 한다는 논리다.

이 접근이 중요해진 이유는 AI 시장의 급변성 때문이다. 클라우드플레어는 "개발자들이 단 하나의 모델 주위에 견고히 구축했다가 그 모델이 단종되거나 더 우수한 모델로 대체되는 경험을 이미 여러 번 했다"고 지적했다. 따라서 보안 자동화 시스템이 특정 모델에 종속되면 새로운 모델 전환 시마다 전체 시스템이 마비될 수 있다.

상태 외부화와 지속성... 시간당 수백만 줄 코드 처리

클라우드플레어가 개발한 하네스의 핵심은 LLM을 "상태 비저장 컴퓨팅 엔진"으로 취급하는 것이다. 기존 AI 에이전트는 1회 세션 내에서 모든 분석을 완료해야 하는데, 대규모 코드베이스에서는 필연적으로 컨텍스트 윈도우가 한계에 도달한다. 예를 들어 1시간 분석 후에는 컨텍스트 윈도우가 포화되면서 AI가 자신이 추적하던 버그를 잊어버린다는 뜻이다.

이를 해결하기 위해 클라우드플레어는 발견 사항을 외부 데이터베이스에 저장하고, 분석 상태를 절대로 메모리에만 보관하지 않도록 설계했다. 또한 네트워크 장애나 속도 제한(rate-limit) 에러로 중단된 작업을 자동으로 재개할 수 있는 재개가능성(resumability)을 구현했다. 수동으로 여러 번 실행한 후 결과를 비교하는 식의 비효율을 완전히 제거한 것이다.

하네스는 다음 단계로 구성된다:

• 정찰(Recon): 3개의 병렬 AI 에이전트가 코드 아키텍처를 분석해 architecture.md 문서 생성
• 사냥(Hunt): 공격 유형별로 전문화된 에이전트들이 각각의 취약점 클래스를 대상으로 코드를 공격적으로 분석
• 검증(Validate): 독립적인 검증 에이전트가 발견된 취약점들이 실제인지 반박하며 재검증
• 보고(Report): 정형화된 JSON 형식의 발견 사항 생성 및 기계적 스키마 검증
• 재검증(Independent Validation): 처음과 완전히 독립적인 별도 에이전트가 모든 발견을 다시 한 번 검증

이 5단계 프로세스를 통해 오탐을 줄이고, 신뢰도 높은 취약점만 최종 보고된다.

크로스-저장소 추론... 의존성 추적으로 실제 위험 발견

클라우드플레어가 강조한 또 다른 핵심은 크로스-저장소 추론(cross-repo reasoning)이다. 단일 저장소를 분석하면 그 저장소 내부의 결함만 찾을 수 있지만, 실제 보안 위험은 여러 애플리케이션 간의 의존성 경계에서 비롯되는 경우가 많다는 점이다.

예를 들어 라이브러리 저장소의 어떤 함수가 약간 이상하더라도, 그것을 호출하는 상위 서비스에서 추가적인 입력 검증이 이뤄지면 문제가 없을 수 있다. 반대로 느슨한 검증만 있는 인터페이스를 통해 호출될 경우 취약점이 활성화될 수 있다는 뜻이다. 클라우드플레어의 시스템은 128개 저장소 간 의존성을 자동으로 추적하며, 각 저장소가 다른 저장소를 어떻게 사용하는지 분석해 이런 경계 취약점을 찾아낸다.

6주 개발, 다양한 언어 자동 지원

클라우드플레어는 초기 ~450줄 규모의 보안 감시 스킬에서 시작해 체계적인 오케스트레이션 계층을 추가해 현재의 하네스로 확장했다. 각 단계를 별도 에이전트로 분리하고, 데이터베이스 뒤에 오케스트레이터를 배치한 구조다.

흥미로운 점은 언어-특화 튜닝이 거의 없다는 것이다. 러스트, Go, C, 루아, 타입스크립트, 파이썬을 비롯한 다양한 언어의 코드베이스를 동일한 하네스로 처리한다. 즉, 모델에게 구문 분석을 맡기면서 언어 간 차이를 자동으로 극복한다는 의미다.

클라우드플레어가 이 경험을 공개한 이유는 명확하다. 같은 과제를 다루는 기업들이 "특정 모델에만 맞춘 단발성 시스템"을 구축하지 말고, 처음부터 모델 교체 가능성을 설계에 반영하도록 제시하기 위함이다. 보안 자동화 시스템의 가치는 개별 AI 모델의 성능보다 오케스트레이션 계층에 있다는 관점을 강조한 것이다.

클라우드플레어 관계자는 "하네스 설계는 모델이 아니라 아키텍처에 중심을 두는 것이 중요하다"며 "어느 모델이 현재 최고더라도, 그 모델이 영원하다고 가정하지 말아야 한다"고 강조했다.