에이전트의 메모리를 프롬프트에 무작정 쏟아붓는 것을 멈추세요

Long-horizon 에이전트들은 마치 지능(intelligence)이 주요 문제인 것처럼 계속해서 평가받고 있습니다. 제 생각에 이는 실제로 문제를 일으키는 지루한 부분, 즉 다음 결정이 무엇을 기억하도록 허용되는지를 가리고 있습니다.

새로운 논문인 AgenticSTS: A Bounded-Memory Testbed for Long-Horizon LLM Agents는 흥미롭습니다. 왜냐하면 메모리를 단순히 더 큰 컨텍스트 윈도우(context window) 경쟁으로 취급하지 않기 때문입니다. 이 논문은 메모리를 하나의 인터페이스(interface)로 취급합니다.

사소하게 들릴 수도 있지만, 그렇지 않습니다.

대부분의 에이전트 루프(agent loops)는 여전히 동일한 패턴을 기본값으로 사용합니다. 이전의 관찰(observations), 도구 호출(tool calls), 추론 흔적(reasoning traces), 성찰(reflections), 그리고 그 외 유용해 보이는 모든 것을 다음 프롬프트에 추가(append)하는 방식입니다. 이는 구축하기 쉽습니다. 하지만 동시에 프롬프트를 잡동사니 서랍(junk drawer)으로 만들어버리는 방식이기도 합니다. 모델은 더 많은 것을 볼 수 있게 되지만, 어떤 메모리 조각이 해당 결정을 유발했는지 더 이상 알 수 없게 됩니다.

AgenticSTS는 더 날카로운 전략을 취합니다. 가공되지 않은 기록(raw transcript)을 추가하지 마십시오. 각 결정에 대해, 정해진 슬롯(typed slots)으로부터 새로운 프롬프트를 구성하십시오.

이 논문은 테스트베드(testbed)로 Slay the Spire 2를 사용하는데, 이는 좋은 선택입니다. 이는 사용자의 선호도 하나를 기억하는 것이 메모리로 간주되는 단순한 채팅 벤치마크가 아닙니다. 한 번의 플레이에는 전투, 카드, 유물(relics), 경로, 상점, 이벤트, 체력 트레이드오프(health tradeoffs), 그리고 지연된 결과(delayed consequences)와 같은 수백 가지의 전술적 및 전략적 결정이 포함됩니다. 규칙은 폐쇄적이고 텍스트로 읽을 수 있지만, 플레이 과정은 단순한 재현(replay)만으로는 해결할 수 없을 만큼 충분히 확률적(stochastic)입니다.

그것이 바로 에이전트 메모리가 중요해지기 시작하는 바로 그런 환경입니다.

유용한 아이디어: 계약으로서의 메모리

이 논문에서 가장 명쾌한 문장은 이것입니다: 메모리는 각 미래의 결정이 무엇을 볼 수 있도록 허용되는지에 대한 계약(contract)이다.

저는 이 프레임워크(framing)가 마음에 듭니다. 왜냐하면 불편한 질문을 던지게 만들기 때문입니다. 에이전트가 개선되었을 때, 메모리 계층(memory layer)이 도움이 된 것입니까, 아니면 무언가 작동할 때까지 모델에 더 많은 컨텍스트를 밀어 넣은 것뿐입니까?

AgenticSTS는 각 결정 프롬프트를 다섯 가지 계층으로 나눕니다:

1. 고정된 프로토콜 지침 (fixed protocol instructions)
2. 현재 상태 및 허용된 행동 스키마 (current state and legal action schemas)
3. 검색된 게임 규칙 (retrieved game rules)
4. 이전 실행으로부터의 에피소드 요약 (episodic summaries from prior runs)
5. 트리거된 전략적 기술 (triggered strategic skills)

중요한 점은 정확히 이 다섯 계층의 설계가 아닙니다. 중요한 점은 각 계층을 검사(inspect), 동결(freeze), 비활성화(disable)하거나 비교(compare)할 수 있다는 것입니다. 결정 과정의 가공되지 않은 전체 기록(raw cross-decision transcripts)을 단순히 덧붙이는 방식이 아닙니다.

이를 통해 메모리는 "컨텍스트 창(context window)에 들어가는 무엇이든"에서 "이 결정을 위해 어떤 유형화된 증거(typed evidence)가 선택되었는가"로 변모합니다.

