에이전트는 결코 기억하기를 선택하지 않는다: 하네스 속성으로서의 메모리 (Memory)

모든 출시된 메모리 (Memory) 설계는 모델에게 저장과 회상을 결정하도록 요청합니다. 정답이 이미 저장소에 있는 제어 실행 (Control run) 환경에서, 모델은 114회의 턴(turn) 동안 단 한 번도 스스로 결정하지 않았습니다. 우리가 건너뛴 단계는 무엇인지, 그리고 이를 어떻게 구축할 수 있는지 소개합니다.

저는 코딩 에이전트 (Coding agents)를 위한 메모리 시스템을 구축하는 데 거의 1년을 보냈고, 마지막에 가서야 제가 문제의 절반만을 잘못 풀고 있었다는 사실을 깨달았습니다. 저장소 (Store)는 괜찮았습니다. 검색 (Retrieval)도 괜찮았습니다. 제가 한 번도 의문을 제기하지 않았던 것은 그 중간 단계, 즉 에이전트가 스스로 그 둘 중 하나를 사용할지 결정할 것이라는 점이었습니다.

어떤 에이전트 메모리 제품을 열어보더라도 동일한 형태를 발견할 것입니다. 무언가를 넣을 장소, 그것을 다시 가져올 방법, 그리고 모델에게 언제 그 두 가지를 수행해야 하는지 알려주는 한 단락의 지침 (Instructions)이 있습니다. 지침 파일 (Instruction files), 메모리 디렉토리 (Memory directories), MCP를 통한 메모리 도구 (Memory tools), 회상 엔드포인트 (Recall endpoint)가 있는 벡터 저장소 (Vector stores) 등이 있습니다. 아키텍처 (Architectures)는 매우 다양하지만, 그 밑바탕에 깔린 가정은 동일합니다. 루프 (Loop)의 어딘가에서 모델이 기억하기를 원해야 한다는 것입니다.

저는 바로 그 가정을 해체하고자 합니다. 모델이 게을러서도 아니고, 도구가 나빠서도 아닙니다. 우리가 메모리를 설계할 때 인간의 기억 중 잘못된 절반을 빌려왔기 때문입니다. 업무 시간 내내 당신을 지탱해 주는 기억은 당신이 직접 찾아 나서는 기억이 아닙니다. 그것은 상황이 불러냈기 때문에 도착하는 기억입니다. 에이전트에서 그러한 단계는 모델이 연습하는 기술 (Skill)이 되어서는 안 됩니다. 그것은 컨텍스트 윈도우 (Context window)를 소유하고, 묻지 않고도 그 안에 무언가를 넣을 수 있는, 모델이 실행되는 프로그램인 하네스 (Harness)의 속성 (Property)이어야 합니다.

이 포스트는 그 논거와 그 뒤에 숨겨진 실행 결과, 그리고 실제로 구축해야 할 대상의 형태에 관한 것입니다. 범위에 대한 사전 경고를 드리자면: 측정값은 하나의 버전 내의 하나의 하네스 안에서 수행된 하나의 작업에 대한 것이며, 섹션 12에서는 이 결과가 어디까지 일반화될 수 있다고 생각하는지, 그리고 어떤 상황에서 제가 이 입장을 철회할 것인지에 대해 설명하겠습니다.

이 포스트와 함께 제공되는 논문. 프로토콜, 채점자(graders), 그리고 이 포스트가 비공식적으로 주장하는 2단계 이론(two-tier theory)을 포함한 전체 내용은 Delivery, Not Storage: Cue-Anchored Working Memory as a Harness Property for Coding Agents (arXiv:2607.20972, 2026년 7월 23일)입니다. 이 포스트의 모든 수치는 해당 논문에서 가져왔습니다. 논문이 유보적인 입장을 취하는 부분에 대해서는 이 포스트도 동일하게 유보적인 입장을 취합니다.

