4편에서는 다중 사용자 환경에서 세션 ID와 유저 프로필을 활용해 기억을 안전하게 격리하고 관리하는 구조를 살펴보았습니다. 나만의 고유한 정체성과 맥락을 지키는 격리 벽을 세웠으니 시스템의 안정성은 한층 높아진 셈입니다.
하지만 실제로 AI 에이전트와 수십, 수백 번의 대화를 이어가다 보면 또 다른 현실적인 장벽에 부딪히게 됩니다. 바로 기하급수적으로 늘어나는 대화 텍스트 양과 그로 인한 ‘토큰(Token) 압박’입니다. 앞서 1편에서 언급했듯이, AI는 맥락을 유지하기 위해 이전 대화 기록을 매번 통째로 다시 읽어야 합니다. 대화가 깊어질수록 AI 모델이 한 번에 삼켜야 하는 데이터 덩어리가 비대해지고, 이는 곧 속도 저하와 비용 폭발, 그리고 단기 기억 상실로 이어집니다.
이 토큰 과부하 문제를 해결하기 위해 현업에서 가장 필수적으로 도입하는 소프트웨어 엔지니어링 기법이 바로 ‘메모리 요약(Summarization) 기술’입니다. AI 에이전트가 핵심 맥락을 놓치지 않으면서도 대화 다이어트를 하는 영리한 원리와 실무 적용 팁을 정리해 보았습니다.
무한한 대화가 초래하는 토큰 부채와 Stateless의 한계
- 1사용자 메시지 입력
현재 질문이 새로운 요청으로 LLM에 전달된다.
- 2대화 기록 재첨부
Stateless 모델이 이전 맥락을 이해하도록 과거 메시지를 매 요청에 함께 보낸다.
- 3컨텍스트 윈도우 누적
대화가 길어질수록 전송되는 토큰과 처리 비용이 증가한다.
- 4슬라이딩 윈도우 적용
한도를 넘기기 전에 오래된 메시지를 제외해 입력 크기를 제한한다.
- 5요약 메모리 보존
제외되는 대화의 핵심 정보를 요약해 이후 요청의 맥락으로 유지한다.
대규모 언어 모델(LLM)을 활용해 챗봇이나 에이전트 서비스를 운영할 때 마주하는 벽은 대화 기록이 길어질수록 기하급수적으로 늘어나는 토큰 비용과 컨텍스트 창의 한계입니다. LLM은 이전 대화 상태를 스스로 저장하지 않는 ‘상태 없음(Stateless)’ 구조로 동작합니다. 사용자와 대화를 이어가려면 지금까지 나눈 대화 기록 전체를 매번 새로운 입력값으로 모델에 다시 전송해야 합니다. 이로 인해 대화 턴이 누적될수록 입력 토큰량이 늘어나 비용이 상승하고 모델의 최대 처리 용량인 컨텍스트 윈도우를 초과해 이전 기억을 잃어버리는 현상이 발생합니다.
개발자는 문제를 해결하기 위해 최근 대화 일정 분량만 남기고 오래된 내용을 잘라내는 슬라이딩 윈도우(Sliding Window) 기법을 흔히 사용합니다. 하지만 이 방식은 대화 맥락이 완전히 끊겨 사용자가 이전에 언급했던 정보를 잊어버리는 치명적인 단점을 지닙니다. 시스템 안정성을 유지하면서 대화 흐름을 장기적으로 이어가기 위해서는 단순한 텍스트 삭제가 아닌 지능적으로 정보를 압축하고 선별하는 메모리 요약 기술을 구성해야 합니다.
참고 출처: LangChain 메모리 개념 문서
대화 요약 기법이 마주하는 두 가지 핵심 오해와 비용적 모순
오래된 원문 대화를 짧은 요약으로 바꿔 중요한 사실과 대화 흐름을 보존한다.
전체 기록 대신 요약문을 전송해 컨텍스트 윈도우 점유와 API 입력 비용을 낮춘다.
요약 과정에서 세부 조건이나 표현이 사라질 수 있으므로 원문 보존 범위를 함께 설계해야 한다.
요약 LLM을 호출하는 비용과 지연이 추가되므로 요약 시점과 모델 선택이 중요하다.
대화 요약(Conversation Summarization)을 도입하면 토큰 압박이 완벽하게 해결될 것이라는 생각은 흔한 오해 중 하나입니다. 실제로 대화 요약 기법은 두 가지 결정적인 비용적·기술적 모순을 내포합니다. 첫째는 ‘요약 비용의 모순’입니다. 대화 내용을 압축하기 위해서는 LLM에게 지금까지의 대화를 제공하고 이를 요약하라는 API 요청을 추가로 보내야 합니다. 대화가 빈번하게 일어나는 서비스에서 매 턴 혹은 짧은 주기마다 요약 LLM을 호출하면 요약본을 생성하기 위해 소비하는 입력 및 출력 토큰 비용이 원본 대화를 그대로 보낼 때보다 오히려 더 커질 수 있습니다.
둘째는 ‘요약본 누적의 한계’입니다. 대화가 아주 길어지면 요약본 자체의 분량도 점차 늘어납니다. 수십 번의 대화 턴을 요약한 텍스트가 2,000토큰을 넘어가기 시작하면 이 요약본 자체가 다시 컨텍스트 윈도우를 압박하는 새로운 요인이 됩니다. 결국 요약본을 다시 요약해야 하는 재귀적 요약 구조를 설계해야 하는데 이 과정에서 초기 대화에 담겨 있던 사용자의 미묘한 감정선이나 지시사항의 세부 맥락이 완전히 탈색되어 맥락 손실 현상이 심화됩니다.
참고 출처: arXiv:2310.08560 연구 논문
맥락 손실을 방지하는 하이브리드 메모리와 계층적 요약 아키텍처
| 메모리 계층 | 보관 내용 | 주요 역할 | 운영 특성 |
|---|---|---|---|
| 최근 대화 버퍼 | 가장 최근의 원문 메시지 | 현재 대화의 세부 맥락 유지 | 정확하지만 토큰 사용량이 빠르게 증가 |
| 요약 메모리 | 오래된 대화의 압축 요약 | 긴 대화의 핵심 흐름 유지 | 토큰을 절약하지만 세부 정보가 손실될 수 있음 |
| 에피소드 메모리 | 사용자와의 과거 사건 및 상호작용 | 이전 경험을 현재 대화에 연결 | 필요한 사건을 선택적으로 검색 |
| 시맨틱 메모리 | 사용자나 도메인에 관한 일반화된 지식 | 장기적으로 재사용할 사실 제공 | 구조화와 검색 정확도가 중요 |
단순 요약의 한계를 극복하기 위해 실무에서는 최근 대화는 원문 그대로 유지하고 오래된 대화만 선택적으로 압축하는 하이브리드 메모리(Hybrid Memory) 구조를 채택합니다. 대표적으로 LangChain 라이브러리에서 제공하는 ConversationSummaryBufferMemory 클래스는 설정된 임계 토큰 제한(max_token_limit)을 기준으로 동작합니다. 임계값을 초과하는 오래된 메시지만 골라내어 백그라운드에서 요약본으로 변환하고 최근 대화 버퍼와 이 요약본을 결합해 모델의 입력값으로 전달하는 방식입니다.
다만 작성 기준일인 2026년 7월 현재 최신 프로덕션 환경에서는 LangChain의 기존 메모리 컴포넌트가 레거시로 분류되며 대신 LangGraph와 같은 프레임워크를 활용해 상태(State)를 명시적으로 제어하는 아키텍처로 변모하고 있습니다. 이 아키텍처는 데이터베이스에 원본 대화를 보관하고 세션이 갱신되거나 중요 이벤트가 감지될 때만 비동기적으로 ‘에피소드 메모리(Episodic Memory)’와 ‘시맨틱 메모리(Semantic Memory)’로 이원화하여 요약 및 분류를 진행합니다. 이를 통해 실시간 사용자 대화 흐름의 지연 시간(Latency)을 줄이면서도 장기적인 맥락을 안정적으로 보존할 수 있습니다.
참고 출처: LangChain 하이브리드 메모리 가이드
프롬프트 캐싱과 메모리 요약의 상호보완적 비용 절감 방정식
최근 LLM 공급업체가 제공하는 프롬프트 캐싱(Prompt Caching) 기술은 메모리 요약 전략의 판도를 완전히 바꾸었습니다. 프롬프트 캐싱은 이전 API 호출 시 전송했던 대화 컨텍스트가 다음 호출 시에도 거의 동일하게 유지되면 공급업체의 서버 단에서 이를 캐싱하여 입력 토큰 비용을 대폭 낮춰주는 기능입니다.
실제 비용 효과를 보여주는 구체적인 통계 지표를 살펴보면 Anthropic 사의 공식 기술 문서 기준으로 2026년 7월 기준 Claude 3.5 Sonnet 모델에서 프롬프트 캐싱을 적용할 때 캐시 적중(Cache Hit) 시 입력 토큰 비용은 100만 토큰당 $3.00에서 $0.30로 감소하여 기존 대비 정확히 90%의 비용 절감 효과를 제공합니다. 한편 OpenAI의 개발자 가이드에 따르면 GPT-4o 모델의 경우 캐시 적중 시 입력 토큰 단가를 50% 할인하여 제공하고 있습니다.
이러한 캐싱 혜택을 극대화하려면 입력 프롬프트의 앞부분이 변하지 않고 그대로 고정되어 있어야 합니다. 매 턴 대화 이력을 요약하여 프롬프트를 조금씩 수정하면 캐시가 깨져 할인 혜택을 전혀 받지 못하는 모순이 발생합니다. 따라서 비용을 최적화하기 위해서는 매 턴 요약하는 설계를 지양하고 프롬프트 캐싱이 유지되도록 최근 대화 원문을 그대로 이어 붙여 캐시 적중률을 최대한 높이다가 누적 토큰이 임계점(예: 8,000토큰)에 도달하는 시점에 한 번 요약 작업을 수행하여 캐시를 갱신하는 ‘배치형 요약(Batched Summarization)’ 아키텍처를 도입해야 합니다.
참고 출처: Anthropic 프롬프트 캐싱 가이드
가상 메모리 기법을 활용한 AI 에이전트와 게임 시뮬레이션 설계
- 1현재 대화
즉시 필요한 메시지와 작업 상태를 빠른 단기 메모리에 둔다.
- 2RAM형 컨텍스트
LLM 컨텍스트 윈도우가 현재 처리에 필요한 정보를 직접 유지한다.
- 3Page Out
오래되거나 우선순위가 낮은 정보를 컨텍스트 밖의 장기 저장소로 이동한다.
- 4Disk형 장기 메모리
과거 사건과 지식을 외부 저장소에 보관해 컨텍스트 사용량을 제한한다.
- 5Page In
현재 대화에 필요한 기억을 검색해 다시 컨텍스트로 불러온다.
- 6응답과 상태 갱신
검색된 기억을 이용해 응답하고 새로 얻은 정보를 메모리 계층에 반영한다.
이를 단순 서비스 챗봇이 아닌 복잡한 게임 월드 빌딩이나 시뮬레이션 환경에 대입해 보면 메모리 설계의 복잡성은 한 단계 더 진화합니다. 시뮬레이션 내에서 여러 에이전트가 독자적으로 행동하고 상호작용하는 환경에서는 각 에이전트가 지닌 메모리가 에이전트의 정체성과 행동 방식을 결정하는 핵심 요소가 됩니다. 무한히 돌아가는 루프 안에서 매번 이전 상황을 요약하는 방식은 동시다발적인 멀티 에이전트 환경에서 감당하기 어려운 비용 폭탄으로 돌아옵니다.
이를 극복하기 위해 운영자 관점에서 주목하는 설계는 컴퓨터 운영체제(OS)의 가상 메모리 계층 구조를 LLM에 이식한 MemGPT 아키텍처입니다. MemGPT는 모델의 제한된 컨텍스트 윈도우를 ‘메인 메모리(RAM)’로 취급하고 외부 데이터베이스나 벡터 저장소를 ‘디스크(Disk)’로 취급합니다. 에이전트는 대화 중 중요도가 낮은 세부 묘사나 과거 사건은 백그라운드 데이터베이스에 보관(Page Out)하고 현재 필요한 정보는 검색 쿼리를 스스로 발행하여 컨텍스트 윈도우로 호출(Page In)합니다. 게임 월드 빌딩 시 이러한 가상 메모리 기법을 적용하면 각 NPC가 방대한 역사와 인물 관계를 지니면서도 실시간 상호작용 시에는 최소한의 토큰만 소모하여 물리적 비용과 연산 지연을 제어할 수 있습니다.
참고 출처: MemGPT 연구 논문(arXiv)
대화 흐름의 목적에 따른 맞춤형 메모리 최적화 체크리스트
- 1대화 길이 확인
짧은 대화인지 장기간 이어지는 대화인지에 따라 원문 버퍼와 요약 메모리의 비중을 정한다.
- 2기억 정확도 정의
원문 수준의 세부 정보가 필요한지, 핵심 사실과 흐름만 유지하면 되는지 결정한다.
- 3비용과 지연 평가
전체 기록 전송, 별도 요약 호출, 장기 메모리 검색이 만드는 토큰 비용과 응답 지연을 비교한다.
- 4캐싱 범위 설정
반복되는 시스템 지침과 공통 프롬프트를 캐시해 중복 입력 비용을 줄인다.
- 5하이브리드 구성 선택
최근 원문, 요약, 장기 기억을 서비스 요구사항에 맞게 조합한다.
서비스 성격과 대화 목적에 따라 최적의 메모리 관리 기술을 선택하는 기준은 달라집니다. 모든 아키텍처에 적용되는 단 하나의 완벽한 메모리 기술은 존재하지 않으므로 시스템 설계자는 다음과 같은 의사결정 이정표를 기준으로 자사 서비스에 맞는 기술을 판단해야 합니다.
- 단순 단발성 상담 및 정보 제공형 서비스: 복잡한 요약 로직이나 외부 데이터베이스 연동 없이 최근 3~5회의 대화 턴만 유지하는 단순 슬라이딩 윈도우 기법으로 충분합니다. 요약 프로세스를 생략해 API 지연 시간과 개발 리소스를 크게 줄일 수 있습니다.
- 장기적인 관계 형성이 필요한 페르소나 챗봇: 사용자의 이름, 취향, 과거 고유 에피소드를 보존해야 하므로 최근 대화 버퍼와 요약 메모리를 병합하는 하이브리드 아키텍처가 필수적입니다. 이때 프롬프트 캐싱 효율을 해치지 않도록 요약 주기를 10~20턴 단위로 길게 설정하고 캐시 할인을 최대한 획득하는 구조로 조정해야 합니다.
- 다양한 도구와 상호작용하는 자율형 에이전트: 데이터의 정확한 로드와 갱신이 핵심이므로 벡터 데이터베이스 기반의 RAG 메모리나 가상 컨텍스트 관리 아키텍처를 도입해야 합니다. 필요한 정보만 프롬프트에 동적으로 바인딩하여 토큰 효율을 극대화합니다.
참고 출처: OpenAI 프롬프트 캐싱 가이드
자주 묻는 질문
Q1. 대화 요약을 구현할 때 요약용 LLM은 메인 서비스 모델과 동일한 것을 써야 하나요?
반드시 동일한 모델을 쓸 필요는 없습니다. 대화 요약은 텍스트의 논리적 핵심만 압축하는 비교적 정형화된 작업이므로 메인 대화에는 성능이 높은 고급 모델(예: Claude 3.5 Sonnet)을 사용하더라도 요약 작업에는 비용이 저렴하고 처리 속도가 빠른 경량 모델(예: GPT-4o-mini, Claude 3 Haiku)을 교차 사용하는 것이 전체 운영 비용을 아끼는 데 유리합니다. 다만 경량 모델이 요약하는 과정에서 사용자의 원래 어조나 중요 지시사항을 무시하고 누락하지 않는지 정기적으로 압축 품질을 검증해야 합니다.
Q2. 프롬프트 캐싱 할인을 받기 위한 대화 기록의 배치 요약 주기는 어떻게 설정하는 것이 가장 유리할까요?
토큰 크기와 사용자 평균 대화 턴 수에 따라 조율해야 하지만 일반적으로 캐시가 유지되는 최소 토큰 단위(예: Anthropic의 경우 1,024토큰 단위로 캐시 적용)를 고려하여 대화 누적 토큰이 4,000~8,000토큰 내외에 도달했을 때 요약을 실행하는 것을 권장합니다. 매 대화 턴마다 요약을 갱신하면 매번 캐시가 깨져 입력 비용이 100% 발생하지만 요약 주기를 늘려 프롬프트 앞부분을 고정하면 대다수 호출에서 50%~90%의 캐시 적중 할인을 적용받아 전체 API 요금을 대폭 절감할 수 있습니다.
Q3. 요약 메모리를 사용할 때 시스템 프롬프트나 핵심 규칙(System Instruction)이 흐려지는 현상은 어떻게 방지하나요?
대화 내용이 요약되는 과정에서 시스템 프롬프트까지 함께 요약되도록 방치해서는 안 됩니다. 시스템 프롬프트와 페르소나 정의 규정은 항상 컨텍스트의 가장 최상단이나 고정된 영역에 원문 그대로 박아두고 요약 대상 영역을 마크다운 태그 등을 사용하여 명확하게 구분(예: <conversation_summary>...</conversation_summary>) 지어야 합니다. 이처럼 정적 컨텍스트와 동적 요약 컨텍스트를 분리 설계해야 모델이 시스템의 원칙을 잊지 않으면서도 압축된 대화 이력을 참고할 수 있습니다.
Q4. 벡터 데이터베이스 검색(RAG) 기반의 메모리 방식은 요약 방식과 비교해 어떤 한계가 있나요?
RAG 기반 메모리는 필요한 과거 시점의 기록만 콕 집어 가져오므로 토큰 소모를 크게 낮출 수 있지만 대화가 진행되어 온 시간적 맥락이나 인과관계의 흐름을 파악하기 어렵다는 한계가 있습니다. 예를 들어 사용자가 방금 전 했던 말의 대명사(“그것”, “아까 말한 곳”)가 가리키는 대상을 벡터 검색은 의미적 유사도만으로 정확히 찾아내기 어렵습니다. 따라서 실시간 대화 흐름의 자연스러움을 위해서는 단기 대화 버퍼와 요약 메모리를 기본으로 깔고 아주 오래된 백그라운드 지식을 조회할 때만 RAG 방식을 병행하는 상호보완적 설계가 요구됩니다.
출처
- ↗ LangChain: Memory Types
- ↗ arXiv: MemGPT: Towards LLMs as Operating Systems
- ↗ Anthropic: Prompt Caching
- ↗ OpenAI: Prompt Caching
다음 편 예고
대화 기록을 무조건 압축하는 것을 넘어, 이제 기억의 종류에 따라 저장 위치와 강도를 다르게 설정해야 합니다. 6편에서는 에이전트가 다루는 데이터를 중요도와 휘발성에 따라 분류하는 ‘계층적 메모리 구조 설계’ 기준을 다룹니다.
댓글 유도 질문
AI와 긴 대화를 나누면서 답변 속도가 눈에 띄게 느려지거나 예전 디테일을 놓치는 현상을 경험해 보신 적이 있나요? 여러분만의 대화 정리 노하우가 있다면 댓글로 공유해 주세요!