에이전트 시리즈 (15): 고급 에이전트 메모리 — 단기, 장기, 압축

메모리는 단순히 "채팅 로그를 저장하는 것"이 아닙니다

대화 기록을 프롬프트(Prompt)에 쏟아붓는 것은 가장 조잡한 형태의 메모리 방식입니다. 실제 시스템은 더 복잡한 요구사항을 가지고 있습니다:

• 사용자가 3번째 턴(Turn)에서 자신의 도시를 언급했습니다. 에이전트는 사용자가 10번째 턴에서 날씨를 물었을 때 어디를 찾아봐야 하는지 알고 있어야 합니다.
• 사용자가 지난주에 어떤 제품 플랜을 사용하는지 시스템에 알려주었습니다. 새로운 세션(Session)에서 이를 다시 물어서는 안 됩니다.
• 20번의 턴이 지난 후, 컨텍스트 윈도우(Context Window)가 거의 가득 찼습니다. 중요한 정보를 잃지 않으면서 어떻게 압축할 수 있을까요?

이것은 세 가지 서로 다른 메커니즘을 필요로 하는 세 가지 서로 다른 문제입니다.

3계층 메모리 아키텍처 (Three-Layer Memory Architecture)

단기 메모리 (Short-term)    세션 내 (Within session)    MemorySaver 체크포인터 (checkpointer)    멀티 턴 질의응답 (Multi-turn Q&A)
장기 메모리 (Long-term)     세션 간 (Cross-session)     지속성 KV / 벡터 DB (Persistent KV / vector DB)   개인화 (Personalization)
압축 (Compression)         세션 내 (Within session)    요약 교체 (Summary replacement)         긴 대화 토큰 가드 (Long-conversation token guard)

데모 1: 단기 메모리 (Short-term Memory) — MemorySaver

LangGraph의 MemorySaver는 가장 가벼운 단기 메모리 구현체입니다. 이는 대화 기록을 thread_id에 바인딩하고 이후 호출 시 자동으로 주입합니다.

from langgraph.checkpoint.memory import MemorySaver
from langchain_core.runnables import RunnableConfig

...

실제 벤치마크 결과:

Thread A Turn 1: Hello Alice! How can I assist you today?

Thread A Turn 2: Sure, I can help you with that. I will need to know the 
...

Thread A와 Thread B는 동일한 응답을 내놓았습니다.

이는 중요한 발견입니다: MemorySaver의 인프라는 올바르게 작동했습니다 — Thread A의 두 번째 호출은 두 개의 메시지 전체 기록을 전달한 반면, Thread B는 하나만 가지고 있었습니다. 하지만 GLM-4-Flash는 "나는 베이징에 산다" (1번째 턴)를 "내가 사는 곳" (2번째 턴)과 연결하지 못했습니다. 이것은 MemorySaver의 문제가 아니라 모델 능력 (Model capability) 문제입니다.

동일한 프롬프트에서 GPT-4나 Claude라면 아마도 베이징 날씨를 직접 조회했을 것입니다. 성능이 낮은 모델은 도구 호출 (Tool call)을 트리거하기 위해 더 명시적인 입력("베이징 날씨가 어때?")이 필요할 수 있습니다.

단기 메모리는 두 가지 계층을 가집니다:

1. 인프라 계층 (Infrastructure layer): MemorySaver가 히스토리가 계속 전달되도록 보장합니다 ✓
2. 모델 계층 (Model layer): LLM이 히스토리에서 컨텍스트를 추출하고 사용할 수 있는지 여부 ← 모델의 성능 (model capability)에 달려 있습니다

데모 2: 장기 메모리 (Long-term Memory) — 세션 간 사실 저장소 (Cross-session Fact Store)

세션 간 메모리 (cross-session memory)의 핵심 아이디어는 다음과 같습니다: LLM을 사용하여 대화에서 주요 사실을 추출하고, 이를 영구적으로 저장한 다음, 다음 세션의 시스템 프롬프트 (system prompt)에 주입하는 것입니다.

세션 1 — 추출 및 저장:

# 시뮬레이션된 영구 저장소 (프로덕션 환경: 데이터베이스 또는 벡터 저장소(vector store)로 교체)
LONG_TERM_STORE: dict[str, dict[str, str]] = {}

...

세션 1 대화:

User: 제 이름은 Alice입니다. 상하이에 거주하고 있고 저희 팀은 WonderBot Pro를 사용합니다.
User: 저희는 주로 데이터 처리를 위해 API를 사용하며, 한 달에 약 50,000번 호출합니다.

추출 및 저장됨:

{'name': 'alice', 'city': 'shanghai', 'team': 'wonderbot pro', 'api_calls': '50000'}

세션 2 — 주입 및 사용:

stored = load_user_facts("user-alice")
facts_text = "; ".join(f"{k}={v}" for k, v in stored.items())

...

세션 2 결과:

User: 오늘 제가 사는 도시의 날씨는 어떤가요?
Agent: 현재 상하이의 날씨는 흐리며, 기온은 섭씨 22도입니다.
Tools used: ['get_weather']

에이전트는 확인 질문 없이 상하이를 직접 조회했습니다. 이는 city=shanghai가 이미 시스템 프롬프트에 포함되어 있었기 때문입니다 — 모델은 대화 이력으로부터 추론한 것이 아니라 명시적인 사실을 읽은 것입니다.

이것이 세션 간 사용에 있어 장기 메모리가 단기 메모리보다 더 신뢰할 수 있는 이유입니다. 명시적인 KV (Key-Value) 형식의 사실은 모델이 대화 이력을 역으로 추론할 필요를 요구하지 않습니다.

데모 3: 히스토리 압축 (History Compression)

대화가 길어짐에 따라 토큰 소비량과 응답 지연 시간 (latency)이 선형적으로 증가합니다. 압축 전략은 다음과 같습니다: 토큰 임계값 (token threshold)을 설정한 다음, 이를 초과하면 히스토리를 요약본으로 교체합니다.

COMPRESSION_THRESHOLD = 250   # 토큰

def summarize_messages(messages: list) -> str:
...

데모 3 실제 결과: 5회 대화(심천의 Bob, WonderBot Pro 평가 중, 개발자 8명, 연간 비용 299×12=3588)의 총 토큰 수는 198개로 유지되었습니다. 이는 250 임계값(threshold) 미만이므로 압축(compression)이 한 번도 트리거되지 않았습니다.

최종 검증:

사용자: 빠르게 요약해줘: 나는 누구고, 어느 도시에 있으며, 연간 API 비용은 얼마인가요?
에이전트: 당신은 심천(Shenzhen) 출신의 Bob이며, 개발자 8명을 위한 WonderBot Pro의 연간 API 비용은 $3,588입니다.

10개의 메시지가 모두 유지되었습니다. 에이전트는 모든 핵심 사실을 정확하게 회상했습니다. 압축은 안전 밸브(safety valve)이지, 매 턴마다 수행되는 작업이 아닙 — 대화가 간결하게 유지될 때는 요약본보다 원본 히스토리(raw history)가 더 정확합니다. 권장 임계값: 2000–4000 토큰.

세 가지 패턴의 비교

패턴	데모 1 결과	데모 2 결과	주요 차이점
단기 메모리 (Short-term)	인프라(Infrastructure)는 정확함; GLM-4-Flash가 암시적 문맥(implicit context) 사용에 실패함	—	모델의 추론 능력에 따라 달라짐
...

핵심 결론:

• 신뢰할 수 있는 턴 간 문맥(cross-turn context)이 필요한 경우 → 단순히 MemorySaver를 사용하는 것이 아니라, 장기 메모리(long-term memory)의 명시적 주입(explicit injection)을 사용하십시오.
• MemorySaver의 가치는 세션 격리(session isolation) (서로 다른 thread_id가 서로에게 영향을 주지 않음)와 **자동 히스토리 전달(automatic history passing)**에 있습니다. 이는 "모델이 암시적 문맥을 추론할 수 있는가"의 문제를 해결하지는 않습니다.
• 압축은 프로덕션(production) 환경에서의 필수 사항이지만, 임계값을 너무 낮게 설정하지 마십시오.

