대화가 20턴을 넘는 순간, 챗봇이 앞서 확인한 정보를 또 묻기 시작했습니다. 처음엔 프롬프트 문제라고 생각했는데, 로그를 파고들다 보니 원인은 전혀 다른 곳에 있었습니다. AI가 기억할 수 있는 물리적 한계, 즉 컨텍스트 윈도우를 초과하면서 대화 앞부분이 조용히 잘려나가고 있었던 겁니다.
이 글은 그 문제를 직접 겪고 해결한 경험을 바탕으로 씁니다. 이론이 아닙니다. 실제로 고객 상담 자동화 챗봇에서 터진 장애였고, 그 장애를 해결하면서 설계 관점이 완전히 바뀐 경험입니다.
대화 유실: 앞부분이 잘려나가는 이유
컨텍스트 윈도우(Context Window)란 AI 모델이 한 번에 처리할 수 있는 텍스트의 최대 범위를 의미합니다. 사람으로 치면 단기 기억 용량에 해당하는 것으로, 이 한도를 넘어서면 모델은 초과된 내용을 말 그대로 '보지 못하는' 상태가 됩니다. 모델이 게으른 게 아닙니다. 물리적으로 접근할 수 없는 정보입니다.
제가 구축한 고객 상담 자동화 챗봇에서 이 문제가 터졌습니다. 전체 대화 히스토리를 그대로 누적해서 모델에 넘기는 구조였는데, 대화가 쌓일수록 한도를 초과한 앞부분 메시지가 잘려나갔습니다. 고객이 초반에 이미 알려준 이름, 주문 번호, 문의 내용을 챗봇이 다시 묻는 상황이 반복됐고, 서비스 품질은 눈에 띄게 떨어졌습니다.
프롬프트를 수십 번 수정해도 나아지지 않았습니다. 당연한 일이었습니다. 문제는 프롬프트가 아니라 구조 자체에 있었으니까요. 이 경험에서 가장 뼈아팠던 건, 잘못된 원인을 붙잡고 수십 번의 수정을 반복하며 시간을 날린 것이었습니다. 컨텍스트 윈도우 초과는 오류 메시지로 알려주지 않습니다. 그냥 조용히 앞부분을 잘라냅니다. 이게 가장 위험한 부분입니다. 장애가 눈에 잘 안 보입니다.
해결 방향은 대화 요약 삽입이었습니다. 일정 턴이 지나면 이전 대화를 짧게 압축한 요약문을 컨텍스트 앞쪽에 고정하고, 오래된 원문 메시지는 제거하는 방식입니다. 요약을 통해 토큰 소비를 줄이면, 같은 컨텍스트 윈도우 안에서 훨씬 많은 대화 흐름을 담을 수 있습니다. 실제로 이 방식으로 바꾼 뒤 대화가 100턴을 넘어도 맥락이 유지됐습니다.
컨텍스트 윈도우 문제를 설계 단계에서 미리 고려해야 하는 이유가 여기 있습니다. "모델이 길면 다 기억하겠지"라는 가정은 실제 운영 환경에서 꽤 빠르게 무너집니다. 전체 대화 히스토리를 무조건 누적하지 않고, 일정 턴 이후 요약문을 컨텍스트 상단에 고정하는 구조를 처음부터 설계에 넣어야 합니다. 토큰 사용량을 모니터링하고 한도 초과 시점을 미리 파악하는 것도 필수입니다. 저는 이걸 장애를 겪고 나서야 넣었습니다. 처음 설계할 때 이 구조를 갖추고 시작했다면 훨씬 좋았을 겁니다.
Lost in the Middle: 가운데가 사라지는 현상
컨텍스트 윈도우 한도 안에 정보가 들어 있어도 문제가 생길 수 있습니다. 바로 Lost in the Middle 현상입니다. 스탠퍼드대학교 연구팀이 발표한 논문에 따르면, 긴 문서를 처리할 때 LLM은 맥락의 앞부분과 뒷부분에 있는 정보는 잘 활용하지만 가운데에 있는 정보는 상대적으로 놓치는 경향이 있습니다.
저는 긴 계약서 분석 작업에서 이 현상을 실제로 겪었습니다. 문서의 핵심 조항이 한가운데 위치해 있었는데, AI가 엉뚱한 조항을 기준으로 답변을 내놓는 일이 반복됐습니다. 처음에는 모델 오류라고 생각했는데, 핵심 정보를 문서 앞쪽으로 재배치하자마자 정답률이 눈에 띄게 올랐습니다. 솔직히 이건 예상 밖이었습니다. 같은 정보를 어디에 두느냐만 바꿨을 뿐인데 결과가 이렇게 달라질 줄은 몰랐습니다.
다만 이 현상은 모델마다, 컨텍스트 길이마다 다르게 나타납니다. "중요 정보는 무조건 앞뒤에 배치하라"는 말이 퍼져 있는데, 제 경험상 어떤 모델을 쓰느냐에 따라 그 효과 차이가 상당히 다릅니다. 설계 단계에서 어떤 모델을 사용할지를 먼저 파악하고, 그에 맞게 정보 배치 전략을 조정하는 편이 현실적입니다. 특정 모델에서 검증한 전략을 다른 모델에 그대로 적용했다가 다른 결과를 얻는 경우도 충분히 있습니다. 모델이 바뀌면 이 부분도 다시 검증해야 합니다.
RAG: 청킹이 성능을 좌우합니다
이 문제를 보완하는 구조로 RAG(Retrieval-Augmented Generation)가 자주 언급됩니다. RAG란 모델이 답변을 생성할 때 외부 문서 데이터베이스에서 관련 정보를 실시간으로 검색해서 참조하는 방식입니다. 쉽게 말해 모델에게 긴 문서를 통째로 주는 대신, 필요한 부분만 골라서 넘겨주는 구조입니다. RAG를 도입하면 컨텍스트 윈도우 한도 문제와 Lost in the Middle 현상을 동시에 줄일 수 있습니다.
RAG 구현에서 청킹(Chunking)이 성능을 좌우합니다. 청킹이란 긴 문서를 모델이 처리하기 적합한 크기의 조각으로 나누는 작업인데, 청크 크기와 오버랩 비율을 어떻게 설정하느냐에 따라 검색 품질이 크게 달라집니다. 청크가 너무 작으면 문맥이 끊기고, 너무 크면 결국 다시 Lost in the Middle 문제로 이어집니다. 제가 실제로 청크 크기를 512토큰에서 256토큰으로 줄이고 오버랩을 20% 적용했을 때 검색 정확도가 체감상 눈에 띄게 개선됐습니다. 이 부분은 서비스 특성과 문서 유형에 따라 직접 실험해보는 것이 가장 빠른 방법입니다. 정해진 정답이 없고, 같은 서비스라도 다루는 문서 유형이 바뀌면 다시 실험해야 합니다.
컨텍스트 윈도우 문제는 한 번에 완전히 해결되는 게 아닙니다. 운영하면서 계속 다듬어야 하는 설계 영역입니다. 대화 요약 삽입, 정보 배치 전략, RAG 청킹 최적화 중에서 지금 겪고 있는 문제에 가장 직결된 것부터 하나씩 적용해보는 걸 권합니다. 이 세 가지를 순서대로 점검하는 것만으로도 AI 서비스 품질이 눈에 띄게 달라집니다.
참고:
Lost in the Middle 연구 논문: https://arxiv.org/abs/2307.03172
Anthropic 컨텍스트 윈도우 문서: https://docs.anthropic.com/ko/docs/about-claude/models