관리 화면에 “대화 내용 저장 안 함” 토글을 추가하는 일은 어렵지 않다. 어려운 부분은 그 값이 대화가 지나가는 모든 경로에서 같은 의미를 갖게 하는 것이다.
AI 챗봇의 한 메시지는 모델 문맥, 새로고침 복원, 장기 대화 기록, 품질 통계, 과금 기록, 오류 로그와 첨부 파일에 서로 다른 형태로 나타날 수 있다. 하나의 DB 저장 함수만 건너뛰어서는 “비저장”이라는 사용자 기대를 만족할 수 없다.
먼저 저장 경로를 목록으로 만든다
우리는 대화 관련 데이터를 목적과 수명으로 나눴다.
| 경로 | 목적 | 대화 비저장 시 기준 |
|---|---|---|
| 단기 세션 문맥 | 다음 응답과 새로고침 복원 | 대화 중 일시 사용, TTL과 종료 시 정리 |
| 장기 대화 기록 | 운영자 조회와 요약 | 원문·AI 요약을 남기지 않음 |
| 첨부 객체 | 모델 입력과 결과 표시 | 세션 종료 처리에서 객체 정리 |
| 사용량·과금 기록 | 서비스 운영과 정산 | 별도 최소화·보존 정책 적용 |
| 보안·오류 로그 | 장애와 침해 대응 | 원문 복제를 피하고 별도 정책 적용 |
이 표에서 중요한 점은 “저장”이 하나의 동작이 아니라는 것이다. 메모리에 잠깐 존재하는 것, TTL이 있는 캐시에 쓰는 것과 사용자가 나중에 조회할 영구 기록을 같은 단어로 부르면 설계와 안내가 모두 모호해진다.
실시간 문맥은 즉시 없앨 수 없다
대화형 모델은 이전 turn을 참고해야 한다. 페이지를 새로고침한 위젯도 현재 세션을 이어가야 한다. 그래서 활성 세션의 원문 history는 Valkey에 제한된 시간 동안 남는다.
대화 비저장 옵션은 실시간 처리 자체를 금지하는 기능이 아니다. 세션 중 필요한 문맥은 일시적으로 처리하되, 만료 처리 뒤 장기 원문으로 전환하지 않는 계약이다.
대화 중: Valkey 문맥으로 응답 생성
세션 종료: 영구 저장 정책 확인
├─ 일반 모드 → 요약·대화 기록 생성
└─ 비저장 모드 → 요약 AI 호출 생략, 원문 대신 정책 상태만 기록
마지막: Valkey history와 meta 정리
비저장 모드에서도 세션이 있었다는 최소 상태가 업무상 필요할 수 있다. 이때 원문 대신 “정책에 따라 저장하지 않음”이라는 대체 정보를 남긴다. 빈 배열만 저장하면 데이터가 없었던 것인지 정책으로 지운 것인지 구분하기 어렵다.
요약 AI 호출도 저장 경로다
DB에 원문을 쓰지 않더라도 세션 종료 때 요약 모델을 호출하면 대화 내용이 외부 AI 처리 경로를 한 번 더 지난다. 따라서 비저장 모드에서는 요약 결과만 버리는 것이 아니라 요약 호출 자체를 건너뛴다.
이 구분은 비용에도 영향을 준다. 모델 호출을 한 뒤 결과만 폐기하면 데이터 최소화와 비용 절감 어느 쪽도 달성하지 못한다. 사용량 기록에는 실제 모델을 호출했는지와 원문 요약을 저장했는지를 별도 상태로 표현해야 한다.
첨부는 상태별 위치를 알아야 지울 수 있다
대화 첨부는 업로드 중 임시 저장소에 있을 수도 있고, 분석 준비가 끝나 최종 저장소로 이동했을 수도 있다. 세션 ID만 삭제한다고 객체가 함께 사라지지는 않는다.
종료 worker는 첨부 레코드의 상태와 저장 위치를 보고 해당 객체를 삭제한 뒤 삭제 상태와 시각을 기록한다. 개별 객체 삭제가 실패하면 나머지 첨부 정리를 계속하고, 주기적인 보완 작업이 남은 객체를 다시 확인한다.
이 경로에서 “DB 행 삭제 = 파일 삭제”라고 가정하지 않는 것이 중요하다. 객체 저장소와 transaction DB 사이에는 원자적 transaction이 없다.
사용량 기록은 별도 계약이다
대화 비저장 설정을 모든 로그 삭제와 같은 뜻으로 만들면 과금, 보안과 장애 분석에 필요한 최소 기록까지 사라질 수 있다. 반대로 “운영 로그라서 필요하다”는 이유로 발화 원문을 그대로 남기면 토글의 의미가 약해진다.
그래서 공개 문구도 범위를 정확히 말해야 한다.
- 대화 원문과 요약의 장기 저장 범위를 줄인다.
- 단기 문맥은 서비스 제공을 위해 제한된 시간 처리된다.
- 과금·보안·오류 분석 기록은 별도 보존 정책을 따른다.
- 발화와 식별자 최소화가 필요하면 개인정보 마스킹 정책을 함께 적용한다.
현재 구현에서도 비저장과 개인정보 마스킹은 서로 다른 옵션이다. 비저장 토글 하나가 사용량 기록의 모든 필드를 자동 제거한다고 가정해서는 안 된다. 어떤 필드가 정말 필요한지는 저장소별로 계속 감사해야 한다.
설정 전파 시점도 계약이다
세션 시작 때 읽은 설정을 meta에 넣으면 대화 처리 경로는 단순해진다. 하지만 대화 도중 관리자가 옵션을 바꿨을 때 이미 열린 세션에 언제 적용할지 결정해야 한다.
- 즉시 적용: 매 turn 또는 영구 저장 직전에 설정을 다시 읽는다.
- 다음 세션부터 적용: 세션 시작 값을 끝까지 유지한다.
- 보수적 적용:
false → true전환만 영구 저장 전에 다시 확인한다.
어느 선택이든 UI 안내, cache 무효화와 worker 동작이 일치해야 한다. 현재 세션 meta에 고정되는 값과 영구 처리 직전 재확인하는 값을 구분해 테스트해야 한다.
지금 다시 한다면
토글을 만들기 전에 데이터 유형 × 저장소 × 목적 × 수명 × 삭제 주체 표를 승인할 것이다. 그 표에서 나온 정책을 세션, 요약 worker, BigQuery logger, 첨부 정리와 운영자 조회 테스트에 각각 연결할 것이다.
핵심은 데이터를 전혀 처리하지 않는다는 과장된 문구가 아니다. 실시간 서비스에 필요한 일시 처리와 사용자가 기대하는 장기 비저장을 분리하고, 남는 최소 기록의 목적과 범위를 명시하는 것이다.
Cloudturing에서는
Cloudturing은 사용자가 선택한 대화 비저장 설정을 정확히 반영하기 위해 세션 문맥, 장기 대화 기록, 첨부와 운영 기록의 저장 경계를 나누고 있다. 실시간 응답에 필요한 일시 처리와 장기 보존을 구분하고, 남겨야 하는 최소 기록도 목적별 정책으로 관리한다.