"에이전트에 세션 기록을 저장해봤자 소용없다" - Amol Kapoor가 뒤집은 'AI 메모리'의 거품

"에이전트에 세션 기록을 저장해봤자 소용없다" — Amol Kapoor가 뒤집은 'AI 메모리'의 거품

핵심 요약:

AI 에이전트 메모리 시장이 뜨겁습니다. 벡터 DB에 세션 기록을 저장하는 스타트업이 우후죽순 생겨나고, 모든 에이전트 프레임워크가 '메모리' 기능을 내세웁니다. 그런데 Amol Kapoor가 12gramsofcarbon.com에 게시한 글은 이 트렌드에 정면으로 반박합니다: SWE(소프트웨어 엔지니어링) 작업에서 에이전트가 이미 문서·PR·커밋 로그에 접근 가능하다면, 과거 세션 기록(transcript)을 메모리로 저장해도 성능 이점이 없다는 것입니다. "아티팩트(artifacts)는 기억하고, 스크래치(scratch)는 잊어라"는 그의 주장은 AI 에이전트 설계의 중요한 원칙을 제시합니다.

📌 'AI 에이전트 메모리' 열풍

2026년 AI 에이전트 업계에서 가장 뜨거운 키워드 중 하나는 메모리(Memory)입니다. 에이전트가 이전 대화나 작업 내역을 기억하면 더 나은 결정을 내릴 수 있을 것이라는 기대 때문입니다. 수많은 스타트업이 벡터 DB 기반 세션 기록 저장 솔루션을 내놓고 있고, Claude Code도 'Auto Dream'이라는 이름으로 메모리 기능을 조용히 출시했습니다.

이 모든 흐름은 하나의 직관에 기반합니다: "더 많이 기억할수록 더 똑똑해진다." 그런데 Amol Kapoor의 분석은 이 직관이 SWE(소프트웨어 엔지니어링) 도메인에서는 사실이 아닐 수 있다고 주장합니다.

🎯 핵심 논증 — '이미 존재하는 정보'의 역설

Kapoor의 논증은 간단하면서도 설득력 있습니다. SWE 작업에서 에이전트가 세션 기록을 통해 얻을 수 있는 정보는, 대부분 이미 구조화된 형태로 존재한다는 것입니다.

정보 유형	이미 존재하는 위치	세션 기록이 추가로 주는 가치
코드 변경 이력	Git 커밋 로그	"이전에 이 파일을 수정했다" — 이미 커밋에 기록됨
변경 이유	PR 설명, 커밋 메시지	"왜 이렇게 수정했는가" — 이미 PR 설명에 기록됨
리뷰 피드백	PR 스레드, 코드 리뷰 코멘트	"이 부분은 이렇게 고쳐야 한다" — 이미 PR에 기록됨
버그 재현 과정	이슈 트래커, 버그 리포트	디버깅 과정의 임시 출력 — 버려져도 되는 정보
API 설계 의도	문서, README, 설계 문서	설계 논의 과정 — 문서에는 최종 결정만 있음

핵심은, SWE 작업에서 '정말 중요한 정보'는 거의 모두 Git, PR, 이슈 트래커, 문서 등에 구조화된 형태로 존재한다는 점입니다. 세션 기록에만 있고 다른 곳에는 없는 '귀중한 정보'는 생각보다 드뭅니다. 세션 기록의 대부분은 "이 접근법을 시도해봤는데 실패했다", "3번째 프롬프트에서 이런 에러가 났다" 같은 일시적 스크래치(scratch)입니다.

💡 '아티팩트는 기억하고, 스크래치는 잊어라'

Kapoor가 제시하는 원칙은 간단합니다: "Keep track of artifacts, not scratch." 즉, 세션 중에 발생한 '최종 결과물(아티팩트)'만 기억하고, 중간 과정의 '스크래치(임시 작업)'는 버리라는 것입니다.

에이전트의 작업을 이 기준으로 분류해보면:

• 아티팩트 (저장할 가치 있음) — 생성된 코드, 수정된 파일, 커밋, PR, 발견된 버그 리포트, 문서화된 설계 결정
• 스크래치 (저장 불필요) — "이런 접근법을 시도했는데 실패했다", "다음과 같은 오류가 발생했다", "3번째 시도에서 성공했다" 같은 임시 정보

