AI 메모리에 대한 대부분의 견해는 더 많이 기억하는 것에 초점을 맞춥니다. 저는 그것이 잘못된 목표라고 생각합니다. 질문은 당신의 에이전트(Agent)가 얼마나 많이 기억하느냐가 아닙니다. 그것은 관련성이 없어 보일 때 무엇이 계속 남아 있느냐 하는 것입니다.

제가 계속해서 마주쳤던 실패 사례가 있습니다. 에이전트가 잊지 말아야 했던 가장 중요한 것, 즉 폐기된 옵션이나 엄격한 제약 조건(Hard constraint)은 대개 눈앞의 작업과 가장 관련이 없어 보이는 것이었습니다. 따라서 관련성(Relevance)에 따라 컨텍스트(Context)를 추출하는 모든 시스템은, 정작 저를 구해줄 수 있는 바로 그 순간에 그것의 가중치를 조용히 낮춰버릴 것입니다. 에이전트가 3번의 세션 전에 당신이 배제했던 바로 그 방식을 즐겁게 다시 제안할 때서야 당신은 이를 깨닫게 됩니다.

관련성 기반 추출(Pull-by-relevance)은 상태 기반 주입(Push-by-state)이 아니다

이 점은 로컬 우선(Local-first) 메모리 엔진인 Bastra Recall을 만드는 Daniel Nevoigt와 dev.to에서 주고받은 대화 중에 명확해졌습니다. 그는 제가 했던 것보다 더 나은 명칭을 붙였기에, 그의 프레임워크를 사용하겠습니다.

리콜 엔진(Recall engine)은 **관련성 기반 추출 (Pull-by-relevance)**입니다. 모델이 요청하면, 랭커(Ranker)가 이번 턴(Turn)에 관련 있어 보이는 것을 답변으로 내놓습니다. 이는 좋은 방식이며, 제대로 된 랭커를 구현하는 것이 어려운 부분입니다. 왜냐하면 전체 컨텍스트 윈도우(Context window)는 성능이 저하되기 때문입니다 (Lost-in-the-middle 현상은 잘 알려져 있습니다). 당신은 단순히 메모리를 저장하는 것이 아니라, 컨텍스트 윈도우를 배급(Rationing)하고 있는 것입니다.

운영 표면(Operating surface)은 **상태 기반 주입 (Push-by-state)**입니다. 프로세스가 현재의 턴이 무엇을 필요로 한다고 생각하든 상관없이 반드시 존재해야 하는 것을 결정합니다. 폐기된 옵션, 열려 있는 결정(Open decision), 제약 조건 등이 이에 해당합니다. 이것들은 턴이 그것들을 필요로 하지 않는다고 생각할 때 바로 제 역할을 수행합니다. 하나의 랭커가 두 가지 목적을 모두 수행할 수는 없으므로, 하나가 다른 하나인 척하는 것이 아니라 두 개의 레이어(Layer)를 모두 가져야 합니다.

당신이 가장 잊지 말아야 할 것은 종종 해피 패스(Happy-path) 턴에서 가장 관련 없어 보이는 것입니다.

어려운 작업은 고정 해제(Unpinning)이다

명백한 해결책은 중요한 것들을 고정(Pin)하여 항상 로드되도록 하는 것입니다. 그것은 절반만 맞는 말입니다. 고정하는 것은 쉽습니다. 어려운 작업은 고정을 해제(Unpinning)하는 것입니다.

계속해서 늘어나기만 하는 고정된(pinned) 세트는 항상 로드되어 있는 두 번째 블롭(blob)이 되어버리며, 이는 컨텍스트 윈도우(context-window) 문제를 한 단계 위에서 재구축한 꼴이 됩니다. 따라서 중요한 부분은 생명주기(lifecycle)입니다. 결정이 열릴(open) 때 고정하고, 결정이 확정(settle)되면 다시 관련성(relevance) 단계로 강등(demote)하며, 제약 조건이 사라지면 은퇴(retire)시키는 것입니다. 그리고 수동으로 관리하는 고정 목록(pin list)을 원해서는 안 됩니다. 멤버십은 이미 추적하고 있는 상태(state)로부터 자연스럽게 도출되어야 합니다. '열림(Open)'은 '확정(Settled)'이 되고, '활성(Active)'은 '대체(Superseded)'됩니다. 세트는 누군가가 토글(toggle)하는 것을 기억해야 하는 플래그(flag)가 아니라, 결정 이벤트(decision events)를 기반으로 스스로를 큐레이션(curate)해야 합니다.

