귀하의 Claude Code 청구 금액은 아마도 필요 이상으로 높을 것이며, RTK가 첫 번째 해결책은 아닙니다.

RTK는 진지한 Claude Code 사용자들의 실제 문제를 해결하고 있습니다. 즉, 셸(shell) 중심의 워크플로우에서 토큰 소모를 줄이는 데 도움을 줄 수 있습니다. 하지만 팀이 스택에 또 다른 훅(hook)을 추가하기 전에, 더 간단한 질문을 던져봐야 합니다. Anthropic이 먼저 해결하라고 권고하는 네이티브 비용 및 컨텍스트(context) 문제를 이미 해결했습니까?

Anthropic의 자체 가이드는 제3자 프록시(third-party proxies)에서 시작하지 않습니다. 컨텍스트 관리(context management), 모델 선택(model choice), MCP 오버헤드(MCP overhead) 감소, 스킬(skills), 그리고 서브에이전트(subagents)와 같은 퍼스트 파티 레버(first-party levers)에서 시작합니다. (1)

RTK의 핵심 제안은 일반적인 셸 워크플로우를 더 압축된 형태로 다시 작성하여 토큰 소비를 줄이는 것이며, 일반적인 명령에서 사용량을 잠재적으로 60%에서 90%까지 절감할 수 있습니다. 그러나 중요한 한계가 있습니다. Read, Grep, Glob과 같은 Claude Code의 내장 도구들은 Bash 훅을 통과하지 않으므로 자동으로 다시 작성되지 않습니다. (2)

진정한 결정 사항은 "RTK를 쓸 것인가 말 것인가"가 아닙니다. 그것은 "자체적인 범위, 동작 및 거버넌스 요구 사항을 가진 또 다른 훅 레이어를 도입하기 전에, Claude Code 자체 내부에서 얼마나 많은 효율성을 확보할 수 있는가?"입니다. 많은 팀에게 그 답은 생각보다 훨씬 큽니다.

Anthropic은 이미 네이티브 비용 레버를 제공하고 있습니다

Anthropic의 Claude Code 비용 문서는 놀라울 정도로 명시적입니다. 이 회사는 토큰 사용량이 컨텍스트 크기에 따라 확장되며, Claude Code가 프롬프트 캐싱(prompt caching)과 자동 압축(auto-compaction)을 통해 이미 비용을 절감하고 있다고 밝히고 있습니다. 그런 다음 선제적인 컨텍스트 관리, 적절한 모델 선택, MCP 서버 오버헤드 감소, CLAUDE.md에서 스킬로 지침 이동, 확장된 사고(extended thinking) 조정, 그리고 장황한 작업을 서브에이전트(subagents)에게 위임하는 것을 포함하여 토큰 사용량을 줄이기 위한 여러 퍼스트 파티 전략을 권장합니다. (1)

이 목록이 중요한 이유는 배포 순서를 바꾸기 때문입니다. RTK를 추가하기 전에, 이미 보유하고 있는 네이티브 시스템을 먼저 강화해야 합니다.

해결책 1: 먼저 컨텍스트를 통제하십시오

Claude Code의 많은 낭비는 RTK (Runtime Tool Kit)의 부재 때문이 아니라, 무질서한 세션 (sessions) 때문에 발생합니다.

Anthropic은 사용량을 점검하기 위해 /cost를 사용하고, 관련 없는 작업으로 전환할 때는 /clear를 통해 새로 시작하며, 요약 과정에서 무엇을 남길지 제어하기 위해 /compact 명령어를 사용할 것을 권장합니다. 또한 Anthropic은 프롬프트 캐싱 (prompt caching)과 자동 압축 (auto-compaction)이 이미 반복되는 프롬프트 비용과 긴 세션의 비대화를 줄여준다고 명시하고 있습니다. (1)

