도입 문의
AI 보안

섀도 AI 정보 유출, 왜 브라우저에서 통제해야 하는가

·

금지에서 조건부 허용으로

2023년 4월, 삼성전자 반도체 부문 엔지니어들이 소스코드와 회의 내용을 ChatGPT에 입력한 사실이 사내에서 확인됐습니다. 회사는 5월 초 사내 기기와 내부망에서 생성형 AI 사용을 제한했고, 당시 여러 글로벌 금융회사와 기업이 비슷한 조치를 취했습니다.

금지는 오래가지 못했습니다. 금융위원회와 금융감독원은 2024년 8월 13일 「금융분야 망분리 개선 로드맵」을 발표해 금융회사의 생성형 AI·SaaS 활용 길을 열었습니다. 같은 해 11월 27일에는 생성형 AI를 활용한 9개 금융회사의 10개 혁신금융서비스를 처음 지정했고, 신청 기간에만 74개사가 141건을 접수했습니다. 지정은 보안대책 준수를 부가 조건으로 합니다.

질문이 바뀌었습니다. “생성형 AI를 막을 것인가”가 아니라 “어떤 데이터가, 어떤 계정으로, 어디로 가는지 통제하면서 허용할 것인가” 입니다.

숫자로 보는 섀도 AI

섀도 AI(Shadow AI)는 조직의 승인이나 보안 검토 없이 임직원이 업무에 사용하는 AI 도구를 말합니다.

지표수치출처
섀도 AI가 연루된 보안 사고 비중20%(2025) → 43%(2026)IBM Cost of a Data Breach 2026
섀도 AI 연루 침해의 평균 비용539만 달러 (전년 463만 달러)IBM Cost of a Data Breach 2026
AI 거버넌스 정책이 없는 침해 조직 비중68%IBM Cost of a Data Breach 2026
생성형 AI 붙여넣기 중 비관리(개인) 계정 비중82%LayerX Enterprise AI & SaaS Data Security Report 2025

IBM 보고서는 Ponemon Institute가 2025년 3월부터 2026년 2월 사이 침해를 겪은 16개국 17개 산업, 602개 조직을 조사한 결과입니다. LayerX 수치는 해당 기업의 고객사 브라우저 텔레메트리 기준이므로 표본 특성을 감안해 해석해야 합니다.

두 자료가 가리키는 방향은 같습니다. 데이터는 파일이 아니라 텍스트 조각의 형태로, 브라우저 입력창을 통해 나가고 있습니다.

기존 통제 계층이 놓치는 세 지점

1. 복호화 예외 트래픽

네트워크 DLP와 SWG(Secure Web Gateway)가 전송 내용을 검사하려면 TLS 복호화가 전제되어야 합니다. 개인 금융·의료 사이트나 인증서 고정(certificate pinning)을 쓰는 앱처럼 운영상 복호화 예외로 두는 트래픽은 내용 검사 대상에서 빠집니다. 예외 목록이 늘어날수록 사각지대도 함께 넓어집니다.

2. QUIC(HTTP/3) 트래픽

HTTP/3는 QUIC 위에서 동작하고, QUIC는 TCP가 아닌 UDP를 사용합니다(RFC 9000, RFC 9114). TCP 기반 프록시만 운용하는 환경에서는 UDP 443 트래픽이 검사 경로를 벗어날 수 있습니다. Chromium 이슈 트래커에는 2015년 이 문제를 이유로 정책 추가를 요청한 기록이 있으며, 이후 QuicAllowed 정책이 도입됐습니다.

프록시가 QUIC 검사를 지원하지 않는다면 관리 대상 브라우저에서 QUIC를 끄는 것이 가장 단순한 조치입니다. Windows 그룹 정책을 쓰지 않는 환경이라면 다음 레지스트리 값으로 동일하게 적용됩니다.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"QuicAllowed"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"QuicAllowed"=dword:00000000

적용 여부는 chrome://policy 또는 edge://policy에서 확인할 수 있습니다. 경계 방화벽에서 UDP 443을 함께 통제하면 브라우저는 TCP 기반 HTTP/2 또는 HTTP/1.1로 폴백합니다. 다만 일부 서비스의 체감 속도가 떨어질 수 있으므로 변경 관리 절차를 거쳐 적용하십시오.

3. 같은 도메인, 다른 계정

많은 SaaS와 생성형 AI 서비스는 개인 계정과 기업 계정이 같은 도메인을 사용합니다. 목적지 도메인 기준 정책만으로는 “승인된 기업 테넌트에 입력하는 것”과 “개인 계정에 입력하는 것”을 구분하기 어렵습니다. 앞의 표에서 붙여넣기의 82%가 비관리 계정에서 발생했다는 수치가 이 사각지대의 크기를 보여줍니다.

통제 계층별 가시성 비교

통제 계층확보 가능한 가시성사각지대가 생기기 쉬운 영역
네트워크 (SWG·CASB·네트워크 DLP)목적지 도메인, 복호화된 HTTP 요청복호화 예외 트래픽, 미처리 QUIC 트래픽, 동일 도메인 내 계정 구분
엔드포인트 DLP파일 이동, OS 클립보드, 저장 매체어느 웹 앱의 어느 계정 입력창인지에 대한 맥락
브라우저 계층입력·붙여넣기·업로드 이벤트의 평문, 탭의 URL과 로그인 계정 맥락비관리 브라우저, 데스크톱 전용 앱, API·CLI 호출

어느 한 계층도 단독으로 완결되지 않습니다. 브라우저 계층의 강점은 암호화되기 전의 평문을, 어느 서비스의 어느 계정에 입력되는지와 함께 볼 수 있다는 데 있습니다.

