100만 토큰 컨텍스트가 곧 완벽한 기억력을 뜻하지는 않습니다. Lost in the Middle, RULER, Context Rot 연구를 바탕으로 LLM과 AI 코딩 에이전트의 성능을 지키는 컨텍스트 엔지니어링 방법을 정리합니다.
AI 코딩 에이전트와 몇 시간 동안 작업하다 보면 이상한 순간이 찾아옵니다.
처음에는 요구사항을 정확히 이해하던 에이전트가 갑자기 이미 고친 코드를 다시 건드리고, 앞에서 합의한 제약을 잊고, 존재하지 않는 파일이나 함수를 확신에 차서 언급합니다.
이때 흔히 드는 생각은 두 가지입니다.
“모델 성능이 갑자기 나빠졌나?”
“컨텍스트 창이 아직 남아 있는데 왜 기억하지 못하지?”
문제는 컨텍스트 창의 최대 크기와 모델이 실제로 안정적으로 활용하는 정보량이 같지 않다는 데 있습니다.
이번 글에서는 긴 컨텍스트가 왜 만능 기억장치가 아닌지, 그리고 Claude Code·Codex·Gemini CLI 같은 AI 에이전트를 더 안정적으로 사용하는 방법을 연구 결과와 실전 구조를 통해 정리합니다.
한 줄 결론
긴 대화 하나에 모든 정보를 쌓기보다, 짧은 작업 세션과 검증된 문서, 필요한 정보만 가져오는 검색 구조를 결합하는 편이 더 안정적입니다.
왜 지금 이 문제가 중요할까?
최근 LLM 서비스는 수십만에서 수백만 토큰의 컨텍스트 창을 강조합니다. 덕분에 긴 문서, 대규모 코드베이스, 여러 회의 기록을 한 번에 입력할 수 있게 되었습니다.
하지만 “입력할 수 있다”와 “정확하게 이해하고 끝까지 활용한다”는 서로 다른 능력입니다.
긴 컨텍스트에는 다음 문제가 함께 들어옵니다.
- 현재 작업과 무관한 파일
- 이전에 실패한 접근 방법
- 오래된 문서와 최신 문서의 충돌
- 비슷하지만 정답이 아닌 로그와 코드
- 반복되거나 서로 모순되는 지시
- 도구 실행 결과와 대화 기록의 누적
즉, 컨텍스트 창이 커질수록 정보만 늘어나는 것이 아니라 판단을 방해하는 신호도 함께 늘어납니다.
컨텍스트 창은 메모리가 아니라 작업대다
컨텍스트 창을 거대한 하드디스크처럼 생각하면 이해가 꼬이기 쉽습니다.
더 적절한 비유는 작업대입니다.
작업대가 넓으면 더 많은 도구와 문서를 펼쳐 놓을 수 있습니다. 그러나 책상 위에 관련 없는 자료가 수백 장 쌓이면 중요한 설계서 한 장을 찾고 비교하는 일은 오히려 어려워집니다.
LLM도 비슷합니다.
컨텍스트 창
├─ 시스템 지시
├─ 사용자 요청
├─ 이전 대화
├─ 검색된 문서
├─ 읽은 코드
├─ 터미널 출력
├─ 오류 로그
├─ 도구 실행 결과
└─ 모델이 앞에서 생성한 답변이 모든 항목은 같은 작업 공간을 공유합니다.
컨텍스트에 정보가 “존재한다”는 사실만으로 모델이 그 정보를 항상 올바르게 찾고, 우선순위를 판단하고, 여러 정보를 연결해 추론한다고 보장할 수는 없습니다.
연구가 보여주는 세 가지 문제
1. 중요한 정보가 중간에 있으면 놓칠 수 있다
2023년 발표된 Lost in the Middle 연구는 관련 정보가 긴 입력의 어디에 배치되는지에 따라 모델 성능이 크게 달라질 수 있음을 보여줬습니다.
많은 모델은 중요한 정보가 입력의 처음이나 끝에 있을 때 비교적 잘 활용했지만, 긴 문맥의 중간에 있을 때 성능이 낮아지는 경향을 보였습니다.
이 현상을 실무에 적용하면 다음과 같습니다.
처음: 핵심 요구사항
중간: 수많은 파일, 로그, 대화
끝: 최근 질문핵심 제약이 중간 어딘가에 묻히면, 모델은 해당 내용을 읽은 적이 있어도 실제 답변에서 제대로 반영하지 못할 수 있습니다.
2. 최대 컨텍스트 길이는 실제 유효 길이가 아니다
NVIDIA 연구진이 제안한 RULER 벤치마크는 단순히 문장 하나를 찾는 테스트를 넘어, 여러 단서 추적과 집계 같은 작업을 포함해 긴 컨텍스트 활용 능력을 평가했습니다.
연구 당시 32K 이상의 컨텍스트를 지원한다고 밝힌 모델들을 평가했지만, 입력 길이와 과제 복잡도가 증가하면서 많은 모델의 성능이 크게 하락했습니다.
중요한 점은 이것입니다.
제품 사양의 최대 토큰 수는 “요청을 받을 수 있는 한도”에 가깝고, 모든 작업에서 동일한 정확도를 유지하는 보증 수치가 아닙니다.
3. 문맥이 길어질수록 성능이 균일하게 유지되지 않는다
Chroma의 Context Rot 연구는 여러 최신 모델을 대상으로 입력 길이만 늘렸을 때도 성능이 점차 불안정해질 수 있음을 관찰했습니다.
특히 다음 조건이 영향을 주었습니다.
- 질문과 정답 문장의 표현이 정확히 일치하지 않을 때
- 정답과 비슷하지만 틀린 방해 정보가 있을 때
- 문서의 구조와 순서가 달라질 때
- 긴 내용을 복제하거나 여러 단서를 연결해야 할 때
현실의 코드베이스와 업무 문서는 단순한 “바늘 찾기”보다 훨씬 복잡합니다. 비슷한 함수, 오래된 문서, 실패 로그, 중복 설정이 함께 존재하기 때문입니다.
“100K 토큰부터 위험하다”는 절대 법칙일까?
아닙니다.
최근 Hacker News에서 화제가 된 글은 대략 100K 토큰 부근을 ‘똑똑한 구간’과 ‘성능이 흐려지는 구간’의 경계처럼 설명했지만, 이는 모든 모델과 모든 작업에 적용되는 과학적 상수가 아니라 작성자의 실전 경험에 가까운 기준입니다.
실제 유효 컨텍스트는 다음 요소에 따라 달라집니다.
- 사용하는 모델
- 추론 작업의 난이도
- 입력 자료의 중복도
- 방해 정보의 양
- 관련 정보의 위치
- 검색·재랭킹 방식
- 시스템 프롬프트와 프로젝트 지침의 품질
- 요구사항이 얼마나 명확하게 구조화되어 있는지
따라서 “몇 토큰까지 안전한가?”보다 다음 질문이 더 중요합니다.
현재 컨텍스트에서 필요한 정보와 불필요한 정보를 구분할 수 있는가?
컨텍스트가 오염됐을 때 나타나는 신호
다음 증상이 반복되면 단순한 프롬프트 수정 대신 세션을 정리할 시점입니다.
- 이미 해결한 문제를 다시 조사한다.
- 합의한 기술 스택이나 제약을 반복해서 어긴다.
- 수정하지 말라고 한 파일을 건드린다.
- 존재하지 않는 함수·파일·옵션을 언급한다.
- 같은 오류를 조금씩 다른 방식으로 반복한다.
- 테스트 결과보다 이전 추측을 더 강하게 믿는다.
- 요청 범위를 벗어나 대규모 리팩터링을 시작한다.
- 답변이 길어지지만 결정과 실행은 줄어든다.
이 상태에서 “앞의 지시를 다시 잘 읽어”라고 추가하면 새로운 지시도 기존 잡음 위에 더해집니다.
실전 해법: 컨텍스트 엔지니어링 7원칙
1. 큰 작업을 검증 가능한 단위로 나눈다
나쁜 요청:
이 저장소 전체를 분석하고 아키텍처를 개선한 다음,
검색 속도를 높이고 테스트와 문서까지 전부 작성해 줘.좋은 작업 분해:
1단계: 검색 요청이 처리되는 진입점과 호출 흐름만 조사
2단계: 병목 후보를 측정할 벤치마크 작성
3단계: 가장 영향이 큰 병목 하나만 수정
4단계: 수정 전후 결과 비교
5단계: 결정 사항과 남은 문제 문서화각 단계가 끝날 때 테스트와 산출물이 남아야 합니다.
2. 중요한 상태는 대화가 아니라 파일에 저장한다
대화 기록은 길어지고 요약 과정에서 손실될 수 있습니다. 반면 짧고 구조화된 파일은 새 세션에서도 다시 읽고 검증할 수 있습니다.
추천 구조:
docs/agent/
├── SPEC.md # 목표, 범위, 제약, 완료 조건
├── PLAN.md # 현재 작업 순서
├── DECISIONS.md # 선택한 방식과 선택 이유
├── STATUS.md # 완료·진행·대기 상태
└── VERIFY.md # 실행 명령어와 기대 결과각 파일은 길게 쓰기보다 “다음 세션이 바로 작업을 이어갈 수 있는가?”를 기준으로 작성합니다.
3. 전체 자료가 아니라 필요한 자료만 검색한다
대규모 코드베이스 전체를 프롬프트에 넣는 대신 다음 순서를 사용합니다.
질문 분석
↓
관련 모듈·문서 후보 검색
↓
재랭킹 또는 필터링
↓
상위 관련 조각만 컨텍스트에 포함
↓
답변 또는 코드 수정이 방식이 바로 RAG의 핵심입니다.
코딩 에이전트라면 파일명 검색만 사용하지 말고 다음 정보를 함께 활용하는 편이 좋습니다.
- 심볼과 참조 관계
- import·호출 그래프
- 최근 변경 파일
- 테스트와 구현 파일의 연결
- 오류 스택 트레이스
- 문서의 수정 시점과 상태
4. 지시는 짧고 우선순위가 명확해야 한다
프로젝트 지침 파일이 너무 길면 중요한 규칙이 평범한 설명 속에 묻힙니다.
좋은 지침은 다음 순서를 분명히 합니다.
1. 사용자 요청
2. 프로젝트 로컬 지침
3. 기존 코드와 테스트
4. 전역 기본 규칙그리고 “항상 완벽하게”, “가능한 모든 것을”, “최대한 자세히”처럼 범위를 무한히 넓히는 표현은 줄이는 편이 좋습니다.
5. 마일스톤이 끝나면 새 세션으로 넘긴다
한 세션에서 조사, 설계, 구현, 디버깅, 문서화까지 모두 이어가면 이전 시행착오가 계속 남습니다.
다음과 같은 시점에 세션 전환을 고려하세요.
- 조사와 설계가 끝났을 때
- 구현 단위 하나가 테스트를 통과했을 때
- 접근 방법이 크게 바뀌었을 때
- 잘못된 가정이 발견됐을 때
- 같은 오류를 두세 번 반복할 때
- 모델이 이미 확정한 제약을 계속 잊을 때
새 세션에는 전체 대화 대신 검증된 파일과 현재 작업만 전달합니다.
6. 자동 요약을 그대로 믿지 말고 검증한다
자동 압축과 요약은 유용하지만, 이미 성능이 떨어진 상태에서 생성된 요약에는 잘못된 가정이 남을 수 있습니다.
요약에는 최소한 다음 항목이 있어야 합니다.
## 목표
## 확정된 제약
## 완료된 작업
## 변경된 파일
## 실행한 검증
## 실패한 접근과 이유
## 다음 한 단계
## 확인되지 않은 가정특히 “무엇을 했는가”보다 “무엇이 실제 테스트로 확인됐는가”가 중요합니다.
7. 모델의 느낌이 아니라 평가 기준으로 확인한다
LLM은 그럴듯한 완료 보고를 만들 수 있습니다. 따라서 작업마다 기계적으로 확인할 수 있는 종료 조건을 둡니다.
예시:
- 단위 테스트 42개 통과
- ruff check 성공
- API 응답 P95 300ms 이하
- 검색 결과 Recall@10 기준선 이상
- 변경 파일이 지정된 디렉터리를 벗어나지 않음
- 문서의 실행 명령어를 새 환경에서 재현완료 조건이 명확할수록 모델이 긴 설명으로 실패를 감추기 어려워집니다.
권장 아키텍처
핵심은 활성 컨텍스트와 장기 상태를 분리하는 것입니다.
- 활성 컨텍스트: 지금 해결할 작업에 필요한 최소 정보
- 프로젝트 산출물: 목표, 결정, 상태, 검증 결과
- 검색 저장소: 코드, 문서, 메모리, 임베딩
- 검증 게이트: 테스트, 린트, 근거 확인
- 세션 전환: 검증된 상태만 다음 작업으로 전달
LLM이 모든 것을 기억하게 만들기보다, 필요한 순간에 정확한 정보를 공급하는 시스템을 만드는 편이 현실적입니다.
바로 사용할 수 있는 세션 인계 템플릿
아래 내용을 HANDOFF.md 또는 STATUS.md에 저장한 뒤 새 세션에서 읽게 하면 됩니다.
# 작업 인계
## 최종 목표
사용자가 얻어야 하는 결과를 한 문장으로 작성한다.
## 현재 범위
이번 세션에서 처리할 범위와 처리하지 않을 범위를 작성한다.
## 확정된 사실
- 코드와 실행 결과로 확인된 사실
- 사용자가 명시한 제약
- 변경하면 안 되는 항목
## 완료된 작업
- 변경 파일
- 핵심 변경 내용
- 관련 커밋 또는 이슈
## 검증 결과
- 실행 명령어:
- 실제 결과:
- 기대 결과와의 차이:
## 실패한 접근
- 시도한 방법:
- 실패 원인:
- 다시 시도하지 말아야 할 조건:
## 다음 작업
1. 다음에 수행할 한 단계
2. 완료 기준
3. 필요한 파일
## 미확인 사항
- 추측 또는 추가 확인이 필요한 내용새 세션 시작 프롬프트:
docs/agent/SPEC.md, DECISIONS.md, STATUS.md, VERIFY.md를 먼저 읽어라.
문서에 없는 사실은 추측하지 말고 코드와 테스트로 확인하라.
이번 작업은 STATUS.md의 '다음 작업' 한 항목만 수행한다.
완료 후 변경 파일, 검증 명령어, 실제 결과를 STATUS.md에 갱신하라.실전 예시: AI 코딩 에이전트가 오류를 반복할 때
상황:
- 에이전트가 이미 폐기한 라이브러리를 다시 사용한다.
- 같은 테스트 오류를 세 번째 수정 중이다.
- 대화가 매우 길어졌다.권장 대응:
1. 현재 변경사항과 테스트 결과를 STATUS.md에 기록
2. 잘못된 접근을 DECISIONS.md에 "폐기"로 기록
3. git diff와 테스트 실패 로그를 파일로 저장
4. 기존 세션 종료
5. 새 세션에서 관련 파일 4~6개만 읽기
6. 실패 원인 하나만 검증
7. 테스트 통과 후 다음 작업으로 이동반대로 피해야 할 대응:
- 앞의 모든 대화를 다시 읽으라고 요구
- 저장소 전체를 다시 분석하게 함
- 더 긴 프롬프트로 규칙을 반복
- 테스트 없이 "이번에는 확실히 고쳐"라고 요청자주 묻는 질문
Q1. 컨텍스트 창이 큰 모델은 필요 없다는 뜻인가?
아닙니다. 긴 문서 요약, 여러 파일 비교, 대규모 로그 조사처럼 큰 컨텍스트가 유용한 작업은 분명히 있습니다.
다만 최대 길이를 전부 채우는 것과 성능이 좋아지는 것은 같은 의미가 아닙니다. 큰 창은 여유 공간이지, 모든 정보를 넣어야 하는 목표치가 아닙니다.
Q2. RAG를 사용하면 컨텍스트 문제를 완전히 해결할 수 있나?
아닙니다. 검색 결과가 틀리거나 관련 문서가 누락되면 모델도 잘못된 답을 만들 수 있습니다.
RAG에는 검색 품질, 청크 구조, 메타데이터 필터, 재랭킹, 출처 표시, 평가 데이터가 함께 필요합니다.
Q3. 자동 압축 기능이 있으면 세션을 바꿀 필요가 없나?
자동 압축은 비용과 길이를 줄이는 데 도움을 주지만, 잘못된 내용까지 정확하게 걸러 준다고 보장할 수는 없습니다.
중요한 마일스톤에서는 사람이 확인한 상태 문서와 테스트 결과를 기준으로 새 세션을 시작하는 편이 안전합니다.
Q4. 가장 먼저 바꿔야 할 습관은 무엇인가?
에이전트에게 모든 것을 기억시키려 하지 말고, 결정과 상태를 짧은 파일로 남기는 습관부터 시작하세요.
이 한 가지 변화만으로도 세션 재시작, 모델 변경, 팀원 인계가 훨씬 쉬워집니다.
마무리
긴 컨텍스트 창은 강력한 기능입니다. 그러나 그것은 완벽한 기억장치가 아니라 넓은 작업 공간에 가깝습니다.
안정적인 AI 워크플로우는 다음 조합에서 나옵니다.
짧은 작업 단위
+ 필요한 정보만 검색
+ 검증된 문서로 상태 보존
+ 테스트 기반 완료 판정
+ 적절한 시점의 세션 전환모델에게 더 많이 보여주는 것보다 무엇을 보여주지 않을지 결정하는 능력이 중요해지고 있습니다.
AI를 잘 쓰는 사람은 가장 긴 프롬프트를 작성하는 사람이 아니라, 모델이 지금 판단하는 데 필요한 정보만 정확하게 공급하는 사람입니다.
참고 자료
- Don't trust large context windows — Garrit's Notes
- Hacker News 토론
- Lost in the Middle: How Language Models Use Long Contexts
- RULER: What's the Real Context Size of Your Long-Context Language Models?
- Context Rot: How Increasing Input Tokens Impacts LLM Performance
이 글은 2026년 6월 15일 공개 자료를 기준으로 작성했습니다. 모델과 도구의 동작은 업데이트에 따라 달라질 수 있으므로, 중요한 업무에서는 직접 평가와 검증을 병행하세요.
'AI & IT > 유용한 AI 지식들📚' 카테고리의 다른 글
| Agentic RAG란? 한 번 검색하고 끝나는 RAG에서 ‘부족하면 다시 찾는 AI’로 (0) | 2026.06.15 |
|---|
