안녕하세요,
그로메트릭 입니다. 🐸
생성형 AI 사용 정책은 마련했지만 실제로 어떤 AI가 쓰이고 있는지는 파악하지 못한 조직이라면 가볍게 넘겨서는 안 될 소식입니다.
더욱더 늘어나는 AI 보안 위협, 소나타입(Sonatype)은 섀도우 AI를 하나의 위험이 아니라 세 가지 서로 다른 문제로 나눠 설명합니다.
훌륭한 사용 정책이 있더라도 자사 소프트웨어 안에서 어떤 AI 모델이 동작하는지 모를 수 있다는 점에서, 소프트웨어 공급망 보안 관점의 실질적인 비즈니스 리스크로 이어질 수 있는 사안입니다.
*아래 글은 소나타입(Sonatype)의 공식 블로그 글을 번역하여 작성되었습니다.
섀도우 AI는 하나의 위험이 아니라 '세 가지 문제'입니다
요약
- 대부분의 기관과 계약업체는 생성형 AI 정책을 갖췄지만, 구성원이 실제로 운영하는 것을 설명할 수 있는 곳은 훨씬 적습니다.
- 섀도우 AI는 데이터 유출, AI 생성 코드 유입, AI 모델 반입의 세 지점에서 위험을 만들며, 실패 방식과 책임 주체, 통제 수단이 서로 다릅니다.
- Verizon의 2026 데이터 침해 조사 보고서(DBIR) 공공 부문 스냅샷에 따르면 회사 기기에서 AI를 정기적으로 쓰는 직원은 1년 전 15%에서 45%로, 30%p 증가했습니다.
- Sonatype Research Labs의 감사에서 2026년 상반기 허깅페이스 요청 9,658건 중 약 7%가 정책에 따라 차단 또는 거부됐습니다.
섀도우 AI(Shadow AI)란 무엇이고, 왜 세 가지 문제로 나눠서 봐야 할까? 🤖
대부분의 기관과 계약업체는 생성형 AI(GenAI) 정책을 갖추고 있습니다. 하지만 자기 조직의 구성원이 실제로 무엇을 운영하는지 설명할 수 있는 곳은 훨씬 적습니다.
이 간극을 지칭하는 이름이 있습니다. 섀도우 IT(Shadow IT)와 비슷하게 섀도우 AI(Shadow AI)라고 하는데, 이는 AI 도구, 서비스, 구성 요소가 조직을 통제하기 위한 프로세스 밖에서 유입될 때 발생하는 현상을 일컫습니다. 섀도우 IT가 대부분 승인되지 않은 애플리케이션의 형태였다면, 섀도우 AI는 그 범위가 훨씬 넓습니다.
섀도우 AI는 아래의 세 지점에서 위험을 만들 수 있습니다.
- 조직 환경 밖으로 나가는 데이터
- 개발자가 커밋하는 AI 생성 코드
- 빌드가 내려받는 AI 모델 및 기타 구성 요소
이 세 가지는 보통 하나의 위험으로 여겨지지만, 그렇지 않습니다. 실패 방식과 책임 주체가 다르고, 이를 다루는 통제 수단도 거의 겹치지 않습니다. 훌륭한 허용 사용 정책을 갖추고도 자사 소프트웨어 내부에서 어떤 AI 모델이 실행되고 있는지 모를 수도 있습니다.
이는 AI 도입에 반대하는 주장이 아닙니다. 생산성 향상은 분명 존재하며, 이 도구를 사용함으로써 가장 성과를 내는 조직은 사용을 금지하려 한 곳이 아니라 승인하여 잘 사용할 수 있도록 만든 조직입니다. 다만 이는 구성원이 사용하는 AI를 조직이 정확하게 파악하고 있을 때에만 효과가 있습니다.
그럼 지금부터 각각의 문제 를 무었인지, 이 문제의 책임 주체는 누구일지, 그리고 어떻게 이 문제를 해결할 수 있는지를 설명드리겠습니다.
섀도우 AI는 이미 진행중... ‼️
Verizon의 2026 데이터 침해 조사 보고서에 따르면, 승인 여부와 관계없이 회사 기기에서 AI를 정기적으로 사용하는 직원은 현재 45%로, 1년 전의 15%에서 30%p 늘었습니다. 이들의 2/3는 개인 계정으로 AI를 사용하는데, 이 말인즉슨 업무를 위해 장비를 제공한 회사가 정작 업무 내용을 확인할 수 없다는 의미입니다.
섀도우 AI는 이 보고서의 데이터 유출 방지(DLP) 분석에서 악의 없는 내부자 행위 중 세 번째로 흔한 유형이며, 외부 AI 서비스로 전송되는 데이터 중 가장 흔한 범주는 소스 코드입니다.
이 마지막 사실은 세 가지 문제를 모두 연결하기 때문에 짚어볼 만합니다. 코드를 외부 AI에 넣는 순간 조직의 정보가 밖으로 나갑니다. 그 코드를 받은 AI가 답으로 코드와 패키지를 돌려주면 개발자가 이를 반영합니다. 그리고 이런 도구의 기반이 되는 모델은 점점 자사 애플리케이션 내부의 구성 요소로 들어옵니다.
결국 하나의 행동이 세 가지 노출 결과를 야기하게 되는 것입니다.
문제 1: 어떤 데이터가 밖으로 나가는가? 📁
대부분의 정책이 이미 다루고 있는 문제이며, 섀도우 AI라고 하면 사람들이 가장 먼저 떠올리는 문제입니다. 직원이 계약서 문구, 인사 데이터, 통제된 비분류 정보(CUI)를 공개 챗봇에 붙여넣어 요약하거나 다시 쓰게 하는 경우입니다.
- 책임 주체: 보안·개인정보 보호 팀, 기록 관리 담당자, 허용 사용 정책 담당자
- 통제 수단: 사람들이 더 선호할 승인 플랫폼 제공, 데이터 유출 방지 및 네트워크 통제, 승인 서비스 명시, 실무 지침 제공
Verizon의 조사 결과는 금지만으로는 효과가 없을 수 있음을 보여줍니다. 직원이 개인 계정으로 옮겨가면 AI 사용이 중단되기는커녕 도리어 시야에서 벗어날 수 있습니다.
미국 국방부(DoW)는 이미 이를 지침으로 명시하고 있습니다. DoW 지침 8430.01에 따르면, 1) 해당 서비스가 부서 시스템 안에서 운영되고 2) 부서 사용 승인을 받은 경우에만, 비공개 정보를 생성형 AI에 입력할 수 있습니다. 둘 중 하나만 충족해서는 허용되지 않습니다.
이 문제는 소프트웨어 공급망 보안 도구로는 해결할 수 없습니다. 저장소 통제, 자재 명세서, 스캐너 어느 것도 개발자가 브라우저에 코드를 붙여넣는 행위를 감시할수는 없기 때문입니다. 이를 막을 수 있다고 주장하는 벤더가 있다면, 어떤 데이터를 근거로 탐지하는지 정확히 파악하세요.
문제 2: 무엇이 다시 안으로 들어오는가?🚪
개발자들은 코딩 어시스턴트를 사용하고 있습니다. 이 경우, 어시스턴트가 내놓은 결과물은 검증을 거치지 않은 외부 유입물이며, 그에 대한 책임은 어시스턴트가 아닌 개발자 쪽에 있다는 사실을 명심해야합니다.
DoW 지침 8430.01은 국방 업무에서 이 점을 명확히 규정하고 있습니다. AI 생성 코드는 검증되지 않은 것으로 간주하며, 개발자와 그 팀은 본인들의 결과물에 대해 전적으로 책임을 집니다. 또한 소프트웨어 개발에 코드 생성이나 테스트에 사용한 모델, 버전, 주요 데이터셋의 기록을 소프트웨어 증빙 패키지와 함께 보관하고 SBOM과 유사한 것으로 취급합니다.
사실 진짜 문제는 코딩 어시스턴트가 코드만 작성하지 않고 의존성도 선택한다는 점입니다. 어시스턴트가 패키지를 제안하는 것은 사용자를 대신해 공급망 의사결정을 내리는 일이며, 기존 어떤 검토 프로세스도 상정하지 않은 속도와 규모로 이뤄집니다. 이는 코드가 올바른지의 문제와는 다릅니다.
결과적으로 책임 소재는 엔지니어링 조직 총괄과, 애플리케이션 보안 담당자에게 있습니다.
이 문제를 해결하는 방법은 AI어시스턴트 결과물을 검증되지 않은 외부 기여자의 PR처럼 취급하는 것입니다. 사람의 검토, 어시스턴트 출력물에 대한 소프트웨어 구성 분석(SCA), 그리고 어떤 모델이 관여했는지에 대한 기록이 필요합니다. 이는 DoW의 요구사항이면서, 나중에 어떤 모델이 어떤 작업을 수행하였는지 확인할 수 있는 유일한 방법입니다.
문제 3: 빌드는 무엇을 내려받는가? 📥
세 번째 문제는 거의 논의되지 않고, 사후에 파악하기 가장 어렵습니다. AI 모델과 머신러닝 패키지가 '구성 요소'로 반입되는 경우입니다.
소나타입은 저장소 관리자를 우회해 공개 저장소에서 곧바로 가져온 구성 요소를 섀도우 다운로드(shadow download)라고 부릅니다.
Sonatype Research Labs는 Beyond Traditional Packages 보고서의 일환으로 2026년 상반기 일부 고객사의 허깅페이스 요청 9,658건을 감사했습니다. 그중 약 7%가 정책에 따라 차단 또는 거부됐습니다. 차단된 674개 모델 중 55%는 조직 정책상 사용이 허용되지 않아, 18%는 보안 사유로 막혔는데, 이는 모델이 기존 정책이 상정하지 않은 거버넌스 질문을 제기하고 있음을 보여줍니다.
모델은 라이브러리와 다릅니다.
알 수 없는 숫자 덩어리 형태로 도착하고, 모델 기반 출력물의 사용 조건을 정한 라이선스가 있을 수 있으며, 오픈 모델은 파인튜닝, 병합, 양자화를 거쳐 새로운 이름으로 재출시되는 일이 비일비재하기 때문에 단순히 이름만으론 무엇을 기반으로 만들어졌는지 거의 알 수 없습니다. 현재 연방 정부 조달에서 특정 업체를 배제하는 제외 명령이 3건 있는데, 모두 하나의 모델 개발사를 지목하고 있으며 그 개발사의 모델을 기반으로 만든 제품까지 적용 대상에 포함하므로, 모델 출처는 단순히 엔지니어링 문제만이 아니라 조달 문제로까지 확장되었습니다.
결국 이 문제의 책임 소재는 플랫폼 엔지니어링, 저장소 관리자를 운영하는 조직에 있습니다.
해결책은 하나의 통제된 유입 경로입니다.
- 모델 다운로드를 프록시 저장소로 라우팅해 모든 요청을 한곳에서 확인
- 기업 네트워크에서의 직접 다운로드 차단
- 클라이언트 설정을 잠가 경로가 조용히 우회되지 않도록 함
이 경계에서 Sonatype Firewall이 개발자가 모델을 받기 전에 감사하거나 격리할 수 있습니다. 감사 모드로 시작해 팀이 실제로 무엇을 내려받는지 확인한 뒤 격리로 전환합니다. 스캔 시점에는 Sonatype Lifecycle이 모델을 파생 모델로 표시하고 어떤 기반 모델에서 나왔는지 알려주며, AI Models Usage 대시보드는 어떤 애플리케이션이 모델을 사용하는지 계보, 커밋 해시, 게시일과 함께 보여줍니다.
마지막 부분은 엔지니어링 측면을 넘어 더 중요한 의미를 지닙니다. 국가안보국(NSA)과 7개 국가 기관이 공동 서명한 AI 및 머신러닝 공급망 위험 공동 지침은 조직이 조달 조건으로 벤더에게 AI 자재 명세서(AI BOM)를 요구하도록 안내합니다. 스스로 만들어낼 수 없는 것을 공급업체에 요구하는 입장은 유지하기 어렵습니다.
섀도우 AI 대응, 담당 영역별로 무엇부터 해야 할까?🛡️
영역을 나눠야 합니다. 이 세 가지는 서로 다른 업무이며, 한 사람의 몫인 경우는 드뭅니다.
1. 정책을 담당한다면 범주가 아니라 구체적인 승인 서비스를 명시하고, 구성원이 개인 계정보다 선호할 만한 승인 플랫폼을 함께 제공해야 합니다. 그런 다음 인벤토리 의무가 이행되고 있는지 확인해야 합니다. OMB 각서 M-26-05는 각 기관장이 기관 네트워크상 소프트웨어의 보안에 책임을 지도록 하고, 기관이 완전한 인벤토리를 유지하도록 지시합니다. 모델 또한 소프트웨어라는 것을 인지해야 합니다.
2. 컴플라이언스를 담당한다면 사이버보안 성숙도 모델 인증(CMMC)과 연관 지어 생각하는 의무는 2단계가 유예됐다고 해서 사라지지 않았습니다. DFARS 252.204-7012, NIST SP 800-171, 공급업체 성과 위험 시스템(SPRS) 점수는 그대로이며, 연간 확약도 유효합니다. 환경과 맞지 않는 확약은 노출이며, 그 격차가 바로 미공개 AI 도구가 만들어내는 것입니다.
3. 플랫폼을 담당한다면 처음부터 차단 정책을 걸지 말고, 먼저 어떤 모델이 들어오는지 확인하는 것부터 시작해야 합니다. 모델 다운로드 앞에 프록시를 두고 Sonatype Firewall을 감사 모드로 켠 뒤, 무엇이든 차단하기 전에 2주 동안 결과를 확인하세요. 대부분의 팀이 놀라는데, 그 놀라움이 도입의 근거입니다. 그런 다음 이를 지속적으로 유지하세요. 한 번 작성한 인벤토리는 시간이 지날수록 현실과 어긋나고, 새로 발견되는 취약점도 반영하지 못합니다. 모든 유입을 단일 경로로 모으는 이유는 기록이 연례 작업에 의존하지 않고 스스로 최신 상태를 유지하도록 하기 위해서입니다.
결국 볼 수 있는 것만 통제할 수 있습니다 👀
섀도우 AI는 더 이상 사람들이 이 도구를 도입할지의 문제가 아닙니다. 이미 도입은 됐고, 이제부터라도 중요한 것은 아래를 식별할 수 있는지입니다.
- 어떤 서비스가 우리 데이터를 받고 있는가
- 어떤 모델이 우리 코드를 작성하는 데 도움을 주는가
- 어떤 모델이 우리가 출시하는 소프트웨어 안에서 실행되는가
세 가지 질문, 세 곳의 책임 주체, 그러나 답은 하나입니다. 볼 수 있는 것만 통제할 수 있습니다.
연방 기관이 소프트웨어에 유입되는 AI 모델과 오픈소스 구성 요소를 통제하도록 소나타입이 어떻게 지원하는지는 소나타입 정부 솔루션에서 확인할 수 있습니다.
출처
소나타입 블로그 : Shadow AI Across Government: It's Three Problems, Not One