시작하기에 앞서 용어에 대한 참고 사항입니다. 하네스 (harness)는 모델이 실행되는 프로그램입니다. 하네스는 대화를 소유하고, 어떤 텍스트가 컨텍스트 윈도우 (context window)에 들어갈지 결정하며, 도구 (tools)를 실행하고, 압축 (compaction)을 처리합니다. Claude Code, Cursor, 그리고 모든 에이전트 런타임 (agent runtime)은 하네스입니다. 컨텍스트 윈도우 (context window)는 모델이 단일 순전파 (forward pass) 과정에서 볼 수 있는 고정된 크기의 텍스트 블록입니다. 모델이 현재 세션에 대해 "아는" 모든 것은 가중치 (weights)에 있거나 해당 윈도우 안에 있습니다.

파트 1: 아무도 언급하지 않는 가정

01. 하나의 가정, 모든 에이전트 메모리 제품

현재의 설계들을 나열하고, 사물을 어떻게 저장하느냐가 아니라, 저장된 사실이 모델의 컨텍스트 윈도우 (context window)에 들어갈지를 누가 결정하느냐에 따라 분류해 보십시오. 그 열에는 단 세 가지 값만 존재하며, 이 값들 사이의 차이는 마케팅 페이지에서 비교하는 그 어떤 것보다 더 중요하다는 것이 밝혀졌습니다.

어느 행에 정교한 엔지니어링이 들어있는지, 그리고 어느 행이 실제로 결과물을 전달하는지 주목하십시오. 지시 파일 (instruction file)은 검색 로직 (retrieval logic)이 전혀 없는 평면적인 텍스트 문서이며, 모든 코딩 에이전트가 가진 단일하게 가장 신뢰할 수 있는 메모리 채널입니다. 그것이 잘 설계되었기 때문이 아닙니다. 모델이 그것에 대해 생각하고 있었든 아니든, 모델 외부의 메커니즘이 그것을 컨텍스트 (context)에 붙여넣기 때문입니다.

그 아래의 행들이 바로 흥미로운 엔지니어링이 일어나는 지점입니다: 키워드가 아닌 의미에 의한 검색 (retrieval), 후보군들의 재순위화 (reranking), 지식 그래프 (knowledge graphs), 오래된 노트를 새로운 노트로 병합하기, 그리고 오래된 정보를 폐기하기 (ageing out) 등이 그것입니다. 이러한 품질의 모든 요소는 슬라이드에는 아무도 적지 않는 숫자, 즉 모델이 실제로 해당 기능을 호출하는 시간의 비율에 의해 배가됩니다. 만약 그 숫자가 0에 가깝다면, 그 위의 모든 과정은 0에 대한 산술 연산에 불과합니다.

불편한 순위. 에이전트 메모리 채널을 신뢰도(reliability) 순으로 정렬하면, 엔지니어링 노력의 역순 순위가 나타납니다. 가장 멍청한 채널인 하네스(harness)가 붙여넣는 정적 파일 (static file)이 가장 신뢰도가 높습니다. 가장 똑똑한 채널인 잘 튜닝된 인덱스를 활용한 의미론적 검색 (semantic retrieval)은 가장 신뢰도가 낮습니다. 왜냐하면 이는 발생하지 않을 수도 있는 모델의 주도적 행위에 의해 제어되기 때문입니다. 여기서 신뢰도는 검색 (retrieval)의 속성이 아닙니다. 그것은 누가 방아쇠를 당기느냐의 속성입니다.

이것은 지시 파일 (instruction files)이 좋다는 주장이 아닙니다. 지시 파일은 대부분의 면에서 끔찍합니다: 정적이고, 무조건적이며, 무한히 커지고, 매 사이클마다 비용이 발생합니다. 이것은 우리가 계속해서 저장 (storage)과 검색 (retrieval)의 공으로 돌리고 있는 작업이 사실은 '전달 (delivery)'이 수행하고 있다는 주장입니다. 그리고 일단 그것을 깨닫고 나면, 다음 질문은 명확해집니다: 지시 파일의 비용 없이 지시 파일의 신뢰도를 얻을 방법이 있을까? 그 질문이 이 포스트의 나머지 내용입니다.

