안녕하세요,
Agentic AI Lab, A-Engineering 담당 B2B Agent팀 조은주입니다.
저희 담당에서는 KT의 다양한 서비스와 기술력을 기반으로, 일반 소비자(B2C)와 기업 고객(B2B)의 니즈에 맞는 AI Agent를 기획하고 개발하고 있습니다. 이러한 에이전트는 고객 상담을 비롯한 개인 비서 에이전트부터, 기업 및 소상공인을 위한 비즈니스 지원형 에이전트에 이르기까지 다양한 영역을 아우르고 있습니다.
최근 6월, 저희 B2B Agent팀에서는 소상공인 대상 창업상담 에이전트를 정식 출시 하였습니다.
정식 출시 이후에도 에이전트를 더욱 똑똑하게 만들기 위한 노력은 계속되고 있는데요.
여러 노력 중에서도 에이전트가 개인의 취향과 관심사 등의 정보를 기억하여 보다 정밀한 서비스를 제공할 수 있도록,
“메모리 기술”을 적용해본 경험을 이번 아티클에서 공유드리려고 합니다.
메모리 개념부터 설계, 기술적 고민, 그리고 소상공인 에이전트 테스트 결과까지의 경험에서 얻은 인사이트를 담았습니다.
1. 배경
1.1 왜 메모리 도입을 고민하게 되었을까?
창업상담 에이전트는 소상공인 사용자의 질문을 이해하고, 최근 대화 히스토리를 바탕으로 적절한 스킬을 조합하여 답변을 생성합니다. 에이전트는 이러한 정보들을 ‘세션’ 단위로 관리하며, 세션이란 사용자가 에이전트와 여러 번 주고받는 대화의 묶음을 의미합니다. 일반적으로 에이전트는 현재 세션 내에서만 문맥을 유지하고 응답을 생성합니다.
아래 (그림1)은 창업상담 에이전트의 기본 아키텍쳐를 나타낸 것입니다.
(그림1)

