요약 보고서

수년간 기업 보안은 새로운 기술을 관리하기 위해 엄격한 방화벽과 광범위한 금지 조치에 의존해 왔습니다. 그러나 생성형 AI의 등장으로 이러한 접근 방식은 실패했습니다. 직원들이 기업의 차단 조치를 우회하여 AI를 사용하면서 대규모의 “섀도우 AI” 취약점이 발생하고 있습니다. 이 글에서는 기업의 AI 도입에 있어 진정한 병목 현상은 완벽한 모델을 찾는 것이 아니라, 민감한 데이터를 노출하지 않고 팀이 모든 공개 AI를 안전하게 사용할 수 있도록 하는 제어 인프라를 구축하는 데 있다는 점을 살펴봅니다.

간략 분석: 기업 AI의 현황

• 금지 조치의 현실:  사무직 근로자의 80%는 IT 부서가 모르는 사이에 공용 AI 도구를 사용하고 있다.
• 데이터 유출 비용:  조직의 60%가 이미 승인되지 않은 GenAI 사용으로 인한 데이터 유출을 경험했습니다.
• 패러다임의 전환:  기존의 데이터 손실 방지(DLP) 방식은 위험이 초기 단계에서 발생하기 때문에 불충분합니다.
• 해결책:  “모든 것을 차단하는” 방식에서 벗어나 민감한 데이터가 AI 모델에 도달하기 전에 토큰화하는 “제어 계층” 접근 방식으로 전환하는 것입니다.

1. AI 차단이 섀도우 AI를 막지는 못합니다: 기업 AI 보안은 가시성 확보에서 시작해야 합니다

ChatGPT, Claude, Copilot 및 기타 공개 LLM 도구가 업무 환경에 도입되었을 때, 많은 IT 및 보안 팀의 첫 번째 반응은 예상대로 접근을 차단하는 것이었습니다. 방화벽에 도메인을 추가하고, 브라우저 확장 프로그램을 제한하고, 승인되지 않은 사용을 금지하는 것이었습니다. 표면적으로는 이것이 책임감 있는 기업 AI 보안 정책처럼 보입니다.

실제로 이러한 방식은 거의 효과가 없습니다. 직원들은 더 빠르게 움직이고, 더 빠르게 글을 쓰고, 더 빠르게 요약하고, 더 빠르게 결과물을 내놓아야 한다는 압박에 시달립니다. 공개된 AI 도구들은 바로 이러한 압박을 해소하는 데 도움을 줍니다. 그 결과, 사무직 직원의 80%가 IT 부서의 인지나 승인 없이 공개 AI 도구를 사용하고 있으며, 개발자의 45%는 마감일을 맞추기 위해 승인되지 않은 코드 도우미를 사용한다고 보고했습니다. 이것이 바로  섀도우 AI 의 핵심 현실입니다 . 공식적인 승인이 없더라도 AI 사용은 계속되고 있는 것입니다.

바로 이러한 이유 때문에 AI를 차단하는 것은 섀도우 AI 문제를 해결하지 못합니다. 차단은 단지 가시성, 정책 제어 및 감사 가능성을 제거할 뿐입니다. 기업 차원의 AI 사용을 막는 대신, 조직은 계약, 고객 데이터, 재무 계획 및 내부 지식이 감독 없이 외부 모델에 노출될 수 있는 숨겨진 보안 계층을 만들어냅니다. 이러한 비즈니스 영향은 이미 측정 가능합니다. AI 관련 사고는 기존 보안 사고에 비해 식별하는 데 26.2%, 차단하는 데 20.2% 더 많은 시간이 소요됩니다.

2. 기업 AI의 진정한 위험은 모델뿐만 아니라 입력 레이어에 있다.

기존 기업 보안은 애플리케이션, 엔드포인트 및 네트워크 경계를 중심으로 구축되었습니다. 하지만 생성형 AI는 이러한 모델을 변화시킵니다. 기업 AI 워크플로에서 가장 큰 위험은 모델 공급업체 자체가 아니라  입력 계층 , 즉 직원들이 모델에 입력하는 프롬프트, 붙여넣은 문서 및 실제 비즈니스 컨텍스트인 경우가 많습니다.

