보안 팀에게 부족한 것은 탐지가 아니다. 진짜 문제는 조치와 커뮤니케이션이고, 보안에서 AI가 실제로 제값을 하는 곳도 정확히 이 두 지점이다. 요즘 스캐너는 컴플라이언스 벤치마크 기준으로 800개의 발견 항목을 아무렇지 않게 쏟아낸다. 발견 자체는 어려운 부분이 아니다. 어려운 것은 그 대부분이 끝내 고쳐지지 않는다는 점, 그리고 고쳐진 항목조차 예산을 승인하는 사람들 눈에는 보이지 않는다는 점이다. 이 글은 그 문제를 정면으로 다룬다고 생각하는 두 가지 AI 기능, 승인 게이트를 거치는 자동 조치와 비기술 독자를 위한 AI 생성 리포트에 대한 101 입문이다. Microsoft 365 보안 플랫폼인 Aether365를 예시로 사용한다. 미리 밝혀두면 Aether365는 내 제품이다. 논거는 논거 자체로 판단하기 바란다.

시작 전에 한 가지 원칙: read-only가 기본값이다. 별도의 명시적 동의 없이는 어떤 것도 테넌트에 쓰기 권한을 얻지 못한다.

모든 보안 스캐너가 남겨두는 두 가지 공백

실제 Microsoft 365 테넌트에 CIS 벤치마크, EIDSCA, CISA ScuBA 같은 포스처 스캔을 돌리면 결과의 모양은 항상 같다. 심각도가 붙은, 실패한 점검 항목의 긴 목록이다. 그다음에는 예측 가능한 두 가지 일이 벌어진다.

첫째, 발견 항목 큐는 모두의 집중력보다 오래 살아남는다. 항목 하나를 고치려면 맞는 관리 센터, 맞는 PowerShell cmdlet, 또는 맞는 Microsoft Graph 호출을 찾아야 하고, 그다음에는 실수 한 번에 실제 사람들이 잠겨버리는 프로덕션 ID 시스템에 변경을 가해야 한다. 이것을 수백 개 항목으로 곱하면 큐는 백로그가 되고, 백로그는 발견 항목이 늙어가는 곳이다.

둘째, 스캔 리포트는 보안 팀 밖으로 나가지 않는다. 컨트롤 ID와 설정 경로로 쓰여 있기 때문이다. 인력과 예산을 결정하는 사람들은 그 내용을 전혀 보지 못하거나, 아무 맥락 없는 컴플라이언스 점수 하나만 본다. 테넌트가 1년 내내 60퍼센트 준수 상태에 머물러도, 경영진은 그것이 무슨 의미였는지 사고 회고 자리에서야 알게 된다.

두 공백 모두 탐지 품질과는 무관하다는 점에 주목하라. 탐지가 좋아질수록 첫 번째 공백은 오히려 넓어진다. 대부분의 "보안 AI" 마케팅이 더 많이 탐지하는 이야기라는 점에서 이 사실은 중요하다. 흥미로운 작업은 탐지의 하류에 있다.

AI Pilot: 사람의 승인 게이트를 거치는 조치

AI Pilot은 첫 번째 공백에 대한 Aether365의 답이고, 누가 만들든 에이전트형 조치가 어떻게 작동해야 하는지 보여주는 유용한 사례 연구다. 루프는 네 단계다: 스캔, 제안, 승인, 적용과 검증.

스캔이 발견 항목을 만든다. 각 항목에 대해 시스템은 실제로 수행할 Microsoft Graph 변경에 정확히 매핑된 구체적인 수정안을 생성한다. 산문으로 된 제안이 아니라 실제 변경 그 자체다. 그다음 제안된 변경을 하나씩 검토해 항목별로 승인하거나 거부한다. 승인된 변경만 적용되고, 적용된 각 변경은 검증을 거쳐 감사 기록에 남는다.

여기서 얻을 101 교훈은 권한 모델이다. 프로덕션의 에이전트 시스템이 신뢰를 얻거나 잃는 지점이 바로 여기이기 때문이다. 읽기 전용 접근이 기본값이고, 계속 기본값으로 남는다. AI Pilot은 사용자가 직접 선택해야 하는 별도의 명시적인 Microsoft 쓰기 동의 연결을 요구한다. 이를 활성화하지 않으면 플랫폼은 물리적으로 테넌트를 변경할 수 없다. 읽기 전용을 유지해야 하는 EU 및 규제 대상 테넌트에서 이 도구를 쓸 수 있게 만드는 것이 바로 이 속성이다. 쓰기 경로는 앱 안의 토글이 아니라 Microsoft의 인가 계층이 강제하는 동의 경계다.

