LLM은 긴 대화를 어떻게 기억할까?
2026년 6월 3일
ChatGPT와 대화를 하다 보면 신기한 순간이 있습니다.
처음에는 "Next.js가 뭐야?"라고 질문하고 수십 번의 대화를 나눈 뒤, 마지막에 "이거 말고 다른 것은 뭐가 있어?"라고 물어도 ChatGPT는 '이거'가 Next.js를 의미한다는 것을 이해합니다. LLM은 이전 대화를 어떻게 기억하는 걸까요? 모든 대화를 계속 전달하는 것일까요? 아니면 별도의 메모리가 존재하는 걸까요?
이번 글에서는 LLM 기반 챗봇이 과거 대화를 현재 질문의 컨텍스트에 포함시키는 대표적인 방법들을 살펴보겠습니다.
1. Sliding Window
가장 단순한 방법은 최근 N개의 대화를 그대로 LLM에게 전달하는 것입니다. 예를 들어 최근 10개의 대화를 컨텍스트에 포함한다고 가정해 보겠습니다.
User: Next.js가 뭐야?
...
User: 장점이 뭐야?
LLM은 이전 대화를 함께 전달받기 때문에 "장점"이 Next.js의 장점이라는 것을 이해하고 답변할 수 있습니다.
이 방식은 구현이 매우 간단하고 별도의 저장소가 필요하지 않다는 장점이 있습니다. 실제로 대부분의 LLM 애플리케이션은 기본적으로 이 방식을 사용합니다.
하지만 대화가 길어질수록 문제가 발생합니다. 토큰 제한 때문에 오래된 대화를 제거해야 하고, 제거된 대화에 중요한 정보가 포함되어 있다면 현재 질문을 정확하게 이해하지 못할 수 있습니다. 그렇다고 전달하는 대화의 개수를 계속 늘리면 토큰 사용량이 증가하여 비용이 커지고 응답 속도도 느려집니다.
Sliding Window는 가장 기본적인 방법이지만, 긴 대화를 처리하기에는 한계가 있습니다.
2. 과거 대화 요약하기
Sliding Window의 한계를 보완하기 위해 사용하는 방법이 Conversation Summary입니다. 최근 N개의 대화는 그대로 전달하고, 그 이전의 대화는 LLM을 이용해 요약한 뒤 함께 전달합니다.
# 대화 요약
- 사용자는 Next.js를 학습 중이다.
- App Router에 관심이 있다.
- TypeScript를 함께 사용하고 있다.
# 최근 대화
...
# 현재 질문
이렇게 하면 오래된 대화를 모두 전달하지 않아도 전체적인 맥락을 유지할 수 있습니다.
하지만 요약 역시 완벽한 해결책은 아닙니다. 요약은 정보를 압축하는 과정이기 때문에 세부 정보가 사라질 수 있습니다. 또한 요약이 잘못 생성되면 이후의 모든 대화가 잘못된 방향으로 이어질 수도 있습니다.
무엇보다 대화가 계속 길어진다면 요약을 다시 요약하는 과정이 반복되고, 이 과정에서 중요한 정보들이 점점 희미해질 가능성이 있습니다. 따라서 Conversation Summary는 전체적인 맥락을 유지하는 데는 효과적이지만, 과거의 세부 정보를 기억하기에는 한계가 있습니다.
3. Retrieval Memory
그렇다면 오래된 대화를 버리지 않으면서도 필요한 순간에만 가져올 수는 없을까요? 이를 위해 사용하는 방법이 Retrieval Memory입니다. 과거의 대화를 하나 이상의 문서(Document) 단위로 저장하고, 각 문서의 임베딩(Embedding)을 생성하여 Vector DB에 저장합니다.
Document 1
User: Next.js가 뭐야?
Assistant: ...
↓
Embedding
↓
Vector DB
새로운 질문이 들어오면 현재 질문도 임베딩한 뒤, Vector DB에서 의미적으로 가장 유사한 과거 대화를 검색합니다. 예를 들어 사용자가 다음과 같이 질문을 했다면
장점은?
검색 과정에서 다음과 같은 Document를 찾을 수 있습니다.
User: Next.js가 뭐야?
Assistant: ...
그리고 LLM에는 다음과 같은 형태로 프롬프트가 전달됩니다.
# 이전의 대화
User: Next.js가 뭐야?
Assistant: ...
# 현재 질문
장점은?
중요한 점은 LLM은 벡터를 이해하는 것이 아니라 검색을 통해 찾아온 원본 대화를 읽는다는 것입니다. 임베딩은 어디까지나 필요한 대화를 빠르게 찾기 위한 검색 인덱스 역할을 수행합니다.
4. Query Rewriting
Retrieval Memory에도 한 가지 문제가 있습니다. 사용자가 아래와 같이 질문하면 "그게"가 무엇을 의미하는지 검색 엔진은 알기 어렵습니다. 그래서 최근에는 검색하기 전에 LLM을 이용해 검색용 질문을 다시 작성하는(Query Rewriting) 기법을 많이 사용합니다.
그게 왜 필요하지?
예를 들어 아래와 같은 대화가 있었다면 검색용 Query를 "Fast API의 장점"처럼 보다 명확한 문장으로 변경한 뒤 Vector Search를 수행합니다.
User: FastAPI를 배우려고 해.
...
User: 장점은?
또한 하나의 Query만 사용하는 것이 아니라 여러 개의 Query를 생성하여 각각 검색한 뒤 결과를 합치는 Multi Query Retrieval도 많이 사용되고 있습니다.
실제 서비스에서는 어떻게 사용할까?
실제로는 하나의 방법만 사용하는 경우는 거의 없습니다. 대표적인 구조는 다음과 같습니다.
사용자 질문
↓
최근 대화 (Sliding Window)
↓
과거 대화 요약 (Conversation Summary)
↓
Vector Search
↓
검색된 과거 대화
↓
LLM
최근 대화는 그대로 유지하고, 오래된 대화는 요약하여 전체적인 맥락을 유지하며, 필요한 세부 정보는 Retrieval을 통해 다시 가져오는 방식입니다.
이처럼 각각의 방법이 서로의 단점을 보완하도록 조합하여 사용합니다. ChatGPT를 비롯한 대부분의 LLM 서비스도 이러한 여러 기법을 함께 사용하는 것으로 알려져 있습니다.
마치며
LLM은 모든 대화를 그대로 기억하는 것이 아닙니다. 최근 대화는 그대로 전달하고, 오래된 대화는 요약하거나 필요한 순간에만 검색하여 현재 질문과 함께 전달합니다. 결국 중요한 것은 얼마나 많은 정보를 저장하느냐가 아니라, 현재 질문에 필요한 정보를 얼마나 정확하게 찾아와 LLM의 컨텍스트에 포함시키느냐입니다.
최근에는 여기에 Knowledge Graph, Episodic Memory, Reflection Memory와 같은 다양한 메모리 구조가 더해지면서 장기적인 대화에서도 일관성을 유지하려는 연구가 활발하게 진행되고 있습니다.