가트너가 경고한 쉐도우 AI, 금지보다 더 어려운 건 통제 설계

쉐도우 AI가 왜 갑자기 보안팀 메인 이슈가 됐나

• 가트너가 기업 AI 확산을 두고 꽤 직접적인 경고를 냈음

  • 보고서 제목은 ‘엄격한 엔드포인트 애플리케이션 통제를 요구하는 쉐도우 AI’
  • 핵심은 직원들의 AI 사용 속도가 회사의 승인·검토 절차보다 훨씬 빠르다는 것
  • 문서 작성, 번역, 회의 정리, 자료 조사, 코드 작성처럼 귀찮은 반복 업무가 많을수록 외부 AI로 손이 감

• 숫자도 꽤 세게 나옴

  • 가트너의 ‘2025년 AI 리스크 관리 및 활용 관련 사이버보안 혁신 조사’에서 사이버보안 리더 조직 302곳을 조사함
  • 이 중 69%가 직원들이 금지된 공개 생성형 AI 서비스를 쓰고 있다고 의심하거나, 실제 사용 근거를 확보했다고 답함
  • 이유는 생산성, 시간 절감, 승인 도구에 대한 불만, 새 도구를 놓치기 싫은 심리로 정리됨

• 쉐도우 AI는 단순히 “챗봇 몰래 씀” 수준이 아님
  • 예전 보안 통제는 단말, 서버, 네트워크, 계정, 클라우드 중심으로 설계됐음
  • 이제 공격 표면이 AI 서비스, AI 브라우저, AI 에이전트, 브라우저 확장, 개발 도구 생태계까지 넓어짐
  • 개인 계정으로 업무용 PC에서 AI를 쓰면 사고가 났을 때 책임 소재도 흐려짐

가트너가 나눈 쉐도우 AI 세 가지 유형

• 첫째는 일반 직원의 쉐도우 AI임

  • 챗GPT, 클로드 같은 AI 비서나 퍼플렉시티 코멧, 챗GPT 아틀라스 같은 AI 브라우저를 개인 업무에 쓰는 케이스
  • 문서, 회의록, 규제 대상 데이터가 조직이 통제하지 않는 외부 도구로 들어갈 수 있음
  • 범위가 제일 넓어서 보안팀 입장에선 탐지도 쉽지 않음

• 둘째는 개발자 쉐도우 AI인데, 이쪽은 더 위험할 수 있음

  • 클로드 코드, 깃허브 코파일럿 같은 AI 코딩 에이전트뿐 아니라 MCP 서버, 코드 패키지, 브라우저 확장 기능이 공식 저장소 밖에서 유입될 수 있음
  • 일부는 개발자가 직접 설치하고, 일부는 AI 코딩 어시스턴트가 자동으로 설치할 수도 있음
  • 그러면 소프트웨어 공급망 보안 업무가 갑자기 훨씬 복잡해짐

• 셋째는 기술 공급자발 쉐도우 AI임

  • AI가 별도 서비스로만 들어오는 게 아니라 CRM, 커뮤니케이션 도구, 글쓰기 보조 도구 같은 기존 업무 앱에 조용히 붙고 있음
  • 표준 소프트웨어 업데이트 과정에서 AI 기능과 에이전트 자동화가 추가될 수도 있음
  • 회사가 “AI 도입 안 했다”고 생각해도, 실제론 쓰는 SaaS 안에 이미 AI가 들어와 있을 수 있다는 얘기임

AI 에이전트는 사고 방식이 좀 다름

• 최근 AI 에이전트는 일정 수준 자율성을 갖고 움직임

  • 그래서 단순히 직원이 정보를 잘못 붙여넣는 문제를 넘어, 자동화 흐름 자체가 공격 대상이 됨
  • 악성 지시문이 프롬프트, 데이터, 파일, 외부 도구 접근 경로에 주입되면 에이전트가 원래 목적과 다른 행동을 할 수 있음

• 더 골치 아픈 건 악성 지시가 저장될 수 있다는 점임

  • 에이전트 메모리, 데이터베이스, 스킬, 손상된 도구 안에 악성 지시가 남으면 잘못된 동작이 반복될 수 있음
  • 정상 소프트웨어처럼 보이는 가짜 AI 앱도 업무용 단말 보안의 새 위협으로 언급됨

