MDASH 내부 들여다보기: Microsoft 규모의 멀티 모델 에이전트 기반 사이버 방어 벤치마크 설계

CoreProse KB-incidents에 처음 게시됨

에이전트 기반 LLM (Agentic LLMs)은 이미 보안 운영의 핵심 경로에 자리 잡고 있습니다: SIEM 경고 보강, SOAR 플레이북 실행, 코드 검토 및 방화벽 변경 제안 등이 그 예입니다. 하지만 많은 팀이 여전히 이들을 엔드 투 엔드(end-to-end), 멀티 모델(multi-model), 안전 필수(safety-critical) 시스템이 아닌, 단일 프롬프트 정확도 기반의 챗봇처럼 측정하고 있습니다. MDASH 방식의 벤치마크(Multi-model, Data-driven, Agentic Security Harness)는 이를 변화시킵니다. 이 방식은 SOC(Security Operations Center)와 SDLC(Software Development Life Cycle)를 하나의 방어 체계로 취급하며, 데이터 계층부터 도구 호출(tool calls)에 이르기까지 전체 아키텍처를 실제적인 공격, 노이즈 및 거버넌스 제약 조건 하에서 평가합니다.[2][3]

이 글의 목표
이 가이드는 다음과 같은 벤치마크를 설계하는 방법을 설명합니다:

• 왜 지금 MDASH 방식의 벤치마크가 중요한가
• 참조용 멀티 에이전트 아키텍처 (reference multi-agent architecture)
• 위협 모델 및 시나리오 설계
• 지표 및 방법론
• 구현 청사진
• 거버넌스 및 배포 고려 사항

1. 왜 MDASH 방식의 멀티 모델 에이전트 기반 사이버 방어 벤치마크가 중요한가
   전통적인 SOC 역량은 분석가의 인원수와 전문성에 따라 확장되었습니다: 더 많은 텔레메트리(telemetry)는 더 많은 인력 또는 더 많은 경고 누락을 의미했습니다.[2] LLM 기반의 SOC는 이러한 곡선을 깨뜨리며, 병목 현상을 데이터 아키텍처와 오케스트레이션(orchestration) 품질로 전환합니다.[3]

LLM이 강화된 SOC의 증거에 따르면 단일 모델이 다음과 같은 작업을 수행할 수 있음을 보여줍니다:

• 대량의 로그 볼륨 상관관계 분석
• 텔레메트리와 위협 인텔리전스(threat intel)의 융합
• 1분 이내에 고충실도(high-fidelity) 사고 요약 생성[3]

이전에는 이러한 작업에 시니어 분석가의 시간이 수 시간 소요되었습니다. 따라서 측정 방식은 '고립된 모델 품질'에서 탐지 시간(time-to-detect) 및 대응 시간(time-to-respond)에 미치는 시스템 수준의 영향으로 이동해야 합니다. 또한 공급업체들은 악성코드 분류(malware triage), 역공학(reverse engineering) 및 핵심 인프라 방어에 최적화된 Trusted Access for Cyber (TAC)를 갖춘 GPT-5.5 및 GPT-5.5-Cyber와 같은 사이버 특화 스택을 출시하고 있습니다.[4][6] 이제 우리는 단순한 프롬프트 엔지니어링(prompt engineering)이나 단일 턴 QA(single-turn QA)가 아닌, 에이전트 기반 시스템 설계를 비교하는 벤치마크가 필요합니다.

새로운 공격 표면
에이전트 기반 AI(Agentic AI) 자체가 하나의 공격 표면(attack surface)입니다.

에이전트: 도구 호출 및 코드 실행

• SIEM, EDR, 티켓팅(ticketing), CI/CD에 접근
• MCP[7]와 같은 프로토콜을 통해 내부 서비스와 통신

모든 새로운 기능은 프롬프트 인젝션 (prompt injection), 데이터 유출 (data exfiltration), 도구 오용 (tool abuse), 안전하지 않은 코드 실행 (unsafe code execution)과 같은 실패 모드 (failure modes)를 유발합니다.[1][8] 업계 가이드라인은 에이전트 보안이 베이스 모델 정렬 (base-model alignment)만큼이나 계획 (planning), 메모리 (memory), 도구 사용 제어 (tool-use controls)에 달려 있다고 강조합니다.[7][8]

