에이전트 기억이 파일로 내려왔다, AMP 초안과 OpenAI의 다른 길

AI 에이전트의 "기억"이 점점 제품 소개 문구에서 개발자 인프라의 구체적인 파일과 프로토콜로 내려오고 있습니다. OpenAI는 Agents SDK의 sandbox agents 문서에서 agent memory beta 기능을 설명하며, 실행 기록을 다음 실행에서 재사용할 수 있는 파일 아티팩트로 정리하는 방식을 공개했습니다. 한편 Agent Memory Protocol, 줄여서 AMP는 Markdown-first, Git-friendly, MCP/filesystem 통합을 앞세운 v0.1 draft를 내놓았습니다.

둘은 같은 종류의 제품이 아닙니다. OpenAI의 memory는 Agents SDK 안에서 sandbox agent 실행을 더 싸고 빠르게 만들기 위한 기능입니다. AMP는 아직 reference implementation도 planned 상태인 독립 포맷 초안입니다. 그런데 같은 주에 가까운 시점에서 두 흐름을 나란히 보면 중요한 변화가 보입니다. 에이전트 기억은 이제 "대화 내역을 길게 넣는다"거나 "모델이 알아서 기억한다"는 수준을 넘어, 누가 읽고 쓸 수 있는지, 어떤 기록이 원본 증거인지, 어떤 기억이 오래되어 폐기되어야 하는지, 다른 런타임으로 옮길 수 있는지를 묻는 운영 계층의 문제가 되고 있습니다.

기억은 세션 로그가 아니라 운영 상태가 됩니다

OpenAI 문서의 흥미로운 지점은 memory를 일반적인 대화 세션과 분리한다는 점입니다. SDK의 conversational Session은 메시지 히스토리를 다루지만, sandbox agent memory는 future runs가 과거 실행에서 배울 수 있도록 lesson을 workspace 파일로 distill한다고 설명합니다. 기본 레이아웃에는 memory_summary.md, MEMORY.md, raw_memories.md, raw_memories/, rollout_summaries/가 들어갑니다. 실행이 끝나면 conversation extraction과 layout consolidation의 두 단계를 거쳐 raw memory와 요약 메모리를 만듭니다.

이 설계는 작지만 중요한 방향 전환입니다. 에이전트가 "기억한다"는 말이 더 이상 벤더의 서버 어딘가에 숨은 상태를 뜻하지 않습니다. 최소한 개발자 도구 관점에서는 기억이 파일이 되고, 요약이 되고, raw evidence와 consolidated lesson으로 나뉩니다. 문서는 memory가 민감 데이터를 포함할 수 있으므로 workspace와 같은 수준의 retention policy를 적용하라고도 경고합니다. 즉 memory는 prompt optimization이 아니라 데이터 거버넌스 대상입니다.

AMP가 같은 문제를 더 노골적으로 밀어붙입니다. AMP README는 에이전트가 쌓는 지식, 선호, 결정, 절차가 보이지 않고, provider를 바꾸면 잠기며, prune/merge/version/audit하기 어렵고, framework마다 호환되지 않는다고 문제를 정의합니다. 해결책은 .amp/ 디렉터리입니다. amp.yaml manifest, nodes/ 아래의 Markdown memory node, ephemeral daily note, 재생성 가능한 index/를 둡니다. 각 node는 frontmatter를 갖고 fact, preference, episode, procedure, reflection 같은 타입으로 분류됩니다.

.amp/
├── amp.yaml
├── nodes/
│   ├── facts/
│   ├── preferences/
│   ├── episodes/
│   └── procedures/
├── daily/
└── index/

핵심은 저장소가 특별한 데이터베이스가 아니라는 점입니다. Markdown으로 읽을 수 있고, wiki-link로 연결하며, Git으로 변경 이력을 남기고, 폴더를 복사하면 migration이 되도록 설계합니다. 이것은 화려한 장기 기억 알고리즘이라기보다 "AI agent가 남기는 상태를 사람이 검토할 수 있는 문서 저장소로 만들자"는 주장에 가깝습니다.

