TL;DR

  • 토큰이 늘 모자라서 Claude Code 플러그인 ponytail과 graphify를 내 개인 일정 관리 레포에 써봤다.
  • ponytail-audit은 고칠 점을 많이 찾아 줬고 수정도 잘됐다. 그런데 그 뒤로 토큰이 얼마나 줄었는지는 체감하지 못했다.
  • ponytail의 규칙은 "토큰을 가장 적게"가 아니라 "기존 코드를 활용해 가장 작은 변경으로"였다. 그래서 마음에 들지 않던 구조도 그대로 남았다.
  • graphify는 graphify-out/에 문서와 그래프를 만들어 줘서 레포를 훑어보기는 편해졌다. 다만 내가 원했던 건 코드 개선이었고, 토큰 체감은 아직 없다.
  • 세션 로그를 집계해 보니 사용량의 97%가 다시 읽는 맥락(cache_read)이었고, 설치 후에도 응답당 사용량은 거의 그대로였다. 토큰을 줄이려면 AI가 쓰는 코드보다 AI가 읽는 맥락을 줄여야 한다.

ponytail은 Claude Code 토큰을 줄여 주는 도구인가요?

직접 써보니 ponytail은 토큰 절약 도구라기보다 코드를 덜, 더 잘 짜게 돕는 도구였다. 처음에는 "AI가 코드를 짧게 쓰면 토큰도 줄겠지"라고 기대하고 설치했다.

ponytail을 켜면 Claude Code가 "게으른 시니어 개발자"처럼 움직인다. 새 코드를 쓰기 전에 아래 순서로 먼저 따져 본다.

  1. 이게 정말 필요한가?
  2. 이 코드베이스에 이미 있는 헬퍼·컴포넌트·패턴인가?
  3. 표준 라이브러리나 플랫폼 기능으로 되는가?
  4. 이미 설치된 의존성으로 되는가?
  5. 한 줄로 끝나는가?
  6. 그래도 안 되면 동작하는 최소한의 코드를 쓴다.

목록을 읽고 나서야 이해했다. 이 규칙의 목표는 토큰이 아니라 새 코드의 양이다. 기존 코드를 최대한 재사용하고 불필요한 추상화를 만들지 않는 데 초점이 있다. 토큰이 줄어드는 건 부수 효과일 뿐이다.

ponytail-audit은 무엇을 찾아 줬나요?

ponytail-audit은 레포 전체를 훑어서 버그, 보안 구멍, 테스트 없는 위험한 코드, 지워도 되는 코드를 순위별 보고서로 정리해 준다. 보고서만 만들고 코드는 바꾸지 않는다. 그래서 수정은 따로 요청해야 한다.

대상은 회사 코드가 아니라 내가 개인 일정 관리용으로 쓰는 레포였다. 생각보다 지적이 많이 나왔고, 하나씩 고쳐 달라고 하니 수정도 깔끔하게 끝났다.

ponytail은 왜 마음에 안 드는 구조를 그대로 두었나요?

ponytail 규칙에 "코드베이스가 이미 가진 구조(계층, 인터페이스, 컨벤션)를 유지한다"가 들어 있기 때문이다. audit 결과를 고칠 때도 파일 구조는 그대로였다.

사실 그 구조는 내가 애초에 짠 것이라 마음에 들지 않았다. 파일 이름 앞에 숫자를 붙여 두고 그 숫자 순서대로 흘러가야 한다는 식의 구조였다. 고칠 기회라고 생각했지만 ponytail은 "구조를 바꾸는 건 요청받지 않은 범위"로 보고 손대지 않았다. 나도 결국 구조는 그대로 두었다.

돌아보면 이건 ponytail이 잘못한 게 아니다. 구조를 갈아엎고 싶다면 그건 따로 요청해야 하는 별도 작업이다. ponytail은 기존 구조 안에서 가장 작은 변경을 고르도록 설계된 도구다.

