• 예를 들어 직장, 집에서 각각 Claude Code를 셋업하는 것은 귀찮다. 그렇다면 셋업용 리포지토리를 만들어서, 거기서부터 셋업할 수 있게 하면 되지 않을까.

• 그럼 겸사겸사, 토대가 될 만한 기능류를 담아서 만들어 달라고 할까, 본인(Claude)에게.

• 최종적인 현재의 최종 형태로서, 다음과 같은 기능이 포함된

• RTK・Lean-CTX 등의 토큰 절감(Token Reduction) 계열 도구의 자동 도입 (이 기사)

• 로컬 LLM을 조합한 6관점 리뷰

• epic/dev 개발 플로우 계열 SKILL

• Knowledge-RAG・Kizami 등의 기억 계열 도구의 자동 도입 (단, 여기는 도입만. 활용할 수 있는 형태는 아직 개발 중)

• 이번에는 RTK・Lean-CTX의 토큰 절감 계열에 관한 기사입니다.

기본적으로는 과거의 Claude Code와의 세션 로그 등을 AI를 이용해 확인하고,

거기서부터 정보를 정리하는 형태로 기사를 쓰고 있습니다만,

어느 정도 생성물(Generative output)이므로, 미리 양해 부탁드립니다.

같은 환경을 준비하는 것, 역시 은근히 번거롭습니다.

"집에서도 작업해야 하는데, 이 환경을 집에도 만드는 건 귀찮아..."

라는 생각을 한 것이 불행의 시작이었습니다.

Gemini를 무료 범위 내에서 최대한 활용해 보고,

만족하지 못해 Claude를 구독하게 된 후, 오랜만에 개발 작업이 즐겁다며 열심히 작업을 하고 있었는데,

이왕이면 이 환경을 부담 없이 복사할 수 있게 해둘까 하는 것이 발단이었습니다.

