들어가며: 왜 지금, 데이터 분류가 문제인가
AI 서비스가 보편화되면서, 우리가 다루는 데이터는 더 이상 깔끔한 테이블과 컬럼이 아닙니다. 로그 키, 이벤트 파라미터, 임베딩, ML 피처, 파이프라인 중간 산출물... 데이터의 형태는 점점 다양해지고, 그 의미는 맥락에 따라 완전히 달라집니다.
예를 들어, 단순히 age라는 이름의 필드가 있다고 가정해보죠. 한 시스템에서는 사용자의 나이를 저장하는 민감 정보일 수 있지만, 다른 인프라 파이프라인에서는 캐시 TTL(Time-To-Live) 값일 수도 있습니다. 전자라면 GDPR, CCPA 등 엄격한 보호 정책이 적용되어야 하지만, 후자라면 그냥 지나쳐도 되는 운영 데이터입니다.
이런 미묘한 차이를 시스템이 정확히 이해하고 분류하는 것이 프라이버시 인프라(Privacy-Aware Infrastructure, PAI) 의 출발점입니다. 메타(Meta)의 엔지니어링 블로그에 공개된 이 사례 연구는, 이 문제를 LLM과 결정론적 규칙의 하이브리드 패턴으로 어떻게 해결했는지 상세히 보여줍니다.
이 글은 원문의 핵심을 실무자의 시각에서 재구성했습니다. 단순 번역이 아닌, 국내 개발 환경에서 적용 가능한 인사이트와 주의점을 함께 전달합니다.

