AI 깊이 이해하기 · 15편 | 기억의 출처, 적용 범위, 충돌과 무효화
어제 남긴 메모에는 “다운로드 링크는 30일 동안 유효하다”고 적혀 있다. 오늘 읽은 공식 문서에는 “오늘부터 새로 만든 링크는 7일 동안 유효하다”고 쓰여 있다. 공개 문서의 변경 사항을 보고하는 Agent가 보고서에 다시 30일을 적었다면, 원문을 찾지 못한 문제만 살펴봐서는 원인을 놓친다. 새 문서를 읽고도 예전 요약을 더 강한 근거로 사용했을 수 있다.
설명을 위해 만든 가상 장면이다. 실제 서비스 정책이나 실행 결과가 아니다. 이번 편에서는 저장된 기억이 새로운 증거와 부딪힐 때 무엇을 현재 판단에 사용할지 정한다. Memory와 Session을 구분한 입문 글에서 한 걸음 더 나아가, 이미 저장된 기억을 고치고 사용 범위를 제한하는 문제를 다룬다.
1. 잘 검색된 기억도 현재 답을 틀리게 만들 수 있다
“다운로드 링크의 유효기간”이라는 질문에는 30일이라고 적힌 옛 메모가 아주 잘 맞는다. 문장에 같은 대상과 속성이 등장한다. 검색 결과가 관련성이 높다는 판단은 자연스럽다. 그러나 그 점수에는 이 정책이 오늘도 적용되는지, 어떤 상품에 해당하는지, 원문을 정확히 요약했는지에 대한 판정이 들어 있지 않다.
LangChain은 의미 기억과 의미 검색을 구별한다. 의미 검색은 내용의 의미를 바탕으로 관련 항목을 찾는 방법이다. LangGraph의 Store도 이 검색을 지원한다. 여기서 설계상 중요한 결론은 검색 순위와 사실 채택을 별도 단계로 두는 것이다. 검색은 읽어볼 후보를 좁히고, 채택 단계는 출처와 조건을 확인한다. LangChain Memory 개요, LangGraph Stores에서 두 기능의 설명을 확인할 수 있다.
또한 오래된 기억이라고 모두 틀린 것은 아니다. “10월 4일에 확인한 문서는 30일이라고 안내했다”는 과거 사실과 “지금 만드는 링크도 30일 유효하다”는 현재 주장은 다르다. 변경 보고서에는 과거 자료가 반드시 필요하다. 문제는 비교 기준으로 보존한 자료가 현재 규칙으로 승격되는 순간에 생긴다.
2. 문장과 함께 남겨야 할 적용 조건
교육용 Agent에서는 기억 한 건을 문장 하나보다 작은 주장과 그 근거의 묶음으로 다룰 수 있다. 예를 들어 “다운로드 링크는 30일 유효하다”라는 주장에는 다음 정보가 따라붙는다. 아래 필드는 이 글의 설계 제안이며 특정 SDK의 표준 스키마가 아니다.
- 대상과 범위: 어떤 서비스, 상품, 문서 언어판, 기능에 관한 주장인지 기록한다. 이름이 같은 다른 상품의 정책을 섞지 않는다.
- 출처와 근거: 원문 주소, 문서 버전, 해당 절이나 문장 위치를 남긴다. 직접 읽은 사실인지, 원문에서 만든 요약인지, 추론인지도 구별한다.
- 관측 시각: Agent가 그 근거를 확보한 시각이다. 원문이 작성되거나 수정된 시각과 분리한다.
- 적용 조건: 시행일과 종료일, 대상 상품, 예외 조건을 기록한다. 조건을 찾지 못했다면 빈칸을 무기한 유효로 해석하지 않는다.
- 현재 사용 상태: 현재 판단 후보, 과거 비교용, 충돌 확인 중, 재확인 필요처럼 용도를 구분한다.
- 다른 기억과의 관계: 무엇에서 요약됐는지, 어느 주장을 어떤 범위에서 대체하는지 연결한다.
특히 시각을 하나로 합치지 않아야 한다. 저장소의 updated_at이 방금으로 바뀌었어도 원문은 어제 읽은 그대로일 수 있다. LangGraph 문서의 created_at과 updated_at은 기억 항목의 생성·수정 시각이다. 애플리케이션은 여기에 원문 관측 시각과 업무상 적용 시점을 따로 담아야 한다. LangGraph Stores의 항목 속성
이 차이를 놓치면 요약을 매일 다시 쓰는 작업이 낡은 근거에 새 날짜를 붙이는 작업이 된다. “오늘 갱신된 기억”이 어느 날의 문서를 설명하는지 역으로 따라갈 수 있어야 한다.
3. 30일과 7일이 함께 맞는 가상 사례
앞의 예를 조금 더 구체적으로 놓자. 아래 날짜와 정책은 모두 설명용이다. Agent의 작업은 가상 서비스의 공개 안내문에서 바뀐 내용을 찾아 로컬 변경 보고서 초안을 만드는 것이다.
10월 4일에 읽은 기본형 상품 안내문은 다운로드 링크의 유효기간을 30일로 설명한다. Agent는 원문 버전 A를 보관하고, 그 내용을 요약한 기억 M1을 만든다. 10월 5일에 같은 안내문의 버전 B를 읽는다. B에는 “10월 5일 이후 기본형에서 새로 생성한 링크는 7일 유효하며, 이전에 생성한 링크는 기존 30일 조건을 유지한다”고 적혀 있다.
이때 M1을 통째로 지우고 “모든 링크는 7일”로 바꾸면 새로운 오류가 생긴다. 새 문서는 적용 시점을 나누고 있다. Agent가 해야 할 정리는 다음과 같다.
- 버전 A와 B가 같은 상품과 같은 안내 항목을 설명하는지 확인한다. 기업형 안내문이라면 기본형 기억을 대체할 근거가 되지 않는다.
- M1의 “30일”을 과거 문서의 설명과 이전 생성 링크에 적용되는 조건으로 구분한다. M1에는 미래 링크의 조건까지 단정할 근거가 없다.
- B에서 새 주장 M2를 만든다. 대상은 기본형의 10월 5일 이후 신규 링크, 값은 7일, 근거는 B의 해당 절이다.
- M1과 M2 사이에 대체 범위를 남긴다. 신규 링크의 현재 설명에서는 M2를 사용하고, 문서 변경 전후 비교에서는 M1의 근거를 유지한다. 기존 링크를 현재 시점에서 설명할 때도 B의 예외 조항을 근거로 연결한다.
이 입력 조건에서 기대하는 보고 문장은 “기본형 신규 다운로드 링크의 유효기간이 10월 5일부터 30일에서 7일로 바뀌었다. 이전 생성 링크에는 기존 조건이 유지된다”가 된다. 두 버전의 출처와 관측 시각도 함께 남긴다. 이는 설계상 기대 출력이며, 실제 Agent를 실행해 얻은 결과는 아니다.
바뀐 숫자만 추출하면 예외가 사라진다. 기억의 최소 단위는 이 사례에서 “30일”이나 “7일”이 아니라 대상, 생성 시점, 유효기간을 함께 담은 조건부 주장이다.
4. 최신 날짜가 충돌을 자동으로 해결하지는 않는다
같은 대상에 관한 기억이 둘 이상 나오면 먼저 무엇이 충돌하는지 좁혀야 한다. 상품이나 적용 기간이 다르면 공존할 수 있다. 범위와 기간이 겹치는데 값이 다를 때 실제 충돌 후보가 된다. 그다음 출처의 권위, 원문 버전, 명시된 변경 관계를 확인한다.
오늘 만든 개인 요약이 어제 공개된 공식 문서보다 새로운 정책인 것은 아니다. 새 요약이 오래된 A만 읽고 작성됐을 수도 있다. 반대로 날짜가 더 최근인 공식 페이지라도 미리보기 상품의 안내라면 일반 제공 상품에 바로 적용할 수 없다. “가장 최근 항목을 선택한다”는 규칙만으로는 이 구분이 되지 않는다.
검색 범위도 중요하다. 의미 검색의 상위 몇 건에 M1만 나왔다고 해서 반대 증거가 없다고 결론 내려서는 안 된다. 현재 규칙을 확정하기 전에는 같은 대상·속성의 기록을 식별자로 찾아 충돌 여부를 확인하는 경로를 둘 수 있다. 기록이 많다면 페이지를 나눠 조회하거나 별도의 현재 주장 목록을 관리한다. 어떤 경우든 목록의 갱신 상태를 확인해야 한다.
그래도 같은 범위의 공식 자료가 서로 다른 값을 말하고 변경 관계를 확인할 수 없다면, 보고서에는 충돌을 남긴다. “현재 적용 조건 미확인”으로 표시하고 필요한 원문 확인을 진행한다. 모델에게 둘 중 더 그럴듯한 문장을 고르라고 맡기면 불확실성이 문장 뒤로 숨는다.
5. 원래 기억을 고친 뒤에도 남는 사본
M1을 수정했는데 다음 보고서에서 다시 30일이 나올 수 있다. 이전 보고서 요약, 검색 색인의 조각, 진행 중인 실행의 Context에 M1의 사본이 남아 있기 때문이다. 14편에서 다룬 의존성 검사를 기억의 갱신에도 연결해야 하는 이유다. 어떤 파생 기록이 이 근거를 사용했는지 알아야 한다.
교육용 설계에서는 M1의 버전을 바꾸거나 현재 사용 상태를 해제할 때, 이를 참조하는 요약을 재검토 대상으로 표시한다. 색인에서 옛 조각이 검색되더라도 Context에 넣기 직전에 원래 기록의 상태와 버전을 대조한다. 진행 중인 보고서가 M1에 의존했다면 해당 문장을 다시 확인한다. 과거 보고서를 몰래 새 사실로 덮어쓰는 대신, 정정이나 후속 보고서가 필요한지 작업 계약에 따라 정한다.
느리게 끝난 요약 작업도 주의 대상이다. B를 반영한 M2가 저장된 뒤, A를 읽었던 작업이 뒤늦게 M1을 현재 기억으로 기록할 수 있다. 이때 확인할 것은 작업 종료 시각보다 입력 근거의 버전이다. 현재 기록의 revision과 근거를 확인하는 조건부 갱신이 필요하며, 충돌하면 새 기록을 다시 읽어야 한다. 앞서 상태 전이에서 다룬 갱신 보호를 기억에도 적용하는 셈이다.
보관 기한도 구별해야 한다. 저장 공간에서 지울 날짜, 다시 확인할 날짜, 정책이 실제로 적용되는 기간은 서로 다른 값이다. HTTP 캐시 표준 역시 신선도와 재검증을 나눠 다루지만, 응답을 재사용할 수 있다는 판단이 요약의 의미와 적용 조건까지 검증해주지는 않는다. RFC 9111의 신선도와 재검증을 참고하되, 기억의 유효성은 별도로 설계해야 한다.
6. 확인할 것은 저장 성공 이후의 판단
기억 저장 호출이 성공했는지만 확인하면 이 문제들을 찾기 어렵다. 새 근거를 읽은 다음 실제로 어떤 주장을 선택했고, 어떤 기억을 제외했는지 확인해야 한다. 다음은 이 글의 가상 Agent에 적용할 검증 사례다. 실행 결과나 성능 수치가 아니라 앞으로 확인할 기준이다.
- 상위 검색 결과가 낡은 경우: M1의 검색 순위를 높여도 신규 링크 보고서에 30일이 현재 조건으로 들어가지 않아야 한다.
- 조건이 다른 경우: 기업형의 더 최근 문서를 넣어도 기본형의 규칙이 바뀌지 않아야 한다.
- 과거를 묻는 경우: 10월 4일 문서의 설명을 물으면 A와 당시 조건을 복원할 수 있어야 한다.
- 충돌을 해결할 수 없는 경우: 겹치는 공식 설명에 근거 없는 우선순위를 주지 않고, 확인되지 않은 범위를 표시해야 한다.
- 옛 사본이나 늦은 쓰기가 돌아오는 경우: M1을 사용 중지한 뒤에도 파생 요약과 지연된 작업이 이를 현재 주장으로 되살리지 않아야 한다.
- 원문을 다시 읽지 못한 경우: 읽기 실패를 “변경 없음”으로 바꾸거나, 과거 관측 시각을 현재로 갱신하지 않아야 한다.
각 사례의 기록에는 질문, 후보 기억의 식별자와 버전, 채택·제외 이유, 사용한 원문, 최종 보고 문장을 남긴다. 그래야 오류가 검색 누락인지, 범위 판정인지, 요약 과정의 조건 손실인지 구별할 수 있다. 이 사례들을 통과하더라도 모든 문서나 실제 운영 환경에서 안전하다고 일반화할 수는 없다.
출발점은 작아도 된다. 현재 보고서의 핵심 주장 하나를 골라 원문까지 거슬러 올라가 본다. 그 원문이 바뀌면 어떤 기억과 문장을 다시 검토해야 하는지도 적는다. 30일이라는 옛 기록을 보존하면서 오늘의 신규 링크에는 7일을 적용할 수 있다면, 기억이 과거와 현재를 구분하는 데 실제로 쓰이고 있는 것이다.
이어 읽기: Memory와 Session의 차이 · 12편: 부분 관측과 읽기 증거. 다음 16편에서는 읽기와 저장 도구가 어떤 입력·결과·실패를 약속해야 하는지 Tool 계약으로 이어간다.
자료 확인일: 2026-10-05. 공식 참고 자료는 본문에 연결했다. 사례의 서비스, 정책, 날짜별 변경, 기억 식별자와 처리 규칙은 교육용으로 구성했다. 실제 운영 사례, 제품 사용 후기, Agent 실행·장애 시험 또는 모델 성능 검증 결과가 아니다. 프레임워크의 저장 기능과 이 글이 제안하는 사실 채택 정책은 구분해 읽어야 한다.