에이전트가 내가 한 행동이 아니라 말한 것만 기억하는 이유
메모리 제품은 대화 기록(Transcript)을 기반으로 구축됩니다
사용 중인 도구에서 메모리가 어디서 오는지 살펴보세요. ChatGPT의 메모리는 대화에서 파생됩니다. Claude의 메모리는 대화에서 파생됩니다. Codex는 이전 대화에서 메모리를 생성합니다. 자체 문서에서는 보관 대상을 "이전 대화의 요약, 영구 항목, 최근 입력 및 지원 증거"로 설명합니다. 코딩 에이전트는 사용자가 작성한 파일을 읽습니다.
이 모든 것은 사용자가 모델을 위해 생성한 언어의 하류(downstream)에 있습니다. 이는 실제적이고 유용한 종류의 메모리이며, 심리학자들이 흔히 의미론적(semantic) 또는 선언적(declarative) 메모리라고 부르는 것(사실, 선호도, 고정 규칙)과 유사합니다. 하지만 이것은 이벤트의 기록, 즉 실제로 어떤 애플리케이션에서 어떤 순서로 얼마나 오랫동안 작업을 수행했는지에 대한 시퀀스가 아닙니다.
'행동' 영역은 자연스러운 캡처 시점이 없습니다
채팅창에 선호도를 입력할 때 캡처는 비용이 들지 않습니다. 텍스트가 이미 존재하기 때문입니다. 하지만 관리자 패널을 클릭하고, 두 개의 스프레드시트를 대조하고, 대금 지급을 승인하기 전에 대시보드를 확인하는 등의 작업을 할 때는 에이전트가 접근할 수 있는 그 어떤 곳에도 기록이 남지 않습니다.
이것이 바로 누락된 절반이 계속 누락된 채로 남아있는 이유입니다. 벤더들이 이를 원하지 않아서가 아닙니다. 이를 수집하려면 화면을 캡처해야 하는데, 이는 완전히 다른 동의, 저장 및 보안 문제를 수반하는 전혀 다른 제품 영역이기 때문입니다. 또한 이 격차가 고정적인 이유이기도 합니다. 모델 성능이 향상된다고 해서 부수적으로 해결될 문제가 아닙니다.
모델이 활동을 요약하면 증거도 함께 사라집니다
화면 캡처를 메모리로 전환하는 가장 뻔한 방법은 모델이 화면을 지켜보고 요약본을 작성하게 하는 것입니다. 하지만 8월 6일자 프리프린트 논문인 Activity Frames: Deterministic Screen-Activity Compilation for Agent Memory and Replay (Nossa Iyamu, arXiv 2608.05784)는 그 반대를 주장하며 그 차이를 측정합니다.
이 파이프라인은 모델을 전혀 사용하지 않습니다. 로컬 캡처 스트림을 "애플리케이션, 사이트, 타이밍, 입력 볼륨 및 원본 행으로 되돌아가는 증거 포인터를 포함하는 유형화된 활동 프레임, 즉 바운디드 에피소드로 분할하며, 루프에 모델이 개입하지 않으므로 출력은 바이트 단위로 동일하고 캐싱 가능하며 기계적으로 감사할 수 있습니다." 저자의 51일간의 활성 데이터에 걸친 128,756개 프레임 코퍼스에서, 하루 분량의 원본 캡처를 컴파일한 결과 68ms 만에 86배 더 작은 프롬프트 준비 완료 컨텍스트 블록이 생성되었으며, 이 블록을 읽은 에이전트는 독립적인 오라클(oracle) 대비 98.4%의 정확도(Wilson 95% CI 91.7–99.7%)로 그날의 질문에 답변했습니다. 이는 "동일한 캡처에 대한 LLM 요약의 정확도인 66-80%와 대조적"입니다.
헤드라인보다 더 중요한 두 가지 주의 사항이 있습니다. 이 논문은 동료 평가(peer-review)를 거치지 않은 프리프린트이며, 코퍼스는 한 전문가의 개인 단일 사용자 데이터입니다. 즉, 이 수치는 여러분의 팀이 아닌 해당 설정에 국한된 결과입니다. 또한 66~80%라는 수치는 동일한 캡처 스트림에 대한 언어 모델 요약과 논문 자체의 비교 결과일 뿐이며, 현재 출시된 실제 제품을 측정한 것이 아닙니다.
이러한 주의 사항에도 불구하고 유효한 것은 구조적인 관점이며, 이는 문서 처리가 작동하는 방식과 동일합니다. 요약은 그것을 생성한 원본으로 되돌아가는 포인터가 없는 손실이 발생하는 결과물(lossy artifact)입니다. 반면 프레임은 증거 포인터를 유지하므로 직접 확인할 수 있습니다.
활동이 캡처되는 경우, 정확히 단 하나의 도구에만 저장됩니다
OpenAI는 이미 이 카테고리의 제품을 제공하고 있습니다. macOS용 ChatGPT Pro 구독자를 위한 옵트인(opt-in) 연구 프리뷰로 문서화된 Chronicle은 최근 화면 활동을 기반으로 Codex 메모리를 구축합니다. 이 문서의 설명은 놀라울 정도로 구체적입니다. 화면 캡처는 로컬 임시 디렉터리에 저장되고 6시간 후에 삭제되는 반면, 생성된 메모리는 Codex 홈 디렉터리 아래에 저장되는 "필요에 따라 읽고 수정할 수 있는 암호화되지 않은 마크다운 파일"입니다. 이를 생성하기 위해 "스크린샷 프레임, 스크린샷에서 추출한 OCR 텍스트, 타이밍 정보 및 로컬 파일 경로"가 OpenAI 서버에서 처리됩니다. 또한 OpenAI는 백그라운드 에이전트가 "요청 제한(rate limits)을 빠르게 소모"하며, Chronicle을 사용하면 "화면 콘텐츠로 인한 프롬프트 주입(prompt injection) 공격 위험이 증가한다"고 명시하고 있습니다.
이는 벤더가 까다로운 기능에 대해 솔직하게 밝힌 것이며, 디자인 선택 또한 타당합니다. 하지만 출력이 어디로 가는지 주목하십시오. 바로 Codex의 로컬 메모리 저장소, 즉 Codex만 읽을 수 있는 단 한 대의 기기 내부입니다. 논문과 함께 제공되는 오픈 소스 프로젝트는 이와 대칭되는 선택을 합니다. 로컬 SQLite 데이터베이스에 캡처하고, 로컬에서 컴파일하고, MCP를 통해 제공하는 방식입니다. 이 역시 출력은 캡처를 수행한 기기에만 존재하게 됩니다.
따라서 오늘날 가장 이상적인 경우라 할지라도, 여러분이 한 행동의 기록은 단 한 대의 노트북에 있는 단 하나의 클라이언트만 읽을 수 있습니다. 정작 여러분이 화요일 아침에 대해 실제로 질문할 어시스턴트는 다른 어시스턴트일 수 있는데 말이죠.
사람들이 시도하는 방법들
루틴을 다시 설명하기. 가장 기본적인 방법입니다. 11단계의 과정을 설명하면 에이전트가 제법 잘 수행하지만, 다음 주에 다시 똑같이 설명해야 합니다. 이 논문의 핵심 동기는 바로 이 비용에 있습니다. 에이전트는 "사용자가 이미 수행한 루틴을 다시 도출하기 위해 값비싼 프론티어 모델의 추론 비용을 온전히 지불"해야 합니다.
에이전트에게 결과물(Artifacts)을 가리키기. Git 로그, 티켓 이력, 브라우저 방문 기록, 내보낸 보고서 등이 있습니다. 실제로 유용하며 가장 저렴하게 근사치를 얻을 수 있는 방법이지만, 결과물은 시퀀스가 아닌 '결과'만을 기록합니다. 커밋(commit)은 무엇이 변경되었는지는 알려주지만, 그 전에 거친 20분간의 확인 과정은 알려주지 않습니다.
범용 화면 녹화 도구. Rewind 스타일의 도구나 최신 로컬 우선(local-first) 녹화 도구는 사용자를 위한 검색 가능한 기록을 생성합니다. 일부 도구는 이제 이를 에이전트에 노출하기도 합니다. 시도해 볼 가치가 있으며, 각 도구에 던져야 할 질문은 동일합니다. 출력이 원본 캡처로 되돌아가는 포인터를 포함하고 있는가, 아니면 사용자의 오후 일과에 대한 모델의 주관적인 인상(impression)에 불과한가?
Chronicle. Mac을 사용하는 Pro 구독자이고 주로 Codex에서 작업한다면, 이는 '행동' 영역을 캡처하는 가장 빠른 지름길입니다. 활성화하기 전에 요청 제한 및 프롬프트 주입에 관한 문서를 반드시 읽어보시기 바랍니다. 적용 범위는 Codex로 제한됩니다.
사후에 직접 런북(Runbook) 작성하기. 가장 정확도가 높은 옵션이지만, 아무도 지속적으로 유지하지 못하는 방법입니다. 이것이 바로 자동 캡처가 계속해서 시도되는 솔직한 이유입니다.
이 목록의 전반적인 형태를 주목해 보세요. 기록이 아예 수집되지 않거나, 수집되더라도 단 하나의 도구만 읽을 수 있는 곳에 저장됩니다.
해결책: 두 영역 모두 접근할 수 있는 단 하나의 저장소 마련하기
종종 혼동되지만, 다음 두 가지는 모두 사실입니다. 일화적 캡처(Episodic capture)는 '캡처'의 문제입니다. 사용자의 동의 하에 무언가가 지켜보고 있어야 하며, 그 어떤 메모리 레이어도 이 사실을 바꿀 수 없습니다. 반면, 그 이후에 기록에 일어나는 일은 '저장 및 액세스'의 문제입니다. 오늘날 대부분의 가치가 손실되는 지점이 바로 여기입니다.
따라서 작업을 명확히 분리하십시오. '행동' 영역을 원한다면 캡처 도구를 선택하고 개인정보 보호 문서를 꼼꼼히 읽어보세요. 그런 다음 컴파일된 출력물과 이미 보유하고 있는 선언적 영역(사양, 결정 사항, 제약 조건 등)이 단일 클라이언트의 로컬 디렉터리나 채팅 기록이 아닌, 여러분이 사용하는 모든 어시스턴트가 읽을 수 있는 곳에 저장되도록 하십시오.
MemoryLake는 이 두 번째 작업을 위한 메모리 레이어입니다. 문서, 결정 사항, 컴파일된 기록이 저장되는 단일 저장소로, Claude 및 Codex와 같은 MCP 지원 도구에서 직접 읽을 수 있으며, ChatGPT에서는 API를 통해 읽을 수 있습니다. 오해를 방지하기 위해 명확히 말씀드리면, MemoryLake는 화면을 감시하지 않으며, 일화적 기록이 필요한 경우 캡처 도구를 대체할 수 없습니다.
1단계: API 키 생성
약 30초 만에 키를 생성하고 첫 번째 요청을 보낼 수 있습니다. 채팅 창에 붙여넣는 대신 환경 변수나 보안 비밀 관리자(secret manager)에 보관하세요.
2단계: 첫 번째 메모리 업로드
현재 매번 다시 설명하고 있는 문서, 이미지, 파일(런북, 사양서, 제약 조건, 결정 기록, 내보낸 보고서 등)을 업로드하세요. 컴파일된 마크다운이나 구조화된 출력을 생성하는 캡처 도구를 사용 중이라면 해당 출력물도 여기에 저장해야 합니다. 이때 요약의 요약본이 아니라 생성된 원본 그대로 업로드하십시오.
3단계: AI 및 에이전트 연결
Claude, Codex, OpenClaw 및 기타 AI 에이전트가 MCP 또는 API를 통해 메모리에 액세스할 수 있도록 허용합니다. ChatGPT에는 MCP 클라이언트가 없으므로 API를 통해 필요한 내용을 검색하여 프롬프트나 모델을 호출하는 워크플로우에 주입합니다. 이 단계의 핵심은 동일한 기록이 여러 도구에 대응할 수 있다는 점이며, 이는 로컬 캡처 저장소가 단독으로 수행할 수 없는 부분입니다.
실제 업무에서 달라지는 점
첫 번째 차이점은 비용이 많이 드는 '행동' 영역을 다시 도출할 필요가 없어진다는 것입니다. 루틴의 기록이 캡처 도구에서 나왔든, 사용자가 10분 동안 직접 작성한 것이든 관계없이, 이를 읽는 에이전트는 과정을 재구성하는 대신 실제로 일어난 일에서부터 시작합니다. 논문에서 보여준 데모는 이의 극단적인 버전으로, 모델 개입 없이 컴파일된 루틴이 "결정론적으로 재실행(replay)"되어 모델 토큰을 전혀 소모하지 않습니다.
두 번째는 출처(provenance)가 보존된다는 점입니다. 이는 AI 시스템이 무언가를 자신 있게 말할 때마다 제기되는 주장과 같습니다. 유용한 기록은 측정된 것과 추론된 것을 구분합니다. 요약은 바로 이 구분을 파괴하며, 이것이 사용자에 대해 그럴듯한 사실을 지어내는 AI 시스템을 잡아내기 어려운 이유입니다. 추론과 관찰이 동일한 문장 안에서 동일한 확신을 가지고 전달되기 때문입니다.
세 번째는 기록이 그것을 생성한 도구보다 오래 지속된다는 점입니다. 캡처 저장소는 설계상 기기 로컬에 종속됩니다. 공유 레이어를 사용하면 이번 분기에 축적한 노트가 에디터를 전환하거나, 노트북을 바꾸거나, 두 번째 에이전트를 추가한 후에도 그대로 유지됩니다. 그리고 여러 도구에서 접근 가능한 단일 메모리는 단일 클라이언트의 메모리 기능과는 완전히 다른 특성을 가집니다.
또한 이미 실행 중인 도구들과 유기적으로 결합됩니다. Codex 메모리, Claude Code의 프로젝트 메모리, ChatGPT's 저장된 메모리는 계속해서 로컬 역할을 수행합니다. 다만 이들이 할 수 없는 것은 서로의 메모리를 읽는 것이며, 이것이 바로 멀티 에이전트 구성이 인계 과정마다 컨텍스트를 잃어버리는 근본적인 이유입니다.
일화 기억을 위한 모범 사례
기능을 켜기 전에 무엇을 캡처할지 결정하세요
화면 캡처는 무해한 기본 설정이 아닙니다. 저장 및 보존 세부 정보를 읽고, 기기 외부로 전송되는 데이터를 확인하고, 업무 중에 고객 작업, 자격 증명 또는 규제 대상 데이터가 화면에 노출되는지 고려하십시오. 화면 콘텐츠로 인한 프롬프트 주입에 대한 Chronicle 문서의 경고는 두 번 읽어볼 가치가 있습니다. 여러분이 방문한 페이지가 에이전트가 따르게 될 지시 사항을 포함하고 있을 수 있기 때문입니다.
원본을 가리키는 포인터가 있는 기록을 선호하세요
증거 포인터가 있는 프레임이든, 파일 경로를 인용하는 런북이든, 원인이 된 장애 사건을 인용하는 결정 기록이든, 검증할 수 있는 메모리는 검증할 수 없는 여러 개의 메모리보다 훨씬 가치 있습니다. 요약은 실제로 어떤 일이 일어났는지 확인해야 하는 순간이 오기 전까지만 효율적으로 느껴질 뿐입니다.
두 영역을 분리하되 인접하게 유지하세요
결정한 내용과 행동한 내용은 서로 다른 기록이므로 하나의 내러티브로 병합되어서는 안 됩니다. 둘 다 저장하고 각각 라벨을 지정한 다음, 질문에 필요한 기록을 검색을 통해 가져오도록 하십시오. 이를 하나로 압축해 버리면 "대시보드를 먼저 확인했다"가 "대시보드 확인을 선호함"으로 왜곡되어 버립니다.
루틴이 캡처 저장소에만 머물게 하지 마세요
자동화할 만큼 중요한 루틴이라면 짧은 문서로도 작성해 두십시오. 캡처 저장소는 기기 로컬에 종속되고, 옵트인 방식이며, 때로는 연구 프리뷰에 불과합니다. 공유 저장소에 있는 다섯 줄짜리 런북은 이 세 가지 제약 조건에서 모두 살아남으며, 새로운 팀원이 읽을 수도 있습니다.
"에이전트가 이미 알고 있다"는 말을 검증해야 할 주장으로 취급하세요
이러한 실패 모드는 조용히 일어납니다. 일화적 기록이 없는 에이전트는 이를 알리지 않고, 그저 그럴듯한 워크플로우를 만들어냅니다. 절차적인 작업을 위임하기 전에 에이전트에게 단계를 다시 설명해 보라고 요청하고, 여러분이 어디에도 기록한 적 없는 단계가 포함되어 있는지 주의 깊게 살펴보십시오.
결론
일화 기억은 아직 아무도 완성하지 못한 에이전트 메모리의 절반입니다. 오늘날의 기능들은 대화 기록을 기반으로 구축되어 있으므로, 사용자가 한 행동이 아니라 말한 것만 기억합니다. 이는 앞서 언급한 논문의 프레이밍이자 논문이 존재하는 이유이기도 합니다. '행동' 영역을 해결하려는 현재의 두 가지 시도는 모두 화면을 캡처하는 방식으로 작동하며, 둘 다 결과를 단 한 대의 기기에 있는 단 하나의 도구에 남겨둡니다. OpenAI의 Chronicle은 Codex의 로컬 메모리 저장소에, 오픈 소스 컴파일러는 MCP를 통해 제공되는 로컬 데이터베이스에 저장합니다.
실질적인 해결책은 마냥 기다리는 것이 아닙니다. 개인정보 보호와의 절충안이 수용 가능하다면 캡처 기능을 활성화하고, 증거 포인터가 없는 모델 요약본보다는 포인터가 유지되는 기록을 선호하며, 축적된 모든 것(컴파일된 활동 기록과 화면에 전혀 노출되지 않은 사양 및 결정 사항)이 둘 이상의 어시스턴트가 읽을 수 있는 곳에 저장되도록 하십시오. 기록은 그것을 생성한 도구보다 더 가치 있습니다.