OpenAI 경로와 AMP 경로는 서로 다른 질문을 풉니다

OpenAI의 경로는 product-integrated memory입니다. 에이전트가 sandbox에서 파일을 읽고, shell을 실행하고, patch를 만들고, 여러 run을 거치며 작업할 때 이전 실행에서 얻은 correction과 lesson을 재사용합니다. 비용 절감도 명시된 목표입니다. 같은 workflow를 다시 탐색하지 않아 agent cost를 줄이고, 사용자가 선호를 반복 설명하지 않아 user cost를 줄이며, 과거 thread를 찾아 붙이지 않아 context cost를 줄입니다.

AMP의 경로는 portable memory입니다. 어떤 에이전트 프레임워크를 쓰든 .amp/ 디렉터리 구조를 읽을 수 있다면 기억을 옮길 수 있어야 합니다. agent integration spec은 세 가지 표면을 제안합니다. MCP 서버는 amp_store, amp_recall, amp_search, amp_forget, amp_link 같은 tool을 노출합니다. resource protocol은 amp://store_id/recall?context=... 같은 URI로 필요한 memory slice를 읽게 합니다. filesystem convention은 Claude Code, Codex, Cursor, OpenClaw처럼 workspace 파일을 직접 다루는 에이전트가 Markdown을 읽고 쓰는 가장 단순한 통합 경로입니다.

이 차이는 개발자가 선택해야 할 질문을 바꿉니다. "어떤 벡터 DB가 recall을 잘하나"만 묻는다면 memory는 검색 문제입니다. 하지만 "이 기억이 나중에 tool call을 바꿨을 때 어디서 온 사실인지 증명할 수 있나"를 묻는 순간 memory는 provenance 문제입니다. "이 에이전트를 Claude Code에서 Codex나 사내 agent runtime으로 옮기면 팀 선호와 절차도 따라오나"를 묻는 순간 memory는 portability 문제입니다. "잘못된 기억을 누가 supersede하고, audit log는 어디에 남나"를 묻는 순간 memory는 운영 정책 문제입니다.

MCP 다음 전장이 왜 memory인가

MCP는 도구 호출의 공통 표면을 만들었습니다. 하지만 도구를 호출하기 전에 agent가 어떤 상태를 참고했는지는 아직 훨씬 덜 표준화되어 있습니다. 같은 search_docs tool을 호출하더라도, agent가 이전에 저장한 "이 고객은 EU region만 허용한다"는 기억을 참고했는지, 아니면 오래된 "US region이 기본"이라는 기억을 참고했는지에 따라 결과가 완전히 달라집니다.

AMP가 MCP integration을 강조하는 이유도 여기에 있습니다. tool은 agent가 바깥 세계를 건드리는 순간을 표준화합니다. memory는 agent가 왜 그 행동을 하려 했는지를 설명하는 내부 증거층입니다. MCP tool verb로 memory를 표준화하는 것이 최종 답인지는 아직 알 수 없습니다. 실제로 Reddit r/mcp 토론에서도 회의적인 반응이 있었습니다. 어떤 사용자는 memory를 MCP tool과 같은 verb로 다루는 것이 맞는지 의문을 제기했고, 다른 댓글은 conformance test가 recall determinism, duplicate/conflict consolidation, provenance preservation을 확인해야 한다고 지적했습니다.

이 비판은 중요합니다. memory API가 store와 recall만 제공하면 개발자 입장에서는 또 다른 RAG wrapper입니다. 프로덕션에서 필요한 것은 더 까다롭습니다. 동일한 query/context에 대해 비슷한 memory set이 안정적으로 반환되는가. 오래된 memory와 새로운 memory가 충돌할 때 어느 쪽이 active가 되는가. memory가 tool call을 유도했다면 그 memory는 원래 어떤 user message, file, webpage, tool result에서 왔는가. 이런 질문이 풀리지 않으면 "장기 기억"은 편리한 기능이 아니라 재현하기 어려운 side effect가 됩니다.

