AI의 활성 메모리와 지속 메모리: AI는 어떻게 기억하고, 검색하고, 잊는가

활성 메모리는 AI 시스템이 현재 처리 중인 작업에 사용할 수 있는 정보입니다. 지속 메모리는 주변 애플리케이션이 나중에 다시 사용할 수 있도록 보존하는 정보입니다. 이 둘의 관계에 따라 어시스턴트가 프로젝트를 이어서 진행하거나, 선호 사항을 적용하거나, 오래된 가정을 바로잡거나, 잊었어야 할 내용을 다시 끄집어내지 않을 수 있는지가 결정됩니다.

연구 보고서 작성을 도와주는 어시스턴트를 생각해 보세요. 한 대화 중에는 개요와 가장 최근에 수정한 내용, 방금 제공한 자료를 참조할 수 있습니다. 일주일 뒤 별도의 대화를 시작했을 때도 대화의 연속성이 유지되는지는 다른 메커니즘에 달려 있습니다. 애플리케이션이 관련 정보를 저장했는지, 그 정보를 찾을 수 있는지, 그리고 다시 모델에 제공하는지가 관건입니다.

그래서 AI는 같은 대화에서 한 가지 세부 사항은 기억하는 듯하면서도 다른 내용은 잊어버릴 수 있습니다. 기억은 여러 작업이 연결된 과정입니다. 정보를 수집하거나 저장하거나 검색하거나 선택하거나 해석하거나 갱신하는 단계에서 문제가 생길 수 있습니다.

이 가이드에서는 이러한 과정을 자세히 살펴봅니다. 일화 기억, 의미 기억, 절차 기억을 아우르는 더 폭넓은 분류 체계는 AI 에이전트 메모리 유형 소개 글을 참고하세요. 여기서는 현재 활성화된 정보와 현재 작업이 끝난 뒤에도 유지될 수 있는 정보의 경계에 초점을 맞춥니다.

활성 메모리와 지속 메모리는 정확히 무엇을 의미할까요?

이 용어들은 아키텍처를 이해하는 데 유용한 구분을 나타내지만, 보편적으로 표준화된 한 쌍의 개념은 아닙니다. 제품 인터페이스와 연구 논문에서는 ‘작업 메모리’, ‘단기 메모리’, ‘컨텍스트’, ‘상태’, ‘장기 메모리’를 서로 겹치는 의미로 사용합니다. 따라서 정확히 설명하려면 먼저 용어의 의미를 정의해야 합니다.

이 글에서 활성 컨텍스트란 현재 응답을 위해 모델에 제공되는 정보, 즉 지시, 메시지, 선택된 도구 출력, 검색된 자료와 모델이 처리할 수 있는 기타 입력을 의미합니다. 활성 작업 상태는 이보다 더 넓은 개념입니다. 여기에는 계획이나 체크리스트, 또는 애플리케이션이 관리하지만 아직 모델의 컨텍스트에 넣지 않은 변수가 포함될 수 있습니다. 이 글에서는 현재 작업 집합을 실용적으로 포괄하는 용어로 ‘활성 메모리’를 사용하되, 필요한 경우 두 개념을 구분합니다.

지속 메모리란 응답이나 세션이 끝난 뒤에도 남아 나중에 사용할 수 있는 정보를 의미합니다. 저장된 선호 사항이나 프로젝트 메모, 이벤트 기록, 구조화된 데이터베이스 필드일 수도 있고, 미완료 작업을 재개할 수 있게 하는 체크포인트일 수도 있습니다. 지속성은 정보가 보존된다는 뜻이지, 모든 대화에서 그 정보를 공유할 수 있다는 뜻은 아닙니다.

따라서 서로 다른 질문 두 가지를 살펴봐야 합니다. 정보가 여전히 존재하는가? 그리고 모델이 필요할 때 그 정보를 받게 되는가? 저장된 대화 기록은 첫 번째 질문에는 답할 수 있지만, 두 번째 문제까지 해결해 주지는 않습니다.

중요한 예외: 단기 상태도 저장할 수 있습니다

‘단기’라고 해서 항상 ‘휘발성 RAM에만 저장된다’는 뜻은 아닙니다. 대화의 작업 상태를 데이터베이스에 체크포인트로 저장하면 중단 후에도 작업을 재개할 수 있습니다. 예를 들어 LangChain의 메모리 문서에서는 체크포인트를 통해 지속되는 스레드 범위 상태와 별도의 네임스페이스로 구성된 장기 메모리를 구분합니다.