1.2 메모리의 필요성
Q. 그렇다면, 스킬셋을 잘 갖추고, 최근 대화를 활용하기만 하면 에이전트가 개인 맞춤 답변을 잘 할 수 있을까요?
A. 반드시 그렇지는 않습니다.
예를 들어 사용자가 다음과 같은 질문을 했다고 가정해보겠습니다:
🙋🏻♂️"저번에 추천해준 상권 말인데, 그거 다시 알려줄 수 있어?"
🙋🏻♀️"지난 번에 내 예산으로는 부족할 것 같다고 했는데 그럼 얼마나 더 필요해?"
이러한 질문들은 과거의 상황, 조건, 추천 이력, 사용자 목표와 같은 개인화된 맥락을 기억하지 못하면 정확한 답변을 제공하기 어렵습니다. 특히 문제가 되는 것은 해당 정보들이 현재 세션의 대화 히스토리에 포함되어 있지 않을 경우 에이전트는 해당 내용을 인식하거나 활용할 수 없다는 점입니다.
사용자가 이전 세션에서 나눈 대화를 기반으로 후속 질문을 하는 경우에 에이전트는 관련 정보를 기억하지 못하고 처음 듣는 질문처럼 반응하거나, 심지어 존재하지 않는 내용을 추론해 응답하는 오류가 발생할 수 있습니다.
결국, 세션 간 맥락을 연결하지 못하면 대화의 연속성과 개인화된 상담 경험을 제공하는 데 근본적인 한계가 발생합니다.
이러한 한계를 해결하기 위해서는 세션을 넘어 사용자와의 상호작용 맥락을 유지할 수 있는
구조화된 기억 장치, 즉 “메모리”의 도입이 필요합니다.
1.3 에이전트에서 말하는 ‘메모리’는 무엇인가요?
에이전트 메모리 = 저장소 + 메모리 관리 로직 + 메모리 활용 방법까지 포함된 개념
에이전트에서 말하는 메모리는 단순한 저장소가 아닙니다. 또한, 에이전트 메모리에 저장되는 데이터는 단순 과거 대화 히스토리가 아닙니다. 에이전트 메모리는 사용자의 발화 중 의미 있고 유용하다고 판단되는 정보만 선택적으로 기억하는 구조화된 기억 장치입니다. 이를 통해 에이전트는 더욱 똑똑하게 문맥을 이해하며, 개인화된 대화를 지속할 수 있습니다.
1.3.1 컨텍스트 윈도우 ≠ 메모리
흔히 에이전트의 ‘기억’을 이야기할 때, 컨텍스트 윈도우를 메모리라고 오해하기 쉽습니다. 하지만 컨텍스트 윈도우는 메모리가 아닙니다. 컨텍스트 윈도우는 LLM이 한 번에 처리할 수 있는 입력 크기로, 토큰 수에 제한이 있습니다. 이 입력 공간에는 다음과 같은 정보가 포함됩니다:
- 시스템 프롬프트: 에이전트의 역할, 행동 지침, 사용 가능한 스킬셋 정보 등을 가진 고정된 입력 값
- 최근 대화 히스토리: 동일 세션 내 사용자 질문과 에이전트 응답의 쌍 (보통 5~15턴)
- 기타 추가 정보: 필요 시 메모리에서 가져온 정보 등 개발자가 설계한 추가 입력
컨텍스트 윈도우에 어떤 정보를 포함할지는 개발자 설계에 따라 자유롭게 구성할 수 있습니다. 필요하다면 메모리에서 가져온 정보도 이 공간에 넣을 수 있죠. 하지만 많은 에이전트들이 사용자별 세션 관리와 기억 구조화가 충분히 구현되지 않은 경우가 많아, 대부분 ‘시스템 프롬프트’와 ‘최근 대화 히스토리’ 위주로 컨텍스트 윈도우를 구성합니다. 이렇게 구성된 컨텍스트 윈도우는 아래와 같은 문제점으로 인해 지속적인 대화 맥락 유지나 개인화된 답변을 제공하기 어렵습니다:
- 토큰 수 제한: 전체 대화를 포함할 수 없어 오래된 내용은 잊히게 됩니다.
- 중요도 고려 불가: 단순히 ‘최근 대화’만 포함되어, 어떤 정보가 중요한지는 고려하지 않습니다.
그렇다면, 단순한 최근 발화만을 컨텍스트 윈도우에 포함하는 대신 대화의 의미나 중요도에 따라 선택적으로 기억된 정보, 메모리가 있다면 어떨까요?
1.3.2 에이전트 메모리의 역할
에이전트 메모리는 사용자-에이전트 간 대화로부터 컨텍스트 윈도우에 넣을 정보를 기억하고, 꺼내 쓰고, 업데이트하는 기능을 포함하는 모듈입니다. 메모리를 통해 에이전트는 다음과 같은 능력을 갖게 됩니다:
- 사용자나 세션을 구분하고
- 중요한 정보를 장기적으로 기억하며
- 기억한 내용을 바탕으로 이후 대화에서도 일관성 있게 응답하며
- 시간이 지남에 따라 정보를 진화시키거나, 불필요한 기억을 제거할 수 있다.
1.3.3 메모리 구분: STM(Short-Term Memory)과 LTM(Long-Term Memory)
에이전트 메모리는 보통 단기 메모리와 장기 메모리 두 가지로 구분됩니다. 그리고 앞서 언급한 최근 대화 히스토리는 단기 메모리 중 하나에 해당한다고 볼 수 있는데요. 이러한 메모리 구분은 사실 인간의 기억 체계를 설명하는 고전 인지심리 이론과도 유사합니다. 바로 [1] 앳킨스-쉬프린 다중-저장 모델(1968)입니다.
[1] 앳킨스-쉬프린 다중-저장 모델(1968)
(그림2)

