AI 에이전트 대화 기록, 로그라서 다 보관해도 될까? transcript 보존 경계를 정하는 5단계

핵심 요약

• 에이전트 대화 원문, 운영 관찰용 로그, 책임 추적용 감사 증적은 같은 보존 규칙으로 다루면 안 됩니다.
• 제품의 기본 동작이나 계약 조건은 저장 위치·기능·계정 설정에 따라 달라질 수 있으므로, 현재 조직의 실제 흐름을 먼저 확인해야 합니다.
• 보존 기간만 정하지 말고 누가 열람을 승인하고, 언제 재검토하며, 어떤 사건에서 삭제할지를 기록마다 정하세요.
• 장애 분석에는 전체 원문보다 요청 ID, 실행 시각, 도구 호출 결과 요약, 승인 흔적처럼 재현에 필요한 최소 증적이 더 유용한 경우가 많습니다.

로그인데 왜 전부 보관하면 안 될까요?

에이전트가 작업한 뒤에는 대화 원문, 도구 출력, 파일 조각, 오류 메시지, 사람의 승인 기록이 한 세션 안에 섞이기 쉽습니다. 장애가 났을 때를 대비해 모두 저장하고 싶어지는 이유도 여기에 있습니다. 그러나 원문에는 비밀값, 고객 식별자, 첨부 원본, 외부 도구가 돌려준 내용처럼 넓게 열람하면 안 되는 정보가 함께 들어갈 수 있습니다.

반대로 기록을 너무 빨리 없애면 담당자가 “언제 어떤 권한으로 어떤 도구를 실행했는지”를 설명하지 못하고, 같은 실패를 재현할 실마리도 사라집니다. 그래서 필요한 질문은 “얼마나 오래 저장할까?” 하나가 아닙니다. 이 기록은 무엇을 설명하기 위해 필요한가, 누가 실제로 열람해야 하는가, 원문이 아니라 어떤 요약이면 재현 가능한가를 함께 물어야 합니다.

예를 들어 야간 배치 에이전트가 고객 파일을 읽고 외부 도구를 호출한 뒤 실패했다고 가정해 보겠습니다. 다음 날 담당자에게 필요한 것은 모든 대화 문장을 보는 일이 아닐 수 있습니다. 작업 ID, 실행 시각, 사용한 작업 버전, 허용된 권한 범위, 실패한 단계, 도구 응답 코드, 사람 승인 여부가 먼저 필요합니다. 원문은 이 정보만으로 원인을 좁히지 못할 때, 정해진 승인 절차를 거쳐 제한적으로 열람하는 자료가 됩니다.

한 장으로 보는 기록 3분류

기록 3분류는 하나의 세션에서 생긴 자료를 목적에 따라 세 갈래로 나누는 방법입니다. 세 분류는 서로 우열이 아니라, 열람과 삭제의 이유가 다르다는 뜻입니다.

이 표는 특정 서비스의 보존 일수를 권하는 규칙이 아닙니다. 조직마다 계약, 데이터 종류, 내부 승인 절차가 다르므로 날짜를 그대로 가져오기보다 기록의 목적과 접근 책임을 맞추는 데 쓰셔야 합니다.

제품 설정만 보고 정하면 안 되는 이유

에이전트 기록은 로컬 컴퓨터, 공급자 서비스, 연결한 외부 도구, 조직의 관찰 시스템처럼 여러 지점에 남을 수 있습니다. 같은 제품 이름을 쓰더라도 계정 유형, 사용 기능, 관리 설정, 계약 조건에 따라 데이터 흐름이 달라질 수 있습니다.

Anthropic의 Claude Code 데이터 사용 문서는 피드백·버그 신고·공유 경로와 선택적 세션 공유, 로컬 캐시 같은 경로를 구분해 설명합니다. 즉, “세션 기록”이라는 한 단어만으로는 어디에 무엇이 남는지 판단할 수 없습니다. 실제 운영에서는 팀이 어떤 경로를 켜 두었는지와 누가 전송을 승인하는지를 별도로 확인해야 합니다.