결정은 열려 있는 동안 고정되고, 확정되면 강등되며, 대체되면 은퇴합니다. 세트는 수동 목록이 아니라 상태(status)를 기반으로 스스로를 큐레이션합니다.

그렇기 때문에 저에게는 세션에서 살아남는 것이 하나가 아니라 두 가지 서로 다른 것입니다:

• 확정된 결론 (settled conclusion): 우리가 결정한 것, 사실, 선택된 접근 방식입니다. 회상 엔진(recall engine)이 이를 잘 처리합니다.
• 오픈 루프 (open loop): 아직 결정되지 않은 것, 지난 세션 이후 변경된 것, 다음 단계가 무엇인지에 대한 것입니다. 이것은 미완성된 부분이기 때문에 검색할 확정된 진실이 없습니다. 이것은 가장 먼저 부패하며, 작업 내용 중 아직 아무것도 이를 참조하지 않기 때문에 관련성 랭커(relevance ranker)가 붙잡을 수 있는 것이 아무것도 없습니다.

내가 실제로 하는 일

나는 에이전트가 작업 시작 시 읽고 작업 종료 시 다시 쓰는 일반 마크다운(Markdown) 파일에 오픈 루프를 유지합니다. 결정 사항은 상태(status)를 가지며, 미결 질문은 별도의 파일에 존재하고, 모든 작업은 세트가 최신 상태를 유지할 수 있도록 작은 쓰기(write-back) 단계로 끝납니다.

## decisions/decisions_log.md
- 2026-06-20  채널 출시 = 블로그 우선, 그 다음 dev.to.   status: accepted
- 2026-06-21  리포지토리 이름을 "cowork-os"로 명명.                   status: locked
...

그 status 필드가 핵심 비결입니다. open은 에이전트(agent)의 눈앞에 계속 머물러 있음을 의미합니다. locked는 관련성(relevance) 단계로 물러날 수 있음을 의미하며, 엔진은 턴(turn)이 필요할 때 이를 다시 표면화(surface)할 것입니다. 저는 파일을 열어 시스템이 무엇을 사실이라고 믿고 있는지 정확히 확인하고, 만약 틀렸다면 해당 라인을 수정할 수 있습니다.

이것은 메모리 엔진(memory engine)이 아니며, 메모리 엔진을 대체하는 것도 아닙니다. 네이티브 메모리(Native memory)는 존재하며, 저 또한 그것을 사용합니다. Bastra와 같은 회상 엔진(Recall engines)은 실재하며 사실 계층(fact layer)에서 뛰어난 성능을 발휘합니다. 이것은 그 위의 계층입니다. 즉, 회상 엔진과 대립하는 것이 아니라 회상 엔진과 나란히 자리하며, 당신이 읽고 통제하는 운영 상태(operating state)입니다.

저는 이것을 Claude Cowork를 위한 오픈 소스 키트인 cowork-os로 패키징했습니다. 폴더 구조, 쓰기 작업 습관(write-back habit)을 강제하는 지침, 그리고 반복적인 루틴(routines)이 포함되어 있습니다. MIT 라이선스이며, 명령어 하나로 설치 가능합니다. 만약 이것이 당신의 에이전트에게 당신의 결정을 다시 설명해야 하는 수고를 덜어준다면, 스타(star)를 눌러주는 것이 다른 사람들이 이를 찾는 데 도움이 됩니다.

이 분야에서 무언가를 구축해 본 분들께 질문 하나 드립니다. 에이전트가 당신이 이미 배제한 사항을 다시 제안할 때, 그것은 검색(retrieval)의 실패인가요, 아니면 폐기된 옵션이 관련성 게이트(relevance-gated)가 없는 적절한 저장 공간을 갖지 못했기 때문인가요?