이 이론은 인간의 기억 체계를 정보 흐름 기반(외부 자극 → 감각 기억 → 단기 기억 → 장기 기억)으로 설명합니다:
(표1)
감각 메모리 (Sensory Memory) |
단기 메모리 (Short-Term Memory) |
장기 메모리 (Long-Term Memory) |
|
---|---|---|---|
특징 |
|
|
|
지속 시간 |
0.25초 ~ 2초 |
약 18초~30초 |
잠재적 |
이와 같은 인간의 기억 구조처럼, 에이전트도 의미 있는 정보를 분리 저장하고, 필요할 때 꺼내서 사용하는 구조로 설계됩니다. 실제 에이전트 시스템에서는 이보다 정교한 방식으로 메모리를 구분하여 정의하고 있습니다. (표2)는 최근 AI 에이전트 메모리 프레임워크 및 연구에서 제안된 메모리 정의입니다.
[2-6] 최신 에이전트 프레임워크 및 메모리 연구
(표 2)
연구 |
메모리 분류 |
메모리 정의 |
특징 |
---|---|---|---|
[2] Langgraph |
STM |
STM |
한 대화 세션 안에서 유지되는(Thread-scoped)대화 내역 및 상태, 업로드 된 문서 정보 |
LTM |
LTM |
여러 스레드에 걸쳐관리되는 정보로, 사용자 정보, 선호도, 기타 지식 |
|
[3] Generative Agent (2023) |
STM |
검색 메모리 (Retrieved Memory) |
현재 상황과 관련된 기억 정보, 최신성, 관련성, 중요도를 기준으로 장기 기억(메모리 스트림)에서 추출되는 정보 |
LTM |
메모리 스트림 (Memory Stream) |
경험한 사실, 대화, 관찰 기록 정보 |
|
시간이 지남에 따라 과거 기억들을 종합해 합성되는 정보 (Reflect을 통해 만들어진 고차원 지식) |
|||
행동 계획 정보 (Planning을 통해 만들어진 절차 지식) |
|||
[4] CoALA (2023.9) |
STM |
작업 메모리 (Working Memory) |
현재 의사결정에서즉시 사용 가능한 정보, 추론을 통해 생성되거나장기 기억에서 인출된 능동적인 지식 |
LTM |
의미 메모리 (Semantic Memory) |
사실, 상식 정보 |
|
일화 메모리 (Episodic Memory) |
과거 경험과 행동 시퀀스 정보 |
||
절차 메모리 (Procedural Memory) |
작업 수행에 사용되는 규칙, 방법과 같이내재화된 지식 |
||
[5] mem0 (2025) |
STM |
대화 히스토리 |
가장 최근 대화 메시지 |
작업 메모리 |
현재 대화 상황에서 즉시 필요한 정보(임시 변수, 상태 등) |
||
주의 컨텍스트 (Attention Context) |
집중해야 할 컨텍스트 영역 |
||
LTM |
사실 메모리 (Factural Memory) |
사용자의 속성, 도메인 지식, 선호도 등 사실 기반 정보 |
|
의미 메모리 |
일반적인 개념 및 관계 정보 |
||
일화 메모리 |
과거 경험이나 그와 관련된 상황 정보 |
||
[6] MemGPT, Letta (2024) |
STM |
메시지 버퍼 (Message Buffer) |
최근 대화 히스토리, 함수 호출 결과 정보 (FIFO큐 형태), 필요 시 아카이브 메모리로 저장 |
STM |
코어 메모리 (Core Memory, In-Context Memory) |
사용자 정보, 선호도, 대화 스타일, 에이전트 페르소나 등 시스템 프롬프트처럼 항상 포함되는 고정 정보 |
|
LTM |
아카이브 메모리 (Archival memory) |
과거 대화 요약, 사용자 경험 등 기타 개인 정보, 벡터 기반 의미 검색으로 불러오는 정보 그리고 임시로 불러온 정보를 Recall Memory라 함 |
이렇듯 메모리의 세부 정의나 구현 방식은 다양하지만, 대부분 다음 두 가지 목적에 따라 메모리를 설계하고 있습니다:
STM
대화 도중 즉시 참조 가능한 상태값
한 세션 내에서 임시적으로 유지되는 정보
컨텍스트 윈도우에 직접 주입되거나 세션 상태로 관리
LTM
여러 세션에 걸쳐 축적되는 개인화된 정보, 사용자 프로필, 과거 발화 요약, 자주 묻는 질문, 선호도 등 지속적으로 보관되는 정보
대화 중 필요할 때 검색, 또는 요약되어 컨텍스트 윈도우에 주입되는 형태
2. 메모리 설계
이 장에서는 저희가 구현한 메모리 기반 에이전트 설계 과정을 공유합니다.
단기 메모리와 장기 메모리라는 기억 구분을 바탕으로, 메모리를 언제 어떤 방식으로 저장하고 활용할 것인지에 대한 고민과 기술적 의사결정을 다루었습니다.
2.1 에이전트 설계 시 핵심 챌린지
에이전트에 메모리를 도입하기 위해 저희는 먼저 다음 세 가지 질문을 던졌습니다:
“무엇을 기억할 것인가?", “언제 기억을 만들고 사용할 것인가?”, 그리고 “기억을 어떤 구조로 표현할 것인가?”
이 질문들을 토대로, 메모리 설계의 핵심 과제를 다음과 같이 정의할 수 있었습니다:
- 정보의 선별 (Selection): 에이전트가 기억해야 할 핵심 정보는 무엇이며, 어떤 기준으로 추출할 것인가?
- 타이밍 (Timing): 대화의 어느 시점에 메모리를 저장 및 갱신하고, 언제 활용할 것인가?
- 표현 형식 (Representation): 기억된 정보를 구조화해서 저장하고, 검색 또는 추론에 적합한 형태로 가공할 수 있는가?
이러한 설계 요소가 명확하지 않으면, 메모리는 단순한 데이터 창고로 전락하거나, 오히려 에이전트의 판단을 방해하는 요인이 될 수 있습니다. 위와 같은 고민을 바탕으로, 저희는 메모리 기반 에이전트 시스템이 가져야 할 핵심 속성 또한 함께 정의하게 되었습니다:
- 상태 (State): 에이전트가 현재 상황을 인식하고 반응할 수 있는가?
- 지속성 (Persistence): 대화 세션이 종료된 이후에도 중요한 정보를 잃지 않고 유지할 수 있는가?
- 선택 (Selection): 기억할 가치가 있는 정보만을 선별해 유지할 수 있는가?
다시 말해서, 상태, 지속성, 선택이라는 세 가지 속성은 ‘좋은 메모리 시스템을 갖춘 에이전트’를 판단하는 핵심 기준이 될 수 있습니다.
2.2 우리가 정의한 메모리 유형
앞서 살펴본 메모리 설계 기준을 바탕으로, 우리는 에이전트에 필요한 기억 정보를 다섯 가지 유형으로 나누어 정의했습니다. (그림3, 표3) 각 메모리는 저장 방식, 유효 기간, 갱신 주기, 활용 시점이 다르며, 이후 설명할 에이전트 아키텍처 및 메모리 흐름 설계에 직접적인 영향을 미칩니다.
(그림3)

