상주형 AI 챗 에이전트가 다루는 로그의 '보존 기간 및 삭제' 설계

챗에 상주하며 대화, 첨부 파일, 요약 결과를 축적해 나가는 타입의 AI 에이전트는 사용할수록 '과거를 기억해서 편리하다'는 장점이 있는 반면, 그 이면에서는 계약 금액, 인사 정보, 거래처명 등 기밀을 포함한 원본 로그가 어딘가에 쌓여갑니다. 본 글에서는 상주형 에이전트가 가진 챗 로그, 첨부 파일, 벡터화된 요약 데이터를 '언제까지 보관할지', '삭제하라고 했을 때 어디까지 지워지는지'라는 보존 기간 및 삭제 설계를 어떻게 구성해야 하는지를 정리합니다.

왜 '계속 남겨두는 것'은 사고를 유발하는가

장기 기억이나 과거 요약 검색은 상주형 에이전트의 가치 중 하나이지만, 보존 기간 설계에 소홀하면 다음과 같은 사고로 이어질 수 있습니다.

• 퇴사자 또는 계약 종료한 거래처와의 대화가 본래 업무 목적을 마친 후에도 계속 검색 가능한 상태로 남아 있는 경우
• '이 메시지를 삭제해 달라'고 요청했음에도 불구하고, 원본 로그는 지워졌지만 벡터 DB나 요약 캐시에는 동일 내용이 남아 있어 검색 결과에 나타나는 경우
• 백업, 로그 기반 시설(ログ基盤), LLM 호출의 캐시 등 저장소가 여러 곳에 분산되어 있기 때문에, 삭제했다고 생각해도 잔존 데이터가 발생하는 경우

즉, '보존 기간을 어떻게 정할지'와 '삭제 요청이 왔을 때 모든 저장소에서 정말 지울 수 있는지'는 별개의 설계 문제로, 처음부터 나누어 생각해야 합니다.

패턴 1: 데이터 종류별로 보존 기간을 분리하기

챗 로그를 한 가지로 취급하지 않고 용도별로 보존 기간의 기본값을 나누어 두면 운영이 간단해집니다.

패턴 2: 삭제 요청은 '논리적 삭제'가 아닌 '저장소 파악'부터 시작하기

삭제 요청에 대한 대응을 한 곳의 플래그 업데이트(논리적 삭제)로 끝내버리면, 검색 인덱스나 캐시, 백업에는 실체가 계속 남아있습니다. 삭제 흐름을 구성할 때는 먼저 대상 데이터가 물리적으로 어디에 존재할 수 있는지 파악하는 것부터 시작해야 합니다.

type RetentionTarget = {
store: 

• 생로그(Raw Log), 요약본, 임베딩, 감사 로그를 하나의 덩어리로 다루지 않고, 종류별로 보존 기간의 기본값을 분리한다
• 삭제 요청에 대응할 때 논리적 삭제에서 끝내지 않고, 저장 위치를 모두 파악한 후 물리적 삭제 및 삭제 예약을 분배한다
• 벡터 DB의 임베딩은 원본 텍스트와 다른 생명주기를 가지며 남아있기 쉬우므로, 삭제 플로우에 명시적으로 포함시킨다
• 보존 기한(TTL)은 나중에 추가하는 것이 아니라, 로그 저장 스키마에 처음부터 갖추어 놓는다

상주형 에이전트(Resident Agent)는 대화를 기억할수록 편리해지지만, 그 편리함은 '언제든지 지울 수 있다'는 설계와 함께하지 않으면 장기적으로 기밀 정보가 축적되는 위험으로 쌓여갑니다.

필자는 Slack / Teams / Chatwork / LINE WORKS에 상주하며 추론 시 기밀 정보 마스킹과 AWS 내부 완결 구성으로 운영하는 AI 에이전트 HACH를 개발하고 있으며, 로그의 보존 기간 및 삭제 설계 역시 안심하고 사용하실 수 있도록 하는 지엽적이지만 중요한 관점이라고 생각합니다.

### Discussion
![](https://static.zenn.studio/images/drawing/discussion.png)