대부분의 회사는 이미 이 질문에 늦게 도착합니다. "우리 직원들이 ChatGPT·Claude·Gemini에 무엇을 붙여넣고 있는가?" 대답은 대개 "모른다"입니다. 마케터는 고객 리스트를, 개발자는 소스코드와 .env를, 인사팀은 주민번호가 든 엑셀을 붙여넣습니다. 악의는 없습니다. 그저 빠르게 일하려는 것뿐입니다.
문제는 결과가 악의와 무관하다는 데 있습니다. 한 번 외부 LLM 서비스에 들어간 데이터는 회사의 통제를 벗어납니다. 이 글은 "AI를 쓰지 마라"가 아니라, 넣으면 안 되는 데이터가 무엇인지 명확히 하고, 그것을 입력되기 전에 걸러내는 실무 접근을 정리합니다.
위험한 건 'AI를 쓰는 행위'가 아니라 '무엇이 나가는지 아무도 모르는 상태'다. 답은 도구 차단이나 직원 통제가 아니라, 민감 데이터가 채팅창을 떠나기 전에 탐지·마스킹하는 것이다.
왜 '넣기 전'이 유일한 통제 지점인가
전통적 DLP(데이터 유출 방지)는 파일이 이메일·USB·클라우드로 나가는 순간을 잡도록 설계됐습니다. 그런데 생성형 AI는 다릅니다. 직원은 파일을 첨부하지 않고, 본문을 복사해 채팅창에 붙여넣습니다. 네트워크에서 보면 그냥 HTTPS 트래픽 한 줄이라, 무엇이 오갔는지 알기 어렵습니다.
게다가 데이터가 서버에 도달한 뒤에는 손쓸 수 없습니다. 로그, 캐시, 모델 학습 파이프라인 어디로 갔는지 회사는 알 수 없습니다. 그래서 통제 지점은 단 하나, 브라우저에서 전송 버튼을 누르기 직전입니다.
데이터가 서버에 닿은 뒤의 통제는 사후약방문이다. 유일하게 의미 있는 순간은 '엔터를 누르기 전'이다.
넣으면 안 되는 데이터 6가지
추상적인 "민감정보"가 아니라, 실제 사고로 이어지는 여섯 가지 구체적 유형입니다.
1. 개인정보 — 주민등록번호·계좌·연락처
가장 위험합니다. 주민등록번호는 변경이 사실상 불가능한 식별자라, 한 번 유출되면 평생 위험이 따라다닙니다. "요약해 달라"며 붙여넣은 직원 명부, 고객 응대 로그, 계약서 스캔본에 주민번호·계좌번호·휴대폰번호가 그대로 실려 나갑니다. 개인정보보호법상 이는 명백한 제3자 제공·처리위탁 이슈로 번질 수 있습니다.
2. 고객정보 — 명단·구매내역·상담 기록
"이 고객 리스트로 세그먼트를 나눠 줘", "이 상담 이력을 분석해 줘" — 마케팅·CS에서 가장 흔한 패턴입니다. 고객의 이름·이메일·구매 이력은 그 자체로 개인정보이며, 회사가 수집 목적 외로 외부 AI에 넘기는 순간 동의 범위를 벗어난 처리가 됩니다.
3. 소스코드 — 사내 저장소 코드
개발자가 "이 버그 고쳐 줘"라며 붙여넣는 코드에는 비즈니스 로직, 내부 API 구조, 때로는 하드코딩된 자격증명이 함께 담깁니다. 코드는 곧 회사의 영업비밀이자 지식재산입니다. 2023년 대기업의 사내 코드가 외부 AI로 유출된 사례가 이미 널리 알려져 있습니다.
4. API 키·시크릿
sk-test-0000… 같은 명백한 더미가 아니라, 운영 중인 실제 토큰이 설정 파일·로그와 함께 붙여넣어집니다. AWS 액세스 키, DB 접속 문자열, OAuth 시크릿이 한 번 노출되면 즉시 악용 가능한 실탄입니다.
5. 내부문서·계약
미공개 재무자료, M&A 문건, 급여 테이블, 계약서 초안 — "핵심만 요약해 줘"라며 통째로 붙여넣습니다. 유출 시 법적·경쟁상 손해가 직접적이며, 대외비 표기 유무와 무관하게 회사 통제를 벗어납니다.
6. 인프라 정보
서버 IP·내부 네트워크 구성·방화벽 규칙·아키텍처 다이어그램은 그 자체로 공격 지도입니다. "이 설정 검토해 줘"라며 붙여넣은 인프라 정보는 공격자에게 정찰 단계를 통째로 넘겨주는 셈입니다.
여섯 가지 모두 악의 없는 생산성 행위에서 나온다. "요약해 줘", "고쳐 줘", "분석해 줘" 한 마디에 딸려 나간다. 그래서 교육만으로는 막히지 않고, 입력 지점에서의 자동 탐지가 필요하다.
한국형 개인정보가 특히 위험한 이유
해외 도구로 만든 탐지 규칙은 대체로 미국식 식별자(SSN, 신용카드번호)에 맞춰져 있습니다. 한국 기업의 실제 위험은 다릅니다.
- 주민등록번호 — 앞 6자리(생년월일)+뒤 7자리 구조에 검증 체크섬이 있어, 형식만 맞는 문자열과 진짜 번호를 구분할 수 있습니다. 단순 정규식은 오탐이 많아 검증 로직이 필요합니다.
- 사업자등록번호 — 10자리에 가중치 기반 검증 규칙이 있어, 계약서·세금계산서에서 자주 함께 노출됩니다.
- 계좌번호·카드번호 — 카드번호는 Luhn 검증으로, 계좌번호는 은행별 패턴으로 판별합니다.
핵심은 정규식만으로는 부족하고 검증 로직이 결합돼야 정확도가 올라간다는 점입니다. 형식이 비슷한 숫자를 전부 막으면 업무가 마비되고, 느슨하면 진짜 번호가 샙니다. 한국 데이터 특성에 맞춘 탐지가 오탐과 미탐을 동시에 줄이는 유일한 길입니다.
금지가 아니라 통제 — 마스킹이 답인 이유
가장 흔한 대응은 "회사 PC에서 ChatGPT 접속 차단"입니다. 그런데 이건 거의 항상 실패합니다. 직원은 개인 휴대폰으로, 집 PC로 우회합니다. 그러면 회사는 가시성마저 완전히 잃습니다. 통제하려다 오히려 사각지대를 키우는 셈입니다.
더 현실적인 접근은 허용하되, 위험한 것만 걸러내는 것입니다.
구체적으로는 세 단계입니다.
- 탐지 — 입력 텍스트에서 주민번호·계좌·API 키·고객정보 패턴을 전송 전에 식별.
- 마스킹 — 발견된 민감 부분만
●●●●로 치환해 문맥은 살리되 원문은 나가지 않게. 직원은 그대로 작업을 이어갑니다. - 안내 — 무엇이 왜 가려졌는지 그 자리에서 알려, 학습 효과를 만듭니다. 사후 처벌이 아니라 그 순간의 코칭입니다.
여기서 브랜드가 지키는 원칙 하나. 탐지된 원문은 서버로 보내지도, 저장하지도 않습니다. 통제는 사람이 아니라 데이터에만 겁니다. 직원을 감시하는 도구가 되는 순간 팀은 우회하고, 통제는 무너지기 때문입니다.
좋은 AI 보안은 직원이 "감시당한다"가 아니라 "실수를 막아줬다"고 느끼게 한다. 그래야 우회하지 않는다.
현실적인 도입 순서
한 번에 완벽을 노리면 아무것도 못 합니다. 순서가 중요합니다.
- 가시성 먼저 — 무엇을 막을지 정하기 전에, 우리 팀이 어떤 AI 도구를 얼마나 쓰는지부터 파악합니다.
- 고위험 6종에 집중 — 위의 여섯 유형, 그중에서도 개인정보·시크릿을 최우선 탐지 대상으로.
- 차단이 아니라 마스킹으로 시작 — 초기엔 경고+마스킹만. 강한 차단은 오탐 신뢰가 쌓인 뒤에.
- 원문 미저장 원칙 고정 — 어떤 로그에도 붙여넣은 원문·프롬프트가 남지 않도록.
- 증적은 메타데이터로 — "언제, 어떤 유형이, 몇 건 가려졌는가"만 남겨 ISMS-P·내부 감사에 대응.
브라우저에서 전송 전에 한국형 개인정보·시크릿·고객정보 패턴을 탐지하고, 위험한 부분만 마스킹합니다. 원문·프롬프트는 서버로 보내지 않고 저장하지도 않으며, 증적은 유형·건수 같은 메타데이터로만 남깁니다. — 보안·원문 미저장 원칙 보기, 개인정보 담당자용 솔루션
담당자용 체크리스트
- 우리 팀이 어떤 생성형 AI 도구를 쓰는지 파악했는가?
- 주민번호·계좌·사업자번호를 형식이 아니라 검증 로직으로 탐지하는가?
- 고객정보·소스코드가 채팅창에 붙여넣어지는 걸 입력 전에 잡을 수 있는가?
- API 키·시크릿 패턴이 전송 전에 걸러지는가?
- 차단이 아니라 마스킹+안내로 업무 흐름을 지키는가?
- 탐지 원문·프롬프트가 어디에도 저장되지 않는가?
- 감사 대응용 증적을 원문 없이 메타데이터로 남기는가?
세 개 이상 "아니오"라면, 지금 우리 회사의 데이터가 매일 채팅창으로 새고 있을 가능성이 높습니다.