AI·기술
스캐너에서 에이전트로 — 데이브레이크가 보안 스타트업의 해자를 무너뜨린다
게시일: 2026-06-25
오픈AI가 사이버보안 프로그램 데이브레이크를 확장하며 코덱스 보안 플러그인, GPT-5.5-Cyber 정식 출시, 핵심 오픈소스를 겨냥한 ‘패치 더 플래닛’ 이니셔티브를 함께 내놨다. GPT-5.5-Cyber는 사이버짐 벤치마크에서 85.6%로 단일 모델 최고치를 기록했고, 3,000만 줄이 넘는 리눅스 커널에서 정보 유출 PoC 8건과 로컬 권한 상승 익스플로잇 24건을 직접 만들어냈다. 핵심은 도구가 ‘경고를 띄우는 스캐너’에서 ‘찾고 검증하고 패치하는 에이전트’로 넘어갔다는 점이다.
무슨 일이 있었나
데이브레이크는 네 조각으로 묶여 있다. 첫째는 코덱스 보안 플러그인이다. 코드베이스 전체든, 선택한 일부든, 커밋 하나든 스캔해서 보고서를 낸다. 보고서에는 심각도 등급, 영향받는 코드 위치, 근거, 그리고 수정 방안이 함께 담긴다. 단순히 줄을 표시하는 데서 그치지 않고 공격 경로를 추적하고 위협 모델을 세우며, 발견한 내용을 검증한 뒤 사람이 검토할 패치를 생성한다. 둘째는 GPT-5.5-Cyber 모델의 정식 출시다. 이 모델은 사이버짐에서 85.6%를 기록했는데, 단일 모델로는 지금까지 나온 최고 점수다. 리포지토리를 분석해 보안에 민감한 구성요소를 찾고, 취약한 코드가 실제로 도달 가능한지 판단하고, 검증한 뒤 패치를 개발·테스트하고, 사람 검토용 근거까지 준비한다.
셋째는 패치 더 플래닛이다. AI 기반 취약점 발견과 패치를 핵심 오픈소스에 적용하는 이니셔티브로, 트레일 오브 비츠·해커원과 함께 만들었다. AI 스캔과 인간 전문가 검토를 짝지운다는 점이 설계의 중심이다. cURL, 파이썬, Go, 시그스토어, pyca/cryptography를 포함해 30개 이상 프로젝트가 참여를 약속했다. 넷째는 기업이 이 역량을 끌어다 쓰는 통로인 데이브레이크 사이버 파트너 프로그램이다. 가장 눈에 띄는 결과는 리눅스 커널 사례다. 3,000만 줄이 넘는 코드 위에서 GPT-5.5-Cyber는 보안 관련 구성요소를 짚어내고 동적으로 검증해, 커널 포인터 정보 유출 PoC 8건과 로컬 권한 상승 익스플로잇 24건을 만들어냈다. 심각도 라벨이 아니라 작동하는 익스플로잇이라는 점이 이전 도구들과 다르다.
창업자에게 의미하는 것
보안 스타트업에 이건 경계선이 움직였다는 신호다. 지난 몇 년간 적지 않은 보안 제품의 실체는 오픈소스 스캐너를 감싼 래퍼였다. 패턴을 매칭하고, 심각도를 매기고, 대시보드에 띄우는 일을 깔끔한 UI와 통합으로 포장한 것이다. 그 층은 이제 모델 안으로 빨려 들어간다. 찾는 데서 멈추지 않고 도달 가능성을 따지고, 검증하고, 패치까지 만들어 내는 에이전트 앞에서 ‘경고를 잘 띄우는’ 제품의 차별점은 얇아진다. 해자를 다시 그어야 한다. 도메인 특화 위협 모델, 특정 컴플라이언스 체계에 맞춘 워크플로, 고객 환경에 깊이 박힌 운영 데이터처럼 범용 모델이 쉽게 복제하지 못하는 곳으로 가치를 옮겨야 한다.
동시에 모든 창업자에게는 자기 회사의 보안 자세 문제이기도 하다. 제품에 실어 보내는 오픈소스 의존성은 이제 양쪽에서 같은 속도로 다뤄진다. 방어자가 기계 속도로 패치를 만들 수 있다면, 공격자도 같은 종류의 도구로 기계 속도로 익스플로잇을 만든다. 리눅스 커널에서 나온 익스플로잇 24건이 그 증거다. cURL이나 파이썬처럼 당신 스택 밑바닥에 깔린 라이브러리가 패치 더 플래닛 대상에 올라 있다는 건, 거기서 나온 수정이 곧 당신에게도 영향을 준다는 뜻이다. 그리고 잊지 말아야 할 한 줄은 여전히 사람이 고리 안에 있다는 사실이다. 코덱스는 패치를 ‘생성’하지만 사람이 ‘검토’하고, 패치 더 플래닛은 AI 스캔에 인간 전문가 검토를 반드시 짝짓는다. 자율 패치가 아니라 검증을 거친 제안이다.
지금 취할 수 있는 행동
먼저 자기 제품이 ‘스캐너 래퍼’인지 정직하게 점검하라. 핵심 가치가 탐지 자체에 있다면, 그 가치는 모델 쪽으로 빠르게 흡수되는 중이다. 검증·재현·패치라는 다음 단계 중 어디에 고유한 강점을 둘 수 있는지 다시 정의하라. 둘째, 의존성 그래프를 실물로 그려라. 당신이 출하하는 코드가 cURL·파이썬·Go 등 패치 더 플래닛 대상에 얼마나 의존하는지 알면, 상류에서 나온 패치를 며칠이 아니라 몇 시간 안에 받아들일 파이프라인을 준비할 수 있다. 셋째, 코덱스 보안 플러그인 같은 에이전트형 도구를 적이 아니라 자기 코드베이스에 먼저 돌려보라. 커밋 단위 스캔으로 자기 약점을 기계 속도로 먼저 찾는 쪽이 유리하다. 넷째, 사람 검토 단계를 워크플로에 명시적으로 박아라. 모델이 만든 패치를 무검토로 병합하지 말고, 누가 무엇을 근거로 승인했는지 남기는 절차를 만들어라. 다섯째, 벤치마크 숫자에 끌려가지 마라. 85.6%는 인상적이지만 특정 벤치마크 위 점수다. 당신 코드베이스에서의 실제 적중률과 거짓 양성률은 직접 돌려봐야 안다.
참고 자료