몇 달 전, 중견 핀테크 기업에서 플랫폼 보안을 담당하는 한 친구가 저에게 잊히지 않는 말을 했습니다. "저희는 3월에 ChatGPT를 차단했습니다. 4월이 되자 DLP 로그에는 AI 관련 사고가 전혀 나타나지 않았죠. 정말로 문제를 해결했다고 믿었습니다."

그러던 중 데이터 팀의 누군가가 한 계약직 직원이 3주 동안 고객 기록을 Claude에 붙여넣고 있었다는 사실을 발견했습니다. 아무도 Claude를 차단하지 않았습니다. 차단할 생각조차 하지 못했습니다.

이것은 현재 전 세계 엔지니어링 조직에서 벌어지고 있는 이야기이며, 솔직하게 이야기할 가치가 있습니다. 왜냐하면 떠도는 대부분의 조언이 이 문제를 정책(Policy)의 문제로 취급하지만, 실제로는 아키텍처(Architecture)의 문제이기 때문입니다.

DNS 차단은 보안 쇼(Security Theater)에 불과하다

네트워크 계층에서 chat.openai.com을 차단하는 것에 대한 실상은 이렇습니다. 그것은 정확히 하나의 도구에 대한 정확히 하나의 접속 경로만을 차단할 뿐입니다. 그게 전부입니다. 사람들이 애초에 왜 AI를 찾게 되었는지에 대한 근본적인 이유, 즉 "이 수동 작업은 느린데 AI를 쓰면 빠르다"라는 이유에는 전혀 영향을 주지 못합니다.

그럼 어떤 일이 벌어질까요? 엔지니어들은 AI 사용을 중단하지 않습니다. 단지 당신이 볼 수 있는 AI를 사용하지 않을 뿐입니다.

• 차단 목록에 없었던 Claude, Gemini, 또는 Perplexity로 전환합니다.
• 개인 키를 사용하여 프롬프트를 LLM API로 프록시(Proxy)하는 VS Code 확장을 설치합니다.
• "생산성"을 위해 이미 승인되었고 데이터 흐름에 대한 감사가 이루어지지 않은 Copilot, Cursor, 또는 Tabnine을 사용합니다.
• 기업 네트워크에서 허용하지 않는 것이 필요할 때 5분 동안 휴대폰 핫스팟에 연결합니다.

이 중 어느 것도 악의적인 것이 아닙니다. 이는 실행 가능한 대안 없이 제한이 생겼을 때 발생하는 현상일 뿐입니다. 만약 당신이 Slack을 차단한 직장에서 근무하며 팀 전체가 일주일 만에 WhatsApp 그룹으로 이동하는 것을 본 적이 있다면, 이미 그 메커니즘을 이해하고 있는 것입니다. AI도 동일한 패턴을 따르고 있으며, 단지 훨씬 더 무서운 데이터 노출 프로필이 결합되어 있을 뿐입니다.

이것이 과거의 Shadow IT보다 더 심각한 이유

Shadow IT는 항상 존재해 왔습니다. 승인되지 않은 SaaS 도구, 개인 Dropbox 계정, 책상 아래에서 개인 서버를 돌리는 엔지니어 한 명과 같은 것들 말입니다. 보안 팀은 이를 다루는 데 수십 년간의 근육 기억 (muscle memory)을 가지고 있습니다.

Shadow AI는 두 가지 구체적인 방식으로 그 근육 기억을 무너뜨립니다.

노출이 즉각적이며 콘텐츠가 풍부합니다. 승인되지 않은 클라우드 드라이브에 파일을 업로드하는 것은 개별적이고 로그로 남길 수 있는 이벤트입니다. 하지만 고객의 API 키가 포함된 스택 트레이스 (stack trace)를 챗봇에 붙여넣는 것은 파일 전송이 아니라, 텍스트 상자에 입력된 문자열입니다. 대부분의 DLP (데이터 유출 방지) 도구는 문장이 아니라 건물을 떠나는 파일을 포착하도록 구축되었습니다. 이 도구들은 프롬프트 (prompt)를 전송 이벤트로 전혀 인식하지 못합니다.

공격 표면 (surface area)을 열거하는 것이 거의 불가능합니다. 탈취된 Dropbox 계정은 하나의 앱입니다. 하지만 AI는 이제 여러분의 IDE, 이메일 클라이언트, CRM, 티켓팅 시스템, 그리고 팀이 설치한 브라우저 확장 프로그램의 절반 속에 내장되어 있습니다. GitHub Copilot을 사용하는 개발자, Notion AI를 사용하는 PM, 그리고 Zendesk에 내장된 AI 요약기를 사용하는 지원 엔지니어는 모두 "AI를 사용 중"이지만, 네트워크 모니터링 관점에서는 그 어느 것도 서로 유사해 보이지 않습니다.

엔지니어링 조직에서 Shadow AI가 실제로 나타나는 모습

이를 구조화해 보면, Shadow AI는 보통 세 가지 계층으로 나타나며, 대부분의 보안 팀은 첫 번째 계층에 대해서만 가시성을 확보하고 있습니다.

계층 1: 이미 차단한 도구들

ChatGPT, Claude.ai, Gemini — 관리되는 기기에서, 기업 네트워크를 통해, 브라우저로 접속하는 경우입니다. 이것이 DNS 수준의 차단이 실제로 다루는 계층이며, 그마저도 부분적으로만 가능합니다. 홈 네트워크나 개인 핫스팟을 사용하는 사람은 이를 그대로 통과해 버립니다.

계층 2: 이미 승인한 도구에 조용히 추가된 AI

이 계층은 대부분의 보안 팀을 방심하게 만드는 단계입니다. Salesforce Einstein, Microsoft 365 Copilot, Notion AI, GitHub의 네이티브 AI 기능 등은 AI 기능이 존재하기 훨씬 이전에 이미 조달되고 승인된 플랫폼의 업데이트 형태로 제공되는 경우가 많습니다. 벤더가 새로운 기능 플래그(feature flag)를 활성화했을 때, 아무도 데이터 처리 합의서(Data Processing Agreement)를 재검토하지 않았습니다. 기술적으로는 이를 사용하는 직원이 정책을 준수하고 있는 것이지만, 실질적으로는 그 데이터가 어디로 가고 있는지 아무도 모릅니다.

계층 3: 아무도 들여다보지 않는 것들

콘텐츠를 제3자 API로 조용히 전달하여 페이지를 요약하거나 이메일을 다시 작성해 주는 브라우저 확장 프로그램(Browser extensions), 개인 API 키를 사용하여 작동하는 로컬 설치형 코딩 어시스턴트(Coding assistants), 밤 11시에 디버깅을 하다가 실수로 프롬프트에 붙여넣은 개발자의 .env 파일 등이 여기에 해당합니다. 이 계층은 정의상 네트워크 모니터링(Network monitoring)에 거의 보이지 않습니다. 누군가가 감시하고 있는 유형의 트래픽 패턴을 생성하지 않기 때문입니다.

기존 스택이 이를 잡아내지 못하는 이유

대부분의 조직이 이미 신뢰하고 있는 스택인 DLP, CASB, SIEM 도구들이 왜 여기서 어려움을 겪는지 구체적으로 살펴볼 가치가 있습니다. 이 도구들이 나빠서가 아니라, 단지 다른 형태의 문제를 해결하기 위해 만들어졌기 때문입니다.

• **DLP (데이터 유출 방지)**는 파일이나 구조화된 전송을 포착하도록 조정되어 있으며, 대화형으로 입력되는 프롬프트 텍스트를 포착하도록 설계되지 않았습니다. 채팅창에 붙여넣은 한 단락의 텍스트는 파일 이동을 기준으로 설계된 규칙을 거의 트리거(trip)하지 않습니다.
• CASB (클라우드 접근 보안 브로커) 플랫폼은 알려진 SaaS 앱에 대해서는 강력하지만, 해당 앱에 사후적으로 결합된 AI 기능에 대해서는 일관되지 않은 커버리지를 보이며, 브라우저 확장 프로그램에 대해서는 가시성이 거의 없습니다.
• **SIEM (보안 정보 및 이벤트 관리)**는 로그에 기록된 내용만 알 수 있습니다. 대부분의 소비자용 AI 도구는 SIEM으로 전송되는 로그를 전혀 생성하지 않으므로, SIEM의 관점에서는 해당 사용이 존재하지 않는 것과 같습니다.
• **네트워크 모니터링 (Network monitoring)**은 기업 네트워크만 커버합니다. 원격 근무는 이 격차를 엄청나게 키웠습니다. 홈 네트워크를 사용하는 개발자가 개인 AI 계정을 사용하는 것은 경계(perimeter) 외부의 영역입니다.

