AI 도구 데이터 유출을 막는 로그 설계 기준

사내 AI 도구에는 고객 문의, 계약서, 소스코드, 장애 로그, 회의록, 재무 자료가 빠르게 섞인다. 사용자는 업무를 끝내기 위해 문서 전체를 붙여 넣고, 애플리케이션은 검색 인덱스나 외부 모델 API로 내용을 전달할 수 있다. 보안팀이 나중에 “무엇이 어디로 갔는가”를 묻더라도 이벤트 구조가 없으면 답할 수 없다.

그렇다고 모든 프롬프트와 응답을 원문으로 저장하는 것도 위험하다. 로그 저장소가 고객정보, 비밀키, 법률 문서, 내부 소스코드를 모아 둔 새로운 고가치 자산이 되기 때문이다. 로그는 많이 남기는 것이 아니라 의사결정에 필요한 증거를 최소한으로 남겨야 한다.

먼저 데이터 흐름을 그린다

로그 필드를 정하기 전에 AI 요청이 거치는 경로를 한 장으로 그린다.

1. 사용자가 웹·IDE·챗봇에서 입력한다.
2. 애플리케이션이 프롬프트를 전처리하거나 DLP 검사를 한다.
3. 파일 저장소, 검색 인덱스, 벡터 DB에서 문맥을 가져온다.
4. 내부 모델 또는 외부 모델 공급자에게 요청한다.
5. 모델이 도구 호출, API 호출, 문서 생성 같은 행동을 요청한다.
6. 응답이 사용자나 다른 시스템으로 전달된다.

각 경계마다 “원문이 존재하는가”, “조직 밖으로 나가는가”, “누가 접근 가능한가”, “어떤 식별자로 추적할 수 있는가”를 표시한다. 이 흐름을 그리지 않고 애플리케이션 로그만 설계하면 프록시, 플러그인, 검색 인덱스, 외부 SaaS 계정 같은 실제 유출 지점을 놓치기 쉽다.

이벤트 단위로 남길 최소 필드

한 요청을 여러 시스템에서 추적할 수 있도록 공통 request_id 또는 trace_id를 사용한다. 필드 이름은 제품에 맞게 바꿀 수 있지만 의미는 일관되어야 한다.

필드	목적	원문 최소화 방법
event_time	사건 시간축 정렬	표준 시간대와 정밀도 통일
request_id	프록시·모델·도구 호출 연결	무작위 식별자 사용
user_id, department	책임 경계와 이상 사용 확인	사번 대신 내부 불투명 ID 고려
tool_id, model_id	어느 서비스와 모델을 사용했는지 확인	공급자·배포명·버전 기록
data_class	고객정보·계약·소스코드 등 등급	원문 대신 분류 결과 저장
input_size, file_count	대량 입력 탐지	문자·바이트·파일 수만 기록
detector_hits	어떤 정책에 걸렸는지 확인	탐지 유형과 개수 저장
policy_action	허용·차단·마스킹·승인 결과	정책 버전 포함
destination	내부·외부 모델 및 리전 구분	논리적 서비스 ID 기록
tool_calls	모델이 호출한 기능 확인	함수명, 대상 종류, 결과 코드
approver, ticket_id	예외 책임 추적	승인 근거를 티켓으로 분리
retention_until	자동 삭제 보장	이벤트 생성 시 만료일 계산

평상시 로그에는 프롬프트 본문, 전체 파일명, 전체 응답을 넣지 않는다. 파일명도 고객명이나 사건번호를 포함할 수 있으므로 확장자, 크기, 내부 문서 ID, 해시 정도로 대체한다.

메타데이터 이벤트 예시

다음 예시는 원문 없이도 정책 판단과 조사 연결이 가능한 형태다. 실제 필드와 보존 기간은 개인정보·노무·계약 요구사항을 검토해 정해야 한다.