이것이 첫 번째 해결책인 이유는 RTK가 방대하게 퍼져 있는 세션 구조를 해결해주지는 못하기 때문입니다. 만약 개발자들이 긴 대화 속에서 관련 없는 컨텍스트 (context)를 계속 끌고 간다면, 명령 재작성 프록시 (command-rewriting proxy)도 그러한 작업 습관을 구제할 수 없습니다.

실행 지침

• /cost를 사용하거나 가시적인 비용 상태 표시줄을 사용하여 토큰 사용량을 명확히 파악하십시오. (1)
• 작업이 전환될 때는 세션을 공격적으로 정리하십시오. (1)
• 압축 (compaction)이 일반적인 이력이 아닌 올바른 정보들을 보존할 수 있도록 압축 명령 (compact instructions)을 추가하십시오. (1)

해결책 2: 셸 출력 (Shell Output)을 최적화하기 전에 적절한 모델을 선택하십시오

이 부분에서도 Anthropic의 가이드는 명확합니다. 비용 관련 문서에 따르면, Sonnet은 대부분의 코딩 작업을 잘 처리하며 Opus보다 비용이 저렴한 반면, Opus는 복잡한 아키텍처 결정이나 다단계 추론 (multi-step reasoning)을 위해 아껴두어야 합니다. Anthropic은 또한 단순한 서브에이전트 (subagent) 작업에는 Haiku와 같은 더 저렴한 모델을 사용할 것을 권장합니다. (1)

이것이 중요한 이유는 많은 팀이 기본적인 모델 규율 (model discipline)을 갖추기도 전에 프록시 최적화로 뛰어들기 때문입니다. 이는 순서가 잘못되었습니다. 만약 개발자들이 Sonnet이나 특화된 서브에이전트가 처리해야 할 일상적인 작업에 비싼 모델을 사용하고 있다면, RTK는 첫 번째 최적화 대상이 아닙니다. 모델 라우팅 (Model routing)이 우선입니다.

실행 지침

• 대부분의 코딩 작업은 기본적으로 Sonnet을 사용하도록 설정하십시오. (1)
• 아키텍처, 모호성, 또는 어려운 다단계 추론에만 Opus를 사용하십시오. (1)
• 코드 리뷰, 디버깅, 또는 데이터 검사(data inspection)와 같은 좁은 범위의 작업을 위해 저비용 서브에이전트를 생성하십시오. Anthropic은 서브에이전트가 자신만의 프롬프트, 권한, 도구 액세스(tool access)를 가진 별도의 컨텍스트 윈도우 (context windows)에서 실행되며, 작업을 더 저렴한 모델로 라우팅할 수 있다고 설명합니다. (3)

해결책 3: Hook Proxy를 추가하기 전에 MCP 오버헤드(Overhead)를 줄이세요

이것은 가장 활용도가 낮은 네이티브 레버(native lever) 중 하나입니다. Anthropian은 MCP 도구 정의(tool definitions)가 기본적으로 지연(deferred)되므로, 도구가 사용되기 전까지는 도구 이름만 컨텍스트(context)에 들어온다고 설명합니다. 또한 사용하지 않는 서버를 비활성화하고, 가능한 경우 gh, aws, gcloud, sentry-cli와 같은 CLI 도구를 우선적으로 사용할 것을 권장합니다. CLI 도구는 MCP 서버보다 컨텍스트 효율성이 높으며, 도구별 목록 나열에 따른 오버헤드(overhead)를 추가하지 않기 때문입니다. (1)

이 조언은 전략적으로 중요합니다. RTK는 마치 셸(shell) 효율성이 유일한 개척지인 것처럼 논의되곤 합니다. 하지만 그렇지 않습니다. 많은 팀에게 더 큰 낭비는 무분별한 MCP 사용 범위(footprint)에서 발생합니다.

실행 지침

• 어떤 MCP 서버가 실제로 활성화되어 있는지 감사(Audit)하세요. (1)
• 사용하지 않는 서버는 비활성화하세요. (1)
• 이미 깔끔하게 작업을 수행할 수 있는 경우, 직접적인 CLI 도구를 우선적으로 사용하세요. Anthropian은 컨텍스트 효율성을 위해 이를 명시적으로 권장합니다. (1)

