임직원 GenAI 사용 통제, 브라우저 확장이냐 네트워크 게이트웨이냐
기업이 임직원의 생성형 AI 사용을 통제하는 두 가지 대표 아키텍처 — 브라우저 확장 방식과 네트워크/프록시 방식을 비교하고, 국내 기업 환경(단말 관리·규제)에서의 선택 기준을 정리한다.
임직원이 ChatGPT에 사내 문서를 붙여넣는 순간, 그 데이터가 어디로 가는지 회사는 알 수 없다. 이 “그림자 AI(Shadow AI)” 문제를 풀기 위해 기업용 GenAI 통제 솔루션들이 쏟아지고 있는데, 자세히 뜯어보면 아키텍처는 크게 두 갈래다. 브라우저 확장 방식과 네트워크/프록시 방식. 둘은 보는 지점도, 막을 수 있는 것도, 우회 난이도도 다르다.
이 글은 두 방식의 trade-off를 정리하고, 국내 기업 환경에서 어떤 기준으로 골라야 하는지를 다룬다.
결론 먼저
- 가시성과 UX가 우선이면 브라우저 확장. 사용자가 무엇을 입력하는지 화면 단에서 그대로 보고, 실시간으로 경고·마스킹·차단을 걸 수 있다. 대신 브라우저에 종속되고 우회 여지가 있다.
- 우회 차단과 커버리지가 우선이면 네트워크/프록시. 브라우저를 안 가려도 트래픽 단에서 막는다. 대신 TLS 인터셉션이 필요하고, 앱·API 트래픽의 내용까지 보긴 어렵다.
- 현실적인 답은 둘의 병행이다. 한쪽만으로는 사각지대가 남는다. 단, 조직의 단말 관리 성숙도와 규제 환경이 우선순위를 결정한다.
두 방식이 실제로 “보는” 지점
브라우저 확장 방식
사용자 단말의 브라우저에 확장(extension)을 설치하고, 웹페이지의 DOM 레벨에서 입력을 가로챈다. 사용자가 프롬프트 입력창에 텍스트를 치면, 전송되기 전에 확장이 그 내용을 검사한다.
장점
- 콘텐츠 가시성이 최고 수준이다. 암호화되기 전, 사람이 읽는 그대로의 텍스트를 본다. PII·기밀 키워드 탐지가 정확하다.
- 실시간 UX 개입이 가능하다. “이 문장에 개인정보가 포함되어 있습니다” 같은 경고를 입력창 옆에 바로 띄우거나, 특정 부분만 마스킹할 수 있다.
- 어떤 AI 서비스든 페이지 단위로 정책을 걸 수 있다.
단점
- 브라우저에 종속된다. 확장을 지원하지 않는 브라우저, 앱(데스크톱 클라이언트), 모바일에서는 무력하다.
- 우회 여지가 있다. 사용자가 확장을 끄거나, 미관리 브라우저를 쓰거나, 개인 기기를 쓰면 빠져나간다.
- 배포·관리 부담. 전 단말에 확장을 강제 설치·업데이트해야 하고, 설치·서명 검증 실패 같은 배포 이슈가 실무에서 자주 발생한다.
네트워크 / 프록시 방식
단말이 아니라 트래픽 경로에 통제 지점을 둔다. 포워드 프록시나 SWG(Secure Web Gateway)가 AI 서비스로 향하는 트래픽을 가로채 검사·차단한다.
장점
- 브라우저·앱·OS를 안 가린다. 트래픽이 그 경로를 지나기만 하면 데스크톱 앱이든 모바일이든 통제 대상이 된다.
- 우회가 상대적으로 어렵다. 개별 단말 설정이 아니라 네트워크 정책이라, 사용자가 끄기 힘들다.
- 중앙 집중 관리. 정책을 한 곳에서 관리한다.
단점
- 콘텐츠를 보려면 TLS 인터셉션이 필요하다. HTTPS 트래픽 내용을 검사하려면 중간에서 복호화해야 하는데, 이는 인증서 배포·프라이버시·성능 이슈를 동반한다. 인터셉션 없이는 “어느 AI 서비스에 접속했다”까지만 알고 “무엇을 입력했는지”는 못 본다.
- API 트래픽·비표준 프로토콜은 사각지대. 앱이 자체 프로토콜이나 인증서 피닝을 쓰면 검사가 막힌다.
- 세밀한 UX 개입이 어렵다. 차단은 하지만 “입력창 옆 실시간 경고” 같은 건 못 한다.
한눈에 비교
| 기준 | 브라우저 확장 | 네트워크/프록시 |
|---|---|---|
| 콘텐츠 가시성 | ◎ (평문 그대로) | △ (TLS 인터셉션 필요) |
| 커버리지 | △ (브라우저 한정) | ◎ (앱·OS 무관) |
| 우회 난이도 | 낮음 (끄기·미관리 기기) | 높음 (네트워크 정책) |
| 실시간 UX 개입 | ◎ | △ |
| 배포·운영 부담 | 확장 배포/업데이트 | 인증서/프록시 운영 |
| 모바일·데스크톱 앱 | ✗ | ○ (경로 통과 시) |
국내 기업 환경에서의 선택 기준
여기서부터가 국내 관점이다. 해외 일반론에는 잘 안 나오는 변수들이 국내에선 결정적이다.
- 단말 관리(MDM) 성숙도. 브라우저 확장을 전사 강제 배포하려면 MDM/EMM이 갖춰져 있어야 한다. 이 인프라가 있는 조직이면 확장 방식의 배포 부담이 크게 준다.
- 금융·공공의 망분리. 외부 AI 서비스 접근 자체가 물리적/논리적으로 차단된 환경이라면, 통제 대상이 “외부 SaaS”가 아니라 “내부 폐쇄망 LLM”이 된다. 이때는 네트워크 통제의 성격이 달라진다. (이 주제는 별도 글에서 자세히 다룬다.)
- 개인정보보호법·감사 대응. TLS 인터셉션은 임직원 통신 내용을 복호화하는 것이라, 국내에선 사전 고지·동의·감사 로그 정책을 함께 설계해야 한다. 기술만 도입하고 거버넌스를 빼면 나중에 문제가 된다.
- BYOD 여부. 개인 기기 허용 조직이라면 확장 강제가 어렵다. 네트워크 방식이나 별도 접근 통제가 필요하다.
실무 추천
MDM이 갖춰진 관리 단말 중심 조직이라면 브라우저 확장으로 시작해 콘텐츠 가시성과 UX를 확보하고, 네트워크 방식으로 우회 경로(미관리 브라우저·앱)를 덮는 이중 구성이 현실적이다.
망분리·규제 환경이라면 애초에 위협 모델이 다르므로, 외부 차단은 네트워크 레이어에서 이미 해결되어 있고 통제의 초점이 내부 LLM 사용으로 옮겨간다. 이 경우 확장/프록시 논쟁보다 내부 게이트웨이의 정책 설계가 본질이다.
어느 쪽이든 공통 원칙은 하나다. 한쪽 아키텍처만으로는 사각지대가 남는다. 완벽한 단일 해법을 찾기보다, 조직의 단말·네트워크·규제 조건에 맞춰 커버리지 공백을 어디에 둘지 의식적으로 결정하는 것이 실무의 핵심이다.
이 글은 특정 벤더 제품이 아니라 아키텍처 유형을 비교한다. 공개 가능한 일반론만 다루며, 특정 고객사 구축 사례나 내부 수치는 포함하지 않는다.