핵심 패턴: 7단계로 풀어낸 하이브리드 분류 시스템
메타 팀이 제시한 접근법은 크게 7단계로 구성됩니다. 각 단계는 'LLM으로 모든 것을 해결하려 하지 말고, LLM은 애매모호한 부분을 처리하고, 안정화된 패턴은 결정론적 규칙으로 증류(distill)하라'는 원칙에 기반합니다.
1단계: 계약(Contract)부터 명확히 하라
분류기는 플랫폼 서비스처럼 행동해야 합니다. 즉, 입력과 출력의 계약이 작고 명확하며 안정적이어야 합니다. 메타 팀은 각 분류기가 하나의 좁은 질문(예: '이 에셋이 사용자 데이터인가?')만 담당하도록 설계했습니다. 출력은 항상 다음을 포함합니다:
- 분류 범주
- 신뢰도 점수 (모델 자체 평가)
- 결정 근거(Decision Trace)
- 매칭된 규칙 (결정론적 로직 사용 시)
- 컨텍스트, 규칙, 프롬프트 버전 정보
2단계: 프롬프트보다 컨텍스트를 먼저 구축하라
메타 팀이 가장 강조하는 부분입니다. 분류 실패의 대부분은 프롬프트가 약해서가 아니라, 증거(Context)가 부족해서 발생했습니다.
단순히 필드 이름만 보고 모델이 추측하게 하는 대신, 다음과 같은 '증거 브리프(Evidence Brief)'를 구성합니다:
- 소스 코드 해석 정보 (필드가 정의/사용된 위치)
- 소유권 및 조직 메타데이터
- 의미론적 어노테이션 (데이터 타입, 출처)
- 계보(Lineage) 정보 (데이터의 흐름)
- ML 휴리스틱 출력 (스캐너, 임베딩 기반 분류기)
- 코드 검색 결과 (참조, 로깅 선언, 호출 지점)
여기서 중요한 것은 순환 참조(Circular Reasoning)를 방지하기 위해, 이미 정답을 암시하는 필드는 모델에게 제공하지 않고 마스킹(masking)한다는 점입니다. 이 마스킹은 단순한 프롬프트 위생이 아니라 시스템 불변 규칙(System Invariant) 으로 취급됩니다.
3단계: 결정 깔때기(Decision Funnel) 사용
컨텍스트가 준비되면, 분류기는 두 가지 경로로 나뉩니다:
- 결정론적 경로(Deterministic Path): 버전 관리된 규칙이 매칭되면, 밀리초 단위로 빠르게 결정. 전체 트래픽의 약 85%를 처리.
- LLM 기반 경로: 새롭거나 애매한 에셋은 LLM이 증거 브리프를 분석. 약 15%를 처리하며, 수 초가 소요되고 비용은 약 400배.
두 경로 모두 동일한 결과 스키마(범주, 신뢰도, 근거, 버전)를 출력하므로, 다운스트림 시스템은 결정이 어디서 왔는지 알 필요가 없습니다.
4단계: 콜드 스타트(Cold Start)를 의도적으로 해결하라
초기에는 레이블이 거의 없는 상태에서 시작합니다. 무작위 샘플링 대신, 정책에 기반한 예시를 시딩(seeding)합니다:
- 드문 민감 범주
- 경계 사례 (정책 해석이 어려운 경우)
- 민감해 보이지만 실제로는 아닌 부정 예시
- 컨텍스트 신호가 충돌하는 에셋
5단계: 학습 루프를 안전하게 유지하라
가장 중요한 설계 원칙 중 하나는 모델이 자신의 숙제를 스스로 채점하지 못하게 하는 것입니다. 메타 팀은 두 개의 루프를 분리했습니다:
- 참조 루프(Reference Loop): 인간이 검토한 레이블을 추가 전용, 버전 관리. 이 레이블이 평가의 기준이 됩니다.
- 최적화 루프(Optimization Loop): 프롬프트, 라우팅, 컨텍스트 사용을 개선하지만, 항상 참조 루프의 레이블로 평가받습니다.
또한, 세 명의 독립적인 '판사(Judge)' LLM을 사용하여 다수결로 최종 레이블을 결정하고, Cohen's Kappa로 판사 간 신뢰도를 측정합니다. 이 지표를 기반으로 시스템이 스스로 '멈춰야 할 때'를 인지합니다.
6단계: 안정적인 행동을 규칙으로 증류(Distill)하라
LLM이 발견한 안정적인 패턴은 단계적으로 결정론적 규칙으로 전환됩니다:
- 1단계: 단일 필드 기반 규칙 (정확 일치, 키워드, 숫자 범위 등)
- 2단계: 복합 규칙 (예: 'on-call에 X 포함 AND semantic type이 ACCOUNT_ID')
- 3단계 (선택): LLM이 규칙 생성을 도와주지만, 모든 후보는 엄격한 검증 게이트(홀드아웃 검증, 섀도우 모드, 인간 검토)를 통과해야 프로덕션에 배포됩니다.
이 증류 과정은 LLM의 프로덕션 역할을 점진적으로 줄여, 최종적으로는 LLM이 전혀 필요 없는 결정론적 엔진만으로 일상적인 분류가 이루어지게 합니다.
7단계: 올바른 것을 자동화하라
자동화의 경계를 명확히 설정합니다. 컨텍스트 수집, 증거 브리프 생성, 후보 분류, 평가 실행, 실패 분석, 후보 규칙 제안은 자동화합니다. 하지만 정책 해석, 참조 레이블 검토, 고위험 불일치, 보호 수준을 변경할 수 있는 규칙 승인은 반드시 인간의 판단을 거치도록 설계했습니다.
이상의 7단계 패턴은 다음 코드 스니펫으로 요약할 수 있습니다 (개념적 예시):
# 개념적 예시: 결정 깔때기 (Decision Funnel)
def classify_asset(asset_id, context_bundle):
# 1. 증거 브리프 생성 (컨텍스트에서 중요 신호 추출)
evidence_brief = build_evidence_brief(asset_id, context_bundle)
# 2. 결정론적 규칙 먼저 시도
matched_rule = find_matching_rule(evidence_brief)
if matched_rule:
return deterministic_decision(matched_rule, evidence_brief)
# 3. LLM 폴백 (애매한 경우)
llm_result = llm_classify(evidence_brief)
# 4. 신뢰도가 낮거나 판사 불일치 시 인간 검토로 라우팅
if llm_result.confidence < AUTO_ACCEPT_THRESHOLD:
route_to_human_review(asset_id, evidence_brief, llm_result)
return llm_result

