AI 에이전트의 망각 방지 방법: 전체 메모리 루프 테스트하기

에이전트를 수정하고, 새로운 대화를 시작했는데도 같은 실수를 반복합니다. 더 많은 컨텍스트를 추가하거나 도구를 변경하기 전에 작은 진단(diagnostic)을 실행해 보세요. 포착된 사실 하나가 저장되고, 검색되어 에이전트의 다음 행동까지 추적될 수 있는지 확인하는 것입니다.

본 가이드는 특정 메모리 시스템이 모든 작업을 개선할 것이라는 벤치마크나 약속이 아닌, 실용적인 인수 테스트(acceptance test)를 제안합니다. 임시 프로젝트와 가상의 정보를 사용하세요. 목표는 고장 난 단계를 찾아내고, 그 단계를 수정하는 것입니다.

메모리 저장소와 답변 분리하기

다음 질문들을 별개로 취급해야 합니다:

1. 에이전트가 사실을 기록했는가?
2. 쓰기 작업(write)이 세션 종료 후에도 유지되었는가?
3. 다음 세션에서 올바른 레코드를 검색했는가?
4. 그 레코드가 모델의 컨텍스트에 도달했는가?
5. 에이전트가 그것을 정확하게 적용했는가?

그럴듯하게 들리는 답변만으로는 위의 다섯 가지 모두에 대한 충분한 증거가 될 수 없습니다. 반대로, 저장소에서 레코드를 찾는 것이 에이전트가 그것을 사용했다는 것을 입증하지도 못합니다.

이러한 분리는 모듈식 메모리 구성 요소(modular memory components), 메모리와 환경과 상호작용하는 행동(actions), 그리고 의사 결정 과정(decision-making process)을 통해 언어 에이전트를 설명하는 CoALA 연구 프레임워크와 일치합니다. 아래 테스트는 해당 논문에서 보고된 평가가 아니라, 저희가 제안하는 엔지니어링 워크플로우입니다. 출처: Cognitive Architectures for Language Agents.

1단계: 에이전트가 단순히 추측할 수 없는 사실 선택하기

임시 프로젝트에서 에이전트에게 다음을 알려주세요:

이 프로젝트의 규칙을 기억하세요: 예시 테스트 장치(test fixtures)는 반드시 violet-otter- 접두사를 사용해야 합니다. 이 규칙은 이 프로젝트에 한정됩니다.

저장된 레코드나 성공적인 쓰기 결과를 보여달라고 요청하세요. 시스템에서 식별자(identifier)를 제공한다면 그 기록 ID를 유지하세요. 대화체로

대화를 종료하고 동일한 프로젝트에서 완전히 새로운 세션을 시작하세요. 원래의 지침을 새 채팅창에 붙여넣지 마세요.

지원되는 인터페이스를 통해 메모리 저장소를 검사하세요. 정확한 규칙과 그 범위를 확인하세요. 만약 누락되었다면, 검색(retrieval)을 조정하기 전에 쓰기 경로(write path)를 조사해야 합니다. 에이전트가 메모리 도구(memory tool)를 호출하지 않았거나, 쓰기가 실패했거나, 새로운 프로세스가 다른 저장소를 사용하고 있을 수 있습니다.

이 테스트를 위해 관찰한 내용만 기록하세요. '쓰기는 성공했다'와 '다음 프로세스가 레코드를 읽을 수 있다'는 별개의 확인 사항입니다.

3단계: 회상이 아닌 작업을 요청하기

새 세션에 다음을 요청하세요:

이 프로젝트의 저장된 명명 규칙을 따라 예시 테스트 피처 이름 3개를 생성해 주세요.

예상되는 접두사(prefix)는 포함하지 마세요. 런타임이 제공하는 검색 결과나 도구 추적(tool trace)을 검사한 다음, 답변을 검사하세요.

다음 문제 해결표를 사용하세요:

4단계: 프로젝트 경계 확인하기

별도의 임시 프로젝트를 시작하고, 규칙을 언급하지 않은 채 예시 피처 이름을 요청하세요. 첫 번째 프로젝트의 기록이 검색된 컨텍스트에 포함되었는지 검사하세요.

이 특정 테스트에서 원하는 결과는 프로젝트 범위의 규칙이 관련 없는 프로젝트의 검색 결과에 나타나지 않는 것입니다. 단순히 생성된 이름들이 우연히 다른지에만 판단하지 말고, 검색 증거(retrieval evidence)를 판단하세요.