graphify를 쓰면 무엇이 달라지나요?

graphify는 코드와 문서를 지식 그래프(knowledge graph)로 바꿔서 graphify-out/ 폴더에 결과를 남긴다. 파일 간 연결, 핵심 노드, 모듈 묶음을 문서로 보여 준다.

일정 관리 레포에 돌려 보니 노드 566개, 엣지 989개짜리 그래프가 나왔다. 그래프를 만드는 데는 입력 토큰 약 16만 5,000개가 한 번 들었다. 문서가 쏟아져 나와서 뭔가 되고 있다는 느낌이 확실히 들었다. 레포 구조를 파악할 때는 코드를 직접 여는 것보다 graphify-out/ 결과를 보는 쪽이 더 편했다.

그런데 써보면서 깨달은 게 있다. 내가 원했던 건 코드 개선이었다. "코드가 좋아지면 AI가 읽을 양이 줄고, 그러면 토큰도 알아서 줄겠지"라고 생각했다. graphify는 코드를 바꾸지 않는다. 이미 있는 코드를 연결해서 보여 줄 뿐이다. 연결을 보여 주는 건 좋지만, 그게 곧바로 토큰 감소로 이어지지는 않았다.

Claude Code 토큰 사용량은 어떻게 계산하나요?

Claude Code는 응답마다 토큰 수를 세션 로그 ~/.claude/projects/<레포>/<세션>.jsonl에 남긴다. 이 값을 합산하면 실제 사용량이 나온다. 응답 한 줄에는 아래처럼 기록된다.

"usage": {"input_tokens": 2, "cache_creation_input_tokens": 35388, "cache_read_input_tokens": 28086, "output_tokens": 206}
  • input_tokens, cache_creation_input_tokens: 새로 읽힌 입력이다. 캐시에 새로 쓰인 양도 여기에 들어간다.
  • cache_read_input_tokens: 캐시에서 다시 읽은 맥락이다. 대화 기록, 파일, 시스템 프롬프트가 여기에 해당한다.
  • output_tokens: AI가 쓴 답과 코드다.

간단히 보려면 Claude Code 안에서 /usage로 구독 한도 사용률을 확인하면 된다. 일별 합계는 로그를 읽는 ccusage로 볼 수 있다. 나는 같은 로그를 직접 집계했다. 하나의 응답이 로그에 여러 줄로 남는 경우가 있어서 message.id와 requestId가 같은 줄은 하나로 셌다.

ponytail·graphify 설치 전후로 토큰이 줄었을까?

숫자로 봐도 거의 그대로였다. ponytail은 11월 6일 오전 10시 28분에, graphify는 10시 59분에 처음 설치했다. 최근 2주 로그(응답 2,301건)를 ponytail 설치 시각 기준으로 나눠 보았다.

구간 응답 수 응답당 output 응답당 cache_read 응답당 input+cache_write
설치 전 (10/23 ~ 11/6 10:28) 1,876 718 140K 3.8K
설치 후 (11/6 10:28 ~ 16:00) 425 746 (+4%) 137K (−2%) 2.8K (−26%)

새로 읽는 입력(input+cache_write)은 26% 줄었다. 하지만 이 항목은 전체 사용량의 2.5%밖에 되지 않는다. 사용량 대부분을 차지하는 cache_read는 2% 줄어드는 데 그쳤다. 일별로 봐도 응답당 cache_read는 129K169K, output은 600890 사이에서 오르내릴 뿐이다. 설치 시점을 기준으로 꺾이는 구간은 없었다.

같은 레포끼리 비교하면 어떨까?

레포마다 작업 성격이 달라서, 설치 전후에 모두 작업한 레포만 따로 나눠 보았다. 여기서 맥락은 cache_read, input, cache_write를 합친 값이다.