Git으로 관리하는 기억이 주는 장점과 함정

AMP versioning spec은 git을 기본 versioning mechanism으로 봅니다. memory mutation이 commit이 되고, branch와 merge를 쓰며, conflict resolution을 git에 기대는 방식입니다. 이 아이디어는 개발자에게 직관적입니다. 에이전트가 새 preference를 만들면 commit이 남고, 오래된 node를 archive하면 changelog가 생기며, semantic conflict가 감지되면 disputed 상태나 reflection node로 surfaced될 수 있습니다.

장점은 분명합니다. 첫째, 기억이 human-inspectable합니다. 운영자가 cat과 git log로 확인할 수 있는 memory는 vendor UI에 숨은 profile보다 감사하기 쉽습니다. 둘째, 팀 단위 협업에 맞습니다. agent memory가 repo 근처에 있으면 project convention, deployment procedure, verification checklist 같은 지식은 코드와 함께 review될 수 있습니다. 셋째, migration 비용이 줄어듭니다. 특정 vendor memory export를 기다리지 않고 디렉터리 자체를 옮기는 길이 생깁니다.

하지만 함정도 있습니다. Git history는 삭제가 어렵습니다. AMP extension spec도 redaction을 말하면서 Git history에는 원본 content가 남을 수 있으므로 완전 삭제에는 별도 작업이 필요하다고 경고합니다. 개인 정보, 고객 데이터, secret에 가까운 기억이 들어오면 "Markdown이라 투명하다"는 장점이 곧 "복제와 유출이 쉽다"는 단점이 됩니다. 또한 scope enforcement가 파일 시스템 수준에서는 advisory에 가깝다면, team/workspace/public 같은 visibility는 실제 MCP server나 API layer에서 강제해야 합니다.

연구는 memory consolidation에 찬물을 끼얹습니다

최근 arXiv 논문 Useful Memories Become Faulty When Continuously Updated by LLMs는 agent memory 낙관론에 중요한 경고를 붙입니다. 논문은 LLM이 과거 trajectory를 textual memory bank로 계속 rewrite하는 consolidated memory 방식이 처음에는 utility를 높일 수 있지만, consolidation이 진행되면서 성능이 떨어지고 no-memory baseline 아래로 내려갈 수 있다고 보고합니다. 특히 저자들은 문제를 원본 experience가 아니라 consolidation step에서 찾습니다. 같은 trajectory라도 update schedule에 따라 memory 품질이 달라지고, raw episode만 보존하는 control이 competitive하게 남는다는 주장입니다.

이 연구는 OpenAI 방식이나 AMP 방식을 직접 평가한 것이 아닙니다. 하지만 설계 원칙에는 바로 연결됩니다. memory system은 raw episode를 버리고 깔끔한 lesson만 남기는 유혹을 경계해야 합니다. 요약은 비용을 줄이고 recall을 빠르게 만들지만, 요약이 원본 증거를 대체하면 잘못된 일반화가 반복 실행에 주입됩니다. 개발자에게 필요한 것은 "기억을 얼마나 많이 쓰나"보다 "언제 consolidation을 허용하고, 어떤 원본을 증거로 남기며, 잘못된 memory를 어떻게 revert하나"입니다.

이 흐름에서 가장 약한 고리는 대개 두 번째 단계입니다. 매 interaction 뒤에 자동으로 lesson을 rewrite하면 memory는 살아 움직이는 듯 보이지만, 실제로는 drift를 축적할 수 있습니다. 반대로 raw episode만 쌓으면 안전하지만 context cost가 커지고 recall이 느려집니다. 그래서 앞으로의 memory 경쟁은 "더 잘 기억한다"가 아니라 "raw evidence와 abstraction을 어떻게 분리하고, 어떤 threshold에서 abstraction을 trust할 것인가"가 될 가능성이 큽니다.

개발자 팀에는 어떤 실무 변화가 오나

