CH08-기억하는 AI — 메모리 관리(Memory Management) 완벽 정리

메모리 관리(Memory Management)는 무상태 LLM에 기억을 달아 대화 연속성·개인화·학습을 가능하게 하는 핵심 에이전트 패턴입니다. 단기(Short-Term)와 장기(Semantic·Episodic·Procedural) 메모리의 구조, 인간 기억과의 매핑, Google ADK의 Session.state·output_key·state_delta·State 접두사, LangGraph의 Checkpointer·Store·thread_id·Namespace, 백엔드 선택(InMemory·PostgreSQL·Redis·VertexAI), CRM/ERP/Groupware 적용과 ROI까지 한 번에 정리했습니다.

 

AGENTIC AI DESIGN PATTERNS · 08

기억하는 AI — 메모리 관리(Memory Management) 완벽 정리

무상태 LLM에 기억을 달기: 단기·장기 메모리, Checkpointer와 Store, output_key·state_delta, 그리고 엔터프라이즈 적용까지

🟢 입문~중급 ⏱️ 약 16분 🔧 LangGraph·Google ADK 🏢 엔터프라이즈

TL;DR — 기본 LLM은 무상태(stateless)라 이전 대화를 기억하지 못합니다. 메모리 관리는 대화·상호작용 정보를 저장·검색·활용해 연속성·개인화·학습을 가능하게 하는 패턴입니다. 메모리는 세션 안에서만 사는 단기(Short-Term)와 세션을 넘어 영속하는 장기(Long-Term)로 나뉘고, 장기는 다시 의미·일화·절차 메모리로 갈라집니다. LangGraph는 Checkpointer(단기)+Store(장기), Google ADK는 Session.state+output_key / MemoryService로 구현합니다.

목 차

1. 왜 메모리인가 2. 메모리 유형 체계 3. 범위와 생명주기 4. 핵심 구성요소 5. 구현① Checkpointer 6. 구현② Postgres 영속 7. 구현③ Google ADK 8. 프레임워크 비교 9. 백엔드 선택 10. 엔터프라이즈 11. 케이스 스터디 12. 베스트 프랙티스

1. 왜 메모리인가 — 똑똑하지만 금붕어인 두뇌

지금까지 일곱 편을 지나왔습니다. 순서대로 쪼개는 체이닝, 입력에 따라 길을 나누는 라우팅, 독립 작업을 동시에 처리하는 병렬화, 쓴 다음 읽고 고치는 리플렉션, 모르면 도구를 쓰는 도구 사용, 언제 어떤 순서로 쓸지 짜는 플래닝, 전문가가 협력하는 멀티 에이전트. 그런데 이 모든 똑똑함에는 치명적 공백이 하나 있습니다.

기본 LLM은 무상태(stateless)입니다. 각 요청은 독립적으로 처리되고, 직전에 무슨 말을 했는지조차 기억하지 못합니다. 방금 이름을 알려줘도 다음 턴이면 깨끗이 잊습니다.

🐟 메모리 없는 AI — 매번 처음

🙋 "내 이름은 김철수야"

🤖 "안녕하세요, 김철수님!"

🙋 "내 이름이 뭐라고 했지?"

🤖 "죄송합니다, 알 수 없습니다" ❌

🧠 메모리 있는 AI — 기억하고 이어감

🙋 "내 이름은 김철수야"

🤖 "반가워요!" → 저장: user:name=김철수

🙋 "내 이름이 뭐라고 했지?"

🤖 "김철수님이시죠!" ✅ ← 조회

그림 1. 메모리는 LLM의 무상태성을 보완해 컨텍스트 연속성·개인화·학습을 가능하게 한다.

메모리가 붙는 순간 가능해지는 것: 컨텍스트 연속성(반복 질문 방지), 개인화(선호도·히스토리 기반 응답), 학습·개선(과거 경험 활용), 복잡한 작업(다단계 진행 상태 추적). 한마디로 "기억하는 AI Agent"가 됩니다.

2. 메모리 유형 체계 — 인간의 기억을 그대로 빌려오다

AI 메모리 설계는 인지과학의 인간 기억 분류를 거의 그대로 차용합니다. 크게 단기 메모리와 장기 메모리로 나뉘고, 장기는 다시 셋으로 갈라집니다.

인간의 기억	AI Agent 메모리	저장 내용	예시
단기 기억	Short-Term	현재 대화·작업 상태	진행 중 대화, 작업 단계
의미 기억	Semantic	사실·개념	이름, 선호도, 회사 정보
일화 기억	Episodic	경험·사건	과거 상담, 해결한 문제
절차 기억	Procedural	규칙·방법	응대 스크립트, 업무 절차