고객이 영수증을 업로드하기를 기다리느라 업무를 잠시 멈춘 고객 지원 에이전트를 떠올려 보세요. 저장된 체크포인트는 해당 지원 건에 속합니다. 체크포인트는 지속적으로 보존되지만, 고객에 관한 일반적인 사실로 자동 전환되거나 관련 없는 요청에 나타나서는 안 됩니다.

어떤 메모리 기능이든 평가할 때는 세 가지 차원을 살펴보면 유용합니다. 즉, 유지 기간, 범위, 현재 모델 호출에서의 이용 가능성입니다. ‘장기’와 같은 명칭만으로는 이 질문에 어느 하나도 완전히 답할 수 없습니다.

활성 메모리와 지속 메모리 한눈에 보기

같은 사실이 두 열에 모두 나타날 수 있습니다. 저장된 프로젝트 선호 사항은 지속 메모리이고, 오늘 프롬프트에 삽입된 사본은 활성 메모리입니다. 프롬프트에서 그 사본을 제거해도 저장된 원본까지 반드시 삭제되는 것은 아닙니다.

AI의 단일 응답이 생성되는 동안에는 어떤 일이 일어날까요?

일반적인 언어 모델 애플리케이션에서는 주변 소프트웨어가 입력을 구성하고, 모델이 출력을 생성하며, 소프트웨어가 다음에 일어날 일을 결정합니다. 입력에는 대화에서 보이는 내용이 포함될 수 있지만, 시스템 지침, 도구 설명, 검색된 메모, 사용자가 채팅 기록에서 볼 수 없는 정보도 들어갈 수 있습니다.

이렇게 구성된 컨텍스트는 모델이 당장 활용하는 근거입니다. 이전 메시지가 더 이상 포함되지 않는다면, 애플리케이션이 한때 그 메시지를 표시했다는 이유만으로 모델이 그 정확한 내용을 신뢰성 있게 복원할 수는 없습니다. 주변 단서로 그럴듯한 답을 추론할 수는 있지만, 추론은 회상과 다릅니다.

도구를 사용하면 시스템이 접근할 수 있는 범위가 넓어집니다. 모델은 프로젝트 파일을 요청해 그 내용을 전달받고, 이후 응답에서 활용할 수 있습니다. 파일은 모델이 활용할 근거가 되기 전부터 애플리케이션에서 이용할 수 있었습니다. 이러한 차이를 보면 에이전트가 매번 전체 자료를 읽지 않고도 방대한 아카이브에 접근할 수 있는 이유를 알 수 있습니다.

트랜스포머 구현은 내부적으로 계산 상태도 유지하며, 여기에는 같은 작업의 반복을 피하기 위해 사용하는 캐시가 포함됩니다. 이러한 메커니즘은 추론 효율을 높이는 데 유용하지만, 편집할 수 있고 권한을 고려하는 사용자 선호 사항이나 프로젝트 이력 기록과 혼동해서는 안 됩니다. 응답 속도가 빨라졌다고 해서 개인 메모리가 생성되었다고 볼 수는 없습니다.

컨텍스트 창을 늘려도 메모리 문제가 해결되지 않는 이유

컨텍스트 창이 크면 애플리케이션이 한 번에 더 많은 자료를 제공할 수 있습니다. 긴 문서나 여러 관련 자료에 걸친 관계를 바탕으로 답해야 할 때 유용할 수 있습니다. 하지만 어떤 자료를 보존할 가치가 있는지, 어느 버전이 기준이 되는지, 사용자가 해당 자료에 접근해도 되는지는 컨텍스트 창의 크기가 결정하지 않습니다.

정보를 컨텍스트 창에 넣을 수 있다고 해서 모델이 그 정보를 반드시 올바르게 활용하는 것도 아닙니다. 중간에서 놓치기 연구에서는 시험 대상 모델이 긴 입력에서 관련 근거가 제시된 위치에 따라 서로 다른 성능을 보일 수 있음을 확인했습니다. 이 결과는 광고된 용량을 회상의 보장으로 간주하기보다 컨텍스트를 실제로 얼마나 효과적으로 활용하는지 평가해야 한다는 점을 일깨웁니다. 다만 모든 최신 모델의 성능을 고정적으로 예측하는 결과는 아닙니다.

