AI 네이티브 시대의 프라이버시 인식 인프라: 자산 분류 사례 연구

프라이버시 통제는 데이터의 정체와 사용 맥락을 정확히 이해해야 제대로 작동하며, 이를 위한 자산 분류가 모든 보존·접근·목적 제한·공유·익명화 정책의 기반이 된다. Meta는 LLM을 모든 운영 판단에 사용하는 대신, 풍부한 맥락과 인간 검토를 바탕으로 모호하거나 새로운 자산을 해석하게 하고, 검증된 패턴은 버전 관리되는 결정론적 규칙으로 전환하는 하이브리드 방식을 제안한다. 그 결과 일상적인 운영 집행은 빠르고 재현 가능하며 감사하기 쉬운 규칙이 담당하고, LLM은 점차 예외적인 경우에만 사용된다.

프라이버시 인프라에서 자산 분류가 중요한 이유

• 프라이버시 인식 인프라(PAI)는 다음 네 가지 운영 문제를 다룬다.
  • 어떤 데이터가 존재하고 어떻게 관리되는지 파악
  • 특정 정책과 관련된 데이터 흐름 탐색
  • 보존 기간, 접근 권한, 허용 목적, downstream 공유 제한 집행
  • 검증 가능한 증거를 통한 컴플라이언스 입증
• 자산 분류는 이 중 ‘데이터 이해’ 계층에 해당하며, 이후 모든 통제의 기반이 된다.
• 분류 대상은 테이블과 컬럼에 한정되지 않는다.
  • 중첩 페이로드의 필드
  • 로그 키와 이벤트 파라미터
  • API 필드
  • ML 피처와 임베딩
  • 중간 파이프라인에서 생성된 파생 데이터셋
• 같은 데이터가 파이프라인을 거치며 피처, 모델 학습 데이터, 결합된 파생 신호 등 여러 표현으로 바뀌므로, 분류는 데이터의 형태보다 의미와 계보(lineage)를 따라야 한다.

데이터 분류가 어려운 네 가지 이유

• 노이즈가 많고 신호가 약하다
  • 자산마다 수십 개의 맥락 필드를 제공하면 모델이 매번 중요한 정보를 다시 찾아야 한다.
  • 불필요한 필드가 토큰과 주의를 소모해 실제 결정 경계를 흐린다.
  • 예를 들어 age는 개인정보 맥락에서는 사람의 나이지만, 인프라 파이프라인에서는 캐시 TTL일 수 있다.
  • 코드 해석과 lineage 분석이 없으면 캐시 파이프라인 전체에 불필요한 제한이 적용되는 false positive가 발생한다.
• 관련 정보가 여러 시스템에 흩어져 있다
  • 코드, 데이터 계보, 소유자, 의미론적 주석, 문서, 실제 사용 패턴을 함께 확인해야 한다.
• 요구사항과 정책 해석이 계속 변한다
  • 제품 기능이 빠르게 바뀌면 정적 규칙이나 주기적 수동 검토만으로는 정책 공백이 생긴다.
• 분류 오류가 downstream 전체에 전파된다
  • false positive는 불필요한 제한을 유발한다.
  • false negative는 보호되지 않은 데이터가 남는 문제를 만든다.
  • 따라서 모호성을 다루는 추론 능력과 설명·재현 가능한 집행 방식이 모두 필요하다.

LLM과 결정론적 규칙의 역할 분담

• LLM은 다음 상황에 제한적으로 사용한다.
  • 기존 규칙으로 처리하기 어려운 모호한 자산
  • 초기 데이터가 부족한 cold start 상황
  • 이전에 보지 못한 새로운 패턴
• 검증된 패턴은 버전이 있는 결정론적 규칙으로 변환한다.
  • 낮은 지연 시간
  • 동일 입력에 대한 재현성
  • 실행 결과의 감사 가능성
  • 대규모 운영에 적합한 비용과 성능
• 일반적인 운영 판단은 LLM이 아니라 규칙이 담당한다.
• 인간은 다음 단계에 관여한다.
  • 기준 라벨(reference label) 판정
  • 보호 정책에 영향을 주는 규칙 승격 검토 및 승인