바로 이 지점에서 실질적인 데이터 유출 위험이 발생합니다. 직원들은 일상적으로 계약서, 개인 식별 정보(PII), 정책 문서, 재무 예측 자료, 지원 로그, 그리고 기업 기밀 소스 코드 등을 AI 프롬프트에 붙여넣습니다. 다시 말해, 프롬프트 자체가 새로운 데이터 손실의 온상이 된 것입니다. 따라서 기업의 AI 거버넌스는 더 이상 모델 선정에만 집중해서는 안 됩니다.  어떤 민감한 데이터가 어떤 정책에 따라 어떤 감사 추적 기록과 함께 모델에 접근하는지, 즉 보다 실질적인 질문에 답해야 합니다.  이러한 이유로  NIST AI 위험 관리 프레임워크 와 같은 프레임워크는  AI 실험에서 관리형 배포로 전환하는 보안 및 기술 책임자들에게 점점 더 중요해지고 있습니다.

시장 신호도 같은 방향을 가리킵니다. 전 세계 LLM 보안 시장은 2025년 42억 달러에서 2034년 287억 달러로 성장할 것으로 예상되며, 이는 연평균 23.7%의 성장률을 나타냅니다. 기업들이 이 분야에 투자하는 이유는 모델 품질이 불확실해서가 아닙니다. 안전한 AI 도입은 프롬프트 계층에서 데이터 노출을 제어하는 ​​데 달려 있기 때문에 투자하는 것입니다.

기업의 AI 도입을 가로막는 진정한 병목 현상은 모델 역량이 아니라, 민감한 데이터가 프롬프트에 도달하기 전에 이를 보호하는 기업 AI 보안 인프라의 부재입니다.

3. 기존 통제 방식이 미흡한 이유

기존 데이터 손실 방지(DLP) 도구를 사용하면 안 되는 이유가 무엇인가요? 기존 DLP는 정적 파일과 이메일 첨부 파일을 위해 설계되었습니다.  데이터가 네트워크를 떠날 때 패턴을 분석하는 방식입니다 .

LLM 환경에서 순수 DLP 및 반응형 보안 조치는 다음 세 가지 이유로 실패합니다.

• 문맥 맹점:  프롬프트에 매우 민감한 전략적 맥락이 포함되어 있더라도 신용 카드 번호에 대한 표준 정규 표현식 규칙이 적용되지 않을 수 있습니다.
• 진화하는 위협 환경:  즉시 주입 공격은 전년 대비 340% 증가했으며, LLM 취약점을 악용할 수 있는 위협 그룹은 2022년 10개 미만에서 2025년 120개 이상으로 늘어났습니다. 바로 이러한 이유로  OWASP Top 10 for LLM Applications는  기업 AI 보안 제어를 구축하는 팀에게 필수적인 자료가 되었습니다.
• 마이크로소프트의 AI용 제로 트러스트(ZT4AI) 격차:  마이크로소프트의 AI용 제로 트러스트 원칙은 조직이 명시적 검증 ,  최소 권한 적용 ,  침해 가능성 가정을  요구합니다  . 반면, 사후 대응형 DLP는 보안 경계가 온전하다고 가정합니다. ZT4AI는 지속적인 평가와 세부적인 수준의 입력 데이터 보호를 요구합니다.

4. 승인 전 보안팀이 평가해야 할 사항

기업 전반에 걸쳐 AI 도구를 사용하기 전에 보안 및 IT 책임자는 평가 기준을 “어떤 모델이 가장 똑똑한가?”에서 “AI 도구로 유입되는 데이터를 어떻게 관리할 것인가?”로 바꿔야 합니다.

실질적인 틀을 마련하려면 다음 네 가지 핵심 요소를 살펴보아야 합니다.

1. 입력 데이터 보호:  데이터가 당사 환경을 벗어나기 전에 민감한 정보를 마스킹하거나 토큰화할 수 있습니까?
2. 감사 추적:  규정 준수 감사를 충족하기 위해 누가 무엇을 조회했고 어떤 데이터가 노출되었는지 정확하게 기록할 수 있습니까?
3. 정책 시행:  부서별로 다른 규칙을 적용할 수 있을까요? (예: 인사부와 재무부에 더 엄격한 개인정보 보호 정책 적용)
4. 워크플로 적합성:  보안 조치로 인해 직원들이 불편한 별도의 포털을 사용해야 합니까, 아니면 Slack이나 IDE와 같이 이미 사용하고 있는 환경에 기본적으로 통합됩니까?