{
  "event_time": "2026-06-19T09:14:25+09:00",
  "request_id": "req_7b3f...",
  "user_id": "usr_91c2...",
  "department": "support",
  "tool_id": "intenal-ai-gateway",
  "model_id": "approved-model-a",
  "destination_scope": "extenal-managed-service",
  "data_class": ["customer-confidential"],
  "input_bytes": 184230,
  "file_count": 2,
  "detector_hits": ["personal-data", "contract-text"],
  "policy_action": "blocked",
  "policy_version": "dlp-2026-06-01",
  "exception_ticket": null,
  "retention_until": "2026-09-17T00:00:00+09:00"
}

이 예시의 값과 보존 기간은 운영 예시일 뿐이다. 실제 적용 전에는 법무·개인정보 담당자와 함께 목적, 접근자, 보존 기간, 삭제 증거를 확인해야 한다.

로그에 남기지 않을 것

다음 정보는 기본적으로 원문 저장 금지 목록에 둔다.

• 주민등록번호, 카드정보, 계좌정보의 전체 값
• 인증 토큰, API 키, 비밀번호, 개인키
• 고객 명단과 계약서 전체 본문
• 비공개 소스코드와 설정 파일 원문
• 의료·법률·노무 상담의 상세 본문
• 모델 시스템 프롬프트와 내부 보안 규칙 원문
• 사용자의 불필요한 키 입력 또는 화면 캡처

탐지 엔진이 민감 문자열을 발견했을 때도 전체 값을 로그에 복사하지 않는다. personal_id_detected: true, 마스킹된 접두·접미 일부, 탐지 규칙 ID, 문서 해시처럼 판단에 필요한 최소 정보로 대체한다. 해시 역시 소규모 후보 값에 대한 역추적 가능성이 있으므로 민감도가 높은 값은 키 기반 해시나 별도 토큰화 방식을 검토한다.

원문 조사가 필요한 경우를 별도 절차로 둔다

사고 조사, 사용자 이의 제기, 품질 분석 때문에 원문이 필요할 수 있다. 이 경우 평상시 로그 보존과 분리된 제한 조사 모드를 둔다.

• 사고 번호와 조사 목적이 있어야 활성화된다.
• 최소 두 역할의 승인 또는 독립 검토를 요구한다.
• 대상 사용자·기간·도구를 좁힌다.
• 원문 열람과 내보내기를 모두 감사 로그로 남긴다.
• 자동 만료 시간을 짧게 둔다.
• 조사 종료 후 삭제 또는 봉인 증거를 남긴다.
• 조사 자료를 모델 학습 데이터로 재사용하지 않는다.

“나중에 필요할 수 있다”는 이유로 원문을 상시 저장하는 것은 제한 조사 모드가 아니다. 목적과 종료 조건이 없는 수집은 로그 저장소를 유출 경로로 만든다.

탐지해야 할 운영 신호

AI 데이터 유출은 단일 금칙어보다 행동 조합으로 보이는 경우가 많다.

신호	확인할 맥락
평소보다 큰 입력·파일 수	업무 이벤트인지, 자동 수집인지
새 모델·새 공급자 사용	승인 목록과 계약 범위에 포함되는지
개인 계정 또는 비관리 브라우저	회사 게이트웨이를 우회했는지
차단 후 반복 재시도	파일 분할·인코딩 등 우회 시도인지
예외 승인 직후 대량 요청	승인 범위와 실제 사용이 일치하는지
모델의 외부 도구 호출 급증	과도한 권한 또는 프롬프트 주입 가능성
응답에서 민감정보 탐지	검색 인덱스·권한 경계가 잘못됐는지
AI 요청과 클라우드 이그레스 동시 증가	대량 업로드 또는 외부 전송인지

마지막 항목은 클라우드 이그레스 비용을 보안 신호로 보는 법과 연결하면 유용하다. AI 게이트웨이 요청량, 외부 API 바이트, 모델 비용, DLP 탐지 결과를 같은 시간축으로 보면 업무 증가와 비정상 전송을 더 잘 구분할 수 있다.

승인 흐름은 짧고 만료 가능해야 한다

정책이 너무 느리면 사용자는 개인 계정, 외부 번역기, 메신저 같은 우회 경로를 찾는다. 예외 요청은 다음 네 질문으로 짧게 구성한다.

