Claude Code로 Claude Code 효율화 도구를 만든 55시간 — contextzip 빌드 리포트

npm install 출력이 150줄이다. Docker 로그가 300줄. Rust 빌드 에러가 80줄. 이게 다 컨텍스트 윈도우를 채운다.

Claude가 이전 코드를 까먹는다. 컨텍스트가 노이즈로 가득 차 있으니까.

그래서 만들었다. CLI 출력을 자동으로 압축하는 도구, contextzip. 아이러니하게도 Claude Code로.

TL;DR RTK를 포크해서 contextzip을 만들었다. 서브에이전트 62번, 405 tool call, 55시간. npm install 150줄이 3줄로. cargo build 에러 80줄이 핵심 5줄로. NPM까지 배포했다.

스펙 하나를 던졌더니 질문이 먼저 왔다

프로젝트 소재는 RTK였다. Claude Code용 CLI 압축 오픈소스. 포크 후 리네이밍해서 contextzip으로 만들면 됐다. 스펙 파일을 Claude에 던졌다.

그런데 브레인스토밍 스킬이 먼저 발동됐다. Claude가 질문을 세 개 던진다.

“레포 이름이 tokenzip인데, 바이너리 이름은 뭘로 통일할 건가요?”

“RTK를 소스 포크할 건가요, dependency로 쓸 건가요?”

“전체를 한 번에 가는 게 맞나요, 주 단위로 끊어가는 게 맞나요?”

평소 같으면 그냥 달려들었을 텐데, 이 질문들이 앞에 꺼내놓이니 생각이 정리됐다. 이름은 레포/바이너리/crate 전부 contextzip으로 통일, RTK 소스 풀 포크, Week 단위 검증 게이트.

이 3분짜리 브레인스토밍이 이후 55시간의 방향을 잡았다. Claude가 “어떻게 구현할지”가 아니라 “무엇을 결정해야 하는지”를 먼저 꺼낸다는 게 핵심이다. 내가 결정하지 않으면 Claude도 모른다.

브레인스토밍 다음은 플랜. Claude가 Week 1부터 Week 3까지, Task 단위로 쪼갠 구현 계획을 만들었다. Task 16개. 각 Task에 구현 파일, 검증 방법, 예상 커밋 메시지까지.

“전체를 한 번에 갈건데 각 week 끝나고 작업에 대한 검증 / 수정 / 확인 후 다음 week로 넘어가줘”

이 프롬프트 하나로 주간 검증 게이트가 생겼다. Week 1 끝나면 멈추고 확인. 이상 없으면 Week 2. 단순한 지시처럼 보이지만 이게 없으면 55시간이 방향 없이 흘렀을 가능성이 높다.

에이전트 62번이 일하는 동안 나는 뭘 했나

플랜이 나오자 서브에이전트 드리븐 개발 스킬이 발동됐다. Claude가 태스크를 병렬로 에이전트에 나눠 분배하기 시작했다.

실제 진행 방식은 이랬다. Task 4(LICENSE 업데이트), Task 6(install.sh 작성), Task 7(GitHub Actions CI/CD)이 동시에 시작된다. 각 에이전트가 완료 알림을 보내면 Claude가 다음 배치를 시작한다. 파일 수정이 겹치지 않는 독립 태스크는 전부 병렬로 돌린다.

Task 4 에이전트가 “RTK attribution을 LICENSE에 추가하고 커밋 완료”를 보고하는 데 걸린 시간이 15분이었다. 내가 직접 했다면 LICENSE 파일 찾고, RTK 원본 라이선스 읽고, 어떻게 표기할지 고민하는 것만 1시간이었을 거다.

55시간 세션에서 Agent 도구 호출이 62번이었다. Bash가 176번으로 가장 많았는데 이건 주로 빌드, 테스트, 검증이다. 에이전트들이 구현하면 Claude가 직접 실행해서 확인하는 구조. Read 37번, Edit 28번. 반면 내가 직접 입력한 프롬프트는 세션 내내 80개 남짓이었다.

에이전트들이 일하는 동안 나는 결과를 보고 다음 결정을 내렸다. “이름 통일 맞아?”, “Week 2로 넘어가”, “냉정하게 전체 검증해줘”. 내 역할이 구현자에서 의사결정자로 바뀐 세션이었다.

이름 통일은 생각보다 깊은 곳에 있었다