5. 기업 AI에 대한 세 가지 접근 방식 비교

조직은 AI 도입이라는 과제에 직면했을 때 일반적으로 세 가지 경로 중 하나를 선택합니다. 실제 상황에서 각 경로의 차이점은 다음과 같습니다.

6. 기업 환경에 적합한 AI 운영 모델의 모습

AI를 안전하게 활용하기 위해 기업은 보호 → 사용 → 복원 → 감사라는 라이프사이클을 기반으로 하는 운영 모델이 필요합니다   .

• 보호:  직원이 프롬프트를 제출하면 시스템은 민감한 데이터(이름, 재무 정보, 기밀 용어)를 즉시 식별하고 로컬에서 토큰화합니다.
• 사용 예:  정제된 프롬프트가 외부 LLM으로 전송됩니다. AI는 민감한 토큰을 전혀 보지 않고 주변 컨텍스트를 사용하여 요청을 처리합니다.
• 복원:  LLM은 출력을 기업 환경으로 반환하며, 직원이 데이터를 읽기 전에 토큰이 원래의 민감한 데이터로 원활하게 대체됩니다.
• 감사:  모든 상호 작용은 중앙 집중식으로 기록되므로 개인 식별 정보나 민감한 데이터가 외부로 전송되지 않았음을 감사 담당자에게 입증할 수 있습니다.

7. LLM 캡슐의 활용 분야

바로 이 지점에서  CUBIG의 LLM Capsule이  중요한 역할을 합니다.
LLM Capsule은 Shadow AI의 운영상 격차를 해소하기 위해 설계되었습니다. 팀들은 공개된 AI 도구를 사용하고 싶어 하지만, 조직은 민감한 데이터의 무분별한 노출을 감당할 수 없습니다. LLM Capsule은 또 다른 모델이 아닙니다.
직원과 그들이 사용하는 AI 도구 사이에 존재하는 제어 계층입니다.

실제로 LLM Capsule은 조직이 AI 사용을 승인하기 전에 가장 중요한 네 가지 질문, 즉 입력되는 데이터의 종류, 해당 데이터가 외부로 전송되는지 여부, 사용 기록의 방식, 그리고 역할이나 부서별로 다양한 정책을 어떻게 시행하는지에 대한 해답을 제시합니다. 플러그인 기반 환경에서 시작하여 웹으로 확장되는 LLM Capsule은 기존 워크플로에 직접 통합되어 모델에 도달하기 전에 입력값을 보호하고, 사용성을 유지하며, 조직 내부에서 감사 가능성을 보장합니다.

즉, 팀은 ChatGPT나 Claude와 같은 강력한 공용 AI 도구를 계속 사용할 수 있으며, 보안 담당자는 전면적인 사용 금지와 비현실적인 비공개 모델 프로젝트 사이에서 선택을 강요받을 필요가 없습니다. LLM Capsule은 사용을 차단하는 대신 AI 도입을 관리할 수 있도록 지원합니다. 민감한 입력값은 전송 전에 감지, 마스킹 또는 토큰화할 수 있으며, 기업 내부에서는 복원되고 명확한 정책 모델에 따라 기록됩니다.

제품 출시 현황

• 웹 버전, 플러그인 출시 예정일:  2026년 5월

자주 묻는 질문

LLM Capsule은 ChatGPT, Claude 또는 다른 LLM을 대체하는 모델인가요?
아닙니다. LLM Capsule은 대체 모델이 아닙니다. 외부 또는 연결된 LLM에 도달하기 전에 민감한 입력값을 보호하는 제어 계층 역할을 합니다.

이 기술이 가장 먼저 해결하는 문제는 무엇일까요?
바로 기업이 직면한 가장 시급한 AI 문제를 해결합니다. 즉, 민감한 입력값, 외부 데이터 전송, 감사 기록 ​​및 부서별 정책 시행에 대한 통제권을 잃지 않고 팀이 AI를 활용할 수 있도록 지원하는 것입니다.

AI 도구를 완전히 차단하면 안 되는 이유가 뭘까요?
차단만으로는 AI 사용을 완전히 막을 수 없기 때문입니다. 차단은 대개 AI 활동을 눈에 띄지 않는 우회 경로로 몰아넣어 관리 체계를 약화시키고, 섀도우 AI를 탐지하기 어렵게 만듭니다.