우리는 막는 대신, 안전한 길을 설계합니다
해커가 아니라, 우리 직원이었습니다
2026년 5월, 한 금융 회사가 미국 증권거래위원회(SEC)에 중대한 보안 사고를 공시했습니다. 원인은 정교한 침투나 제로데이 취약점이 아니었습니다. 한 직원이 고객의 이름과 SSN을 승인받지 않은 AI 애플리케이션에 입력해 업무를 처리한, 그 단순한 행동이 발단이었습니다.
주목할 점은 이 사고를 막아 낸 방어선이 하나도 없었다는 것입니다. 방화벽, 침입 탐지 시스템, 엔드포인트 보안 등등 기업의 보안 예산은 대부분 밖에서 안으로 들어오는 위협을 겨냥해 세워져 있습니다. 그러나 이번 위협은 정반대 방향, 안에서 밖으로 흘러 나갔습니다. 그것도 회사를 해치려는 악의가 아니라, 단지 일을 더 빨리 끝내려던 선의의 손끝에서 시작됐습니다. 경계를 지키도록 설계된 보안은 이런 종류의 유출 앞에서 구조적으로 무력화 됩니다.
이것이 섀도우 AI(Shadow AI)입니다. IT 부서의 골칫거리를 넘어, 이제 기업의 존립을 흔드는 리스크로 올라선 그림자입니다. 그리고 대부분의 기업은 자신의 조직에 이 그림자가 얼마나 넓게 퍼져 있는지조차 아직 모릅니다.
섀도우 IT가 아니라, 섀도우 AI입니다
섀도우 IT라는 말 자체는 새롭지 않습니다. 예전에도 직원들은 IT의 승인을 우회해 개인 클라우드 저장소나 메신저를 업무에 썼습니다. 그래서 많은 리더가 섀도우 AI 역시 “관리 도구 목록에 항목이 하나 더 추가된 것” 정도로 가볍게 취급합니다. 이 오해가 첫 단추를 어긋나게 합니다.
결정적 차이는 데이터에 무슨 일이 벌어지느냐입니다. 과거의 섀도우 IT가 데이터를 무단으로 저장하고 전송하는 위험이었다면, 즉 데이터가 어딘가에 놓이는 문제였다면 섀도우 AI는 외부 모델이 기업의 민감한 데이터를 처리하고 때로는 학습(training)에까지 활용 된다는 점에서 차원이 다릅니다. 유출된 파일은 회수하거나 접근 권한을 끊을 수 있지만, 모델의 가중치 속에 녹아든 정보는 삭제라는 개념 자체가 성립하지 않습니다. 데이터가 자산에서 퍼블릭 AI 모델의 일부로 상태가 바뀌고, 그 전이는 비가역적입니다.
더 근본적으로는, 공격면(attack surface)이 이동했습니다. 과거 보안이 지키던 전선은 네트워크 경계와 파일 전송 채널이었습니다. 섀도우 AI 시대의 새로운 전선은 프롬프트가 됩니다. 직원이 브라우저 입력창에 무엇을 타이핑하는가?! 여기가 데이터가 조직을 떠나는 최전선이 됐고, 하필 이 지점이 전통적 보안 스택의 사각지대입니다.
잘 알려진 사례가 이를 압축해 보여 줍니다. 어느 대기업 엔지니어들이 디버깅을 위해 독점 소스코드를 클라우드 AI에 붙여 넣은 순간, 그 코드는 기업의 통제권을 영구히 벗어났습니다. 악성코드도, 내부자의 배신도 아니었습니다. 그저 더 빨리 문제를 풀려는 유능한 직원의 합리적 선택이었을 뿐입니다. 바로 이 점이 이 위협을 다루기 어렵게 만듭니다.
섀도우 AI는 하나의 얼굴이 아닙니다
이 위협을 과소평가하게 만드는 두 번째 오해는, 섀도우 AI를 “직원이 몰래 클라우드 AI를 이용하는 것” 하나로만 그리는 것입니다. 실제 표면은 훨씬 넓고, 대부분은 눈에 띄지 않습니다.
- 브라우저 직접 접속: 개인 계정으로 퍼블릭 AI에 접속하는 가장 익숙한 형태. 그나마 탐지가 쉬운 축입니다.
- 개인 디바이스(BYOD): 회사 통제 밖의 스마트폰·노트북에서 이뤄지는 사용. 사내 네트워크 로그에 아무 흔적도 남지 않습니다.
- SaaS 내장 AI(Embedded AI): 이미 승인받아 쓰던 협업·문서 도구에 벤더가 조용히 얹은 AI 기능. 직원은 새 도구를 쓴다는 자각조차 없이 민감 데이터를 외부 모델에 흘려보냅니다. 가장 은밀하고 가장 광범위한 표면입니다.
- 비공식 API·자율 에이전트: 개발자가 생산성을 위해 임의로 붙인 API 연동이나, 승인 없이 배포한 AI 에이전트. 사람의 개입 없이 데이터를 읽고 씁니다.
- 코드 어시스턴트·브라우저 확장: 개발 환경과 브라우저에 설치된 AI 플러그인이 코드베이스와 화면 맥락을 상시 외부로 전송합니다.
이 표면들은 각기 다른 노출 경로와 다른 탐지 난이도를 가집니다. 그래서 “AI 하나 차단”으로 대응하는 조직은, 정작 가장 넓은 표면(내장 AI·개인 디바이스)을 통째로 놓칩니다. 관리하려면 먼저 이 지형 전체를 지도로 그려야 합니다.
위험은 네 갈래로 번집니다
섀도우 AI의 위험을 하나의 덩어리로 뭉뚱그리면 대응도 뭉툭해집니다. 위협을 네 갈래로 분해하면, 각각을 겨냥한 통제가 보입니다.
첫째, 데이터 유출과 영구 상실. 민감 정보가 외부 모델로 나가는 순간이자, 앞서 말한 비가역성의 문제입니다. 유출 자체보다 되돌릴 수 없음이 본질입니다.
둘째, 학습 흡수. 학습에 데이터를 쓰는 옵션이 켜진 서비스라면, 입력한 정보가 모델의 파라미터에 반영되어 다른 사용자의 응답에 형태를 바꿔 새어 나올 수 있습니다. 유출이 유출된 그 데이터의 문제라면, 학습 흡수는 그 데이터가 만든 능력이 남의 것이 되는 문제입니다.
셋째, 환각 주입. 방향이 반대인 위험입니다. 데이터가 나가는 게 아니라, 잘못된 정보가 들어옵니다. 미승인 AI가 지어낸 그럴싸한 판례·시장 통계·수치를 직원이 검증 없이 공식 보고서나 의사결정에 담으면, 하나의 환각이 연쇄적인 오판으로 증폭됩니다. 근거가 결여된 생성물이 조직의 판단 회로에 조용히 주입되는 것입니다.
넷째, 자율 에이전트의 무단 행동. 가장 새롭고 폭발력이 큰 갈래입니다. 통제 밖에서 배포된 AI 에이전트는 사람보다 훨씬 빠른 속도로 시스템에 접근하고 데이터를 조작합니다. 사람의 실수는 한 번에 한 건이지만, 잘못 설정된 에이전트의 실수는 초당 수천 건입니다. 피해 반경(blast radius)이 사람의 속도가 아니라 기계의 속도로 벌어집니다.
네 갈래의 공통점은, 이것이 모델의 성능 문제(capability)가 아니라 모델을 놓은 자리의 문제(governance)라는 것입니다. 아무리 뛰어난 모델도 통제되지 않은 자리에 놓이면 이 네 위험을 그대로 증폭합니다.
78%가 몰래 쓰는데, 정책은 12%뿐입니다
그렇다면 이건 몇몇 부주의한 직원의 일탈일까요. 숫자는 정반대를 말합니다. 최근 조사에서 직원의 78~90%가 IT의 승인이나 통제 없이 개인 계정으로 AI 도구를 업무에 쓰고 있었습니다. 반면 공식 AI 거버넌스 정책을 갖춘 기업은 12%에 불과했습니다. 거의 모두가 쓰는데, 거의 아무도 관리하지 않는 상태, 수요와 통제 사이의 간극이 이토록 벌어진 기술은 드뭅니다.
직원들이 악의로 그러는 것이 아닙니다. 밀려드는 업무 속에서 AI가 주는 생산성 향상(어떤 조사는 33%까지 봅니다.)을 뿌리치지 못할 뿐입니다. 여기서 관점을 뒤집어야 합니다. 이 78%는 위반자 명단이 아니라, 충족되지 못한 생산성 수요의 지도입니다. 직원들이 샛길로 가는 것은 회사가 안전한 큰길을 깔아 주지 않았기 때문입니다. 수요는 실재하는데 공식 공급이 없으니, 시장이 늘 그렇듯 암시장이 그 자리를 메운 것입니다.
그러니 이건 규율의 문제가 아니라 설계의 문제입니다. 문제의 원인을 사람에게서 찾으면 통제와 처벌로 가고, 구조에서 찾으면 설계로 갑니다. 그리고 오직 설계만이 이 문제를 실제로 해소합니다.
금지는 왜 실패하는가
많은 조직의 첫 반응은 차단입니다. 사내 네트워크에서 AI 접속을 막는 금지 위주 정책(prohibition-based governance). 그러나 이 방식이 실패한다는 것은 이미 여러 현장에서 증명됐습니다. 막으면 직원들은 더 추적하기 어려운 우회로를 찾을 뿐입니다. 개인 폰으로, 퇴근 후 집에서, 승인받은 SaaS 안에 얹힌 내장 AI로. 금지는 위협을 없애지 못하고, 그저 가시성 밖으로 밀어냅니다. 통제하려던 시도가 오히려 탐지 가능성을 떨어뜨리는 역설입니다.
기술적으로도 기존 방어 도구는 이 전선을 지키지 못합니다. DLP(데이터 유출 방지)와 CASB(클라우드 접근 보안 중개)는 파일 전송과 클라우드 앱 접근을 통제하도록 설계됐지, 프롬프트에 담긴 의미를 읽도록 만들어지지 않았습니다. 세 가지 이유입니다. 첫째, AI로 오가는 트래픽은 대부분 암호화(TLS)돼 있어 종단 간 내용 검사가 어렵습니다. 둘째, 내장 AI는 이미 화이트리스트에 오른 정상 SaaS 도메인을 통해 작동하므로 CASB의 허용된 앱으로 통과합니다. 셋째, 무엇보다 이 도구들에는 자연어 프롬프트에서 민감 정보와 맥락을 식별하는 계층 자체가 없습니다. 소스코드 한 덩어리가 채팅창에 붙여넣기 되는 것과 평범한 질문 하나를 구분하지 못합니다.
정리하면, 금지는 수요를 음지로 밀어내고, 기존 도구는 그 음지를 살펴 볼 눈이 없습니다. 그래서 대부분의 조직은 통제하고 있다는 착각 속에서 실제로는 아무것도 통제하지 못합니다. 통제가 필요 없다는 말이 아닙니다. 통제의 방향이 틀렸다는 것입니다. 막는 통제는 위협을 음지로 숨기지만, 길을 여는 통제는 위협을 양지로 끌어냅니다.
그래서 우리는 막는 대신, 안전한 길을 깝니다
CHANSWER가 이 문제 앞에서 택하는 자리가 여기입니다. 금지의 반대말은 방치가 아니라 설계된 개방입니다. 세 겹으로 세웁니다.
하나, 안전한 공식 경로(Sanctioned AI Pathway)를 먼저 엽니다. 직원이 섀도우 AI로 향하는 근본 동력은 생산성입니다. 그 갈증을 막을 것이 아니라, 안전하게 풀어 줘야 합니다. 핵심은 데이터가 조직을 떠나지 않는 아키텍처입니다. 학습에 데이터를 쓰지 않는 계약(training opt-out)과 테넌트 격리(tenant isolation)가 보장된 프라이빗 LLM을 두고, 사내 지식을 붙일 때는 원문을 밖으로 보내는 대신 데이터가 사내에 머무는 검색 증강(data-resident RAG) 구조로 근거만 주입합니다. 접근은 SSO와 역할 기반 권한(RBAC)으로 묶고, 모든 프롬프트와 응답은 감사 로그로 남기며, 외부로 나가는 트래픽은 이그레스(egress) 통제로 관문을 둡니다. 이렇게 하면 직원은 샛길보다 빠르고 편한 큰길을 얻고, 회사는 그 길 위에서 벌어지는 일을 전부 봅니다. 데이터를 밖으로 내보내지 않으면서 AI를 쓰는 이 구조는, 우리가 여러 사례에서 다뤄 온 데이터 주권의 원리 위에 있습니다.
둘, 프롬프트 계층의 탐지·가시화 아키텍처를 세웁니다. DLP·CASB가 놓치는 그 지점, 브라우저에서 AI로 흘러가는 프롬프트 자체를 검사하는 AI 특화 관문(AI gateway)을 둡니다. AI 사용 현황을 실시간으로 가시화하고, 민감 정보(PII·소스코드·자격증명 등)가 프롬프트에 담기면 실시간으로 마스킹하거나 차단하거나 경고합니다. 파급이 큰 자율 에이전트의 행동에는 사람의 승인 게이트(HITL)를 두어, 확률적으로 움직이는 AI를 결정적 가드레일로 감쌉니다. 원칙은 단순합니다. 보이지 않는 것은 관리할 수 없습니다.
셋, 리터러시를 조직의 체질로 심습니다. 기술적 통제만으로는 부족합니다. 퍼블릭 클라우드 AI가 데이터를 어떻게 다루는지, 어떤 데이터를 어떤 경로에 넣어선 안 되는지를 구체적 가이드라인으로 가르쳐야 합니다. 직원들에게 금지 목록을 던지는 것이 아니라, 판단의 기준을 손에 쥐여 주는 일입니다. 자동화가 사람을 방어선 밖으로 밀어내는 것이 아니라, 사람을 방어선의 가장 앞줄로 세우는 것입니다. 이 세 겹을 조직의 체질로 함께 심어 나가는 일이 FORWARD가 하는 역할입니다.
준비는 감이 아니라, 등급입니다
안전한 길을 깔았다고 끝이 아닙니다. 어떤 AI 사용을 어디까지 허용할지를 감이 아니라 등급으로 정해야 합니다. 모든 AI 사용을 같은 무게로 다루면, 통제는 과하거나 부족한 양극단으로 흐릅니다.
실전에서는 사용 사례를 리스크 등급으로 분류하고, 각 등급에 승인 티어를 매핑합니다. 마케팅 문구 초안처럼 민감도가 낮은 작업은 공식 경로 안에서 자유롭게 열어 두고, 고객 개인정보나 규제 데이터가 얽힌 고위험 작업은 별도 승인과 감사, HITL을 요구하는 식입니다. 이 리스크 등급을 뒤에서 설명할 EU AI Act의 위험 분류 체계와 정렬해 두면, 컴플라이언스가 사후 대응이 아니라 설계에 내장됩니다.
그리고 이 모든 것을 지표로 관리합니다. 공식 경로를 통한 사용 비율(sanctioned ratio), 프롬프트에 민감 정보가 유입되는 빈도, 아직 음지에 남은 섀도우 사용의 탐지율. “우리는 잘 관리되고 있다”는 말은 아무것도 바꾸지 못합니다. 관리되는 것은 측정되는 것뿐입니다.
이건 보안 이슈가 아니라, 이사회의 문제입니다
마지막으로, 이 문제의 무게를 다시 재야 합니다. 섀도우 AI는 IT 부서의 기술 이슈로 격하해 둘 사안이 아닙니다.
2026년 8월 본격 시행되는 EU AI Act 같은 규제 환경에서, 섀도우 AI는 보안을 넘어 컴플라이언스의 문제가 됩니다. 이 규제는 AI를 위험도에 따라 등급으로 나누고, 고위험 AI를 사용하는 배포자(Deployer)에게 별도의 의무를 부과합니다. 문제는, 직원이 임의로 고위험 AI 도구를 업무에 끌어 쓰는 순간 회사가 자신도 모르는 사이에 이 배포자의 지위에 서게 된다는 것입니다. 즉 섀도우 AI는 회사가 알지도 못하는 규제 의무를 회사 몰래 발생시키고, 그 위반의 책임은 고스란히 법인에 돌아옵니다. 과징금은 매출의 상당 비율에 이를 수 있습니다.
데이터 주권, 규제 노출, 조직 문화가 한데 얽힌 이 문제는, CISO의 대시보드를 넘어 이사회의 어젠다로 격상되어야 합니다. 리스크를 감수할지 말지를 정하는 것은 결국 리더의 판단이고, 그 판단의 언어를 갖추는 일은 기술이 아니라 리더십의 몫이기 때문입니다.
막는 것이 아니라, 여는 것입니다
섀도우 AI는 직원의 배신이 아니라, 조직이 안전한 길을 설계하지 않은 결과입니다. 그러니 물어야 할 질문은 “어떻게 막을까”가 아니라 “어떻게 안전하게 열까”입니다.
약점은 숨길 때 가장 위험하고, 먼저 드러내 다룰 때 비로소 강점이 됩니다. 음지로 새어 나가던 직원들의 AI를 양지로 끌어내 안전한 길 위에 올릴 때, 조직 전체에 흩어져 있던 가장 큰 위협은 가장 큰 생산성의 원천으로 바뀝니다. 통제는 혁신을 막는 벽이 아니라, 혁신이 안전하게 흐르도록 내는 물길입니다. 격차는, 무엇을 금지했느냐가 아니라 무엇을 안전하게 열었느냐에서 갈립니다.
이 관점과 연결된 프로그램
- ATLAS · 지식 자산화 — 데이터가 사내를 벗어나지 않는(data-resident RAG·테넌트 격리), AI가 근거로 삼는 안전한 데이터 기반
- VERTICAL · 도메인 특화 파트너십 — 금융·헬스케어·공공 등 규제·민감 데이터 환경에 맞춘 리스크 등급·컴플라이언스 설계
- FORWARD · 상주형 파트너십 — 안전한 경로·프롬프트 계층 탐지·리터러시를 조직 체질로 심으며 함께 걸음
- HELM · 리더 AI 의사결정 — 섀도우 AI를 이사회 차원의 전략·컴플라이언스 과제로 다루는 리더십
CHANSWER는 기회를 답으로, 답을 역량으로 옮기는 일을 합니다. 지금 조직에 보이지 않게 새어 나가는 AI가 있다면, 그것을 막을 것이 아니라 안전하게 여는 아키텍처부터 함께 설계하겠습니다.
Comments are closed.