/context를 사용하여 사용량을 확인하고, MCP 서버를 중단하고, 불필요한 메모리 파일을 삭제했습니다. 기동 시점의 사용량은 확실히 줄어들었습니다. 이 절차에 대해서는 이 기사가 자세히 설명하고 있습니다.

그럼에도 불구하고, 작업을 시작하고 30분도 채 되지 않아 다시 Compacting conversation...이 나타납니다.

기동 시에 확보한 자리는 작업을 시작하는 순간부터 다시 채워지기 때문입니다. 채워지는 내용은 읽어들인 파일의 내용과, 커맨드 실행 결과, 그리고 대화 그 자체입니다. 이 부분은 /context의 내역에는 나타나지 않습니다. 작업할 때마다 늘어나기 때문에, 줄이는 방법도 달라야 합니다.

제가 실천하고 있는 줄이는 방법을 절차로서 적어두겠습니다.

가장 효과적입니다. 수천 행의 파일을 하나 읽게 하면 그것만으로도 수만 토큰이 점유됩니다.

먼저 위치를 특정하고 나서, 그 주변만 읽게 합니다.

# ❌ 「이 파일을 보고 수정해줘」 → 전부 점유됨
# ✅ 우선 해당 부분을 찾음
grep -rn "handle_submit" ./includes/
...

Claude Code에게 부탁할 때도 범위를 지정합니다.

❌ includes/class-handler.php를 읽고, 유효성 검사(Validation)를 수정해줘
✅ includes/class-handler.php의 300행 부근에 있는 handle_submit의
유효성 검사 부분만 보고 수정해줘. 주변 60행 정도면 충분해

어디에 있는지 모를 때도 바로 열게 하지 않습니다. 먼저 검색하게 하여 타겟을 정한 뒤에 읽게 합니다.

✅ 우선 grep으로 validate라는 단어를 포함하는 곳을 찾아서,
후보 목록(파일명과 행 번호)만 출력해줘.
내용을 읽는 것은 어떤 것을 볼지 결정한 다음에 해

테스트나 빌드 출력은 성공한 부분이 길 뿐, 필요한 것은 실패한 부분뿐입니다.

# ❌ 전부 실행
composer test
# ✅ 실패한 부분만 추출
...

로그도 마찬가지로, 범위를 좁힌 뒤에 전달합니다.

# ❌ tail -f로 로그를 전부
# ✅ 해당 시각의 전후만
sed -n '/2026-07-27 14:2/,/2026-07-27 14:3/p' debug.log

git diff도 그대로 전달하면 거대해집니다. 파일을 좁히거나, 통계만 먼저 확인합니다.

git diff --stat # 우선 전체상
git diff -- includes/class-handler.php # 볼 곳을 결정한 뒤에

조사는 과정이 길어집니다. '저걸 보니 아니네, 다음 걸 보자' 식의 시행착오가 전부 메인 대화에 쌓이면, 결론에 도달할 즈음에는 자리가 다 차 있습니다.

서브 에이전트(Task 툴)에게 맡기면, 중간에 읽은 내용은 메인에 올라가지 않습니다. 돌아오는 것은 결론뿐입니다.

의뢰할 때의 형식을 남겨둡니다.

서브 에이전트로 조사해 주세요.
【조사할 것】
이 플러그인에서, 사용자 입력을 받아 DB에 저장하고 있는 곳을
...

중요한 것은 마지막의 "목록만, 내용은 붙여넣지 마"입니다. 이것을 쓰지 않으면 조사 결과로서 대량의 코드가 반환되어, 결국 메인에 쌓이게 됩니다.

또 하나, 전제를 쓰는 것입니다. 서브 에이전트는 메인 대화를 알지 못합니다. 이쪽에서 당연하다고 생각하는 조건을 쓰지 않고 던지면, 대상 외의 디렉토리까지 조사한 답이 돌아옵니다. 저는 이것 때문에 한 번 헛수고를 한 적이 있습니다.