레포 응답 수 (전 → 후) 응답당 맥락 응답당 output
개인 일정 관리 (audit·graphify 대상) 153 → 105 175K → 160K (−9%) 1,122 → 921 (−18%)
개인 배포 자동화 204 → 114 148K → 128K (−14%) 812 → 645 (−21%)
테스트 도구 568 → 112 134K → 156K (+16%) 713 → 764 (+7%)

ponytail-audit과 graphify를 직접 돌린 일정 관리 레포에서는 맥락이 9%, output이 18% 줄었다. 반대로 테스트 도구 레포는 오히려 16% 늘었다. 전체로 합치면 이런 증감이 서로 상쇄되어 −2%가 된다.

같은 로그를 다른 세션에서 사용자 턴 단위로 일찍 집계했을 때는 턴당 총 토큰이 794K에서 626K로 21% 줄어 보였다. 다만 그때 설치 후 표본은 30턴(5세션)뿐이었고, 대부분 노트 정리 같은 가벼운 작업이었다. 어떻게 자르느냐에 따라 −21%부터 +16%까지 나온다는 것 자체가 아직 효과를 판단할 수 없다는 뜻이다.

이 비교만으로 결론을 내릴 수는 없다. 설치 후 데이터는 반나절치뿐이고, 같은 작업을 놓고 비교한 값도 아니다.

왜 토큰이 줄었다는 체감이 없을까?

체감이 없는 가장 큰 이유는 사용량의 거의 전부가 "다시 읽는 맥락"이기 때문이다. 2주 동안 쓴 약 3억 3,000만 토큰 중 97%가 cache_read였다. 새로 읽는 입력은 2.5%, output은 0.5%였다.

  • ponytail이 줄이는 건 output 쪽이다. 코드를 덜 쓰게 해도 전체의 0.5%에서 줄어드는 것이라 사용량 그래프에서는 보이지 않는다.
  • graphify가 효과가 있다면 cache_read나 input이 줄어야 한다. 그래프를 만든 일정 관리 레포에서는 맥락이 9% 줄었지만, 전체 사용량에서 보일 만큼은 아니다.
  • 멀티레포 작업이 사용량을 키운다. 사용량이 가장 많았던 두 날, 11월 5일(약 6,200만)과 6일(약 6,800만)은 모두 하루에 레포 6개를 오간 날이다. 레포를 한두 개만 쓴 날은 1,800만~4,000만 수준이었다. 레포를 옮길 때마다 맥락을 처음부터 다시 읽는다.

결국 토큰을 줄이려면 AI가 쓰는 코드보다 AI가 읽는 맥락을 줄여야 한다. 내가 고른 두 도구는 애초에 그 지점을 겨냥한 도구가 아니었다.

결과 / 회고

도구 기대한 것 실제로 해 준 것 토큰 체감
ponytail 토큰 절약 기존 코드를 재사용해 작게 고치기, audit 보고서 아직 없음
graphify 코드 개선 → 토큰 절약 레포 구조를 문서와 그래프로 정리 아직 없음

두 도구 모두 나쁘지 않았다. ponytail은 코드를 더 잘 짜게 돕는 도구였고, graphify는 레포를 훑어보기 편하게 해 줬다. 다만 내가 처음 기대한 "토큰이 확 줄어드는 경험"은 아직 없다.

계속 쓰다 보면 체감이 오지 않을까 싶다. 그래도 이제는 감이 아니라 숫자로 확인할 수 있다. 다음에는 같은 작업을 도구를 켠 상태와 끈 상태로 돌려 cache_read와 output을 따로 비교해 볼 생각이다. 마음에 들지 않던 숫자 접두사 파일 구조는 ponytail에 맡기지 않고 별도 작업으로 정리할 계획이다.

AI가 짠 코드와 내 코드를 비교한 경험은 AI와 코딩 대결에서 20줄짜리 내 코드가 진 이유에, 일정 관리 방식은 AI로 일하니 모든 일이 딥워크가 됐다에 정리했다.

참고