02. 당신이 선택할 수 없는 메모리 계층 (Memory Tier)

지난달 세 번째 화요일에 점심으로 무엇을 먹었는지 기억해 보려고 노력해 보세요. 당신은 방금 힘든 일을 수행했습니다: 검색을 구성하고, 제약 조건을 탐색하며, 찾아내거나 혹은 포기했습니다. 심리학자들은 이를 자발적 검색 (voluntary retrieval)이라고 부릅니다. 이것은 느리고, 전략적이며, 모든 에이전트 메모리 도구가 모델링하는 계층입니다.

이제 계단실의 어떤 냄새가 당신이 무언가를 결정하기도 전에, 요청하지 않았음에도 20년 전의 어느 장소로 당신을 데려갔던 마지막 순간을 떠올려 보십시오. 혹은 조금 덜 낭만적으로 말하자면, 설정 파일(config file)을 수정하기 위해 앉았을 때 '조심해, 이건 핵심적인 파일이야. 지난 3월에 이것 때문에 운영 환경(prod)이 망가졌었어'라는 생각이 스스로 떠오른 적을 생각해보십시오. 당신은 그것을 질의(query)하지 않았습니다. 상황이 그것을 전달한 것입니다.

그 두 번째 계층이 바로 **비자발적 검색 (involuntary retrieval)**이며, 일상적 인지(everyday cognition)에 대한 일기 연구(diary studies)에 따르면 이는 예외적인 현상이 아닙니다. 이는 사람들이 기능하는 방식의 일상적이고 빈번한 부분이며, 주의(attention)가 분산된 상황, 즉 다른 무언가를 하느라 바쁠 때 가장 많이 나타납니다. 이 검색은 노력적이고 전략적이기보다는 연상적(associative)이고 문맥 민감적(context-sensitive)입니다.

이것이 발화(firing)하기 위한 조건은 잘 규명되어 있습니다. Endel Tulving의 **부호화 특수성 원리 (encoding specificity principle)**에 따르면, 단서(cue)는 메모리가 형성될 때 부호화(encoded)되었던 내용과 겹치는 정도에 따라 작동합니다. 이후 자발적 검색(spontaneous retrieval)에 관한 연구는 이를 더욱 정교화했습니다. 독특한 '단서-사건' 쌍은 일반적인 쌍보다 훨씬 더 많은 비자발적 기억을 생성합니다. 특정 장면과 결합된 특정 소리는 그 장면을 다시 불러옵니다. 일반적인 소리는 특별한 아무것도 불러오지 못합니다.

주방에서의 두 가지 계층.

자발적 검색 (Voluntary retrieval)은 레시피를 찾아보는 것입니다. 당신은 그것이 필요하다는 것을 알고, 그것이 대략 어디에 있는지 알며, 가서 가져옵니다. 그것은 작동하지만, 의도적인 움직임이라는 비용이 발생합니다.

비자발적 검색 (Involuntary retrieval)은 팬 손잡이를 잡으려다 손을 멈추는 것입니다. 왜냐하면 그 손잡이가 한때 뜨거웠기 때문입니다. 아무도 무엇인가를 찾아보지 않았습니다. 상황, 손잡이, 손을 뻗는 동작이 그 상황에 처해 있는 것의 부수 효과(side effect)로서 기억을 생성했습니다. 만약 매번 손을 뻗기 전에 "이 손잡이가 과거에 뜨거웠던 적이 있는가"를 의식적으로 질의해야 한다면, 당신은 결국 그것을 잊어버릴 것이고, 결국 데이게 될 것입니다.