에이전트를 구축하는 개발자들에게는 바로 이 부분이 벤치마킹할 가치가 있는 부분입니다.

실제 운영 중인 에이전트의 많은 실패는 신비로운 모델의 오류가 아닙니다. 그것은 컨텍스트의 실패입니다. 에이전트가 잘못된 것을 기억하거나, 옳은 것을 잊거나, 오래된 상태(stale state)를 새로운 상태(fresh state)와 혼동하거나, 세상이 변한 후에도 이전의 성찰(reflection)을 그대로 유지하는 식입니다. 만약 당신의 유일한 메모리 정책이 "더 많이 추가하기(append more)"라면, 디버깅은 고고학 작업이 되어버립니다.

유형화된 메모리 인터페이스(typed memory interface)는 당신에게 차이점(diff)을 비교할 수 있는 대상을 제공합니다.

결과는 겸손하며, 그렇기에 더 유용합니다

이 논문은 압도적인 승리를 주장하지 않으며, 이는 논문의 장점입니다.

고정된 최저 난이도 설정에서, 스캐폴드(scaffold)가 없는 베이스라인은 10게임 중 3번 승리했습니다. 트리거된 전략적 기술을 추가한 스캐폴드 환경의 셀(cells)에서는 10게임 중 6번 승리했습니다. 저자들은 표본 크기에 대해 신중합니다. 3/10 대 6/10에 대한 피셔의 정확 검정(Fisher's exact test) 결과는 p = 0.37 정도이므로, 이는 방향성을 보여줄 뿐 통계적으로 결정적인 것은 아닙니다.

이러한 주의 사항은 중요합니다. 수준 낮은 논문이라면 "3승이 6승이 되었다"를 에이전트 메모리에 대한 포괄적인 주장으로 확대 해석했을 것입니다. 하지만 이 논문은 주로 다음과 같이 말합니다. "여기 메모리 계층을 연구할 수 있을 만큼 충분히 분리 가능한, 재사용 가능한 테스트베드가 있습니다."

그것이 더 나은 기여입니다.

이번 릴리스에는 298개의 완료된 궤적 (trajectories), 조건 태그 (condition tags), 동결된 메모리 및 기술 스냅샷 (frozen memory and skill snapshots), 프롬프트 기록 (prompt records), 그리고 분석 스크립트가 포함되어 있습니다. 이는 헤드라인에 나오는 승률보다 더 중요합니다. 이는 다른 누군가가 누적 컨텍스트 (accumulating-context) 행을 추가하고, 게임과 점수 산정 방식을 일치시킨 상태에서, 제한된 메모리 (bounded memory)가 동일한 조건 하에서 전사 기록의 성장 (transcript growth)보다 실제로 더 나은 성능을 보이는지 테스트할 수 있음을 의미합니다.

그것이 바로 제가 다음에 보고 싶은 실험입니다.

왜 “그저 더 큰 컨텍스트 윈도우를 사용하라”는 것만으로는 충분하지 않은가

더 큰 윈도우 (windows)가 도움이 되기는 합니다. 하지만 이는 메모리를 설계하는 것을 피하기 위한 유혹적인 방법이기도 합니다.

에이전트가 짧은 작업을 수행한다면 히스토리 (history)를 덧붙이는 것이 대개 괜찮습니다. 하지만 장기적으로 실행되는 에이전트의 경우, 프롬프트는 사실, 오래된 사실, 부분적인 계획, 도구 출력 (tool output), 실패한 시도, 그리고 모델 스스로가 자신의 혼란을 요약한 내용이 뒤섞인 상태가 됩니다. 윈도우가 커질수록, 이것이 메모리가 아니라 퇴적물 (sediment)임에도 불구하고 여전히 메모리인 척하기가 더 쉬워집니다.

AgenticSTS 계약은 그 반대 방향을 추진합니다. 온라인 프롬프트 (online prompt)를 제한된 범위 내로 유지하십시오. 과거는 타입이 지정된 아티팩트 (typed artifacts)에 저장하십시오. 현재의 결정에 필요한 것만 검색(retrieve)하십시오. 각 메모리 경로를 감사 가능하게 (auditable) 만드십시오.

이것이 제가 실제 업무에서 에이전트 시스템이 동작하기를 원하는 방식에 더 부합합니다.

에이전트가 코드를 편집하고 있다면, 저는 다음 프롬프트에 “지금까지 일어난 모든 일”이 들어있는 것을 원하지 않습니다. 저는 현재 작업, 관련 파일, 최신 실패 테스트, 알려진 제약 조건, 그리고 아마도 이전 시도에서 어렵게 얻어낸 작은 노트 세트를 원합니다. 에이전트가 문서를 처리하고 있다면, 저는 현재 문서 상태, 스키마 (schema), 검색된 소스 구절, 그리고 현재 상황과 실제로 일치하는 이전 추출 실수들을 원합니다.

메모리는 쏟아붓는 것이 아니라 선택되어야 합니다.

실무적인 패턴

이 논문은 게임에 관한 것이지만, 이 패턴은 지루한 개발자 자동화 (developer automation) 분야에도 매우 잘 적용됩니다:

• 현재 상태 (current state)로부터 안정적인 지침 (stable instructions)을 분리할 것
• 규칙과 참조 (references)를 검색 레이어 (retrieval layer)에 유지할 것
• 이전 경험을 채팅 잔해 (chat residue)가 아닌 명시적인 기록 (explicit records)으로 저장할 것
• 반복되는 수정 사항을 트리거 가능한 기술 (triggered skills)로 승격시킬 것
• 테스트를 위해 모든 메모리 레이어 (memory layer)를 제거 가능하게 만들 것

마지막 지점은 팀들이 흔히 건너뛰는 부분입니다. 만약 특정 메모리 레이어를 끌 수 없다면, 그것이 도움이 되는지 알 방법이 없습니다. 그저 전체 덩어리가 가끔 작동한다는 사실만 알 수 있을 뿐입니다.

유용한 에이전트 하네스 (agent harness)라면 다음과 같은 지루한 질문들을 던질 수 있게 해줘야 합니다:

에피소드 노트 (episodic notes)가 도움이 되었는가, 아니면 오래된 노이즈 (stale noise)를 추가했는가?

기술 라이브러리 (skill library)가 의사결정을 개선했는가, 아니면 그것을 생성한 모델에서만 작동했는가?

검색 (retrieval)이 올바른 규칙을 찾아냈는가, 아니면 모델이 자신의 기초 지식 (base knowledge)으로 문제를 해결했는가?

에이전트가 실패한 이유가 모델이 약해서인가, 아니면 메모리 계약 (memory contract)이 잘못된 증거를 제공했기 때문인가?

이러한 질문들은 화려하지 않습니다. 하지만 이것이 에이전트 시스템이 유지보수 가능해지는 방식입니다.

나의 견해

에이전트 메모리는 더 이상 '느낌 (vibes)'의 레이어로 취급되어서는 안 됩니다.

기본 설정이 "모델이 혼란스러워질 때까지 대화 기록 (transcript)을 추가하다가, 그 후에 기록을 요약하고 요행을 바라는 것"이 되어서는 안 됩니다. 기본 설정은 작은 계약 (contract)이어야 합니다: 무엇이 다음 의사결정에 들어가는지, 그것이 어디서 왔는지, 언제 작성되었는지, 그리고 어떻게 비활성화할 수 있는지에 대한 계약 말입니다.

AgenticSTS가 제한된 타입형 메모리 (bounded typed memory)가 컨텍스트를 축적하는 것보다 항상 더 낫다는 것을 증명하는 것은 아닙니다. 논문에서도 그 점을 명시하고 있습니다. 다만, 이 논문은 비교를 수행하는 더 깔끔한 방법을 보여줍니다.

저에게 있어 중요한 변화는 바로 이것입니다. 다음에 등장할 유용한 에이전트 벤치마크는 가장 긴 작업을 수행하거나 가장 화려한 모델을 가진 것이 아닙니다. 하나의 메모리 레이어를 변경했을 때 그 결과를 신뢰할 수 있는 벤치마크입니다.

만약 당신의 에이전트가 무엇을 기억하도록 허용되었는지 설명할 수 없다면, 그것은 아직 메모리를 가진 것이 아닙니다. 그것은 그저 지하실이 있는 프롬프트 (prompt with a basement)일 뿐입니다.

유용한 메모리와 컨텍스트 사재기 (context hoarding) 사이의 경계선을 어디에 그으시겠습니까?