의미 있는 벤치마크는 다음 사항을 다루어야 합니다:

• 탐지 및 분류 (triage) 품질
• 부하 상황에서의 오케스트레이션 (orchestration) 동작
• 적대적 압박 하에서의 안전성 및 정책 준수

구체적인 사례
직원 5,000명 규모의 한 SaaS 기업이 SIEM 상단에 LLM 분류 (triage) 어시스턴트를 시범 도입했습니다. 이 시스템은 다음과 같은 결과를 냈습니다:

• 중앙값 경보 검토 시간을 약 60% 단축함
• 하지만 오케스트레이션이 노이즈가 많은 EDR 피드 (EDR feed)를 과도하게 신뢰함에 따라, 발생 빈도는 낮지만 영향력이 큰 몇몇 측면 이동 (lateral-movement) 경보를 자동으로 종료해 버렸습니다.[2][3]

노이즈가 섞인 적대적 텔레메트리 (adversarial telemetry)와 놓친 치명적 사건에 대한 명시적 지표를 포함한 MDASH 스타일의 벤치마크가 있었다면 이를 드러낼 수 있었을 것입니다.

소결론
MDASH가 중요한 이유는 사이버 AI가 이제 안전 제어 (safety controls)와 데이터 배관 (data plumbing)을 포함하여 엔드 투 엔드 (end-to-end)로 평가되어야 하는 설계된 멀티 모델 에이전트 시스템 (multi-model agent systems)의 영역이기 때문입니다.[3][4][7]

멀티 모델 에이전트 기반 사이버 방어 시스템의 개념적 아키텍처 (Conceptual Architecture of a Multi‑Model Agentic Cyber Defense System)

MDASH는 명확한 참조 아키텍처(reference architecture)에서 시작합니다. 즉, 명시적인 역할(roles), 도구(tools), 그리고 가드레일(guardrails)을 가진 협력적 에이전트 계층 구조입니다.[2][5][7]

2.1 핵심 에이전트 계층 구조 (Core agent hierarchy)

전형적인 역할:

• 최상위 보안 오케스트레이터 (Top‑level Security Orchestrator): 작업을 수신하고(예: 배치 분류(triage batch), 사고 평가, 리포지토리 검토), 하위 에이전트에게 위임하며, 상태를 추적하고, 결과를 종합합니다[3][7]
• SOC 분류 에이전트 (SOC Triage Agent): SIEM/EDR에 연결하여 경보(alerts)를 보강하고, 소스를 상관 분석하며, 심각도와 플레이북(playbooks)을 제안합니다[2]
• 위협 헌팅 에이전트 (Threat Hunting Agent): 과거 로그, 인텔리전스(intel), 지식 베이스를 바탕으로 가설을 테스트합니다
• 코드 및 SDLC 보안 에이전트 (Code & SDLC Security Agent): Git, CI, 그리고 SCA 도구와 통합하여 위협 모델을 구축하고, 공격 경로를 찾으며, 샌드박스(sandboxes)에서 패치를 테스트합니다[5][6]
• 도구 실행기 / 액추에이터 에이전트 (Tool Executor / Actuator Agents): 고위험 작업(방화벽 변경, 계정 잠금, 패치 배포)을 래핑(wrap)하며, 더 엄격한 정책과 인간의 승인 경로를 강제합니다[1][4]

Databricks의 에이전트형 AI(Agentic AI) 확장 기능은 계획(planning), 메모리(memory), 도구 사용(tool use)을 별도의 위험을 수반하는 구성 요소로 취급하며, 각 요소에 대한 전용 제어(controls)를 권장합니다.[7] MDASH 아키텍처는 이를 반영하여 다음을 포함해야 합니다:

• 플래너 서비스 (A planner service)
• 메모리 저장소 (A memory store)
• 도구 라우터 (A tool router)
  이를 통해 각 구성 요소를 독립적으로 평가하고 강화(hardened)할 수 있습니다.

데이터 흐름도(data-flow diagram)로서의 아키텍처: 보안 엔지니어링 관점에서 MDASH는 다음과 같은 데이터 흐름도로 문서화되어야 합니다:

• SIEM/EDR 로그 및 트레이스(traces) → 전처리(preprocessing) → 특징/임베딩 저장소(feature/embedding stores)
• 지식 베이스(knowledge bases) 및 사고 이력(incident history)에 대한 검색 및 RAG (Retrieval-Augmented Generation)
• 멀티 모델 추론 (예: 오케스트레이션(orchestration)을 위한 GPT-5.5, 심층 분석을 위한 GPT-5.5-Cyber)[4][6]
• MCP 또는 유사한 커넥터를 통한 도구 호출(Tool invocations)
• 거버넌스 계층(governance layers)을 통해 라우팅되는 출력값 (티켓, SOAR 작업, 코드 변경 사항)[1][7][8]

각 단계(hop)는 지연 시간(latency), 정확성(correctness), 그리고 안전성(safety)을 평가하는 지점이 됩니다.[3][7]

정책 집행 지점 (Policy enforcement points)
에이전트가 민감한 내부 데이터와 신뢰할 수 없는 입력을 연결하기 때문에, Databricks는 다음 사항에 대해 계층화된 제어를 권장합니다:[1][7][8]

• 데이터 액세스 (Data access): 최소 권한 원칙(least privilege), 행/열 필터링
• 입력 검증 (Input validation): 프롬프트 정화(sanitizing), 도구 인자(tool arguments) 제한
• 출력 제한 (Output restriction): 실행 또는 영구 저장될 수 있는 항목 제한

참조 아키텍처(reference architecture)에는 도구, 데이터 커넥터

3.2 SOC 정렬 시나리오 (SOC-aligned scenarios)
현재의 SOC AI 배포는 SIEM 분류 (triage), 정보 보강 (enrichment), 그리고 사고 자격 검증 (incident qualification)을 자동화합니다.[2] MDASH는 다음과 같은 시나리오를 통해 이를 확장합니다:

• 소수의 실제 침해 사례가 숨겨진 자격 증명 스터핑 (Credential-stuffing) 급증
• 정당한 도구와 저소음 신호를 사용하는 느린 측면 이동 (lateral movement)
• 악성코드 분류 (malware triage) 및 권장 사항이 필요한 중요 서버의 의심스러운 바이너리[2][3][4]
  각 시나리오에 대해, 벤치마크는 합성 또는 재현된 공격을 주입하고 다음을 측정합니다:
• 올바른 분류까지 걸리는 시간 (Time-to-correct-classification)
• 미탐 (False-negative) 및 오탐 (false-positive) 비율
• 분석가 업무량 감소 및 에스컬레이션 (escalation) 패턴

적대적 에이전트 시나리오 (Adversarial agent scenarios)
LLM 및 에이전트 보안 연구는 다음과 같은 취약점을 강조합니다:[1][8]

• 직접 및 간접 프롬프트 주입 (prompt injection)
• RAG/지식 베이스 오염 (poisoning)
• 악성 도구 응답
• 탈옥 (Jailbreaks) 및 데이터 유출 (data-exfil) 프롬프트
  MDASH는 다음을 포함해야 합니다:
• 로그 또는 문서에 숨겨진 적대적 지침
• 정책을 무시하려는 오염된 RAG 코퍼스 (corpora)
• 적대적 출력을 반환하는 도구 (예: 위조된 권한) 및 에이전트가 여전히 정책을 집행하고 안전 장치를 트리거하는지 여부 측정.[1][7][8]

3.3 SDLC 및 제품 보안 시나리오 (SDLC and product security scenarios)
Daybreak는 보안 코드 리뷰, 공격 경로 모델링 (attack-path modeling), 의존성 분석 (dependency analysis), 그리고 샌드박스 패치 검증을 통해 SDLC에 보안을 내장합니다.[5][6] MDASH는 다음을 위한 시나리오로 이를 반영해야 합니다:

• 현실적인 저장소 (repos)에서 치명적인 취약점 탐지
• 코드 및 인프라 정의로부터 위협 모델 (threat models) 생성
• 패치 제안 및 샌드박스에서의 검증[5][6]
  GPT-5.5 및 GPT-5.5-Cyber는 엔터프라이즈 SOC부터 중요 인프라 및 레드팀 스타일의 작업에 이르기까지 서로 다른 방어 계층을 목표로 하므로, 시나리오는 운영 계층 및 예상 제어 강도에 따라 태그가 지정되어야 합니다.[4][6]