실패 모드와 비교해 보라: 상시 쓰기 권한을 가진 완전 자율 에이전트가 발견하는 즉시 고쳐버리는 방식이다. 효율적으로 들리지만, 새벽 2시에 Conditional Access 정책을 "고쳐버려서" 온콜 엔지니어가 원인을 확인하러 로그인조차 못 하게 되는 순간까지만 그렇다. 변경 건별 승인 게이트가 없는 자율성은 조치 도구를 무한한 인내심을 가진, 감사받지 않는 관리자로 바꿔놓는다. 게이트는 AI의 한계가 아니다. 그것이 곧 기능이다.

Business Impact Reports: 번역 계층

두 번째 공백은 커뮤니케이션이고, 이것이 오늘날 보안에서 LLM의 가장 화려하지 않으면서 가장 방어 가능한 용도다. 언어 모델은 보안 도구가 늘 못해온 한 가지, 즉 기술적 상태를 비기술 독자가 행동으로 옮길 수 있는 서사로 번역하는 일을 정말로 잘한다.

Business Impact Reports는 원시 스캔 결과를 이사회에 바로 올릴 수 있는 문서로 만든다: 평이한 언어의 경영진 요약, 컴플라이언스 점수가 비즈니스에 갖는 의미, 어느 사업 부문이 가장 큰 리스크를 지고 있는지, 우선순위가 매겨진 "이것부터 하라" 로드맵, 그리고 발견 항목과 GDPR, NIS2, ISO 27001 의무 사항 간의 매핑이다. 리포트는 24개 언어 중 어느 것으로든 생성되는데, 이는 들리는 것보다 중요하다. 뮌헨의 CFO는 리포트를 독일어로 받고 보안 팀은 영어로 일하는데, 둘 다 같은 스캔 데이터에서 나온다.

정직한 101이라면 두 가지 단서를 달아야 한다. 리포트는 그 아래에 있는 스캔만큼만 좋다. 나쁜 데이터를 서술하는 LLM은 페이지 번호까지 달린 자신만만한 헛소리를 만들어낸다. 그리고 AI 생성 리포트에는 명확한 데이터 처리 원칙이 필요하다. Aether365의 원칙은 이렇다: 스캔 데이터는 어떤 모델의 학습이나 파인튜닝에도 사용되지 않고, AI는 리포트를 생성하는 그 순간에만 실행되며, 전체 과정은 EU AI Act에 맞춰 사람의 감독 아래 유지된다. 어떤 도구를 고르든 이 답변을 서면으로 요구하라.

어떤 AI 보안 기능에도 통하는 101 체크리스트

브랜딩을 걷어내고, 어떤 "AI 더하기 보안" 기능이든 다섯 가지 질문으로 평가하라:

  • 쓰기 접근이 옵트인이고 별도로 동의를 받는가? 읽기 전용 기본값은 기본 조건이다. 별도의 쓰기 동의 경로가 진짜 시험대다.
  • 모든 변경을 개별적으로 승인할 수 있는가? 300개 변경의 일괄 승인은 게이트가 아니라 고무도장이다.
  • 검증된 감사 기록이 있는가? 적용됨과 검증됨은 같지 않다. 변경 건마다 둘 다 필요하다.
  • AI가 결정을 내리는가, 자료를 만드는가? 사람의 승인을 받기 위해 수정안과 리포트 초안을 만드는 AI는 리스크가 낮다. ID 인프라에서 무인으로 행동하는 AI는 그렇지 않다.
  • 내 데이터가 학습에 사용되는가? 답이 한 문장을 넘어가면 답은 "그렇다"이다.

내가 보기에 AI Pilot과 Business Impact Reports는 보안 AI의 정직한 버전이다. 모델이 지루한 매핑과 번역을 맡고, 권한은 사람이 쥔다. 병목은 처음부터 탐지가 아니었다. 고치는 것과 설명하는 것이 병목이었고, 이번 세대의 도구가 겨냥해야 할 곳이 정확히 거기다.

다음으로 읽을 글

이 이야기의 인프라 측면, 즉 Microsoft 365 테넌트를 다른 클라우드 자산과 똑같이 다뤄야 하는 이유가 궁금하다면 ercan.cloud의 클라우드로 클라우드 점검하기: M365 Security 포스처 스캐닝 101을 참고하라. AI, 클라우드, 플랫폼 작업에 대한 컨설팅 문의, 또는 그냥 인사를 건네고 싶다면 ercanermis.com에서 시작하라.

참고 자료