긴 대화에서 답이 어긋나는 이유 | Context Window
AI의 작업 책상 Context Window의 구조와 짧게 유지해야 하는 이유, 모듈형 프롬프트 원칙을 이해합니다
Overview
매일 쓰는 명령 레슨에서 "대화가 길어지면 Claude의 응답 품질이 눈에 띄게 떨어진다"고 언급했습니다. 같은 모델에 같은 지시를 해도 세션이 길어질수록 처음 묻던 핵심에서 점점 멀어집니다. 왜 이런 일이 생길까요?
이 레슨에서는 그 원인인 Context Window가 무엇인지, 왜 짧게 유지할수록 결과가 좋은지, 이를 구조적으로 해결하는 모듈형 프롬프트 원칙을 설명합니다.
학습 목표
- Context Window가 무엇이고 무엇으로 구성되는지 설명합니다
- Context가 길어지면 품질이 떨어지는 두 가지 메커니즘을 구별합니다
- 모듈형 프롬프트의 핵심과 4가지 전략을 이해하고, Claude Code의 어떤 도구가 어떤 전략을 구현하는지 짚습니다
Context Window: AI의 작업 책상
프로젝트 자료를 펼쳐놓고 일하는 책상을 떠올려 보세요. 책상이 넓을수록 문서를 동시에 많이 볼 수 있지만 한계가 있습니다. 자료가 쌓일수록 처음에 올려둔 것은 구석으로 밀려 보기 어려워집니다.
Claude의 Context Window가 바로 이 책상입니다. 한 번의 응답을 만들 때 AI가 실제로 "보는" 정보의 전체 범위이고, 그 크기는 Token(토큰) 단위로 잽니다.
책상 위에 무엇이 올라가 있나
"내가 쓴 메시지만 Context를 차지한다"고 생각하기 쉽지만, 실제로는 보이지 않는 곳에서 이미 상당량이 소비됩니다.
- System Prompt: Claude의 기본 행동을 정의하는 지침
- 내장 도구 정의: 파일 읽기·쓰기·검색, bash 실행 등 Claude Code 도구의 사용 설명서
- MCP 도구 설명: 외부 서비스(Slack, Jira, GitHub 등) 연결 시 각 도구의 사용법
- CLAUDE.md: 프로젝트 규칙 파일
- 사용자 메시지: 대화창에 입력한 내용
- Claude의 응답: Claude가 생성한 답변과 도구 호출(tool_use) 요청
- 도구 응답: Claude의 요청으로 도구가 파일을 읽거나 명령을 실행해 돌려준 결과
MCP 란?
MCP(Model Context Protocol)는 외부 서비스를 Claude Code에 붙이는 플러그인 시스템입니다. Slack을 붙이면 Claude가 Slack 메시지를 읽을 수 있고, GitHub을 붙이면 이슈를 검색할 수 있는 식입니다. Part 2에서 자세히 다룹니다.
사용자 메시지는 이 요소들 중 하나일 뿐입니다. 위 요소들이 같은 Context Window를 함께 채우기 때문에, 새 메시지를 입력하기 전에도 책상의 일부는 이미 차 있습니다.
Context Rot: 길어질수록 떨어지는 품질
책상이 채워지는 구조를 봤습니다. 그러면 책상이 넓을수록 좋을까요? 그렇지 않습니다. AI의 주의력 총량은 고정되어 있습니다. 한 사람이 동시에 다룰 수 있는 서류 양이 정해져 있듯, LLM도 한 응답에 분배할 수 있는 처리 능력에 한계가 있습니다. 같은 주의력을 더 많은 토큰에 나눠 쓰면 토큰당 주의력이 줄어듭니다. 토큰이 쌓일수록 응답 품질이 떨어지는 이 현상을 업계에서는 Context Rot이라 부릅니다. 근본 원인은 고정된 주의력, 곧 Attention Budget(주의력 예산)입니다. Context Rot은 두 가지 모습으로 드러납니다.
Context Rot 이란?
Rot은 음식이 상하듯 '오래 묵으면 못 쓰게 된다'는 뜻입니다. Context Window에 토큰이 길게 쌓일수록 응답 품질이 상한다고 해서 붙은 이름입니다.
Smart Zone·Dumb Zone: 위치 편향
한 시간짜리 회의를 들어본 기억을 떠올려 보세요. 도입부 5분에 나왔던 안건과 마지막에 정리한 결론은 또렷한데, 중간 30분 즈음에 오갔던 세부 논의는 흐릿합니다. 회의록을 다시 봐도 "이건 언제 얘기됐지?" 싶은 대목이 꼭 하나씩 있습니다.
LLM도 같은 경향을 보입니다. Context의 초반부에서 주의력이 가장 높고 후반부도 상대적으로 잘 처리되지만, 중간 구간의 정보는 놓치는 경향이 강합니다. 업계에서는 이를 Lost in the Middle이라 부릅니다.
AI 입장에서 Context는 Smart Zone(초반·후반 부근)과 Dumb Zone(중간)으로 나뉜다고 생각하면 됩니다. 중요한 지시를 Context 한가운데 묻어두면 놓치기 쉽습니다.
지침이 많을수록 떨어지는 준수율
회의에서 상사가 업무 지시를 한다고 상상해 보세요. 3가지를 말하면 다 기억합니다. 10가지를 말하면 8~9개 정도 기억합니다. 20가지를 한꺼번에 쏟아내면 전체적으로 빠뜨리는 것이 생기기 시작합니다.
LLM도 같은 경향을 보입니다. 지침이 많아질수록 개별 지침의 준수율이 점진적으로 떨어집니다. 20개 지침도 대부분 따르지만, 충돌하는 규칙이나 맥락에서 먼 지침부터 빠지기 시작합니다.
해법: 모듈형 프롬프트로 지금 필요한 것만
두 현상의 근본 원인은 같습니다. 고정된 주의력을 더 많은 대상에 나누면 각각이 받는 주의력이 줄어듭니다. 양이 아니라 구조의 문제입니다. 더 자세히 알려주는 게 아니라 지침의 구조를 개선하는 것이 해법입니다.
Context는 양이 아니라 질이 좌우합니다. 정확히 관련된 5,000 토큰이 "혹시 필요할까봐" 끌어모은 20,000 토큰보다 더 나은 답을 만듭니다. 모듈형 프롬프트는 이 원칙을 구조로 구현한 방식입니다.
네 가지 전략이 있습니다.
- 조건부 전달: 전체 스펙이 아니라 지금 작업하는 영역의 스펙만 제공
- 요약본 활용: 전체 문서 대신 목차만 갖고 다니다가, 필요한 부분만 불러오기
- 서브에이전트 위임: 조사를 별도 Context Window에서 실행하고 메인에는 요약만 반환
- 작업별 컨텍스트 갱신: 작업이 바뀌면 이전 컨텍스트를 정리하고 새 작업에 필요한 내용만 전달
Claude Code가 구현하는 도구들
Claude Code에는 이 네 전략이 각각 다른 도구로 구현되어 있습니다.
| 전략 | 도구 | 로드 시점 | 역할 |
|---|---|---|---|
| 조건부 전달 | Rules | 특정 파일 경로 작업 시 | 조건부 컨텍스트 |
| 요약본 활용 | Skills | /skill 호출 시에만 | 지연 로드 (~30 토큰 요약만 존재) |
| 서브에이전트 위임 | Sub-agents | 위임 시 별도 Context Window | 메인 컨텍스트 오염 방지 |
| 작업별 갱신 | CLAUDE.md | 매 대화 시작 시 자동 | 상시 필요한 핵심 규칙 |
구체적인 사용법은 Part 2에서 실습합니다.
핵심 포인트 정리
- Context Window = AI의 작업 책상: 사용자 메시지는 요소 하나일 뿐이고, System Prompt·도구 정의·MCP·CLAUDE.md·도구 응답이 보이지 않는 곳에서 책상을 채웁니다
- Context Rot: 길어질수록 품질이 상하는 Context Rot은 위치 편향(Lost in the Middle)으로 중간 정보를 놓치고, 지침이 많을수록 각 규칙의 준수율이 떨어집니다. 원인은 고정된 주의력 예산(Attention Budget)이고, 양이 아니라 구조의 문제입니다
- 모듈형 프롬프트: 전체 자료를 한 번에 넣기보다, 지금 작업과 직접 관련된 정보만 Context에 남깁니다. Claude Code의 Rules·Skills·Sub-agents·CLAUDE.md가 각각 하나의 전략을 구현합니다
FAQ
이어서 배울 내용
지금 작업에 필요한 Context만 골라 주는 것이 품질을 좌우한다는 점을 확인했습니다. 하지만 또 다른 문제가 남습니다. AI는 매 대화를 백지에서 시작합니다. 프로젝트가 뭐 하는 곳인지, 어떤 기술 스택을 쓰는지, 빌드 명령어가 뭔지 매번 처음부터 설명하는 것도 Context 낭비입니다.
CLAUDE.md가 이 문제를 해결합니다. 프로젝트 핵심 정보를 한 번만 정리해두면 매 대화 시작 시 자동으로 로드됩니다. 반복 설명을 없애면서도 AI가 프로젝트를 이해한 상태에서 대화를 시작할 수 있습니다.
- CLAUDE.md: 프로젝트 규칙을 한 번 작성하고 매번 자동 제공
- 잘 쓴 CLAUDE.md의 원칙