그래서 뭘 해야 하나

• 첫 번째 대응은 승인된 AI 도구를 실제로 쓰기 쉽게 만드는 것임

  • 직원이 새 AI 서비스를 쓰고 싶을 때 공식 요청 절차가 너무 느리면 우회가 기본값이 됨
  • 조직이 승인한 AI 도구를 빠르게 도입하거나, 신규 서비스 접근을 투명하게 요청할 수 있어야 함
  • 현업 입장에서 공식 절차가 제일 빠르고 편해야 쉐도우 AI가 줄어듦

• 두 번째는 AI 사용 기준을 구체적으로 쪼개는 것임

  • 어떤 AI 공급자와 도구가 문서 작성, 생산성 향상, 소프트웨어 개발에 승인됐는지 명확해야 함
  • 영업·마케팅과 소프트웨어 엔지니어링은 다루는 데이터와 사용 방식이 다르므로 같은 규칙으로 묶기 어려움
  • 데이터 민감도, 업무 유형, 도구 특성을 반영한 기준과 AI 리터러시 교육이 같이 가야 함

• 세 번째는 탐지와 위험 평가임

  • 어느 부서에서 어떤 AI 도구를 쓰는지, 그 도구가 얼마나 자율적으로 행동하는지, 어떤 민감 데이터에 접근하는지부터 파악해야 함
  • 이후 고위험 직원 그룹과 고위험 사용 사례를 우선순위로 잡아야 함
  • URL 필터링, 다운로드 차단, 비인가 앱 실행 제한 같은 기존 단말·네트워크 통제도 여전히 쓸모 있음

• 장기적으로는 앱 허용목록과 권한 관리가 핵심으로 감

  • 승인된 앱만 업무용 단말에서 실행되도록 제한하는 방식임
  • 다만 전사 적용은 업무 방식 자체를 바꾸는 문제라 IT 변경관리와 예외 처리 절차까지 같이 손봐야 함
  • 관리자 권한을 관성적으로 열어두는 문화도 AI 시대엔 바로 리스크가 됨

• 결론은 “직원이 AI를 쓰느냐 마느냐”가 아니라 “AI 사용 욕구를 회사 안쪽으로 끌어들일 수 있느냐”임

  • 직원은 이미 더 빠른 업무 처리를 위해 AI를 찾고 있음
  • 개발자는 최신 AI 코딩 도구를 업무 환경에 들여오고 있음
  • 기존 소프트웨어 공급자도 제품 안에 AI 기능을 계속 심고 있음
  • 모른 척하거나 단순 차단만 하면 쉐도우 AI는 더 깊게 숨어버릴 가능성이 큼

---

기술 맥락

• 쉐도우 AI 대응에서 중요한 선택은 “차단”이 아니라 “통제 가능한 경로 만들기”예요. 현업이 AI를 쓰고 싶은 이유가 생산성이라면, 공식 도구가 느리고 불편한 순간 비공식 도구가 이겨요.

• 개발자 환경은 특히 조심해야 해요. AI 코딩 에이전트가 MCP 서버, 패키지, 확장 기능 같은 주변 도구를 끌어오면 보안팀 입장에서는 기존 앱 설치 관리보다 훨씬 넓은 공급망을 봐야 하거든요.

• 엔드포인트 통제가 다시 중요해지는 이유도 여기에 있어요. AI 서비스 자체는 클라우드에 있어도, 실제 유입 지점은 브라우저, 확장 기능, 로컬 개발 도구, 업무용 SaaS 업데이트일 때가 많아요.

• 프롬프트 인젝션이 위험한 건 AI 에이전트가 단순 응답기가 아니라 행동 주체처럼 움직이기 때문이에요. 악성 지시가 문서나 도구 응답 안에 숨어 있으면, 사용자는 정상 업무 흐름이라고 생각하는데 에이전트는 다른 행동을 할 수 있어요.

• 그래서 정책 문서만으로는 부족해요. 승인 도구, 로그와 탐지, URL·다운로드 통제, 권한 관리, 예외 승인 절차가 같이 묶여야 실제 운영에서 버틸 수 있어요.