• 장기적으로는 LLM이 담당하는 운영 범위를 줄이고, 규칙이 처리하는 안정적인 영역을 넓히는 것이 목표다.

원칙 1: 프롬프트보다 맥락이 중요하다

• 분류 실패의 주요 원인은 지시문이 약해서가 아니라 모델에 제공된 증거가 부족하거나 정리되지 않았기 때문이다.
• 원시 필드를 그대로 전달하면 중요한 정보와 오해를 일으키는 정보가 섞인다.
• 대신 다음 요소를 포함한 evidence brief를 구성한다.
  • 판단을 지지하는 신호
  • 판단과 모순되는 신호
  • 각 정보의 출처(provenance)
  • 모델이 이미 알고 있는 정보와 중복되는 순환 필드의 마스킹
• 프롬프트를 계속 최적화하는 것보다, 코드·계보·소유권·문서 등 관련 증거를 선별하고 구조화하는 편이 정확도 향상에 더 효과적이다.
• 즉, 모델에 무엇을 어떻게 묻는지보다 먼저 무엇을 보여줄지를 설계해야 한다.

원칙 2: 평가와 최적화를 분리한다

• LLM의 결과는 추천이며, 그 자체가 정답 데이터가 되어서는 안 된다.
• 평가 체계는 분류기와 독립적으로 유지해야 한다.
  • 서로 다른 모델과 프롬프트 전략
  • 고정된 reference set
  • 사람이 검토한 라벨
  • 회귀(regression) 통과 기준
• 분류 결과를 다시 평가 기준으로 사용하면 실제 개선이 아니라 모델의 드리프트를 측정할 위험이 있다.
• 인간 검토 라벨은 모델 출력과 분리된 신뢰 가능한 기준점으로 사용해야 한다.

원칙 3: 안정적인 동작을 규칙으로 증류한다

• 반복적으로 검증된 분류 패턴은 사람이 검토한 뒤 결정론적 규칙으로 만든다.
• 규칙에는 버전, 적용 조건, 판단 근거를 남겨야 한다.
• 규칙 기반 집행은 LLM 추론보다 빠르고, 결과를 재생(replay)할 수 있으며, 감사와 디버깅이 쉽다.
• LLM은 새로운 패턴을 발견하는 학습 장치로 활용하고, 안정화된 지식은 규칙에 축적한다.

플랫폼 서비스로서의 분류 계약

분류기는 개별 모델 호출이 아니라 안정적인 플랫폼 서비스처럼 설계해야 한다.

• 입력
  • 자산 식별자
  • 정리된 맥락 정보 묶음
• 출력
  • 분류기 taxonomy상의 카테고리
  • 모델의 원시 confidence score
  • 판단에 영향을 준 증거를 보여주는 decision trace
  • 결정론적 규칙으로 판단했다면 매칭된 규칙
  • 사용된 맥락, 규칙, 프롬프트의 버전 정보
• confidence는 모델의 자기평가일 뿐이므로, 사람이 검토한 라벨과 비교해 실제 보정 상태를 평가해야 한다.
• 모든 분류기를 하나의 보편적 taxonomy로 통합하지 않고, 각 분류기가 하나의 범위가 좁은 질문을 담당하도록 한다.
  • 예: 사용자 데이터인지 운영 데이터인지 분류
  • 예: 특정 AI 학습 용도에 적합한 자산인지 분류
• 좁은 범위의 분류기는 평가·디버깅·거버넌스가 쉽고, 여러 분류기의 결과를 downstream에서 조합할 수 있다.

실무적으로는 LLM을 최종 집행 엔진으로 삼기보다, 사람이 검토한 라벨과 충분한 맥락을 이용해 새로운 패턴을 발견하는 보조 계층으로 두는 것이 바람직하다. 이후 안정화된 판단은 버전 관리되는 규칙으로 승격해 운영하고, 모든 결과에 증거·버전·추적 정보를 남겨 재현성과 감사 가능성을 확보해야 한다.