프로젝트 아카이브에 출시일에 관한 논의가 40건 있다고 가정해 보겠습니다. 그중 39건은 처음 정한 날짜를 언급하고, 마지막으로 승인된 변경 사항에서는 날짜를 옮겼습니다. 40건의 논의를 모두 제공하면 읽는 데 따르는 부담과 어떤 정보가 우선하는지를 판단하는 문제가 생깁니다. 승인된 변경 사항을 연결해 현재 상태를 세심하게 관리한 기록이 있으면 관련 답변을 더 쉽게 확인할 수 있습니다.

따라서 긴 컨텍스트와 선별적 검색은 서로 보완할 수 있습니다. 검색을 통해 유용한 근거 자료를 찾고, 충분히 큰 컨텍스트를 활용하면 모델이 그 근거를 함께 살펴볼 수 있습니다. 어떤 방식을 선택할지는 작업의 성격, 원자료의 양, 단서를 놓쳤을 때 따르는 결과에 따라 달라집니다.

정보는 어떻게 지속 메모리가 되는가

오래 유지되는 메모리는 저장 여부를 결정하는 것에서 시작됩니다. 애플리케이션은 사용자가 명시적으로 내린 지침을 저장하거나, 대화에서 후보 사실을 도출하거나, 사건을 보존하거나, 요약을 만들 수 있습니다. 각 방식으로 생성되는 근거의 유형은 서로 다릅니다.

“Project Cedar에서는 미터법 단위를 사용하세요”는 명시적인 프로젝트 선호 사항입니다. “사용자는 미터법 단위를 선호하는 것 같다”는 추론입니다. “최근 Cedar 보고서 세 건에서 미터법 단위를 사용했다”는 관찰입니다. 유용한 기록은 이러한 차이를 보존하며, 이를 향후 모든 작업에 적용되는 단정적인 주장 하나로 뭉뚱그리지 않습니다.

유용한 기록에는 무엇이 담기는가

가상의 프로젝트 도우미를 예로 들면, 기록에는 진술 내용, 프로젝트 식별자, 해당 정보가 속한 사용자나 조직, 출처가 된 상호작용, 타임스탬프, 유효성 상태, 예외 사항이 포함될 수 있습니다. 이러한 필드가 있으면 정보의 출처와 여전히 유효한지를 확인할 수 있습니다.

{
  "scope": "project:cedar",
  "statement": "Use metric units in project reports",
  "source_type": "explicit_user_instruction",
  "source_ref": "conversation_17/message_8",
  "status": "current",
  "exception": "Client edition may require dual units"
}

이는 예시를 위한 스키마이지 보편적인 표준은 아닙니다. 기억에 문장 하나보다 많은 정보가 담겨야 하는 이유를 보여주는 것이 목적입니다. 출처를 참조하면 검증에 도움이 되고, 적용 범위를 명시하면 지나친 일반화를 막을 수 있으며, 상태 필드를 두면 수정할 수 있습니다.

즉시 기록과 백그라운드 처리

즉시 기록하면 명시적인 수정 사항을 바로 다음 요청부터 반영할 수 있습니다. 백그라운드 처리는 완료된 상호작용을 검토하고, 중복 항목을 통합하거나, 더 숙고된 요약을 작성할 수 있습니다. LangChain 문서에서는 두 접근 방식과 각각의 장단점을 설명하며, 즉시 응답 경로에 추가되는 작업도 다룹니다.

실용적인 설계라면 확인된 선호 사항은 즉시 저장하고, 긴 조사 세션은 나중에 처리할 수 있습니다. 하지만 두 단계 사이의 시간도 처리해야 합니다. 기록이 성공하기 전에 시스템이 선호 사항을 저장했다고 사용자에게 알리면, 다음 대화에서 연속성이 끊기는 문제가 드러날 수 있습니다.

기억을 기록할 때는 실패 시 처리 방침도 필요합니다. 저장소를 일시적으로 사용할 수 없다면 애플리케이션은 저장이 완료되지 않았다고 알리거나, 대기 중인 작업임을 명확히 표시해 둘 수 있습니다. 기록을 시도한 것을 성공적으로 저장된 기억처럼 취급하면 사용자에게 잘못된 경험을 줄 수 있습니다.