첫 번째 변화는 repo 주변 파일의 중요도입니다. 이미 많은 코딩 에이전트는 AGENTS.md, CLAUDE.md, .cursor/rules, workflow 문서를 읽습니다. 여기에 memory store가 붙으면 repo는 코드만 담는 공간이 아니라 agent operating context까지 담는 공간이 됩니다. 프로젝트별 verification command, 금지된 deployment path, 특정 고객 환경에서 반복된 장애, 팀의 code review preference가 memory node로 남을 수 있습니다.

두 번째 변화는 review 대상의 확장입니다. 사람이 코드를 review하듯 agent memory diff도 review해야 할 수 있습니다. "항상 이 테스트를 건너뛰라"는 잘못된 procedure가 memory에 들어가면 다음 run의 행동이 바뀝니다. "고객 A는 보안 예외를 허용한다"는 outdated fact가 살아 있으면 agent가 위험한 추천을 할 수 있습니다. memory가 tool call을 바꾸는 순간, memory diff는 prompt artifact가 아니라 change management 대상입니다.

세 번째 변화는 vendor lock-in 논의의 재등장입니다. 모델은 쉽게 바꿀 수 있어도 memory가 vendor 안에 잠기면 에이전트의 누적 경험은 이동하지 못합니다. AMP의 "copy the directory = migration" 구호는 그래서 매력적입니다. 다만 매력적인 포맷이 곧 표준이 되는 것은 아닙니다. 실제 표준이 되려면 구현체, conformance suite, security model, import/export adapter, adoption이 필요합니다. 현재 AMP README도 amp-cli, amp-mcp, amp-python을 planned로 표시합니다. 기사 시점에서는 가능성이지 성숙한 생태계가 아닙니다.

지금은 표준 확정보다 질문의 등장을 봐야 합니다

이번 흐름을 "AMP가 에이전트 memory 표준이 됐다"로 읽으면 과장입니다. GitHub repository는 초기 상태이고, reference implementation도 아직 계획 단계입니다. OpenAI memory도 beta 문서입니다. 하지만 "에이전트 기억을 어디에 저장하고, 누가 검토하고, 어떻게 이동하고, 어떤 원본 증거와 연결할 것인가"라는 질문이 동시에 여러 곳에서 등장했다는 점은 작지 않습니다.

MCP가 tool integration을 표면으로 끌어냈다면, memory는 agent의 내부 상태를 표면으로 끌어낼 차례입니다. 장기 실행 에이전트가 실제 업무에 들어갈수록 문제는 더 분명해집니다. 잘못된 기억은 잘못된 tool call보다 더 오래갑니다. tool call은 로그 한 줄로 끝나지만, memory는 다음 실행의 판단을 바꿉니다. 그래서 앞으로의 좋은 에이전트 플랫폼은 더 긴 context window만 자랑하지 않을 것입니다. 어떤 기억이 active인지, 어떤 기억이 disputed인지, 어떤 기억이 원본 evidence 없이 요약만 남았는지 보여줘야 합니다.

개발자에게 지금 필요한 태도는 신중한 실험입니다. OpenAI Agents SDK처럼 제품 내부 memory를 쓴다면 retention policy와 sensitive data boundary를 먼저 정해야 합니다. AMP 같은 portable format을 검토한다면 아직 draft임을 전제로, 팀의 AGENTS.md나 runbook과 충돌하지 않는 좁은 범위에서 시작해야 합니다. 무엇보다 memory를 성능 최적화 캐시로만 보지 말아야 합니다. 에이전트가 기억하는 순간, 그 기억은 팀의 운영 지식이자 감사 대상이 됩니다.

결국 이번 뉴스의 핵심은 기억하는 에이전트가 똑똑해졌다는 이야기가 아닙니다. 기억이 파일이 되고, Git diff가 되고, MCP resource가 되고, 삭제와 redaction의 정책 문제가 되기 시작했다는 이야기입니다. AI 에이전트 경쟁의 다음 병목은 모델이 무엇을 아느냐가 아니라, 에이전트가 무엇을 기억한다고 주장할 때 그 기억을 우리가 검증하고 옮기고 지울 수 있느냐에 있습니다.