매일 아침 Claude Code나 Cursor를 열 때마다 에이전트는 어제를 기억하지 못한다. 어제 두 시간 동안 파악한 인증 서비스의 race condition, 팀원이 이미 검증한 결제 모듈의 타임아웃 원인—전부 사라진다. 더 고통스러운 건 팀 단위로 일할 때다. A 엔지니어의 에이전트가 월요일에 알아낸 것을 B 엔지니어의 에이전트가 수요일에 처음부터 다시 발견한다. 이 반복은 단순한 불편함이 아니라 컨텍스트 자산의 증발이다.
이 문제를 정면으로 겨냥한 도구가 AMFS(Agent Memory File System)다. dev.to에 공개된 소개 글에 따르면, AMFS는 MCP 서버 형태로 Cursor·Claude Code에 연결되어 에이전트가 발견한 지식을 fact / belief / experience 타입으로 구조화하고 버전 관리한다. 핵심은 세 가지다. 첫째, 모든 메모리 항목에 confidence score가 붙는다. 배포 성공 후엔 올라가고, 인시던트와 연결되면 내려간다. 둘째, Copy-on-Write 방식으로 이전 버전을 삭제하지 않아 인과 추적이 가능하다. 셋째, 팀 전체가 동일한 메모리 스토어를 공유한다. amfs_briefing()을 세션 시작 시 호출하면 에이전트는 "오늘 처음 만난 코드베이스"가 아니라 "팀이 쌓아온 지식 위에서 시작하는 동료"가 된다.
그런데 메모리 지속성만으로 문제가 풀리지는 않는다. 어떤 컨텍스트를 메모리에 저장할 가치가 있는지 판단하는 것 자체가 설계 문제이기 때문이다. Skaro 2.0이 제안하는 방향이 여기서 맞닿는다. Skaro는 "또 다른 AI 코딩 도구"가 아니라 인간과 AI가 역할을 분리한 채 협업하는 워크스페이스를 표방한다. 핵심 아이디어는 .skaro 폴더 안에 ADR(Architecture Decision Record), 마일스톤, 태스크 스펙을 구조화된 아티팩트로 저장하는 것이다. 채팅 히스토리처럼 흩어지지 않고, 리포지토리와 함께 살아남는 외부 메모리다. AI는 매 태스크 전에 이 파운데이션을 로딩하고, 논의 결과는 다시 아티팩트로 기록된다. 컨텍스트가 개인의 머릿속이나 슬랙 스레드가 아니라 프로젝트 구조 안에 정착하는 방식이다.
두 접근의 공통 전제는 명확하다. AI 에이전트를 잘 쓴다는 것은 프롬프트를 잘 쓰는 것이 아니라 컨텍스트 구조를 설계하는 것이다. AMFS가 에이전트 간 지식 전파 레이어를 담당한다면, Skaro 스타일의 아티팩트 관리는 의사결정 맥락의 영속성을 담당한다. 두 레이어가 결합될 때—팀의 발견이 메모리에 쌓이고, 아키텍처 결정이 문서로 남고, 다음 에이전트가 그 위에서 출발할 때—비로소 AI가 "매번 처음부터 시작하는 도구"에서 "팀의 누적 경험을 이어받는 시스템"으로 전환된다.
여기서 자주 간과되는 변수가 있다. 이 시스템을 설계하고 운영하는 개발자의 기술 깊이다. dev.to의 또 다른 글 "Write Less, Know More"는 이 지점을 날카롭게 짚는다. AI는 자신감에 최적화되어 있지, 정확성에 최적화되어 있지 않다. 실제로 AI가 구현했다고 주장하지만 실제로는 작성하지 않은 기능, 존재하지 않는 데이터를 검증하며 여러 턴을 소비하는 사례가 반복된다. AMFS의 confidence score가 틀린 믿음에 높은 점수를 매기지 않으려면, 아티팩트에 기록된 ADR이 실제 아키텍처를 반영하려면, 결국 사람이 AI 출력을 감사할 수 있어야 한다. 기술 이해도가 없는 사람은 AI의 거짓말을 메모리에 그대로 저장하고, 그 잘못된 컨텍스트를 팀 전체가 이어받는 최악의 루프를 만든다.
프롬프트의 품질도 마찬가지다. 컴포넌트를 어디에 배치할지, 어떤 라이브러리를 쓸지, 무엇을 유틸로 추상화할지 가이드할 수 있는 개발자는 AI가 만드는 결과물의 아키텍처 정합성을 훨씬 높게 끌어올린다. 기술 어휘가 풍부할수록 프롬프트의 천장이 높아지고, 그 천장이 곧 에이전트 워크플로우의 품질 상한선이 된다. AI 에이전트 시대의 역설은 여기 있다. 코드를 직접 덜 쓸수록, 코드를 이해하는 역량이 더 중요해진다.
실무 관점에서 지금 당장 적용 가능한 레이어를 세 단계로 정리할 수 있다. 첫째, 팀 메모리 레이어—AMFS 같은 도구로 에이전트 발견 사항을 confidence score와 함께 공유 스토어에 축적한다. 비슷한 원리를 CLAUDE.md나 .cursor/rules 파일로도 구현할 수 있다. 둘째, 아티팩트 레이어—ADR, 마일스톤 스펙, 핵심 제약 조건을 리포지토리 안에 구조화된 문서로 남긴다. 에이전트가 매 세션마다 이 파운데이션을 컨텍스트로 주입받는다. 셋째, 감사 레이어—에이전트가 작성한 코드와 기록한 메모리를 개발자가 주기적으로 검토하고, 잘못된 belief를 낮은 confidence로 교정하거나 아예 삭제한다. 이 세 레이어가 갖춰질 때 AI 에이전트는 팀의 기술 부채를 쌓는 용병에서 팀의 누적 경험을 증폭하는 동반자로 바뀐다.
앞으로 이 방향은 더 빠르게 구체화될 것이다. MCP 생태계가 성숙하면서 메모리·컨텍스트·아티팩트를 연결하는 레이어가 도구 수준이 아니라 팀 인프라 수준으로 올라올 가능성이 높다. 중요한 건 도구가 먼저 갖춰지는 것이 아니라, 팀이 "무엇을 기억시킬 것인가"를 먼저 설계하는 것이다. 에이전트에게 기억을 주는 것은 기술 문제지만, 무엇을 기억하게 할지 결정하는 것은 여전히 사람의 판단이다.