몇 년 사이 컨텍스트 윈도우는 8k에서 1M으로 불었다. 군비경쟁은 사실상 끝났고, 이제 웬만한 프런티어 모델은 책 한 권을 통째로 삼킨다. 그러면 컨텍스트 고민은 끝났어야 한다. 다 넣으면 되니까.
그런데 현장에서 벌어진 건 정반대다. 더 넣을 수 있게 되자, 오히려 ‘덜 넣는’ 기술이 중요해졌다. 직관과 어긋나는 이 지점이 컨텍스트 엔지니어링의 출발점이다.
”길수록 좋다”는 직관의 배신
윈도우가 1M이라고 1M을 채우라는 뜻이 아니다. 컨텍스트가 길어질수록 모델이 그 안에서 정확히 필요한 정보를 집어내는 능력은 오히려 떨어진다. 특히 중간에 묻힌 정보일수록 잘 못 찾는다(lost in the middle). “혹시 모르니 다 넣자”는 정확도를 깎으면서 비용과 지연만 키운다.
이걸 context rot라고 부른다. 윈도우 용량은 상한이지 목표가 아니다. 들어갈 수 있다는 것과 들어가야 한다는 건 다른 얘기다.
무게중심이 프롬프트에서 컨텍스트로
그래서 잘하는 일의 성격이 바뀌었다. 프롬프트 엔지니어링은 “한 번의 질문을 어떻게 다듬나”였다. 컨텍스트 엔지니어링은 윈도우에 들어가는 전체를 설계하는 일이다 — 지시문만이 아니라 검색 결과, 도구 출력, 대화 이력, 메모리까지 다.
핵심 질문도 달라졌다. “어떻게 물을까”가 아니라 “무엇을 넣고, 무엇을 빼고, 언제 비울까”. 좋은 프롬프트 한 줄보다, 관련 있는 것만 정확히 담고 나머지를 덜어낸 윈도우가 결과를 가른다. 에이전트 시대엔 무엇을 넣느냐가 어떻게 묻느냐를 압도한다.
가장 ROI 높은 한 수 — commands
그 윈도우를 설계하는 첫 자리가 에이전트에게 주는 상비 컨텍스트, CLAUDE.md나 AGENTS.md 같은 파일이다. 지난 글에서 본 OKF·llms.txt의 흐름과 같은 패턴 — 평범한 마크다운을 모델의 맥락으로 쓰는 것.
구조는 개요 → 아키텍처 → 컨벤션 → 테스트 → 명령어 → 안티패턴 순이 잘 먹힌다. 이 중 Anthropic이 “가장 ROI 높은 항목”으로 꼽는 건 의외로 명령어(commands) 다. 빌드·테스트·린트 명령을 그대로 적어두면, 모델이 매번 추측하던 걸 알아서 돌리며 자기 코드를 검증하는 루프를 만든다. 거창한 설명보다 이 한 섹션이 먼저다.
반대로 가장 흔한 안티패턴은 3,000줄짜리 monolithic 파일이다. 다 적을수록 좋겠지 싶지만, 정작 중요한 지시가 묻히고 매 요청마다 토큰을 태운다.
윈도우가 넘칠 때 — 끝난 건 압축, 다 쓴 건 비우기
긴 작업·긴 대화에선 윈도우가 결국 찬다. 관리법은 세 가지로 정리된다. 지나간 대화는 핵심만 요약으로 갈아끼우고(compaction), 한 번 쓰고 결론을 뽑아낸 도구 출력은 비우고(tool-result clearing), 매번 들고 다닐 필요 없는 사실은 윈도우 바깥에 두고 필요할 때만 꺼낸다(memory).
공통 원리는 하나다 — 윈도우는 “지금 이 순간 필요한 것”만 담는 작업대다. 끝난 것은 압축하고, 다 쓴 것은 비우고, 나중 것은 밖에 둔다. 이건 신뢰할 수 있는 RAG가 “충분한 컨텍스트인지 판단하고 모르면 기권”하는 것과 같은 정신이다. 더 넣는 게 답이 아니다.
이 주제를 실전 체크리스트로 한 장에 정리한 컨텍스트 엔지니어링 가이드를 따로 만들어 뒀다 — CLAUDE.md 구조부터 세 가지 관리 전략, 안티패턴까지.