지속 기억을 활성 컨텍스트로 불러오는 방법

검색은 접근 가능 여부, 관련성, 근거를 따져 보는 일련의 결정으로 이루어집니다. 시스템은 먼저 어떤 사용자, 테넌트, 프로젝트 또는 작업의 기록을 참조할 수 있는지 확인해야 합니다. 그런 다음 후보 기록을 찾고, 응답 컨텍스트에 포함할 항목을 선택합니다.

검색 방식은 질문에 맞아야 합니다. “Cedar의 승인된 마감일은 언제인가요?”라는 질문에는 프로젝트 필드에서 정확히 조회하는 방식이 가장 적합할 수 있습니다. “이 배포 오류를 전에 본 적이 있나요?”라는 질문에는 이전 사고 기록을 대상으로 한 키워드 검색과 의미 유사도 검색이 도움이 될 수 있습니다. 벡터 데이터베이스는 이 과정에서 사용할 수 있는 한 가지 선택지일 뿐, 모든 기억에 반드시 필요한 것은 아닙니다.

표현이 달라지는 경우에는 의미 검색이 특히 유용합니다. “보고서를 간결하게 작성하기”에 관한 검색어가 “짧은 경영진 요약”이라는 저장된 선호 사항과 일치할 수 있습니다. 하지만 관련 진술이 다른 고객에 관한 것이거나, 폐기된 프로젝트 버전을 가리킬 수도 있습니다. 유사도는 후보를 찾아낼 뿐, 사실 여부나 사용 권한을 입증하지는 않습니다.

검색 결과가 없을 때도 처리 방법이 필요하다

“지난달에 내가 승인한 지출 한도는 얼마였나요?”라는 질문을 생각해 보세요. 승인된 금액을 찾을 수 없다면, 도움이 되는 응답은 근거가 없다는 점을 밝히고 추가 설명을 요청하는 것입니다. 그럴듯한 숫자를 제시하면 기억의 부재가 허위 승인으로 바뀝니다.

따라서 메모리 인터페이스는 확인된 일치, 불확실한 일치, 충돌, 근거가 되는 기록 없음으로 구분해야 한다. 각 결과에 따라 직접 답변하거나, 답변에 단서를 달거나, 추가 설명을 요청하거나, 근거 없는 가정에 따라 행동하지 않을 수 있다.

검색한 뒤에도 해석이 중요하다. “제안된 최대 예산: $5,000, 승인 대기 중”이라는 기록을 “승인된 예산: $5,000”으로 바꾸어서는 안 된다. 올바른 문서를 찾는 것만큼 저장된 표현과 제공된 맥락에 단서를 그대로 남기는 것도 중요하다.

예시로 살펴보기: 시간의 흐름에 따라 프로젝트 기억하기

한 팀이 Cedar 연구 보고서를 작성하도록 돕는 어시스턴트를 떠올려 보자. 다음 예시는 가상의 상황이지만, 메모리 설계에서 흔히 마주치는 여러 선택지를 보여 준다.

세션 1: 프로젝트 설정하기

사용자는 보고서를 요청하고, 미터법 단위를 지정하고, 출처 세 개를 제공하며, 초안 마감일이 금요일이라고 말한다. 활성 맥락에는 이러한 지침과 출처 발췌문이 포함된다. 활성 작업 상태에는 완료된 섹션과 아직 검증이 필요한 주장이 기록된다.

잠재적으로 영구 보존할 기록은 용도가 서로 다르다. 미터법 선호는 프로젝트에 속한다. 초안 마감일은 현재 마일스톤에 속한다. 제공된 출처는 프로젝트의 근거 자료 보관소에 넣는다. 검증되지 않은 주장은 불확실성을 그대로 표시해 미완료 조사 목록에 기록한다.

세션 2: 적절한 근거를 바탕으로 이어서 작업하기

3일 뒤, 사용자는 방법론 섹션을 마무리해 달라고 요청한다. 어시스턴트에게는 최신 개요, 관련 출처, 현재 작업 상태, 적용되는 서식 규칙이 필요하다. 이전 브레인스토밍 세션에서 폐기한 문장까지 모두 필요한 것은 아니다.

