TIL: 당신의 AI 기능에 DLP 필터 그 이상이 필요한 이유

AI DLP와 AI 프라이버시 방화벽(privacy firewalls)의 빠른 분석, 그리고 잘못된 선택이 나중에 어떤 대가를 치르게 하는지에 대하여

지난주 우리 팀의 주니어 개발자가 PR(Pull Request)을 올렸는데, 세 개의 파일 깊숙한 곳에 사용자의 이메일과 자유 형식의 "메모(notes)" 필드를 포함한 전체 원시 요청 본문(raw request body)을 LLM API로 직접 전송하는 코드가 숨겨져 있었습니다. 필터링도, 마스킹(masking)도, 아무것도 없었습니다. 리뷰를 통과했고, 거의 머지(merge)될 뻔했습니다.

이것은 누군가를 비난하려는 글이 아닙니다. 기본적으로 6개월 전 다른 프로젝트를 하던 제 모습입니다. 알고 보니 이것은 LLM을 기반으로 구축하는 거의 모든 팀이 출시 직전이나 직후에 아주 고통스럽게 배우게 되는 일 중 하나였습니다. 그래서 제가 이 문제에 빠지기 전에 누군가 설명해 주었으면 좋았을 내용을 TIL(Today I Learned) 버전으로 정리해 보았습니다.

누구나 처음에 저지르는 실수

LLM 호출을 연결합니다. 깨끗한 샘플 데이터로 테스트합니다. 잘 작동합니다. 배포합니다. 그러고 나면 실제 사용자들이 그 자유 형식 필드에 실제 내용들을 입력하기 시작합니다 — 이름, 전화번호, 때로는 배송 문제로 불만을 토로하느라 집 주소 전체를 입력하기도 합니다 — 그리고 갑자기 그 모든 세부 정보가 제3자 API의 요청 로그(request logs)에 남게 됩니다.

누구도 의도적으로 잘못을 저지른 것이 아닙니다. 이 간극은 누군가 찾아내기 전까지는 그저 보이지 않을 뿐입니다.

사람들이 선택하는 두 가지 해결책 (그리고 왜 하나만 확장 가능한가)

문제를 인지하고 나면 두 가지 방향으로 갈 수 있는데, 사람들은 이 둘이 같은 것처럼 말하지만 결코 같은 것이 아닙니다.

옵션 1: 차단하기. 이것은 기본적으로 LLM 트래픽에 적용된 AI DLP (데이터 손실 방지, data loss prevention)입니다. 나가는 프롬프트(prompt)를 스캔하여 이메일, 전화번호, 카드 번호 등의 패턴과 일치하는지 확인하고, 일치하는 항목이 있으면 외부로 나가기 전에 거부하거나 플래그(flag)를 지정합니다. 이는 보안 팀이 이미 실행하고 있을 도구들의 자연스러운 확장입니다.

옵션 2: 변환(Transform)하기. 이것은 사람들이 'AI 프라이버시 방화벽 (AI privacy firewall)'이라고 부르기 시작한 방식입니다. "이것이 통과되어도 되는가?"라고 묻는 대신, "이것을 어떻게 안전하게 보낼 수 있는가?"를 묻습니다. 프롬프트가 인프라를 떠나기 전에 민감한 엔티티(entity)들이 플레이스홀더 토큰(placeholder tokens)으로 교체되며, 모델은 해당 플레이스홀더를 사용하여 응답합니다. 그리고 응답이 돌아오면 앱이 실제 값을 다시 원래대로 교체합니다.

제가 이해하는 데 너무 오래 걸렸던 부분은 바로 이것입니다: 옵션 1은 작동할 때 기능을 망가뜨립니다. 만약 DLP 계층이 전화번호가 포함되어 있다는 이유로 프롬프트를 차단한다면, 귀하의 앱은 실제로 무엇을 하게 될까요? 에러를 보여줄까요? 요청을 조용히 드롭(drop)할까요? 이에 대한 좋은 UX(사용자 경험) 답변은 없습니다. 왜냐하면 그 경우 기능 자체가 작동하지 않기 때문입니다.

옵션 2는 그러한 실패 모드(failure mode)가 없습니다. 데이터가 거부되는 대신 위장되기 때문에, 민감한 정보 여부와 상관없이 기능이 매번 동일하게 작동합니다.

이를 정말 잘 설명해 주는 자료

단순히 마케팅 문구를 반복하는 대신, 이 비교를 제대로 정리해 놓은 자료를 찾아보았고, 배포 모델, 비용, 컴플라이언스(compliance) 관점 등 모든 것을 다룬 확실한 자료를 발견했습니다:

AI DLP vs. AI Privacy Firewall: which one should you actually choose

만약 귀하가 팀을 위해 이 결정을 직접 내려야 하는 사람이라면, 방향을 정하기 전에 읽어볼 가치가 있습니다.

