Essay AI 에이전트 메모리가 아직 함정인 이유: 가지치기 문제

• AI 에이전트한테 “기억”을 붙이려는 시도는 거의 다 함정에 빠짐. 이유는 단순. 아무도 진짜 어려운 문제인 가지치기(pruning, 뭘 버릴지 결정)를 못 풀고 있어서
• 최근에 안 쓴 것부터 버리는 LRU 같은 캐시 전략은 안 통함. 메모리 큐레이션은 “최근성”이 아니라 “관련성”의 문제이기 때문. 1년 전 한 번 본 사실이 오늘 결정적일 수 있음
• 진짜로 작동하려면 의미(semantic)·시간(temporal)에 더해 인과관계(causal)를 동시에 모델링해야 함. “미래에도 쓸 사실인가”는 인과 체인 없이는 추론 자체가 불가능하기 때문
• 결론: 범용 에이전트 메모리는 아직 필요하지도, 가능하지도 않음. 좁은 도메인에 묶고 의사결정 입력으로 제한해서 쓸 때만 유용함
• 대안은 메모리 시스템을 따로 만드는 게 아니라, 환경 자체에 구조화된 작업 기록으로 박아두는 것. git 히스토리, 결정 로그, PR 토론, 태그 단 Slack 메시지가 이미 그 자리에 있음

왜 LRU 같은 단순 가지치기는 안 통하나?

• LRU(Least Recently Used)는 “최근에 안 쓴 거부터 버린다”는 캐시 알고리즘. 브라우저 캐시 같은 데서 잘 작동함
• 그런데 에이전트 메모리에서 중요한 건 “최근성”이 아님. 1년 전에 한 번 들은 고객의 결제 정책이 오늘 결정의 핵심이 될 수 있음
• 즉 메모리 가지치기는 본질적으로 “관련성” 판단의 문제. 관련성은 도메인을 이해해야만 매길 수 있음
• 도메인 이해 없이 통계적 휴리스틱(빈도, 최근성, 토큰 길이)으로 자르면, 자주 안 등장하지만 결정적인 사실부터 먼저 사라짐

범용 메모리가 풀리려면 뭐가 필요한가?

• 세 가지 모델링이 동시에 필요함. 의미 모델(이 사실은 무엇에 관한 것인가), 시간 모델(언제까지 유효한가), 그리고 인과 모델(이 사실이 다른 무엇과 어떻게 연결돼 있는가)
• 이 중 가장 어려우면서 가장 결정적인 축이 인과 모델. “A 때문에 B가 정해졌다”는 체인이 있어야 “A가 바뀌면 B를 다시 꺼내봐야 한다”가 나옴. 단순 동시 등장(co-occurrence) 통계로는 절대 안 잡힘
• “미래에 쓸 사실인가”의 추론도 결국 인과 모델 위에서만 가능. 가비지 컬렉션 시점에 인과 체인을 따라가며 영향 범위를 추정해야 함
• 즉 지울지 말지 결정하려면 전체 메모리 코퍼스 + 인과 그래프 + 미래 시나리오에 동시 어텐션을 줘야 한다는 얘기. 계산량이 폭발하고, 학습시킬 데이터 품질·규모도 지금 시점엔 턱없이 부족함

AI 메모리 레이어 스타트업들은 어디까지 왔나?

2026년 4월 기준, 가장 많이 언급되는 메모리 레이어들을 모아보면 공통 패턴이 보임. 다들 가지치기·인과 모델링은 정면 돌파 안 하고 도메인을 좁히거나 LLM에 큐레이션을 위임하는 방식으로 우회 중.

프로젝트	배경/펀딩	오픈소스	핵심 아키텍처	가지치기·인과 처리
Mem0	YC S24, $24M Series A (2025.10)	Apache (오픈코어)	벡터·그래프·key-value 하이브리드. add/search API	사실 단위 추출·중복 제거. 우선순위는 휴리스틱
Zep / graphiti	YC W24, Daniel Chalef. graphiti는 Apache 2.0	부분 (graphiti만)	시간 인식 지식 그래프. 각 사실에 유효 구간 부여	시간축은 강함. 인과는 그래프 엣지로 표현 가능하나 자동 추출 제한적
Letta (구 MemGPT)	UC Berkeley BAIR 스핀아웃, Felicis 리드 $10M Seed	Apache 2.0	OS 메타포 3계층(Core·Recall·Archival). LLM이 직접 자기 메모리 편집	LLM이 매번 가지치기 결정
Supermemory	Cloudflare·Google 임원 등 $2.6M Seed (2025.10)	MIT	벡터·시맨틱 검색. MCP 연결자 다수. 19세 창업자	충돌·만료 자동 처리 주장. LongMemEval·LoCoMo 등 벤치마크 1위
Cognee	오픈소스 프로젝트	Apache 2.0	ECL 파이프라인(Extract·Cognify·Load) + 지식 그래프. 30+ 데이터 커넥터	멀티홉 추론 벤치마크 강세. 그래프에서 일부 인과 캡처

