Skip to main content
이 문서는 GenAI 개념 섹션의 일부입니다.
← AI Agent 아키텍처 개요
Agent가 맥락을 유지하고 과거 경험으로부터 학습하려면 메모리(Memory) 가 필요합니다. 인간의 기억 체계와 유사하게, Agent의 메모리도 여러 유형으로 나뉩니다.

왜 Agent Memory가 핵심인가

메모리 없는 Agent의 한계

메모리가 없는 Agent는 매 대화가 “첫 만남”처럼 시작 됩니다. 사용자가 누구인지, 이전에 어떤 대화를 나눴는지, 어떤 선호를 가지고 있는지 전혀 기억하지 못합니다.
주의 비유: 메모리 없는 Agent = 매일 기억을 잃는 직원. 어제 했던 일을 오늘 또 처음부터 설명해야 합니다. 고객이 “지난주에 말씀드린 환불 건이요”라고 하면, “어떤 환불 건이요?”라고 되물어야 합니다. 이런 Agent에게 복잡한 업무를 맡길 수 있을까요?
구체적으로 메모리가 없을 때 발생하는 문제는 다음과 같습니다:

메모리가 Agent 성능에 미치는 영향

업계 벤치마크와 실제 운영 데이터에 따르면, 적절한 메모리 시스템을 도입한 Agent는 다음과 같은 성능 개선을 보입니다:
  • 작업 완료율 +30%: 이전 맥락을 기억하므로 멀티스텝 작업에서 중간에 실패하는 빈도가 대폭 감소
  • 사용자 만족도 +40%: 반복 질문이 줄어들고 개인화된 응답을 제공하여 체감 품질 향상
  • 평균 대화 턴 수 -25%: 이미 알고 있는 정보를 다시 물어볼 필요가 없어 업무 처리 속도 향상
  • 재방문율 +50%: “기억해주는 Agent”에 대한 사용자 신뢰도 상승
참고 핵심: Memory는 Agent를 단순 도구에서 신뢰할 수 있는 동료 로 격상시키는 핵심 요소입니다. 단순 Q&A 챗봇이라면 메모리 없이도 가능하지만, 업무 자동화 Agent 를 목표로 한다면 메모리 설계가 필수입니다.

메모리 유형

Short-term Memory (단기 기억)

현재 대화의 히스토리(메시지 목록)를 의미합니다. LLM의 Context Window 크기에 의해 제한되며, 모든 Agent가 기본적으로 가지는 가장 기본적인 메모리입니다.

Context Window 관리 전략

LLM의 Context Window는 무한하지 않습니다. 대화가 길어질수록 토큰 예산이 소진되며, 이를 효과적으로 관리하는 전략이 필요합니다.

LangGraph에서 대화 히스토리 관리

Context Window가 가득 찼을 때 전략

대화가 매우 길어져 Context Window 한계에 도달하면 세 가지 접근법을 선택할 수 있습니다: 1. 요약 후 교체 (추천)
2. Sliding Window (단순하지만 효과적)
3. 중요도 기반 선별 유지 (고급)

Long-term Memory (장기 기억)

세션을 넘어 영속적으로 저장되는 정보입니다. 일반적으로 Vector DB나 외부 데이터베이스로 구현하며, Agent가 관련성이 있을 때 과거 상호작용을 검색하여 활용합니다.

구현 아키텍처 3가지

Databricks Vector Search로 Long-term Memory 구현

Lakebase(PostgreSQL)로 구조화 메모리 구현

하이브리드 메모리 아키텍처 (권장)

실무에서 가장 효과적인 방식은 Vector Search + Lakebase를 함께 사용 하는 것입니다:

Episodic Memory (에피소드 기억)

과거 문제 해결 과정의 기록입니다. “지난번에 비슷한 오류가 발생했을 때, 이렇게 해결했다…”와 같은 경험 기반 학습을 가능하게 합니다.

구현 패턴: MLflow Tracing 기반 경험 학습