우리가 실제로 만든 것

우리는 결국 변환(transform) 방식을 선택했습니다. 즉, 백엔드와 모델 API 사이에 위치하는 작은 프록시(proxy) 계층을 두는 것입니다. 모든 외부로 나가는 프롬프트는 먼저 엔티티 탐지(entity detection)(이름, 이메일, 전화번호, 주문 ID 등)를 거치며, 민감한 부분들이 안정적인 플레이스홀더로 교체된 후 모델로 전송됩니다. 응답은 플레이스홀더가 포함된 상태로 돌아오며, 우리의 프록시는 프론트엔드에 도달하기 전에 실제 값을 다시 원래대로 교체합니다.

이는 정규 표현식 (regex)을 사용하는 것보다 초기 작업량이 더 많습니다. 하지만 또한 사용자가 그날 무엇을 입력했느냐에 따라 기능이 무작위로 고장 나지 않는 유일한 방식이기도 합니다.

**Questa AI**는 처음부터 직접 구축하는 대신, 무엇이 "프로덕션 준비 완료 (production-ready)" 상태인지에 대한 참고 지점이 필요하다면 바로 이러한 종류의 실시간 익명화 및 재수화 (anonymize-and-rehydrate) 레이어를 구축하고 있는 벤더 중 하나입니다.

정규 표현식 단계는 당신을 힘들게 할 것입니다

프록시를 구축하기 전, 우리는 고전적인 방식인 이메일용 정규 표현식, 전화번호용 정규 표현식, 카드 번호용 정규 표현식을 시도했습니다. 테스트 스위트에서는 괜찮아 보였습니다. 하지만 프로덕션 환경에서는 국제 전화 형식, 오타가 있는 이메일, 그리고 기본적으로 미국식 패턴이 아닌 모든 것을 놓쳤습니다. 또한 가끔씩 우리 지원 에이전트의 이름을 "민감 정보"로 잘못 식별하여 교체해야 할 상황이 아님에도 교체해 버리기도 했습니다.

이러한 문제들이 아이디어를 포기해야 할 이유는 아닙니다. 오히려 다른 탐지 시스템을 튜닝하는 것과 마찬가지로, 배포 후에 실제 튜닝 기간이 필요할 것이라고 예상해야 하는 이유입니다. 우리는 현재 다른 버그 버킷(bug bucket)과 마찬가지로, 놓친 사례나 오탐 (false-positive) 사례를 매달 검토하고 있습니다.

이것이 단순한 엔지니어링 측면의 '있으면 좋은 기능'이 아닌 이유

만약 당신의 제품이 EU 사용자와 접촉한다면, EU AI 법 (EU AI Act)의 투명성 규칙은 이미 시행 중이며, GDPR의 데이터 최소화 (data minimization) 원칙은 아주 오래전부터 존재해 왔습니다. 문제가 발생한 후에 문제를 포착하는 대신, 설계 단계부터 노출을 어떻게 최소화하고 있는지 누군가 묻는다면 "정규 표현식을 사용하고 있습니다"라는 답변은 매우 취약한 답변이 될 것입니다. 출시 전에 익명화 레이어를 구축하는 것은, 고객이 이미 의존하고 있는 기능에 나중에 이를 끼워 맞추는 것보다 훨씬 적은 차이 (diff)를 발생시킵니다.

더 자세한 내용을 원하신다면

저는 이 동일한 근본적인 문제에 대해 다양한 독자층을 대상으로 몇 가지 다른 관점의 글을 작성했습니다. 이 주제가 당신이 구축하고 있는 것과 관련이 있다면 살펴볼 가치가 있습니다:

Why "Just Block It" Doesn't Work for AI Data Leaks

대부분의 기업이 인지하지 못하는 AI 프라이버시 함정

우리는 고객의 개인정보(PII)를 유출할 뻔한 AI 기능을 출시할 뻔했습니다

요약 (TL;DR)

• DLP는 민감한 프롬프트(Prompt)를 차단합니다. 프라이버시 방화벽(Privacy firewalls)은 이를 변형하여 기능이 계속 작동할 수 있도록 합니다.
• 차단 방식은 나쁜 사용자 경험(UX) 문제를 야기합니다: 요청이 거부되면 어떻게 될까요?
• 변형(Transforming) 방식은 그에 상응하는 실패 모드(Failure mode)가 없습니다 — 즉, 항상 작동합니다.
• 출시 전에 이를 구축하세요. 나중에 사후 적용(Retrofitting)하는 것은 훨씬 더 큰 작업이 됩니다.

다른 팀들은 이 문제를 어떻게 다루고 있는지 진심으로 듣고 싶습니다 — 여러분의 접근 방식을 댓글로 남겨주세요.