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