AI 보안 뉴스를 보면 보통 “AI가 공격에 쓰였다”는 장면부터 떠올립니다. 이번에는 방향이 반대입니다. 마이크로소프트가 보안 업무 자체에 여러 AI 에이전트를 연결하는 프로젝트를 공개했습니다.
핵심은 AI가 경고를 더 많이 만드는 것이 아닙니다. 위험을 찾고, 맥락을 확인하고, 조치까지 이어지는 흐름을 나누어 운영하는 데 있습니다.
이번 발표가 눈에 띄는 이유
마이크로소프트는 2026년 7월 27일 보안 분야의 에이전트 활용을 설명하면서 Project Perception을 소개했습니다. 그리고 8월 3일부터 공개 프리뷰를 시작한다고 밝혔습니다.
이 프로젝트는 보안 신호와 주변 맥락을 모으고, 여러 모델과 전문 에이전트를 연결해 보안팀의 판단을 돕는 방식입니다. 아직 모든 보안 업무를 사람 대신 처리한다는 뜻은 아닙니다. 사람이 확인해야 할 대상을 더 빨리 좁히는 데 초점이 있습니다.
왜 보안 업무를 여러 AI 에이전트로 나눴을까
보안 업무는 한 번의 답변으로 끝나지 않습니다. 이상 징후를 찾은 뒤 실제 공격인지 확인하고, 영향을 받은 범위를 살피고, 대응 방법을 고른 다음, 변경 내용을 기록해야 합니다.
그래서 역할을 세 방향으로 나누는 구조가 등장합니다.
- Red 에이전트: 공격자 관점에서 취약점과 공격 가능성을 찾습니다.
- Blue 에이전트: 방어자 관점에서 신호를 분석하고 대응 방법을 검토합니다.
- Green 에이전트: 운영 환경에서 안전한 수정과 복구가 가능한지 확인합니다.
역할을 나누면 한 에이전트의 판단을 그대로 믿는 대신, 서로 다른 관점에서 다시 확인할 수 있습니다. 이것은 AI가 틀리지 않는다는 설계가 아니라, 틀릴 수 있다는 전제에서 위험을 줄이는 설계입니다.
모델 하나로 해결하지 않는 이유
모든 작업에 같은 AI 모델을 쓰면 편해 보이지만, 속도와 비용, 정확도가 항상 같은 방향으로 좋아지지는 않습니다. 마이크로소프트는 작업에 맞는 여러 모델을 조합하는 다중 모델 구조를 강조했습니다.
공식 발표에는 CyberGym 평가에서 96%의 결과와 거의 50%의 비용 절감이라는 수치가 소개되어 있습니다. 다만 이는 마이크로소프트가 공개한 자체 평가 결과이므로, 다른 환경에서도 같은 결과가 나온다고 받아들이면 안 됩니다.
비개발자가 가져갈 기준 세 가지
- 권한을 작게 시작하기: 처음에는 읽기와 요약만 허용하고, 삭제나 외부 전송 권한은 분리합니다.
- 사람의 승인을 남기기: 결제, 게시, 계정 변경처럼 되돌리기 어려운 작업은 마지막 확인을 거치게 합니다.
- 작업 기록을 남기기: 어떤 자료를 보고 어떤 판단을 했는지 나중에 확인할 수 있어야 합니다.
한계도 분명합니다
에이전트를 여러 개 연결한다고 자동으로 안전해지는 것은 아닙니다. 잘못된 신호가 전달되면 여러 에이전트가 같은 방향으로 잘못 판단할 수도 있습니다. 테스트 환경과 실제 운영 환경을 분리하고, 권한과 승인 단계를 따로 설계해야 하는 이유입니다.
결론
AI 보안의 다음 단계는 “AI를 쓸 것인가”가 아니라 “AI가 어디까지 움직일 수 있는가”를 정하는 일에 가깝습니다. 방어 업무에 AI 에이전트를 붙일수록 역할 분리, 사람의 승인, 작업 기록이 함께 필요합니다.
출처
공개된 공식 발표를 바탕으로, 비개발자도 이해할 수 있도록 핵심 구조와 적용 기준을 정리했습니다.