[ 트렌드] 당신의 AI 비서는 기밀 데이터를 읽고 있다 (그리고 보안 도구로는 막을 수 없다)
상상해 보자. 회사에서 몇 달에 걸쳐 Microsoft 365 Copilot을 도입했다. 민감도 레이블도 설정하고, DLP 정책도 구성하고, 컴플라이언스 체크리스트도 다 채웠다. CISO도 승인했다. 보안은 완벽해 보였다.
그런데 4주 동안, Copilot이 기밀 이메일을 읽고 요약하고 있었다—설정해둔 보안 레이블을 완전히 무시한 채로. EDR은 경고를 보내지 않았다. WAF도 조용했다. DLP 대시보드는 전부 초록불이었다.
한 사용자가 이상한 점을 발견하고 신고해서 겨우 알게 됐다.
가상 시나리오가 아니다. 2026년 1월 Microsoft 고객들에게 실제로 벌어진 일이다—8개월 만에 두 번째. 이 사건은 AI를 쓰는 모든 기업이 알아야 할 위기를 보여준다: 기존 보안 도구는 사람이 데이터를 옮기는 세상을 전제로 만들어졌다. AI 에이전트는 그 규칙을 따르지 않는다.
실제로 무슨 일이 벌어졌나
사실 관계부터 정리하자. Microsoft Copilot은 1년도 안 되는 사이에 데이터 보호 정책을 두 번이나 무시했다.
첫 번째 사건은 2025년 7~8월경 발생했다. 자세한 내용은 여전히 불분명하다—Microsoft가 조용히 넘어갔고, 대부분의 기업은 자사 보안 경계가 뚫렸다는 사실조차 몰랐다.
두 번째 사건은 무시하기 어렵다. 2026년 1월 21일부터 Microsoft 365 Copilot이 "기밀(confidential)" 민감도 레이블이 붙은 이메일을 처리하기 시작했다. 요약했다. 질문에 답변했다. 명시적으로 "접근 금지"라고 표시된 지침을 그냥 참고 사항 정도로 취급했다.
4주간 이 위반이 계속됐다. Microsoft는 2026년 2월 4일에 CW1226324로 공식 추적을 시작했지만, 고객들은 1월 말부터 이상 징후를 보고하고 있었다. 수정 배포가 시작된 건 2월 10일—최초 보고로부터 3주 뒤였다.
보안팀 입장에서 정말 무서운 건 이거다: 어떤 자동화 시스템도 이걸 잡아내지 못했다. EDR도, WAF도, DLP도 경고를 보내지 않았다.
탐지는 가장 원시적인 방법으로 이뤄졌다: 한 사용자가 Copilot이 접근하면 안 되는 정보를 요약하는 걸 눈치채고 수동으로 신고한 것이다.
Microsoft만의 문제가 아니었다. 같은 시기에 보안 연구자들은 AI 기반 고객 경험 플랫폼을 통해 700개 이상의 조직이 침해당했다고 밝혔다—SOC(보안 운영 센터)가 이미 심사하고 승인한 시스템들이었다.
이 플랫폼들은 수십억 건의 비정형 데이터를 처리한다: 설문 양식, 리뷰 사이트, 소셜 미디어 피드, 콜센터 녹취록. AI 엔진이 이 데이터를 흡수하고 급여 시스템, CRM 데이터베이스, 결제 프로세서에 연결된 자동화 워크플로를 실행한다. 보안팀은 "고객 피드백 도구"로 보고 승인했지만, 실제로는 공개 인터넷 양식에서 내부 민감 시스템으로 직통 통로를 열어준 셈이었다.
공통점? 모든 사례에서 전통적 보안 인프라는 눈이 멀어 있었다.
보안 스택이 AI를 감지하지 못하는 이유
왜 이런 일이 반복되는지 이해하려면, DLP가 실제로 어떻게 작동하는지—그리고 AI가 왜 그걸 무력화하는지 알아야 한다.
전통적 DLP는 사람의 작업 흐름을 전제로 설계됐다. 누군가 민감 데이터를 복사하려 하거나, 기밀 파일을 외부로 이메일 보내거나, USB에 다운로드하거나, 보호된 정보를 스크린샷 찍으려 할 때. DLP 도구는 체크포인트에서 이런 행위를 감시한다: 클립보드, 이메일 게이트웨이, 네트워크 경계, 화면 캡처 API.
모델은 단순하다: 데이터 이동을 감시하라. 민감 데이터가 경계를 넘으려 하면 차단하라.
AI 에이전트는 데이터를 이동시키지 않는다. 데이터로부터 추론한다.
Copilot에게 "이번 주 이메일 요약해줘"라고 하면, 이메일을 외부 서버로 복사하지 않는다. 사용자의 인증 정보로 정당한 API를 통해 접근한다. 메모리에서 처리한다. 원문을 그대로 재현하지 않으면서 여러 출처의 정보를 압축한 요약을 생성한다.
보안 도구 관점에서 이건 정상적인 인가된 접근처럼 보인다. AI는 이메일 읽기 권한이 있다—그게 목적이니까. DLP는 인증된 요청을 확인하고, 사용자 접근 권한을 점검한 뒤 통과시킨다.
문제는 그 다음에 일어나는 일이다. Copilot은 이메일을 읽기만 하는 게 아니라 합성하고, 문서 간 패턴을 연결하고, 민감도 경계를 넘나드는 추론을 도출한다. "기밀" 이메일 3개와 "공개" 이메일 2개를 하나의 응답으로 요약할 수 있는데, 이는 사실상 맥락적 이해를 통해 보호 정보를 세탁하는 것과 같다.
아키텍처 격차를 쉽게 설명하면 이렇다:
전통적 보안 모델:
사용자 → [DLP 검사] → 데이터 접근 → [DLP 검사] → 외부 전송
DLP가 각 단계에서 감시한다: 접근 시 레이블 확인, 권한 검증, 반출 감시.
AI 보안의 현실:
사용자 → AI 에이전트 → 무제한 데이터 접근 → 추론/요약
DLP는 두 번째와 세 번째 단계 사이에서 눈이 먼다. 데이터가 AI 모델에 도달할 때쯤이면 이미 체크포인트를 지난 뒤다. "유출"은 전통적 반출 패턴이 아닌 처리 과정에서 발생한다.
이건 패치로 고칠 수 있는 버그가 아니다. 근본적인 아키텍처 불일치다. 1990년대 보안 전제를 2026년 AI 시스템에 끼워 맞출 수 없는 것은, 2010년대에 온프레미스 보안을 클라우드 워크로드에 끼워 맞출 수 없었던 것과 같다. 같은 뼈아픈 교훈, 다른 기술 파도.
비즈니스 임팩트: CISO들이 허둥대는 이유
"벤더가 고쳐줄 때까지 기다리면 되지"라고 생각한다면 전략적 문제를 놓치고 있는 거다.
컴플라이언스 관점에서 이건 악몽이다. GDPR 위반, CCPA 침해, 업종별 규제는 데이터 노출을 알았는지 여부를 따지지 않는다. 탐지가 소급적으로만 작동하기 때문에 감사 추적이 불완전하다—사건 발생 후 로그를 수동으로 검토해서 무슨 일이 있었는지 파악해야 한다. 데이터가 부적절하게 접근되거나 요약되지 않았다는 걸 증명할 방법이 없다.
"보안 도구가 작동하지 않는 줄 몰랐습니다"는 법적 항변이 되지 않는다.
이로 인해 내가 '신뢰 세금(Trust Tax)'이라 부르는 상황이 생긴다. 기업에게 남은 선택지는 세 가지인데 전부 안 좋다:
- AI 도입을 철회해서 리스크를 없앤다—대신 보안 격차를 감수하는 경쟁사에게 경쟁 우위를 뺏긴다
- 알려진 취약점을 안고 운영한다—컴플라이언스와 침해 리스크를 감수한다
- 보안 인프라를 처음부터 재구축한다—비용도 크고, 시간도 오래 걸리고, 성숙한 솔루션도 아직 없다
세 가지 모두 비용, 시간, 또는 경쟁력을 요구한다. 쉬운 답은 없다.
벤더 관계 위기도 있다. Microsoft 365 Copilot, Google Workspace AI, Slack AI 등의 기업 계약은 기존 보안 프레임워크가 적용될 거라는 전제 하에 체결됐다. SLA에 AI 관련 장애 조항이 없다—아무도 이 격차를 예상하지 못했으니까. 벤더들이 급하게 솔루션을 덧붙이고 있지만, 근본적인 아키텍처가 하루아침에 바뀌진 않는다.
피해 범위를 생각해 보자. Microsoft Copilot에는 수백만 명의 기업 사용자가 있다. 데이터 접근 권한을 가진 모든 AI 비서가 잠재적으로 취약하다—Google의 Gemini in Workspace, Salesforce Einstein, Slack의 AI 기능 등. 이건 Microsoft만의 문제가 아니라, 업계 전체의 아키텍처 가정이 틀렸던 것이다.
커리어 리스크도 솔직히 짚자. AI 승인을 빠르게 밀어붙인 CISO들은 이제 이사회에 기밀 데이터가 왜 노출됐는지 설명해야 한다. 컴플라이언스 체크박스를 채운 IT팀은 그 체크박스가 생각했던 의미가 아니었다는 걸 알게 됐다. 경쟁력 유지를 위해 빠른 AI 도입을 밀어붙인 임원들은 이제 그 결과를 마주하고 있다.
침해 조사가 시작되면—그리고 결국 시작될 것이다—누군가 책임을 져야 한다.
무엇이 바뀌어야 하나: "골든 파이프라인"의 미래
그렇다면 진짜 AI 보안은 어떤 모습이어야 할까?
보안 아키텍트들 사이에서 떠오르는 합의는 AI 네이티브 보안 인프라가 필요하다는 것이다—기존 도구에 AI 기능을 덧붙이는 게 아니라.
핵심 원칙은 다르다:
접근 계층이 아닌 추론 계층을 모니터링하라. 전통적 보안은 누가 어떤 파일에 접근하는지 감시한다. AI 보안은 모델이 각 추론 작업에서 어떤 데이터를 사용하고 어떤 출력을 생성하는지 추적해야 한다.
모델의 입력과 출력을 모두 추적하라. AI가 50개 문서에 접근했다는 것만으로는 부족하다. 그 문서들의 어떤 정보가 응답에 나타났는지, 그리고 그 조합이 분리되어야 할 정보를 드러내지는 않았는지 알아야 한다.
비정형 데이터를 위한 "스키마리스" 보안을 구현하라. 전통적 DLP는 정형 데이터베이스와 레이블이 붙은 문서에 잘 작동한다. AI는 깔끔한 범주에 맞지 않는 지저분하고 계속 변하는 운영 데이터를 흡수한다. 보안 정책이 정적 규칙이 아닌 모델 행동에 적응해야 한다.
벤더들이 "골든 파이프라인"이라 부르는 게 바로 이것이다—AI 접근을 나중에 덧붙인 기존 시스템이 아니라, 처음부터 AI를 위해 설계된 데이터 인프라.
실시간 추론 모니터링은 AI 쿼리가 여러 민감도 레벨의 데이터에 걸쳐 접근할 때 플래그를 올리고, 조합을 통해 보호 정보를 드러내는 요약을 탐지하며, 전통적 DLP가 인식하지 못하는 이상 패턴을 경고할 수 있다.
초기 단계 벤더들이 이런 골든 파이프라인을 구축 중이다. Empromptu는 거버넌스를 내장하여 AI 추론용 운영 데이터를 준비하는 데 집중하고 있다. Runlayer는 기업 환경에 특화된 안전한 에이전틱 AI 기능을 제공한다. Rapidata는 보안 고려사항을 처음부터 포함한 실시간 강화학습 인프라를 구축하고 있다.
하지만 냉정한 현실이 있다: 이 인프라는 오늘날 대규모로 존재하지 않는다. 매우 초기 단계의 솔루션들이다. 성숙한 AI 네이티브 보안을 구축하려면 몇 달이 아닌 몇 년이 걸린다. 데이터 아키텍처를 기본 원칙부터 다시 설계해야 한다. "이 제품 설치하면 안전합니다"라는 옵션은 없다.
그 사이에 기업들은 눈을 가린 채 비행 중이다.
지금 당장 할 수 있는 것
그렇다고 손 놓고 있을 수만은 없다. 역할별, 시간대별 행동 지침을 정리했다.
이번 주: 피해 통제
CISO라면:
- 현재 어떤 AI 도구가 민감 데이터 시스템에 접근 권한을 갖고 있는지 감사하라
- Microsoft Purview 또는 동등한 로깅을 사용 중인지 확인하라 (사건 발생 시 소급 분석에 필요하다)
- 가정된 보안과 실제 보안 태세 사이의 격차에 대해 경영진에게 브리핑하라
IT 보안팀이라면:
- 데이터 접근 권한이 있는 모든 AI/ML 서비스를 목록화하라
- AI 벤더 SLA에서 보안 보증 항목을 검토하라 (스포일러: 모호하다)
- 현재 AI 사고 탐지 역량을 솔직하게 문서화하라
컴플라이언스 담당이라면:
- AI 관련 시나리오로 리스크 레지스터를 업데이트하라
- AI 침해 탐지 워크플로에 맞게 사고 대응 계획을 검토하라
이번 달: 시간 벌기
AI 쿼리 로그를 수동으로 표본 점검하라. 사용자가 의심스러운 AI 행동을 신고할 수 있는 프로세스를 만들어라—쉽게 만들고 의심을 장려하라. 일반 보안 사고와 별도로 AI 전용 사고 대응 플레이북을 수립하라.
데이터 분류 전략을 재검토하라. 일부 데이터는 더 나은 보안이 나올 때까지 AI 시스템에서 아예 차단할 만큼 민감할 수 있다. 이건 기술적 결정이 아니라 비즈니스 결정이다.
이번 분기: 미래 계획
AI 네이티브 보안 벤더를 평가하라. 아직 미성숙하다는 걸 알지만, 솔루션이 성숙해질 때 바로 도입할 수 있도록 포지셔닝하라. 전사 적용은 못 하더라도 최고 민감도 데이터에 대해 "골든 파이프라인" 접근 방식을 시범 적용하라.
일반 IT 거버넌스와 별도로 AI 거버넌스 프레임워크를 개발하라. 전제가 다르니 정책도 달라야 한다.
다년간의 보안 아키텍처 마이그레이션 예산을 확보하라. 한 분기짜리 프로젝트가 아니다.
하지 말아야 할 것
패닉에 빠져 AI 도구를 전부 끄지 마라—경쟁 우위를 잃고 직원들은 보안이 더 취약한 우회 방법을 찾게 된다.
벤더가 알아서 고쳐줄 거라 가정하지 마라—벤더들도 실시간으로 배우는 중이다.
완벽한 솔루션이 나올 때까지 기다리지 마라—존재하지 않고, 앞으로 몇 년간도 없을 것이다.
무시하고 넘어가길 바라지 마라—법적 책임은 무지가 아니라 태만을 따른다.
모든 조직이 답해야 할 전략적 질문: 실제로 검증 가능한 보안과 교환할 수 있는 AI 역량은 어디까지인가?
보편적으로 맞는 답은 없지만, 없는 보안을 있다고 우기는 건 확실히 틀린 답이다.
앞으로: 청산의 시간
이 패턴은 IT 업계에 오래 있었다면 익숙하다.
1990년대에 메인프레임 사고방식 위에 인터넷 보안을 얹었다. 2000년대에 데스크톱 모델에서 모바일 보안을 끼워 맞췄다. 2010년대에 온프레미스 도구로 클라우드 보안을 적용했다.
매번 그 전환은 고통스럽고, 비용이 많이 들었고, 침해 사고가 줄줄이 터졌다. 매번 기본 원칙부터 보안을 재구축한 조직이 앞서 나갔다. 끼워 맞추기를 시도한 조직은 수년간 "기술 부채 세금"을 냈다.
지금은 2020년대이고, AI가 새 프론티어다. 기업들이 역사에서 배울 것인가, 반복할 것인가가 관건이다.
2025년은 AI의 약속이 AI의 현실을 앞지른 해였다. 2026년은 어떤 약속이 진짜였고 어떤 게 희망 사항이었는지 드러나는 해다.
보안은 과대 포장됐다. 그 교정이 지금 일어나고 있다.
Microsoft의 실패가 드러내는 건 Microsoft가 보안에 유독 취약하다는 게 아니다—세계에서 가장 정교한 보안 조직 중 하나다. 드러나는 건 AI가 30년간 의존해온 전제를 근본적으로 깨뜨린다는 것이다.
당신의 AI 비서는 유용하다. 질문에 답하고, 이메일을 요약하고, 생산성을 높이고, 시간을 절약해준다.
하지만 명시적으로 보지 말라고 해놓은 모든 것도 다 보고 있다.
AI가 실제로 작동하는 방식에 맞춰 보안을 재구축할 때까지—우리가 바라는 방식이나 마케팅된 방식이 아닌—이 상황은 바뀌지 않는다.
문제는 당신의 조직이 이 문제에 직면할지 여부가 아니다.
사용자 신고로 발견할 것인가, 컴플라이언스 감사로 발견할 것인가, 아니면 침해 통보로 발견할 것인가다.
현명하게 선택하라.
참고: 이 분석은 Microsoft Copilot 사건(추적 참조 CW1226324), The Register, VentureBeat, 보안 연구자들의 보도, Microsoft 자체 문서 등 공개 정보를 기반으로 작성됐다. 조직별 상황에 맞는 구체적 지침은 법무 및 보안팀과 상담하길 권한다.