브라우저 계층 통제의 설계 원칙

1. 전송 전 이벤트 단위로 판정

붙여넣기, 키보드 입력, 파일 업로드, 드래그 앤 드롭은 서로 다른 이벤트입니다. 요청이 서버로 전송되기 전에 이벤트 단위로 판정해야 “이미 나간 뒤에 탐지”하는 사후 대응을 피할 수 있습니다.

2. 계정·테넌트 맥락 결합

같은 문장이라도 승인된 기업 테넌트에 입력되면 허용하고, 개인 계정에 입력되면 경고하거나 차단하는 식으로 판정해야 합니다. 정책의 기본 단위는 “도메인”이 아니라 “서비스 + 계정 + 데이터 유형”의 조합입니다.

3. 차단 일변도가 아닌 단계형 응답

응답적용 예기대 효과
허용 + 기록승인된 기업 테넌트, 민감정보 미탐지업무 흐름 유지, 사용 현황 가시화
경고 + 사유 입력미승인 서비스 또는 내부 문서로 추정되는 텍스트사용자 스스로 판단하도록 유도, 우회 동기 감소
마스킹주민등록번호·계좌번호 등 식별 패턴 탐지업무 목적은 유지하면서 식별정보만 제거
차단소스코드·고객 데이터 대량 붙여넣기, 개인 계정으로의 파일 업로드고위험 유출 경로 봉쇄

모든 것을 차단하면 사용자는 개인 기기로 옮겨 가고, 조직은 가시성을 잃습니다.

4. 원문이 아닌 메타데이터 로깅

프롬프트 원문을 그대로 저장하면 로그 서버가 새로운 민감정보 저장소가 됩니다. 탐지 유형, 조치 결과, 대상 서비스, 사용자, 시각을 기본으로 기록하고, 원문 보관은 예외적으로 기간과 접근 권한을 통제하는 편이 안전합니다.

5. 우회 경로를 함께 봉쇄

브라우저 계층 통제는 관리 대상 브라우저 안에서만 유효합니다. 생성형 AI 도메인은 관리 대상 브라우저에서만 접근하도록 네트워크 정책을 함께 적용하고, 데스크톱 전용 앱과 API 호출 경로는 엔드포인트·네트워크 정책으로 보완해야 합니다.

도입 순서 - 가시화, 코칭, 집행

처음부터 차단 정책을 켜면 오탐과 업무 민원이 한꺼번에 몰립니다. 아래 순서는 운영 부담을 나눠 정착시키기 위한 권장 흐름입니다.

단계운영 모드목표산출물
1. 가시화모니터링 전용어떤 AI 서비스를, 어떤 계정으로, 어떤 데이터 유형과 함께 쓰는지 파악서비스·계정·데이터 유형별 사용 현황
2. 코칭경고 + 사유 입력승인 서비스로 유도하고 정책을 사용자에게 인지시킴승인 서비스 목록, 예외 요청 흐름
3. 집행마스킹·차단고위험 데이터 유형과 개인 계정 경로를 우선 통제데이터 유형별 집행 정책
4. 운영정기 튜닝오탐 조정, 신규 AI 서비스 반영분기별 정책 리뷰 기록

1단계 결과가 있어야 2단계 이후의 정책을 근거 있게 설계할 수 있습니다. 사용 현황 없이 만든 차단 정책은 대부분 과잉이거나 누락입니다.

마치며

생성형 AI는 금지 대상에서 관리 대상으로 바뀌었습니다. 관리의 핵심은 데이터가 암호화되어 네트워크로 나가기 전, 사용자가 붙여넣기 버튼을 누르는 그 순간에 있습니다. 그 순간을 가장 가까이에서 볼 수 있는 곳이 브라우저입니다.

젠스랩은 브라우저를 정책 집행 지점(PEP, Policy Enforcement Point)으로 삼는 클라이언트 기반 보안 브라우저 BrowZen을 제공합니다. 보안 브라우저의 기본 개념과 VDI·RBI 등 다른 방식과의 차이는 보안 브라우저(SEB)란 무엇인가에서 확인하실 수 있습니다.

참고 자료

자주 묻는 질문

생성형 AI 사이트를 도메인 단위로 차단하면 충분하지 않나요?

신규 AI 서비스가 계속 늘고 기존 업무 SaaS에 AI 기능이 내장되면서 도메인 목록만으로는 누락이 생깁니다. 전면 차단은 개인 기기와 개인 계정 사용으로 우회를 유도해 오히려 가시성을 잃게 만듭니다. 승인된 서비스는 허용하고 민감 데이터 입력만 통제하는 방식이 현실적입니다.

브라우저 확장 프로그램으로도 같은 통제가 가능한가요?

확장 프로그램도 페이지 이벤트를 관찰할 수 있어 기존 브라우저에 빠르게 배포할 수 있다는 장점이 있습니다. 다만 브라우저 정책으로 강제 설치와 비활성화 방지를 함께 설정해야 하고, 사용자가 확장이 없는 다른 브라우저를 쓰면 통제 밖으로 벗어납니다. 어떤 방식이든 비관리 브라우저 경로를 네트워크 정책으로 함께 막아야 실효성이 확보됩니다.

프롬프트 원문을 모두 로그로 남겨야 하나요?

권장하지 않습니다. 프롬프트 원문 로그는 그 자체가 민감정보 저장소가 되어 새로운 유출 표적이 됩니다. 탐지 유형, 조치 결과, 대상 서비스, 사용자, 시각 등 메타데이터 중심으로 기록하고, 원문 보관이 꼭 필요하면 보관 기간과 접근 권한을 별도로 통제하는 방식이 개인정보 최소 수집 원칙의 취지에 맞습니다.

함께 읽어보기