LLM 입력에 개인정보가 섞일 때: 전송 전 차단과 로그 점검

LLM에 고객 문의나 사내 문서를 넣기 전, 이메일 주소와 전화번호가 섞여 있는지 확인하고 전송 여부를 결정해야 합니다. 프롬프트에 들어간 개인정보를 답변 단계에서 가려도 이미 외부 요청에 실린 뒤입니다. 입력 검사, 필요한 항목만 추리는 작업, 요청 본문과 로그 확인을 모델 호출보다 앞에 두는 편이 안전합니다.

입력 상자와 실제 요청 본문은 다르다

상담 기록을 요약한다면 담당자에게 필요한 것은 문의 내용과 처리 상태일 수 있습니다. 원본 화면에는 연락처, 서명, 주문번호가 함께 보이더라도 요약 요청에는 그 필드가 필요하지 않을 수 있습니다. 우선 화면의 전체 텍스트를 프롬프트에 복사하는 경로부터 끊습니다. 서버에서 허용 필드만 골라 새 요청 객체를 만드는 방식이 원본 객체에서 몇 필드만 지우는 방식보다 점검하기 쉽습니다.

요청을 보내는 함수 직전에 검사하면 웹 화면뿐 아니라 배치, 관리자 화면, 재시도 작업에도 같은 규칙을 적용할 수 있습니다. 다만 검사 위치가 마지막이라고 해서 앞 단계에서 원문을 로그에 남겨도 되는 것은 아닙니다. 입력을 수집하는 단계부터 로그 정책을 분리해야 합니다.

짧은 차단 검사부터 실제로 돌려 보기

아래 예시는 Node.js 표준 라이브러리만 쓰는 로컬 검사입니다. stdin으로 받은 문자열에서 이메일과 국내 휴대전화처럼 보이는 패턴을 찾으면 종료 코드 2를 반환합니다. 통과해도 모델에 전송하지 않고 OK_TO_REVIEW만 출력합니다. 4,000자 제한은 이 예시의 입력 크기 정책이지 모델 제공자의 공통 제한이 아닙니다.

import { readFileSync } from 'node:fs';
const raw = readFileSync(0, 'utf8');
const email = /[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/i;
const mobile = /(^|[^\d])01[016789][ -]?\d{3,4}[ -]?\d{4}(?!\d)/;
let reason = '';
if (!raw.trim() || raw.length > 4000) reason = 'SIZE';
else if (email.test(raw)) reason = 'EMAIL';
else if (mobile.test(raw)) reason = 'MOBILE';
if (reason) {
  console.error(`BLOCKED:${reason}`);
  process.exitCode = 2;
} else {
  console.log('OK_TO_REVIEW');
}

코드를 check-prompt.mjs로 저장한 뒤 node check-prompt.mjs < sample.txt를 실행합니다. 테스트 입력이 [email protected]이면 BLOCKED:EMAIL과 종료 코드 2, 일반 업무 문장만 있다면 OK_TO_REVIEW와 종료 코드 0을 기대합니다. 차단 이유만 남기고 원문이나 탐지된 값을 출력하지 않는 점이 중요합니다.

통과가 안전 판정은 아니다

정규식은 이름, 주소, 문맥 속 계좌번호, 변형된 연락처를 모두 찾지 못합니다. 고객이 이메일을 띄어 쓰거나 이미지에 연락처를 넣는 경우도 이 코드의 검사 대상 밖입니다. 반대로 문의 본문에 예시 도메인이 등장해도 차단될 수 있습니다. 따라서 OK_TO_REVIEW는 다음 검토 단계로 넘어갈 수 있다는 뜻이지 개인정보가 없다는 보증이 아닙니다.

업무에서 다뤄야 할 식별자 종류를 정하고, 필드 기반 제거와 탐지기를 함께 쓰며, 모호한 건은 전송하지 않은 채 담당자가 확인하도록 합니다. 예를 들어 Microsoft Presidio의 Analyzer는 텍스트의 PII 개체를 여러 인식기로 탐지하고 사용자 정의 인식기를 추가할 수 있습니다.[1] 이 도구를 붙여도 한국어 이름이나 회사 고유 고객번호에 대한 시험 데이터와 누락 점검은 별도로 필요합니다.

• 차단 시에는 요청 ID, 검사 버전, 차단 유형만 기록하고 프롬프트 원문은 남기지 않습니다.
• 모델 호출이 실패해 재시도할 때도 원본 입력을 다시 붙이지 않고 같은 정제·검사 경로를 거칩니다.
• 품질 확인용 샘플은 실제 고객 데이터 대신 합성 입력으로 만들고, 오탐과 누락을 서로 다른 항목으로 확인합니다.

전송 전에 확인할 마지막 경계

HTTP 요청을 만드는 코드에서 허용 필드, 대상 서비스, 재시도 데이터, 디버그 로그를 함께 살펴봅니다. 외부 모델에 전달하지 말아야 하는 문서는 마스킹으로 억지로 통과시키기보다 처리 경로 자체를 분리해야 합니다. 개인정보 탐지 결과가 불확실하거나 필수 입력만으로 업무 목적을 달성하지 못한다면 자동 전송을 멈추고 입력 양식과 처리 정책을 다시 설계하는 것이 낫습니다.

업무 화면과 연계하는 개발 범위는 소프트모아 홈페이지에서 확인할 수 있습니다.

참고 문서

[1] Presidio Analyzer 공식 문서

소프트모아는 해당 시스템을 구축합니다. 문의하기