같은 Grok 구독으로 더 오래 버티는 법: 우리가 실제로 측정한 것

Grok Build가 "한도에 도달했다"며 멈출 때, 대부분의 사람은 자기가 질문을 너무 많이 했다고 생각합니다. 그런데 세션 안에서 실제로 오가는 바이트를 재 보면 그림이 다릅니다. 한도를 태우는 것의 대부분은 당신이 친 프롬프트가 아니라, 에이전트가 스스로 읽어 들인 것입니다.

우리는 이걸 추측으로 두지 않고 측정했습니다. 그리고 그 측정에 맞춰 meshcode가 Grok을 띄우는 방식을 바꿨습니다. 이 글은 무엇을 쟀고, 무엇을 바꿨고, 그 결과 어디까지가 사실이고 어디부터는 아닌지에 대한 기록입니다.

세션 하나가 삼킨 30.4MB

2026년 8월 19일, Grok 세션 하나에 흘러든 유입 코퍼스 전체를 계측했습니다. 총 30.4MB. 항목별로 뜯어보면 범인이 분명합니다.

여기서 중요한 건 분포의 모양입니다. Grok은 대부분의 경우 알아서 20~80줄만 읽습니다 — 그 호출들은 아무 문제가 없습니다. 예산을 태우는 건 limit을 아예 지정하지 않은 290번의 호출이고, 그것만으로 1.83MB입니다. 파일을 통째로 읽어 들인 겁니다.

Grok의 메타 검색 툴인 search_tool도 같은 모양입니다. p90은 11KB로 얌전한데, 최대값이 39KB이고 합계는 2.75MB입니다. 반대로 meshcode 자신의 툴은 이미 스스로 상한을 걸고 있어서 실측 최대가 read 9.9KB, grep 8KB였습니다 — 여기는 손댈 게 없었습니다.

왜 꼬리 하나가 세션 전체를 갉아먹는가

"30MB 중 1.83MB면 6%밖에 안 되는데?"라고 생각하기 쉽습니다. 이게 함정입니다.

에이전트 대화에서 컨텍스트는 누적됩니다. 3번째 턴에 30KB짜리 파일이 통째로 들어오면, 그 세션이 40턴까지 간다면 그 30KB는 남은 37턴 동안 매 턴 다시 청구됩니다. 한 번의 무절제한 읽기가 한 번의 비용이 아니라, 세션이 길어질수록 복리로 붙는 비용이 되는 겁니다.

Grok Build의 한도가 특히 예민하게 반응하는 지점이 여기입니다. 앞선 글에서 정리했듯 Grok의 무료 한도는 리셋 시각을 알려 주지 않고 업셀만 보여 줍니다. 언제 풀리는지 모르는 예산일수록, 초반에 새는 구멍이 뼈아픕니다.

그래서 우리가 잡은 목표는 "Grok을 아껴 쓰게 만들자"가 아니라 훨씬 좁았습니다: 정상 호출은 절대 건드리지 않고, 꼬리만 자른다.

meshcode가 Grok에 거는 바운드 네 개

meshcode에서 Grok 패널을 띄우면, 그냥 grok 을 실행하는 것과 달리 네 가지 장치가 함께 걸립니다.

1. read_file에 300줄 상한. Grok의 read_file은 Grok 바이너리 자체 툴이라 우리가 결과에 손을 댈 수 없습니다. 대신 호출이 나가기 전에 끼어들어, limit이 없거나 300을 넘는 호출에만 limit=300을 넣습니다. 20~80줄짜리 정상 호출은 이 값에 닿지도 않습니다.

2. MCP 툴 결과에 12,000바이트 상한. search_tool의 p90이 11KB이므로, 12,000이라는 값은 정상 응답을 자르지 않으면서 39KB짜리 꼬리만 잘라냅니다. 이건 사용자의 ~/.grok/config.toml을 건드리지 않고 meshcode가 띄운 그 프로세스에만 걸립니다.

3. 첫 턴에 남의 카탈로그가 붙지 않게. Grok TUI는 기본적으로 Cursor의 MCP 설정과 skills/rules를 스캔합니다. meshcode는 Cursor를 쓰지 않으므로, 남아 있는 Cursor 카탈로그가 툴 스키마로 첫 턴에 통째로 붙는 것을 끕니다.

4. 대량 탐색은 값싼 모델에게. 가장 큰 절감은 상한이 아니라 구조에서 나옵니다. "어디에 있는지 찾는" 작업을 meshcode가 더 싼 백엔드의 자식 세션에 넘기면, 그 자식이 읽어 들인 수십 MB는 당신의 Grok 세션에 한 줄도 쌓이지 않습니다. 돌아오는 건 파일:줄 몇 줄뿐입니다. meshcode는 세션 시작 시 이 규칙을 심고, 탐색 호출이 쌓이면 짧은 리마인더로 다시 세웁니다.