설계에 있어 중요한 부분은 바로 여기입니다. 당신이 작업하는 동안 당신을 안전하게 지켜주는 계층은 두 번째 계층이며, 이는 정확히 당신의 통제 하에 있지 않은 계층입니다. 당신은 뜨거운 손잡이를 기억하기로 결정하지 않습니다. '결정하는 것' 자체가 실패 모드(failure mode)입니다. 만약 기억에 결정이 필요하다면, 그 결정은 실제 작업과 경쟁하게 될 것이고, 실제 작업이 승리할 것입니다. 왜냐로 실제 작업이 바로 당신이 주의를 기울이고 있는 대상이기 때문입니다.

제가 사용해 온 모든 에이전트 메모리(agent memory) 제품은 요리법(recipe book)을 모델링합니다. 그중 어떤 것도 뜨거운 손잡이를 모델링하지 않습니다. 그리고 뜨거운 손잡이야말로 부하(load)가 발생하는 지점입니다.

이 비유가 주장하지 않는 것.

저는 언어 모델(language model)이 인지 과정으로서 일화적 부호화(episodic encoding), 공고화(consolidation), 또는 비자발적 회상(involuntary recall)과 유사한 무언가를 가지고 있다고 말하는 것이 아닙니다. 그렇지 않습니다. 모델은 컨텍스트 윈도우(context window)와 일련의 가중치(weights)를 가질 뿐이며, 그것이 전부입니다.

전이되는 것은 메커니즘이 아니라 _전달 규율(delivery discipline)_입니다. 인간의 기억 연구가 여기서 자리를 잡는 이유는 단 한 가지 때문입니다. 즉, 중대한 작업을 수행하는 시스템은 에이전트가 결코 시작하지 않는 검색 경로(retrieval path)에 크게 의존하며, 그 경로는 단서 특이성(cue specificity)에 의해 제어된다는 점을 입증했기 때문입니다. 그 제약 조건은 당신이 글로브 패턴(glob pattern)과 이벤트 훅(event hook)을 사용하여 하네스(harness)에 구현할 수 있는 것입니다. 신경과학은 그대로 두고, 제약 조건만 가져가십시오.

이 문헌을 아는 누군가가 반박하기 전에 한 가지 주의사항을 말씀드립니다. 인간의 비자발적 회상은 신뢰할 수 없습니다. 그것은 쓸데없는 순간에 작동하고, 당신이 필요로 하는 순간에는 놓치며, 당신에게 걸어오는 사람의 이름을 떠올리는 데 매우 서투르기로 유명합니다. 만약 논거가 "인간의 기억을 복제하자"였다면, 그러한 비신뢰성은 심각한 문제가 되었을 것입니다.

그것은 논거의 문제가 아닙니다. 하네스 (harness) 내의 큐 (cue)는 관찰 가능한 상태 (observable state)에 대한 불리언 (boolean) 값이며, 따라서 그것이 참일 때만 정확히 작동하고 그렇지 않을 때는 절대 작동하지 않습니다. 설계된 버전은 영감을 준 대상보다 엄격하게 더 신뢰할 수 있으며, 이것이 바로 대상을 찬양하기보다 그것을 구축하는 이유입니다. 생물학이 기여하는 바는, 초기화되지 않은 경로 (un-initiated path)가 하중을 견디고 있다는 관찰입니다. 이는 자명하지 않은 사실이며, 에이전트 메모리 (agent memory) 분야 전체가 마치 이것이 거짓인 것처럼 구축해 왔던 부분입니다.

제2부: 실행 결과가 실제로 보여준 것

03. 114턴 동안 자발적 메모리 작업 0회

이론은 저렴합니다. 제가 2단계 프레임워크 (two-tier framing)를 믿는 이유는, 이것이 반대 가설을 반증하기 위해 제가 설정한 실험이었고, 결국 반증할 수 없었기 때문입니다.

