메모리 설계 베스트 프랙티스
1. TTL(Time-To-Live) 설정
오래된 메모리는 가치가 떨어지거나 오히려 해로울 수 있습니다. 3년 전 선호했던 제품을 지금도 추천하면 오히려 역효과입니다.| 메모리 유형 | 권장 TTL | 근거 |
|---|---|---|
| 대화 히스토리 (세부) | 30일 | 세부 대화는 빠르게 가치 감소 |
| 사용자 선호 | 90일 | 선호는 비교적 안정적이나 변할 수 있음 |
| 학습된 도메인 지식 | 1년 | 정책/규정 변경 주기에 맞춤 |
| 에피소드 (성공 패턴) | 6개월 | 도구/API 변경으로 오래된 패턴이 무효화될 수 있음 |
2. 메모리 요약(Consolidation)
주기적으로 세부 기억을 요약하여 저장 공간을 절약하고 검색 품질을 높입니다.3. 선택적 망각(Selective Forgetting)
모든 것을 기억하는 것이 능사가 아닙니다. 관련 없는 기억은 삭제하고, 특히 개인정보 삭제 요청(GDPR Right to Erasure) 에 대응할 수 있어야 합니다.4. 메모리 범위(Scoping)
메모리의 접근 범위를 명확히 구분해야 합니다:| 범위 | 접근 주체 | 예시 |
|---|---|---|
| Session-level | 현재 대화 세션만 | 현재 대화의 맥락 |
| User-level | 특정 사용자의 모든 세션 | 사용자 선호, 과거 이력 |
| Agent-level | 특정 Agent의 모든 사용자 | Agent가 학습한 도메인 지식 |
| Global-level | 모든 Agent, 모든 사용자 | 공통 정책, 회사 규정 |
5. 검색 전략: 복합 랭킹
메모리 검색 시 Vector similarity만으로는 부족합니다. 여러 신호를 결합하여 최적의 기억을 찾아야 합니다.메모리 안티패턴
실무에서 흔히 발견되는 메모리 설계 실수와 해결 방법입니다:| 안티패턴 | 문제 | 해결 |
|---|---|---|
| 무한 축적 | 메모리가 무한히 커져 검색 성능 저하, 비용 증가 | TTL 설정 + 주기적 Consolidation |
| Privacy 위반 | 개인정보(PII)가 메모리에 영구 저장 | PII 마스킹, 삭제 정책, GDPR 대응 로직 |
| Context Pollution | 관련 없는 기억이 프롬프트에 포함되어 답변 품질 저하 | 관련도 임계값 설정 (예: similarity > 0.7만 포함) |
| 메모리 충돌 | 서로 모순되는 기억이 공존 (예: “부서: 마케팅” vs “부서: 영업”) | 최신 기억 우선(timestamp), 충돌 감지 및 해결 로직 |
| 과도한 의존 | 메모리 시스템 장애 시 Agent 전체가 멈춤 | 메모리를 graceful degradation으로 설계 (없어도 기본 동작) |
| 비용 폭발 | 모든 대화를 벡터 임베딩하여 저장하면 스토리지/컴퓨팅 비용 급증 | 중요한 정보만 선별 저장, 요약 후 저장 |
주의 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): 구조화된 데이터 저장. 사용자 프로필, 설정값 등 정확한 조회에 적합. 서버리스로 관리 부담 최소.
- 두 가지를 결합 하면 “이름이 뭐였지?” (구조화 조회)와 “비슷한 문제를 겪은 적 있나?” (의미 검색)를 모두 처리할 수 있습니다.
”메모리 데이터는 어떻게 보호하나요?”
세 가지 계층으로 보호합니다:- 접근 제어: Unity Catalog ACL을 통해 메모리 테이블/인덱스에 대한 읽기/쓰기 권한을 세밀하게 관리합니다. Agent별, 팀별로 접근 가능한 메모리 범위를 제한할 수 있습니다.
- PII 마스킹: 메모리 저장 전에 개인정보(이름, 전화번호, 주민번호 등)를 자동 탐지하여 마스킹합니다. Databricks의 AI Functions(
ai_mask())를 활용하면 편리합니다. - TTL 기반 삭제: 보존 기한이 지난 메모리는 자동 삭제하여 불필요한 데이터 보유를 방지합니다. GDPR/PIPA 등 개인정보 보호법 준수에 필수적입니다.
”메모리가 많아지면 성능이 느려지지 않나요?”
적절히 설계하면 문제가 되지 않습니다. 핵심 전략은 다음과 같습니다:- TTL + Consolidation: 오래된 세부 기억은 요약하고, 만료된 기억은 삭제
- 관련도 임계값: Vector Search에서 유사도가 낮은 결과는 필터링
- 인덱싱 최적화: Lakebase에 적절한 인덱스 설정, Vector Search에 메타데이터 필터 활용
- 비동기 저장: 메모리 저장은 응답 반환 후 비동기로 처리하여 사용자 체감 지연 최소화
다음: Multi-Agent 패턴 →