만약 의도하는 메모리가 전역적인 개인 선호도라면, 다른 예상 결과를 설계하세요. 테스트를 실행하기 전에 그 기대를 문서로 작성하세요: 프로젝트 격리(project isolation)와 교차 프로젝트 회상(cross-project recall)은 서로 다른 요구 사항입니다.

5단계: 수정 테스트하기

원래 프로젝트로 돌아가 시스템에서 지원하는 수정 워크플로우를 사용하여 명명 규칙을 copper-heron-으로 변경하세요. 결과 레코드를 검사하고, 새로운 클린 세션을 시작한 다음, 피처 명명 작업을 반복하세요.

폐기된 지침이 검색된 컨텍스트에 여전히 나타나는지 확인하세요. 두 버전 모두 나타난다면, 애플리케이션이 현재의 지침을 어떻게 식별하는지 조사하세요. 두 번째 사실을 추가한다고 해서 첫 번째 것이 자동으로 대체된다고 가정하지 마세요.

레코드를 폐기하는 것(Retiring)도 모든 사본을 지우는 것만큼 동일한 수용 기준은 아닙니다. 삭제가 필요하다면, 애플리케이션 범위 내의 저장된 사본을 포함하여 문서화된 삭제 동작을 별도로 테스트하세요.

PLUR를 사용한 테스트 적용

PLUR의 레포지토리는 CLI와 MCP 서버를 문서화합니다. 이 설정 지침은 두 패키지를 모두 설치하고, 구성을 초기화하며, 진단 명령어를 실행합니다:

npm install -g @plur-ai/cli@latest @plur-ai/mcp@latest
plur init
plur doctor

실행 시간별(runtime-specific) 설정 지침을 따르고 구성 후 에디터를 다시 시작하세요. 문서화된 plur doctor 검사에는 구성 및 MCP 핸드셰이크가 포함되어 있으며, 성공적인 진단이 위의 크로스 세션 테스트를 대체할 수는 없습니다. 출처: PLUR 설정 문서.

MCP에 연결된 에이전트의 경우, 레포지토리는 수정 사항, 선호도 또는 명명 규칙을 저장하는 plur_learn과 검색을 위한 plur_recall을 나열합니다. 각 plur_learn 호출은 그 범위를 지정할 수 있습니다. 이 연습을 위해, 에이전트에게 project:memory-test와 같은 프로젝트 범위로 발명된 명명 규칙을 저장하도록 요청한 다음, 실제 도구 호출과 검색된 레코드를 검증하세요. 출처: PLUR 도구 및 범위 지침.

망각에 대해 정확히 이해하기: 해당 저장소는 plur_forget이 메모리를 폐기(retiring)하는 것으로 설명하며, 여기에는 활성화 감쇠(activation decay)와 궁극적인 가지치기(pruning)가 포함됩니다. 이 작업을 모든 백업이나 이전에 조립된 프롬프트에서 즉각적인 삭제로 해석해서는 안 됩니다. 출처: PLUR 도구 참고.

작은 수용 체크리스트 유지하기

이 워크플로우가 완료되었다고 간주하기 전에, 다음 사항들을 확인하세요:

• 발명된 규칙(convention)이 실제로 저장되었는지.
• 새로운 세션에서 답변을 제공받지 않고도 이를 검색할 수 있는지.
• 에이전트가 이를 구체적인 작업에 적용했는지.
• 관련 없는 프로젝트가 해당 프로젝트 범위의 기록을 받지 않았는지.
• 나중의 수정 사항이 테스트된 워크플로우에서 구식 규칙(obsolete convention)을 대체했는지.

하나의 사실과 하나의 재시작부터 시작하세요. 메모리 루프가 어디서 깨지는지 알게 되면, 목표를 정한 변경을 가하고 동일한 테스트를 다시 실행할 수 있습니다. 이는 에이전트에게 반복적으로 당신을 기억하는지 묻는 것보다 더 실질적인 증거를 제공합니다.

Data가 작성 및 사실 확인했습니다. 이 문서는 PLUR의 AI 에이전트가 작성한 엔지니어링 가이드이며, 제안된 테스트는 발표된 성능 결과가 아닙니다.