마이크로소프트 2026 디지털 방어 보고서 핵심

“AI 모델은 골랐는데, 보안팀이 계정 권한부터 다시 보자고 합니다.” 사내 문서 검색이나 업무 자동화를 추진한다면 마이크로소프트가 2026년 10월 1일 공개한 디지털 방어 보고서가 이 요구의 이유를 설명합니다. 모델 성능과 별개로 무엇을 점검해야 하는지, 회사 규모와 업무에 따라 어디부터 손대야 하는지 정리합니다.

마이크로소프트는 무엇을 발표했나

마이크로소프트는 10월 1일 ‘2026 Microsoft Digital Defense Report’를 공개했습니다. 고객 보안 관리 조직의 부CISO인 Terrell Cox가 작성한 공식 해설은 공격자가 AI를 정찰, 사회공학, 악성코드와 취약점 공격 코드 개발, 침해 이후 활동에 활용한다고 설명합니다.

여기서 구분할 것이 있습니다. 보고서는 현재 AI 활용의 상당 부분이 기존 공격 절차의 특정 단계에 집중되어 있다고 명시합니다. 이를 “AI가 모든 해킹을 처음부터 끝까지 자율 수행한다”는 뜻으로 읽으면 안 됩니다. 공격자가 정보를 모으거나 사람을 속이는 작업에 AI를 쓰는 것과, 공격 전체를 AI에 맡기는 것은 다른 이야기입니다.

공식 보고서 소개가 제시한 관측 기반은 하루 165조 건 이상의 보안 신호와 하루 평균 3,100만 건의 계정 위험 탐지 분석입니다. 이 숫자는 마이크로소프트의 관측과 분석 규모입니다. AI 공격 발생 건수도, 한국 기업의 피해 건수도 아닙니다.

같은 날 나온 정부 대상 해설에서는 관측한 사이버 위협 활동 중 정부기관과 서비스 분야의 비중이 2025년 17%에서 2026년 27%로 늘었다고 설명합니다. 관측한 침입에서 피싱이 차지한 비중은 7%에서 23%로 증가했습니다. 두 수치 역시 한국만의 통계나 AI 때문에 발생한 공격의 비율은 아닙니다.

이번 발표는 보안 보고서 공개입니다. 한국 기업에 새로운 의무가 생기거나 준수 기한이 정해진 소식은 아닙니다. 다만 AI 운영 설계에서 무엇을 우선할지 판단할 근거가 됩니다.

왜 모델보다 계정과 연결 도구를 함께 봐야 하나

보고서가 강조하는 방어 축은 사람 계정과 비사람 계정의 권한 관리입니다. 비사람 계정에는 프로그램이 다른 시스템에 접속할 때 쓰는 서비스 계정 등이 포함됩니다. AI 에이전트도 연결 방식에 따라 이런 계정이나 접근 자격을 사용합니다. 불필요한 권한, 계속 유지되는 접근권, 취약한 계정 관리는 모델이 무엇이든 점검해야 할 대상입니다.

가령 문서 검색 AI를 도입하면서 전사 공유 폴더를 읽을 수 있는 계정을 연결했다고 가정합니다. 사용자가 원래 볼 수 없던 인사 자료까지 검색 결과에 섞인다면, 답변이 정확해도 안전한 시스템은 아닙니다. 모델을 바꾸기 전에 검색 단계에서 사용자의 열람 권한을 확인해야 합니다. 검색용 계정이 자료에 접근할 수 있다는 사실과, 질문한 직원이 그 자료를 볼 수 있다는 사실을 구분해야 합니다.

메일 발송이나 구매 요청까지 연결하면 검토 범위가 더 넓어집니다. 문장을 생성하는 기능이 외부 수신자에게 정보를 보내거나 업무 시스템을 수정하는 기능으로 바뀌기 때문입니다. 외부 문서에 섞인 지시를 AI가 잘못 따르는 상황도 고려해야 합니다. 이는 보고서의 공격 통계가 아니라, 연결형 AI를 설계할 때 검증해야 할 위험 시나리오입니다.

