보안팀의 문제는 "취약점을 못 찾는다"가 아니라 "너무 많이 나오고, 진짜 위험한 것을 가릴 시간이 없다"에 가깝습니다. 여기에 에이전트형 AI가 들어오면 부담을 줄일까요, 아니면 더 빠르고 그럴듯한 알림 공장을 만들까요.
최근 Microsoft의 MDASH가 중요한 이유는 성능 순위표 하나 때문만은 아닙니다. 100개가 넘는 AI 에이전트를 역할별로 나눠 Windows 취약점을 찾고 검증했다는 점에서, 취약점 관리가 '스캐너 구매'에서 'AI 조사팀 운영'으로 바뀔 수 있음을 보여줍니다.1
MDASH의 핵심은 "똑똑한 모델"보다 "분업 구조"다
MDASH는 Multi-Model Agentic Scanning Harness의 약자입니다. Microsoft 설명에 따르면 이 시스템은 단일 LLM에 코드를 던지는 방식이 아니라, 준비·스캔·검증·중복 제거·증명 생성 같은 단계를 나눠 처리합니다.2
예를 들어 한 에이전트는 의심스러운 코드 경로를 찾고, 다른 에이전트는 그 주장이 실제로 도달 가능한지 반박합니다. 또 다른 에이전트는 입력값을 만들어 취약점이 실제로 터지는지 확인합니다. 복잡한 추론에는 고성능 모델을, 대량 검증에는 경량화된 모델을 쓰는 식입니다.
이 구조가 중요한 이유는 보안 업무의 병목이 단순 탐지가 아니기 때문입니다. 실무에서는 다음 질문이 더 어렵습니다.
이 취약점이 실제 공격 경로에 있는가
기존 취약점과 중복인가
재현 가능한 증거가 있는가
패치가 문제를 막았는가
지금 당장 고쳐야 하는가
MDASH가 겨냥하는 지점은 바로 이 중간 작업입니다. 즉, 사람을 대체한다기보다 숙련된 보안 연구원이 하던 반복적 조사와 검증을 병렬화하려는 시도에 가깝습니다.
100개 에이전트는 강점이지만, 새로운 리스크도 만든다
Microsoft는 MDASH가 Windows 네트워킹·인증 스택에서 16개 신규 취약점을 찾았고, 이 중 4개가 Critical 등급의 원격 코드 실행 취약점이었다고 밝혔습니다.2 또 의도적으로 21개 취약점을 심은 비공개 테스트 드라이버에서 21개를 모두 찾고 오탐은 없었다고 설명했습니다.2
공개 벤치마크 CyberGym에서는 1,507개 실제 취약점 재현 과제 기준 88.45%를 기록해 Anthropic Mythos와 OpenAI 계열 시스템보다 앞섰다는 결과도 제시됐습니다.2
다만 이 수치를 그대로 "우리 환경에서도 오탐이 없다"로 해석하면 위험합니다. 벤치마크와 실제 기업 코드베이스는 다릅니다. 사내 프레임워크, 오래된 빌드 체계, 접근 권한, 비공개 라이브러리, 규제 데이터가 얽히면 탐지율과 재현율은 달라질 수 있습니다.
멀티 에이전트 구조에는 분명 장점이 있습니다. 여러 가설을 병렬로 세우고, 서로 반박하며, 모델 간 불일치를 신호로 쓸 수 있습니다. 하지만 반대로 조정 실패, 중복 리포트, 설명 불가능한 결론, "여러 AI가 동의했으니 맞겠지"라는 과신도 생길 수 있습니다.
보안 리더가 봐야 할 질문은 "AI가 얼마나 똑똑한가"가 아닙니다. "이 시스템의 판단을 사람이 감사하고 되돌릴 수 있는가"입니다.
도입 전에 물어야 할 질문들
MDASH류 도구를 검토한다면 데모 점수보다 운영 조건을 먼저 확인해야 합니다.
첫째, 결과가 재현 가능한가. 취약점 리포트가 자연어 설명에서 끝나면 기존 스캐너보다 조금 세련된 알림일 뿐입니다. 안전한 PoC, 트리거 입력, 빌드 로그, 실패 조건이 함께 있어야 합니다.
둘째, 코드와 데이터가 어디로 가는가. Windows 같은 대형 벤더 내부에서는 폐쇄된 환경 구성이 가능하지만, 일반 기업은 소스코드 유출과 모델 학습 사용 여부를 따져야 합니다.
셋째, 오탐 처리 비용을 누가 부담하는가. "AI가 찾았다"는 이유로 개발팀이 매번 조사해야 한다면 보안팀과 개발팀의 관계는 더 나빠집니다.
넷째, 패치 검증까지 이어지는가. 앞으로 차이는 취약점을 빨리 찾는 데서 끝나지 않습니다. 고친 코드가 실제로 공격 경로를 차단했는지 확인하는 능력이 핵심이 됩니다.
앞으로의 경쟁력은 "발견"보다 "우선순위 판단"에 있다
MDASH가 예고하는 변화는 명확합니다. 취약점 발견은 더 상시화되고, Patch Tuesday 같은 주기적 패치 이벤트는 더 빽빽해질 수 있습니다. 공격자도 비슷한 자동화 도구를 쓸 수 있기 때문에 방어자는 더 빨리 찾아야 하고, 더 빨리 고쳐야 합니다.
하지만 모든 조직이 당장 100개 AI 에이전트를 운영해야 한다는 뜻은 아닙니다. 지금 필요한 준비는 세 가지입니다. 코드 소유권과 빌드 재현성을 정리하고, 취약점 triage 기준을 문서화하며, AI가 낸 결론을 검토할 보안 엔지니어의 역할을 새로 정의하는 일입니다.
MDASH는 화려한 AI 발표라기보다 취약점 관리 업무의 형태가 바뀌고 있다는 신호입니다. 앞으로 보안팀의 경쟁력은 "AI가 몇 개를 찾았는가"가 아니라 "AI가 찾은 것 중 무엇을 오늘 고칠지 판단할 수 있는가"에서 갈릴 가능성이 큽니다.
참고
1Microsoft pits more than 100 AI agents against each other to find Windows vulnerabilities
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.