이 글은 Sonatype 공식 블로그의 Shadow AI Across Government: It's Three Problems, Not One을 에스코어가 공식 파트너로서 한국어로 번역한 콘텐츠입니다.
에스코어 인사이트
섀도 AI는 승인되지 않은 AI 서비스 사용에 따른 정보 유출 문제에 그치지 않습니다. AI 코딩 도구가 생성한 코드와 선택한 의존성, 그리고 개발·배포 과정에 유입되는 AI 모델까지 각각 다른 통제 지점이 필요합니다. 특히 코드 생성 단계와 모델 유입 단계의 위험을 일반적인 사내 AI 사용 정책만으로 관리하기는 어렵습니다.
에스코어는 이러한 위험을 데이터 반출 통제, AI 생성 코드 및 의존성 검증, AI 모델의 반입·출처 관리로 구분해 접근할 필요가 있다고 봅니다. 아래 번역문은 각 영역의 책임 주체와 통제 방안을 구체적으로 설명합니다.
Sonatype 원문 번역
대부분의 정부기관과 계약업체에는 이미 생성형 AI(GenAI) 사용 정책이 있습니다. 그러나 구성원들이 실제로 어떤 도구를 사용하고 있는지 파악하는 곳은 훨씬 적습니다.
이러한 간극을 가리키는 용어가 있습니다. 과거의 섀도 IT처럼 섀도 AI(Shadow AI)는 AI 도구, 서비스, 컴포넌트가 조직의 관리 절차를 거치지 않고 도입되는 현상을 말합니다. 다만 섀도 IT가 주로 승인되지 않은 애플리케이션의 형태로 나타났다면, 섀도 AI는 그보다 더 다양한 위험을 일으킬 수 있습니다.
섀도 AI의 위험은 세 지점에서 발생합니다.
•
조직의 환경 밖으로 나가는 데이터
•
개발자가 커밋하는 AI 생성 코드
•
빌드 과정에서 다운로드하는 AI 모델과 기타 컴포넌트
이 세 가지를 흔히 하나의 위험으로 이야기하지만 실제로는 서로 다릅니다. 실패가 발생하는 방식도, 담당하는 조직도 다르며, 이를 해결하는 통제 수단도 거의 겹치지 않습니다. 조직이 훌륭한 AI 사용 정책을 갖추고 있더라도, 자체 소프트웨어 안에서 어떤 AI 모델이 실행되는지는 전혀 모를 수 있습니다.
그렇다고 AI 도입에 반대하자는 뜻은 아닙니다. AI 도구를 통한 생산성 향상 효과는 실제로 나타나고 있으며, 이러한 도구를 가장 효과적으로 활용하는 조직은 사용을 금지하려 하기보다 조직이 승인한 방식으로 쉽고 편리하게 사용할 수 있는 환경을 마련한 조직입니다. 다만 그러려면 구성원들이 실제로 어떤 경로를 이용하는지 볼 수 있어야 합니다.
세 가지 문제가 각각 무엇인지, 누가 책임지며, 어떻게 해결할 수 있는지 살펴보겠습니다.
AI 도입은 이미 이루어졌습니다
Verizon의 2026년 데이터 침해 조사 보고서에 따르면, 회사 기기에서 정기적으로 AI를 사용하는 직원의 비율은 승인 여부와 관계없이 45%에 이릅니다. 1년 전의 15%에서 크게 증가한 수치입니다. 이 사용자 중 3분의 2는 회사 계정이 아닌 계정으로 AI 서비스에 접근했습니다. 기기 비용을 부담하는 조직 입장에서는 이러한 활동을 대부분 파악할 수 없다는 뜻입니다.
같은 보고서의 데이터 손실 방지(DLP) 조사 결과에서 섀도 AI는 악의적 의도가 없는 내부자 행위 가운데 세 번째로 많이 나타났습니다. 외부 AI 서비스로 전송된 데이터 중 가장 흔한 유형은 소스코드였습니다.
마지막 사실에 주목해야 합니다. 세 가지 문제가 모두 연결되는 지점이기 때문입니다. 소스코드가 외부로 나가는 것은 정보 유출 문제입니다. 그 코드를 받은 AI 어시스턴트는 다시 코드와 의존성 선택 결과를 돌려줍니다. 그리고 이러한 도구를 뒷받침하는 모델 자체도 점점 더 애플리케이션 내부의 컴포넌트로 유입되고 있습니다.
하나의 행동이 세 가지 노출 위험으로 이어지는 것입니다.
첫 번째 문제: 외부로 나가는 데이터
대부분의 정책이 이미 다루는 문제이며, 섀도 AI라고 할 때 일반적으로 떠올리는 상황입니다. 직원이 계약서 문구, 인사 정보 또는 통제 대상 비기밀 정보(CUI)를 요약하거나 다시 작성하기 위해 공개 챗봇에 붙여 넣는 경우가 이에 해당합니다.
•
책임 주체: 보안 및 개인정보 보호 조직, 기록 관리 담당자, AI 사용 정책 책임자
•
통제 수단: 직원들이 선호할 만한 승인된 플랫폼 제공, DLP와 네트워크 통제 적용, 승인 서비스의 구체적 명시, 실무 지침 제공
Verizon의 조사 결과는 금지만으로 문제가 해결되지 않는 이유를 보여줍니다. 직원이 개인 계정을 사용하면 AI 활용이 중단되는 대신 조직의 가시성 밖으로 더 멀어질 수 있습니다.
미국 전쟁부(DoW) 산하 조직에는 관련 지침이 이미 마련되어 있습니다. DoW 지침 8430.01은 생성형 AI 서비스가 부처의 시스템에 위치하고 부처 사용 승인을 받은 경우가 아니라면, 비공개 부처 정보를 해당 서비스에 입력하지 못하도록 합니다. 두 조건을 모두 충족해야 합니다.
이 문제를 해결하지 못하는 수단: 소프트웨어 공급망 관리 도구입니다. 저장소 통제, 자재명세서, 스캐너는 개발자가 브라우저에 코드를 붙여 넣는 행위를 포착하지 못합니다. 공급업체가 가능하다고 주장한다면 정확히 어떤 원격 측정 데이터를 수집하는지 확인해야 합니다.
두 번째 문제: 다시 들어오는 결과물
개발자들은 이미 코딩 어시스턴트를 사용하고 있습니다. 어시스턴트가 생성한 결과물은 아직 검증되지 않은 입력이며, 이에 대한 책임이 결과물을 만든 도구로 넘어가지는 않습니다.
DoW 지침 8430.01은 국방 분야에서 이 점을 분명히 합니다. AI 생성 코드는 검증되지 않은 것으로 취급하며, 배포하는 소프트웨어에 대한 책임은 전적으로 개발자와 해당 팀에 남습니다. 또한 소프트웨어의 생성이나 테스트에 사용된 모델, 버전, 주요 데이터셋의 기록을 소프트웨어 증빙 자료와 함께 보관하도록 요구합니다. 이는 소프트웨어 자재명세서(SBOM)와 유사한 방식으로 취급됩니다.
여기에는 더 미묘한 문제가 있습니다. 코딩 어시스턴트는 코드만 작성하지 않고 의존성도 선택합니다. 어시스턴트가 어떤 패키지를 추천하는 행위는 개발자를 대신해 공급망 관련 결정을 내리는 것과 같습니다. AI 코딩 도구가 의존성을 선택하는 속도와 양은 기존 검토 절차가 처리할 수 있는 수준을 넘어섭니다. 이는 생성된 코드 자체가 올바른지 확인하는 것과는 별개의 문제입니다. Sonatype은 이달 초 다른 글에서 이 주제를 더 자세히 다뤘습니다.
책임 주체: 엔지니어링 리더십과 애플리케이션 보안 조직입니다.
통제 수단: AI 어시스턴트의 결과물을 처음 보는 기여자가 제출한 풀 리퀘스트처럼 취급해야 합니다. 사람의 검토, 새로 도입된 모든 의존성에 대한 소프트웨어 구성 분석(SCA), 결과물 생성 과정에 관여한 모델의 기록이 필요합니다. 마지막 항목은 DoW의 요구사항일 뿐 아니라, 나중에 어떤 모델이 사용됐는지 답할 수 있는 유일한 방법이기도 합니다.
세 번째 문제: 빌드 과정에서 다운로드하는 컴포넌트
세 번째 문제는 가장 적게 논의되며, 사후에 파악하기도 가장 어렵습니다. AI 모델과 머신러닝 패키지가 소프트웨어 컴포넌트로 조직 환경에 유입되는 문제입니다.
Sonatype은 저장소 관리자를 우회하여 공개 저장소에서 직접 가져온 컴포넌트를 섀도 다운로드(shadow downloads)라고 부릅니다. Sonatype Research Labs는 Beyond Traditional Packages 보고서를 작성하는 과정에서 2026년 상반기 여러 고객의 Hugging Face 요청 9,658건을 조사했습니다. 이 가운데 약 7%가 정책에 따라 차단되거나 거부됐습니다. 차단된 모델 674개 중 55%는 모델의 허용 적합성 문제로, 18%는 보안 문제로 차단됐습니다. 기존 정책이 고려하지 못했던 거버넌스 문제가 AI 모델에서 나타나고 있다는 의미입니다.
모델은 일반적인 라이브러리와 다릅니다. 내부를 살펴보기 어려운 가중치 형태로 제공되며, 출력물의 사용 방법을 제한하는 라이선스 조건이 붙을 수도 있습니다. 공개된 이름만으로는 모델이 무엇을 바탕으로 만들어졌는지 거의 알 수 없습니다. 공개 모델을 미세 조정하거나 병합·양자화한 뒤 새로운 배포자의 이름으로 다시 공개하는 일이 흔하기 때문입니다. 미국 연방정부의 세 가지 배제 명령은 특정 모델 개발업체를 지목하고, 해당 업체의 구현물을 '사용하여 개발한' 제품까지 적용 범위를 넓혔습니다. 이제 모델 출처는 엔지니어링뿐 아니라 조달에서도 확인해야 할 사항이 됐습니다.
책임 주체: 플랫폼 엔지니어링 조직과 저장소 관리자 운영 담당자입니다.
통제 수단: 관리되는 단일 반입 경로를 마련하는 것입니다. 모든 요청을 한곳에서 확인할 수 있도록 모델 다운로드를 프록시 저장소로 경유시키고, 사내망에서 직접 다운로드하는 경로를 차단하며, 클라이언트 설정을 고정해 우회가 쉽게 일어나지 않도록 해야 합니다. Sonatype Firewall은 이러한 경계에서 개발자에게 전달되기 전에 모델을 감사하거나 격리할 수 있습니다. 먼저 감사 모드에서 실제 다운로드 현황을 파악한 다음 격리 단계로 전환하는 방식이 좋습니다. 검사 단계에서는 Sonatype Lifecycle이 파생 모델을 식별하고 기반 모델을 표시하며, AI Models Usage 대시보드는 계보, 커밋 해시, 게시일과 함께 어떤 애플리케이션에서 모델을 사용하는지 보여줍니다.
이는 엔지니어링 밖에서도 중요합니다. 미국 국가안보국(NSA)을 비롯한 8개 국가기관이 공동 발표한 AI·머신러닝 공급망 위험 지침은 조달 조건으로 공급업체에 AI 자재명세서(AI BOM)를 요구하도록 권고합니다. 정작 구매 조직이 직접 그러한 자료를 만들 수 없다면 공급업체에 요구하기도 어렵습니다.
어떻게 대응해야 할까요?
각자가 맡은 영역부터 살펴보아야 합니다. 세 가지 문제는 서로 다른 업무이며, 한 사람이 모두 담당하는 경우는 드뭅니다.
정책 담당자라면: 승인된 서비스의 범주만 적지 말고 구체적인 이름을 명시해야 합니다. 사용 정책과 함께 직원들이 다른 방법보다 선호할 만한 플랫폼을 제공하고, 필요한 자산 목록도 실제로 관리되는지 확인해야 합니다. OMB 메모 M-26-05는 각 기관장이 기관 네트워크에서 사용하는 소프트웨어의 보안에 책임을 지고 완전한 자산 목록을 유지하도록 지시합니다. 모델도 소프트웨어입니다.
컴플라이언스 담당자라면: 사이버보안 성숙도 모델 인증(CMMC)과 관련된 의무가 2단계 시행 중단으로 사라진 것은 아닙니다. DFARS 252.204-7012, NIST SP 800-171, 공급업체 성과 위험 시스템(SPRS) 점수 산정은 달라지지 않았으며, 연례 확인 의무도 유지됩니다. 실제 환경과 맞지 않는 준수 확인서가 위험의 원인이 됩니다. 조직에 보고되지 않은 AI 도구가 바로 그러한 불일치를 만듭니다.
플랫폼 담당자라면: 통제 강제보다 가시성 확보부터 시작해야 합니다. 모델 다운로드 앞단에 프록시를 두고 Sonatype Firewall을 감사 모드로 켠 다음, 차단하기 전에 2주 동안 실제로 무엇이 들어오는지 살펴보아야 합니다. 대부분의 팀은 예상하지 못한 결과를 발견하게 되며, 바로 그 발견이 도입의 사업적 근거가 됩니다. 이후에는 이 과정을 지속적으로 운영해야 합니다. 자산 목록은 작성한 날부터 낡기 시작합니다. 반입 경로를 하나로 통합하는 이유는 기록이 연례 수작업이 아니라 지속적으로 자동 갱신되도록 하기 위해서입니다.
섀도 AI의 핵심 문제는 이제 구성원들이 AI 도구를 도입할 것인지가 아닙니다. 이미 사용하고 있기 때문입니다. 이제 중요한 것은 다음 세 가지를 식별할 수 있는지입니다.
•
어떤 서비스가 조직의 데이터를 받는가?
•
어떤 모델이 코드 작성을 돕는가?
•
어떤 모델이 실제 배포 소프트웨어 안에서 실행되는가?
세 가지 질문, 세 가지 책임 주체, 그리고 하나의 답이 있습니다. 볼 수 있는 것만 관리할 수 있습니다.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide