logo
|
Blog

    벤치마크 1위에 속지 마세요 | 실제 코드 보안을 높이는 AI 솔루션 선택법

    AI 보안 시장의 화려한 발표문과 벤치마크 점수 속에서 '진짜 제품'을 가려내는 방법. 소스코드 분석과 실행 환경 검증, 그리고 구체적인 재현 단계(PoC) 입증까지—AI 보안 솔루션 도입 전 반드시 확인해야 할 3가지 핵심 기준을 소개합니다.
    Xint's avatar
    Xint
    Aug 10, 2026
    벤치마크 1위에 속지 마세요 | 실제 코드 보안을 높이는 AI 솔루션 선택법
    Contents
    실제로 무슨 일이 일어났는가실험실 테스트에 숨겨진 함정AI 보안 솔루션 도입 전, 반드시 던져야 할 3가지 질문1. 분석의 출발점이 어디인가? (What did it start from?)2. 실제로 어디까지 볼 수 있는가? (What can it actually see?)3. 결국 어떤 결과물을 내놓는가? (What does it hand you at the end?)기존 솔루션 업체들도 인정하는 한계그렇다면, 어떤 선택을 해야할까요?

    지난 7월, 불과 72시간 사이에 클라우드 보안 거대 기업, 하이퍼스케일러, 버그 바운티 플랫폼, 그리고 Y 콤비네이터 스타트업이 일제히 발표를 쏟아냈습니다. 자신들의 AI가 실제 소프트웨어에서 진짜 취약점을 찾아낼 수 있다는 내용이었죠.

    보안 도구를 구매하는 담당자라면 수많은 영업, 홍보 메일을 받았을 겁니다. 그리고 그 모든 내용에는 예외 없이 똑같은 세 단어가 등장합니다. ‘자율적(Autonomous)’, ‘검증된(Validated)’, ‘익스플로잇 가능(Exploitable)’.

    하지만 이들이 말하는 이 단어들은 겉보기엔 같지만, 실제 의미하는 바는 전혀 다릅니다.

    그래서 일종의 가이드북을 준비했습니다. 실제로 무슨 일이 일어났는지, 이것이 AI 보안 업계에 무엇을 시사하는지, 그리고 단순히 잘 쓰인 영업 홍보 문구와 진짜 제품을 가려내기 위해 던져야 질문은 무엇인지를 정리해 봤습니다.

     

    실제로 무슨 일이 일어났는가

    구글에 인수된 Wiz는 취약점 연구를 위한 에이전틱(Agentic) 시스템인 Project Atlas를 발표했습니다. CyberGym 벤치마크에서 90.9%의 성공률로 1위를 차지했고, Wiz의 발표에 따르면 수년간 퍼징(Fuzzing)과 코드 리뷰를 거쳐온 오픈소스 코드에서 200개 이상의 알려지지 않은(previously unknown) 취약점을 찾아냈다고 합니다. 며칠 뒤 마이크로소프트 역시 자체 에이전트 하네스를 통해 동일한 벤치마크에서 95.95%를 기록했다고 주장했습니다.

    Bugcrowd는 웹 애플리케이션 및 API용 에이전틱 모의침투 제품인 Savant Pathseeker의 얼리 액세스를 출시했습니다.

    Nebula Security는 세계 챔피언 CTF 팀 출신들이 개발한 AI 에이전트 Vega를 들고 Y 콤비네이터를 통해 등장했고, 이미 1,000개 이상의 버그를 찾아낸 성과를 선보였습니다.

    또한 Aikido는 이미 자율 모의침투 기업 2곳과 AI 코드 리뷰 기업 1곳을 인수한 데 이어, 또 다른 보안 스타트업을 추가로 인수했습니다.

    이 네 가지 발표가 가리키는 결론은 하나입니다. 지난 2년 동안 Xint팀이 줄곧 주장해 왔던 내용이기도 한데요, AI는 이제 인간 전문가가 발견하는 취약점을, 인간이 도저히 따라갈 수 없는 속도와 비용으로 찾아낼 수 있습니다. 이 사실에 대한 논쟁은 이미 끝났고, 더 이상 왈가왈부할 필요도 없는 상황입니다.

    하지만 정작 중요한 질문은 따로 있습니다. 하지만 그 누구도 이에 대해 제대로 다루고 있지 않죠.

     

    실험실 테스트에 숨겨진 함정

    자동차 제조 기업들은 차량 안정성을 입증하기 위해 충돌 테스트 등급을 공개합니다. 별 5개를 받는 결과는 물론 의미가 있습니다. 하지만 이 테스트는 정해진 속도, 정해진 장벽, 그리고 엔지니어가 충격을 예상한 위치에 센서가 미리 배치된 통제된 충돌 실험입니다. 그 누구도 이 실험 결과를 실제 도로 위의 운전과 착각하지 않습니다.

    벤치마크 역시 마찬가지입니다. 지난 7월, 모두가 1위를 차지하기 위해 달려들었던 CyberGym 벤치마크는 이미 알려진 취약점을 시스템에 미리 제공해 두었습니다. 취약점에 대한 설명과 관련 코드를 미리 쥐여준 뒤, 시스템이 작동 가능한 재현 검증(PoC) 코드를 만들어낼 수 있는지를 평가하는 방식이였죠.

    이 역시 기술력을 검증하는 유용한 측정 기준이였고, 여기서 경쟁했던 팀들 또한 수준 높은 엔지니어링을 보여주었습니다. 하지만 Wiz 스스로도 솔직하게 인정했듯이, 이미 알려진 취약점을 재현하는 것은 알려지지 않은 취약점을 새로 찾아내는 것과는 완전히 다르고 훨씬 쉬운 문제입니다.

    진정한 발견은 아무런 힌트도 없는 백지상태에서 시작됩니다. 취약점 설명도, 취약한 함수가 무엇인지도 가리켜주지도 않으고, 매일같이 코드가 변경되는 거대하고 복잡한 코드베이스를 AI가 직접 파헤쳐야 하죠.

    이것이 현업 보안 팀이 매일 마주하는 진짜 현실입니다. 그리고 현재 그 어떤 공개 벤치마크도 이 진짜 실력을 측정해 내지 못합니다. 즉, 현재의 리더보드가 기술적 완성도에 대해선 의미 있는 정보를 줄지 몰라도, 막상 이 제품을 여러분의 실제 코드베이스에 적용했을 때 무엇을 해낼 수 있는지는 아무것도 장담할 수 없습니다.

    Xint는 이러한 리더보드 점수를 높이기 위해 제품을 최적화하지 않기로 선택했습니다. 기술력이 모자라서가 아닙니다. 이미 답이 정해진 버그를 재현하는 건 실전 보안의 가장 쉬운 영역에 불과하기 때문입니다. Xint는 리더보드 상단에 이름을 올리는 대신, 실제 코드베이스에서 아무도 몰랐던 취약점을 발굴하는 기술력으로 평가받고자 합니다.

     

    AI 보안 솔루션 도입 전, 반드시 던져야 할 3가지 질문

    1. 분석의 출발점이 어디인가? (What did it start from?)

    취약점의 위치와 정보를 미리 알고 입증만 하는 시스템과, 전체 소스코드만 주고 스스로 문제점을 찾아내게 하는 시스템은 기술의 수준부터 완전히 다릅니다. 도입하려는 제품이 분석을 어디서부터 시작하는지 반드시 확인해 보세요. 그리고 기존에 전혀 알려지지 않았던 취약점을 실제 몇 개나 찾아냈는지 물어보시기 바랍니다.

     

    2. 실제로 어디까지 볼 수 있는가? (What can it actually see?)

    이 질문은 현재 시장에 나온 보안 솔루션들의 유형을 명확히 가르지만, 대부분의 구매 담당자가 간과하는 핵심 요소입니다.

    • 외부 침투 방식: 실행 중인 애플리케이션에 트래픽을 보내며 반응을 살핍니다. 하지만 소스 코드가 없기 때문에 내부에서 어떤 일이 벌어지는지 세부 사정은 알 수 없습니다.

    • 소스 코드 분석 방식: 수십 개 파일과 서비스 간 데이터 흐름을 추적합니다.하지만 방화벽(WAF) 너머의 실제 운영 환경에서 해당 엔드포인트에 정말로 접근할 수 있는지는 알 수 없습니다.

    두 방식 모두 나름의 역할이 있지만 단독으로는 반쪽짜리 진단에 그칩니다. 실제 공격자는 코드와 운영 환경의 경계를 따지지 않죠. 가장 치명적인 보안 사고는 항상 소스 코드와 운영 환경이 만나는 그 '경계선'에서 발생합니다. 소스 코드와 실행 중인 시스템을 동시에 봐야만 비로소 파악되는 로직 결함처럼 말이죠.

    티오리가 이 두 가지 접근법을 모두 구축하는 이유가 바로 여기에 있습니다. Xint Code는 소스 코드를 읽고, Xint Web은 실행 중인 애플리케이션을 공격해 검증합니다. 그리고 가장 치명적인 취약점은 이 두 영역이 만날 때 포착되기에, 두 솔루션을 하나의 플랫폼으로 통합하고 있습니다.

     

    3. 결국 어떤 결과물을 내놓는가? (What does it hand you at the end?)

    제품의 실질적 가치를 결정짓는 가장 핵심적인 질문입니다.

    단순히 위험해 보이는 코드 패턴을 뜻하는 '약점(Weakness)'과, 실제 공격 경로와 검증된 재현 단계를 갖춘 '취약점(Vulnerability)'은 엄연히 다릅니다. 기존 SAST 솔루션들은 단순 약점을 수천 개씩 쏟아내며 이를 높은 ‘커버리지’라고 포장하곤 합니다. 그 결과 개발자들은 분기 내내 무엇이 진짜 취약점인지 가려내느라 시간을 허비하게 됩니다.

    Xint는 명확한 원칙 아래 구축되었습니다. "공격 실행 과정을 직접 증명할 수 없다면 리포팅하지 않는다."

    구체적인 재현 단계(Reproduction steps)는 리포트에 단순히 구색 맞추기용으로 채우는 기능이 아닙니다. 탐지 결과가 진짜임을 입증하는 핵심 증거입니다. 이것이 없으면 개발자는 리포트를 보고 즉시 수정에 나서는 것이 아니라, 결과의 진위 여부를 두고 불필요한 소모전만 벌이게 됩니다.

    시장의 흐름도 이미 이 방향으로 바뀌고 있습니다. 규제 기관들 역시 단순 스캐너 결과가 아닌, 실제 공격 가능성(demonstrated exploitability)의 입증을 요구하기 시작했습니다. 특정 시점 기준의 형식적인 점검 방식은 수명을 다했습니다. 명확한 재현 증거를 제시하지 못하는 도구는 곧 시장에서 한계를 드러낼 것입니다.

     

    기존 솔루션 업체들도 인정하는 한계

    Bugcrowd의 Pathseeker FAQ를 자세히 읽어보면 흥미로운 부분이 있습니다. 신제품 출시 발표문 중, AI 모의침투 도구가 복잡한 비즈니스 로직 결함, 익스플로잇 체이닝(Exploit Chaining), 제로데이 공격에는 적합하지 않으며, 이것만으로는 규제 준수(Compliance) 요건을 충족할 수 없다고 솔직하게 밝히고 있습니다.

    이는 AI 제품이 기초 수준(Floor)을 높여줄 뿐이며, 보안의 최고 수준(Ceiling)에 도달하려면 인간 연구원의 서비스를 별도로 구매해야 한다는 의미입니다.

    이는 비즈니스 측면에서는 합리적 모델일지도 모릅니다. 하지만 티오리가 지향하는 방향과는 다릅니다.

    우리는 그 '최고 수준(Ceiling)' 자체가 바로 제품이어야 한다고 믿습니다. 비즈니스 로직 결함, 연계 익스플로잇, 그리고 알려지지 않은 취약점은 AI가 쉬운 일을 다 하고 남겨놓은 '인간의 몫'이 아닙니다. 고난도 핵심 취약점이야말로 고객이 오펜시브 보안(Offensive Security)에 비용을 지불하는 가장 핵심적인 이유입니다. 티오리는 지난 10년간 Pwn2Own 대회와 미국 DARPA 연구 프로젝트 등을 통해 기술력을 증명해 왔으며, Xint의 엔진 역시 이 작업을 직접 수행해온 전문가들이 만든 겁니다.

    그렇다면, 어떤 선택을 해야할까요?

    • 벤치마크 점수에 현혹되지 마세요. 최근 이 솔루션이 아무도 찾지 못했던 어떤 취약점을 찾아냈는지, 그리고 그것을 실제로 증명하는 재현 단계를 확인해 보세요.

    • 반쪽짜리 솔루션에 만족하지 마세요. 소스 코드와 실제 실행 환경을 모두 볼 수 있는 도구인지, 아니면 둘 중 하나만 볼 수 있는 도구인지 확인해야 합니다. 그리고 그 사이의 사각지대에서 어떤 결함이 발생하는지 체크하세요.

    • 단순 탐지 건수에 속지 마세요. 탐지 건수는 보안 업계에서 가장 부풀리기 쉬운 지표이며, 시스템의 실제 안전성과는 가장 거리가 먼 숫자입니다.

    지금 보안 시장에는 수많은 변화가 일어나고 있고, 그 대부분은 실제 현실입니다. 이제 핵심 질문은 "AI가 취약점을 찾을 수 있는가?"가 아닙니다. "발견한 취약점을 실제로 증명해낼 수 있는 솔루션은 무엇인가?"입니다.

    실제 여러분의 소스코드에서 이 차이가 어떻게 증명되는지 확인하고 싶으시다면, Xint가 직접 보여드릴께요.

    Share article
    Contents
    실제로 무슨 일이 일어났는가실험실 테스트에 숨겨진 함정AI 보안 솔루션 도입 전, 반드시 던져야 할 3가지 질문1. 분석의 출발점이 어디인가? (What did it start from?)2. 실제로 어디까지 볼 수 있는가? (What can it actually see?)3. 결국 어떤 결과물을 내놓는가? (What does it hand you at the end?)기존 솔루션 업체들도 인정하는 한계그렇다면, 어떤 선택을 해야할까요?

    Xint

    RSS·Powered by Inblog