각 프로젝트의 한계:

• Mem0: 사실은 잡지만 “왜 이렇게 결정됐나” 인과 체인은 약함

• Zep / graphiti: 대화 출처 기반이라 도메인 외부 인과 추론은 안 함

• Letta: 모든 메모리 작업이 LLM 호출이라 비용·지연·불투명성 부담

• Supermemory: 개인 RAG 무게중심이라 멀티에이전트·복잡 인과 추적은 약함

• Cognee: 생태계가 Mem0 대비 작고 셀프호스팅 운영 부담 큼

• 공통점은 순수한 범용 메모리는 아무도 못 풀고 있다는 것. 다 좁은 도메인·휴리스틱·LLM 위임 중 하나로 우회 중

• 차이점: Mem0는 사실 단위로 빠르게, Zep는 시간축을 정밀하게, Letta는 LLM 자체가 메모리 매니저, Supermemory는 검색 속도·벤치마크, Cognee는 데이터 다양성

• 1인기업 입장에선 라이브러리 선택보다 “내 도메인은 무엇이고 어디까지 좁힐 수 있나”를 정하는 게 먼저. 도메인이 안 정해진 채로 라이브러리부터 고르면 어느 쪽도 잘 안 맞음

그럼 1인기업가는 뭘 해야 하나?

• 메모리 시스템을 새로 만드는 데 시간 쓰지 말고, 이미 환경에 박혀 있는 구조화된 작업 기록을 그대로 메모리로 쓰는 게 현실적
• 이 작업 기록들이 사실상 메모리로 작동하는 이유는 단순. 인과 체인이 텍스트 안에 자연스럽게 박혀 있어서, 별도 모델 없이 사람·에이전트가 따라갈 수 있기 때문
• git 히스토리: “왜 이 코드가 이렇게 됐는지”가 커밋 메시지·diff에 남음. 변경의 인과가 한 자리에 묶여 있는 형태
• 코드 인라인 주석: 함수 위에 “왜 이 처리를 하는가, 어떤 엣지 케이스를 막으려는 건가”를 한 줄만 남겨도 됨. 코드를 다시 볼 때 가장 가까운 자리에 인과가 박혀 있는 형태
• 결정 로그: “왜 이 결정을 했는가”를 평문으로 남기면, 6개월 뒤 본인이나 에이전트가 그 인과를 그대로 인용할 수 있음
• PR 토론·이슈 댓글: 코드 변경의 맥락(왜 이 옵션을 골랐고 무엇을 버렸는지)이 코드 옆에 영구적으로 박힘
• 태그 단 Slack/노트 메시지: 키워드로 검색 가능한 형태로 흘려두면 그게 곧 메모리

접근	가지치기 풀어야 함?	1인기업 적용성
범용 에이전트 메모리	풀어야 함 (못 풀고 있음)	아직 위험
좁은 도메인 메모리 (Zep 등)	도메인 휴리스틱으로 우회	케이스별로 검토
환경에 박힌 작업 기록 (git 등)	사람이 자연스럽게 함	즉시 가능

그럼 ChatGPT/Claude의 메모리 기능도 함정인가?

함정에 가깝다고 봄. 일반 소비자 시나리오(이름·취향 기억)에서는 그럭저럭 작동하지만, “비즈니스 결정의 컨텍스트”처럼 관련성 판단이 까다로운 영역에서는 잘못된 걸 잘못된 시점에 끌어와 노이즈를 만들기 쉬움. 차라리 메모리를 끄고 매번 명시적으로 컨텍스트를 넣는 쪽이 안전한 경우가 많음.

컨텍스트 윈도우를 100만 토큰으로 늘리면 메모리 문제도 풀리지 않나?

별개의 문제. 컨텍스트 윈도우는 “한 번에 얼마나 보여줄 수 있나”의 문제고, 메모리는 “100만 토큰 안에 뭘 골라 넣을 것인가”의 문제. 윈도우가 커질수록 오히려 가지치기·우선순위 판단이 더 중요해짐. 큰 컨텍스트에 노이즈가 섞이면 모델 성능이 오히려 떨어지는 현상은 이미 알려져 있음.

구체적으로 환경에 기록을 박는다는 게 뭔가?

별도 메모리 DB 만들지 말고, 작업물 옆에 평문으로 “왜”를 남기는 것. 커밋 메시지에 의도, README에 결정의 근거, 이슈에 논의, Slack 채널에 검색 가능한 태그. 6개월 뒤 본인이 grep 한 번으로 찾을 수 있으면 그게 사실상 메모리. 사람과 에이전트가 동일한 인터페이스로 접근하는 게 핵심.

---

관련: 같은 맥락에서 컨텍스트 그래프가 1조 달러 기회라는 Foundation Capital의 글도 같이 보면 좋음. 도구를 늘리는 게 아니라 기본기·판단력이 먼저라는 관점과도 이어짐.