반응형 vs 자율형 (Reactive vs autonomous)
현대적인 SOC는 순수하게 반응적인 분류 (triage)에서 에이전트가 다음과 같은 역할을 수행하는 보다 자율적인 방어로 이동하고 있습니다:

• 표면적 이상 징후를 지속적으로 모니터링
• 선제적 조치 제안[3]
  MDASH는 다음을 구분해야 합니다:
• 반응형 작업 (Reactive tasks) – 정적 경고 배치 분류 및 정보 보강
• 자율형 작업 (Autonomous tasks) – 지속적인 모니터링,

이상 징후 탐지(anomaly surfacing), 별도의 성공 지표 및 안전 기대치를 적용한 선제적 방어(pre-emptive hardening). 소결론: MDASH의 가치는 현실적인 운영 계층 및 공격자 행동에 기반하여 SOC 분류(triage), 적대적 에이전트 행동, 그리고 SDLC 보안을 아우르는 시나리오에서 발생합니다.[2][3][5][8]

4. 평가 차원, 지표 및 방법론 (Evaluation Dimensions, Metrics and Methodology)
   MDASH는 정확도(accuracy), 성능(performance), 안전성(safety) 측면에서 시스템을 점수화하는 방법을 정의합니다.

4.1 정확도 및 효율성 지표 (Accuracy and efficiency metrics)
경고 분류(alert triage)를 위한 핵심 지표는 다음과 같습니다:[2]

• 심각도 등급별 정밀도(Precision) 및 재현율(Recall)
• 분류 소요 시간(Time-to-triage) (p50/p95)
• 인간으로의 에스컬레이션(Escalation) 비율 및 하류 재오픈(downstream re-open) 비율
  SOC 확장성(scalability)을 포착하기 위해, 수동 기준선 대비 사고당 분석가 시간의 감소량을 측정합니다. 이는 LLM 기반 설계가 병목 현상을 데이터 및 오케스트레이션(orchestration) 계층으로 이동시킨다는 점을 반영합니다.[3]

지연 시간(Latency) 및 처리량(Throughput)
멀티 모델 파이프라인(Multi-model pipelines)은 임베딩(embeddings), 검색(retrieval), 추론(reasoning), 도구 호출(tool calls)을 체인 형태로 연결합니다.[4]
MDASH는 다음을 기록해야 합니다:

• 엔드 투 엔드(End-to-end) 지연 시간: 경고 수집(alert ingestion) → 권장 조치
• 단계별 지연 시간: RAG, LLM 추론, 각 도구 호출
• 현실적인 경고량 및 동시성(concurrency) 하에서의 처리량[2][4]
  이러한 지표들은 실시간에 가까운 탐지 및 대응의 실현 가능성을 결정합니다.

4.2 안전성 및 견고성 지표 (Safety and robustness metrics)
Databricks의 계층적 제어 및 '2인 규칙(Rule of Two)' 가이드를 바탕으로, MDASH는 다음을 추적해야 합니다:[1][7][8]

• 프롬프트 인젝션(Prompt-injection) 성공률 (에이전트가 허용되지 않은 동작을 수행하는 경우)
• 정책 위반(Policy-violation) 비율 (금지된 데이터 또는 도구에 대한 접근 시도)
• 잘못된 형식 또는 안전하지 않은 도구 호출 빈도
• 장기 메모리(long-term memory) 오용 (악성 지침의 지속성)[7][8]
  각 적대적 시나리오는 다음을 출력해야 합니다:
• 효과성 점수(Effectiveness score) – 공격이 탐지를 회피했는가?
• 회복 탄력성 점수(Resilience score) – 제어 장치가 작동했는가, 로그가 기록되었는가, 사용자에게 경고가 전달되었는가?

계획(Planning), 메모리(Memory), 그리고 도구 연결성(Tool connectivity)
에이전트 기반 AI (Agentic AI) 프레임워크는 다음과 같은 새로운 위험 요소를 강조합니다:[7]

• 장기 메모리(Long-term memory)의 정확성 및 정화(Sanitization)
• 다단계 계획(Multi-step plan)의 안전성 및 체크포인팅(Checkpointing)
• MCP 및 유사 프로토콜을 통한 신뢰할 수 없는 도구 출력 처리