RTK → contextzip 리네이밍이 완벽하게 됐다고 생각했다. Week 3 후반, QA 에이전트가 직접 바이너리를 실행해서 출력을 확인했다.

contextzip 0.1.0 (based on rtk 0.30.1)

바이너리 이름은 바꿨지만, 버전 문자열 안에 rtk가 하드코딩되어 있었다. 소스 코드 검색으로는 쉽게 잡히지 않는 위치였다.

에이전트가 실제로 명령을 실행해서 출력을 눈으로 확인했기 때문에 잡을 수 있었다. 코드 리뷰만으로는 놓쳤을 이슈다. 이게 QA 에이전트를 따로 쓰는 이유다. “읽는” 에이전트와 “실행해서 보는” 에이전트는 다르다.

그 외에도 Java 스택트레이스를 압축할 때 savings가 음수로 나오는 버그가 있었다. 원본보다 압축 결과가 더 긴 케이스. 정규식이 Java 프레임워크 라인을 너무 좁게 잡아서 핵심 라인까지 날려버린 게 원인이었다. Rust panic 파싱도 마찬가지였다. 정규식이 표준 패닉 포맷만 커버하고, 스레드 이름이 붙은 변형 케이스를 놓쳤다.

프롬프트는 단순했다. “여기서는 token을 줄이고 노이즈 줄이는 작업이야. 어떤 거 했어? 다 완료했어?” 이 질문이 Claude로 하여금 기능 목록이 아니라 실제 동작 여부를 점검하게 만들었다. “어떤 거 구현했어?”와 “다 완료했어?”는 다른 질문이다.

4개 역할 에이전트 동시 감사

구현 마무리 단계에서 냉정한 평가가 필요했다.

“지금 작업에 대해 객관적으로 평가해주고 모든 코드 모든 기능에 대해 냉정하게 피드백해줘. 상품화를 할 수 있는 레벨 기준으로”

Claude가 에이전트 4개를 동시에 고용했다.

PM 에이전트는 시장 준비도를 감사했다. Value proposition이 모호하다, “contextzip이 왜 RTK보다 나은지” 설명이 없다, RTK 잔재가 아직 남아있다는 P0 이슈가 나왔다.

시니어 엔지니어 에이전트는 코드 품질을 봤다. 1,049개 테스트 전부 통과지만 #[allow(dead_code)] 어노테이션이 build_cmd.rs, error_cmd.rs 등 여러 곳에 남아있다고 지적했다. 릴리스 전에 정리해야 할 기술 부채.

UX/README 에이전트는 문서가 실제 기능과 불일치하는 부분을 찾았다. README에 있는 절약 수치가 실제 테스트 결과와 다른 경우가 있었다. “팩트 기반으로 README를 재작성해야 한다”는 결론.

QA 에이전트는 end-to-end 테스트를 직접 돌렸다. 위에서 말한 --version 이슈가 여기서 잡혔다.

4개 리포트가 동시에 올라왔다. P0부터 순서대로 수정 에이전트를 다시 투입했다. 혼자 리뷰했다면 1~2개 관점에서만 봤을 거다. 4개 역할로 동시에 보니 코드, 문서, 마케팅, QA 사각지대가 한 번에 드러났다.

100개 테스트 케이스 기반 성능 검증도 이 단계에서 했다. 에이전트가 케이스를 만들고 실행하고 결과를 집계했다. 실제 숫자가 나오니 README에 인용할 수 있었다.

NPM으로 배포하는 Rust 바이너리

Rust 바이너리를 npx contextzip 한 줄로 설치하는 게 목표였다. 개발자라면 Rust 툴체인 없이도 쓸 수 있어야 한다.

NPM 패키지로 래핑하는 방식을 썼다. bin/install.js가 OS와 아키텍처를 감지해서 맞는 사전 빌드 바이너리를 받아온다. Mac ARM, Mac x86, Linux 각각. Windows는 에이전트가 확인해보니 지원이 어렵다고 판단해서 일단 제외했다.

GitHub Actions는 에이전트가 처음부터 만들었다. push/PR 시 자동 테스트 실행, 릴리스 태그(v*) 시 각 플랫폼용 바이너리 빌드 후 GitHub Releases에 업로드. NPM 패키지는 그 릴리스 바이너리를 내려받는 구조.

NPM 토큰을 발급받고 에이전트에 던졌다. CI가 자동으로 npm publish를 트리거하는 파이프라인이 완성됐다. 이 흐름을 처음부터 설계하고 구현하는 데 에이전트 없이 혼자 했다면 반나절은 걸렸을 테지만, 에이전트가 CI 파일까지 작성하고 커밋했다.