해결책 4: 반복 가능한 워크플로(Workflow) 로직을 CLAUDE.md에서 분리하세요

이것은 미묘하지만 중요한 부분입니다. Anthropian의 비용 가이드에서는 CLAUDE.md의 지침을 스킬(skills)로 옮길 것을 명시적으로 권장합니다. Anthropian의 개요 및 스킬 문서에서도 CLAUDE.md는 항상 로드되는 프로젝트 가이드(project guidance)로 설명하는 반면, 스킬(skills)과 커스텀 명령(custom commands)은 공유가 가능하고 관련이 있을 때 호출할 수 있는 반복 가능한 워크플로를 패키징하는 용도로 설명합니다. (1)

이 차이는 매우 중요합니다. 과부하가 걸린 CLAUDE.md는 모든 세션에서 컨텍스트 세금(context tax)이 되기 때문입니다. 모든 워크플로, 관례(convention), 템플릿을 시작 파일에 계속 집어넣는다면, 당신은 그것에 대해 반복해서 비용을 지불하게 됩니다.

실행 지침

• CLAUDE.md는 모든 워크플로 변형이 아닌, 안정적인 프로젝트 가이드를 위해서만 유지하세요. Anthropian은 이 파일이 매 세션 시작 시 읽힌다고 밝히고 있습니다. (4)
• 재사용 가능한 워크플로는 스킬(skills)이나 커스텀 명령(custom commands)으로 옮기세요. Anthropian은 /review-pr 또는 /deploy-staging과 같은 공유 커스텀 명령을 명시적으로 지원합니다. (4)
• 반복 가능한 동작이 관련이 있을 때만 로드되기를 원한다면 스킬(skills)을 사용하세요. (5)

Fix Five: 모든 것을 메인 스레드(Main Thread)를 통해 최적화하기 전에 서브에이전트(Subagents)를 사용하세요

Anthropic의 서브에이전트(subagent) 문서는 가치 제안을 매우 직접적으로 설명합니다. 서브에이전트는 자신만의 시스템 프롬프트(system prompts), 도구 액세스(tool access), 권한을 가진 별도의 컨텍스트 윈도우(context windows)에서 실행됩니다. Anthropic은 서브에이전트가 컨텍스트를 보존하고, 탐색(exploration)과 구현(implementation)을 격리하며, 제약 조건을 강제하고, 작업을 더 빠르고 저렴한 모델로 라우팅하여 비용을 제어하는 데 도움이 된다고 말합니다. (3)

이는 운영 측면에서 매우 중요한 사항입니다. 만약 여러분의 메인 Claude Code 세션이 조사(research), 디버깅(debugging), 검증(validation), 구현(implementation)을 하나의 컨텍스트 윈도우에서 모두 처리하려다 보니 비대해진 상태라면, RTK가 첫 번째 해결책이 되어서는 안 됩니다. 더 나은 위임(delegation)이 우선입니다.

해야 할 일

• 대량의 반복적인 작업을 위해 특화된 서브에이전트(subagents)를 생성하세요. Anthropic은 이를 일반적인 패턴으로 나열하고 있습니다. (3)
• 메인 스레드(main thread)가 모든 소란스러운 작업이 아닌, 오케스트레이션(orchestration)과 의사 결정에 집중할 수 있도록 유지하세요. (3)
• 정확도 요구 사항이 허용하는 범위 내에서, 좁은 범위의 위임된 작업에는 비용이 더 저렴한 모델을 사용하세요. (1)

그렇다면 RTK는 어디에 적합한가?

이러한 네이티브 레버(native levers)들이 갖춰진 후에야 RTK를 도입할지 판단하기가 훨씬 쉬워집니다.

RTK가 가장 강력한 효과를 발휘하는 경우는 다음과 같습니다:

• 팀이 터미널 우선(terminal-first) 방식일 때
• Claude Code 사용이 이미 성숙 단계에 있을 때
• 가공되지 않은 Bash 출력이 주요 토큰 소모원(token sink)일 때
• 개발자들이 훅 기반(hook-based) 워크플로우에 익숙할 때
• 팀이 RTK는 Bash 도구 호출만 가로챌 뿐, Read, Grep, Glob과 같은 내장 도구(built-in tools)는 가로채지 않는다는 점을 이해하고 있을 때 (2)

마지막 포인트는 단순한 각주가 아닙니다. 그것은 운영상의 경계선입니다. 만약 개발자들이 대부분의 시간을 Claude Code의 내장 도구 안에서 보낸다면, RTK는 일부 사람들이 기대하는 일관된 최적화 효과를 만들어내지 못할 것입니다. RTK의 자체 문서에서도 이를 명시하고 있습니다. (2)

나의 결론

Claude Code의 네이티브 최적화를 먼저 해결하세요. RTK는 그다음입니다.

이것이 대부분의 팀에게 실질적인 순서입니다. Anthropic은 이미 컨텍스트 (context), 모델 선택 (model selection), MCP 오버헤드 (MCP overhead), 워크플로 패키징 (workflow packaging), 그리고 위임된 실행 (delegated execution)을 위한 퍼스트 파티 레버 (first-party levers)를 제공하고 있습니다. 이러한 요소들은 RTK보다 범위가 넓고, 정당화하기 쉬우며, 플랫폼 자체의 비용 모델과 더 잘 일치합니다. (1)

RTK도 여전히 역할이 있습니다. 하지만 RTK는 혼란스러운 에이전트 사용에 대한 첫 번째 해결책이 아니라, 이미 규율 있게 Claude Code를 운영하고 있는 팀을 위한 2차 레이어 최적화 (second-layer optimization)로 취급되어야 합니다.

실질적인 의사결정 프레임워크 (A Practical Decision Framework)

다음과 같은 경우, 먼저 Claude Code를 네이티브하게 최적화하세요:

• 세션이 길고 무질서한 경우
• 모델 선택이 일관되지 않은 경우
• MCP 사용량이 비대해진 경우
• CLAUDE.md가 쓰레기통처럼 변해버린 경우
• 팀이 아직 서브에이전트 (subagents)나 커스텀 명령어를 제대로 사용하지 못하는 경우

그 이후에 다음과 같은 경우, RTK를 추가하세요:

• 워크플로가 쉘 (shell) 중심으로 강력하게 구동되는 경우
• 가공되지 않은 명령 출력 (raw command output)으로 인한 토큰 소모 (token burn)가 여전히 유의미한 경우
• 팀이 훅 거버넌스 (hook governance)를 다루는 데 익숙한 경우
• 내장 도구들이 여전히 Bash 훅 경로를 우회한다는 점을 수용할 수 있는 경우 (2)

다음과 같은 경우, 아직 RTK를 추가하지 마세요:

• 팀이 주로 Claude Code의 내장 도구에 의존하는 경우
• 운영 모델이 아직 미성숙한 경우
• 훅 (hooks), 관리되는 설정 (managed settings), 또는 워크플로 표준을 담당하는 주체가 없는 경우
• 명령 재작성 (command rewriting)으로 워크플로 설계 문제를 해결하려 하는 경우

핵심 요약 (Key Takeaways)

• Anthropic은 프롬프트 캐싱 (prompt caching), 자동 압축 (auto-compaction), 컨텍스트 관리 (context management), 모델 선택 (model choice), MCP 감소 (MCP reduction), 스킬 (skills), 그리고 서브에이전트 (subagents)를 포함하여 Claude Code의 비용과 컨텍스트 확산 (context sprawl)을 줄일 수 있는 여러 가지 네이티브 방식을 이미 제공하고 있습니다. (1)
• RTK는 유용하지만, 쉘 중심의 토큰 비효율성이라는 더 좁은 문제를 해결합니다.
• RTK의 Bash 훅은 Read, Grep, Glob과 같은 Claude Code 내장 도구를 가로채지 못합니다. (2)
• 대부분의 팀은 또 다른 훅 기반 레이어를 도입하기 전에 Claude Code의 네이티브 동작을 먼저 최적화해야 합니다.
• 올바른 도입 순서는 일반적으로 네이티브 제어 (native controls)를 먼저, RTK를 두 번째로 하는 것입니다.