체크포인트에 문헌 검토가 완료됐다고 적혀 있더라도, 어시스턴트는 해당 부분을 편집하기 전에 저장된 결과물을 열어 확인해야 한다. “완료됨”은 진행 상황에 대한 주장이고, 실제 문서는 무엇이 완료됐는지를 보여 주는 근거다. 결과물의 전체 내용을 재현하려는 요약보다 결과물을 가리키는 지속성 있는 참조 정보가 더 유용할 수 있다.

세션 3: 모든 내용을 다시 쓰지 않고 예외 적용하기

사용자는 미터법과 야드파운드법 단위를 모두 포함한 고객용 버전을 요청한다. 현재 작업에는 두 단위를 함께 사용해야 한다. 일반적인 프로젝트 규칙까지 바꿀지는 사용자의 표현과 적용 범위에 달려 있다. “이번 버전에는”은 “앞으로는 두 단위를 모두 사용해”보다 범위가 좁다.

신중한 어시스턴트는 해당 버전에만 적용되는 예외를 기록한다. 반면 지나치게 일반화하는 어시스턴트는 전체 적용되는 기본 설정을 바꾸어 이후 보고서에 오류를 일으킨다. 데이터베이스의 쓰기와 검색이 모두 성공했더라도 이는 메모리의 실패다.

세션 4: 마무리하고 임시 상태 정리하기

결과물을 전달한 뒤에는 마일스톤을 완료로 표시해야 한다. “보고서를 계속 진행해”라는 지시를 받으면 오래된 체크리스트부터 다시 이어 가는 대신 전달된 버전을 찾아 어떤 수정이 필요한지 물어야 한다. 프로젝트 정책에 따라 임시 메모는 만료될 수 있지만, 최종 보고서와 중요한 결정은 계속 이용할 수 있어야 한다.

여기서 영구 메모리의 장점이 드러난다. 같은 설명을 반복할 필요가 줄고 작업의 연속성이 향상된다. 비용도 분명하다. 애플리케이션은 선호 사항, 예외, 결과물, 변화하는 작업 상태 사이의 관계를 관리해야 한다.

요약, 압축, 예외 누락의 위험

긴 상호작용에는 다음 응답에 필요 이상으로 많은 내용이 쌓일 수 있다. 압축은 기록의 일부를 더 간결한 표현으로 대체한다. 요약에는 목표, 결정 사항, 해결되지 않은 질문, 원본 작업을 가리키는 참조 정보가 남을 수 있다.

Anthropic의 컨텍스트 엔지니어링 지침은 압축과 컨텍스트 창 밖에 저장한 메모를 장기간 작업에서 연속성을 유지하는 방법으로 소개한다. 두 기법 모두 이후 응답에 사용 가능한 자료를 바꾸므로 그 품질이 중요하다.

압축은 선택적으로 이루어진다. “미터법 단위 사용”이라는 요약은 “고객용 버전에서는 두 단위를 모두 사용해야 한다는 예외를 제외하고 미터법 단위 사용”보다 짧다. 하지만 프로젝트의 중요한 사례 중 하나에는 맞지 않는다. 누락된 예외는 이후 요약에도 조용히 이어질 수 있으며, 나중에는 그 경위를 추적하기 어려워진다.

Cedar 어시스턴트의 경우, 더 나은 인계 내용에는 일반 규칙과 그 예외, 완료된 섹션, 남은 검증 작업, 최신 파일의 참조 정보를 남겨야 한다. 승인 금액이나 식별자처럼 근삿값으로 처리하면 문제가 될 수 있는 정확한 세부 정보는 구조화된 기록이나 원본 문서에 보관해야 한다.

요약에는 불확실성도 그대로 남겨야 한다. “설문 B 사용을 검토했다”를 “설문 B를 선택했다”로 바꾸어서는 안 된다. 압축된 기록 때문에 잠정적인 결정이 확정된 것처럼 보인다면, 시스템은 맥락을 아끼려다가 잘못된 기억을 만들어 낸 셈이다.

AI 메모리는 정정과 충돌을 어떻게 처리해야 할까

지속 메모리는 내용을 바꿀 수 없으면 쓸모가 줄어든다. 프로젝트는 진행되고, 선호는 달라지며, 이전 정보가 틀린 것으로 밝혀지기도 한다. 정정 내용을 별도의 조건 없는 기록으로 추가하면 검색 시스템이 서로 모순되는 두 진술 중 하나를 선택해야 하는 상황이 생길 수 있다.

