AI 도구 사용 로그에서 민감정보를 거르는 입력·출력 필터

AI 도구를 여러 번 사용하면 나중에 왜 그런 결과가 나왔는지 확인하기 위해 로그를 남기고 싶어집니다. 하지만 프롬프트와 도구 인자에는 원고, 고객 정보, 토큰, 내부 경로가 함께 들어갈 수 있습니다.

저는 모든 것을 저장하는 대신 나중에 확인해야 하는 질문부터 정했습니다. 입력·출력·도구 호출·오류를 같은 방식으로 기록하지 않고, 목적에 맞는 최소 정보만 남기는 흐름을 소개합니다.

로그의 목적을 먼저 나눕니다

로그를 남기는 이유는 품질 개선, 장애 분석, 비용 확인, 보안 감사로 나뉩니다. 한 목적에 필요한 정보가 다른 목적에는 과도할 수 있습니다. 예를 들어 비용 확인에는 전체 프롬프트보다 모델명·토큰 수·응답 시간이 필요합니다.

목적을 문서에 적으면 보존 기간과 접근 권한도 함께 정할 수 있습니다. ‘나중에 필요할 것 같아서’는 민감한 원문을 오래 보관하는 이유가 되지 못합니다.

• 품질: 입력 구조와 출력의 평가 결과를 남깁니다.
• 장애: 오류 유형·요청 ID·실행 단계를 남깁니다.
• 비용: 모델·호출 수·처리량·요금을 남깁니다.
• 감사: 누가 언제 어떤 권한으로 도구를 호출했는지 남깁니다.

민감정보는 입력 단계에서 줄입니다

출력 로그에서 나중에 마스킹하는 것보다 모델과 도구로 보내기 전에 최소화하는 편이 안전합니다. 원고 전체 대신 필요한 문단만 보내고, 사용자 식별자는 내부 ID나 일회성 별칭으로 바꿉니다.

마스킹 규칙은 이메일·전화번호 같은 정형 정보만 다루지 않습니다. API 키, 쿠키, 파일 경로, 내부 URL, 원고 속 실명처럼 프로젝트에 따라 중요한 값도 목록에 넣어야 합니다.

대상처리남길 정보

비밀 키	전송 전 제거	키가 필요했다는 이벤트
개인 식별자	별칭으로 치환	일관된 내부 ID
원고·문서	필요 범위만 발췌	문서 버전·구간
파일 경로	프로젝트 상대 경로	파일 역할

도구 인자와 응답도 검수 대상입니다

프롬프트만 가리면 안전하다고 생각하기 쉽지만, 실제 위험은 도구 인자에 들어 있는 파일 경로나 데이터베이스 쿼리일 수 있습니다. 응답에는 모델이 원문을 그대로 되풀이하거나 비밀 값을 추측해 쓰는 경우도 있습니다.

저는 로그 저장 전에 입력·도구 인자·응답을 각각 필터링합니다. 필터가 실패하면 저장을 중단하고, 운영자에게 어떤 필드가 문제였는지만 알립니다.

• 입력 필터: 보내기 전에 정규식·규칙·허용 목록으로 검사합니다.
• 도구 필터: 경로·쿼리·권한 범위를 기록 가능한 형태로 줄입니다.
• 출력 필터: 응답에 포함된 비밀·개인정보를 제거합니다.

보존과 접근 권한을 함께 줄입니다

민감정보가 없는 로그도 오래 보관할 이유가 없다면 삭제해야 합니다. 개발·스테이징·운영 로그의 보존 기간과 접근 권한을 다르게 두고, 원문을 볼 수 있는 사람을 최소화합니다.

로그를 분석할 때는 원문 대신 요약·해시·통계로 충분한지 먼저 확인합니다. 감사가 필요할 때도 토큰이나 원고 본문을 다시 열 수 있게 만드는 것보다 어떤 동작이 있었는지를 확인하는 편이 안전한 경우가 많습니다.

AI 도구를 사용할 때 남겨야 할 경계

