“컨텍스트 윈도우 200K 토큰”이라는 스펙만 보면 웬만한 코드베이스는 통째로 넣어도 될 것 같습니다. 그런데 막상 다 넣으면 응답 품질이 뚝 떨어져요.
모델이 긴 컨텍스트에서 중간 내용을 놓치는 현상은 여러 연구로 확인돼 있습니다. 넣을 수 있다는 것과 잘 쓴다는 것은 다른 문제인 거죠.
그래서 나온 개념이 컨텍스트 엔지니어링입니다. 한 문장으로 정리하면, 유한한 컨텍스트 윈도우를 예산처럼 취급해 매 순간 가장 유효한 정보만 올려두는 설계 기법이에요.
이 글에서는 왜 컨텍스트가 예산인지, 예산을 아끼는 네 가지 전략, 그리고 CLAUDE.md 같은 상시 로드 파일의 설계 기준까지 정리합니다.
핵심 요약부터 보고 갈게요.
- 컨텍스트는 클수록 좋은 게 아니라, 관련성이 높을수록 좋습니다
- 전략은 크게 넷입니다. 선별 로딩, 요약(압축), 격리, 외부화(메모리)
- 상시 로드 파일(CLAUDE.md 등)은 “항상 참인 것”만 담아 짧게 유지합니다
- 도구·지시서도 컨텍스트 소비자입니다. 등록만 해두고 안 쓰는 도구는 비용입니다
왜 예산인가, 컨텍스트의 비용 구조
컨텍스트 윈도우에는 세 가지 비용이 동시에 걸립니다.
첫째, 성능 비용. 관련 없는 내용이 많을수록 모델의 주의가 분산됩니다. 특히 긴 컨텍스트의 중간 부분은 회수율이 떨어진다는 “lost in the middle” 현상이 알려져 있어요.
둘째, 금전 비용. 입력 토큰은 매 요청마다 과금됩니다. 대화가 길어질수록 같은 내용이 반복 과금되고요.
셋째, 기회 비용. 잡동사니가 차지한 자리만큼 정작 필요한 코드와 문서가 들어갈 공간이 사라집니다.
컨텍스트 엔지니어링의 관점 전환은 이겁니다. “얼마나 넣을 수 있나”가 아니라 “이 토큰이 지금 여기 있을 자격이 있나”를 묻는 것.
전략 1·2, 선별 로딩과 요약
선별 로딩(retrieval)은 필요할 때 필요한 것만 가져오는 전략입니다. 파일 2,000줄을 다 읽는 대신 관련 함수만 읽고, 문서 전체 대신 검색으로 해당 절만 가져오는 식이에요.
Skill의 점진적 로딩(평소엔 한 줄 설명만, 실행 시에만 본문 로드)도 같은 원리입니다.
요약(compaction)은 쌓인 히스토리를 압축합니다. 수십 번의 도구 호출 기록을 “이 파일들을 수정했고 테스트는 통과했다” 한 문단으로 접는 거죠.
코딩 에이전트들이 대화가 길어지면 자동으로 수행하는 그 압축입니다.
요약에는 손실이 따른다는 점만 기억해 두세요. 세부 사항이 접히면서 사라질 수 있어서 중요한 결정 사항은 요약 전에 파일로 빼두는 게 안전합니다.
전략 3·4, 격리와 외부화
격리(isolation)는 컨텍스트를 어지럽히는 작업을 별도 세션으로 떼어내는 전략입니다. 대규모 탐색을 서브에이전트에게 시키면, 파일 덤프는 그쪽 컨텍스트에서 소비되고 본진에는 결론 몇 줄만 돌아옵니다.
본진의 예산을 지키는 가장 확실한 방법이에요.
외부화(memory)는 컨텍스트 밖 저장소를 씁니다. 세션이 끝나면 컨텍스트는 증발하지만, 파일로 적어둔 것은 남죠.
작업 상태를 마크다운으로 기록해 두고 다음 세션이 이어받는 패턴이 대표적입니다. 프로젝트 지식을 CLAUDE.md와 메모리 파일로 축적하는 패턴도 여기 해당하고요.
| 전략 | 한 줄 요약 | 대표 사례 |
|---|---|---|
| 선별 로딩 | 필요할 때만 가져온다 | 부분 읽기, Skill 점진 로딩 |
| 요약 | 히스토리를 접는다 | 자동 컴팩션 |
| 격리 | 다른 세션에 시킨다 | 서브에이전트 |
| 외부화 | 파일에 적어둔다 | 메모리 파일, 상태 문서 |
상시 로드 파일의 설계 기준
CLAUDE.md 같은 파일은 매 세션 예산에서 선공제되는 고정비입니다. 그래서 기준이 명확해야 해요.
담을 것은 “항상 참이고, 어기면 안 되는 것”입니다. 코딩 컨벤션, 금지 사항, 빌드 명령어 같은 것들이요.
빼야 할 것은 “가끔만 필요한 것”입니다. 특정 작업의 상세 절차는 Skill로, 과거 작업 기록은 메모리 파일로 내리는 게 맞습니다.
도구 등록도 같은 논리가 적용됩니다. MCP(Model Context Protocol) 서버를 붙일수록 도구 정의가 고정비로 쌓입니다.
안 쓰는 서버 열 개는 그 자체로 성능 저하 요인이에요. 정기적으로 정리할 가치가 있습니다.
마무리
컨텍스트 엔지니어링은 결국 관련성 관리입니다. 큰 창이 생겼다고 다 채우는 게 아니라, 매 순간 모델의 책상 위에 지금 작업과 관련된 것만 올려두는 일이죠.
하네스 엔지니어링 편에서 다룬 실행 루프와 이 글의 예산 관리가 합쳐지면, 에이전트 설계의 큰 그림이 완성됩니다. 다음 글에서는 이를 실제로 조립한 파이프라인 사례를 다루겠습니다.