더 유용한 업데이트는 새로운 근거가 무엇을 대체하는지 명확히 한다. 프로젝트 책임자가 출시일을 11월 15일에서 11월 29일로 변경하면, 기존 기록을 대체된 것으로 표시하고 새 결정에 연결할 수 있다. 현재 마감일에 관한 질문에는 새 버전을 사용하고, 원래 계획에 관한 질문에는 이전 기록을 참조할 수 있다.

최신성만으로 모든 충돌을 해결할 수는 없다. 최근 작성된 초안 메모가 오래전에 승인된 정책보다 권위가 낮을 수 있다. 사용자는 개인적인 선호를 바꿀 권한은 있어도 조직 전체에 적용되는 규칙을 바꿀 권한은 없을 수 있다. 업데이트 정책은 사실의 종류와 출처의 권한을 고려해야 한다.

일부 모순은 사람이 명확히 설명할 때까지 미해결 상태로 남겨야 한다. 두 프로젝트 책임자가 서로 양립할 수 없는 날짜를 제시했고 어느 날짜가 다른 날짜를 대체한다는 명시적 설명도 없다면, 어시스턴트는 두 출처를 모두 보여 주고 어느 쪽을 적용해야 하는지 물을 수 있다. 가장 비슷하거나 가장 최근의 기록을 말없이 선택하면 시스템에 권한이 없을 수도 있는 결정을 감추게 된다.

AI가 잊는다는 것은 무슨 뜻일까?

잊기는 단일한 스위치가 아니다. 제품은 프롬프트에 특정 사실을 더 이상 삽입하지 않거나, 일반 검색에서 제외하거나, 오래된 정보로 표시하거나, 메모리 기록을 삭제하거나, 보관된 다른 사본을 제거할 수 있다. 이러한 작업은 향후 동작과 보관된 데이터에 서로 다른 영향을 미친다.

활성 컨텍스트에서 제외

이전 메시지가 생략되거나 요약되면 다음 모델 입력에서 어떤 사실이 사라질 수 있다. 그러면 모델이 당장 활용할 수 있는 정보가 줄어든다. 하지만 원본 대화 기록이나 메모리 기록은 여전히 남아 있다가 이후 검색을 통해 다시 나타날 수 있다.

회상 만료 또는 억제

만료된 마감일은 보관소에 남아 있으면서 현재 업무에 관한 검색에서는 제외될 수 있다. 과거 기록을 보존할 목적이 있을 때 억제는 유용하지만, 완전한 삭제라고 설명해서는 안 된다. 과거 기록 검색이나 관리 업무 절차를 통해 여전히 해당 기록에 접근할 수도 있다.

저장된 메모리 삭제

영구 기록을 삭제할 때는 그 기록에서 파생된 검색용 표현도 함께 처리해야 한다. 프로필에서 문장을 삭제했더라도 검색 가능한 요약에 남아 있으면 어시스턴트가 나중에 같은 선호를 다시 추론할 수 있다. 아키텍처에 따라 원본 기록, 임베딩, 요약, 캐시, 복제본을 각각 별도로 제거해야 할 수 있다.

백업과 로그에는 별도의 보존 일정이 적용될 수 있다. 제품은 이러한 한계를 명확히 설명하고, 복원 과정에서 삭제된 자료가 다시 활성화되지 않도록 해야 한다. “이 메모리를 더 이상 사용하지 않겠습니다”와 “보관된 사본을 모두 제거했습니다”는 서로 다른 약속이다.

모델 가중치 변경

외부 메모리를 삭제해도 모델 매개변수가 바뀌지는 않는다. 정보가 학습에 사용되었다면 모델에서 해당 정보를 처리하는 일은 학습 및 배포 과정과 관련된 별도의 문제다. 마찬가지로 개인 메모리를 삭제해도 모델이 일반 지식이나 새 프롬프트에 제공된 단서로 비슷한 사실을 생성하지 않으리라고 보장할 수는 없다.

따라서 의미 있는 망각 테스트는 시스템이 여전히 정보를 저장하고 있는지뿐 아니라, 일반적인 검색 경로를 통해 그 정보가 다시 유입될 수 있는지도 확인해야 한다. 채팅 응답에서 한 번 “잊어버렸습니다”라고 말한다고 해서 어느 쪽도 입증되는 것은 아니다.

