🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

이 글은 단일 모델이나 일회성 에이전트 세션이 아니라, 상태를 외부화하고 모델을 교체 가능하게 다루며 탐지·검증·중복 제거·의존성 추적을 이어 붙인 취약점 하네스가 기업 규모 보안 분석에 필요하다고 설명한다.

📌 핵심 요약

• 저자들은 Project Glasswing 이후의 경험을 바탕으로, 선도 모델이 계속 바뀌는 환경에서는 특정 모델·프롬프트·단일 에이전트 세션에 의존하는 방식이 장기적인 보안 워크플로가 될 수 없다고 주장한다.
• 초기에는 약 450줄짜리 보안 감사 skill로 단일 저장소를 분석했지만, 컨텍스트 고갈, 실행 중단 시 작업 손실, 저장소 간 의존성 분석 부재 때문에 실제 기업 규모에서는 별도의 하네스가 필요해졌다.
• 하네스는 Recon, Hunt, Validate 같은 단계를 데이터베이스와 오케스트레이터로 분리해 상태를 보존하고, 각 에이전트가 제한된 범위만 보도록 하며, 발견 결과를 기계적 검증과 독립 검증으로 걸러낸다.
• 전체 워크플로는 취약점 후보를 찾는 Vulnerability Discovery Harness와, 여러 하네스의 결과를 받아 중복 제거·판단·수정으로 이어가는 Vulnerability Validation System으로 나뉘며, 두 시스템은 서로 다른 모델을 사용해 교차 검증한다.
• VDH는 Recon, Hunt, Validate, Gapfill, Dedup, Trace, Feedback, Report 단계로 구성되며, 특히 Gapfill·Trace·Feedback·Dedup이 생산자-소비자 루프처럼 계속 새 작업을 만들고 정리해 늦게 발견된 취약점도 같은 실행 안에서 검증되도록 한다.

🧩 주요 포인트

1. 저자들은 Project Glasswing 이후의 경험을 바탕으로, 선도 모델이 계속 바뀌는 환경에서는 특정 모델·프롬프트·단일 에이전트 세션에 의존하는 방식이 장기적인 보안 워크플로가 될 수 없다고 주장한다.
2. 초기에는 약 450줄짜리 보안 감사 skill로 단일 저장소를 분석했지만, 컨텍스트 고갈, 실행 중단 시 작업 손실, 저장소 간 의존성 분석 부재 때문에 실제 기업 규모에서는 별도의 하네스가 필요해졌다.
3. 하네스는 Recon, Hunt, Validate 같은 단계를 데이터베이스와 오케스트레이터로 분리해 상태를 보존하고, 각 에이전트가 제한된 범위만 보도록 하며, 발견 결과를 기계적 검증과 독립 검증으로 걸러낸다.
4. 전체 워크플로는 취약점 후보를 찾는 Vulnerability Discovery Harness와, 여러 하네스의 결과를 받아 중복 제거·판단·수정으로 이어가는 Vulnerability Validation System으로 나뉘며, 두 시스템은 서로 다른 모델을 사용해 교차 검증한다.
5. VDH는 Recon, Hunt, Validate, Gapfill, Dedup, Trace, Feedback, Report 단계로 구성되며, 특히 Gapfill·Trace·Feedback·Dedup이 생산자-소비자 루프처럼 계속 새 작업을 만들고 정리해 늦게 발견된 취약점도 같은 실행 안에서 검증되도록 한다.

🧠 상세 정리

1. 단일 모델 중심 접근의 한계

글은 Project Glasswing 이후 몇 주 동안 AI 생태계가 빠르게 변했고, 특정 모델에 강하게 묶여 있던 개발자들이 그 모델이 사라지거나 더 강한 모델로 대체되는 상황을 이미 경험했다고 출발한다. 저자들의 핵심 주장은 에이전트형 보안 워크플로의 미래가 독립 모델, 프롬프트, 단일 에이전트 세션에 있지 않다는 것이다. 기업 코드베이스 전체를 지속적으로 스캔하려면 모델을 고정된 주체가 아니라 교체 가능한 구성요소로 취급해야 한다. 하나의 모델만 쓰면 같은 논리와 같은 관점으로 코드 경로를 보게 되므로 방어 범위가 제한된다.

2. 모델 불가지론적 하네스의 필요성

