고객 지원 챗봇을 운영하다 보면 세션 후반부 응답 비용이 초반 대비 4~5배 치솟는 순간이 옵니다. 저도 그 숫자를 처음 봤을 때 잠깐 멍했습니다. 멀티턴 LLM 대화에서 히스토리를 어떻게 관리하느냐는 단순한 최적화 문제가 아니라, 서비스 품질과 비용을 동시에 결정하는 핵심 설계 선택입니다.
슬라이딩 윈도우: 단순함의 함정
멀티턴 대화에서 가장 먼저 떠올리는 전략은 슬라이딩 윈도우(Sliding Window)입니다. 여기서 슬라이딩 윈도우란 전체 대화 이력 중 가장 최근 N개의 메시지만 LLM에 전달하고 나머지는 버리는 방식입니다. 마치 화면을 스크롤하듯 창을 이동시키는 이미지에서 이름이 붙었습니다.
구현이 간단하다는 점에서 저도 처음에 이 방법을 선택했습니다. 코드 몇 줄로 끝나고, 비용 절감 효과도 즉각적이었습니다. 문제는 그다음에 터졌습니다. 고객이 대화 초반에 입력한 계정 정보나 문제 상황이 윈도우 밖으로 밀려나면서, 상담 중반부터 챗봇이 맥락을 잃기 시작한 겁니다. "아까 말씀드렸는데요..."라는 고객 불만이 쌓였고, CSAT(Customer Satisfaction Score, 고객 만족도 점수)가 약 8% 하락하는 걸 데이터로 확인했습니다.
솔직히 이건 예상 밖이었습니다. 최근 10턴이면 충분하다고 생각했는데, 실제 고객 대화는 초반 정보가 끝까지 중요한 구조였습니다. 슬라이딩 윈도우는 콘텐츠 추천이나 단답형 Q&A처럼 앞 맥락 의존도가 낮은 유즈케이스엔 적합하지만, 고객 지원처럼 초반 정보가 누적되는 구조에서는 근본적인 한계가 있습니다.
동적 요약: 기억을 압축하는 기술
두 번째 접근은 동적 요약(Dynamic Summarization)입니다. 오래된 메시지를 그냥 버리는 대신, LLM을 활용해 핵심 내용을 요약본으로 압축한 뒤 원문 대신 요약을 컨텍스트에 넣는 방식입니다. Microsoft의 채팅 완성 공식 문서와 LangChain, LlamaIndex 같은 주요 LLM 프레임워크에서도 공식 지원하는 방법입니다(출처: Microsoft Azure OpenAI).
저는 요약 프롬프트를 "대화의 핵심 결론과 미해결 이슈만 3줄 이내로 요약"으로 설정했습니다. 간결하게 잡아두지 않으면 요약이 또 길어지고, 절감 효과가 희석됩니다. 제 경험상 요약 프롬프트의 길이 제약이 생각보다 훨씬 중요합니다.
스마트 메모리 시스템 연구에 따르면, 전체 히스토리를 압축하는 것이 아니라 핵심 사실만 선별해 저장하는 메모리 형성(memory formation) 방식이 기본 히스토리 관리 대비 토큰 비용을 80~90% 절감하면서 응답 품질을 26% 향상시킨다는 결과가 있습니다(출처: Mem0). 이 수치를 처음 접했을 때 반신반의했는데, 실제로 요약 방식을 적용한 후 저도 입력 토큰이 눈에 띄게 줄어드는 걸 확인했습니다.
다만 동적 요약에는 품질 검증 문제가 따라옵니다. LLM이 생성한 요약이 원본의 핵심을 실제로 잘 보존하는지 수치화하기가 까다롭습니다. 저는 요약본을 별도 저장해두고, 이후 대화에서 고객이 이전 내용을 언급할 때 챗봇 응답의 정확도를 간접 모니터링하는 방식으로 검증했습니다. 완벽한 방법은 아니지만, 요약 품질이 실제로 서비스 품질에 미치는 영향을 체감하기엔 충분했습니다.
하이브리드 전략: 레이어 설계로 균형 잡기
슬라이딩 윈도우의 맥락 손실과 순수 동적 요약의 품질 불안정성을 동시에 해결하려면 하이브리드 전략이 현실적인 답에 가깝습니다. 제가 실제로 운영한 구조는 대화를 세 레이어로 나누는 방식이었습니다.
- 레이어 1 (고정 컨텍스트): 사용자 계정 정보, 현재 이슈 요약 — 항상 유지하고 프롬프트 캐싱 적용
- 레이어 2 (최근 원문): 최근 6턴은 원문 그대로 유지
- 레이어 3 (압축 구간): 7턴 이전 대화는 LLM 요약으로 교체
여기서 프롬프트 캐싱(Prompt Caching)이란 동일하거나 유사한 컨텍스트를 반복 전송할 때 LLM 제공자 서버에서 해당 부분을 캐시해 토큰 처리 비용을 줄이는 기술입니다. 레이어 1처럼 변하지 않는 고정 정보를 캐싱 대상으로 잡으면 비용 절감 효과가 배가됩니다.
이 구조로 전환한 뒤 평균 입력 토큰이 45% 감소했고, CSAT는 슬라이딩 윈도우 적용 전 수준으로 회복했습니다. 비용과 품질 두 마리 토끼를 동시에 잡은 건데, 핵심은 레이어 1에서 '절대 압축하지 않는 정보'를 명확히 정의한 것이었습니다.
Claude Code가 컨텍스트 창 한도에 근접할 때 자동 압축(auto-compaction)을 기본 활성화 상태로 제공하는 것도 같은 철학입니다. 개발자가 별도 구현 없이 장기 코딩 세션을 유지할 수 있게 해주는 이 기능은 프롬프트 캐싱과 함께 작동해 비용을 최적화합니다. 제가 직접 써봤는데, 긴 세션에서도 초반 설계 맥락이 잘 유지되는 편이었습니다.
적응적 압축 트리거와 설계의 본질적 한계
요약을 언제 실행할지, 즉 압축 트리거(compression trigger) 설계도 생각보다 까다로운 엔지니어링 결정입니다. 압축 트리거란 히스토리 압축을 실행하는 조건을 말하며, 이 시점 설계가 잘못되면 중요한 정보가 요약으로 대체되는 타이밍에 문제가 생깁니다.
처음에는 '7턴마다' 고정 주기로 압축을 실행했습니다. 단순하지만, 대화 흐름과 무관하게 동작하다 보니 중요한 정보 교환 직후에 요약이 실행되는 상황이 발생했습니다. 이를 개선해 두 가지 조건을 결합한 적응적 트리거를 구현했습니다. 히스토리가 3,000 토큰을 초과하는 시점이나, 사용자 문제가 해결된 것으로 판단되는 자연적 종결점 중 먼저 발생하는 시점에 압축을 실행하는 방식입니다. 단순 주기보다 컨텍스트 보존율이 체감상 크게 달라졌습니다.
연구자들이 제안한 액티브 컨텍스트 압축(Active Context Compression)은 이 문제를 한 단계 더 깊이 다룹니다. 에이전트가 스스로 이전 추론 과정을 검토하고, 더 이상 필요 없는 중간 스캐폴딩(intermediate scaffolding), 즉 결론 도출 과정에서 발생한 임시 추론 단계들을 능동적으로 제거하는 접근입니다. 점균류가 탐색 후 막힌 경로를 물리적으로 수축시키는 방식에서 영감을 받은 이 연구는, '모든 걸 기억하는 에이전트는 결국 아무것도 유용하게 기억하지 못한다'는 통찰을 바탕에 깔고 있습니다.
제가 보기에 이 통찰은 단순히 에이전트에만 해당하는 이야기가 아닙니다. 어떤 압축 전략을 선택하든, '무엇을 기억할 것인가'를 알고리즘이 결정한다는 사실 자체가 근본적인 한계입니다. LLM 기반 요약은 인간의 기억처럼 태스크 맥락에 따라 유연하게 중요도를 조절하지 못합니다. 따라서 단일 압축 전략이 모든 유즈케이스에 최적일 수는 없고, 서비스 성격에 맞게 레이어 설계와 트리거 조건을 직접 튜닝하는 과정이 불가피합니다.
더 근본적으로는 LLM의 상태 비저장(stateless) 설계 자체가 멀티턴 대화 환경에서 구조적 병목입니다. 매 요청마다 전체 히스토리를 재전송하는 구조는 세션이 길어질수록 필연적으로 비효율이 누적됩니다. 서버사이드 세션 상태 관리나 KV 캐시 영속성 같은 인프라 수준의 해결책이 더 성숙해질 때까지는, 레이어 기반 하이브리드 전략이 현재로서 가장 현실적인 선택지라고 생각합니다.
결국 멀티턴 히스토리 관리는 한 번 설계하고 끝나는 작업이 아닙니다. 저도 지금도 CSAT 데이터와 토큰 비용 지표를 함께 보면서 레이어 경계와 트리거 조건을 조금씩 조정하고 있습니다. 처음부터 완벽한 설계를 목표로 하기보다, 데이터 기반으로 반복 개선할 수 있는 구조를 먼저 갖추는 것이 훨씬 실용적입니다. 비용과 품질의 균형점은 서비스마다 다르고, 그 균형을 찾는 과정 자체가 이 분야에서 가장 중요한 엔지니어링 역량이라고 생각합니다.
참고:
- LLM Chat History Summarization Best Practices (Mem0, 2025): https://mem0.ai/blog/llm-chat-history-summarization-guide-2025
- Active Context Compression in LLM Agents (arXiv, 2026): https://arxiv.org/pdf/2601.07190
- Context Management and Compaction in LLMs (Medium, 2026): https://kargarisaac.medium.com/the-fundamentals-of-context-management
- Automatic Context Compression (AI Forum Medium, 2026): https://medium.com/the-ai-forum/automatic-context-compression-in-llm-agents
- Claude Code Cost Management: https://code.claude.com/docs/en/costs