메모리, RAG, 학습, 캐싱: 각 기술의 경계

검색 증강 생성(RAG)은 생성 과정에서 모델에 외부 근거를 제공한다. 초기 RAG 연구에서는 모델 매개변수와 검색 가능한 문서 색인을 결합했다. 개인 메모리 시스템도 검색을 활용할 수 있지만, 상호작용 기록을 생성하고 업데이트하며 보관을 종료하는 정책도 필요하다.

회사 매뉴얼은 검색될 수 있지만, 그렇다고 해서 사용자의 메모리가 되는 것은 아니다. 이전 상호작용에 관한 메모는 벡터 색인 없이 단순한 파일에서 검색할 수도 있다. 검색은 하나의 메커니즘일 뿐이며, 어떤 시스템을 구축하는지는 그 기반이 되는 기록의 목적과 수명 주기에 따라 결정된다.

학습과 미세 조정은 모델 매개변수를 수정한다. 일반적인 외부 메모리는 이와 달리 모델에 제공되는 근거를 바꾼다. 새로 저장된 선호를 따르는 보조 도구는 모델 가중치가 그대로여도 다르게 작동할 수 있다.

프롬프트 및 추론 캐싱은 지원되는 경우 이전 계산 결과를 재사용한다. 이를 통해 효율성을 높일 수는 있지만, 기억된 주장이 최신인지, 권한이 있는 정보인지, 향후 작업에 적합한지는 그 자체로 판단하지 못한다. 이러한 계층은 함께 존재할 수 있으며, 문제를 해결하려면 관찰된 동작의 원인이 어느 계층에 있는지 파악해야 한다.

MemGPT는 영향력 있는 아키텍처 사례다. 운영체제의 작동 방식에 착안해 제한된 컨텍스트와 외부 메모리 계층 사이에서 정보를 이동하는 방법을 탐구했다. 여기서 얻을 수 있는 유용한 교훈은 정보 이동을 명시적으로 관리해야 한다는 것이다. 저장 공간이 늘어나면 모델의 즉각적인 컨텍스트도 제한 없이 자동으로 확장된다고 가정해서는 안 된다.

지속형 메모리는 왜 실수를 더 오래 남길 수 있을까

잘못된 응답은 한 번의 상호작용에 영향을 미칠 수 있다. 잘못된 메모리는 여러 차례에 걸쳐 영향을 줄 수 있다. 보조 도구가 사용자가 어떤 결정을 승인했다고 추론해 그 내용을 사실로 저장한 뒤, 나중에 저장된 기록을 근거로 제시하면 이전에 저지른 자체 오류가 독립적인 증거인 것처럼 보일 수 있다.

우리 프로젝트 보조 도구에서는 원본 출처와 모델의 해석을 구분할 수 있어야 한다. 결정 사항을 요약하면 내용을 찾는 데 도움이 될 수 있지만, 중대한 조치를 뒷받침하는 근거는 승인된 결정 자체여야 한다. 여러 개의 생성된 메모에 반복해서 기록된다고 해서 근거 없는 추론 하나가 서로 독립적인 여러 건의 확인으로 바뀌는 것은 아니다.

지속형 메모리는 지침 오염의 경로가 되기도 한다. 신뢰할 수 없는 문서에 보조 도구가 앞으로의 동작을 바꾸도록 지시하는 문장이 들어 있을 수 있다. 그 문장을 운영 규칙으로 저장하면 외부 콘텐츠가 권한 경계를 넘어오게 된다. 메모리 저장소에 들어 있다는 이유로 해당 내용을 신뢰할 수 있는 지침으로 격상하지 말고, 애플리케이션은 출처에 따라 처리해야 한다.

공유 환경에서는 또 다른 경계를 고려해야 한다. 어떤 사실이 질문과 관련이 있더라도 다른 고객이나 프로젝트에 속한 정보일 수 있다. 정보가 모델에 전달되기 전에 접근 제어를 통해 검색 범위를 제한해야 한다. 권한 없는 기록을 이미 제공한 뒤 모델에게 무시하라고 요청하는 방식은 설계상 더 취약하다.

메모리가 실제로 작동하는지 평가하는 방법

그럴듯한 시연에서는 보조 도구에 저장된 선호 하나를 다시 말해 보라고 하는 경우가 많다. 제대로 된 평가는 여러 세션에 걸쳐 변화하는 정보를 추적하고, 메모리가 완료된 작업의 품질을 높이는지 확인한다.