이러한 도구들을 더 강력하게 튜닝(Tuning)한다고 해서 격차가 해소되지는 않습니다. 애초에 이 도구들은 이러한 종류의 신호를 탐지하도록 설계되지 않았기 때문입니다.

차단보다는 가시성 — 실질적인 방법론

이 문제를 잘 다루고 있는 팀들은 가장 엄격한 차단 목록(blocklists)을 가진 팀들이 아닙니다. 그들은 다음과 같은 질문에 실제로 답할 수 있는 팀들입니다: 사람들이 어떤 AI 도구를 사용하고 있는지, 어떤 데이터가 입력되고 있는지, 그리고 그것이 사용자의 역할과 다루는 정보의 민감도를 고려했을 때 적절한지 말입니다.

이것은 방화벽(firewall)의 문제가 아니라, 발견(discovery)과 모니터링(monitoring)의 문제입니다. 실질적인 변화를 이끌어낼 수 있는 몇 가지 구체적인 방안은 다음과 같습니다:

1. 정책을 수립하기 전에 AI 자산 인벤토리(asset inventory)를 실행하세요. 매핑되지 않은 대상은 관리할 수 없습니다. SaaS AI 기능, 브라우저 확장 프로그램(browser extensions), IDE 플러그인, 그리고 엔지니어링 팀이 직접 호출하는 모든 AI API를 목록화하세요.
2. 도구를 이름이 아닌 위험도(risk)에 따라 분류하세요. 적절한 데이터 레지던시(data residency) 제어 기능이 포함된 기업용 Copilot 배포는, 동일한 직원이 개인용 ChatGPT 계정을 집 노트북에서 사용하는 것과는 다른 위험 범주에 속합니다. 이들을 다르게 취급해야 합니다.
3. 포괄적인 차단 대신 역할 기반 액세스(role-based access)를 사용하세요. 운영 환경(production) 자격 증명을 다루는 개발자는 샌드박스(sandboxed) 저장소에서 작업하는 사람보다 더 엄격한 AI 가드레일(guardrails)이 필요합니다. 모두에게 동일한 하나의 정책을 적용하는 것은 대부분의 조직에서 너무 느슨하거나 혹은 너무 제한적일 수밖에 없습니다.
4. 프롬프트 수준의 감사 로깅(audit logging)을 구축하세요. 이것이 실제 집행 메커니즘입니다. 아무도 검증할 수 없는 서면 정책은 그저 PDF 파일일 뿐입니다. AI 도구에 무엇이 제출되고 있는지 로깅하고, 민감한 데이터 카테고리가 나타날 때 플래그(flagging)를 지정하는 것이 정책을 실질적인 것으로 만드는 방법입니다.
5. 사람들에게 승인된 대안을 제공하세요. 모든 Shadow AI 사례는 동일한 방식으로 시작됩니다. 누군가는 빠르게 움직여야 했고, 승인된 경로가 승인되지 않은 경로보다 느렸던 것입니다. 실제로 유용한 승인된 도구를 제공하지 않는다면, 사람들이 스스로 도구를 찾아낼 것임을 보장하는 셈입니다.

핵심 요약

ChatGPT를 차단하는 것이 반드시 틀린 것은 아닙니다. 다만 질문을 잘못 던지고 있을 뿐입니다. 질문은 "어떻게 하면 사람들이 이 특정 도구를 사용하는 것을 막을 수 있을까"가 되어서는 안 됩니다. 대신 "우리 시스템 전반에서 실제로 어떤 AI가 실행되고 있으며, 누가, 어떤 데이터를 사용하여 사용하고 있는가"가 되어야 합니다.

DNS 규칙만으로는 그 질문에 답할 수 없습니다. 답을 얻으려면 여러분의 기술 스택(Stack) 전반에서 AI가 실제로 어떻게 사용되는지에 대한 가시성(Visibility)을 구축한 다음, 추측하고 그 추측이 맞기를 바라는 대신 발견된 사항 위에 거버넌스(Governance)를 계층적으로 쌓아 올려야 합니다.

Shadow AI는 사실 직원들이 규칙을 무시한다는 이야기가 아닙니다. 이는 자신의 환경에서 어떤 일이 일어나고 있는지 파악할 수 있는 가시성을 아직 구축하지 못한 엔지니어링 조직에 관한 이야기입니다. 이는 해결 가능한 문제이지만, 차단이 아닌 관찰에서부터 시작되어야 합니다.

필독: Why Blocking ChatGPT Won't Stop Shadow AI