(표3)
메모리 분류 |
메모리 정의 |
저장 데이터 |
특징 |
목적 |
---|---|---|---|---|
STM |
대화 히스토리 (conversation history) |
과거 대화 데이터 |
|
|
행동 이벤트 (behavior event) |
클릭, 구매, 앱 실행, 키 입력, 음성 명령 |
|
|
|
상황 상태 (situational state) |
현재 목표, 현재 위치, 기기 사용 여부, 웹페이지/앱 화면 및 GUI상태, 공유 화면 등 |
|
|
|
현재 대화 주제 (active topic) |
일상 대화, 상권 추천,법률 상담 등 사전 정의된 의도 |
|
|
|
LTM |
정체성 (identity) |
소속, 직업, 가치관, 스타일, 관심사, 선호 언어 |
|
|
목표 (goal) |
장기 목표, 프로젝트 일정, 여행 계획 |
|
|
|
문맥 요약 (contextual summary) |
“최근 활동으로 보아 스트레스 지수 높음”, “업무 집중도가 높음” |
|
|
|
과거 대화 주제 (topic) |
일상 대화, 상권 추천,법률 상담 등 사전 정의된 의도 |
|
|
각각의 메모리 유형은 활용 목적과 시점이 뚜렷하게 다릅니다. 다음 절에서는 이러한 메모리 유형이 실제 에이전트 아키텍처 내에서 언제, 어떻게 활용되는지를 설명합니다.
2.3 에이전트 구조 내 메모리 적용 시점
앞서 정의한 메모리 유형을 실제 시스템에 어떻게 적용할 것 인가는, 메모리를 언제 검색하고 어떤 기준으로 사용할 지를 결정하는 설계에 달려 있습니다.
저희는 메모리 활용 방식에 따라 다음 세 가지 구조적 접근 방식을 정의하고 시도했습니다.
1안) 선제적 메모리 활용 방식
2안) 선택적 메모리 활용 방식
3안) 도구로서 메모리 활용 방식
2.3.1 선제적 메모리 활용 방식
항상 메모리를 먼저 검색해서 함께 고려하는 방식
선제적 메모리 활용 방식은 사용자의 입력이 들어왔을 때 LLM(오케스트레이션LLM)에 질의를 전달하기 전 단계에서 메모리 검색 모듈이 먼저 실행되는 방식입니다. 이때 메모리 저장소에서 사용자 관련 메모리(LTM/STM)를 검색한 후, 이를 포함한 전체 컨텍스트를 기반으로 도구 선택 및 플래닝을 수행합니다.
- 장점
- 모든 대화에서 개인화 고려 가능
- 응답 일관성이 높고, 사용자 맥락이 잘 반영됨 - 단점
- 항상 메모리를 검색하여 사용하므로 불필요한 정보까지 포함될 수 있음
- 관련도가 낮은 메모리로 인해 응답 품질 저하 우려

