XBOW의 AI Security Engineer 로드맵에 Aven을 대입해보기

KISA 2026 정보보호 루키 meet up에서 XBOW가 "AI Security Engineer가 되는 6단계 로드맵"을 발표했다. Foundations(토큰·컨텍스트·프롬프팅) → Build(API·도구 호출) → Agents(에이전트 루프) → Multi-agent(서브에이전트·오케스트레이션·팬아웃) → Extend(MCP·RAG·메모리) → Operate(eval·가드레일·스케일, 최종적으로는 매니저 에이전트가 함대를 지휘하는 자율 SOC). 이 여섯 칸에 Aven을 그대로 대입해보면 재밌는 게, "우리가 지금 몇 단계에 있는가"보다 **"이 단계를 실측 데이터 없이 그냥 통과했다고 우길 수도 있었는데, 반복 측정을 했더니 어디서 발목이 잡히는지가 훨씬 구체적으로 보인다"**는 점이다. 이 글은 Aven을 이 여섯 칸에 하나씩 놓아보고, 각 칸에서 실제로 어떤 숫자가 나왔는지, 그리고 다음 칸으로 가려면 뭘 더 해야 하는지를 정리한다.

Stage 1~2 (Foundations, Build) — 이미 지나온 구간

토큰·컨텍스트·프롬프팅, API/도구 호출·스키마 단계는 Aven의 ISMS 진단 파이프라인(가이드 탐색 → JSON 구조화 → 검증 → 스크립트 생성 → 보고서 생성)과 침투 테스트 파이프라인의 Recon 단계에 이미 녹아있다. 여기서 배운 건 기능 구현 자체보다 **"스키마가 안 맞으면 그 자리에서 바로 재시도하게 만드는 게이트"**였다 — 앞 단계 출력이 다음 단계 입력 스키마와 어긋나면 파이프라인 전체가 오염된다는 걸 초기에 겪고 나서 넣은 안전장치다.

Stage 3 (Agents) — 이미 있음, 근데 안정성 편차가 있다는 걸 이번에 처음 숫자로 봤다

정찰 에이전트(ReAct 스타일: 관측→판단→행동 반복)와, 침투 테스트의 전략 라우팅(solve_smart)이 이 단계다. XBOW 로드맵은 "언제 에이전트가 단순 스크립트를 이긴다"를 이 단계의 핵심 질문으로 던지는데, 우리 실측이 정확히 이 질문에 숫자로 답을 냈다.

에이전트가 스크립트를 이기는 조건은 "관측 정보가 충분할 때"뿐이라는 게 이번에 명확해졌다. 다음 단계로 넘어가기 전에 해야 할 일: 지금 프로빙이 "문자가 제거되는지"만 보고 "문맥 제약"(속성 안인지 스크립트 안인지)까지는 못 봐서 블라인드로 잘못 분류하는 문제가 있었다 — 이 분류 정밀도를 올리는 게 Stage 3을 제대로 졸업하기 위한 다음 과제다.

Stage 4 (Multi-agent) — 도구 분업까지는 됐고, 팬아웃 규모는 아직

Planner가 LLM 계획과 휴리스틱 계획을 병합하고, 14종 Capability로 디스패치하는 구조가 여기 해당한다. sqlmap+LLM tamper 선택 조합이 각각 단독으로는 실패하던 allowlist 우회를 뚫어낸 게 이 단계의 성과다. 다만 XBOW가 그리는 "Multi-agent"는 여러 에이전트가 병렬로 넓게 뻗어나가는(fan-out) 그림인데, Aven은 아직 한 문제에 여러 캐퍼빌리티를 순차·병합하는 수준이지, 여러 타겟·여러 문제를 동시에 병렬 처리하는 스케일까지는 못 갔다. 다음 단계 목표는 이 팬아웃 폭을 넓히는 것 — 다만 이번 실측에서 배운 "LLM 선택은 변동성이 크니 표준 폴백을 항상 깔아둬야 한다"는 원칙을 팬아웃 규모가 커질수록 더 엄격하게 지켜야 할 거라는 게 예상되는 지점이다.