설계 체크리스트

단기 메모리 (Short-term Memory, MemorySaver)

• 사용자별 / 대화별로 고유한 thread_id를 할당하십시오.
• thread_id로 무작위 문자열이 아닌 사용자 ID를 사용하십시오 — 이는 다회차(multi-turn) 대화의 연속성을 유지합니다.
• "모델이 암시적 정보를 추론하지 못하는 문제"를 해결하기 위해 MemorySaver에 의존하지 마십시오.
• 프로덕션 환경: MemorySaver가 아닌 영구 체크포인터(SqliteSaver, PostgresSaver)를 사용하십시오.

장기 메모리 (Long-term Memory)

• LLM을 사용하여 사실(facts)을 추출하십시오 — 파싱 규칙을 직접 작성하지 마십시오
• 명시적인 KV(Key-Value) 형식으로 시스템 프롬프트에 사실을 주입하십시오; 명시적인 것이 암시적인 것보다 낫습니다
• 업데이트 정책을 정의하십시오: 무한히 추가하는 대신 오래된 사실을 덮어쓰십시오
• 프로덕션(Production): 사실적 메모리(factual memory)를 위한 구조화된 DB, 의미적 메모리(semantic memory)를 위한 벡터 스토어(vector store)

이력 압축 (History Compression)

• 임계값(Threshold): 2000–4000 토큰 (너무 낮으면 = 빈번한 압축 발생 = 정밀도 손실)
• 요약 프롬프트는 반드시 "특정 숫자와 이름을 보존하라"고 명시해야 합니다 — 그렇지 않으면 LLM이 과도하게 추상화합니다
• 압축 후, 핵심 사실이 요약에 여전히 포함되어 있는지 확인하십시오
• 도구 호출(tool-call) 도중에 압축을 트리거하지 마십시오 — 실행 컨텍스트(execution context)를 깨뜨립니다

요약 (Summary)

다섯 가지 핵심 요점:

1. MemorySaver는 인프라이지 만능 해결책(silver bullet)이 아닙니다: 이는 이력이 전달되는 것을 보장하지만, 모델이 암시적 컨텍스트(implicit context)를 사용할 수 있는지 여부는 모델의 역량에 달려 있습니다.
2. 명시적 주입(Explicit injection)이 암시적 추론(implicit inference)보다 더 신뢰할 수 있습니다: 시스템 프롬프트에 city=shanghai를 넣는 것이 모델이 10개의 메시지 이력으로부터 이를 추론하기를 기대하는 것보다 더 안정적입니다.
3. 세 가지 계층을 조합하여 사용하십시오: 단기 메모리(세션 격리) + 장기 메모리(세션 간 개인화) + 압축(토큰 가드)
4. 사실 추출(Fact extraction)은 장기 메모리를 위한 핵심 단계입니다: LLM 추출 + JSON 파싱은 비구조화된 대화를 구조화되고 주입 가능한 사실로 변환합니다.
5. 압축은 안전 밸브(safety valve)이지 매 턴(per-turn) 수행 작업이 아닙니다: 대화가 짧을 때는 원본 이력이 더 정밀합니다; 임계값을 초과할 때만 압축하십시오.

다음 단계: 에이전트 도구 설계 (Agent Tool Design) — 고품질 도구를 설계하는 방법: 도구의 세분성(granularity), 에러 처리(error handling), 재시도 전략(retry strategies), 그리고 하나의 도구를 사용할 때와 여러 개로 나눌 때의 기준.

참고 문헌 (References)

• LangGraph Persistence documentation
• LangGraph MemorySaver reference
• 이 시리즈의 전체 데모 코드: agent-14-memory

실제 기업급 워크플로우에서 검증된 AI 에이전트와 기술을 큐레이션하여 제공하는 마켓플레이스 PrimeSkills를 확인해 보세요. 불필요한 내용은 빼고, 실제로 작동하는 것들만 모았습니다.

저의 홈페이지에서 더 유용한 지식과 흥미로운 제품들을 찾아보세요.