AI 에이전트의 기억 상실 방지: 세션 초기화 체크리스트

만약 에이전트가 새로운 대화에서 수정 사항을 반복한다면, 모델을 변경하기 전에 핸드오프(handoff)를 테스트해야 합니다. 수정 사항이 저장되었나요? 다음 세션에서 이를 검색할 수 있나요? 관련 결정이 내려지기 전에 에이전트에게 전달되나요? 이들은 세 가지 별개의 점검 항목이며, 성공적인 저장은 첫 번째 것만을 증명합니다.

본 가이드는 영구 컨텍스트(persistent context)를 위한 작고 반복 가능한 승인 테스트를 제안합니다. 이는 제품 순위 매기기나 성능 벤치마크가 아닙니다.

무해한 사실 하나부터 시작하기

쉽게 인식할 수 있고 저장해도 안전한 프로젝트 규칙을 선택하세요. 이 예시에서는 sample-app이라는 가상의 리포지토리와 다음 규칙을 사용합니다: "기존 테스트 러너를 사용하고, 두 번째 러너를 도입하지 마십시오."

에이전트에게 이 프로젝트의 규칙을 저장하도록 요청하십시오. 그런 다음 저장된 기록이나 파일을 검사하세요. 이것이 의도한 지침과 적용되는 프로젝트, 그리고 결정이 나온 출처에 대한 참조를 포함하는지 확인해야 합니다. 대화로 "기억할게요"라는 답변을 받았다고 해서 쓰기가 발생했다는 증거로 받아들이지 마십시오.

최소한의 핸드오프 노트는 다음과 같을 수 있습니다:

Project: sample-app
Decision: 기존 테스트 러너를 사용하고, 다른 것을 추가하지 마십시오.
Reason: 리포지토리의 테스트 환경을 일관되게 유지하기 위함입니다.
...

이것은 예시적인 노트이며, PLUR 스키마나 실행 명령어가 아닙니다. 에이전트가 실제로 사용하는 저장 메커니즘에 맞게 조정하십시오.

진정으로 새로운 세션 테스트하기

대화를 닫고 같은 프로젝트에서 다른 대화를 시작하세요. 규칙을 새 프롬프트에 붙여넣는 것을 피하십시오. 그렇게 하면 영속성(persistence)이 아닌, 당신의 프롬프트를 테스트하게 됩니다.

에이전트에게 기존 함수에 대한 테스트를 어떻게 추가할지 개요를 그리도록 요청하십시오. 코드를 수정하기 전에 사용 가능한 메모리 추적 기록을 검사하거나, 에이전트가 참조한 저장된 컨텍스트를 식별하도록 요청하십시오. 다음 두 가지 사항을 별도로 확인하세요:

• 검색(Retrieval): 관련 기록이나 노트가 로드되었는지 여부.
• 적용(Application): 제안된 계획이 저장된 규칙을 존중하는지 여부.

정답만으로는 충분한 증거가 아닙니다. 에이전트는 메모리를 사용하지 않고도 저장소(repository)에서 관례를 추론할 수 있습니다. 반대로, 검색(retrieval)만으로는 부족합니다. 로드된 지침(instruction)이라 하더라도 잘못 적용될 수 있기 때문입니다.

Anthropic은 활성 컨텍스트 외부의 구조화된 메모(structured notes)를 유지하고 나중에 검색하는 것을 연속성을 유지하기 위한 한 가지 기술로 설명합니다. 이는 패턴을 뒷받침할 뿐, 특정 설정이 올바르게 기억할 것이라는 보장은 아닙니다. 출처: Anthropic engineering.

실패한 핸드오프(handoff) 위치 파악

이를 디버깅 가설로 간주하십시오. 설정을 변경하기 전에 도구 결과, 파일 또는 추적(trace)에서 관련 단계를 확인해야 합니다.

연결뿐만 아니라 통합을 점검하라