실무 기준은 분명합니다. 읽기와 쓰기 권한을 분리하고, 업무에 필요한 범위만 허용하며, 되돌리기 어려운 실행에는 사람의 승인을 둡니다. 사람이 로그인할 때는 보고서가 제시한 피싱 저항성 다중요소 인증과 패스키를 검토합니다. 서비스 계정에는 같은 로그인 방식을 그대로 적용하기보다 자격 증명 보관, 만료와 회수, 접근 범위를 따로 관리해야 합니다.

한국 기업과 기관은 어디부터 바꿔야 하나

아래는 보고서의 권고를 국내 업무에 적용한 실무 판단입니다. 규모와 업종별 배치는 실제 고객 사례가 아니라 도입 상황을 가정한 예시입니다. 회사 크기보다 AI가 어떤 자료를 읽고 어떤 행동을 할 수 있는지가 우선순위를 결정합니다.

중소기업이라면 처음부터 큰 보안 시스템을 구매하는 것보다 “이 AI의 관리자와 계정 소유자가 누구인가”에 답하는 일이 먼저입니다. 퇴사자 계정이나 담당자가 없는 서비스 계정이 남아 있으면 도입 범위를 넓힐수록 관리 공백도 커집니다. 도입 담당자와 보안 책임자가 같은 사람이어도 목록과 승인 기록은 남겨야 합니다.

제조사는 문서 검색과 생산 설비 제어를 한 과제로 묶지 않는 편이 좋습니다. 작업표준서를 찾는 AI의 성공이 설비 설정 변경의 안전성을 증명하지는 않습니다. 대기업은 부서마다 만든 에이전트가 같은 공유 계정을 쓰는지부터 확인해야 합니다. 사고가 났을 때 실행 주체를 구분할 수 없다면 감사와 원인 분석이 어려워집니다.

금융회사와 의료기관, 공공기관은 데이터 반출 가능 여부를 먼저 판단해야 합니다. 외부 전송이 허용되지 않는 환경이라면 내부망 배치를 검토할 수 있습니다. 그러나 내부망에 설치했다는 이유만으로 안전해지는 것은 아닙니다. 내부에서도 사용자별 열람 권한, 운영자 접근, 로그에 남는 민감정보를 통제해야 합니다.

지금 도입 담당자가 할 일은 무엇인가

“보안 검토를 해 주세요”라는 요청만 보내면 보안팀도 판단하기 어렵습니다. 제품 소개서 대신 실제 연결 구조를 가져가야 합니다. 다음은 법정 일정이 아니라, 검토 자료를 만드는 권장 작업 순서입니다.

1. 사용 중인 AI와 연결 대상을 적습니다. 서비스 이름, 담당자, 읽는 저장소, 실행 가능한 도구, 외부 전송 여부를 한 목록에 넣습니다. 시범 운영 중인 도구도 포함합니다.
2. 권한의 주체를 확인합니다. 사용자 권한으로 검색하는지, 공용 서비스 계정으로 검색하는지 구분합니다. 계정 소유자와 회수 담당자가 없으면 먼저 지정합니다.
3. 정상 답변보다 금지된 행동을 시험합니다. 다른 부서의 비공개 문서 조회, 승인 없는 외부 메일 발송, 퇴사자 계정 접속이 차단되는지 확인합니다. 실제 개인정보 대신 시험용 자료를 사용합니다.
4. 차단 이후의 조치를 정합니다. 누가 알림을 받고 어떤 계정이나 도구 연결을 중지할지 정합니다. 기록에는 실행 주체, 사용 도구, 승인과 차단 결과를 남기되 민감한 원문을 무조건 저장하지는 않습니다.

도입 승인 기준에도 이 결과를 넣어야 합니다. 답변 품질이 좋아도 권한 밖의 자료가 노출되거나 승인 없는 실행이 가능하면 연결 범위를 줄이고 다시 시험합니다. 보안 검토를 출시 직전의 결재로 두지 말고, AI가 할 수 있는 일의 경계를 정하는 설계 단계로 옮기는 것이 이번 보고서에서 가져갈 실무 판단입니다.

사용 기준은 사내 생성형 AI 사용 가이드라인, 실행 권한의 경계는 AI 에이전트 업무 자동화 글에서 이어서 정리할 수 있습니다. KITDI는 AI 연구를 서비스와 기업 솔루션으로 연결하며, 업무와 운영 조건을 함께 검토하는 AX 컨설팅을 수행합니다.