Claude Code를 팀에 실제로 정착시키는 법

Claude Code를 팀에 실제로 정착시키는 법

RTK 토큰 절약과 CLAUDE.md 구조 개선—두 가지 실전 최적화가 가리키는 하나의 결론: AI 코딩 어시스턴트의 성패는 모델이 아니라 운영 설계에 달려 있다.

Claude Code RTK 토큰 절약 CLAUDE.md 에이전트 엔지니어링 컨텍스트 최적화 AI 코딩 어시스턴트 Harness Engineering
광고

Claude Code를 팀에 도입했는데 생각보다 비용이 빠르게 불어난다면, 혹은 에이전트가 엉뚱한 판단을 반복한다면—그건 모델 문제가 아닐 가능성이 높다. 두 가지 흐름이 동시에 같은 지점을 가리키고 있다. 컨텍스트에 뭘 넣느냐, 그리고 지침 문서를 어떻게 설계하느냐. 이 두 가지가 Claude Code 운영의 실질적인 변수다.

토큰은 모델이 낭비하는 게 아니라 구조가 낭비한다

velog에 올라온 RTK 실전 적용기를 보면 문제가 선명하게 드러난다. Claude Code로 작업하다 보면 cargo testgit log 같은 명령 결과가 통째로 에이전트 컨텍스트에 쌓인다. 통과한 테스트 200개 목록이 다 올라가는데, 정작 Claude에게 필요한 정보는 "뭐가 실패했는지" 한 줄뿐이다. 이건 모델의 비효율이 아니라 구조의 비효율이다.

RTK(Rust Token Killer)는 이 문제를 CLI 프록시 방식으로 파고든다. 명령을 가짜로 실행하거나 스킵하는 게 아니라, 실제로 실행한 뒤 결과를 압축해서 넘긴다. 공식 저장소 기준 30분 세션에서 11.8만 토큰이 2.4만 토큰으로 줄었다고 한다. 테스트류는 90% 이상, git statusdiff는 60~80% 수준이다. 실제 적용기에서도 git status 단일 명령으로 입력 110토큰이 38토큰으로 줄어 65.5% 절감이 확인됐다.

다만 무작정 전역 적용하기 전에 짚어야 할 지점이 있다. RTK는 결과를 요약하는 도구이기 때문에, 압축 과정에서 에이전트가 판단 근거로 쓰는 맥락이 잘려나갈 수 있다. 해당 적용기에서도 git log 압축 시 "다음 단계: threshold tuning 남음" 같은 커밋 본문 맥락이 사라지면서, 아직 안 끝난 작업을 완료로 잘못 판단할 위험이 생겼다. 해법은 명령별로 전략을 나누는 것이다. 평소엔 압축된 버전으로 토큰을 아끼되, 판단이 중요한 순간에는 rtk proxy git log로 원본을 그대로 열어보는 식이다. exclude_commands 전역 설정보다 유연하고, 실제로 일부 버전에서 해당 설정의 버그도 보고돼 있어 현시점에서는 더 안전한 선택이다.

운영 리스크도 확인하고 들어가야 한다. curl 헤더에 Bearer 토큰이 포함된 명령을 rtk가 가로채면 그 값이 평문으로 로그에 남는다. 팀 환경에서 쓴다면 민감한 명령을 exclude하거나, 텔레메트리를 rtk telemetry disable로 끄는 설정을 온보딩 체크리스트에 넣어야 한다. 설치 과정에서도 crates.io에 동명의 무관한 패키지가 있어 cargo install rtk가 아닌 GitHub 릴리스에서 직접 받아야 한다. Windows 환경에서는 훅 자동 설치가 완전하지 않아 CLAUDE.md 지시문 방식으로만 동작하는 점도 팀 표준화 전에 확인이 필요하다.

CLAUDE.md는 지침서가 아니라 에이전트 계약서다

두 번째 흐름은 CLAUDE.md 설계 문제다. velog의 CLAUDE.md 개선기는 AI가 생성해준 지침 문서를 그대로 쓰다 생긴 문제를 솔직하게 드러낸다. 프로젝트가 커질수록 CLAUDE.md는 길어지고, skill.md·convention.md 같은 문서도 늘어나는데—문제는 이 문서들이 코드에서 읽을 수 있는 정보를 중복해서 담고 있다는 점이다. 처음엔 토큰 낭비로 끝나지만, 진짜 문제는 코드 로직이 바뀔 때 문서는 그대로 남아 에이전트가 "코드"와 "지침" 중 뭘 믿어야 할지 모르는 상황이 생기는 것이다.

개선 방향은 단순하다. CLAUDE.md에 넣어야 할 정보는 "작업 내내 반복적으로 참조되어야 하고, 코드만 봐서는 알 수 없는 의도나 제약"이어야 한다. 코드에서 읽을 수 있는 기술 스택 목록, 폴더 구조, 빌드 방법 같은 정보는 덜어내야 한다. 기획서 링크처럼 "여기 참고 문서 있음"이라는 안내성 문장도 실행 지침이 아니다. "README.md가 바뀔 만한 수정을 하면 README도 함께 갱신할 것"처럼, 에이전트가 작업 중에 행동으로 연결할 수 있는 문장으로 바꿔야 한다.

이 원칙은 결국 한 가지로 수렴한다. 같은 정보를 두 문서에 각각 다른 표현으로 중복 서술하지 않는 것. 갱신 대상이 하나로 수렴하면 "고치면 같이 갱신해라"는 규칙 자체가 필요 없어진다. CLAUDE.md를 AI가 뽑아준 초안 그대로 쓰는 팀이라면, 지금 당장 한 번은 직접 뜯어봐야 한다.

팀 단위로 적용하려면

두 흐름이 가리키는 시사점은 같다. Claude Code 운영 최적화는 모델 선택이나 프롬프트 한 줄의 문제가 아니라, 컨텍스트 파이프라인과 지침 문서를 어떻게 설계하느냐의 문제다. RTK는 에이전트가 소비하는 컨텍스트를 통제하는 구조이고, CLAUDE.md 정제는 에이전트가 판단 근거로 삼는 정보의 신뢰도를 높이는 작업이다. 둘 다 "AI가 더 잘하도록" 모델을 건드리는 게 아니라, 에이전트 주변 시스템을 설계하는 일이다.

팀에 Claude Code를 정착시키려 한다면 우선순위가 있다. 먼저 CLAUDE.md를 직접 감사하라. AI가 생성한 초안에는 중복, 안내성 문장, 코드에서 이미 읽을 수 있는 정보가 섞여 있을 가능성이 높다. 그 다음 RTK 같은 컨텍스트 압축 레이어를 도입하되, 명령별로 압축 전략을 달리하는 규칙을 팀 지침에 명시하라. 보안 민감 명령 처리 방식과 텔레메트리 설정은 온보딩 체크리스트에 고정하는 것이 좋다. 도구를 쓰는 게 아니라 에이전트 운영 구조를 설계하는 것—이게 Claude Code를 팀 워크플로우에 실제로 심는 방법이다.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요