FAQ

Claude Code는 이미 자체적으로 토큰 사용량을 최적화하나요?

네, 그렇습니다. Anthropic에 따르면 Claude Code는 이미 프롬프트 캐싱 (Prompt Caching)과 자동 압축 (Auto-compaction)을 사용하고 있으며, 선제적인 컨텍스트 관리 (Context Management), 모델 선택, MCP 오버헤드 감소, 스킬 (Skills), 서브에이전트 (Subagents), 그리고 전처리 훅 (Preprocessing Hooks)과 같은 추가적인 비용 제어 방법을 권장합니다. (1)

Claude Code 내부에서 무엇을 가장 먼저 최적화해야 하나요?

컨텍스트 위생 (Context Hygiene), 모델 선택, MCP 규율, 그리고 워크플로우 패키징 (Workflow Packaging)부터 시작하세요. Anthropic의 자체 비용 가이드에서도 제3자 도구를 도입하기 전에 이러한 레버(Levers)들을 먼저 지목하고 있습니다. (1)

CLAUDE.md에 더 많은 내용을 채워 넣는 것의 가장 강력한 네이티브 대안은 무엇인가요?

스킬 (Skills)과 커스텀 명령 (Custom Commands)입니다. Anthropic은 CLAUDE.md에 있는 지침을 스킬로 옮길 것을 권장하며, 반복 가능한 워크플로우를 위한 공유 커스텀 명령을 지원합니다. (1)

최적화에 있어 서브에이전트 (Subagents)가 왜 중요한가요?

Anthropic은 서브에이전트가 자체적인 컨텍스트 윈도우 (Context Windows)에서 실행되며, 고유한 도구 액세스 및 권한을 가질 수 있고, 좁은 범위의 작업을 더 저렴한 모델로 라우팅함으로써 비용을 제어하는 데 도움이 된다고 설명합니다. (3)

RTK가 도입할 가치가 생기는 시점은 언제인가요?

팀이 이미 Claude Code 사용에 숙련되어 있고, 토큰 낭비의 상당 부분이 Bash를 통해 흐르는 셸 중심 (Shell-heavy) 워크플로우에서 발생할 때입니다. (2)

Claude Code에서 RTK의 가장 큰 한계는 무엇인가요?

RTK 자체 문서에 따르면, RTK의 훅 (Hook)은 Bash 도구 호출 시에만 실행되는 반면, Read, Grep, Glob과 같은 Claude Code 내장 도구들은 자동으로 재작성(Rewritten)되지 않습니다. (2)

추가 읽을거리

• Should You Standardize RTK for Claude Code Yet?
• Claude Code Security in 2026: Hooks, Fake Installers, and What You Must Lock Down First
• What CTOs Should Standardize First in an AI Dev Stack
• Why Most AI Coding Rollouts Fail Before the Model Does

작성자: Dr. Hernani Costa | 제공: Core Ventures

원문 게시처: First AI Movers.

기술은 쉽습니다. 하지만 기술을 손익계산서(P&L)에 매핑하는 것은 어렵습니다. First AI Movers에서 우리는 단순히 코드를 작성하는 것에 그치지 않고, EU 중소기업(SMEs)을 위한 '경영 신경계 (Executive Nervous System)'를 구축합니다.

귀하의 아키텍처는 기술 부채 (Technical Debt)를 만들고 있습니까, 아니면 비즈니스 자산 (Business Equity)을 만들고 있습니까?

👉 AI 준비도 점수 확인하기 (무료 기업 진단)

참고 문헌