Agent의 모든 실행은 MLflow Tracing을 통해 기록됩니다. 성공한 실행 경로와 실패한 경로를 분류하고, 유사한 상황에서 성공 패턴을 우선 추천하는 방식으로 Episodic Memory를 구현할 수 있습니다.

경험 기반 학습 아키텍처


Working Memory (작업 기억)

현재 진행 중인 추론을 위한 임시 메모장입니다. 계획(Plan), 중간 결과, 현재 상태 등을 저장하며, Agent State로 구현되는 경우가 많습니다.

LangGraph State를 활용한 Working Memory

Agent Scratchpad 패턴

Scratchpad 는 Agent가 추론 과정에서 중간 메모를 남기는 공간입니다. 복잡한 멀티스텝 작업에서 특히 유용합니다.

메모리 유형별 비교

성공 예시: 고객 지원 Agent가 “지난번에 문의하신 환불 건은 어떻게 되셨나요?”라고 물을 수 있으려면 Long-term Memory 가 필요합니다. 현재 세션의 대화만으로는 이전 세션의 맥락을 알 수 없기 때문입니다.
주의 현재 대부분의 Agent는 Short-term Memory만 가집니다. Long-term Memory는 Vector Search나 Lakebase(PostgreSQL)를 활용하여 별도 구현해야 합니다. Agent 프레임워크가 자동으로 제공하는 것이 아닙니다.

현업에서의 Agent Memory 구현 패턴

실제 기업들이 운영 환경에서 채택하는 메모리 패턴은 다음과 같이 분류됩니다:

Session Memory

가장 기본적인 패턴으로, ChatAgent의 messages 파라미터가 이에 해당합니다. 별도 인프라 없이 구현 가능하며, 대부분의 Agent 프레임워크에서 기본 제공합니다.

User Profile Memory

사용자가 처음 접속했을 때 프로필 정보를 로드하여 System Prompt에 주입합니다. 대화 중 새롭게 파악된 정보(직책 변경, 새로운 선호 등)를 자동 갱신합니다.

Knowledge Memory

Agent가 업무를 수행하면서 새로 학습한 지식을 축적합니다. 예를 들어, “이 회사의 환불 정책은 구매 후 30일 이내”라는 정보를 한 번 확인하면 메모리에 저장하여, 이후 같은 질문에 즉시 답변합니다.

Team Memory

Multi-Agent 시스템에서 Supervisor Agent와 Worker Agent들이 공유하는 메모리입니다. 한 Agent가 발견한 정보를 다른 Agent가 활용할 수 있어, 중복 작업을 방지합니다.

Memory 솔루션 비교

참고 Databricks 환경에서의 권장 조합: Vector Search(의미 검색용 Long-term Memory) + Lakebase(구조화 프로필 데이터) + LangGraph Checkpointer(세션 관리). 이 조합은 별도 외부 서비스 없이 Databricks 플랫폼 내에서 완결됩니다.

메모리 설계 베스트 프랙티스

1. TTL(Time-To-Live) 설정

오래된 메모리는 가치가 떨어지거나 오히려 해로울 수 있습니다. 3년 전 선호했던 제품을 지금도 추천하면 오히려 역효과입니다.

2. 메모리 요약(Consolidation)

주기적으로 세부 기억을 요약하여 저장 공간을 절약하고 검색 품질을 높입니다.

3. 선택적 망각(Selective Forgetting)

모든 것을 기억하는 것이 능사가 아닙니다. 관련 없는 기억은 삭제하고, 특히 개인정보 삭제 요청(GDPR Right to Erasure) 에 대응할 수 있어야 합니다.

4. 메모리 범위(Scoping)

메모리의 접근 범위를 명확히 구분해야 합니다:

5. 검색 전략: 복합 랭킹

메모리 검색 시 Vector similarity만으로는 부족합니다. 여러 신호를 결합하여 최적의 기억을 찾아야 합니다.

