AI 로그 개인정보 보호 — 마스킹·접근 권한·삭제 기준 만들기

입력창에서 고객 이메일을 제외하도록 바꿨더라도 오류 추적 도구에는 이전 요청 본문이 남아 있을 수 있습니다. 이런 상황을 점검하려면 입력 화면뿐 아니라 데이터가 복제되는 경로도 살펴봐야 합니다.

로그 보호의 출발점은 어떻게 가릴지보다 무엇을 저장하지 않아도 되는지를 정하는 것입니다. AI에 입력하면 안 되는 정보에서 입력 범위를 정했다면, 이번에는 사용 과정에서 남는 사본을 확인해 보겠습니다.

먼저 로그가 지나가는 곳을 그려 보세요

다음은 가상 고객 문의 분석 서비스의 데이터 경로입니다. 실제 운영 시스템을 조사한 결과가 아닙니다.

문의 입력
  → 애플리케이션 요청 처리
  → AI API와 연결 도구
  → 응답 생성

별도로 확인할 사본
  → 서버 콘솔 / 오류 추적 / 실행 트레이스
  → 고객 지원 내보내기 / 분석 저장소 / 백업

정상 응답만 보지 말고 실패 경로도 확인하세요. SDK 오류 객체, HTTP 요청 헤더, 재시도 기록에 원문이나 인증 정보가 들어갈 수 있습니다. 운영 로그에서 제거했어도 외부 오류 수집 도구가 먼저 가져가면 노출 범위는 줄지 않습니다.

AI 제공자의 학습 사용 여부, 서비스 내부 보존, 우리 애플리케이션 로그는 서로 다른 항목입니다. “학습에 사용하지 않음”을 선택했다고 모든 사본이 즉시 사라진다고 해석하지 않습니다.

필드별로 저장 목적을 정하세요

아래는 기본 운영 로그를 최소화하기 위한 설계 예시입니다. 업무상 별도 보관 의무가 있는 자료의 삭제 지침은 아닙니다.

필드	기본 운영 로그의 처리	남기는 이유
실행 ID·오류 코드	기록	장애 흐름 연결
모델·프롬프트 버전	기록	변경 원인 추적
처리 시간·토큰 수	기록	성능·비용 확인
이메일·전화번호	원문 제외	기본 오류 분석에는 불필요
문의 전문·첨부파일	기본 저장 제외	별도 필요성과 권한 검토
인증 헤더·API 키	기록 금지	로그로 자격 증명이 복제되지 않게 함
원문 열람 이력	필요한 최소 정보 기록	누가 어떤 목적으로 봤는지 확인

민감정보와 접근 토큰 등을 로그에서 직접 기록하지 않도록 관리하는 원칙은 OWASP Logging Cheat Sheet에 정리되어 있습니다. 여기서는 그 원칙을 AI 요청·응답 경로에 적용합니다.

마스킹은 저장 전에 적용하세요

다음 입력은 테스트용 가상 데이터입니다. 실제 고객정보나 실제 비밀값을 테스트에 사용하지 않습니다.

[테스트 입력]
TEST_CUSTOMER_001
이메일: customer@example.com
주문: TEST_ORDER_042
문의: 배송 상태를 확인해 주세요.

[기본 운영 로그 예시]
run_id=run-demo-019
task=delivery-question
status=failed
error_code=upstream_timeout
redaction_applied=true

운영 로그는 원문 전체에서 일부만 별표로 바꾸는 대신, 허용한 필드만 새로 구성할 수 있습니다. 개별 고객 추적이 꼭 필요하면 제한된 연결 저장소의 불투명 식별자를 사용하고, 그 연결 정보에 대한 접근도 관리합니다.

이름·주문번호·주소의 일부만 남아도 다른 정보와 결합해 사람을 알아볼 수 있습니다. 이메일을 단순 해시로 바꾸는 방법도 가능한 값을 대입해 연결할 위험이 있어 완전한 익명화라고 설명할 수 없습니다.

정규식은 정해진 형식을 찾는 데 유용하지만 자연어 속 개인정보나 이미지의 글자를 모두 잡지 못합니다. 탐지 필터에만 의존하지 말고 저장 필드 제한, 업로드 범위 제한, 원문 접근 통제를 함께 적용하세요. OWASP의 민감정보 노출 자료에서도 입력 정제와 최소 권한을 방어 요소로 다룹니다.

원문 열람은 일반 로그 조회와 분리하세요

디버깅에 원문이 꼭 필요한 경우에는 모두가 보는 로그 화면에 복사하지 않습니다. 사유·승인·접근 만료 조건이 있는 별도 경로를 마련합니다.