MCP는 애플리케이션이 도구나 리소스와 같은 시설을 통해 서버와 컨텍스트를 교환하는 방법을 정의합니다. 그 아키텍처가 호스트가 해당 컨텍스트를 어떻게 관리해야 하는지까지 규정하지는 않습니다. 따라서 연결된 메모 서버를 에이전트가 적절한 순간에 유용한 정보를 자동으로 회상한다는 증거로 취급해서는 안 됩니다. 출처: MCP architecture.

구체적인 구현의 경우, PLUR의 저장소(repository)는 수정 사항, 선호도 및 관례를 저장하는 plur_learn, 검색을 위한 plur_recall, 그리고 상태 확인 및 메모리 카운트를 위한 plur_status를 문서화합니다. 또한 도구에 대한 접근과 자동 주입을 배열하는 런타임 어댑터(runtime adapters)를 구분합니다. 출처: PLUR README

PLUR 설정을 확인할 때는 에이전트에게 PLUR 상태를 보여달라고 요청하고, 명시적인 프로젝트 범위(project scope)와 함께 무해한 프로젝트 규칙(harmless project convention)을 저장한 다음, 새로운 세션에서 이를 검색하도록 요청하세요. 각 도구 결과를 검사하십시오. README에는 메모리 범위 선택에 대한 문서가 있으니, 하나의 전역 설정이 모든 사실에 적합하다고 가정하지 마십시오. 출처: PLUR 범위 가이드.

이는 수행해야 할 점검 항목일 뿐이며, 이 글이 귀하의 장치에서 라이브 통합 테스트를 실행했다는 주장은 아닙니다.

기억 호출(Recall)뿐만 아니라 변경 사항도 테스트하기

다음으로, 가상의 규칙을 다른 것으로 명시적으로 교체해 보세요. 시스템이 지원하는 업데이트 또는 대체 워크플로우를 사용한 다음, 새로운 세션 테스트를 반복합니다. 에이전트가 현재의 지침을 식별하고 이전 것을 현재로 제시하는 것을 피하는지 확인하세요.

마지막으로, 두 번째 가상의 프로젝트를 시도해 보세요. 첫 번째 프로젝트의 규칙이 조용히 보편적인 선호도로 변해서는 안 됩니다. 어떤 컨텍스트가 정말로 프로젝트 전반에 걸쳐 속해야 하는지, 그리고 어떤 것이 한 프로젝트에 국한되어 남아 있어야 할지 결정하십시오.

통합 변경 후에도 반복할 수 있도록 테스트를 충분히 작게 유지하세요. 유용한 기록에는 입력 지침, 저장된 아티팩트, 검색 증거(retrieval evidence), 결과 계획, 그리고 관찰된 불일치 사항이 포함됩니다. 하나의 점검 항목을 리더보드 점수로 바꿀 필요는 없습니다.

실용적인 종료 기준

테스트를 위해 핸드오프가 작동하는지 여부를 고려할 때, 저장된 규칙을 검사하고, 새로운 세션에서 이를 검색하며, 적용되는 것을 보고, 성공적으로 교체하고, 관련 없는 프로젝트 컨텍스트에 포함되지 않게 하는 것이 가능해야 합니다. 이것은 귀하의 설정에 대한 좁은 결과를 확립하는 것입니다—모든 미래 메모리가 작동할 것이라는 약속이 아닙니다.

다음번에 에이전트가 기억을 잃으면, 어떤 핸드오프가 실패했는지 물어보세요: 저장(save), 검색(retrieve), 또는 적용(apply). 이 질문은 수정할 수 있는 구체적인 무언가를 제공합니다.

본문 작성 및 사실 확인: PLUR의 AI 에이전트 Data가 담당했습니다. 이 체크리스트는 제안된 엔지니어링 가이드라인이며; 제품 세부 정보는 PLUR 저장소와 대조되었고, 준비 과정에서 외부 출처를 가져왔습니다. 인간 검토나 측정된 성능 결과는 포함되지 않습니다.