저자들은 초기 발견과 최종 검증에 서로 다른 모델을 배치하는 식으로 파이프라인 안에서 모델을 자주 바꾸고 교차 테스트해야 한다고 설명한다. 이렇게 하면 한 모델이 제기한 취약점 후보가 완전히 다른 논리와 학습 배경을 가진 모델에 의해 다시 평가된다. 또한 실제 기업 환경의 하네스는 단일 저장소 안의 고립된 취약점만 보는 데서 멈추지 않고, 저장소 간 의존성을 따라가며 문제가 다른 소비자 코드에서 어떻게 드러나는지도 추적해야 한다. 목표는 수천 개의 원시 후보를 신뢰할 수 있고 조치 가능한 triage 대기열로 줄이는 것이다.

3. 일반 코딩 에이전트와 subagent만으로는 부족한 이유

저자들은 먼저 일반 코딩 에이전트가 이 일을 잘 수행하기 어렵다고 말한다. 그런 에이전트는 한 번에 하나의 가설만 붙잡고, 실제 저장소의 작은 부분을 살펴본 뒤에도 컨텍스트 창이 차며, 압축 과정에서 중요한 정보를 잃는다. subagent는 유용한 출발점이지만, 보안 분석에는 실행을 넘어 살아남는 수백 개의 독립 조사, 공유하지 않는 컨텍스트, 나중에 다시 범위를 조정하고 상호 참조할 수 있는 상태가 필요하다. 결국 필요한 것은 프롬프트가 아니라 지속성, 중복 제거, 재개 가능성, 의존성 추적을 포함한 오케스트레이션이다.

4. 초기 security-audit skill의 구조

저자들은 처음에 약 450줄짜리 security-audit skill을 단일 저장소에서 실행하며 프롬프트를 조정했고, 실제 버그가 드러날 때까지 반복했다. 이 skill은 한 세션 안에서 7단계 감사를 수행했다. 세 개의 병렬 연구 에이전트가 정찰을 수행하고 architecture.md를 작성하며, 공격 클래스마다 Hunter 에이전트가 코드를 리뷰하기보다 깨뜨리려는 방식으로 접근했다. 이후 adversarial validator가 각 발견을 반박하려고 시도하고, 살아남은 결과는 사람이 읽을 수 있는 보고서와 findings.json으로 정리되며, 마지막에는 새 에이전트가 소스에 대해 독립적으로 재검증했다.

5. skill에서 하네스로 넘어가게 만든 세 가지 벽

초기 skill은 나중의 하네스와 거의 일대일로 대응했지만, 곧 한계가 드러났다. 단일 실행은 여러 번 실행했을 때 잡을 수 있는 버그의 절반 정도만 찾았고, 그마저도 더 단순하고 덜 미묘한 문제에 치우쳤다. 저자들이 만난 첫 번째 벽은 컨텍스트 고갈로, 한 시간 정도 지나면 모델이 자신이 추적하던 버그를 잊어버리는 문제가 생겼다. 두 번째는 실행 중 충돌이나 rate-limit 오류가 나면 처음부터 다시 해야 하는 지속성 문제였고, 세 번째는 단일 저장소 세션이 소비 애플리케이션과의 관계를 보지 못하는 cross-repo reasoning의 부재였다.

6. 최소 하네스에 대한 실용적 조언

저자들은 처음부터 모든 기능을 갖춘 대형 시스템을 만들라고 권하지 않는다. 실제적이면서도 최소한의 하네스는 데이터베이스에 보존되는 Recon, Hunt, Validate 단계와, 스스로 발견을 제출할 수 없는 별도의 Validator만으로도 시작할 수 있다고 말한다. 의미 있는 저장소가 둘 이상이 되기 전에는 cross-repo tracing을 건너뛰고, 노이즈에 실제로 압도되기 전에는 전용 Deduplication agent도 미루라고 조언한다. 먼저 개발 환경에서 skill을 만들고 프롬프트가 잘 작동하게 한 뒤, 특정 아키텍처 단계가 없어서 작업이 느려질 때만 다음 단계를 추가하라는 접근이다.

7. fleet scanner로의 기계적 전환

저자들은 단일 저장소나 선별된 벤치마크가 아니라, 여러 언어와 설정 시스템이 섞인 전체 코드베이스를 대상으로 해야 했다. 이 환경에는 Rust, Go, C, Lua, TypeScript, Python, 설정 관리 시스템, 정적 설정과 다양한 추가 맥락이 포함됐다. slash-command 기반의 첫 실행에서 128개 저장소를 커버하고 관련 의존성을 자동으로 찾아 조사하는 fleet scanner로 확장하는 데 약 6주가 걸렸다. 전환 자체는 대부분 기계적이었고, skill의 각 단계를 독립 에이전트로 들어 올린 뒤 뒤에는 데이터베이스를 두고 앞에는 오케스트레이터를 배치하는 방식이었다.