이 설정은 에이전트가 메모리 저장소 (memory store)를 사용하지 않을 수 있는 모든 변명을 제거합니다. 저장소에는 에이전트가 시도하려는 정확한 작업에 관한 네 가지 노트가 미리 심어져 있었습니다. 즉, 읽기만 하면 잘못된 길로 빠지는 것을 막아줄 수 있는 실질적인 주의 사항 (gotchas)들이었습니다. 메모리 도구들은 세션의 초기화 과정에서 연결 및 검증되었습니다. 워크스페이스 지침 파일 (workspace instruction file)에는 모델이 언제 도구를 사용해야 하는지에 대한 사용 가이드가 포함되어 있었습니다. 그 후 에이전트에게 자연스러운 코딩 작업을 부여하고 그대로 두었습니다.

측정 결과. 114턴 동안, 에이전트는 자발적 메모리 작업 (voluntary memory operations)을 단 한 번도 수행하지 않았습니다. 단 한 개의 노트를 쓰지도 않았습니다. 단 한 개의 노트를 읽지도 않았습니다. 에이전트 자신의 문제에 대한 네 가지 해답은 호출 한 번이면 닿을 수 있는 거리에서, 단 한 번의 질의도 받지 못한 채 내내 저장소에 놓여 있었습니다.

여기서 '턴 (turn)'은 하나의 완전한 '생각-행동-관찰 (think-act-observe)' 사이클을 의미합니다. 즉, 모델이 응답을 생성하고, 선택적으로 도구를 호출하며, 그 결과를 받는 과정입니다. 이러한 과정이 114번 지나갔습니다. 에이전트는 파일을 읽고, 명령어를 실행하고, 코드를 작성하며 작업을 진행했습니다. 하지만 단순히 메모리 저장소를 자신의 작업 레퍼토리 (working repertoire)의 일부로 취급하지 않았을 뿐입니다.

제가 이것을 보여줄 때 사람들이 가장 먼저 하는 말은 가이드라인 (guidance)이 충분히 강력하지 않았을 것이라는 점입니다. 이는 타당한 반사적 반응이지만, 수치는 이를 뒷받침하지 않습니다. 동일한 세트 내에서 시드(seed)를 설정하지 않은 5번의 도구 장착 실행 (tool-equipped runs) 전체를 살펴보면, 모델이 매 세션 시작 시 읽는 워크스페이스 지침 파일 (workspace instruction file)에 메모리 가이드라인에 대한 언급이 32번이나 있었음에도 불구하고, 자발적인 메모리 쓰기 (voluntary memory writes)는 실행당 0~1회에 그쳤습니다. 동일한 계열의 다른 실행에서는 에이전트에게 10개의 도구를 제공하고 파일 내에 해당 도구에 대한 언급을 30번이나 포함했음에도, 63번의 턴 (turns) 동안 도구 호출 (tool calls)이 단 한 번도 발생하지 않았습니다. 여기서 올라갈 수 있는 용량-반응 곡선 (dose-response curve)은 존재하지 않습니다. 더 많은 단어를 사용한다고 해서 더 많은 호출을 얻어낼 수 있는 것이 아니었습니다.

두 번째 반사적 반응은 이것이 제3자 도구 (third-party tooling)에 대한 편향이라는 것인데, 이는 더 흥미로운 가설이지만 역시 틀렸습니다. 하네스 (harness)는 자체적인 네이티브 메모리 기능 (native memory feature)을 제공합니다. 즉, 모델이 스스로 노트를 작성하도록 훈련된 내장 디렉토리 (built-in directory)가 있으며, 외부 서버가 관여하지 않고 학습해야 할 도구 스키마 (tool schema)도 없습니다. 하지만 어떤 arm의 실행에서도 해당 디렉토리는 생성되지 않았습니다. 따라서 모델은 채굴을 위해 자체 옵션을 선호한 것이 아니라, 작업 중간에 멈춰서 메모리 위생 (memory hygiene) 작업을 수행하는 범주 자체를 거부하고 있었던 것입니다.

세 번째 반사적 반응, 즉 작업이 메모리를 필요로 할 만큼 충분히 어렵지 않았다는 생각은 이를 배제하기 위해 별도의 추가 실험이 필요했던 부분이며, 섹션 05에서 그 내용을 다룹니다. 이는 이 프로젝트에서 가장 기이한 결과입니다.