에이전트가 똑같은 실수를 반복한다면, 모델 문제가 아닐 가능성이 높다. 기억 문제다. ExpTracker.AI를 운영하던 팀은 이미 실패한 가격 실험을 AI가 재추천하는 상황을 겪었다. 데이터도 있었고, 사후 분석 문서도 있었다. 그런데 AI는 처음 보는 아이디어인 것처럼 반응했다. Dev.to에 공개된 이 사례가 불편한 이유는, 비슷한 일이 지금 당신 팀에서도 벌어지고 있을 가능성이 크기 때문이다.
에이전트의 기억은 '스토리지'가 아니라 '설계'다. Claude Code 내부 구조를 보면 이 차이가 선명해진다. Velog에 정리된 Claude Code 에이전트 분석에 따르면, 에이전트가 컨텍스트를 구성하는 레이어는 크게 여섯 가지다. 정적 프로젝트 지시사항(CLAUDE.md, .claude/rules/*.md), 현재 작업 환경의 동적 상태(파일·Git·터미널), 세션을 가로질러 유지되는 영구 메모리(MEMORY.md), MCP 서버·Skills·Hooks·Subagent로 구성된 확장 기능, 권한과 환경 변수를 담은 설정값, 그리고 대화 히스토리다. 이 중 대부분의 팀이 챙기지 않는 것이 세 번째 레이어—영구 메모리다.
로그를 쌓는 것과 기억을 설계하는 것은 다르다. ExpTracker 팀이 초기에 저장한 실험 데이터는 이런 형태였다. 가설: 사용자는 가격에 둔감 / 결과: 실패. 사람이 읽기엔 충분하다. 하지만 AI가 의미 기반으로 검색하기엔 너무 빈약하다. '프리미엄 사용자는 20% 인상에 반응하지 않을 것'이라는 새 제안이 들어왔을 때, 키워드 매칭은 실패했다. 의미는 같지만 표현이 달랐기 때문이다. 해결책은 단순했다—'왜 실패했는가'까지 포함한 의도 중심의 구조화된 메모리. "스타터 티어 가격을 30% 올렸고, 3주 내 이탈률이 18% 증가했다. 이 세그먼트의 가격 민감도가 높다는 것을 시사한다." 이렇게 저장하자 의미 기반 검색이 작동하기 시작했다.
Claude Code의 Skills 패턴은 이 원리를 팀 단위로 확장한다. Andrej Karpathy가 공개한 LLM Wiki 패턴을 Claude Code 스킬로 구현한 사례(dev.to)는 같은 문제를 다른 각도에서 푼다. /wiki-init, /wiki-ingest, /wiki-query, /wiki-lint 네 개 커맨드로 구성된 이 스킬은 에이전트가 매번 문서를 검색하는 대신, 컴파일된 지식 베이스를 유지하게 만든다. CTO 의사결정 위키를 만든 팀은 아키텍처 결정·미팅 노트·사후 분석을 하나의 쿼리 가능한 베이스로 축적했다. Slack 스레드를 뒤지며 맥락을 재구성하는 작업이 사라졌다. 핵심은 같다—에이전트가 '기억할 수 있는 구조'를 사람이 먼저 설계해줘야 한다.
그렇다면 팀이 실제로 챙겨야 할 설계 포인트는 세 가지다.
첫째, CLAUDE.md 계층을 루트와 서브디렉터리에 모두 작성하라. 프로젝트 규칙과 코딩 컨벤션을 여기에 넣으면, 매 세션마다 컨텍스트를 재주입하는 비용이 사라진다. 이것은 정적 기억이다.
둘째, MEMORY.md를 팀의 사후 분석 저장소로 활용하라. 반복되는 버그 패턴, 실패한 설계 결정, 그리고 ExpTracker 팀이 학습한 것처럼 '왜 실패했는가'의 이유까지 기록해야 한다. 결과만 저장하면 에이전트는 여전히 처음 보는 척한다.
셋째, 복잡한 조사 태스크는 Subagent에 위임하고 요약을 메인 컨텍스트로 끌어오는 구조를 만들어라. 모든 정보를 하나의 컨텍스트 윈도우에 우겨넣으면 오히려 품질이 떨어진다. ExpTracker 팀의 경험에서도 확인됐다—관련 과거 실험 5개 이하가 최적이었다. 더 많은 데이터가 더 나은 판단을 만들지 않는다.
Hooks와 MCP는 기억의 실시간 확장이다. 커밋 전 특정 스크립트를 실행하고 그 결과를 대화 컨텍스트에 주입하는 Hooks, 외부 서비스 데이터를 실시간으로 가져오는 MCP 서버—이 두 레이어는 에이전트의 기억을 정적 파일 너머로 확장한다. 설계된 기억 구조 위에 이 확장 기능들이 올라올 때, 에이전트는 단순한 코딩 어시스턴트가 아니라 프로젝트 히스토리를 이해하는 동료처럼 작동하기 시작한다.
팀이 진짜로 바꿔야 할 것은 개념이다. ExpTracker 팀이 스스로 정리한 가장 큰 교훈은 기술적인 게 아니었다. 과거 실험을 '아카이브'가 아니라 '능동적으로 사용할 자산'으로 다루기 시작했을 때 시스템 행동이 달라졌다. Claude Code의 영구 메모리도 마찬가지다. MEMORY.md를 만들어놓고 방치하면 아카이브다. 팀이 의도적으로 업데이트하고, 에이전트가 그걸 참조하도록 설계해야 기억이 된다.
에이전트는 기억하지 못해서 실패하는 게 아니다. 기억할 구조를 설계받지 못해서 실패한다. 그 설계는 도구가 아니라 팀이 해야 한다.