1. 어떤 데이터 등급을 사용할 것인가.
2. 어떤 업무 목적과 결과물이 필요한가.
3. 어느 도구·모델·리전으로 보낼 것인가.
4. 언제까지 필요한가.

승인 결과에는 허용 범위와 만료일이 있어야 한다. 예를 들어 특정 프로젝트 문서, 특정 모델, 특정 사용자 그룹, 일주일 같은 범위를 조합한다. 만료 없는 예외는 상시 허용과 같으므로 주간 검토에서 장기 예외를 정책으로 승격하거나 제거한다.

보존 기간과 접근 권한 설계

모든 이벤트를 같은 기간 보관할 필요는 없다. 차단 이벤트, 관리자 정책 변경, 원문 조사 로그는 일반 성공 요청보다 더 긴 감사 필요가 있을 수 있다. 반대로 일반 성공 이벤트의 세부 메타데이터는 짧게 보존할 수 있다. 기간은 다음 요소로 결정한다.

• 사고 탐지와 조사에 필요한 시간
• 계약·규제·노무 요구사항
• 개인정보 최소 보유 원칙
• 저장소 침해 시 피해 범위
• 집계 지표로 전환할 수 있는 시점

접근 권한도 역할별로 나눈다. 헬프데스크는 요청 상태만, 보안 운영자는 탐지 메타데이터만, 제한된 조사자는 승인된 범위의 원문만 보도록 한다. 로그 조회 자체도 이상 행동 탐지 대상에 포함한다.

사고 대응 플레이북

민감정보가 승인되지 않은 AI 도구로 전송된 정황이 있으면 다음 순서로 대응한다.

1. 요청 ID, 사용자, 도구, 시간 범위를 확보한다.
2. 추가 요청을 막되 업무 전체를 중단하지 않도록 대상 계정·도구 범위를 좁힌다.
3. 공급자의 저장·학습·삭제 정책과 계약상 통지 경로를 확인한다.
4. 관련 세션, API 키, 연결 앱 토큰을 검토하고 필요하면 회전한다.
5. 같은 문서가 다른 도구로 전송됐는지 검색한다.
6. 데이터 소유자, 개인정보·법무 담당자에게 분류 결과와 범위를 전달한다.
7. 삭제 요청, 접근 제한, 정책 수정 결과를 증거로 남긴다.
8. 원인이 사용자 교육, UI 설계, DLP 탐지, 권한 중 어디에 있었는지 재발 방지 조치를 만든다.

시크릿이 포함되었다면 단순 삭제 요청만으로 끝내지 말고 해당 자격 증명을 즉시 폐기·교체하고, CI/CD 파이프라인·저장소·로그·아티팩트의 잔존 여부를 조사한다.

배포 전 검증 테스트

• 프롬프트와 파일 원문이 일반 로그에 남지 않는지 확인한다.
• DLP 탐지 결과가 원문 없이도 조사 티켓과 연결되는지 확인한다.
• 차단, 마스킹, 승인, 만료 이벤트가 모두 기록되는지 확인한다.
• 외부 모델과 내부 모델이 명확히 구분되는지 확인한다.
• 로그 접근 권한과 내보내기 기록을 테스트한다.
• 보존 만료 후 실제 삭제가 이루어지는지 샘플 검증한다.
• 제한 조사 모드가 승인 없이 활성화되지 않는지 확인한다.
• 장애 시 로그 실패가 AI 요청의 무제한 우회로 이어지지 않는지 확인한다.

참고 기준

• NIST AI Risk Management Framework
• NIST AI RMF Generative AI Profile
• OWASP Logging Cheat Sheet
• OWASP Top 10 for LLM and GenAI Applications 2025

AI 보안 로그는 감시를 위해 모든 대화를 쌓는 장치가 아니다. 데이터 흐름을 설명하고 정책이 작동했는지 검증하며, 사고가 났을 때 범위를 좁히는 최소 증거다. 원문을 줄이고 이벤트 구조를 표준화할수록 보안팀은 더 적은 데이터로 더 정확한 판단을 할 수 있다.