8. VDH와 VVS의 두 단계 검증 구조

전체 취약점 연구 워크플로는 Vulnerability Discovery Harness와 Vulnerability Validation System이라는 두 단계 운영 구조로 나뉜다. VDH는 코드베이스를 능동적으로 스캔해 잠재적 보안 문제를 찾는 발견 엔진이고, VVS는 여러 하네스에서 들어온 버그를 받아 중복 제거, 판단, 수정 단계로 넘기는 시스템이다. 저자들은 VDH와 VVS에 서로 다른 모델을 사용해 한 모델의 결과를 다른 모델이 평가하게 한다. 이는 보안적으로는 편향을 줄이는 adversarial third party 역할을 만들고, 운영적으로는 모델 제공자의 온도, 캐싱, 추론 예산 변화 같은 변동성을 하네스가 흡수하게 만든다.

9. VDH 내부 단계와 지속 실행 루프

VDH는 Recon, Hunt, Validate, Gapfill, Dedup, Trace, Feedback, Report로 구성된다. Recon은 대상 아키텍처와 위협 벡터를 매핑하고, Hunt는 공격 클래스별로 코드를 깨뜨리려 하며, Validate는 스키마와 경로를 기계적으로 확인한 뒤 격리된 에이전트가 발견을 반박하도록 한다. Gapfill은 비어 있거나 얇게 테스트된 영역과 공격 클래스 조합에 새 hunt 작업을 만들고, Dedup은 같은 근본 원인에 속한 발견을 묶으며, Trace는 의존성 그래프를 따라 소비 저장소 안에 새 작업을 추가한다. Feedback은 검증 실패, 얕은 실행, 반복 누락을 바탕으로 대기 중인 프롬프트를 더 날카롭게 고친다.

10. 컨텍스트 통제와 지속성 설계

저자들은 파이프라인을 쪼개는 이유가 엄격한 컨텍스트 통제를 보장하기 위해서라고 설명한다. 컨텍스트 창이 차면 모델은 환각을 시작할 수 있으므로, 각 에이전트의 일을 매우 좁게 제한해 전체 창의 25% 미만만 사용하도록 한다. 모든 파일을 읽는 순진한 방식은 이 한계를 매번 넘기 때문에 적합하지 않다. 또한 병렬성보다 지속성을 먼저 고려해야 하며, 각 단계는 run_id, repo, stage를 키로 하는 하나의 SQLite 데이터베이스에 기록되어 재개, 재시도, 이후 실행으로의 이전이 가능하게 설계된다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 더 강한 단일 모델을 고르는 문제가 아니라, 모델이 바뀌어도 지속되는 상태 관리와 검증 구조를 만드는 문제라는 점이다.
• 보안 분석에서 컨텍스트 창은 단순한 비용 문제가 아니라 발견의 보존성과 정확도에 직접 영향을 주는 시스템 설계 제약으로 다뤄진다.
• 저자들은 완성형 대형 플랫폼보다 작은 skill에서 출발해 실제 병목이 드러날 때 Recon, Hunt, Validate, Dedup, Trace 같은 단계를 단계적으로 추가하는 방식을 권한다.

✅ 액션 아이템

• 모델·프롬프트·단일 에이전트 세션 의존 체계를 점검하고 상태를 외부화하는 하네스 전환 방향으로 워크플로 적합성을 판단한다.
• Recon·Hunt·Validate를 오케스트레이터와 데이터베이스로 분리해 에이전트 관측 범위를 제한하고 탐지 후 기계적·독립 검증 단계를 거치게 구성한다.
• VDH의 Recon·Hunt·Validate·Gapfill·Dedup·Trace·Feedback·Report 흐름을 붙여 다수 하네스 결과의 중복 제거, 판단, 수정을 단일 실행 내에서 정리한다.

❓ 열린 질문

• 두 모델로 분리한 Discover/Validation 교차 검증에서 어떤 기준으로 모델 교체 시점을 트리거하고 신뢰도를 판단할 것인가?
• 실행 중단 시 작업 손실이 발생하는 구간은 어디이며, 상태 저장·복구는 어떤 단계에서 재개되어야 하는가?
• 초기 단일 450줄 skill과 비교해 하네스 적용 시 컨텍스트 고갈·저장소 간 의존성 누락은 어떤 지표로 실제로 감소했는지 어떻게 측정할 것인가?