Compacting conversation...

이 문구가 뜰 때마다 조금 낙담하게 됩니다. 기다려야 할 뿐만 아니라, 압축된 이후에는 방금 결정했던 내용을 잊어버리기도 하니까요.

저도 예전에 이 현상이 늘어나는 것이 신경 쓰여서, /context 명령어로 컨텍스트(Context)의 내역을 직접 측정해 본 적이 있습니다. 측정해 보니 생각보다 많은 양이 작업을 시작하기도 전부터 채워져 있었습니다. MCP 서버 정의, 항상 읽어들이는 메모리 파일, 시스템 프롬프트(System Prompt). 아무것도 하지 않았는데도 이미 상당한 자리가 예약되어 있는 상태였습니다.

얼마 전, Zenn에서 비슷한 작업을 수행한 글을 읽었습니다. 사용하지 않는 MCP를 중단하고, 자체 제작한 MCP의 출력을 재검토하며, 불필요한 메모리 파일을 삭제하여 사용량을 크게 줄였다는 내용이었습니다. 하는 방법은 저와 같은 방향이었고, 게다가 확실한 수치로 증명되어 있었습니다.

다만, 그 글을 읽으면서 제가 직접 측정했을 때 깨달았던 점을 아직 쓰지 않았다는 사실이 떠올랐습니다. /context로 보이는 것은 컨텍스트 고정비(Fixed Cost)뿐이라는 점입니다.

고정비와 변동비

컨텍스트 소비에는 성질이 다른 두 가지가 있습니다.

**고정비(Fixed Cost)**는 세션을 열었을 때 이미 포함되어 있는 것입니다. MCP 서버 정의, CLAUDE.md와 같은 메모리 파일, 시스템 프롬프트. 작업 내용과 상관없이 매번 동일한 양의 공간을 차지합니다.

**변동비(Variable Cost)**는 작업을 진행하면서 쌓여가는 것입니다. 읽어들인 파일의 내용, 커맨드(Command)나 테스트 실행 결과, 대화 그 자체. 무엇을 하느냐에 따라 양이 완전히 달라집니다.

/context를 입력했을 때 내역으로 나열되는 것은 주로 전자인 고정비입니다. 그렇기에 그 화면을 보고 줄일 수 있는 것은 고정비이며, 이는 한 번 줄여두면 매번 효과를 보는 좋은 투자가 됩니다. 다만, 줄일 수 있는 양에는 한계가 있습니다. 전부 삭제하더라도 제로(0)가 되지는 않습니다.

반면 변동비에는 한계가 없습니다. 큰 파일을 여러 권 읽게 하면 그것만으로도 고정비의 몇 배가 쌓입니다. 그리고, Compacting conversation...을 실제로 불러오는 것은 대부분 변동비 쪽이었습니다.

고정비를 줄이는 이야기는 앞서 언급한 글에 잘 정리되어 있습니다. 여기서는 그 너머의 변동비에 대해 쓰겠습니다.

변동비를 줄이는 법

제가 실천하고 있는 것들을 효과가 큰 순서대로 정리했습니다.

파일을 통째로 읽히지 않기

가장 효과적입니다.

"이 파일을 봐줘"라고 통째로 맡기면 당연히 전부 포함됩니다. 수천 행의 파일이라면 그것만으로도 수만 토큰(Token)입니다. 실제로 필요한 것은 그중 하나의 함수뿐인 경우가 대부분이었습니다.

따라서 미리 범위를 좁힙니다. grep으로 해당 부분을 찾은 뒤 그 주변부만 읽게 합니다. 행 범위를 지정하여 읽게 합니다. 어디에 있는지 모를 때도 우선 검색을 통해 짐작을 한 뒤에 파일을 엽니다.

"전부 읽고 나서 생각해줘"는 인간에게는 정중한 부탁이지만, 컨텍스트 입장에서는 가장 비용이 많이 드는 부탁이었습니다.

도구의 출력을 전부 흘려보내지 않기

테스트나 빌드(Build) 출력은 성공했을 때는 길기만 할 뿐 정보가 거의 없습니다.

실패한 부분만 추출해서 전달하도록 하면 소비량이 크게 달라집니다. 테스트라면 실패한 케이스만, 로그라면 해당 시점의 전후 맥락만 전달합니다. 파이프(Pipe)로 걸러서 보여준다는 단순한 이야기지만, 이를 수행하느냐 아니냐에 따라 세션의 수명이 달라졌습니다.

조사 업무는 서브 에이전트(Sub-agent)에게 맡기기

조사는 과정이 길어집니다. 이것을 보고, 저것을 보고, 아니면 다음 것을 보고. 이러한 시행착오가 전부 메인 대화에 쌓이면 결론에 도달할 때쯤에는 컨텍스트가 가득 차 버립니다.

