🧑🏻💻 Ep.30 | 기억하는 AI와 잊어야 하는 데이터
고객이 배송 문의를 다시 시작했습니다. AI는 “지난번처럼 화요일 오후로 바꿔드릴까요?”라고 물었어요. 주문 번호를 다시 말하지 않아도 되니 꽤 편리해 보였습니다.
그런데 고객이 이어서 물었습니다.
“지난번에 가족 병원 일정 때문에 미뤘다는 것도 저장돼 있나요?”
팀 채널이 잠시 조용해졌습니다. 배송 선호 시간을 기억하자는 기능이었는데, 대화를 요약하는 과정에서 그 이유까지 장기 메모에 들어가 있었거든요.
기억은 사용자의 수고를 줄여줍니다. 무엇을 잊어야 하는지 정하지 않으면, 편리함이 곧 불안함이 됩니다.
※ 이 글의 고객 대화와 삭제 흐름은 여러 데이터 운영 패턴을 합성한 가상 사례입니다.
1. “기억”이라는 한 단어를 쪼개본다
대화형 제품에서는 여러 데이터가 모두 기억처럼 보입니다. 하지만 쓰임과 수명이 다릅니다.
지금 대화에서 주문을 이어가기 위한 주문 번호는 세션 상태입니다. 배송 변경 결과는 분쟁과 운영을 위해 남겨야 할 업무 기록일 수 있습니다. 사용자가 직접 고른 알림 시간은 프로필 설정입니다. “가족 병원 일정이 있다”는 문장은 모델이 대화에서 추려낸 요약이고요.
이 네 가지를 같은 저장소에 같은 기간 보관하면 문제가 생깁니다. 현재 대화에만 필요했던 말이 영구 프로필이 되고, 모델의 추측이 사용자 사실처럼 다음 답변에 쓰일 수 있습니다.
먼저 이름을 나누면 질문도 달라집니다. 누가 만들었는지, 왜 필요한지, 얼마나 보관할지, 사용자가 보고 고칠 수 있는지 각각 답할 수 있게 됩니다.
2. 저장하기 전에 다음 사용 장면을 말해본다
“나중에 개인화에 쓸 수 있다”는 이유는 너무 넓습니다. 나중이 언제인지, 어떤 화면에서 어떤 이익을 주는지 알 수 없으니까요.
배송 선호 시간은 다음 주문 때 선택 단계를 줄여줄 수 있습니다. 언어 설정은 고객센터 답변을 읽기 쉽게 합니다. 반면 가족의 병원 일정은 다음 배송을 추천하는 데 꼭 필요하지 않습니다. 민감한 사정을 저장해 얻는 이익보다 오해와 노출 위험이 큽니다.
그래서 필드마다 한 문장을 적어봅니다.
“예를 들어 이 정보는 다음 주문에서 배송 시간을 먼저 제안하기 위해 90일 동안 보관한다.”
여기서 90일은 보편적인 정답이 아니라 제품 목적과 정책에 따라 정해야 할 예시입니다. 문장을 쓰기 어렵다면 저장 이유가 아직 약한 겁니다. 정한 기간이 끝나면 자동으로 지우고, 다시 필요하면 새 동의를 받습니다.
💡 저장하지 않은 데이터는 유출되지도, 낡은 사실로 사용되지도 않습니다.
3. 동의는 켜고 끄는 경험이어야 한다
가입할 때 긴 약관 아래 체크박스 하나를 두는 것만으로 사용자가 ‘기억’을 이해했다고 보기 어렵습니다.
AI가 처음으로 장기 기억을 만들려는 순간, 무엇을 왜 저장할지 짧게 보여주는 편이 낫습니다. 설정에서는 저장된 내용을 직접 보고, 틀리면 고치고, 더는 원하지 않으면 끌 수 있어야 하고요.
업무상 반드시 남겨야 하는 기록과 선택적인 개인화도 구분합니다. 환불 처리 이력은 법적·운영상 보관이 필요할 수 있지만, 선호 말투나 배송 시간 기억은 거절해도 핵심 서비스를 쓸 수 있어야 합니다.
사용자가 기억 기능을 끈 뒤에도 새 요약이 계속 생성된다면 UI의 선택은 거짓말입니다. 동의 상태가 수집, 요약, 검색, 답변 생성의 모든 단계에 실제로 전달되는지 확인해야 합니다.
4. “지워주세요”가 도착한 날
고객이 가족 일정에 대한 기록을 삭제해달라고 요청했습니다. 운영자가 프로필 테이블의 한 줄을 지웠고, 처리 완료라고 답하려던 순간 누군가 물었습니다.
“검색 인덱스에 만든 벡터는요?”
확인해보니 원문 대화, 장기 요약, 검색용 벡터, 품질 분석용 데이터셋, 백업에 같은 내용이 다른 형태로 남아 있었습니다. 한 필드를 지우는 것으로 끝나는 구조가 아니었어요.
삭제 경로를 데이터 흐름과 함께 그려야 합니다.
1️⃣ 원본 대화에서 대상 범위를 찾는다.
2️⃣ 그 대화로 만든 요약과 프로필 값을 지운다.
3️⃣ 검색 인덱스와 캐시의 파생 데이터를 무효화한다.
4️⃣ 분석·평가 데이터에 들어갔다면 승인된 정책에 따라 제거하거나 비식별화한다.
5️⃣ 외부 모델 제공자와 백업의 보존 조건을 확인한다.
삭제는 한 번의
DELETE 쿼리가 아니라 여러 시스템을 지나는 작업입니다. 일부 단계가 실패하면 완료라고 말하지 않고 재시도 상태와 처리 기한을 남겨야 합니다.5. 감사 기록에도 모든 내용을 남길 필요는 없다
삭제가 제대로 됐는지 증명하려면 로그가 필요합니다. 여기서 역설이 생깁니다. 지웠다는 증거를 남긴다며 삭제 대상의 원문을 로그에 다시 복사할 수 있기 때문입니다.
감사 기록에는 누가 언제 어떤 범주의 데이터를 어떤 요청 ID로 처리했는지, 각 시스템의 결과가 어땠는지를 남깁니다. 가족 일정 같은 실제 내용까지 적을 이유는 없습니다. 접근 권한과 보존 기간도 일반 애플리케이션 로그와 다르게 봐야 하고요.
장애 재현을 위해 대화를 무기한 쌓아두는 습관도 점검합니다. 필요한 최소 표본과 기간을 정하고, 민감한 값은 가리며, 목적이 끝나면 정리합니다. 디버깅 편의를 사용자의 영구 보존 동의로 바꿔서는 안 됩니다.
외부 모델 API의 보존 정책은 별도입니다. 우리 DB에서 지웠다고 외부 처리 기록까지 사라진다고 추정하지 않습니다. 계약과 설정, 실제 데이터 흐름을 확인해야 합니다.
6. 기억도 틀리고 낡는다
사용자가 한때 화요일 배송을 선호했다고 해서 계속 그럴까요. 이사를 했거나 근무 일정이 바뀌었을 수 있습니다. 모델이 “저녁 배송 선호”라고 요약했지만, 사실은 그날 한 번만 부탁한 것일 수도 있고요.
기억에는 출처와 생성 시각, 확실한 사실인지 모델의 요약인지가 함께 있어야 합니다. 오래된 값은 다시 확인하고, 사용자의 현재 말이 과거 요약보다 우선해야 합니다. 충돌하면 몰래 덮어쓰기보다 “선호 시간이 바뀌었나요?”라고 묻는 편이 낫습니다.
7. 기억의 품질은 정확도만이 아니다
품질 지표도 정확도만 보지 않습니다. 저장된 기억이 실제로 단계를 줄였는지, 사용자가 얼마나 자주 수정·삭제하는지, 불필요한 정보가 답변에 튀어나오지는 않는지 봅니다.
✅ 잘 기억하는 AI는 많은 것을 오래 저장하는 AI가 아닙니다. 필요한 정보를 이유가 있는 동안만 간직하고, 사용자가 원할 때 그 흔적까지 따라가며 잊을 수 있는 AI입니다.
가족 일정이 남았던 사건 뒤 팀은 장기 요약을 더 똑똑하게 만드는 대신, 저장 대상을 먼저 줄였습니다. 개인화는 조금 덜 놀라워졌지만 사용자가 이해하고 통제할 수 있는 기능이 됐습니다. 그쪽이 오래 쓸 수 있는 기억에 더 가까웠습니다.
🌱 데이터의 수명까지 설계하는 개발자들이 모인 곳, 루퍼스
데이터를 잘 쓰는 일에는 잘 지우는 일도 포함됩니다. 개인정보와 제품 경험 사이의 현실적인 경계를 함께 고민하고 싶다면 루퍼스에서 시작해보세요 🙌
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 800+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
📢 LOOPERS의 소식이 궁금하다면?
Share article