컨텍스트 윈도우는 모델이 한 번에 입력으로 받을 수 있는 토큰의 총량입니다. “200K”면 최대 20만 토큰까지 넣을 수 있다는 뜻입니다. 그런데 넣을 수 있는 양과 모델이 제대로 활용하는 양은 다릅니다. Chroma가 모델 18종을 대상으로 측정한 결과, 예외 없이 전부 입력이 길어질수록 성능이 떨어졌습니다. 당시 최신 모델인 GPT-4.1·Claude 4·Gemini 2.5·Qwen3뿐 아니라 GPT-3.5 Turbo 같은 구형 모델도 포함했습니다. 한도가 가득 차기 훨씬 전부터입니다.
2026년에 “컨텍스트 엔지니어링”이 화두가 된 이유는 컨텍스트 윈도우가 커져서가 아니라, 커진 만큼 다 쓰면 안 된다는 게 측정으로 확인됐기 때문입니다. 기술의 방향이 “더 많이 넣기”에서 “무엇을 넣지 않을지 고르기”로 뒤집혔습니다.
입력 토큰이 늘어날수록 출력 품질이 떨어지는 현상입니다. 이름은 Chroma의 2025년 7월 기술 보고서에서 굳었습니다. 먼저 밝혀둘 것 — Chroma는 벡터 데이터베이스를 파는 회사이고, 이 주제에 사업상 이해관계가 있습니다. 이 글에서 가장 많이 인용하는 자료이므로 감안하고 읽어 주세요. 보고서가 모델 목록과 실험 설계를 공개하고 있다는 점은 검증 가능성 쪽에 무게를 실어 줍니다.
흔한 오해부터 걷어내겠습니다. 이건 입력이 한도를 넘겨 잘리는 문제가 아닙니다. 한도 안에서, 여유가 남아 있는 상태에서 일어납니다. 모델이 “읽을 수는 있는” 구간과 “제대로 쓸 수 있는” 구간이 다르다는 뜻입니다.
컨텍스트 윈도우의 크기는 입력이 거부당하지 않는 한도이지, 품질이 유지되는 한도가 아닙니다. 두 값은 다릅니다.
Chroma의 지적은 기존 장문 벤치마크가 실제 사용 환경을 충분히 반영하지 못한다는 것입니다. 통과 여부보다 어떤 조건에서 측정했는지가 중요합니다.
18개 모델 중 모든 과제에서 일관되게 강한 모델은 없었습니다. 성능은 과제 의존적입니다.
Chroma(Kelly Hong · Anton Troynikov · Jeff Huber, 2025-07-14)는 Anthropic·OpenAI·Google·Alibaba의 모델 18종을 세 갈래 과제로 테스트했습니다. 앞서 밝힌 대로 Chroma는 이 영역에 상용 이해관계가 있는 회사입니다.
| 과제 | 설계 | 무엇을 보는가 |
|---|---|---|
| 건초더미 속 바늘 찾기 Needle in a Haystack, 이하 NIAH |
입력 길이 8종 × 바늘 위치 11종 | 어휘가 그대로 겹칠 때와 의미만 통할 때의 차이 |
| LongMemEval | 정제된 대화형 QA 프롬프트 306개, 평균 약 113K 토큰 | 필요한 부분만 준 경우 vs 전체를 준 경우의 격차 |
| Repeated Words | 단어쌍 7종. 각 쌍마다 25~10,000 단어 구간의 변형 1,090개 | 내용 이해가 아니라 그대로 복제하는 능력 |
길이만의 함수가 아니라는 게 이 연구의 핵심입니다. 같은 길이여도 조건이 나쁘면 더 나빠집니다.
질문과 정답 문장의 의미가 얼마나 가까운지를 나타내는 값(임베딩 코사인 유사도)이 낮을수록 성능이 떨어졌습니다. 실험에서 유사도 범위는 소재에 따라 0.445~0.775(에세이), 0.521~0.829(arXiv)였습니다.
실무 함의: 질문과 정답이 의미적으로 멀수록 불리합니다. 단어가 겹치느냐 아니냐와는 다른 축입니다.
비슷하지만 답이 아닌 정보가 하나만 있어도 성능이 떨어졌고, 넷이면 더 떨어졌습니다.
실무 번역: “일단 관련돼 보이면 다 넣자”가 정확히 이 조건을 만듭니다.
모델 계열별로 실패하는 방식도 갈렸습니다. 다만 아래 셋은 서로 다른 실험에서 나온 결과이므로 하나의 경향으로 묶어 읽으면 안 됩니다.
직관과 반대입니다. 잘 구성된 문서를 주면 모델이 더 잘 이해할 것 같지만, 측정 결과는 그 반대였습니다.
다만 여기서 “문서를 뒤섞어 넣으라”는 결론을 끌어내면 안 됩니다. 이건 통제된 실험 조건에서 관찰된 현상이고, 원인이 무엇인지까지 확립된 건 아닙니다. 실무에서 가져갈 함의는 이 정도입니다 — “맥락을 풍부하게 주면 더 잘할 것”이라는 가정이 측정으로 뒷받침되지 않는다. 문서를 통째로 넣는 선택을 “친절해서 좋다”고 정당화할 수는 없습니다.
2026년 5월 12일 공개된 별개의 프리프린트(Sam Martin · Fabien Roger)가 같은 문제를 에이전트 운영의 급소에서 다룹니다. Chroma 연구와 저자도 과제도 다른 독립 연구입니다. 대상은 코딩 에이전트의 실행 기록을 LLM으로 감시하는 구성입니다.
Opus 4.6, GPT 5.4, Gemini 3.1을 분류 모델로 써서, 50만 토큰이 넘는 기록에서 위험한 행위를 찾게 했습니다. 결과는 이렇습니다.
논문의 결론 문장이 특히 뼈아픕니다 — 장문 컨텍스트 저하를 고려하지 않은 감시자 평가는 감시 성능을 과대평가하고 있을 가능성이 높다.
논문이 시험한 완화책은 기록 중간중간 주기적으로 상기시키기, 그리고 사후 학습 개선입니다. 전자는 오늘 적용 가능하고, 후자는 모델 제공자의 몫입니다.
이 연구는 arXiv 프리프린트이며 동료 심사를 거치지 않았습니다.
Anthropic이 공개한 대응은 세 가지입니다. 공통 전제는 컨텍스트를 유한한 예산으로 다루는 것입니다.
한도에 가까워진 대화를 요약해서 새 컨텍스트로 다시 시작합니다. 요령은 무엇을 남기고 무엇을 버릴지 고르는 데 있습니다.
Anthropic의 튜닝 순서: 먼저 재현율을 최대화해 빠뜨리는 게 없게 만들고, 그 다음 불필요한 내용을 덜어내며 정밀도를 올립니다.
NOTES.md, TODO.txt 같은 컨텍스트 바깥의 파일에 기억을 두고 필요할 때 다시 읽습니다.
계속 들고 있지 않아도 되는 것을 컨텍스트 밖으로 빼는 것이 요점입니다. 넣을 자리는 유한하고, 채울수록 나빠지니까요.
작업을 나눠 각자 깨끗한 컨텍스트에서 깊게 파고, 상위 에이전트에는 압축된 요약만 돌려줍니다.
탐색 과정의 잡음이 상위 에이전트의 컨텍스트를 오염시키지 않는 구조입니다.
여기서부터는 측정 결과가 아니라 거기서 끌어낸 실무 판단입니다. 내용을 둘로 나눠 적었습니다. 하나는 연구가 실제로 시험한 것이고, 다른 하나는 그 결과에서 제가 추론한 실무 가설입니다. 후자는 가설이고, 여러분의 환경에서 검증하셔야 합니다.
| 실무 행동 | 근거가 되는 측정 |
|---|---|
| 입력 길이를 성능 변수로 다룬다. 한도에 여유가 남았다고 안전하다고 보지 않는다 | 18종 전부에서 길이에 따른 저하가 관측됨 (Chroma) |
| LLM에게 긴 기록의 1차 검토를 맡기지 않는다 | 80만 토큰의 정상 활동 뒤 위험 행위 누락이 2×~30× 증가 (Martin·Roger). 단, “기계적 필터로 먼저 좁히면 나아진다”는 이 논문이 시험한 완화책이 아닙니다 — 아래 7.2 참조 |
| 긴 감시·검토 파이프라인이 있다면 중간에 지시를 다시 상기시킨다 | 같은 논문이 시험한 완화책 중 하나 |
| 모델 계열의 실패 방식에 맞춰 폴백을 설계한다 (기권형은 재시도, 환각형은 검증) | NIAH 방해 정보 실험의 계열별 환각률 차이, LongMemEval의 보수적 기권 (Chroma) |
| compaction·구조화된 메모·서브에이전트를 쓴다. compaction 프롬프트는 재현율을 먼저 맞춘다 | Anthropic의 공식 엔지니어링 가이드 |
| 습관 | 가설 | 대신 해볼 것 |
|---|---|---|
| 한 세션을 하루 종일 이어서 씀 | 토큰이 쌓일수록 초반 지시가 실질적으로 희석될 것이다. 단, 세션 재시작 효과를 직접 측정한 연구는 없습니다 | 작업 단위로 끊고 남길 것을 명시적으로 골라 새로 시작 |
| “관련될 것 같은” 파일을 에이전트에게 모두 읽힘 | 유사하지만 답이 아닌 파일이 distractor처럼 작동할 것이다. 실험의 distractor는 인위적으로 구성된 것입니다 | 필요한 범위만. 넓게 훑어야 하면 서브에이전트에 맡기고 요약만 받기 |
| 문서를 통째로 붙여넣음 | 길이는 늘고 정답 밀도는 떨어질 것이다. “논리적 일관성이 오히려 불리하다”는 결과를 일반 문서로 확장할 근거는 없습니다 | 해당 절만 넣기 |
| 긴 로그를 통째로 넘기고 “문제 찾아줘” | 입력을 짧게 만드는 어떤 방법이든 도움이 될 것이다. 논문이 시험한 완화책은 “주기적 상기”와 “사후 학습 개선”이지 기계적 사전 필터링이 아닙니다 | grep·날짜 범위 등으로 먼저 좁힌 뒤 넘기고, 효과를 직접 재보기 |
| 사용자 표현 그대로 검색·질의 | 질문과 정답의 의미 거리가 멀면 불리하므로, 질의를 문서 용어에 가깝게 다듬으면 나아질 것이다. 질의 재작성 자체는 시험되지 않았습니다 | 질의 재작성을 A/B로 직접 측정해 보기 |
아래는 Redis가 2026년에 발표한 IT·AI 인프라 담당자 대상 설문입니다. 벤더가 발표한 조사이고, 표본 크기와 표집 방법이 공개돼 있지 않습니다. Redis는 이 영역에 상용 이해관계가 있습니다. 모집단 추정치가 아니라 업계 분위기의 방향으로만 읽으시는 게 맞습니다.
| 응답 | 비율 |
|---|---|
| “에이전트는 모델이 망가져서보다 컨텍스트가 망가져서 더 자주 실패한다”에 동의 | 73% |
| 에이전트가 시스템 간 관계를 신뢰성 있게 다루지 못한다고 응답 | 69% |
| 임시방편·탐색 단계(Stage 1~2)에 머물러 있음 | 81% |
| 축적되는 컨텍스트 체계를 구축했다고 응답 | 4% |
이 수치를 증거로 쓸 수는 없습니다. 다만 앞 절들의 측정 결과와 방향이 어긋나지 않는다는 점 정도는 말할 수 있습니다.
CLAUDE.md, NOTES.md)| 자료 | 내용 | 링크 |
|---|---|---|
| Chroma — Context Rot (2025-07-14) Kelly Hong · Anton Troynikov · Jeff Huber. 1차 연구, 단 벤더 발표 |
18개 모델, 3개 과제군, 조건별 저하 폭, haystack 구조 결과 | trychroma.com |
| Classifier Context Rot (2026-05-12) Sam Martin · Fabien Roger. arXiv 프리프린트, 동료 심사 없음 |
코딩 에이전트 감시에서의 장문 저하, 2×~30× 누락 증가 | arxiv.org/abs/2605.12366 |
| Anthropic — Effective context engineering for AI agents 1차 자료. 모델 제공자의 공식 엔지니어링 가이드 |
compaction, 구조화된 메모, 서브에이전트 구조와 튜닝 순서 | anthropic.com |
| Redis — State of Context Engineering 2026 벤더 설문. 표본 크기·표집 방법 미공개 |
업계 분위기. 근거로는 쓰지 않았습니다 | redis.io |
이 문서는 2026-09-06 기준 공개 자료를 정리한 기술 요약입니다. 모델 세대가 바뀌면 수치는 달라집니다. 운영에 적용하기 전에 각 자료의 실험 조건이 여러분의 사용 환경과 맞는지 확인하세요.