국내 개발 생태계에서의 적용 맥락
메타의 이 패턴은 규모가 큰 빅테크 사례이지만, 국내 환경에서도 충분히 적용 가능한 원칙을 담고 있습니다.
1. SI/금융권 레거시 시스템: 국내 SI 프로젝트나 금융권 시스템은 수많은 테이블과 컬럼이 존재하지만, 데이터의 의미(개인정보 여부)가 문서화되지 않은 경우가 많습니다. 이 패턴을 차용하면, 초기에는 LLM으로 빠르게 분류를 시도하고, 안정적인 패턴이 발견되면 이를 SQL 기반의 결정론적 규칙으로 전환할 수 있습니다. 예를 들어, 컬럼명에 'SSN', 'JUMIN', 'PHONE' 같은 키워드가 포함되면 무조건 민감 정보로 분류하는 규칙을 먼저 세우고, 나머지 애매한 케이스만 LLM에 넘기는 식입니다.
2. 스타트업의 빠른 프로덕트 개발: 스타트업은 데이터 거버넌스에 투자할 여력이 부족합니다. 하지만 이 패턴은 '완벽한 분류'보다 '지속적인 개선'을 목표로 합니다. 초기에는 간단한 키워드 기반 규칙만으로 시작하고, 서비스가 성장하면서 LLM 기반 분류를 도입하고, 다시 안정화된 패턴을 규칙화하는 식으로 점진적으로 고도화할 수 있습니다.
3. 주의사항:
- 비용: LLM 추론 비용은 결정론적 규칙 대비 약 400배까지 차이날 수 있습니다. 국내 환경에서는 토큰 비용이 특히 중요하므로, LLM 사용량을 지속적으로 모니터링하고 규칙 커버리지를 늘리는 것이 비용 최적화의 핵심입니다.
- 한국어 데이터: 한국어는 교착어 특성상 형태소 분석이 중요합니다. 단순 키워드 매칭만으로는 '주민등록번호', '주민번호', 'JUMIN' 등 다양한 변형을 잡기 어렵습니다. 초기 규칙 설계 시 정규표현식과 함께 한국어 형태소 분석기를 활용한 패턴을 고려해야 합니다.
- 규제 대응: 개인정보보호법, 신용정보법 등 국내 규제는 데이터 분류에 더 엄격한 기준을 요구할 수 있습니다. '자동 분류' 결과를 완전히 신뢰하기보다는, 일정 비율의 샘플을 항상 인간이 검토하는 '감사 루프'를 시스템에 내장하는 것이 바람직합니다.

결론: 프라이버시 인프라는 '세금'이 아니라 '더 나은 아키텍처'를 위한 동력
메타의 이 사례가 주는 가장 큰 교훈은, 프라이버시 인프라 구축이 단순한 규제 준수 비용이 아니라, 시스템 아키텍처를 더 명확하고, 풍부한 컨텍스트를 갖추며, 안전하게 진화시키는 원동력이 될 수 있다는 점입니다.
핵심 원칙을 다시 정리하면:
- 컨텍스트가 프롬프트보다 중요하다. 모델에게 더 나은 질문을 고민하기 전에, 더 나은 증거를 제공하라.
- 결정론은 재현 가능성을 의미한다. LLM이 같은 답을 내는 것이 아니라, 같은 입력과 버전으로 같은 결정을 재현할 수 있어야 한다.
- 정확도 하나만으로 판단하지 마라. 불균형 데이터셋에서는 매튜 상관 계수, macro F1, 클래스별 재현율 등 다양한 지표를 함께 봐야 한다.
- LLM의 추천과 진실(Reference)은 분리하라. 모델이 스스로를 채점하게 두지 마라.
- 커버리지는 정확성과 같지 않다. 자동화율이 높아졌다고 안심하지 말고, 품질이 유지되는지 항상 확인하라.
- 증류(Distillation)가 프로덕션 모델이다. LLM은 발견과 추론에 사용하고, 안정화된 패턴은 결정론적 규칙으로 전환하라.
- 자기 규제는 운영이 아닌 아키텍처의 문제다. 시스템이 스스로 멈출 줄 알아야 한다.
다음 단계 학습 방향
- 실습: 자신의 프로젝트에서 가장 분류가 애매한 데이터 필드 3개를 골라, 수동으로 '증거 브리프'를 작성해보세요. 어떤 컨텍스트가 결정에 도움이 될지 고민해보는 것만으로도 큰 인사이트를 얻을 수 있습니다.
- 도구 탐색: 오픈소스 데이터 분류 도구(예: Apache Atlas, DataHub)와 LLM을 결합하는 PoC를 진행해보세요.
- 심화 학습: 메타의 이 패턴은 '에이전트 관찰 가능성(Agent Observability)' 등 다른 영역으로도 확장 가능하다고 합니다. LLM 에이전트의 행동을 감사하는 아키텍처에도 같은 원칙이 적용될 수 있습니다.
참고: 이 글은 메타 엔지니어링 블로그의 'Privacy-aware infrastructure in the AI-native era: An asset classification case study'를 기반으로 작성되었습니다.