홍보 자동화, 그리고 막힌 벽

구현이 끝나자 문제가 바뀌었다. 이제 어떻게 알리냐.

Claude가 Reddit r/claudeai, r/rust용 포스트를 만들었다. HN 제출용 텍스트도. DEV.to 블로그 글도. 그리고 GitHub Actions로 매일 자동 홍보하는 워크플로우도.

Awesome Claude Code 리스트에 PR을 자동으로 올리려고 했다. 에이전트가 시도했고, 바로 막혔다. 해당 레포 CONTRIBUTING 문서에 “gh CLI 제출 금지, 자동으로 닫힌다”고 명시되어 있었다. 에이전트가 규칙을 읽고 “수동으로 올려야 한다”고 보고했다. 브루트포스를 시도하지 않고 멈춘 게 맞는 판단이었다.

X(트위터) 자동화도 막혔다. 계정 신규 생성 후 일정 기간 API 제한이 걸린다. 이건 우회할 방법이 없다. 직접 올려야 했다.

Reddit도 신규 계정이라 자동 발행이 안 됐다. 에이전트가 각 플랫폼별 포스트 텍스트를 만들고 복붙할 수 있게 준비해뒀다. 내가 직접 올리는 건 5분짜리 작업이 됐다.

자동화할 수 있는 건 자동화하고, 막힌 건 막혔다고 보고하고, 대안을 준비한다. Claude가 이 판단을 잘한다.

reddit에 올라갔더니 첫 번째 댓글이

그리고 contextzip을 claude가 공식 hook으로 이미 사용한다는 걸 아는가, 이런 피드백도 나왔다. 아직 스타 수는 적지만 “이게 실제로 어디서 쓰이냐”는 질문이 이미 들어왔다.

Claude Code hook 설정과 연동해서 git 명령, cargo 명령, npm 명령 출력을 자동으로 압축하는 흐름을 README에 더 명확하게 써야 했다. 에이전트가 README를 다시 썼다.

README는 이 프로젝트에서 가장 많이 고쳐진 파일이다. 에이전트가 쓰고, 검토하고, 다시 쓰고. 영어 기본에 10개 이상 언어 번역본도 추가했다. 한국어, 일본어, 중국어, 독일어, 프랑스어, 스페인어, 포르투갈어, 러시아어. 언어 사용자 수 순서로.

결국 README는 마케팅 문서다. “5초 만에 설치, 즉시 효과”가 보이게 쓰는 게 핵심이라는 걸 이번에 배웠다.

이 세션에서 Claude Code를 어떻게 썼는지

55시간에 걸쳐 쌓인 것들을 정리해보면, 몇 가지 패턴이 보인다.

브레인스토밍 스킬은 “어떻게 구현할지”가 아니라 “무엇을 결정해야 하는지”를 앞에 꺼낸다. 이 3분이 이후 시간 전체의 방향을 잡는다.

플랜 스킬은 Week 단위로 쪼갠 계획을 만들고, “한 week 끝나면 검증”이라는 지시 하나가 중간 검증 게이트를 자동으로 만든다. 계획이 없으면 55시간이 목적지 없이 흐른다.

서브에이전트는 독립 태스크를 병렬로 돌린다. 파일이 겹치지 않는 작업은 전부 동시에. 이게 속도의 핵심이다.

4개 역할 동시 감사는 코드, 문서, 마케팅, QA를 한 번에 보게 한다. 혼자 리뷰하면 1~2개 관점에서만 본다.

그리고 프롬프트. “어떤 거 했어? 다 완료했어?”는 기능 목록이 아니라 실제 동작 여부를 묻는다. 이 차이가 QA 품질을 만든다.

세션 통계는 405 tool call에 62 에이전트 호출이다. 내가 직접 쓴 프롬프트는 80개 남짓. 나머지는 에이전트들이 일했다.

혼자 Rust로 이 스코프를 구현했다면 2주는 걸렸을 거다. 55시간이 길게 느껴지지만, 6개 신규 모듈과 1,056개 테스트와 NPM 배포와 다국어 README까지 포함하면 그렇지 않다.

Claude Code로 도구를 만들고, 그 도구로 Claude Code를 더 잘 쓴다. 이 루프가 지금도 작아지고 있다.