strix 멀티 에이전트 아키텍처 해부: XBEN 벤치마크 96%와 DevSecOps 통합

정적 분석(SAST)은 소스코드 패턴 매칭에 의존하기 때문에 오탐(false positive)이 잦고, 동적 분석(DAST)은 HTTP 요청·응답만 들여다보느라 여러 취약점이 얽힌 공격 체인을 놓친다. strix는 이 두 방식과 다른 길을 택한 오픈소스 침투테스트 도구다. 자율 AI 에이전트가 코드를 직접 실행해 취약점을 찾고, 실제로 동작하는 PoC(Proof-of-Concept) 익스플로잇을 만들어 그 취약점이 진짜인지 검증까지 끝낸다.

라이선스는 Apache-2.0, 저장소는 usestrix/strix이며 이 글이 다루는 버전은 v0.4.0(2026년 기준)이다. 탐지에서 멈추지 않고 익스플로잇 생성·검증까지 자동화한다는 점이 기존 도구와 갈라서는 지점이다.

항목	정적 분석(SAST)	동적 분석(DAST)	strix
분석 방식	소스코드 패턴 매칭	HTTP 요청/응답 분석	자율 에이전트 실행
오탐률	높음	중간	낮음 (PoC 검증)
복합 취약점	미탐지	제한적	체인 공격 탐지 가능
컨텍스트 이해	제한적	없음	LLM 기반 추론
자동 수정 제안	일부 지원	미지원	지원

단일 AI가 아니라 에이전트 그래프

strix의 설계 핵심은 하나의 AI가 모든 일을 처리하는 방식을 버리고, 전문화된 에이전트를 그래프로 엮어 병렬로 협업시키는 데 있다.

⤢✕

**Manager(The Brain)**는 대상 시스템을 분석해 고수준 목표를 세분화된 태스크로 쪼개고, 컨텍스트에 맞춰 도구와 에이전트를 동적으로 배정하며 전체 워크플로우를 조율한다. 여기서 나온 결과는 다시 Manager로 모여 통합된다.

Surface Agent는 대상 애플리케이션의 엔드포인트, 파라미터, 인증 경로를 탐색해 API 스키마와 라우트 구조, 입력 필드를 자동으로 식별하고 공격 가능 영역의 우선순위를 매긴다. 이렇게 매핑된 공격 표면은 Vulnerability Agent로 넘어가 SQL Injection, XSS, CSRF, SSRF 등 카테고리별 전문 탐지가 이루어진다. 이 단계에서는 HTTP 프록시와 브라우저 드라이버를 활용한 동적 테스트가 병행되고, 결과는 구조화된 형태로 다음 단계에 전달된다.

발견된 취약점 후보는 Exploit Agent가 넘겨받아 실제 PoC 익스플로잇을 만든다. 터미널 세션과 Python 런타임에서 코드를 직접 실행해 취약점이 실제로 악용 가능한지, 영향도는 어느 정도인지를 확인하는 단계다. 마지막으로 Report Agent가 검증된 취약점에 대한 상세 보고서를 자동 생성하는데, 재현 단계·영향 범위·수정 권고사항을 담고 SARIF나 JSON 같은 표준 형식으로도 출력한다.

Think-Plan-Act-Observe: 스크립트가 아니라 루프

strix의 각 에이전트는 정해진 순서대로 흘러가는 선형 스크립트가 아니라 인지적 루프(cognitive loop)로 동작한다.

⤢✕

Think 단계에서 LLM이 지금까지 수집한 정보와 이전 행동의 결과를 종합하고, Plan 단계에서 어떤 도구를 쓸지·어떤 페이로드를 시도할지 다음 행동을 추론한다. Act 단계는 HTTP 요청 전송, 브라우저 조작, 터미널 명령 실행 같은 실제 행동이고, Observe 단계는 그 결과를 관찰해 새 정보를 다시 컨텍스트에 반영한다. 이 루프 덕분에 strix는 공격 전략을 실시간으로 조정할 수 있다. 예를 들어 SQL Injection 시도가 WAF(Web Application Firewall)에 걸리면, 자동으로 우회 기법을 적용하거나 다른 공격 벡터로 전환한다.

