프롬프트를 잘 쓰는 것에서, 컨텍스트 윈도우를 설계하는 것으로
모델에게 무엇을 넣을지가 무엇을 묻는지보다 중요해졌다
프롬프트 엔지니어링의 다음 단계 — 한 번의 질문이 아니라 모델이 보는 전체를 설계한다
| 관점 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |
|---|---|---|
| 대상 | 한 번의 질문(prompt)을 다듬는 것 | 윈도우에 들어가는 전체를 설계하는 것 |
| 범위 | 지시문·예시·역할 | 지시문 + 검색 결과 + 도구 출력 + 대화 이력 + 메모리 |
| 핵심 질문 | "어떻게 물을까" | "무엇을 넣고, 무엇을 빼고, 언제 비울까" |
| 주된 적 | 모호한 지시 | 과잉 컨텍스트 · context rot |
토큰을 더 넣을수록 정보 회수 정확도가 떨어지는 현상
컨텍스트가 길어질수록 모델이 그 안에서 정확히 필요한 정보를 찾아내는 능력은 떨어진다. 중간에 묻힌 정보일수록 더 그렇다(lost in the middle). "혹시 모르니 다 넣자"는 정확도를 깎고 비용·지연만 키운다. 윈도우 용량은 상한이지 목표가 아니다.
답에 꼭 필요한 정보를 충분히 담되, 그 이상은 덜어낸다. 중요한 지시는 윈도우의 앞이나 끝처럼 모델이 주목하는 위치에 둔다. 신뢰할 수 있는 RAG가 "충분한 컨텍스트인지 판단하고 모르면 기권"하는 것과 같은 원리다.
에이전트에게 주는 프로젝트 상비 컨텍스트 — 구조가 곧 품질이다
CLAUDE.md), 역할은 같다 — "이 프로젝트를 처음 보는 동료에게 건네는 한 장의 안내서"다.
모델이 가장 먼저 맥락을 잡게 한다. 목적·도메인·주요 사용자. 길 필요 없다.
"어디에 무엇이 있는가"를 알려주면 모델이 엉뚱한 파일을 뒤지지 않는다. 전체 트리가 아니라 핵심 경로만.
"주변 코드처럼 써라"를 명문화한다. 모델이 팀의 관습을 추측하지 않게 한다.
모델이 자기 코드를 스스로 검증하게 하는 출발점. 테스트 프레임워크·실행 범위·기대치를 적는다.
가장 ROI 높은 항목이다(Anthropic). 모델이 매번 추측하던 명령을 그대로 적어두면, 빌드·테스트·린트를 알아서 돌리며 자가 검증 루프를 만든다. 여기를 가장 먼저 채워라.
모델이 자주 저지르는 실수("이 라이브러리 쓰지 마", "이 디렉터리 건드리지 마")를 명시한다. 사후 교정보다 사전 차단이 싸다.
긴 작업·긴 대화에서 윈도우를 깨끗하게 유지하는 법
대화가 길어지면 오래된 턴을 그대로 두지 말고 핵심만 요약해 치환한다. "지금까지 무엇을 결정했고 어디까지 했는가"를 압축본으로 유지하면, 원문 수천 토큰을 수백 토큰으로 줄이면서 맥락은 보존한다. 긴 에이전트 세션의 기본기다.
검색 결과·파일 덤프·로그처럼 한 번 쓰고 나면 필요 없어지는 도구 출력이 윈도우를 잡아먹는 주범이다. 이미 결론을 뽑아냈다면 원본 출력은 비우고 요약만 남긴다. 가장 빠르게 토큰을 회수하는 방법이다.
매번 다 들고 다닐 필요가 없는 사실·결정·선호는 윈도우 바깥의 저장소(파일·DB·메모리 도구)에 두고, 필요할 때만 검색해 끌어온다. 윈도우는 작업 공간, 메모리는 서랍이다. 긴 호흡의 작업일수록 이 분리가 중요해진다.
컨텍스트를 망치는 가장 흔한 방법들
"많이 적을수록 좋겠지"하며 모든 걸 한 파일에 욱여넣는다. 정작 중요한 지시가 묻히고, 매 요청마다 토큰을 태운다.
관련 있을지 모를 문서를 전부 컨텍스트에 붙인다. context rot로 정확도가 떨어지고 비용만 는다.
가장 ROI 높은 항목을 안 적는다. 모델이 빌드·테스트 명령을 매번 추측하다 틀린다.
한 번 쓴 검색 결과·파일 덤프를 비우지 않아 윈도우가 점점 막힌다.
모델이 읽는다는 걸 잊고, 장식·중복·맥락 없는 약어로 채운다. 모델이 의도를 못 잡는다.