그러다 겸사겸사 이것저것 담다 보니, 작업 시작 후 3개월 차에 돌입해도 아직 완성되지 않았습니다(

그런 이유로, settings.json이나 CLAUDE.md 등의 기초적인 파일들을 리포지토리에 집어넣고,

이후 이용할 환경에서 <projectRoot>/CLAUDE.md나 <projectRoot>/settings.json 등을 만들며,

~/.claude/ 하위의 파일은 글로벌(Global)한 것으로 취급한다는 방침을 정하고, 리포지토리 구축에 착수했습니다.

Claude 구독 자체는 2026/03부터 하고 있었습니다만,

개발 사용 시 토큰을 엄청나게 잡아먹어서(Token consumption),

금방 리미트(Limit)에 도달해 업무가 중단되어 발광하는 사태가 벌어지고 있었습니다.

(이쪽의 사용법이 잘못된 부분도 있었다. 세션을 끊지 않고 계속 이어가는 등 기본이 되어 있지 않았다)

이렇게 되지 않으려고 Gemini를 그만두고 돈을 낼까 생각했는데... 하며 낙담하고 있었는데,

X를 구경하다가 RTK 포스트를 발견하여, 한번 시도해 볼까 하는 생각에 넣어보기로 했습니다.

Claude와 대화(Wall-hitting)한 결과, 도입할 가치가 있다고 하여, 그럼 도입하자고 Claude에게 의뢰.

리포지토리는 위와 같이 기초적인 파일이 이미 복사되는 상태였으므로,

그 위에 얹는 형태로 설치 및 셋업도 포함하도록 수정하게 하여,

우선 운용해 보기로 하고 운용을 시작했습니다.

도입은 해서 좋았다가 결론입니다.

이것은 나중 이야기입니다만, 유사한 도구로서 Lean-CTX도 도입하고 있습니다.

Lean-CTX에 대해서는 별도 항목에서 작성할 것이므로, 여기서는 RTK에 집중한 결과로서 정리해 나가겠습니다.

2026/07/06 시점에서 rtk gain의 결과는 다음과 같은 느낌이었습니다.

수치상으로는 낮은 결과가 나왔습니다만,

이는 후술할 Lean-CTX도 연관되어 있기 때문에,

이 결과만으로 RTK의 효과에 의문을 품을 수는 없습니다.

집계 대상 기간은 2026/06/01 ~ 2026/07/06 시점의 것입니다.

다음과 같이, 효과가 있어야 할 부분(예: git 명령어 계열 등)에는 제대로 작동하고 있으므로,

이것만으로도 도입해 두는 것이 손해가 되는 것은 아니라고 생각합니다.

물론 RTK 자체가 이용하는 모든 명령어를 커버하는 것은 아니기 때문에,
모든 것에 효과가 있는 것은 아니지만, 효과가 0은 아니라면 괜찮다고 판단하고 있습니다.
(토큰을 1 토큰이라도 절약할 수 있다면 더 좋으니까)

RTK가 출력을 압축/정형화하는 것이나 다른 hook/툴과 중복되는 것으로 인해 운영상의 함정이 많았습니다.

이 부분은 AI의 출력도 보면서, '어?' 싶으면 RTK의 경우까지 포함해서 전달하고,
다시 확인할 정도의 운용은 필요하다는 느낌입니다.

상세한 내용은 다음과 같습니다.

PR 리뷰 등에서 diff가 필요할 때, gh pr diff의 출력을 awk '/^diff --git/'로 파일 단위로 필터링해야 하는 상황이 있었다.

하지만 RTK가 gh pr diff의 출력을 압축 및 정형화하면, 가공되지 않은 (raw) unified diff를 전제로 하는 동작이 깨지게 된다. 그 결과, awk 필터가 작동하지 않아 제외하고 싶은 파일이 남거나, 기대했던 diff 블록 단위로 처리할 수 없게 되었다.

대책은, diff 구문을 파싱하는 처리에서는 RTK를 bypass(우회)하는 것이다.

rtk proxy gh pr diff 191 > /tmp/pr191.diff

다른 프로젝트의 로그에서도 gh pr diff 2 | awk ...가 작동하지 않아, "RTK가 포맷 변환을 완료함"이라고 판단하고 git diff main..branch -- ':!file'로 전환되는 현상이 있었다.

이는 RTK 본체 측의 미해결 버그(unresolved bug)로, 현재로서는 회피할 수밖에 없는 부분이다.

RTK는 Claude Code의 Bash hook을 통해 git diff HEAD와 같은 명령어를 rtk git diff HEAD로 교체한다.

다만, $() 안에 git 명령어가 있는 경우, 교체 위치가 어긋나 명령어가 깨지는 경우가 발생할 수 있다.

DIFF=$(git diff HEAD)
# 본래 기대하는 교체
DIFF=$(rtk git diff HEAD)
...

이 결과로 인해 $() 내의 명령어 치환(command substitution)이 이상해져서, git rtk diff HEAD와 같은 잘못된 git 서브 명령어(subcommand)로 실행된다.

그렇기 때문에 RTK가 올바르게 호출되지 않으며, RTK의 절감 대상이나 통계에도 포함되지 않는 케이스가 발생한다.

이러한 케이스들이 해결된다면, RTK의 절감 효율은 조금 더 높아질 가능성이 있다.

RTK를 도입하게 된 배경을 말씀드리자면, 당시(아마도 5월쯤이었던 것 같다) 토큰 절감 관련 이야기가 조금 화제가 되었던 시기였다.

(Claude Code가 토큰 소비 버그를 안고 있어서, 소비량이 급증해 금방 리미트(limit)에 도달한다는 포스트가 많았던 시기. 참고로 2026/07/07 시점에도 해당 Issue는 Open 상태이다.)

Lean-CTX도 그런 흐름 속에서 우연히 포스트를 보게 되었고, 가벼운 마음으로 Claude에게 물어보면서 도입하기로 결정했던 기억이 있다.

다만, Lean-CTX 자체는 RTK의 동작 부분과의 충돌 외에도, Knowledge-RAG나 Kizami가 이미 분담하고 있던 장기 기억(long-term memory) 관련 분야의 기능도 갖추고 있었기 때문에, RTK로 다 커버하지 못하는 부분을 기대하며 도입하여 사용해 보기로 판단했다.

구체적으로는 다음과 같은 표와 같다.

리포지토리로서의 목적은 동일한 환경을 구축하는 것이지만, 이 리포지토리를 이용하는 환경에서의 목표는 개발, 유지보수, 운영의 실무적인 영역이다.

그러한 관점에서 유효하다고 판단한 근거로, Lean-CTX 측의 설명에서는 다음과 같은 절감 사례가 언급되어 있었다.

이 수치는 내 환경에서의 실측값이 아니라, Lean-CTX 조사 시 공식 정보 및 README 등에서 수집한 대표값이다.

git status와 같은 Shell 출력은 Claude Code 상에서의 호출 방식이나 hook 순서에 따라 RTK 측에서 처리할 수도 있고, Lean-CTX 측에서 처리할 수도 있다.

이 점을 엄격하게 제어하려면 hook 설정이나 allowlist(허용 목록) 조정이 필요하다.

다만, 도입 목적은 어디까지나 Claude Code로 전달되는 토큰 (Token) 양을 줄이는 것이므로,

RTK와 Lean-CTX의 담당 영역이 일부 겹치는 것은 허용하며,

둘 중 어느 한쪽이라도 압축을 해주고 있다면 목적은 달성된 것이라는 판단을 내리고 있습니다.

2026/07/07 시점에서, lean-ctx gain 및 lean-ctx stats -a의 결과는 다음과 같았습니다.

RTK의 표와 표시 항목을 맞출 수 있는 것들을 맞춘 표는 다음과 같습니다.

Raw gain 출력 표 및 lean-ctx stats -a 결과

Commands: 1575
Input: 1865114 tokens
Output: 1229490 tokens
...

Lean-CTX 단독으로 나타난 이 수치에 대해서는, 도입하기를 잘했다는 생각이 듭니다.

파일 관련 처리는 RTK보다 우수할지도 모르겠습니다.

조금 더 제대로 영역 분리 등의 설정을 다듬는다면 효율 자체도 올라갈 수 있겠지만,

그럴 경우 앞서 언급한 hook 설정 등, 아마도 추측입니다만 CLAUDE.md에서의 동작 제어 등도 수단으로서 검토할 필요가 생길 가능성이 있기 때문에,

우선은 대략적으로 넣어두었고 어느 정도 토큰을 절감해주고 있으므로, 현재로서는 허용해도 괜찮다는 판단하에 이용을 계속하고 있습니다.

Lean-CTX 단독으로 발생할 수 있는 것과 RTK와의 복합 작용에 기인하는 것 모두를 고려한 결과였습니다.

최종적으로는 Lean-CTX 측의 shell allowlist를 상당히 완화했습니다.

shell_security = "on"
shell_allowlist = []

shell_allowlist = [] 설정은 실질적으로 Lean-CTX의 필터를 거의 그대로 통과시키는 설정이 됩니다.

따라서 Claude Code의 permissions.deny 등 다른 레이어에서 위험한 명령어를 제한해 두는 것을 강력히 권장합니다.

shell_security 자체는 유효한 상태로 유지하면서 shell_allowlist = []로 설정함으로써, Lean-CTX 측의 셸 명령어 필터링은 실질적으로 무효화했습니다.

위험한 명령어에 대해서는 Lean-CTX 도입 전부터 어느 정도 Claude Code 측의 permissions.deny로 제어하고 있었기 때문에, 최종적으로는 그쪽에서 관리하는 방침으로 정했습니다.

처음에는 RTK를 도입하고 나중에 Lean-CTX를 도입해 보았으나, 결국 RTK를 제거하거나 혹은 Lean-CTX를 제거하여 하나로 통합하는 판단은 하지 않았습니다.

달성하고자 하는 항목은 토큰 절감이 목적이었기 때문에, 그 관점에서 보았을 때 다음과 같은 결과가 나왔습니다.

단순히 토큰 수만 집계하면 다음과 같습니다.

RTK와 Lean-CTX는 집계 대상이나 측정 방법이 다르기 때문에, 절감률을 그대로 나란히 놓고 비교하는 것은 그리 적절하지 않습니다.

또한, hook이나 MCP를 경유한 처리가 겹치는 부분도 있으므로, 위의 합산값은 "엄밀한 총 절감량"이라기보다 제 환경에서 각 도구가 기록했던 절감 실적의 합계로 보고 있습니다.

병용함에 따른 문제나 Lean-CTX 측의 설정 문제 등도 있었지만, Claude Code의 리미트(limit)에 걸리기까지의 시간이 늘어난다면 괜찮다(ヨシ)는 판단하에 병용을 계속하기로 했습니다.

여러 가지 X(구 Twitter) 등도 확인하면서, 궁금한 내용을 Claude에게 추가로 물어보며 진위 여부를 확인하기도 했기에 생각보다 시간은 걸렸습니다.

다만, 어느 정도 안심하고 사용할 수 있는 Claude Code 환경을 만들기 위한,

준비의 준비 정도는 갖춰졌다는 느낌입니다.

그렇다고는 해도 이 분야는 일취월장(日進月歩)은커녕 조령모개(朝令暮改)의 기세로 변화하고 있기 때문에,

놓치고 있는 부분이 있어 토큰 (Token) 절감의 여지는 아직 더 남아있을지도 모르겠습니다.