원문 열람 요청 양식
장애 ID:
원문 없이 확인한 내용:
추가로 필요한 데이터 범위:
열람 담당 역할 / 승인 역할:
접근 만료 조건:
외부 다운로드 허용 여부:
열람 종료 후 확인 사항:

“관리자니까 볼 수 있음”으로 끝내지 말고 해당 장애를 해결하는 데 필요한 범위인지 확인합니다. 열람 이력에는 원문을 다시 복제하지 않습니다. 외부 지원팀에 보내는 캡처·내보내기 파일도 같은 기준으로 검토하세요.

삭제는 저장소별로 확인해야 합니다

보존 기간은 처리 목적, 조직 정책, 적용되는 법적·계약상 의무에 따라 정합니다. 모든 로그를 일률적으로 며칠 보관하면 적법하다는 식의 기준은 제시하지 않습니다.

저장 위치	종료·삭제 확인 항목
기본 로그	보존 기한과 삭제 작업 결과
원문 조사 저장소	조사 종료·예외 보관 승인 여부
오류 추적 서비스	본문·첨부·이벤트 사본의 처리
내보내기 파일	수신 대상과 남은 사본
백업	만료 일정과 복원 시 삭제 재적용

백업을 즉시 개별 삭제할 수 없다면 접근 제한, 만료 계획, 복원 후 재노출 방지 절차를 확인합니다. 실제 남아 있는 사본을 조사하지 않고 “완전 삭제 완료”라고 보고하지 마세요.

가상 정보로 정상·오류 경로를 시험하세요

탐지용 이메일·고객 표식·가짜 비밀 표식을 준비합니다.
정상 처리, 유효성 오류, API 오류, 시간 초과를 각각 발생시킵니다.
콘솔·트레이스·오류 수집·내보내기에서 표식을 검색합니다.
권한 없는 역할이 원문과 연결 정보를 볼 수 없는지 확인합니다.
테스트 사본 삭제 후 각 저장소의 조회 결과를 대조합니다.
마스킹이 실패해도 원문이 그대로 저장되지 않는지 확인합니다.

마스킹 실패 시 처리 중단이 필요한지, 민감한 본문 없이 최소 오류만 남길지는 서비스 위험에 맞춰 결정합니다. 중요한 보안 사건 자체를 로그에서 사라지게 만드는 것과 민감한 원문을 제외하는 것은 구분해야 합니다.

외부 문서가 비밀값 출력을 유도하는 상황까지 시험하려면 프롬프트 인젝션 안전 점검의 격리된 테스트 원칙을 함께 적용하세요.

기대 결과와 실패 징후

기대 결과: 원문 없이 오류 흐름을 추적할 수 있고, 원문이 필요한 조사는 제한된 범위에서만 이루어집니다. 삭제 결과를 저장소별로 설명할 수 있습니다.

실패 징후: 화면에서는 별표인데 내보내기에는 원문이 남거나, 정상 경로만 가려지고 오류 경로에는 인증 헤더가 기록되거나, 백업 복원 뒤 삭제 정보가 다시 나타납니다.

마스킹 적용 표시를 확인했다면 실제 저장·열람·복구 경로에서 원문이 어디까지 남는지도 대조하세요. 화면에서 가려졌다는 사실만으로 사본이 처리됐다고 판단하지 않습니다.

자주 묻는 질문

Q1. 이메일 일부를 가렸으면 개인정보가 아닌가요? 그렇게 단정할 수 없습니다. 다른 정보와의 결합 가능성과 실제 재식별 위험을 검토해야 합니다.

Q2. 암호화해서 저장하면 원문을 모두 남겨도 되나요? 암호화는 보호 수단이지 수집 목적과 필요성을 대신하지 않습니다. 복호화 권한과 사본, 보존 기간도 관리해야 합니다.

Q3. 장애 분석을 위해 로그를 영구 보관해도 되나요? 목적과 적용 의무를 검토해 필요한 기간을 정해야 합니다. 오래 보관할 통계와 개별 원문을 분리하는 방법부터 검토하세요.

Q4. 로그를 지우면 AI 제공자 쪽 데이터도 지워지나요? 별도 시스템이므로 그렇다고 볼 수 없습니다. 사용한 상품의 저장·삭제 조건과 계약을 따로 확인해야 합니다.

공식 자료와 확인 기준일

확인 기준일: 2026-09-06 — 필드표와 테스트는 기술 운영 예시입니다. 개인정보 처리의 적법성이나 법정 보존 기간을 대신 판단하는 지침은 아닙니다.