API 및 데이터 보존 문서도 기능별·계약별 처리 차이를 설명합니다. 일부 상태 보유 기능이나 별도 관리 기능은 자체 보존 모델을 가질 수 있으며, 특정 조건은 조직 단위 설정과 계약 확인이 필요합니다. 따라서 어떤 표준 용어가 보인다고 해서 모든 세션과 모든 연결 도구에 똑같이 적용된다고 가정하면 안 됩니다.

권한도 함께 보셔야 합니다. Claude Code 보안 문서는 권한 기반 동작과 민감한 작업의 검토 필요성을 설명합니다. 이는 특정 제품의 보안 기능만으로 조직의 책임이 끝난다는 뜻이 아닙니다. 오히려 기록 접근도 실행 권한처럼 “누가, 왜, 얼마나 오래” 필요한지 정해야 한다는 운영 원칙으로 읽는 편이 안전합니다.

5칸 기록 보존 카드 작성법

5칸 기록 보존 카드는 기록 한 종류마다 남기는 짧은 운영 문서입니다. 긴 정책 문서를 기다리지 않아도 팀이 다음 장애부터 같은 기준으로 움직이게 해 줍니다. owner가 비어 있는 기록은 다음 단계로 넘기지 않는 규칙을 권합니다.

카드의 핵심은 “원문 보관”을 기본값으로 적는 일이 아닙니다. 예를 들어 운영 로그에는 요청 ID, 작업 버전, 시작·종료 시각, 성공·실패 상태, 오류 분류, 승인 ID처럼 조사에 필요한 필드를 남기고 원문 입력·출력은 빼는 방식을 먼저 시도해 보세요. 실패 원인이 외부 도구 응답에 있다면 응답 전문 대신 오류 코드, 호출 대상의 종류, 재시도 횟수, 허용된 권한 범위를 남길 수 있습니다.

최소 증적 리허설: 원문 없이 장애를 설명해 보기

카드를 작성했다면 실제로 작동하는지 시험해야 합니다. 최소 증적 리허설은 원문 transcript를 열지 않은 상태에서, 이미 남긴 운영 로그와 감사 증적만으로 사건을 재현·분류할 수 있는지 확인하는 짧은 점검입니다. 원문을 반드시 삭제하라는 시험이 아니라, 원문 접근이 정말 필요한 순간을 줄이기 위한 연습입니다.

1. 최근의 낮은 위험 사건 하나를 고릅니다. 예를 들어 읽기 작업만 수행하다 시간 초과가 난 사례가 적합합니다.
2. 원문 접근을 막습니다. 조사 담당자는 작업 ID, 실행 시각, 배포 버전, 도구 호출 요약, 오류 분류, 승인 기록만 봅니다.
3. 세 가지 질문에 답합니다. 어떤 단계에서 실패했는지, 사용자·외부 시스템에 실제 영향이 있었는지, 누가 다음 조치를 결정하는지 확인합니다.
4. 답이 막힌 지점을 한 줄로 남깁니다. “권한 사용 여부가 없다”, “도구 응답 코드가 없다”처럼 필요한 필드만 보강합니다.
5. 원문 열람이 필요했다면 이유를 기록합니다. 다음에는 원문 전체가 아니라 어떤 범위·마스킹·승인 절차가 필요한지 카드에 반영합니다.

이 방식은 운영 비용도 함께 다룹니다. 매번 긴 원문을 여러 사람이 읽는 방식은 조사 시간이 늘고 민감정보를 볼 사람도 많아집니다. 반대로 최소 증적만으로 1차 분류가 되면, 원문 열람은 정말 복잡한 사건에 한정되고 owner는 더 빨리 복구 결정을 내릴 수 있습니다.

세션이 진행 중일 때 어떤 결과를 최종 기록으로 인정할지도 함께 정리해 두세요. AI 에이전트 스트리밍 미리보기와 최종 기록의 정합성을 먼저 보면, 미완료 표시와 확정된 결과를 같은 증적으로 섞지 않는 기준을 잡는 데 도움이 됩니다.

즉시 멈춰야 하는 실패 조건

다음 신호가 보이면 보존 규칙을 그대로 실행하기보다 owner와 함께 중단·재검토하는 편이 좋습니다.