AI 도구는 조사와 구조화에 도움을 주지만, 결과의 책임까지 가져가지는 않습니다. 저는 작업을 시작할 때 입력에 포함해도 되는 정보, 외부 출처로 확인해야 하는 주장, 사람이 직접 판단해야 하는 결과를 구분합니다. 이 세 가지가 섞이면 AI가 만든 문장이나 도구 호출을 실제 경험과 사실처럼 받아들이기 쉽습니다.

작은 샘플로 실행한 뒤 기록을 검토하는 것도 중요합니다. 프롬프트·도구 인자·응답·파일 결과 중 무엇을 보관할지 정하고, 민감정보와 권한을 최소화합니다. 한 번 잘 나온 결과보다 같은 조건에서 다시 확인할 수 있는 과정이 더 오래 남는 자산입니다. 최신 사양과 정책을 다루는 글은 조사일과 버전을 고정하고 발행 전에 공식 문서를 다시 읽습니다.

• 입력 범위: 원고·개인정보·토큰·파일 경로 중 무엇을 보내지 않을지 정합니다.
• 근거: 공식 문서와 직접 경험을 분리해 기록하고 URL을 보관합니다.
• 검수: 사실·출처·문체·권한·재현성을 사람이 확인합니다.
• 중단 조건: 결과가 반복되지 않거나 비용·권한이 커지면 사용을 멈춥니다.

다음 작업에서 다시 확인할 항목

한 번 적용한 방법이 언제나 같은 결과를 내는 것은 아닙니다. 사람과 서비스와 원고의 조건이 바뀌면 같은 원칙도 다른 판단을 요구합니다. 그래서 저는 글을 작성한 뒤 결론만 보관하지 않고, 결론이 성립한 조건과 다시 확인해야 할 조건을 함께 적습니다. 이 기록이 있으면 몇 달 뒤 글을 업데이트할 때 당시의 경험을 현재의 사실처럼 착각하지 않을 수 있습니다.

특히 버전·정책·가격·플랫폼 기능처럼 외부에서 바뀌는 내용은 조사한 날짜와 공식 문서의 주소를 남깁니다. 발행 시점에 문서가 달라졌다면 본문에 변경 사실을 표시하고, 직접 확인하지 못한 부분은 독자가 알 수 있도록 범위를 제한합니다. 경험을 공유하는 글도 다른 사람의 환경에 그대로 적용될 수 있으므로, 성공 사례보다 실패 조건을 함께 쓰는 편이 안전합니다.

마지막으로 이 글을 읽은 분이 바로 할 수 있는 행동은 하나로 줄입니다. 모든 항목을 한꺼번에 바꾸기보다 현재 상태를 기록하고, 작은 실험을 한 번 실행하고, 결과를 다시 적는 순서입니다. 그렇게 쌓인 기록이 다음 글의 소재가 되고, 처음의 판단을 더 정확하게 고쳐 쓰는 근거가 됩니다.

• 범위 표시: 이 글의 결론이 적용되는 환경과 적용되지 않는 환경을 구분합니다.
• 날짜 기록: 버전·정책·가격·문서를 확인한 날짜를 남깁니다.
• 실패 조건: 어떤 상황에서는 이 방법을 쓰지 말아야 하는지 적습니다.
• 작은 실행: 독자가 오늘 시도할 수 있는 가장 작은 행동을 고릅니다.
• 후속 기록: 실행 결과와 다음에 바꿀 조건을 별도 메모로 남깁니다.

이 기록을 나중에 다시 읽을 때는 결과만 보지 않고 당시의 조건도 함께 확인합니다. 조건이 달라졌다면 결론을 그대로 복사하지 말고 현재의 입력과 제약을 다시 적습니다. 그 과정을 거쳐야 이 글이 단순한 경험담이 아니라 다음 판단을 돕는 작업 기록으로 남습니다.

마치며

AI 로그의 품질은 많이 저장하는 데 있지 않고 필요한 질문에 답하면서도 민감정보를 남기지 않는 데 있습니다. 현재 로그 필드마다 품질·장애·비용·감사 중 어떤 목적이 있는지 표시하고, 목적이 없는 원문부터 줄여 보시기 바랍니다.

참고한 문서: MCP Authorization 사양 · Google 생성형 AI 콘텐츠 지침