에이전트 메모리 — 무엇을 기억하고 무엇을 잊을 것인가

지난 9개월 동안 우리 DevOps 에이전트의 메모리 를 4번 다시 짰다. 각 재설계의 trigger 는 같은 한 가지 — 기억을 더 늘렸더니 행동이 더 나빠졌다.

이 글은 그 9개월의 결론 — 에이전트 메모리는 무엇을 저장할지가 아니라 무엇을 잊을지의 문제.

메모리 = 컨텍스트의 누적

LLM 에이전트가 멀티턴 대화를 하려면, 이전 턴의 결과 를 다음 턴의 입력 에 넣어야 한다. 이 누적이 메모리. 단순한 형태는 대화 history 를 그냥 다 넣기.

이게 깨지는 첫 지점 — 컨텍스트 윈도우 한계. 200K 토큰 모델도 멀티턴 100회 에서 한계.

두 번째 지점 — 길어진 컨텍스트의 정확도 저하. "lost in the middle" 현상 — 컨텍스트 가운데의 정보가 잘 안 쓰임.

세 번째 — 비용. 매 턴 전체 history 를 보내면 토큰 비용이 턴 수 제곱 으로 증가.

4 종류의 메모리

해결책은 메모리 종류를 분리 하는 것.

1. Working memory — 현재 작업의 컨텍스트

지금 풀고 있는 작업의 직접 정보. 사용자 요청, 직전 액션, 직전 결과. 짧고 휘발성.

저장: 컨텍스트 윈도우의 최근 부분. 자동으로 새 턴이 들어오면 오래된 게 밀려남.

2. Episodic memory — 과거 작업의 결과

이전에 푼 비슷한 문제 의 기억. "이런 인시던트는 전에 해결한 적 있음".

저장: 외부 vector store. embedding 매칭으로 현재 작업과 비슷한 과거 를 찾음.

3. Semantic memory — 도메인 지식

조직의 runbook, 정책, 아키텍처 문서. 시간에 따라 천천히 변함.

저장: RAG (vector retrieval). 매 턴 관련 부분만 가져옴.

4. Procedural memory — 학습된 패턴

"이 종류의 작업은 이런 단계로 푼다" — 절차의 일반화. 보통 모델 자체에 내장 또는 fine-tuning.

저장: 시스템 프롬프트의 예시 또는 별도 fine-tuning.

4 종류 잊기 정책

핵심은 각 메모리가 어떻게 잊는가.

Working — 시간 기반

가장 단순. N 턴 이상 오래된 working memory 는 잊음. 단, 중요한 사실 은 episodic 으로 승격.

승격 기준: 결정 변경, 새 사실 추가, 사용자 정정.

Episodic — 유사도 + 빈도

이전 작업이 너무 많아지면 검색이 희미 해짐. 6개월 이상 된 episode 중 접근 빈도 낮은 것 부터 압축.

압축 = 원본 episode → summary. summary 는 vector 는 유지하지만 전문 텍스트는 제거. 검색 가능하지만 가벼움.

Semantic — 명시적 갱신

도메인 문서가 변경 되면 vector store 의 해당 부분 재인덱싱. 자동 이 아님 — 사람이 어떤 변경이 의미 있는지 결정.

이게 가장 자주 잘못되는 부분. 자동화하려는 시도가 많지만, 문서의 어떤 부분이 의미 있는 변경인지 판단이 모델로는 어려움.

Procedural — 고정 또는 fine-tune

거의 안 잊음. 갱신은 fine-tuning 사이클로 — 분기 1회 정도.

우리가 부딪힌 4 함정

1. Working 의 압축 시점 결정

N 턴 이상 의 N 을 정해야 함. 우리는 처음 50 턴 으로 시작 → 10 턴 으로 줄임. 50 은 컨텍스트가 너무 길어서 정확도 저하, 10 은 바로 직전 작업의 맥락이 빠짐. 결국 15 턴.

2. Episodic 의 유사도 임계

얼마나 비슷해야 episode 를 가져오나? 우리 처음 0.7 cosine similarity → 0.85 로 올림. 0.7 은 덜 관련된 것 이 너무 많이 들어옴, 0.9 는 진짜 유사한 것조차 놓침.

3. Semantic 의 오래된 정보 제거 시점

조직의 정책 문서가 2년 전 버전 인 채로 vector store 에 있었음. 에이전트가 옛 정책 으로 행동. 분기 1회 명시적 점검 박음.

4. 4 종 사이의 충돌

가장 어려운. semantic 이 X 정책 이라고 말하는데 episodic 의 과거 사례 가 Y 결정 을 한 경우. 모델이 어느 쪽을 따를지가 불안정.

해결: 우선순위 명시 — semantic > episodic > working. 정책 변경 후에는 과거 episode 의 무효화 가 명시적으로.

9개월의 한 줄

기억을 더 줘서 더 똑똑하게 가 아니라, 덜 줘서 더 정확하게. 메모리 설계의 절반 이 잊기 정책 이다.

누가 이 글을 읽으면 좋은가

LLM 에이전트의 멀티턴 정확도가 길이가 늘수록 떨어지는 경험을 한 모든 팀. 위 4 메모리 + 4 잊기 정책이 한 곳에 동시에 정의되어 있지 않으면, 9개월 후에 재설계 가 됨. 처음부터 박는 게 훨씬 싸다.