컨텍스트 윈도우가 압축될 때 에이전트의 기억을 잃는 문제: 설계상 그렇지 않도록 구현

이번 주에 컨텍스트-윈도우 컴팩션(context-window compaction)을 '200k 토큰 로보토미(lobotomy)'라고 부르고, Memento라는 이름의 외부 상태 파일로 이를 패치한 글이 있었습니다. 잘 쓰인 글이며, 명명법은 그 위험성을 정직하게 다루고 있습니다. 하지만 이 글은 근본적인 문제를 해결책보다 더 쉽게 보이게 만들었습니다.

cover

중요한 부분은 다음과 같습니다: 컨텍스트 윈도우 내부에만 존재하는 메모리는 구조적으로 기억을 잃습니다(amnesiac). 컴팩션은 그 설계의 버그가 아니라, 명시된 대로 작동하는 설계 자체입니다. 이 윈도우는 예산(budget)이 있고, 예산이 소진되면 무언가가 빠져나가야 하며, 무엇이 빠져나갈지는 사용자(당신)가 결정하는 것이 아니라 요약기(summariser)가 결정합니다.

제가 대응한 실패 지점은 바로 이것입니다. HyperMarrow는 Windows용 에이전트의 로컬 우선 메모리 레이어이며, 아래 속성들은 제가 실제로 강제하는 것들입니다. 이들은 작동 시점이 빠른 순서로 배열되었는데, 위에서 언급된 모든 실패는 읽기 시간(read time)이 아니라 쓰기 시간(write time)에 결정되기 때문입니다.

1. 출처와 타임스탬프가 기록된 의사결정 (Decisions are written down with a source and a timestamp)

선호도, 결정 또는 결론은 어디서 왔는지, 언제였는지를 담은 실제 기록으로 영구적인 로컬 스토리지에 저장됩니다. 매 턴마다 대화록(transcript)에서 재파생되는 가정은 주소도, 출처도, 이력도 없기 때문에 컴팩션되어 사라지게 할 것도 없고 복구할 것도 없습니다. 일단 기록이 출처(provenance)를 갖게 되면, 에이전트가 믿는 것과 그 이유가 더 이상 논거(argument)가 아니라 조회 가능한 데이터(lookup)가 됩니다.

2. 컴팩션 전에 쓰기 (Write before you compact)

영구적인 사본(durable copy)이 존재하고 확인되기 전까지는 작업 컨텍스트를 요약하거나 삭제하는 것이 허용되지 않습니다. 이것은 쓰기 선행 규칙(write-ahead rule)이며, 다섯 가지 중 가장 먼저 작동합니다. 만약 컴팩션이 먼저 실행된다면, 그것이 삭제한 것은 사라지고 그 손실에 대해 오류가 발생하지 않습니다. 그저 조용히 무언가를 가져갈 뿐입니다.

이것은 또한 '뇌절제술(lobotomy)' 게시물에 직접적으로 답하는 규칙입니다. 프롬프트에 로드된 상태 파일은 여전히 창 안에 있습니다. 다른 모든 것과 마찬가지로 다음 압축 과정에서 요약됩니다. 이 규칙은 영구적인 사본이 저장소이고, 프롬프트가 그 위에 대한 뷰일 때만 작동합니다.

3. 망각은 경계 지어 계획되며; 고정된 기록은 절대 사라지지 않습니다

무한한 메모리는 기능이 아닙니다. 관련성이 없어지면 기록들은 영원히 유지되는 것이 아니라 일정에 따라 만료되고, 사용자가 명시적으로 고정한 기록은 감쇠에서 면제됩니다. 경계가 없으면 검색 공간만 커지고, 긴 기록에 대한 짧은 질의는 사용할수록 나아지는 것이 아니라 더 나빠집니다.

이것이 저장소(store)와 스크래치패드(scratchpad)를 구분하는 부분입니다. 스크래치패드는 전체 삭제로 다듬어져야 합니다. 반면, 저장소는 무언가를 하나씩, 의도적으로 폐기할 수 있으며 무엇을 폐기했는지 알려줍니다.

4. Recall은 사용자의 단어를 돌려주고, 그 출처를 보여줍니다

작성된 내용 자체가 이미 손실적이었다면, 어떤 순위 지정기(ranker)도 실제로 필요한 문장을 복구할 수 없습니다. Recall은 패러프레이즈가 아닌 저장된 기록을 가져오며, 해당 기록이 어디에서 왔는지와 함께 그 결과를 제공합니다. 이것이 세션 간 연속성(cross-session continuity)을 실질적으로 만드는 것입니다: 한 세션에서 내린 결정이 몇 달 후 다른 세션에서도 출처와 함께 재발견될 수 있습니다.