Stage 5 (Extend: MCP·RAG·메모리) — 여기가 지금 우리의 최전선

Aven은 아직 MCP로 외부 도구를 표준화해서 연결하거나, 과거 익스플로잇 시도를 벡터 검색으로 불러오는 장기 메모리를 갖추지 못했다. 지금은 매 실행이 사실상 무상태(stateless)에 가깝다 — 예를 들어 지난주에 특정 WAF 우회에 어떤 tamper 스크립트가 통했는지를 이번 실행이 기억하지 못한다. XBOW 로드맵이 이 단계에서 강조하는 "재사용 가능한 스킬"이 정확히 이 빈틈이다. 기대치: 과거 성공/실패 사례를 RAG로 축적해두면, 지금 사람이 표준 폴백으로 하드코딩해둔 안전망의 상당 부분을 "이전에 이 패턴에서 뭐가 통했는지"를 검색해서 대체할 수 있을 것 — 다만 이것도 도입하자마자 바로 신뢰할 게 아니라, Stage 3에서 배운 대로 반복 측정으로 실제 개선 폭을 확인해야 할 항목이다.

Stage 6 (Operate: 자율 SOC) — 그림은 우리 구조와 같은데, "사람 승인" 게이트가 아직 헐겁다

XBOW 슬라이드에서 유일하게 빨간 박스로 강조된 문구가 "HUMAN APPROVES high-impact"다. 이게 정확히 우리가 "재현되지 않은 단일 관찰"로 분류해둔 사례와 만난다 — 최소한의 정찰 정보만으로 에이전트가 "Redis 웹쉘 → SSRF → php include"라는 3단계 체인을 스스로 발견해 flag를 획득한 그 순간, 사람이 승인해야 할 만큼 파급력이 큰 조치를 에이전트가 스스로 실행까지 끝내버렸는데 그 실행 로그가 저장소에 안 남아있었다. Stage 6에 도달했다고 말하려면 "매니저 에이전트가 함대를 지휘한다"는 아키텍처보다, 그 함대가 무슨 판단을 내렸는지를 사람이 승인 시점에 실제로 확인할 수 있는 로깅이 먼저 갖춰져야 한다는 걸 이번에 배웠다. 지금 Aven의 실제 성숙도는 이 지점에서 Stage 6 그림과 가장 멀리 떨어져 있다.

앞으로의 방향

이 여섯 칸에 대입해보고 나니 다음에 뭘 해야 할지가 훨씬 또렷해졌다.

1. 프로빙 분류 정밀화 (Stage 3 마무리) — 문맥 제약까지 반영해서 blind 오분류를 줄이고, 실패 시 recon 폴백을 추가한다
2. Best-of-N/재시도 정책 — blind 경로의 20~80% 변동성을 다회 시도로 흡수하되 예산 가드와 결합한다
3. MCP·RAG 도입 (Stage 5) — 과거 실행 로그를 장기 메모리로 축적해서, 표준 폴백을 "검색된 과거 성공 사례"로 점진적으로 대체한다
4. 실행 로깅 강화 (Stage 6 진입 조건) — 특히 다단계 체인처럼 파급력이 큰 자율 판단은 재현 가능한 로그로 반드시 남긴다. 이게 없으면 "사람이 승인한다"는 문구 자체가 의미가 없다
5. 다중 provider 교차 검증 — 지금 라우팅 결론이 특정 모델(Gemini)에 묶여있는지 확인하기 위해 Anthropic 경로로도 같은 실험을 반복한다

XBOW의 6단계 로드맵은 "무엇을 갖춰야 하는가"의 지도였고, 우리 실측은 그 지도 위에 "지금 정확히 어디서 흔들리는가"를 좌표로 찍어준 셈이다. Aven이 다음에 성장할 방향은 이 두 개를 겹쳐놓고 나서야 비로소 선명해졌다.

이 글은 KISA 2026 정보보호 루키 meet up에서 촬영한 XBOW 발표 자료(AI Security Engineer 로드맵)와, Aven 프로젝트의 자체 실측 기록을 대조해 정리했다.