메모리 안티패턴

실무에서 흔히 발견되는 메모리 설계 실수와 해결 방법입니다:
주의 Context Pollution은 가장 흔한 안티패턴 입니다. 관련 없는 과거 기억이 프롬프트에 포함되면 LLM이 혼란을 일으켜 오히려 메모리가 없는 것보다 나쁜 결과를 만들 수 있습니다. 반드시 관련도 임계값 을 설정하세요.

Databricks에서 Agent Memory 구축 가이드

실전에서 Databricks 플랫폼 위에 Agent Memory를 단계별로 구축하는 방법입니다.

Step 1. Session Memory — 기본 제공

ChatAgent의 messages 파라미터를 활용하면 별도 구현 없이 세션 내 메모리를 사용할 수 있습니다.

Step 2. User Profile Memory — Lakebase 활용

Step 3. Semantic Memory — Vector Search 활용

Step 4. 하이브리드 통합 — System Prompt에 메모리 주입

모든 메모리를 통합하여 Agent의 System Prompt에 주입하는 최종 단계입니다.

고객 FAQ

”메모리 없이 Agent를 운영할 수 있나요?”

단순 Q&A는 가능합니다.”오늘 날씨 알려줘”, “이 함수 사용법 알려줘” 같은 단발성 질문에는 메모리가 필요 없습니다. 하지만 다음 중 하나라도 해당되면 메모리가 필수입니다:
  • 사용자별 개인화 가 필요한 경우
  • 이전 대화의 맥락을 이어가야 하는 경우
  • Agent가 과거 경험으로부터 학습 해야 하는 경우
  • 멀티스텝 작업 에서 중간 결과를 추적해야 하는 경우

”메모리 구현에 어떤 DB를 써야 하나요?”

Databricks 환경이라면 Vector Search + Lakebase 조합을 권장 합니다.
  • Vector Search: 자연어 기반 의미 검색. “지난번 환불 관련 대화” 같은 퍼지 검색에 적합. Unity Catalog 통합으로 권한 관리 자동.
  • Lakebase (PostgreSQL): 구조화된 데이터 저장. 사용자 프로필, 설정값 등 정확한 조회에 적합. 서버리스로 관리 부담 최소.
  • 두 가지를 결합 하면 “이름이 뭐였지?” (구조화 조회)와 “비슷한 문제를 겪은 적 있나?” (의미 검색)를 모두 처리할 수 있습니다.

”메모리 데이터는 어떻게 보호하나요?”

세 가지 계층으로 보호합니다:
  1. 접근 제어: Unity Catalog ACL을 통해 메모리 테이블/인덱스에 대한 읽기/쓰기 권한을 세밀하게 관리합니다. Agent별, 팀별로 접근 가능한 메모리 범위를 제한할 수 있습니다.
  2. PII 마스킹: 메모리 저장 전에 개인정보(이름, 전화번호, 주민번호 등)를 자동 탐지하여 마스킹합니다. Databricks의 AI Functions(ai_mask())를 활용하면 편리합니다.
  3. TTL 기반 삭제: 보존 기한이 지난 메모리는 자동 삭제하여 불필요한 데이터 보유를 방지합니다. GDPR/PIPA 등 개인정보 보호법 준수에 필수적입니다.

”메모리가 많아지면 성능이 느려지지 않나요?”

적절히 설계하면 문제가 되지 않습니다. 핵심 전략은 다음과 같습니다:
  • TTL + Consolidation: 오래된 세부 기억은 요약하고, 만료된 기억은 삭제
  • 관련도 임계값: Vector Search에서 유사도가 낮은 결과는 필터링
  • 인덱싱 최적화: Lakebase에 적절한 인덱스 설정, Vector Search에 메타데이터 필터 활용
  • 비동기 저장: 메모리 저장은 응답 반환 후 비동기로 처리하여 사용자 체감 지연 최소화

다음: Multi-Agent 패턴 →