첫 메시지는 10초, 100번째는 30초가 되는 이유
당신의 에이전트가 처음에는 빠르지만 대화가 길어질수록 느려지는 현상을 겪었나요? 사용자와 나눈 대화가 50개, 100개를 넘어가면서 응답 속도가 점점 떨어집니다. 가끔 타임아웃이 나기도 합니다. 같은 모델인데 왜 이런 일이 일어날까요?
문제는 모델이 아닙니다. 문제는 당신이 과거의 모든 대화를 프롬프트에 집어넣고 있다는 점입니다. 지금 이 순간, 사용자의 마지막 메시지 하나를 처리하기 위해 지난 100번의 대화 전부를 토큰화해서 메모리에 올립니다. 그렇게 되면 토큰 비용도 올라가고, 응답 시간도 느려지고, LLM의 정확도도 떨어집니다.
2026년 현재, 많은 개발자들이 이 현상을 “컨텍스트 로트”라고 부릅니다. 깨진 냉장고처럼 시간이 지날수록 정보가 부패합니다. 처음에는 신선하던 맥락 정보가 점점 오염되고, 모델의 성능이 눈에 띄게 떨어집니다. 이를 해결하는 것이 2026년 에이전트 개발의 핵심 과제입니다.
컨텍스트 윈도우는 거짓말쟁이다
광고에서는 128K, 심지어 1백만 토큰까지 처리한다고 떠벌립니다. 그런데 현실은 다릅니다. 실제 사용 환경에서 안정적으로 작동하는 범위는 4K에서 8K 정도입니다. 대규모 컨텍스트를 처리할 수 있다는 것은 기술적으로 사실이지만, 정확도는 보장하지 않습니다.
예를 들어 GPT-4o는 128K 토큰을 처리할 수 있다고 선전하지만, 실제 벤치마크 테스트에서는 관련 정보가 컨텍스트 후반부에 있으면 찾지 못합니다. Claude도 마찬가지입니다. 형식적으로는 막대한 컨텍스트를 다룰 수 있지만, 의미 있는 추론은 4K에서 8K 범위에서만 제대로 작동합니다.
이 불일치의 이유는 아키텍처에 있습니다. LLM은 KV 캐시라는 메커니즘으로 이전 토큰의 정보를 저장합니다. 컨텍스트가 길어지면 이 캐시도 커집니다. 결국 메모리 대역폭의 병목이 생깁니다. 모델은 토큰을 생성하는 데 더 이상 계산을 쓰지 않고, 데이터를 옮기는 데만 시간을 씁니다. 게다가 컨텍스트가 길어질수록 “관련 없는 정보를 찾아내기”라는 추가 작업이 생깁니다. 모델이 동시에 두 가지를 해야 하는 거죠. 관련 정보를 찾고 동시에 추론하기. 바로 여기서 성능 저하가 발생합니다.
당신의 에이전트가 느려지는 기술적 이유
에이전트의 메모리 문제를 이해하려면 먼저 어디가 병목인지 파악해야 합니다. 응답 시간이 느려지는 것은 세 가지 원인 때문입니다.
첫 번째는 토큰 비용입니다. 매번 전체 대화 이력을 프롬프트에 담으면, 입력 토큰 수가 선형적으로 증가합니다. 대화 100번이면 수천, 수만 개 토큰입니다. OpenAI의 GPT-4o 기준으로 입력 토큰은 $0.03/1M개인데, 거기에 처리 지연까지 더해지면 경제성이 떨어집니다.
두 번째는 응답 속도입니다. 컨텍스트 길이가 길어질수록 첫 토큰 생성까지의 시간(TTFT, Time To First Token)이 길어집니다. 모델이 모든 이전 토큰의 KV 캐시를 구성해야 하기 때문입니다. 사용자는 10초를 기다리다가 30초를 기다리다가, 결국 답답해합니다.
세 번째는 정확도 손상입니다. 이게 가장 심각합니다. 컨텍스트가 길어지면 모델의 주의력이 흐트러집니다. 100개의 과거 메시지 중에서 현재 질문과 관련된 것이 뭐가 있는지 찾는 것이 어려워집니다. 모델은 중요한 정보를 놓치거나, 불필요한 과거 정보에 집착합니다. 결과적으로 답변의 질이 떨어집니다.
메모리는 한 가지가 아니다
인간의 뇌처럼 에이전트도 여러 종류의 메모리가 필요합니다. 2026년 최고의 에이전트들은 이를 명확히 구분합니다.
단기 기억은 현재 작업에 필요한 정보입니다. 사용자의 최근 3-5개 메시지, 현재 진행 중인 작업 상태, 즉시 필요한 컨텍스트만 포함합니다. 이것이 프롬프트에 들어가는 부분입니다. 일반적으로 2K에서 4K 토큰 범위가 최적입니다.
장기 기억은 외부 저장소입니다. 벡터 데이터베이스, Redis, 관계형 데이터베이스 등을 활용합니다. 모든 과거 대화를 저장하되, 필요할 때만 검색해서 가져옵니다. 예를 들어 사용자의 선호도, 과거 결정 사항, 학습된 패턴 등을 여기에 보관합니다.
절차 기억은 워크플로우와 규칙입니다. 특정 작업을 수행하는 방법, 의사결정 규칙, 시스템 지침 등을 마크다운 파일이나 별도의 명령어 레지스트리로 관리합니다. 이것들은 거의 변하지 않으므로 매번 새로 로드할 필요가 없습니다.
2026년의 정답: 적응형 컨텍스트 관리
이제 어떻게 해야 할까요? 가장 효과적인 전략은 대화 깊이에 따라 동적으로 메모리를 관리하는 것입니다.
처음 5번의 대화에서는 모든 메시지를 포함하세요. 이 단계에서는 문맥 구축이 중요합니다. 그 다음부터는 요약 전략을 시작합니다. 매 5번의 대화마다 일화적 요약을 만듭니다. “사용자가 X에 대해 물었고, 에이전트가 Y를 답변했으며, 사용자는 만족했다”는 식의 단문식 요약입니다. 원본 대화는 벡터 DB에 저장하지만, 프롬프트에는 요약만 포함합니다.
20번 이상의 대화가 누적되면, 중요도 필터링을 적용합니다. 모든 메시지가 동등하게 중요한 것은 아닙니다. 사용자의 현재 질문과 의미적으로 유사한 과거 메시지만 검색해서 프롬프트에 넣습니다. 이를 RAG(검색 증강 생성)라고 부릅니다. 벡터 임베딩을 사용해 관련성을 계산합니다.
100번 이상의 대화가 있다면, 메타 메모리를 구축합니다. “사용자의 주요 관심사는 X, Y, Z이고, 과거에 X에 대해 Z번 물었으며, 선호하는 답변 스타일은 간결한 형식”이라는 메타 정보를 저장합니다. 프롬프트에는 이 메타 정보만 포함하고, 구체적인 과거 대화는 필요할 때만 꺼냅니다.
실제 구현: LangGraph와 메모리 체크포인트
LangGraph를 쓰면 이것이 상당히 간단해집니다. LangGraph의 체크포인트 기능을 사용하면 사용자별로 독립적인 메모리 스레드를 관리할 수 있습니다. thread_id를 기반으로 각 사용자의 대화 상태를 분리 저장합니다. 이렇게 하면 한 사용자의 긴 대화가 다른 사용자에게 영향을 주지 않습니다.
더 중요한 것은 상태 축약입니다. 매 5-10개 메시지마다 상태 요약을 실행합니다. 현재까지의 대화, 결정, 사용자 선호도를 간단한 텍스트로 요약하고 벡터 DB에 저장합니다. 이후 새로운 메시지가 들어오면 최근 3-5개 메시지와 함께 이 요약을 프롬프트에 포함시킵니다. 원본 대화는 추가 컨텍스트가 필요할 때만 검색합니다.
Anthropic의 “메모리” 기능을 사용하는 것도 좋은 방법입니다. GPT-5.2 같은 최신 모델들은 사용자 간의 장기 메모리를 보유합니다. 시스템이 과거 대화를 자동으로 요약하고, 사용자의 선호도를 학습합니다. 이렇게 되면 개발자가 직접 메모리 관리를 할 필요가 줄어듭니다.
멀티 에이전트 아키텍처: 컨텍스트를 나누기
대화가 정말 복잡해진다면, 싱글 에이전트 대신 멀티 에이전트 구조를 고려하세요. 각 에이전트가 특정 영역을 담당합니다. 예를 들어, “대화 분석 에이전트”, “의사결정 에이전트”, “실행 에이전트” 이렇게 분리합니다. 각각이 더 작은 컨텍스트 윈도우를 가지지만, 협력하면서 더 큰 문제를 해결합니다.
이 방식의 장점은 각 에이전트가 최적화된 메모리를 가질 수 있다는 것입니다. 대화 분석 에이전트는 과거 100개의 메시지를 분석하되, 의사결정이 필요한 순간에는 필요한 정보만 다른 에이전트에게 전달합니다. 결과적으로 프롬프트 길이는 짧아지고, 처리 속도는 빨라집니다.
2026년 최고의 에이전트들은 이렇게 한다
Anthropic의 Claude Code, OpenAI의 최신 에이전트들, 그리고 실제 프로덕션 환경에서 돌아가는 시스템들을 보면 공통점이 있습니다. 모두 컨텍스트를 엄격하게 관리합니다.
단순히 크기만 큰 컨텍스트 윈도우에 의존하지 않습니다. 대신 정보의 품질과 관련성을 우선시합니다. 현재 작업과 무관한 정보는 철저히 걸러냅니다. 필요한 정보는 여러 번 반복합니다. 시스템 프롬프트는 항상 유지하되, 대화 이력은 동적으로 관리합니다.
마지막으로, 중요한 메시지는 별도로 핀(pin)합니다. 사용자의 최초 설정, 중요한 결정, 에러 사항 등을 별도 버퍼에 유지해서, 아무리 오래된 대화도 쉽게 접근할 수 있게 합니다.
결론: 크기보다는 품질, 속도보다는 정확도
128K 토큰 컨텍스트를 자랑하는 모델을 써도, 실제로는 4K에서 8K 범위에서만 제대로 일합니다. 이것은 제한이 아니라 현실입니다. 중요한 것은 그 한정된 공간을 얼마나 현명하게 사용하는가입니다.
대화가 길어질수록 느려지는 문제는 더 많은 토큰을 담으려고 할 때 생기는 게 아닙니다. 부적절한 정보를 담으려고 할 때 생깁니다. 해결책은 컨텍스트 윈도우를 키우는 것이 아니라, 컨텍스트 관리를 똑똑하게 하는 것입니다.
2026년의 에이전트 개발은 더 이상 “최대한 많이 담기”가 아니라 “필요한 것만 정확하게”입니다. 단기 기억에는 현재 작업 관련 정보만, 장기 기억에는 검색 가능한 형식으로 모든 이력을 저장하고, 절차 기억에는 변하지 않는 규칙과 지침을 보관하세요. 이렇게 하면 아무리 오랫동안 대화해도 응답은 빠르고, 정확도는 유지되고, 비용도 효율적입니다.