XBEN 벤치마크: 104개 중 100개

strix v0.4.0은 XBEN 벤치마크에서 업계 최고 수준의 성과를 기록했다. XBEN은 104개의 웹 보안 챌린지로 구성된 CTF 형식 벤치마크로, 평가 기준이 단순 탐지가 아니라 실제 익스플로잇을 통한 플래그 추출이다. 난이도는 실제 침투 테스트 시나리오를 기반으로 한 다양한 공격 유형을 포괄한다.

지표	수치
해결 챌린지	100 / 104
성공률	96%
평균 풀이 시간	약 19분 / 챌린지

96%라는 성공률은 strix가 단순 패턴 매칭이 아니라 실질적인 공격 경로 추론(reasoning)을 수행하고 있음을 보여준다.

DevSecOps 파이프라인에 끼워 넣기

strix는 개발자 우선(developer-first) CLI를 제공해 기존 CI/CD 파이프라인에 쉽게 통합된다.

⤢✕

실행 환경은 두 갈래다. 로컬 실행은 Docker 기반 샌드박스에서 모든 처리가 이루어져 코드나 민감 데이터가 외부로 유출되지 않는다. usestrix.com에서 제공하는 호스팅 버전은 대규모 팀을 위한 성능과 통합 기능을 강화한 관리형 서비스다. 어느 쪽이든 각 스캔 세션이 독립된 Docker 컨테이너에서 실행돼 대상 시스템에 미치는 영향을 최소화한다.

파이프라인에 실제로 붙이려면 몇 가지를 미리 정해야 한다. 대상 URL·API 엔드포인트·인증 정보를 사전 구성하고, 프로덕션 데이터 접근이 제한되는 테스트 제외 영역을 명확히 정의해야 한다. 결과 처리 정책으로는 Critical/High 취약점 발견 시 빌드 차단 임계값을 설정하고, 자동 수정 제안(auto-fix)을 쓸지 결정하며, 보안 팀 알림과 이슈 트래커 연동 여부도 정해야 한다. 리소스 측면에서는 AI 에이전트 실행에 충분한 Docker CPU/메모리 할당이 필요하고, 스캔 빈도와 범위에 따라 LLM API 호출 비용도 계획해야 한다.

어디에 쓸 수 있나

AI 코드 생성 도구로 빠르게 작성된 코드의 보안 품질을 검증하는 바이브 코딩 보안 검증이 첫 번째 활용처다. strix가 생성된 코드를 대상으로 자율적으로 침투 테스트를 수행해 개발 속도를 유지하면서도 보안 수준을 확보한다.

문서화가 부족한 레거시 웹 애플리케이션에서는 Surface Agent가 자동으로 공격 표면을 매핑하고, Vulnerability Agent가 알려진 취약점 패턴과 제로데이 가능성을 동시에 탐색하는 레거시 시스템 보안 감사에 쓸 수 있다.

REST/GraphQL API를 대상으로는 인증 우회, 권한 상승, IDOR(Insecure Direct Object Reference) 같은 API 특화 취약점을 자율적으로 탐지하고 PoC를 생성하는 API 보안 테스트가 세 번째 시나리오다.

한계는 분명히 있다

기반 LLM의 성능과 비용에 결과가 직접 좌우된다는 점, LLM API 접근이 필요해 에어갭(air-gapped) 환경에서는 쓰기 어렵다는 점이 우선 걸린다. 결제 로직 우회 같은 도메인 특화 취약점은 별도 컨텍스트 제공이 필요하고, 무엇보다 반드시 인가된 대상에만 사용해야 한다 — 비인가 시스템 테스트는 불법이다.

XBEN 벤치마크에서의 96% 성공률은 LLM 기반 보안 에이전트가 이미 실용적인 수준에 도달했음을 보여준다. 탐지부터 PoC 검증까지 전 과정을 자동화한 strix를 DevSecOps 파이프라인에 통합하면 개발 속도와 보안 품질을 동시에 챙길 여지가 생긴다.