LongMemEval은 정보 추출, 여러 세션에 걸친 추론, 시간적 추론, 지식 업데이트, 답변 유보를 평가한다. 이러한 평가 항목은 장기 메모리의 품질이 일치하는 문장 하나를 검색하는 것보다 훨씬 폭넓은 개념임을 보여준다. 공개된 벤치마크 결과는 테스트 대상 시스템과 설정에 한정해 해석해야 하며, 현재 모든 제품에 적용되는 결과라고 간주해서는 안 된다.

Cedar 워크플로를 평가한다면 선호를 제시하고, 프로젝트를 재개하고, 예외를 추가하고, 마감일을 수정하고, 메모를 삭제한 다음, 오래되었거나 근거가 부족한 기억의 인출을 드러내도록 설계된 질문을 할 수 있다. 또한 추가된 시스템이 결과를 개선하는지 확인할 수 있도록 같은 모델을 메모리 기능 없이도 테스트해야 한다.

• 저장 정확도: 시스템이 의도한 진술을 적용 범위와 단서까지 포함해 저장했는가?
• 검색의 유용성: 관련 없는 과거 기록으로 컨텍스트를 넘치게 하지 않으면서 작업에 필요한 근거를 찾았는가?
• 업데이트 처리: 수정된 내용이 현재 사실을 대체하면서도 유용한 과거 정보와의 구분은 유지했는가?
• 답변 유보: 뒷받침하는 기록이 없을 때 보조 도구가 그 사실을 인정했는가?
• 격리: 기록이 올바른 사용자, 테넌트, 프로젝트의 범위 안에만 유지되었는가?
• 망각: 삭제 또는 만료 후에는 파생 요약을 통한 경우까지 포함해 의도한 정보가 이후에 다시 검색되지 않았는가?
• 운영 비용: 개선 효과가 추가 지연 시간, 모델 호출, 저장 공간 및 유지 관리 비용을 정당화했는가?

실패는 어느 단계에서 발생했는지 추적해야 한다. 답변이 누락된 것은 기록에 실패했거나, 검색 범위가 잘못 설정됐거나, 순위 결정이 부적절했거나, 한정 조건이 빠졌거나, 모델이 적절한 근거를 잘못 해석했기 때문일 수 있다. 컨텍스트 크기를 늘린다고 이런 문제를 모두 해결할 수 있는 것은 아니다.

적합한 메모리 설계 선택하기

일회성 문서 요약에는 현재 문서와 지침만 필요할 수 있다. 중단된 분석은 작업 체크포인트가 있으면 도움이 된다. 반복적으로 진행되는 프로젝트의 어시스턴트는 버전이 관리되는 결정 사항과 산출물 참조 정보가 필요할 수 있다. 여러 사용자 세션에 걸쳐 작동하는 어시스턴트는 별도의 편집 가능한 선호도 저장소가 필요할 수 있다.

먼저 메모리가 답해야 할 미래의 질문을 구체적으로 정한다. “아직 끝나지 않은 일은 무엇인가?”라는 질문에는 작업 상태가 필요하다. “이 고객이 요구하는 형식은 무엇인가?”라는 질문에는 범위가 지정된 선호 사항이 필요하다. “우리는 왜 이 접근법을 거부했는가?”라는 질문에는 이를 뒷받침하는 근거가 포함된 결정 기록이 필요하다. 질문이 다르면 적절한 표현 방식도 달라야 한다.

무분별한 아카이브를 개인화된 정보로 제시하기보다는, 명확하고 출처를 확인할 수 있는 기록을 소수만 유지하는 편이 낫다. 현재 상태와 과거에 발생한 일을 구분하고, 원본 자료로 연결되는 링크를 보존하며, 처음부터 설계에 수정과 삭제를 포함해야 한다.

능동 메모리는 AI 시스템에 일관된 현재 상태를 제공한다. 지속 메모리는 시간의 흐름 속에서도 연속성을 유지하게 할 수 있다. 그 연속성의 품질은 두 메모리 사이에서 내리는 결정에 달려 있다. 무엇을 저장하고, 무엇을 다시 불러오며, 어떤 버전을 기준으로 삼고, 무엇을 사라지게 둘 것인지가 중요하다.