MDASH는 다음과 같은 하위 점수(Sub-scores)를 제공할 수 있습니다:

• 안전한 메모리 사용
• 정확한 다단계 계획
• 안전한 도구 중재 및 응답 검증

4.3 SDLC 특화 지표
Daybreak 워크플로우에서 영감을 얻은 SDLC 지표는 다음을 포함해야 합니다:[5][6]

• 실제 정답(Ground truth) 대비 취약점 탐지 범위
• 스캔 시의 오탐률(False-positive rate)
• 탐지부터 샌드박스 검증된 패치까지의 평균 시간(Mean time)
• 생성된 보안 문서의 품질 및 완결성

방법론 및 재현성
모든 MDASH 실행은 다음을 기록해야 합니다:[1][2][4][8]

• 모델 버전 및 설정 (예: GPT-5.5 vs GPT-5.5-Cyber, temperature)
• 시스템 프롬프트(System prompts) 및 템플릿
• 도구 구성 및 권한
• 데이터 슬라이스(Data slices), 시나리오 ID, 시드(Seeds)

LLM 보안 가이드는 NIS2 및 DORA와 같은 규제 체제에 대해 재현성(Reproducibility)과 감사 가능성(Auditability)을 강조합니다.[8] MDASH 결과는 재현 가능하고 추적 가능(Attributable)해야 합니다.

소결론
MDASH는 단순히 "답이 맞았는가?"를 훨씬 넘어선 것을 평가합니다. 이는 감사 가능하고 반복 가능한 방법론 하에서 정확성, 지연 시간(Latency), 안전성, 그리고 SDLC 성과를 측정합니다.[1][2][4][7]

5. 구현 청사진: 데이터에서 멀티 모델 에이전트 오케스트레이션까지
   MDASH는 기존의 SOC 및 SDLC 스택 위에서 실행되어야 합니다.

5.1 데이터 및 검색 계층
SOC 데이터 계층(SIEM, EDR, 자산 인벤토리, 위협 인텔리전스)을 도구를 통해 접근 가능한 구조화된 저장소로 계측(Instrument)합니다.[2][3]
일반적으로:

• 텔레메트리(Telemetry)를 통합 스키마로 정규화
• 인덱싱된 저장소 구축 (로그용 컬럼형 저장소, 텍스트용 벡터 저장소)
• 에이전트를 위한 읽기 전용, 최소 권한 인터페이스 노출[1][8]
  그 위에 벡터 검색(Vector search) 및 하이브리드 필터링(KNN + 메타데이터)을 갖춘 검색 계층을 구현합니다.

이 계층 또한 공격 표면(Attack surface)이 될 수 있습니다: RAG 코퍼스(Corpora)는 악의적인 지시문으로 오염(Poisoning)될 수 있습니다.[1][8] 검색 보호(Guarding retrieval)를 위해 Databricks 스타일의 계층적 제어를 적용합니다:[1][7][8]

• 수집된 문서 필터링 및 정제(Sanitize)
• 각 에이전트가 쿼리할 수 있는 컬렉션(Collections) 제한
• 가능한 경우, 실행 가능한 지시문을 제거하기 위해 검색된 청크(Chunks)를 후처리

5.2 에이전트 오케스트레이션(Agent orchestration) 및 역할 분리
역할 분리를 인코딩하기 위해 에이전트 프레임워크(커스텀, LangGraph 스타일 또는 MCP 기반)를 사용합니다:[7]

• 플래너 에이전트(Planner agent) – 작업을 해석하고 계획 및 하위 작업(Sub-tasks) 생성
• 워커 에이전트(Worker agents) – 특정 도구 호출(쿼리, EDR 작업, 티켓 업데이트, CI 실행) 수행
• 거버넌스 에이전트(Governance agent) – 정책을 강제하고, "제2의 의견(Second opinion)" 검사를 수행하며, 감사를 위한 근거(Rationales)를 기록[1][7]
  이는 위험 분석을 위해 계획, 메모리 및 도구 실행을 분리하는 Databricks의 방식을 반영합니다.[7]

코드 및 SDLC 경로
이를 반영하기 위해