Context Window

문제

큰 파일도 아니고 긴 대화도 아닌데 세션이 갈수록 무거워집니다. 무엇이 쌓이고 있는지 짐작이 안 갑니다.

추천

파일·훅·스킬 선행 읽기의 크기는 “한 번 읽으면 끝”이 아니라 “호출할 때마다 다시 청구되는 비용”으로 봅니다. 한 번의 크기가 아니라 호출 횟수를 곱한 값이 실제 비용입니다.

이유

큰 단일 파일을 계속 Edit하면, 하네스는 Edit할 때마다 그 파일의 앞부분을 다시 컨텍스트에 넣습니다. 포매터 같은 도구는 커밋 직전 1회만 돌리지만, Edit은 그렇지 않습니다. 같은 파일을 여러 번 고치면 앞부분 재주입도 그 횟수만큼입니다. Edit마다 붙는 훅 장문이나 슬래시 스킬 본문 주입도 같은 계열입니다. 호출할 때마다 다 청구됩니다.

스킬도 같은 함정이 있습니다. 스킬이 “필수 선행 읽기 파일” 목록을 갖고 있으면, 그 스킬이 호출될 때마다 목록의 파일을 전부 다시 읽습니다. 짧은 조회표(lookup table)는 SKILL.md 안에 인라인으로 넣습니다. 긴 예시 산문은 외부 파일에 남겨 두되 “이 파일을 먼저 읽어라”는 강제 지시만 없앱니다. 그러면 표는 매 호출마다 오고 산문은 필요할 때만 옵니다.

파일 크기를 한 번의 읽기 비용으로만 재면 실제 부담을 놓칩니다. 실제 부담은 (파일 크기) × (그 세션에서 이 경로를 다시 여는 횟수)입니다. 자주 도는 경로일수록 크기를 줄이는 효과가 큽니다.

예시

스킬을 설계할 때는 이 파일이 스킬 호출마다 다시 읽히는지를 먼저 확인합니다.

스킬 본문에 필요한 정보인가?
├─ 짧은 조회표(값·플래그·경로) → SKILL.md에 인라인화한다
└─ 긴 설명·예시 산문
    ├─ 매 호출마다 필요한가? → 인라인화한다
    └─ 드물게만 필요한가? → 외부 파일로 두되 강제 읽기 지시는 없앤다

같은 질문을 자주 Edit하는 파일에도 적용합니다. 파일이 크고 그중 한 구역만 반복해서 고친다면, 그 구역을 별도 파일로 쪼개는 편이 매 Edit의 재주입 비용을 줄입니다.

하지 말 것

스킬에 “필수 선행 읽기 파일” 목록을 여러 개 걸어두기. 목록이 길수록 매 호출의 고정비가 커집니다. 실제로 쓰이는 것은 짧은 조회표뿐인 경우가 많습니다.

도구 출력을 가공 없이 그대로 컨텍스트에 붓기. 줄 번호·길이 상한·2단 조회(먼저 목록, 필요할 때만 본문)로 설계하지 않으면 큰 출력이 매번 그대로 쌓입니다.

포매터가 1회만 도는 것과 Edit이 반복되는 것을 같은 비용으로 취급하기. 전자는 한 번의 비용이고 후자는 호출 수만큼 곱해지는 비용입니다.