모델 출력 단계에서 보안이 완료되었다고 생각했던 AI 기반 지원 시스템이, CRM 기록을 프롬프트에 입력하는 "사이드 도어(side door)"를 통해 고객 데이터를 유출하고 있었습니다. 제작자의 사후 분석(post-mortem)에 따르면, 모델이 생성하는 텍스트만 보호하는 것으로는 충분하지 않습니다. 인바운드 요청, 내부 도구에서 가져온 데이터, 그리고 최종 출력물 모두에 독립적인 보호 조치가 필요합니다. 그렇지 않으면 모델 출력 단계의 침해 사례가 발생하지 않더라도 이름, 이메일, ID 등이 노출될 수 있습니다.
세 가지 경계가 중요한 이유
대부분의 운영자는 언어 모델이 학습하거나 본 비밀 정보를 반복할 때 유출이 발생한다고 가정합니다. 하지만 실제로는 모델이 데이터를 확인하기도 전에 가장 큰 노출이 발생합니다. AI 에이전트는 세 가지 정보 스트림을 수신합니다:
- Ingress(유입) – 고객이 입력하는 가공되지 않은 쿼리.
- Return path(반환 경로) – 에이전트가 CRM과 같은 다운스트림 시스템에서 가져오는 정보.
- Emission(출력) – 모델이 사용자에게 반환하는 텍스트.
이 스트림 중 하나라도 보호되지 않은 식별자를 포함하고 있다면, 출력 레이어에 필터가 적용되어 있더라도 에이전트가 답변에 이를 의도치 않게 포함할 수 있습니다.
데모에서 프로덕션으로: 값진 교훈
프로토타입을 실제 헬프 데스크에 적용하는 과정에서, 단순한 "가리기 후 전송(redact-then-send)" 방식이 놓쳤던 구체적인 실패 사례들이 드러났습니다.
가리기 대신 토큰화(Tokenize) 사용 – 모델에 도달하기 전에 이름이나 이메일을 삭제하면 시스템이 정확한 답변을 재구성하는 것을 방해합니다. 원본 값을 보안 금고(vault)에 저장하고, 프롬프트에서는 이를 무작위 UUID로 대체한 뒤, 모델 작업이 끝나면 다시 UUID를 원래 값으로 교체하십시오. 이렇게 하면 기능을 유지하면서도 모델의 컨텍스트에서 원본 데이터를 제외할 수 있습니다.
체크섬(Checksum)으로 식별자 검증 – 정규 표현식은 계정 번호처럼 보이는 문자열을 찾아내지만, 체크섬은 그것이 실제 유효한 ID인지 확인합니다. 체크섬 필터를 사용하면 에이전트가 임의의 숫자를 민감한 데이터로 취급하는 것을 방지하여, 불필요한 가리기가 발생하는 오탐(false positive)을 줄일 수 있습니다.
중첩된 구간 병합 – 고객 기록에는 이름 뒤에 이메일 주소가 붙어 있어 문자가 겹치는 경우가 많습니다(예: “John Doe john.doe@example.com”). 이름만 토큰화하면 이메일 파편이 평문으로 남아 출력될 수 있습니다. 중첩된 전체 영역을 하나의 토큰으로 처리하십시오.
올바른 경계 테스트 – 출력(emission) 레이어만 확인하여 통과하는 테스트는 잘못된 보안 신뢰를 줍니다. 반환 경로(return path)에서의 유출을 잡아내는 실패하는 테스트가 실제 수정을 이끌어냅니다. 세 가지 경계 각각을 명시적으로 검증하는 테스트 스위트를 설계하십시오.
그라운드 트루스(Ground Truth) 추적 – 사람이 AI가 생성한 초안을 전송하기 전에 수정한다면, 모델은 이미 잘못된 응답을 생성한 것입니다. AI의 초안과 최종적으로 사람이 승인한 메시지를 비교하면 신뢰도 격차를 파악할 수 있으며, 시스템이 실수를 반복하도록 학습하는 것을 방지할 수 있습니다.
기업이 직면한 리스크
고객 서비스 AI 에이전트는 대중과의 상호작용과 내부 데이터 저장소가 만나는 접점에 위치합니다.
반론: 왜 여전히 일부는 가리기(redaction) 방식을 선호하는가
요약
AI 기반 고객 서비스 에이전트를 보호하는 것은 단일 문(single-door)의 문제가 아닙니다. 인바운드 요청, 내부 시스템에서 가져온 데이터, 그리고 아웃바운드 텍스트를 각각 별개의 벽으로 취급하십시오. 그중 하나라도 뚫리면 서비스 전체가 위험해집니다. 민감한 필드를 토큰화하고, 식별자를 검증하며, 중첩된 구간을 병합하고, 올바른 경계를 테스트하며, AI 초안을 최종 메시지와 지속적으로 비교하는 것이 "코파일럿(copilot)"을 신뢰할 수 있는 에이전트형 서비스로 바꾸는 실질적인 단계입니다.