그래서 조사는 서브 에이전트에게 맡기고 결과만 받도록 했습니다. 중간에 읽은 파일의 내용은 메인 대화에 포함되지 않습니다.

다만, 이 방식으로 실패한 적이 있습니다. 서브 에이전트는 메인 대화의 내용을 모릅니다. 전제 조건을 전달하지 않고 던지면, 제가 당연하다고 생각하는 조건을 무시한 답변이 돌아옵니다. 분리할 경우에는 전달할 전제 조건도 함께 작성해야 합니다.

작업마다 세션을 나누기

조사와 구현을 같은 세션에서 계속하지 않습니다. 구현을 시작하기 전에 한 번 끊어줍니다.

구분(Cut)을 스스로 넣으면 Compacting에 의해 강제로 끊기는 것보다 제 의도대로 끊을 수 있습니다. 압축에 맡기면 무엇이 남고 무엇이 삭제되었는지 선택할 수 없습니다. 스스로 끊으면 필요한 결론만을 가지고 새로운 세션을 시작할 수 있습니다.

너무 줄이면 다른 곳에서 대가를 치른다

고정비에 대해 한 가지만 보충하자면.

저는 한때 MCP (Model Context Protocol)를 줄이는 데 너무 열중한 나머지, 필요한 것까지 중단한 적이 있습니다. 결과적으로 그 기능이 필요할 때마다 수작업으로 돌아가게 되었고, 절약한 토큰보다 소요된 시간이 더 비싼 대가를 치렀습니다.

절약이 목적이 되면 이렇게 됩니다. 공간을 비우는 목적은 작업을 하기 위해서인데, 작업이 불편해진다면 본말전도입니다.

비슷한 이야기를 하나 더 하자면, CLAUDE.md에 매번 규칙을 복창하게 하는 기법이 있습니다. 컨텍스트 (Context)가 아깝다는 생각에 한동안 시도하지 않았습니다. 실제로 넣어보니 거의 신경 쓰이지 않았습니다. 규칙 세트는 기껏해야 수백 토큰 수준이며, 파일 읽기 단위와는 비교조차 되지 않습니다.

아끼는 곳을 자릿수(桁)로 판단하라. 수백 토큰를 아끼려다 수만 토큰을 놓치고 있다면 의미가 없습니다. 저는 인상(impression)에 의존해 절약하려다 이 실수를 저질렀습니다.

애초에, 넣기 전에 선택한다

고정비(Fixed cost)를 줄이는 작업을 하며 느낀 점은, 줄이기 전에 넣는 시점에서 선택할 수 있었을 것이라는 점이었습니다.

저는 무언가를 추가하고 싶을 때, 가벼운 순서대로 검토하려고 노력합니다. 설정 파일로 해결할 수 있는가. 스크립트 하나로 끝낼 수 있는가. 기술(Skill)로 해결할 수 있는가. 그래도 부족할 때 MCP를 넣습니다.

MCP는 강력하지만, 넣는 순간부터 사용하지 않는 턴(turn)에서도 정의된 만큼의 자리를 계속 차지합니다. 사용 빈도가 낮을수록 상주시키는 형태가 되지 않는 편이 좋았습니다.

줄이는 것은 사후 처리이고, 선택하는 것은 예방입니다. 예방하는 편이 나중에 드는 수고가 적습니다.

다음의 나에게 전달하는 메모

/context

로 보이는 것은 주로 고정비. 줄이면 매번 효과가 있지만 한계가 있음

Compacting

을 호출하는 것은 대개 변동비(Variable cost) 쪽 - 파일은 통째로 읽게 하지 않는다. grep이나 행 범위로 좁힌 뒤에 읽는다

• 도구 출력은 실패한 부분만 전달한다. 성공 로그는 길기만 하다
• 조사는 서브 에이전트 (Sub-agent)에게. 단, 전제 조건을 전달하지 않으면 헛수고하게 된다
• 압축(Compression)에 의해 끊기기 전에 스스로 끊는다
• 아끼는 곳은 자릿수로 판단한다. 수백 토큰를 아끼려다 수만 토큰를 놓치지 않는다
• 줄이는 것보다, 넣기 전에 가벼운 순서로 선택하는 것이 더 저렴하다

컨텍스트가 부족하다고 느낄 때, 가장 먼저 보는 것은 고정비여도 좋다고 생각합니다. 한 번의 조치로 효과가 나타나기 때문입니다. 다만, 그 부분을 다 줄였는데도 부족하다면 원인은 사용 방식에 있습니다. 제 경우, 그 부분을 고쳤을 때 Compacting을 보는 횟수가 더 줄었습니다.

평소에는 raplsworks.com에서 WordPress 플러그인 개발이나 Claude Code 주변의 이야기를 쓰고 있습니다.

Discussion