이 원칙은 Claude Code의 'Auto Dream' 기능과 정확히 대비됩니다. Auto Dream은 세션 기록을 REM 수면처럼 압축·요약하려고 시도하지만, Kapoor의 주장에 따르면 이 과정 자체가 불필요한 작업입니다. 세션 기록을 요약하는 데 토큰을 소비하는 것보다, 에이전트가 Git 로그와 PR을 직접 읽도록 하는 것이 더 효율적입니다.

💭 메모리 스타트업의 거품

Kapoor의 분석은 AI 에이전트 메모리 시장에 냉정한 평가를 요구합니다. 2026년 현재, '에이전트 메모리'를 표방하는 수많은 스타트업이 존재하지만, 그중 상당수는 근본적인 질문을 회피하고 있습니다.

첫째, '무엇을' 기억할 것인가에 대한 질문이 빠져 있다. 대부분의 메모리 솔루션은 "어떻게 저장할까" (벡터 DB, 임베딩, 검색)에 집중하고, "무엇을 저장할까" (아티팩트 vs 스크래치)에 대한 고민은 부족합니다. Kapoor의 분석은 후자가 훨씬 더 중요한 질문임을 보여줍니다.

둘째, SWE 도메인의 특수성을 고려해야 한다. Kapoor의 논증은 SWE 작업에 한정됩니다. 고객 지원 에이전트, 의료 진단 에이전트, 법률 리서치 에이전트 등 다른 도메인에서는 세션 기록이 더 중요한 정보를 담을 수 있습니다. SWE의 특수성은 '대부분의 중요한 정보가 이미 Git과 PR에 구조화되어 있다'는 점입니다.

셋째, '메모리'와 '옵저버빌리티'를 혼동하지 말아야 한다. 세션 기록이 에이전트 자체의 성능 향상에는 도움이 되지 않을 수 있지만, 팀의 옵저버빌리티(observability) 목적으로는 유용합니다. "에이전트가 왜 이런 결정을 내렸는가"를 추적하려면 세션 기록이 필요합니다. Kapoor의 주장은 '메모리'와 '로깅'의 목적을 분리해야 한다는 점을 시사합니다.

넷째, 이 분석은 '메모리'가 아닌 '컨텍스트 엔지니어링'의 중요성을 역설한다. 에이전트에게 필요한 것은 '과거 세션을 기억하는 능력'보다, '현재 필요한 정보를 Git, PR, 문서에서 실시간으로 검색하는 능력'입니다. 이는 Will Larson이 '컨텍스트 엔지니어링'이라고 부른 개념과 정확히 일치합니다.

🔮 AI 에이전트 메모리 설계의 교훈

Kapoor의 분석이 AI 에이전트 설계자들에게 주는 교훈을 정리하면:

• 메모리 != 세션 기록 — 에이전트에게 '기억'이 필요하다면, 구조화된 아티팩트(코드, 문서, PR)를 기억하게 해야 합니다. 세션 전체를 저장하는 것은 노이즈를 저장하는 것과 같습니다.
• 정보 중복을 피하라 — Git, 이슈 트래커, 문서 등 이미 존재하는 정보를 벡터 DB에 다시 저장할 필요가 없습니다. 대신 에이전트가 이 도구들에 직접 접근하게 하십시오.
• '의미 있는 요약'이 핵심 — 세션 전체를 저장하는 대신, 세션에서 얻은 인사이트(insight)만 요약해 저장하는 것이 더 효과적입니다. "이 세션에서 발견한 것은 X이다"라는 수준의 요약이면 충분합니다.
• 팀 도구와의 통합이 메모리보다 중요하다 — 에이전트가 Git, 이슈 트래커, 문서, 코드 리뷰 시스템에 직접 접근할 수 있다면, 별도의 메모리 시스템이 필요 없을 수 있습니다. OpenWiki 같은 도구가 이 방향으로 접근하고 있습니다.

💡 한 줄 요약:

Amol Kapoor의 분석은 AI 에이전트 메모리 시장의 거품을 찌릅니다. SWE 도메인에서 에이전트가 세션 기록을 메모리로 저장해도, 이미 Git·PR·문서 등 구조화된 컨텍스트에 접근 가능하다면 성능 향상 효과는 제한적입니다. "아티팩트(결과물)는 기억하고, 스크래치(임시 작업)는 잊어라"는 원칙은 AI 에이전트 설계의 중요한 기준을 제시합니다. 진정한 에이전트 메모리는 '저장'이 아니라 '검색'과 '통합'에 달려 있습니다.