1. “감사”라는 이유만으로 원문을 무기한 보관합니다. 목적, 열람자, 삭제 조건 없이 남긴 원문은 조사 자료가 아니라 접근 위험이 될 수 있습니다.
2. 제품 기본값을 조직 정책으로 오인합니다. 계정, 기능, 연결 도구, 계약 조건을 확인하지 않은 보존 결정은 실제 흐름과 어긋날 수 있습니다.
3. 원문 접근 권한이 너무 넓습니다. 사건 담당자와 승인 절차가 정해지지 않았다면, 필요한 사람보다 많은 사람이 민감한 내용을 보게 됩니다.
4. 최소 증적 리허설이 반복해서 실패합니다. 이때는 원문을 더 오래 남기는 대신, 막힌 질문에 필요한 구조화 필드를 보강해야 합니다.
5. 외부 도구 출력과 첨부 원본을 무심코 같은 범주에 넣습니다. 생성 위치와 민감도, 삭제 주체가 다른 자료는 같은 정책으로 묶지 마세요.

도입 전에 데이터 수집 범위와 권한을 먼저 정리하고 싶다면 Claude Code 텔레메트리 점검표를, 요청이 어디에서 처리되는지 함께 나누고 싶다면 AI 에이전트 처리 지역 라우팅 계약을 이어서 보셔도 좋습니다.

다음 운영 회의에 가져갈 점검표

자주 묻는 질문

장애 분석 때문에 원문 transcript를 전부 보관해야 하나요?

항상 그렇지는 않습니다. 먼저 원문 없이도 작업 ID, 실행 시각, 버전, 오류 분류, 권한 사용, 승인 기록으로 1차 분류가 가능한지 시험해 보세요. 답이 막히는 지점이 있다면 원문 전체보다 필요한 필드나 제한된 원문 범위를 보강하는 편이 좋습니다.

운영 로그와 감사 증적은 왜 분리해야 하나요?

운영 로그는 시스템 상태와 실패 경로를 빠르게 보는 데 쓰이고, 감사 증적은 누가 어떤 권한과 승인으로 결정했는지 설명하는 데 쓰입니다. 목적과 기본 열람자가 다르므로 같은 원문과 같은 접근 규칙으로 묶으면 둘 다 불편해질 수 있습니다.

원문을 제한 접근으로 올려야 하는 때는 언제인가요?

구조화된 증적만으로 원인을 좁힐 수 없고, 사건 owner가 구체적인 조사 목적과 열람 범위를 설명할 수 있을 때가 적합합니다. 열람 뒤에는 조사 결과와 추가로 필요한 최소 증적을 남기고, 계속 보관할 이유를 다시 판단하세요.

특정 보존·데이터 처리 조건은 어디서 재확인하나요?

현재 사용하는 제품의 공식 문서, 조직 관리 화면, 계약 문서를 함께 확인하세요. 특히 계정 유형, 켜진 기능, 연결한 외부 서비스에 따라 조건이 달라질 수 있으므로, 다른 팀의 설정을 그대로 적용하지 않는 편이 좋습니다.

이 카드는 정책 문서를 대신하나요?

아닙니다. 카드는 현장 운영자가 목적과 책임을 빠르게 맞추기 위한 실행 도구입니다. 법률, 규제, 고객 계약처럼 별도 검토가 필요한 기준은 조직의 보안·법무·책임자와 함께 확인하셔야 합니다.

참고 자료

• Anthropic Claude Code Docs — Data usage: Claude Code의 데이터 사용, 선택적 피드백·공유 경로, 계정·설정별 보존 및 로컬 데이터 흐름을 확인할 수 있습니다.
• Anthropic Claude Platform Docs — API and data retention: 기능과 계약 조건에 따라 달라지는 데이터 보존, ZDR 적용 범위, 상태 보유 기능의 별도 처리 모델을 설명합니다.
• Anthropic Claude Code Docs — Security: 권한 기반 동작, 민감한 작업의 검토, 조직 차원의 안전한 운영 원칙을 확인할 수 있습니다.