⚡ Short-Term (단기)

Thread-scoped · 세션 종료 시 소멸

대화 히스토리 · 세션 상태 · 임시 계산 · 작업 진행도

구현: Session State · Checkpointer

🗄️ Long-Term (장기) · 영속

Cross-thread · 사용자/조직 범위

Semantic 의미 — 사실·개념·프로필

Episodic 일화 — 경험·이벤트·이력

Procedural 절차 — 규칙·프로세스·지침

구현: MemoryService · Store

그림 2. 메모리 유형 체계 — 단기는 휘발성 작업 기억, 장기는 영속적 지식(의미·일화·절차).

3. 범위와 생명주기 — 무엇을, 얼마나 오래 기억할까

메모리 설계의 핵심 질문은 둘입니다. 누가 접근하는가(범위)와 언제까지 사는가(생명주기). 유형별로 정리하면 이렇습니다.

메모리 유형	범위	생명주기	저장 내용
Short-Term	현재 세션	세션 종료 시 소멸	대화 히스토리, 상태
Semantic	사용자/조직	영구적	프로필, 설정
Episodic	사용자	영구적 (TTL 가능)	경험, 이벤트
Procedural	조직	영구적	규칙, 프로세스

Google ADK는 이 "범위"를 State 접두사로 아주 간결하게 표현합니다. 키 이름 앞에 붙이는 접두사 하나로 저장 범위와 수명이 정해집니다.

user:

사용자 전체 · 영구

user:name

app:

앱 전체 · 영구

app:version

(없음)

현재 세션 · 종료까지

current_task

temp:

현재 호출만 · 삭제

temp:cache

그림 3. Google ADK State 접두사 — 키 이름 앞 접두사가 범위와 생명주기를 결정한다.

4. 핵심 구성요소 — 메모리를 이루는 6개의 부품

프레임워크가 달라도 메모리를 이루는 부품의 역할은 같습니다. 각 부품이 단기·장기 중 어디에 속하고 어느 프레임워크의 것인지 함께 보면, 뒤 구현 3종이 모두 이 표의 변주임이 보입니다.

구성요소	역할	메모리	프레임워크
Session	단일 대화 스레드(메시지+이벤트+상태) 컨테이너	단기	ADK
State	세션 내 동적 데이터(key-value)	단기	ADK
output_key	Agent 응답을 State에 자동 저장	단기	ADK
state_delta	여러 상태를 명시적으로 갱신	단기	ADK
Checkpointer	그래프 실행 상태 저장(단기 영속화)	단기	LangGraph
Store	네임스페이스 기반 장기 저장소	장기	LangGraph

결국 한 문장으로 모입니다 — 단기는 Session·State·Checkpointer로, 장기는 Store(ADK는 MemoryService)로.

5. 구현 ① LangGraph Checkpointer — 단기 메모리의 기본기

LangGraph에서 단기 메모리는 Checkpointer가 담당합니다. 그래프 실행 상태를 턴마다 스냅샷으로 저장해, 같은 대화를 이어가게 해줍니다. 개발용은 휘발성 MemorySaver입니다.

PYTHON · MemorySaver + thread_id로 대화 잇기

from langgraph.graph import StateGraph, START, END from langgraph.graph.message import add_messages from langgraph.checkpoint.memory import MemorySaver class ConversationState(TypedDict): messages: Annotated[Sequence[BaseMessage], add_messages] # 메시지 누적 리듀서 user_name: str turn_count: int checkpointer = MemorySaver() # 개발용(휘발성) graph = builder.compile(checkpointer=checkpointer) # thread_id가 같으면 = 같은 대화(히스토리 유지) config = {"configurable": {"thread_id": "conversation-001"}} graph.invoke({"messages": [HumanMessage("제 이름은 김철수입니다")]}, config) graph.invoke({"messages": [HumanMessage("제 이름이 뭐였죠?")]}, config) # → AI가 "김철수"를 기억! (Checkpointer가 이전 상태 로드)

핵심은 둘입니다. thread_id가 같으면 히스토리를 잇고, 다르면 완전히 독립된 새 대화가 됩니다(고객별 격리). 그리고 add_messages 리듀서가 노드 반환값을 자동으로 누적합니다. 저장된 체크포인트는 graph.get_state()·checkpointer.list()로 조회해 타임트래블(이전 상태 복원·디버깅·감사)도 가능합니다.

6. 구현 ② LangGraph 영속 메모리 — 프로덕션의 Checkpointer + Store

