2010년대 초, 기업 IT 팀은 예상하지 못한 문제에 직면했습니다. 직원들이 업무를 위해 Dropbox, Gmail, Google Docs를 사용하고 있었고, 그것도 기업의 경계 바깥에서 사용하고 있었던 것입니다. 데이터가 건물 밖으로 나가고 있었습니다. 섀도 IT가 탄생한 순간이었습니다.
10년이 지난 지금, 같은 패턴이 반복되고 있습니다. 다만 이번에는 걸린 판돈이 더 큽니다.
섀도 AI란 무엇인가?
섀도 AI는 IT, 보안, 컴플라이언스 팀이 알지 못하거나 감독하지 않는 상태에서 직원들이 AI 도구, 모델, 에이전트를 사용하는 것을 말합니다. 예를 들면 다음과 같습니다.
- 개발자가 디버깅을 위해 독점 소스 코드를 ChatGPT에 붙여 넣는 경우
- 영업 담당자가 고객 데이터를 넣어 Claude로 제안서 초안을 작성하는 경우
- 재무 팀이 비공개 정보가 담긴 계약서를 요약하기 위해 Copilot을 사용하는 경우
- 엔지니어가 어떤 거버넌스 계층도 없이 LLM API를 호출하는 내부 도구를 만드는 경우
이 중 악의적인 활동은 하나도 없습니다. 모두 업무를 더 빨리 해내려는 사람들입니다. 하지만 리스크 관리 관점에서 보면, 정량화하기 어렵고 해소하기는 더욱 어려운 노출을 만들어 냅니다.
그리고 이것은 소수의 예외적인 행동이 아닙니다. 2026년의 업계 조사에 따르면 승인되지 않은 AI 도구를 사용하는 지식 노동자는 80퍼센트에 가깝고, 절반 이상이 그 사용 사실을 관리자에게 적극적으로 숨기고 있습니다. 한편 실질적인 모니터링 체계를 갖춘 조직은 약 28퍼센트에 불과합니다.
섀도 AI가 섀도 IT와 다른 이유
섀도 IT는 대체로 데이터 상주 위치(data residency)의 문제였습니다. 파일이 사내 파일 서버가 아니라 Dropbox에 있었던 것입니다. 데이터는 밖으로 퍼지지 않고 한곳에 머물렀으며, 다만 있어서는 안 될 곳에 있었을 뿐입니다.
섀도 AI는 데이터 유출(exfiltration)의 문제입니다. 직원이 고객 데이터를 외부 LLM에 붙여 넣으면, 그 데이터는 서드파티 추론 제공업체로 전송됩니다. 제공업체의 이용 약관에 따라 모델 학습에 사용될 수도 있습니다. 로그에 저장될 수도 있습니다. 그 회사의 지원 엔지니어가 접근할 수도 있습니다.
또 다른 차이는 양입니다. AI 지원 코딩 도구를 사용하는 개발자 한 명이 하루에 수백 건의 프롬프트를 생성할 수 있습니다. 하나하나가 잠재적인 데이터 노출 사건입니다. 노출 면적은 Dropbox에 있는 파일과 비교할 수 없습니다.
발견 문제
알지 못하는 것은 통제할 수 없습니다. 섀도 AI의 첫 번째 과제는 발견입니다. 어떤 AI 도구를 누가, 어떤 데이터로 사용하고 있는지 명확하게 파악하는 것입니다.
이는 생각보다 어렵습니다. AI 도구는 브라우저, VS Code 확장, 직원이 직접 작성한 스크립트의 API 호출, 그리고 UI에 조용히 AI 기능을 추가한 SaaS 제품을 통해 접근됩니다. 기존의 네트워크 모니터링으로는 이 모두를 잡아내지 못합니다.
효과적인 섀도 AI 발견은 다음을 결합합니다.
- 브라우저 확장 텔레메트리: 직원이 방문하는 AI 기반 웹사이트와 도구를 수집
- 네트워크 프록시 분석: 알려진 LLM 제공업체로 향하는 API 호출을 식별
- 개발자 도구 훅: 독점 코드가 공유될 가능성이 가장 높은 코딩 환경에서의 AI 사용을 파악
- SaaS 및 결제 감사: 이미 비용을 지불하고 있는 도구 안에서 조용히 활성화된 AI 애드온처럼, 네트워크를 전혀 거치지 않는 AI 기능과 구독을 포착
무엇을 할 것인가
섀도 AI를 발견하는 것은 전제 조건입니다. 이를 거버넌스 아래 두는 것이 실제 목표입니다.
많은 조직이 저지르는 실수는 이를 차단의 문제로 취급하여 AI 도구를 거부 목록에 추가하고 직원들이 따라 주기를 바라는 것입니다. 이 접근은 두 가지 이유로 실패합니다. 첫째, 직원들은 우회로를 찾습니다. 위에서 본 은폐 통계가 바로 차단 정책이 현실에서 만들어 내는 결과입니다. 둘째, AI 도구가 제공할 수 있는 정당한 생산성 향상을 막아 버립니다.
더 효과적인 접근은 유도형 거버넌스(channeled governance)입니다. 승인된 AI 도구를 직원들이 경계를 우회할 필요가 없을 만큼 좋게 만들고, 모든 AI 상호작용에 얇은 거버넌스 계층을 적용하여 PII를 스캔하고, 데이터 분류 정책을 적용하고, 감사 목적으로 기록하되 워크플로를 막지 않는 것입니다.
이는 섀도 IT에서 효과를 거둔 것과 같은 플레이북입니다. Dropbox를 차단해서는 이길 수 없습니다. 사내 파일 저장소를 쓸 만큼 좋게 만들고, 데이터가 어디에 있든 데이터와 함께 이동하는 DLP 정책을 적용해야 이깁니다.
한발 앞서 나가기
섀도 AI를 잘 다루는 기업들에는 몇 가지 공통점이 있습니다.
-
제한하기 전에 측정합니다. 처음 90일은 정책 적용이 아니라 발견에 씁니다. 실제 사용 패턴을 이해해야 그에 맞는 정책을 설계할 수 있습니다.
-
이유를 알려 줍니다. 회사에 AI 정책이 있는 이유를 이해하는 직원은 그 정책을 따를 가능성이 더 높습니다. "고객 개인정보를 보호하기 위해 프롬프트에서 고객 데이터를 스캔합니다"라는 말은 "AI는 금지입니다"라는 말과는 전혀 다르게 와닿습니다.
-
규정을 지키는 길을 쉽게 만듭니다. 승인된 AI 도구를 쓰려면 세 번의 승인이 필요한데 승인되지 않은 도구는 클릭 한 번이면 된다면, 사람들은 더 쉬운 길을 택합니다. 거버넌스는 보안뿐 아니라 사용성에서도 이겨야 합니다.
섀도 AI는 사라지지 않습니다. 도구는 너무나 훌륭하고 생산성 향상은 너무나 실재합니다. 문제는 조직에 이를 거버넌스 아래 둘 계획이 있는지, 아니면 사고가 대신 그 결정을 내려 주기를 기다리고 있는지입니다.
그 얇은 거버넌스 계층을 여러분의 AI 호출 앞에 두고 싶으신가요? API 기본 URL이 Control Zero 게이트웨이를 가리키도록 설정하면, PII 탐지를 활성화한 모든 정책에 대해, 게이트웨이를 통과하는 JSON 트래픽이 제공업체에 도달하기 전에 64개의 기본 제공 탐지기(12개 패턴 팩 전반)로 스캔됩니다. 코드 변경은 필요 없습니다. 게이트웨이 가이드를 참고하십시오.