2.3.2 선택적 메모리 활용 방식
이번 대화에 메모리가 정말 필요한가?를 먼저 판단하고 가져오는 방식
선택적 메모리 활용 방식은 LLM(오케스트레이션LLM) 앞단에 판단용 LLM (gpt-4o-mini) 또는 툴 기반 판별 로직을 두고, 메모리의 사용 여부를 결정합니다.
그 판별 결과, 메모리의 도움이 필요하다고 판단되면 관련 메모리를 검색하여 포함시키고, 그렇지 않다면 기존 대화 히스토리만으로 응답을 생성합니다.
- 장점
- 과도한 정보 주입을 방지, 응답 정확성 및 속도 향상 - 단점
- 메모리의 필요성 판단 정확도에 따라 성능이 좌우

2.3.3 도구로서 메모리 활용 방식
메모리도 하나의 도구일 뿐, 필요한 경우에만 호출하는 방식
도구로서 메모리를 활용하는 방식은 메모리 검색기를 도구로 사용하는 구조를 가집니다. 즉, 다른 외부 툴(RAG, API 호출 등)과 동일하게 메모리도 에이전트가 사용할 수 있는 하나의 스킬로 취급되며, 에이전트가 메모리를 조회해야 할지 자체적으로 판단합니다.
- 장점
- 메모리 검색을 최소화하면서 필요한 순간에만 호출 가능하여 에이전트 자율성 및 유연성 향상 - 단점
- LLM(오케스트레이션LLM) 도구 선택 능력에 의존
- 메모리를 과소 활용할 가능성 존재