프로덕션에서는 휘발성 메모리로는 안 됩니다. 단기는 PostgresSaver(ACID 보장)로, 세션을 넘는 장기 메모리는 PostgresStore로 영속화합니다. Store는 네임스페이스 튜플로 메모리를 계층화합니다.

PYTHON · 단기(Checkpointer) + 장기(Store) 통합

from langgraph.checkpoint.postgres import PostgresSaver from langgraph.store.postgres import PostgresStore with ( PostgresStore.from_conn_string(DB_URI) as store, # 장기 PostgresSaver.from_conn_string(DB_URI) as checkpointer, # 단기 ): def call_model(state: MessagesState, config, *, store): user_id = config["configurable"]["user_id"] namespace = ("memories", user_id) # 계층 네임스페이스 memories = store.search(namespace, # 시맨틱 검색 query=state["messages"][-1].content) # ...메모리를 활용해 응답 생성... graph = builder.compile( checkpointer=checkpointer, # 단기 메모리 store=store, # 장기 메모리 ) # 장기 메모리 CRUD store.put(("memories", "user_123"), "lang_pref", {"language": "Korean"}) item = store.get(("memories", "user_123"), "lang_pref")

대용량·고동시성 환경이면 AsyncPostgresSaver로 비동기 처리하고, 캐싱·TTL이 중요하면 RedisSaver를 씁니다. Checkpointer는 "이 대화"를, Store는 "이 사용자"를 기억한다고 보면 정확합니다.

7. 구현 ③ Google ADK — output_key와 state_delta

Google ADK는 Session.state를 중심으로 메모리를 다룹니다. 가장 간단한 길은 output_key — Agent 응답이 자동으로 State에 저장되고, 다음 Agent가 {변수} 템플릿으로 참조합니다.

PYTHON · output_key 자동 저장 + Multi-Agent 상태 공유

from google.adk.agents import LlmAgent, SequentialAgent extractor = LlmAgent( name="ExtractorAgent", instruction="핵심 정보를 추출하세요.", output_key="extracted_info", # → state["extracted_info"]에 자동 저장 ) analyzer = LlmAgent( name="AnalyzerAgent", instruction="다음을 분석하세요: {extracted_info}", # 앞 결과를 템플릿 참조 output_key="analysis_result", ) pipeline = SequentialAgent(sub_agents=[extractor, analyzer]) # 상태 자동 공유

여러 값을 한 번에 바꾸거나 시스템 이벤트로 상태를 갱신할 땐 EventActions.state_delta를 쓰고 append_event()로 적용합니다(state를 직접 수정하지 않는 것이 원칙). 장기 메모리는 MemoryService가 맡아 add_session_to_memory()로 저장하고 search_memory()로 다른 세션에서 검색합니다.

8. 프레임워크 비교 — 같은 목표, 다른 어휘

두 프레임워크는 "기억한다"는 본질은 같고 부르는 이름과 추상화가 다릅니다. 한 표로 대응시켜 두면 어느 쪽을 읽어도 번역이 됩니다.

기능	Google ADK	LangGraph
단기 메모리	Session.state + output_key	Checkpointer
장기 메모리	MemoryService	Store
자동 저장	output_key="변수명"	add_messages 리듀서
명시적 저장	EventActions.state_delta	store.put(namespace, key, value)
범위 지정	접두사 (user:, app:, temp:)	Namespace 튜플
시맨틱 검색	VertexAI RAG	store.search(namespace, query=)
세션 식별	session_id, user_id	thread_id

그림 4. 메모리 기능 대응표 — ADK의 어휘와 LangGraph의 어휘.

9. 백엔드 선택 — 개발은 InMemory, 운영은 영속 스토리지

메모리의 "그릇"은 요구사항에 따라 고릅니다. 빠르게 만들 땐 InMemory, 무결성이 중요하면 PostgreSQL, 속도가 생명이면 Redis, 의미 검색이 필요하면 Vector Store입니다.

InMemory

개발/테스트

빠름 · 설정 불필요 · 휘발성

PostgreSQL

트랜잭션

ACID · 감사 추적 · 복잡 쿼리

Redis

고성능

초고속 · TTL 지원 · 캐싱

Vector Store

시맨틱

유사도 검색 · 임베딩 비용

VertexAI

관리형

인프라 불필요 · 자동 확장

개발은 InMemory로 POC → 운영은 PostgreSQL/Redis로 영속화가 정석. Google Cloud면 VertexAI 관리형도 후보.

그림 5. 메모리 백엔드 선택 — 요구사항(속도·무결성·검색·운영부담)으로 고른다.

10. 엔터프라이즈 — CRM·ERP·Groupware의 기억

메모리는 엔터프라이즈에서 가장 직접적으로 ROI로 환산됩니다. 시스템마다 기억해야 할 것이 다르고, 그 효과도 측정 가능합니다.

🤝 CRM

고객 프로필·상담 이력·선호도·구매 패턴·VIP 규칙

상담 시간 40%↓

고객 만족도 25%↑

전환율 35%↑

이탈율 20%↓

🏭 ERP

프로세스 상태·승인 워크플로·의사결정 로그·예외 패턴

처리 시간 50%↓

일관성 80%↑

오류율 60%↓

감사 준비 70%↓

💬 Groupware

협업 컨텍스트·회의 기록·프로젝트 지식·팀 규칙

온보딩 시간 65%↓

회의 시간 30%↓

생산성 45%↑

업무 연속성 90% 보장

그림 6. 엔터프라이즈 메모리 적용과 ROI — CRM·ERP·Groupware별 기억 대상과 효과.

비용 관점으로도 분명합니다. PostgreSQL 메모리 인프라($500/월)로 상담 비용 $5,000/월을 절감하면 ROI 900%, 개발·통합($30,000 일회성)으로 연간 $120,000을 효율화하면 연 300%입니다.

11. 케이스 스터디 — 옴니채널 상담과 도입 로드맵

대표 시나리오는 옴니채널 고객 상담입니다. 고객이 채팅으로 문의를 시작해 전화로 이관하고 이메일로 후속 조치를 받아도, 모든 채널이 같은 메모리를 공유해 컨텍스트가 끊기지 않습니다. 단기(현재 상담)는 PostgresSaver가, 장기(고객 프로필·상담 이력)는 PostgresStore가 책임집니다.

1

파일럿

1~2개월

단일 채널 · InMemorySaver POC

→

2

확장

2~3개월

Postgres 전환 · Store 추가 · 레거시 연동

→

3

최적화

3~6개월

TTL 자동 정리 · 성능 튜닝

→

4

고도화

6개월+

시맨틱 검색 강화 · 크로스 시스템 통합

성능 목표: 메모리 조회 <50ms(P95) · 체크포인트 저장 <100ms(P95) · 동시 세션 >1,000

그림 7. 메모리 도입 4단계 로드맵 — 파일럿에서 고도화까지.

12. 베스트 프랙티스 — 쓸지 말지, 어떻게 쓸지

메모리는 강력하지만 공짜가 아닙니다(저장 비용·검색 지연·개인정보 책임). 쓸 자리와 피할 자리를 먼저 가립니다.

✅ 권장

다중 턴 대화 봇 (컨텍스트 유지 필수)

개인화 서비스 (선호도·히스토리)

복잡한 다단계 작업 (진행 상태 추적)

CRM/ERP 통합 (고객·프로세스 상태)

⛔ 비권장

단순 일회성 질의응답 (오버헤드)

익명 사용자 서비스 (개인화 불가)

실시간 스트리밍 (지연 허용 불가)

극도로 높은 동시성 (동기화 복잡)

실무 체크리스트: ① 범위 정의(세션/사용자/앱) ② 휘발성 판단(temp:로 분리) ③ 긴 대화는 요약·압축(50개 초과 시) ④ TTL 정책(개인정보 규정 준수) ⑤ 민감 정보 마스킹·암호화(GDPR 삭제권·이동권) ⑥ state 직접 수정 금지(append_event 사용) ⑦ 메모리 서비스 장애 시 graceful degradation.

★ 마치며

"순서대로 쪼개라"가 체이닝, "입력에 따라 길을 나눠라"가 라우팅, "독립 작업은 동시에"가 병렬화, "쓴 다음 읽고 고쳐라"가 리플렉션, "모르면 도구를 써라"가 도구 사용, "언제 어떤 순서로 쓸지 계획하라"가 플래닝, "전문가가 협력하라"가 멀티 에이전트였다면 — 메모리 관리는 "겪은 것을 기억하라"입니다. 기억이 생긴 에이전트는 다음 편에서 그 기억으로 배우기 시작합니다.

시리즈: 01 Prompt Chaining → 02 Routing → 03 Parallelization → 04 Reflection → 05 Tool Use → 06 Planning → 07 Multi-Agent → 08 Memory Management → (다음) 09 Learning & Adaptation

#메모리관리 #MemoryManagement #AI에이전트 #Checkpointer #LangGraph #GoogleADK #장기메모리 #생성형AI

안내: 본 글은 Agentic AI Design Patterns 학습 자료(교재·패턴정의·엔터프라이즈 적용전략·구현 3종)를 재구성한 교육용 콘텐츠입니다. 코드는 개념 설명용 예시이며, 프레임워크 API는 버전에 따라 달라질 수 있습니다.