1편에서 컨텍스트 윈도우가 왜 유한한지를 봤습니다. 그런데 요즘 모델 스펙을 보면 이런 생각이 듭니다. 이미 100만 토큰짜리 모델이 나왔는데, 그냥 코드베이스든 문서든 통째로 넣으면 되는 것 아닐까. 아껴 쓰고 말고 할 게 있나.
이번 편에서 깰 통념이 바로 이것입니다. 컨텍스트 윈도우에 “들어간다”와 모델이 그걸 “잘 쓴다”는 완전히 다른 문제입니다. 컨텍스트가 길어질수록 모델 성능이 떨어지는 현상은 여러 연구로 확인돼 있고 에이전트를 오래 돌려본 사람이라면 누구나 체감하는 일이기도 합니다. 세션 후반으로 갈수록 답변이 어딘가 산만해지고, 이미 고친 버그를 다시 고치겠다고 나서는 그 순간들 말이죠.
lost in the middle, 중간은 읽히지 않는다
2023년 스탠퍼드 연구진이 발표한 “Lost in the Middle” 논문은 이 분야에서 가장 자주 인용되는 결과입니다. 긴 컨텍스트 여러 위치에 정답 문서를 심어두고 모델이 얼마나 잘 찾아내는지 측정했더니, 정확도가 U자 곡선을 그렸습니다. 컨텍스트의 맨 앞과 맨 뒤에 있는 정보는 잘 찾는데, 한가운데 있는 정보는 회수율이 뚝 떨어졌어요. 심한 경우 중간에 정답을 넣었을 때의 성능이 아예 문서를 안 주고 물어봤을 때보다 낮게 나왔습니다.
모델이 문서 20개를 “다 읽는” 건 맞습니다. 다만 균등하게 주의를 주지 않을 뿐이에요. 사람이 두꺼운 보고서의 서론과 결론만 집중해서 읽고 본론은 눈으로만 훑는 것과 비슷한 패턴이 어텐션 가중치에도 나타나는 겁니다.
모델 발표 자료에 자주 나오는 “건초더미에서 바늘 찾기(needle in a haystack)” 테스트 점수는 이 문제를 가려버리기 쉽습니다. 이 테스트는 긴 텍스트에 문장 하나를 심고 그대로 찾아내게 하는 단순 회수 과제인데, 최신 모델들은 대부분 만점 가까이 받아요. 문제는 실전 작업이 단순 회수가 아니라는 점입니다. 여러 곳의 정보를 연결하고 추론해야 하는 과제로 바꾸면, 같은 모델도 컨텍스트가 길어질수록 점수가 미끄러집니다.
context rot, 길이 자체가 성능을 깎는다
2025년에는 벡터 DB 회사 Chroma가 이 현상에 “context rot”라는 이름을 붙인 기술 보고서를 냈습니다. 18개 주요 모델을 대상으로 입력 길이만 늘려가며 같은 과제를 시켰더니, 과제 난이도가 그대로여도 입력이 길어지는 것만으로 성능이 일관되게 하락했어요. 컨텍스트 윈도우 스펙 안쪽에서도요.
원인은 몇 겹으로 겹쳐 있습니다. 우선 어텐션의 구조적 한계입니다. 어텐션 가중치는 전체 합이 정해져 있는 예산 같은 것이라, 토큰이 많아질수록 토큰 하나에 돌아가는 몫이 옅어집니다. 관련 없는 내용이 많이 섞일수록 정작 중요한 신호가 묻히는 거죠. 다음은 학습 분포 문제입니다. 모델이 학습한 텍스트 대부분은 짧은 문서라, 수십만 토큰짜리 입력은 모델 입장에서 훈련 때 거의 본 적 없는 낯선 상황입니다. 스펙상 처리는 가능해도 그 길이에서의 추론 품질까지 보장되는 건 아니에요.
그래서 실무에서는 “실효 컨텍스트”라는 감각이 필요합니다. 스펙이 20만 토큰이어도 복잡한 추론 과제에서 품질이 유지되는 구간은 그보다 훨씬 짧다고 보는 게 안전합니다. 스펙 숫자는 “여기까지 넣어도 에러가 안 난다”는 뜻이지, “여기까지 넣어도 똑똑하다”는 뜻이 아닙니다.
에이전트의 컨텍스트는 그냥 긴 게 아니라 지저분하다
에이전트에서는 문제가 한 단계 더 심해집니다. 1편에서 봤듯 에이전트의 컨텍스트에는 도구 호출 결과가 쌓이는데, 이 축적물은 길기만 한 게 아니라 서로 모순되기 때문입니다.
전형적인 시나리오를 보죠. 에이전트가 버그를 잡으려고 파일을 읽고, 수정하고, 다시 읽습니다. 이제 컨텍스트에는 같은 파일의 수정 전 버전과 수정 후 버전이 나란히 들어 있어요. 실패했던 테스트 로그와 성공한 테스트 로그도 함께 있고요. 모델이 다음 판단을 할 때 이 중 어느 쪽을 참조할지는 보장되지 않습니다. 낡은 버전을 보고 “아직 버그가 있네요”라며 이미 끝난 수정을 다시 시작하는 행동이 여기서 나옵니다.
이런 실패 양상에는 이름도 붙어 있습니다. 잘못된 정보(예: 환각이 섞인 요약)가 컨텍스트에 들어가 이후 판단을 연쇄로 오염시키는 context poisoning, 쌓인 이력이 너무 길어 모델이 새 지시보다 과거 패턴 반복에 끌리는 context distraction, 비슷하지만 다른 정보가 섞여 혼선을 부르는 context confusion, 그리고 모순된 정보가 충돌하는 context clash. 이름은 몰라도 증상은 익숙하실 겁니다. 세션 후반의 에이전트가 유독 같은 실수를 반복하고, 하지 말라던 걸 하는 이유가 대부분 이 넷 중 하나예요.
품질 저하를 알아채는 신호
긴 세션에서 다음 신호가 보이면 컨텍스트 문제를 의심할 때입니다.
- 이미 해결한 문제를 다시 꺼내거나, 같은 파일을 반복해서 읽습니다
- 세션 초반에 정한 규칙(코딩 컨벤션, 건드리지 말 파일)을 어기기 시작합니다
- 답변이 장황해지고, 직전 질문이 아니라 한참 전 주제에 끌려갑니다
- 방금 알려준 정보를 무시하고 컨텍스트 어딘가의 낡은 정보로 답합니다
중요한 건 이게 모델이 “지쳐서”가 아니라는 점입니다. 모델은 매 턴 처음부터 다시 읽는 stateless 기계입니다. 달라진 건 모델이 아니라 읽어야 할 컨텍스트의 상태예요. 길고, 지저분하고, 모순된 컨텍스트가 입력으로 들어가니 출력 품질이 떨어지는 겁니다.
정리
- 컨텍스트에 들어간다고 잘 쓰이는 게 아닙니다. 중간 정보의 회수율이 떨어지는 lost in the middle, 길이 자체가 성능을 깎는 context rot 모두 연구로 확인된 현상입니다.
- 스펙 숫자는 상한이지 품질 보증이 아닙니다. 복잡한 추론이 필요한 작업일수록 실효 컨텍스트는 스펙보다 훨씬 짧다고 봐야 합니다.
- 에이전트의 컨텍스트는 도구 호출 잔해가 쌓여 모순까지 품습니다. poisoning·distraction·confusion·clash 네 가지 실패 양상이 세션 후반 품질 저하의 주범입니다.
진단이 끝났으니 다음 편부터는 처방입니다. 가장 기본 도구인 /clear와 /compact부터 시작합니다. 이 둘은 “컨텍스트를 비운다”는 점은 같지만 동작 원리가 완전히 다르고, 잘못 쓰면 오히려 작업 맥락을 날려버립니다. 언제 비우고 언제 압축해야 하는지 기준을 세워봅니다.