Microsoft가 2026년 5월 Patch Tuesday와 함께 공개한 MDASH는 보안팀이 AI를 어떻게 써야 하는지 꽤 선명한 답을 줍니다. 핵심은 “좋은 모델 하나”가 아니라, 취약점 탐색 과정을 여러 단계로 쪼개고 각 단계에 맞는 에이전트와 검증 장치를 붙인 운영 시스템입니다.
Microsoft 설명에 따르면 MDASH는 Windows 네트워킹·인증 스택에서 16개 신규 취약점을 찾는 데 쓰였고, 그중 4개는 Critical 원격 코드 실행 취약점입니다. 비공개 테스트 드라이버에서는 심어둔 21개 취약점을 모두 찾았고 false positive가 없었다고 밝혔습니다. CyberGym 벤치마크에서는 1,507개 실제 취약점 기준 88.45% 점수를 기록했다고 합니다.
개발팀 입장에서 이 뉴스가 중요한 이유는 단순합니다. AI 보안 도구를 도입할 때 “모델이 코드를 잘 읽는가”만 보면 실패합니다. 실제 제품 코드에서는 탐색 범위, 증거 수집, 재현, 중복 제거, 소유자 라우팅, 패치 검증까지 이어져야 합니다.
MDASH의 파이프라인은 크게 prepare, scan, validate, dedup, prove 단계로 설명됩니다. Prepare 단계에서는 코드베이스를 인덱싱하고 공격 표면과 과거 커밋을 바탕으로 threat model을 만듭니다. Scan 단계에서는 전문 auditor agent가 후보 취약점을 냅니다. Validate 단계에서는 debater agent가 해당 취약점이 실제로 도달 가능한지, exploitable한지 반박합니다.
Dedup 단계는 같은 원인을 가진 보고서를 묶습니다. 보안팀에서 이 단계는 생각보다 중요합니다. AI가 만든 리포트가 200개인데 실제로는 같은 버그의 변형 12개라면 triage 비용이 폭발합니다. 마지막 prove 단계에서는 조건이 맞으면 triggering input을 만들고 동적으로 증명합니다. C/C++ 계열에서는 ASan 같은 런타임 검증과 연결될 수 있습니다.
이 흐름은 일반 개발팀의 정적 분석 자동화에도 그대로 적용됩니다. 코드 품질, 권한 검사, API 호환성, 마이그레이션 리스크 탐지도 “발견”과 “증명”을 분리해야 합니다. 발견 에이전트가 빠르게 넓게 훑고, 검증 에이전트가 좁게 깊게 들어가야 운영 가능합니다.
단일 프롬프트로 “이 코드에서 취약점을 찾아줘”라고 하면 결과가 좋아 보여도 운영에 넣기 어렵습니다. 첫째, 모델이 왜 그 경로를 봤는지 추적하기 어렵습니다. 둘째, 놓친 범위를 알 수 없습니다. 셋째, false positive가 triage 시간을 잡아먹습니다. 넷째, 재현 가능한 증거가 없으면 보안팀과 개발팀 사이에서 핑퐁이 생깁니다.
MDASH가 여러 모델과 100개 이상 전문 에이전트를 둔 이유는 각 역할이 다르기 때문입니다. Auditor는 의심 지점을 찾습니다. Debater는 반박합니다. Prover는 실행 가능한 입력을 만듭니다. Domain plugin은 커널 호출 규약, IRP 규칙, lock invariant, IPC trust boundary 같은 모델이 기본적으로 모르는 지식을 넣습니다.
실무에서는 이 구조를 작게 시작할 수 있습니다. 예를 들어 웹 서비스라면 auditor는 “인증 우회 가능성”, “tenant id 누락”, “unsafe redirect”, “SQL/NoSQL injection”처럼 규칙별로 나눕니다. Debater는 라우터, middleware, schema validator를 따라가며 실제 도달성을 확인합니다. Prover는 curl, unit test, Playwright, property-based test 중 하나로 증거를 남깁니다.
첫째, AI 보안 스캔의 출력은 “의심”과 “확정”을 분리해야 합니다. 의심은 많아도 괜찮지만 확정 리포트에는 재현 경로, 영향 범위, 최소 패치 방향이 있어야 합니다.
둘째, 코드베이스별 지식을 plugin 또는 rule pack으로 관리해야 합니다. 우리 회사의 인증 미들웨어, tenant 분리 방식, payment callback 규칙, feature flag 정책은 범용 모델이 자동으로 알 수 없습니다. 이 지식을 프롬프트에 매번 붙이는 대신 파일화해야 재사용됩니다.
셋째, false positive 예산을 정해야 합니다. 보안 자동화는 많이 찾는 것보다 사람이 처리할 수 있는 큐를 만드는 게 중요합니다. 하루에 triage 가능한 건 10건인데 200건을 쏟아내면 자동화가 아니라 노이즈입니다.
넷째, 증거 아티팩트를 표준화해야 합니다. 좋은 리포트는 affected file, call path, input condition, reproduction command, expected/actual behavior, suggested owner를 포함합니다. AI가 만든 장문의 설명보다 이 필드들이 더 중요합니다.
다섯째, 패치 검증까지 포함해야 합니다. 취약점 발견만 자동화하면 개발자는 “고쳤다”고 말하고 보안팀은 다시 확인해야 합니다. 에이전트가 regression test 또는 exploit test를 남기면 다음 릴리즈에서도 같은 버그가 돌아오는지 확인할 수 있습니다.
대기업처럼 100개 에이전트부터 만들 필요는 없습니다. 오히려 작은 팀은 좁은 규칙 3개로 시작하는 편이 낫습니다. 추천 시작점은 인증, 멀티테넌시, 외부 입력 검증입니다. 이 세 가지는 SaaS 제품에서 사고 비용이 크고, 코드 패턴도 비교적 명확합니다.
1주 차에는 과거 장애나 보안 리뷰에서 반복된 패턴을 10개 모읍니다. 2주 차에는 각 패턴마다 “탐색 프롬프트”와 “검증 체크리스트”를 만듭니다. 3주 차에는 CI가 아니라 PR 리뷰 보조로만 돌립니다. 4주 차에 false positive 비율과 개발자 수용률을 보고 CI 차단 여부를 결정합니다.
바로 main branch를 막는 도구로 넣으면 반발이 큽니다. 처음에는 comment-only 모드로 두고, 사람이 “유효함/무효함/나중에”를 태깅하게 하세요. 이 피드백이 쌓이면 rule pack과 prompt가 개선됩니다.
MDASH의 메시지는 분명합니다. AI 보안의 경쟁력은 모델 이름이 아니라 파이프라인 설계입니다. 개발팀도 지금부터 “코드를 읽는 AI”가 아니라 “증거를 남기고 검증 가능한 AI 보안 워크플로”를 만들어야 합니다.