압축(Compacting)에 의해 끊기게 되면, 무엇을 남기고 무엇을 버릴지 선택할 수 없습니다. 스스로 끊으면 필요한 결론만을 가지고 다음으로 넘어갈 수 있습니다.

끊는 타이밍은 작업의 성격이 바뀔 때로 하고 있습니다. 조사가 끝나고 구현에 들어갈 때. 구현이 끝나고 리뷰에 들어갈 때.

(끊기 전에, 다음 세션으로 넘길 것을 작성하게 함)
여기까지 파악한 내용을, 다음 세션에 전달하는 형태로 정리해줘.
・확정된 사실
...

이것을 받아서 새로운 세션의 도입부에 붙여넣습니다. 읽은 파일의 내용은 넘어가지 않고, 결론만이 계승됩니다.

줄이는 작업을 해도, 보이지 않으면 계속할 수 없습니다. 상태 표시줄(Status line)에 잔량을 표시해 두면, 늘어나는 패턴을 파악할 수 있습니다.

npx ccstatusline

제 경우, 이것을 보기 시작한 이후로 "이렇게 부탁하면 한꺼번에 줄어든다"라는 패턴을 파악할 수 있었습니다. 대개 큰 파일을 읽게 한 직후입니다.

절약을 시작하면 세세한 부분이 신경 쓰이게 됩니다. 다만, 수치를 확인하지 않으면 불필요한 참음을 하게 됩니다.

CLAUDE.md에 매번 규칙을 복창하게 하는 방법이 있습니다. 컨텍스트(Context)가 아깝다는 생각이 들어 한동안 시도하지 않았습니다. 하지만 실제로 적용해 보니 거의 신경 쓰이지 않았습니다. 규칙 세트는 기껏해야 수백 토큰 수준이며, 이는 파일 1개를 읽는 것과는 자릿수부터 다릅니다.

반대로, MCP를 너무 많이 줄였을 때는 필요한 기능을 사용할 수 없게 되어, 다시 수작업으로 돌아가는 데 드는 시간이 더 컸습니다.

줄일 대상을 선택할 때는 먼저 자릿수를 확인하세요. 수백 토큰을 아끼려고 애쓰는 것보다, 수만 토큰의 읽기를 한 번 줄이는 것이 훨씬 효과적입니다.

/context
에 나타나는 것은 기동 시의 고정분입니다. 작업 중에 쌓이는 부분은 별도로 줄여야 합니다.

• 파일은 grep이나 행 범위(line range)로 좁힌 뒤에 읽게 합니다. 통째로 읽는 것이 비용이 가장 높습니다.
• 테스트·로그·diff는 실패 지점이나 대상 파일로 범위를 좁힌 뒤에 전달합니다.
• 조사는 서브 에이전트(Sub-agent)에게 맡깁니다. 이때 "목록만 보여주고 내용은 붙여넣지 말 것"이라는 "전제"를 반드시 작성합니다.
• 압축되기 전에 스스로 구획을 나눕니다. 다음 단계로 넘길 내용은 불렛 포인트(bullet points)로 작성하게 합니다.
• npx ccstatusline으로 잔량을 상시 표시하며, 줄어드는 패턴을 파악합니다.
• 아껴야 할 대상은 자릿수로 판단합니다. 수백 토큰보다는 한 번의 큰 읽기를 줄여야 합니다.

기동 시의 정리(Cleaning)는 한 번에 효과를 보지만 한계가 있습니다. 그 부분을 다 깎아내도 부족할 때는 전달 방식을 수정하면 아직 여지가 남아 있습니다. 도움이 되었다면 저장해 두었다가, Compacting이 늘어나기 시작할 때 다시 확인해 보세요.

평소에는 raplsworks.com에서 WordPress 플러그인 개발이나 Claude Code 관련 글을 쓰고 있습니다.