"덜 쓴다"가 정확히 뜻하는 것 — 그리고 아닌 것

여기서 정직할 필요가 있습니다. 우리는 "토큰 40% 절감" 같은 숫자를 말하지 않습니다. 그런 숫자는 워크로드마다 달라지고, 우리가 잰 건 그게 아닙니다.

우리가 실제로 말할 수 있는 건 이겁니다:

• 세션 하나에 30.4MB가 들어왔고, 그중 최대 항목은 read_file 11.9MB였다.
• 그 안에서 상한이 실제로 겨냥하는 건 limit 없는 290콜의 1.83MB와 10KB를 넘긴 1.32MB의 꼬리다.
• search_tool은 합계 2.75MB에 최대 39KB짜리 응답이 섞여 있었고, 12,000바이트 상한이 그 꼬리를 자른다.
• 자른 만큼은 한 번이 아니라 남은 턴 수만큼 절약된다. 컨텍스트는 누적되기 때문이다.

반대로 이건 사실이 아닙니다: 이 장치들이 Grok을 더 똑똑하게 만들지는 않습니다. 300줄로 잘린 파일을 에이전트가 더 봐야 한다면 이어서 읽으면 됩니다 — 다만 그때는 필요한 부분만 읽게 됩니다. 상한의 목적은 금지가 아니라, 기본값을 무절제에서 절제로 뒤집는 것입니다.

맨손 grok TUI를 망가뜨리지 않는 것도 조건이었다

이 작업에서 가장 까다로웠던 부분은 절감이 아니라 부작용이었습니다.

Grok의 훅 파일은 프로젝트 단위로 놓을 수가 없고 전역 ~/.grok/hooks/에만 놓입니다. 즉 meshcode가 설치한 훅은 사용자가 터미널에서 맨손으로 grok을 칠 때도 발화합니다. 초기 구현은 훅이 매번 meshcode 바이너리를 실행해서 "우리 세션인가?"를 확인했는데, 그 확인 자체가 호출당 895ms였고 특정 조건에서는 read_file 한 번마다 창이 하나씩 뜨기까지 했습니다. 남의 세션에서요.

그래서 판정을 바이너리 안쪽에서 바깥의 작은 셸 스크립트로 끌어올렸습니다. meshcode가 띄운 세션에만 심기는 표식이 없으면, 스크립트는 아무것도 실행하지 않고 즉시 통과합니다.

어제 재검증한 실측치입니다:

남의 도구를 느리게 만들면서 얻는 절감은 절감이 아닙니다. 맨손 Grok 사용자에게 이 훅의 비용은 정확히 0이어야 했고, 그게 확인된 뒤에야 실었습니다.

meshcode의 관점

meshcode는 macOS와 Windows용 네이티브 데스크톱 앱이고, 여러 에이전트를 병렬 패널에서 돌리는 구조로 만들어졌습니다. 이미 쓰고 있는 Grok 구독을 그대로 패널에 연결할 수 있습니다 — 같은 결제, 같은 한도이고, meshcode가 중간에서 추가로 받는 것은 없습니다.

다만 같은 구독이 더 오래 갑니다. 특별한 마법이 있어서가 아니라, 세션에 무엇이 얼마나 흘러드는지 실제로 재고 그 꼬리에 상한을 걸어 두었기 때문입니다. 그리고 정말 큰 탐색 작업은 애초에 당신의 Grok 컨텍스트가 아니라 더 싼 모델의 컨텍스트에서 벌어지게 만들어 두었기 때문입니다.

한도 관리 자체를 그만두고 싶다면, 그 옆에 meshcode 자체 과금형 모델을 준비해 둘 수 있습니다 — 월 요금도, 공유 윈도우도 없이 쓴 만큼만 차감되는 잔액입니다. 한쪽이 "come back later"라고 할 때 갈 곳이 있다는 뜻입니다. 같은 분해를 Claude 쪽에서 보고 싶다면 Claude Pro 구독을 더 오래 쓰는 법에서 다뤘습니다.

한도를 프롬프트로 아끼려 하지 마세요 — 유입에 상한을 거세요. meshcode는 무료로 시작할 수 있고, Grok 패널은 첫 실행부터 위 네 가지 바운드가 걸린 채로 뜹니다.

👉 meshcode 다운로드 — Mac, Windows.