에이전트의 메모리가 작동하는 것처럼 보이나요? 실제로 작동하는지 확인하는 1분 테스트

약 6개월 동안 나는 내 에이전트의 메모리가 제대로 작동하고 있다고 믿었습니다.

그것은 세션(session)을 넘나들며 무언가를 기억했습니다. 프로젝트로 돌아왔을 때 적절한 컨텍text를 불러왔습니다. 무언가 변경되었을 때 스스로 수정하기도 했습니다. 눈에 보이는 모든 신호는 내가 구축한 시스템이 제 역할을 다하고 있다고 말해주었습니다.

하지만 그것은 제 역할을 하고 있지 않았습니다. Claude Code는 자체적인 내장 메모리(built-in memory)를 탑재하고 있었고, 실제로 답변을 하고 있었던 것은 바로 그것이었습니다. 내 시스템도 실행 중이었고, 자체 저장소(store)에 기록하며 바쁘게 움직이는 듯 보였지만, 그것은 대역(understudy)에 불과했습니다. 네이티브(native) 기능이 내내 주연을 맡고 있었음에도 나는 내가 주연을 넘겨주었다는 사실을 전혀 눈치채지 못했습니다. 몇 달 동안 나는 다른 배우가 대사를 읊고 있는 무대 위에서 내 시스템의 성공을 읽고 있었던 것입니다.

아무것도 잘못된 것처럼 보이지 않았습니다. 에이전트는 좋은 답변을 내놓았습니다. 바로 그것이 문제입니다.

조용한 성공은 위험한 종류입니다

요란하게 실패하는 시스템은 쉬운 사례입니다. 격차를 발견하고, 수정하면 됩니다.

조용히 그림자에 가려진 시스템은 위험한 종류입니다. 그림자는 유용하고 그럴듯한 출력을 만들어내기 때문에, 성공과 동일해 보이기 때문입니다. 출력 결과만 봐서는 내 시스템이 작동하는 것과 다른 무언가가 내 시스템을 대신해 작동하는 것을 구분할 수 없습니다. 두 경우 모두 출력이 동일하기 때문입니다. 그것이 함정이며, 좋은 답변은 그 함정에서 벗어날 방법이 아닙니다.

유일한 탈출구는 강제 함수(forcing function)입니다. 다른 것을 꺼버리고 어떤 일이 일어나는지 확인하는 것입니다.

테스트

이 방법은 내 것뿐만 아니라 어떤 에이전트 메모리 설정에서도 작동하며, 약 1분 정도 걸립니다. 런타임(runtime)의 네이티브 메모리를 끄십시오. Claude Code에서는 한 줄이면 됩니다:

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

그런 다음 평소처럼 에이전트를 사용하십시오. 무언가를 기억하라고 요청하십시오. 새로운 세션으로 돌아와 그것을 다시 물어보십시오. 대역이 집으로 돌아간 후 당신의 시스템이 실제로 무엇을 하는지 지켜보십시오.

• 만약 메모리가 여전히 작동한다면, 좋습니다. 그것이 항상 일을 해온 주인공이었습니다.
• 만약 갑자기 기억이 사라진다면, 네이티브 저장소가 당신을 대신해 주고 있었던 것이며, 당신이 보여준 모든 데모는 당신의 시스템이 아니라 그림자였던 것입니다.

마침내 제 개인 설정에서 이 테스트를 실행했을 때, 제 시스템은 조용해졌습니다. '작동한다'고 믿었던 6개월은 사실 무언가가 그것을 대신 가려주고 있었던 6개월이었음이 드러났습니다.

상황이 나아지지 않고 더 악화되는 이유

이미 자체적인 저장소를 가진 런타임 (Runtime)에 메모리 시스템을 덧붙일 때마다, 당신은 이러한 위험에 노출됩니다. 그리고 기반이 되는 모델 (Model)이 똑똑해질수록 그 간극을 더 잘 가려주게 됩니다. 이는 당신의 데모가 더 훌륭해 보일수록, 그것이 증명하는 바는 더 적어진다는 것을 의미합니다.

유능한 모델을 사용한 세련된 데모는 당신의 시스템이 작동한다는 증거가 아닙니다. 그것은 단지 모델이 시스템이 작동하지 않는다는 사실을 숨길 수 있을 만큼 충분히 뛰어나다는 증거일 수도 있습니다.

따라서 답변이 좋다고 해서 당신의 메모리가 작동한다고 믿지 마십시오. 실제로 무엇이 영구 저장 (Persisted)되고 있는지 확인하고, '오프 테스트 (off-test)'를 실행하십시오. 다른 요소를 꺼버리고, 실제로 누가 대화하고 있었는지 확인하십시오.

저는 이것을 깨닫는 데 반년이 걸렸습니다. 당신은 단 한 줄의 코드와 1분이면 충분합니다.