5. 개인 정보 보호 경계는 약속이 아니라 설정입니다

기록이 어디에 저장되는지, 그리고 특정 기록이 기기를 벗어날 수 있는지 여부는 정책의 한 단락이라기보다는 구성 결정(configuration decision) 문제입니다. 로컬 우선(Local-first) 방식은 특정한 이유로 중요합니다: 만약 저장소가 사용자의 디스크에 있다면, 압축 과정은 생존할 수 있는 일시적인 사건이지만, 저장소가 공급업체(vendor)의 것이라면 장기 기억은 그들의 로드맵만큼만 지속적일 것입니다.

실제로 압축 과정을 거치는 것이 무엇을 바꾸는가

'뇌절제술'이라는 틀에 비추어 다시 읽어보세요:

• 압축이 이벤트가 아닙니다. 윈도우는 원하는 만큼 자주 압축될 수 있습니다. 왜냐하면 해당 기록은 애초에 윈도우 안에만 존재했던 것이 아니기 때문입니다.
• 무엇을 기억했는지 확인할 수 있습니다. 모든 기록은 출처를 가지고 있으므로, 요약본에서 추론하는 대신 에이전트가 실제로 보존한 내용을 확인할 수 있습니다.
• 잘못된 믿음을 수정할 수 있습니다. 잘못된 기록을 편집하는 것은 지원 티켓(support ticket)이 아니라 파일 작업입니다.
• 세션 간 연속성은 트릭이 아닌 속성입니다. 새로운 세션은 전체 대화록(transcript)을 다시 시작하는 대신, 출처가 첨부된 이전 결정을 재탐색합니다.
• 기억은 도구보다 오래갑니다. 저장소는 단순한 로컬 파일이기 때문에, 에이전트 교체, 버전 업데이트, 또는 공급업체 이탈에도 살아남습니다.

이 모듈들은 기록(record), 회상(recall), 통합(consolidation) 및 파일-브릿지(file-bridge)로 구성되어 MCP를 통해 노출되므로, 에이전트는 도구마다 맞춤형 통합을 할 필요가 없습니다.

여전히 부족한 점

• 쓰기 전 규칙(write-ahead rule)은 지연 시간 비용을 발생시킵니다. 압축 전에 영속적인 쓰기를 보장하려면, 압축이 저장 장치에 의존하게 됩니다. 느린 디스크의 경우 이는 눈에 띄는 지연이며, 이를 설명하는 정직한 방식은 '무료 승리'가 아니라 '교환(trade)'입니다.
• 제한된 망각(Bounded forgetting)은 원하는 것을 폐기할 수 있습니다. 감쇠(Decay)는 예약되고 검토 가능하지만, 여전히 정책이며, 정책은 결국 필요한 기록에 대해 잘못 판단할 수 있습니다. 고정(Pinning)이 탈출구인데, 이는 적시에 알아차리는 것에 달려있습니다.
• 출처가 정확성을 의미하지는 않습니다. 기록은 완벽하게 정직한 출처를 가지고 있어도 여전히 틀릴 수 있습니다. 저장소의 어떤 것도 이를 알려주지 않을 것입니다.
• 압축이 유일한 손실 채널은 아닙니다. 요약을 잘못하거나 애초에 손실성(lossy) 기록을 작성하는 에이전트는, 이러한 규칙들이 작동할 기회조차 생기기 전에 입력 단계에서 이미 손실합니다.

여러분 차례입니다

만약 에이전트가 압축될 만큼 오랫동안 실행된다면, 기억 문제는 프롬프트 엔지니어링 문제가 아닙니다. 더 긴 윈도우는 단지 절벽을 옮길 뿐입니다. 그러니: 에이전트가 망각할 때, 토큰 예산을 늘리는 것을 선호하시겠습니까, 아니면 저장소를 열어 무엇을 보존했는지 읽어보는 것을 선호하시겠습니까?

HyperMarrow는 Windows 데스크톱 메모리 레이어입니다. 로컬 우선(local-first) 빌드는 여기에서 확인할 수 있습니다: HyperMarrow

공개 고지: 제가 HyperMarrow를 만들었으므로, 이 점을 염두에 두고 위의 내용을 읽어주세요. 여기에 인용된 커뮤니티 게시물은 실제적이며 공개된 것이고, 본 게시물을 위해 숫자, 사용자 수 또는 추천사는 위조되지 않았습니다.