앞서 소개한 방식들은 서로 배타적이지 않으며, 메모리 사용 유형에 따라 혼합하여 적용할 수도 있습니다. 예를 들어, '정체성' 메모리 유형은 항상 포함(1안), '목표' 메모리 유형은 필요 시에만 포함(2안), '문맥 요약' 메모리 유형은 도구로 판단하여 조회(3안)하는 식으로 유연한 적용이 가능합니다.
2.4 왜 mem0를 선택했는가?
메모리를 에이전트에 도입하기 위해, 저희는 기존 다양한 오픈소스 메모리 프레임워크를 분석하였습니다.
각 프레임워크는 메모리 저장 방식, 검색 및 주입 방식, 업데이트 타이밍, 세션 간 관리 방식 등에서 차이를 보입니다. (표4)
(표4)
프레임워크 |
STM/LTM분리 |
저장소유연성 |
LLM유연성 |
메모리연산 |
관리 도구 및 UI |
인지도 |
특징 요약 |
---|---|---|---|---|---|---|---|
[7] LangChain 자체 Memory |
X |
O |
O |
△ |
X |
|
|
[2] LangGraph 자체 Memory |
△ |
O |
O |
△ |
X |
|
|
[5] mem0 (Cloud) |
△ |
X |
X |
O |
O |
|
|
[5] mem0 (self-hosted) |
△ |
O |
O |
O |
X |
- |
|
[6] MemGPT (Letta) |
O |
△ |
O |
O |
O |
|
|
[8] A-Mem |
X |
X |
△ |
O |
X |
|
|
[9] Zep |
△ |
O |
O |
O |
O |
|
그중에서는 저희는 [5] mem0 (Cloud) 를 선택하게 되었습니다. 그 이유는 다음과 같습니다:
- 직관적인 관리 UI 제공: 웹 대시보드를 기본 제공, 별도 메모리 관리 도구를 구축하지 않아도 메모리 연산 결과를 시각적으로 확인 가능
- 기본적인 메모리 정책 지원: 어떤 정보를 저장하고, 어떤 정보를 제외할 것인지에 대한 저장 정책을 프롬프트로 쉽게 설정할 수 있도록 지원, 빠른 프로토타이핑 가능
- 자동 메모리 관리 및 추적 기능: 메모리 자동 관리 지원, 저장된 메모리의 추적 용이
따라서, 개발, 테스트 단계에서 메모리 개발하고 검증하기에 mem0가 적합하다고 판단하여 테스트를 진행하였습니다.
3. 테스트 및 관찰
해당 절에서는 메모리를 저희 에이전트에 적용했을 때 어떤 변화가 있는지 관찰하였습니다.
3.1 테스트 시나리오
실제 서비스 맥락에서 메모리 효과를 확인하기 위해 저희는 가상의 사용자 페르소나를 사전에 정의하였습니다.
각 페르소나는 실제 서비스 사용자를 모사할 수 있도록 사용자의 관심 업종, 목표, 주요 관심사 등을 구체적으로 설정하였으며, 페르소나 별 가상의 대화 시나리오도 별도 설계하였습니다. 이러한 페르소나와 시나리오는 토픽별, 업종별로 구분된 사용자 질의 테스트셋 600개(토픽 16개, 업종 36개)를 분석하여 작성되었습니다.
다음은 저희가 설계한 페르소나와 그에 따른 대화 예시 중 일부입니다.
3.1.1 가상 페르소나 예시
항목 |
사용자 |
---|---|
업종 |
무인운영 기반 스터디카페 |
성별 및 나이 |
38세, 남성 |
성향 |
|
목표 |
|
주요 관심사 |
|
가상 시나리오 |
|
3.1.2 페르소나 별 대화 상세 예시
세션 항목 |
사용자_1 |
---|---|
세션1 |
오전 고객 유입 전략 고민
TypeScript▼
|
세션2 |
인력 부담 완화 위한 단시간 알바 도입
TypeScript▼
|
3.2 결과
본 테스트에서는 메모리 적용 전, 후 차이를 명확히 관찰할 수 있는 대표 질의를 선정하여 답변 비교를 수행하였습니다.
🙋🏻♂️"혼자 매장을 하루 2~3번 방문해서 관리하는데 버거워요. 알바채용을 고려하는데, 언제 어떤 업무로 뽑으면 좋을까요?"
해당 질의는 에이전트가 사용자 매장의 운영 방식, 피크타임, 과거 질문 내용을 기억하고 있는지에 따라 답변 품질이 달라질 수 있는 대표적인 시나리오입니다. 특히, 사용자가 이전 대화에서 언급한 ‘매장 피크타임’ 및 ‘업종 특성’이 반영되지 않으면, 에이전트는 단순한 일반론적 답변만을 제공할 수밖에 없습니다.
테스트 결과(표7), 메모리 적용 전에는 누구에게나 동일한 일반적인 답변이 제공되는 반면, 메모리 적용 후에는 사용자 매장의 피크타임, 관련 이벤트, 업종 정보까지 기억하여, 보다 똑똑하고 개인화된 답변을 제공하는 것을 확인할 수 있었습니다.
- 메모리 적용 전:사용자 개인 정보 반영 불가, 업종, 매장 특성 무관한 일반적인 템플릿 답변, 실제 매장 피크타임과 불일치할 가능성 존재
- 메모리 적용 후:사용자 매장 피크타임과 과거 발화 정확히 반영, 매장 상황에 맞춘 개인화된 답변 제공
(표7)
사용자 질의 |
에이전트 답변 |
|
---|---|---|
메모리 적용 전 (사장이지app, 05.27기준) |
메모리 적용 후 |
|
[무인운영 기반 스터디카페 소상공인] 혼자 매장을 하루 2~3번 방문해서 관리하는데 버거워요.알바채용을 고려하는데, 언제 어떤 업무로 뽑으면 좋을까요? |
![]() |
![]() |
3.3 추가 메모리 관찰
본 테스트에서는 대화 진행 중에 어떤 형태의 메모리가 저장되는지, 그리고 저장된 메모리가 어떻게 활용되는지 추적하였습니다. 또한, 에이전트 메모리가 사용자 관점에서 충분히 투명하게 관리, 검증 가능한 구조로 동작하는지를 관찰하였습니다.
[사용자 질문] 오전 고객 유입 전략 고민
대화 시나리오 별로 저장된 메모리 항목, 메모리 검색 결과를 아래 (표8)로 정리하였습니다. 이를 통해 어떤 발화가 메모리에 저장되었고(표8의 항목a,b), 어떤 질문에서 어떠한 메모리가 검색되어 사용되었는지(표8의 항목c)를 가시적으로 확인할 수 있습니다.
(표8)
구분 |
사용자 질의 |
에이전트 답변 |
추가되거나 업데이트 된 메모리 |
---|---|---|---|
a |
![]() |
![]() |
추가된 메모리![]() |
b |
![]() |
![]() |
추가된 메모리![]() |
|
… |
… |
… |
c |
![]() |
![]() |
추가된 메모리![]() ![]() |
[사용자 질문] 나에 대해서 아는 내용 말해봐
추가로, 사용자는 에이전트가 자신에 대해 어떤 정보를 기억하고 있는지 직접 확인하고 검증할 수 있어야 합니다. 그래서 “나에 대해서 아는 내용 말해봐”라는 사용자의 질문을 통해, 에이전트가 축적된 메모리를 기반으로 사용자 정보를 정확히 요약하여 응답하는지 또한 확인하였습니다.
사용자질의: 나에 대해서 아는 내용 말해봐 에이전트 답변: 사장님께서 운영 중인 스터디카페와 관련된 정보를 아래와 같이 정리해드릴게요: 1.운영 상황 - 스터디카페를 운영 중이며, 무인매장 형태로 관리하고 계십니다. - 매장을 하루 2~3번 방문하여 관리하고 있지만, 업무가 버겁다고 느끼고 계십니다. 2.운영 시간대별 특징 - 오전 9시부터 12시까지는 매장이 거의 텅 비어 있어 수익이 나지 않는 상황입니다. - 오후 5시부터 9시까지는 자리가 꽉 찰 정도로 붐비며, 특히 오후 피크타임(6시~8시)에 집중적으로 고객이 많습니다. 3.고객 유치 및 마케팅 - 오전 시간대 고객을 늘리기 위해 할인 프로모션과 무료 캡슐커피 제공 방안을 고려하고 계십니다. - 다만, 너무 잦은 할인 프로모션이 기존 정가 손님들에게 부정적인 영향을 미칠까 걱정하고 계십니다. - 정가 손님 중 가격에 민감한 고객이 있음을 인지하고 계십니다. 4.알바 채용 - 오후 피크타임(6시~8시)에 주 3회 알바를 고용하여 바닥 청소와 소모품 보충 업무를 맡기기로 결정하셨습니다. - 4시간 풀타임 알바 채용은 비용 부담이 크다고 느끼고 계십니다. 5.고객 피드백 관리 - 카카오톡을 통해 고객 후기를 지속적으로 모니터링하고 계십니다. 혹시 추가로 궁금한 점이나 더 필요한 정보가 있다면 말씀해주세요! 😊
1234567891011121314151617181920
4. 교훈 및 향후 계획
4.1 교훈
이번 메모리 설계 및 테스트를 통해, 메모리를 에이전트에 적용하는 것으로 대화 품질과 개인화 수준이 실제로 향상될 수 있음을 검증하였습니다.
특히, 단순히 과거 발화를 저장하는 것만으로는 충분하지 않으며, 어떤 정보를 메모리로 저장할 것인지 언제, 어떤 상황에서 저장된 메모리를 꺼내 쓸 것인지를 세밀하게 설계하는 것이 메모리 활용의 핵심이라는 점을 확인할 수 있었습니다.
다만, 이번 테스트에서는 다음 항목에 대한 충분한 검증은 수행하지 못했으며, 향후 실제 서비스 환경에서 반복 실험과 추가 검증이 필요합니다:
- 불필요한 메모리의 관리 및 삭제 타이밍
- 메모리 업데이트 시점 및 자동 갱신 로직
- 메모리 연산이 전체 응답 속도와 비용에 미치는 영향
4.2 향후 계획
향후, 저희는 다음과 같은 방향으로 메모리 기능을 고도화할 계획입니다.
(표9)
항목 |
설명 |
---|---|
메모리 정책 고도화 |
메모리 저장, 업데이트, 삭제와 관련한 메모리 연산 로직을 |
에이전트 간 공유 메모리, 공유 정책 수립 |
동일 사용자가 여러 에이전트를 사용할 경우, |
프라이버시 및 메모리 삭제 정책 강화 |
사용자가 메모리를 조회, 수정, 삭제할 수 있도록 지원, |
메모리 구조 최적화 |
에이전트 응답 속도와 운영 비용을 고려한 |
References
[1] Atkinson, R. C., & Shiffrin, R. M. (1968). Human memory: A proposed system and its control processes. In Psychology of learning and motivation (Vol. 2, pp. 89-195). Academic press.
[2] LangGraph Overview
[3] Park, J. S., O'Brien, J., Cai, C. J., Morris, M. R., Liang, P., & Bernstein, M. S. (2023, October). Generative agents: Interactive simulacra of human behavior. In Proceedings of the 36th annual acm symposium on user interface software and technology (pp. 1-22).
[4] Sumers, T., Yao, S., Narasimhan, K., & Griffiths, T. (2023). Cognitive architectures for language agents. Transactions on Machine Learning Research.
[5] Chhikara, P., Khant, D., Aryan, S., Singh, T., & Yadav, D. (2025). Mem0: Building production-ready ai agents with scalable long-term memory. arXiv preprint arXiv:2504.19413. Memory Types - Mem0
GitHub - mem0ai/mem0: Memory for AI Agents; Announcing OpenMemory MCP - local and secure memory management.
[6] Packer, C., Fang, V., Patil, S., Lin, K., Wooders, S., & Gonzalez, J. (2023). MemGPT: Towards LLMs as Operating Systems.
GitHub - letta-ai/letta: Letta (formerly MemGPT) is the stateful agents framework with memory, reasoning, and context management.
[7] LangChain memory — 🦜🔗 LangChain documentation
[8] Xu, W., Mei, K., Gao, H., Tan, J., Liang, Z., & Zhang, Y. (2025). A-mem: Agentic memory for llm agents. arXiv preprint arXiv:2502.12110.
GitHub - agiresearch/A-mem: A-MEM: Agentic Memory for LLM Agents
[9] Rasmussen, P., Paliychuk, P., Beauvais, T., Ryan, J., & Chalef, D. (2025). Zep: A Temporal Knowledge Graph Architecture for Agent Memory. arXiv preprint arXiv:2501.13956.
GitHub - getzep/zep-python: Zep: Long-Term Memory for AI Assistants (Python Client)
아티클 작성에 도움을 주신 분들
심선희(B2B Agent팀), 신나라(B2B Agent팀)