프롬프트 로그 보관 정책: 품질 개선과 개인정보 보호 사이
LLM 로그를 무작정 저장할 때 생기는 개인정보 위험을 줄이고 마스킹, 보존 기간, 접근권한을 설계하는 기준을 설명한다. Prompt Logs·Privacy·LLM Ops 관점에서 처음 접하는 독자도 개념, 적용 조건, 실패 가능성을 차례대로 이해할 수 있게 설명한다.
핵심 요약
프롬프트 로그는 품질 개선에 유용하지만 원문을 무기한 저장하면 개인정보, 인증정보, 내부 문서가 한 저장소에 모인다. 메타데이터와 콘텐츠를 분리하고, 저장 전 마스킹·샘플링·목적별 보존 기간·접근 승인·삭제 전파를 설계해야 한다.
LLM 서비스는 문제를 재현하고 품질을 평가하기 위해 프롬프트와 응답을 기록하고 싶어 한다. 그러나 사용자는 채팅창을 검색창이나 메모장처럼 사용하며 이름, 계약 내용, 소스 코드, 비밀번호까지 붙여 넣을 수 있다. 검색 증강 시스템은 사용자 입력뿐 아니라 검색된 문서 조각과 도구 실행 결과도 로그에 남길 수 있다.
따라서 “로그를 남길지 말지”의 이분법보다 어떤 목적에 어떤 필드를 얼마나 오래 저장할지 나누는 것이 중요하다. 이 글은 기술 운영 기준이며, 개인정보 처리 근거·고지·사용자 권리·산업별 보존 의무는 관할 법률과 계약을 개인정보·법무 담당자와 확인해야 한다.
조직 차원의 허용 도구와 데이터 등급은 섀도 AI를 금지 문구로 막을 수 없는 이유와 현실적 정책, 로그 필드와 탐지 설계는 AI 도구 데이터 유출을 막는 로그 설계 기준과 연결하면 중복 정책을 줄일 수 있다.
로그를 네 계층으로 분리한다
| 계층 | 예시 | 기본 정책 |
|---|---|---|
| 운영 메타데이터 | 요청 ID, 모델 버전, 지연, 토큰 수, 오류 코드 | 기본 저장 가능, 내용 제외 |
| 안전·보안 이벤트 | 정책 차단 코드, 도구 호출 대상, 권한 실패 | 제한 접근, 사건 목적 보존 |
| 품질 샘플 | 마스킹된 프롬프트·응답 일부 | 샘플링, 짧은 기간, 검토자 제한 |
| 원문 콘텐츠 | 전체 대화, 첨부, 검색 문서 조각 | 기본 비저장 또는 명시적 승인 |
모든 요청에 같은 로그 수준을 적용하지 않는다. 결제·의료·법률·인사처럼 고위험 업무는 원문 저장을 끄고 메타데이터 중심으로 운영할 수 있다. 반대로 공개 문서 요약 기능은 제한된 샘플을 품질 평가에 사용할 수 있다.
저장 전 처리 파이프라인
마스킹은 저장한 뒤 배치로 하는 것보다 수집 경계에서 먼저 수행해야 한다.
- 입력·출력·검색 결과·도구 호출을 별도 필드로 분리한다.
- 비밀번호, API 키, 토큰, 결제정보 등 명확한 비밀 패턴을 차단한다.
- 이메일·전화번호·계정 ID 등 개인정보를 토큰화하거나 제거한다.
- 자유 입력 원문은 허용된 사용 사례만 샘플링한다.
- 마스킹 실패 또는 확신이 낮은 레코드는 격리하거나 저장하지 않는다.
- 목적·데이터 등급·보존 정책 태그를 붙인다.
- 암호화된 저장소와 제한된 인덱스로 전송한다.
정규식만으로 모든 민감 정보를 찾을 수는 없다. 데이터 분류 모델이나 DLP를 사용하더라도 거짓 음성과 과잉 마스킹을 측정하고, 고위험 필드는 구조적으로 수집하지 않는 설계가 우선이다.
권장 로그 봉투 예시
{
"requestId": "req_8f3...",
"tenantId": "tokenized_tenant",
"userId": "rotating_pseudonym",
"purpose": "support_answer_quality",
"model": {
"provider": "approved-provider",
"modelId": "model-version-id"
},
"input": {
"stored": false,
"length": 842,
"language": "ko",
"sensitiveCategories": ["email"]
},
"retrieval": {
"documentIds": ["doc_token_1"],
"chunksStored": false
},
"tools": [
{ "name": "ticket-read", "resultStored": false, "status": "success" }
],
"output": {
"stored": true,
"redacted": true,
"safetyDecision": "allow"
},
"retentionClass": "quality-sample-14d"
}
문서 ID도 사용자가 접근할 수 없는 문서를 추론하게 만들 수 있으므로 토큰화와 권한 분리가 필요하다.
보존 기간을 목적별로 다르게 둔다
- 실시간 장애 진단: 수 시간~수일의 짧은 원문 보존을 검토
- 품질 평가 샘플: 평가 주기와 재현에 필요한 제한 기간
- 비용·성능 지표: 콘텐츠 없이 장기 집계 가능
- 보안 사건: 사건 티켓과 연동해 별도 보존·접근
- 사용자 대화 기록: 제품 기능과 사용자 삭제 기대에 맞춘 정책
- 모델 학습 데이터: 별도 승인·정제·계보 관리가 필요한 독립 데이터셋
운영 로그를 나중에 학습 데이터로 재사용하려면 원래 목적과 다른 처리일 수 있다. 자동 전환하지 말고 별도 승인, 필터링, 데이터 계보, 삭제 전파를 거친다.
접근과 조회 통제
프롬프트 원문을 보는 권한은 일반 로그 조회 권한과 분리한다.
- SSO와 개인 계정, 강한 인증을 사용한다.
- 서비스·테넌트·기간·사건 번호로 범위를 제한한다.
- 원문 조회는 시간 제한 승인과 사유를 요구한다.
- 대량 검색·내보내기·공유 링크를 경보한다.
- 운영자 화면에서 기본 마스킹하고 필요 시 단계적으로 해제한다.
- 조회자 자신의 요청이거나 이해관계가 있는 데이터 검토를 통제한다.
- 개발·테스트 환경에 운영 원문을 복사하지 않는다.
검색 증강과 도구 로그의 특별 위험
RAG 시스템에서는 프롬프트보다 검색된 내부 문서가 더 민감할 수 있다. 로그에는 검색 질의, 문서 ID, 문서 조각, 점수, 최종 답변이 함께 남기 쉽다.
- 검색 문서 조각은 기본 저장하지 않고 ID와 정책 결정만 남긴다.
- 사용자 권한과 검색 권한의 일치 결과를 기록한다.
- 도구 호출 인자·결과에서 비밀값을 제거한다.
- 쓰기 도구는 실행 전·후 상태와 승인자를 기록하되 본문 최소화 원칙을 적용한다.
- 실패한 도구 결과가 예외 로그에 원문으로 남지 않게 한다.
탐지 신호
- 마스킹 실패율과 민감 패턴 탐지 건수의 급증
- 원문 저장 비율이 정책 기준을 초과하는 서비스
- 보존 기한을 넘긴 레코드와 삭제 큐 적체
- 특정 운영자의 대량 원문 조회·내보내기
- 새 모델·도구 배포 뒤 로그 필드나 전송량 증가
- 테넌트 간 문서 ID·대화가 섞이는 징후
- 사용자 삭제 후 검색 인덱스·평가 데이터에 남은 레코드
- 로그 저장소 비용·카디널리티의 비정상 증가
사고 대응
비밀값이나 개인정보가 로그에 저장된 경우 해당 필드 수집을 우선 중단하고 영향 기간과 저장 계층을 파악한다. 원시 저장소, 검색 인덱스, 분석 복제본, 평가 데이터셋, 외부 관측 도구에서 삭제한다. 비밀번호·토큰이면 실제 삭제 확인과 별개로 회전해야 한다. 접근·내보내기 이력을 검토하고 법적 통지 판단은 개인정보·법무 담당자와 진행한다.
출시 체크리스트
- 메타데이터, 안전 이벤트, 품질 샘플, 원문이 분리돼 있는가.
- 마스킹이 영구 저장 전에 실행되는가.
- 프롬프트뿐 아니라 검색 결과와 도구 결과도 정책 대상인가.
- 원문 저장이 기본값이 아니라 목적별 선택인가.
- 보존 기간이 코드와 스토리지 정책에 적용돼 있는가.
- 사용자 삭제가 평가·학습 데이터까지 전파되는가.
- 원문 조회와 내보내기를 감사·경보하는가.
- 새 모델·SDK 배포 시 로그 스키마 차이를 검사하는가.
참고 기준
- NIST AI Risk Management Framework
- NIST AI 600-1: Generative AI Profile
- OWASP GenAI Security Project
- NIST Privacy Framework
- OWASP Logging Cheat Sheet
결론
품질 개선에 필요한 것은 모든 대화의 영구 보관이 아니라 재현 가능한 최소 증거다. 콘텐츠와 메타데이터를 분리하고 저장 전 마스킹, 목적별 보존, 제한 조회를 적용하면 운영 가시성을 유지하면서 로그 저장소가 새로운 민감정보 창고가 되는 것을 막을 수 있다.
전체 댓글 0개