AI 토큰 다이어트: Codex·Claude·OpenClaw에 3중 절약 구조를 설치했다

# AI 토큰 다이어트: Codex·Claude·OpenClaw에 3중 절약 구조를 설치했다

## 📝 한줄 요약

장시간 AI 업무에서 컨텍스트가 빠르게 차고 토큰 비용이 커지는 문제를 줄이기 위해, Codex·Claude Code·OpenClaw에 RTK·Caveman·Headroom을 연결했다. 설치로 끝내지 않고 새 업무부터 자동 적용되는 구조와 실제 연결 상태까지 검증했다.

**바쁘시면 이것만 읽어도 돼요:**
- RTK는 명령 출력을 줄이고, Caveman은 답변의 군더더기를 줄이며, Headroom은 모델에 전달되는 컨텍스트를 압축한다.
- 세 도구를 함께 사용해 출력·응답·컨텍스트를 서로 다른 단계에서 절약했다.
- RTK 첫 로컬 테스트에서 출력 토큰이 **25개에서 12개로 줄어 52% 절감**됐다.
- Codex·Claude Code·OpenClaw의 새 업무에서 자동 적용되도록 전역 설정까지 연결했다.
- 유명한 도구라도 공식 저장소, 체크섬, 텔레메트리, Windows 호환성을 검증해야 한다.
- 설치 완료 메시지보다 실제 플러그인·MCP·프록시 연결 상태 확인이 더 중요했다.

## 🎯 이런 분들께 도움돼요

- AI를 오래 사용하면 컨텍스트가 빨리 차는 비개발자·PM
- Codex·Claude Code·OpenClaw를 함께 사용하는 실무자
- 토큰 비용은 줄이고 싶지만 설치 명령이나 설정 파일이 부담스러운 사람
- 개인별 설정을 팀 공통 운영 체계로 확장하려는 PMO·리더

## 😫 문제 상황 (Before)

AI와 짧게 대화할 때는 토큰이 크게 신경 쓰이지 않았다. 문제는 업무가 길어질 때였다. 조사 결과, 파일 내용, 명령 출력, 오류 로그가 차곡차곡 쌓이면서 컨텍스트가 빠르게 커졌다. 대화가 길어지면 앞선 맥락을 압축하거나 새 세션으로 옮겨야 했고, 그 과정에서 다시 설명해야 하는 일도 생겼다.

특히 한 가지 AI만 쓰는 환경이 아니었다. Codex, Claude Code, OpenClaw를 업무 성격에 따라 번갈아 사용하니, 도구마다 토큰을 아끼는 방법도 달랐다. 매번 “짧게 답해줘”, “로그를 요약해줘”라고 지시하는 방식으로는 일관성이 없었다.

그래서 목표를 바꿨다. 사람이 매번 절약을 요청하는 것이 아니라, **AI가 새 업무를 시작하는 순간부터 토큰 효율 구조를 자동으로 불러오게 하자**고 정했다.

## 🛠️ 사용한 도구

- **Hermes Agent:** 공식 자료 조사, 설치, 설정 병합, 상태 검증
- **RTK:** Git·테스트·빌드 등 명령 출력 압축
- **Caveman:** 기술 내용은 유지하면서 응답 표현을 간결하게 만드는 스킬
- **Headroom:** 도구 출력·로그·코드·대화 컨텍스트를 모델 전송 전에 압축하고 필요 시 복원
- **대상 에이전트:** Codex, Claude Code, OpenClaw
- **환경:** Windows 10

---

## 🔧 작업 과정

### 먼저, “유명해 보이는 RTK”가 아니라 공식 RTK를 찾았다

RTK라는 이름은 여러 분야에서 사용된다. 위치 측정 기술, 개발 라이브러리, 다른 Rust 도구도 같은 이름을 쓴다. 이름만 보고 설치하면 전혀 다른 프로그램을 받을 수 있었다.

내 요청은 분명했다.

```
공신력 있고 가장 인정받은 RTK 하나를 찾아서 설치하고, 토큰 절약용으로 Caveman과 Headroom을 Codex, Claude, OpenClaw에 설치해줘. 앞으로 새로운 업무 시작 시 항상 불러와서 토큰 효율을 지킬 수 있게 해줘.
```

AI는 후보를 바로 설치하지 않았다. 공식 저장소인지, 최근에도 관리되는지, Windows 배포 파일이 있는지, 라이선스가 무엇인지부터 확인했다. 그 결과 Rust Token Killer의 공식 프로젝트인 `rtk-ai/rtk`를 선택했다.

공식 Windows 배포 파일을 내려받은 뒤에는 게시된 체크섬과 실제 파일 값도 비교했다. 별이 많다는 이유만으로 신뢰하지 않고, 받은 파일이 공식 배포물과 같은지도 확인한 것이다. 텔레메트리는 문서끼리 설명이 달라 실제 상태를 확인한 뒤 명시적으로 비활성화했다.

이 과정에서 배운 첫 번째 교훈은 단순했다. **AI에게 설치를 맡길수록 “무엇을 설치했는가”보다 “어떤 근거로 선택했는가”가 중요하다.**

---

### 출력·문체·컨텍스트를 각각 다른 도구로 줄였다

처음에는 토큰 절약 도구 세 개가 비슷한 역할을 할 것으로 생각했다. 조사해 보니 서로 줄이는 지점이 달랐다.

- RTK는 길게 쏟아지는 명령 출력을 정리한다.
- Caveman은 답변의 인사말·반복·군더더기를 줄인다.
- Headroom은 모델에 전달되기 직전의 로그·파일·대화 컨텍스트를 압축한다.

한 가지 도구로 모든 문제를 해결하는 대신, 토큰이 낭비되는 세 지점을 각각 막는 구조였다. 수도관의 한 곳만 잠그는 것이 아니라, 입력부터 출력까지 여러 밸브를 두는 방식에 가까웠다.

세 도구를 Codex·Claude Code·OpenClaw에 한 번에 연결했다. 기존 설정을 통째로 바꾸지 않고, 각 에이전트가 지원하는 방식에 맞춰 필요한 부분만 추가했다.

- Codex에는 전역 작업 규칙과 압축 컨텍스트 복원 도구를 연결했다.
- Claude Code에는 명령 훅, 사용자 플러그인, 복원 도구를 연결했다.
- OpenClaw에는 두 개의 압축 플러그인과 항상 켜지는 간결한 응답 규칙을 연결했다.

핵심은 설치 개수가 아니었다. **세 에이전트에서 같은 운영 원칙이 유지되도록 만든 것**이 가장 큰 변화였다.

---

### 첫 테스트에서 52%가 줄었다

설치 직후 가장 먼저 RTK를 로컬에서 시험했다. 같은 Git 상태 확인 작업을 RTK 경로로 실행한 결과는 다음과 같았다.

- 입력 기준 토큰: 25
- 압축 후 출력 토큰: 12
- 절감 토큰: 13
- 절감률: **52%**

이 수치는 전체 AI 업무 비용이 52% 줄었다는 뜻은 아니다. 한 번의 명령 출력 테스트 결과다. 하지만 “토큰 절약이 될 것”이라는 설명이 아니라, 실제 환경에서 전후 수치를 확인했다는 점이 인상적이었다.

작은 명령 하나에서 절약되는 양은 작아 보여도, 긴 개발 세션에서는 상태 확인, 파일 검색, 테스트 결과, 오류 로그를 여러 번 읽는다. 반복되는 출력이 절반 가까이 줄어들면 컨텍스트가 차는 속도에도 차이가 생길 수 있다.

이때 가장 크게 느낀 점은 **좋은 자동화는 기능 설명보다 첫 번째 측정값에서 신뢰가 생긴다**는 것이었다.

---

### OpenClaw 플러그인은 한 번에 설치되지 않았다

가장 막혔던 부분은 OpenClaw였다. RTK 공식 저장소에 OpenClaw 플러그인이 있었지만, 현재 설치된 OpenClaw가 기대하는 패키지 형식과 맞지 않았다. 일반 설치 명령으로는 플러그인이 등록되지 않았다.

여기서 “공식 지원이라고 했으니 될 것”이라고 밀어붙이지 않았다. 플러그인 파일과 OpenClaw의 실제 로드 방식을 비교한 뒤, 공식 저장소의 로컬 소스 경로를 OpenClaw가 직접 읽도록 연결 방식을 바꿨다.

Headroom도 같은 원칙으로 처리했다. 공식 플러그인 소스를 로컬에서 빌드하고 설치한 뒤, OpenClaw의 컨텍스트 처리 엔진을 Headroom으로 지정했다.

최종적으로 OpenClaw에서 다음 상태를 직접 확인했다.

- RTK 명령 재작성 플러그인: 로드됨
- Headroom 컨텍스트 압축 플러그인: 로드됨
- 컨텍스트 처리 엔진: Headroom으로 지정됨
- 기본·보조 워크스페이스의 Caveman 규칙: 적용됨

막혔을 때 설치 명령만 바꾼 것이 아니라, **도구가 실제로 플러그인을 발견하고 로드하는 경로를 확인한 것**이 해결의 핵심이었다.

---

### 설치보다 어려운 건 “다음 업무에도 자동으로 켜지는가”였다

세 도구를 한 번 실행하는 것은 어렵지 않았다. 하지만 내가 원한 것은 일회성 실행이 아니었다.

```
앞으로 새로운 업무 시작 시 항상 불러와서 토큰 효율을 지킬 수 있게 해줘.
```

이 요구를 충족하려면 에이전트마다 다른 자동화 방식이 필요했다.

- Codex는 모든 새 작업이 읽는 전역 규칙에 토큰 절약 원칙을 넣었다.
- Claude Code는 새 세션 훅과 사용자 플러그인을 사용했다.
- OpenClaw는 워크스페이스의 상시 규칙과 전역 플러그인을 사용했다.
- Headroom 프록시는 Windows 로그인 시 자동 시작되도록 등록했다.

마지막에는 “설치 성공” 메시지를 믿지 않고 실제 상태를 검사했다. Claude Code와 Codex에서는 복원 도구가 연결되는지 확인했고, OpenClaw에서는 플러그인 로드 상태와 컨텍스트 엔진을 확인했다. Headroom은 로컬 상태 점검을 통과했고 압축 코어가 로드된 것도 확인했다.

이 작업의 핵심 팁은 여기에서 나왔다. **설치는 시작일 뿐이고, 새 세션 자동 적용과 실제 연결 검증까지 끝내야 비로소 운영 가능한 자동화다.**

## ✅ 결과 (After)

### Before vs After

| 항목 | Before | After |
|---|---|---|
| 토큰 절약 방식 | 매번 짧게 답해 달라고 수동 요청 | 출력·문체·컨텍스트를 3단계로 자동 최적화 |
| 적용 대상 | 에이전트별로 서로 다른 임시 설정 | Codex·Claude Code·OpenClaw 공통 운영 원칙 적용 |
| 새 업무 시작 | 절약 지시를 다시 입력 | 전역 규칙·훅·플러그인으로 자동 적용 |
| 명령 출력 검증 | 측정값 없음 | RTK 첫 테스트에서 25토큰에서 12토큰으로 감소 |
| Headroom 실행 | 필요할 때 수동 실행 | Windows 로그인 시 로컬 프록시 자동 시작 |
| 보안 확인 | 도구 설명에 의존 | 공식 저장소·체크섬·텔레메트리·네트워크 범위 확인 |

### 완성된 결과

- Codex: RTK 규칙, Caveman 간결 응답, Headroom 프록시와 복원 도구 연결
- Claude Code: RTK 훅, Caveman 사용자 플러그인, Headroom 프록시와 복원 도구 연결
- OpenClaw: RTK 플러그인, Headroom 컨텍스트 엔진, 두 워크스페이스의 Caveman 상시 규칙
- Windows: Headroom 로컬 프록시 자동 시작
- 개인정보 보호: Headroom·RTK 텔레메트리 비활성화

이번 검증에서는 외부 유료 모델을 호출해 전체 업무 절감률을 측정하지 않았다. 비용과 외부 전송 안전 원칙을 지키면서 로컬 연결·상태·첫 RTK 측정까지만 확인했다. 따라서 52%는 전체 시스템의 보장 수치가 아니라 RTK 명령 한 건의 실제 측정값으로 봐야 한다.

## 💬 이 과정에서 배운 AI 활용 팁

### 효과적이었던 것

1. **설치 전에 역할을 나눠 보기**
   - 명령 출력, AI 답변, 전체 컨텍스트는 서로 다른 문제다. 한 도구에 모든 것을 기대하기보다 단계별로 도구를 조합하는 편이 명확했다.

2. **인지도와 안전성을 분리해서 검증하기**
   - GitHub 인지도는 후보를 고르는 기준일 뿐이다. 공식 배포 파일, 체크섬, 라이선스, 최근 관리 상태, 텔레메트리까지 따로 확인해야 했다.

3. **성공 메시지보다 상태를 읽기**
   - “설치됨”과 “새 세션에서 실제 작동함”은 다르다. 플러그인 로드, 복원 도구 연결, 프록시 상태를 각각 확인해야 했다.

4. **숫자는 측정 범위를 함께 쓰기**
   - “52% 절감”만 쓰면 전체 비용 절감처럼 보일 수 있다. 어떤 작업에서 무엇을 비교했는지 함께 기록해야 신뢰도가 생긴다.

### 이렇게 하면 안 돼요

1. **원격 설치 명령을 검토 없이 바로 실행하지 않기**
   - 설치 과정이 여러 에이전트의 전역 설정을 바꿀 수 있다. 공식 저장소를 확인하고 기존 설정을 백업하거나 병합해야 한다.

2. **압축 결과를 모든 업무에서 그대로 신뢰하지 않기**
   - 보안 검사, 배포, 권한 변경, 데이터 삭제처럼 원문 경고가 중요한 작업에서는 압축되지 않은 원본을 확인해야 한다.

3. **선택형 외부 전송 기능을 자동으로 켜지 않기**
   - Caveman의 선택형 문서 압축 기능처럼 파일 내용을 외부 AI에 보낼 수 있는 기능은 별도 승인을 거쳐야 한다.

4. **Windows 지원 문구만 믿지 않기**
   - 실제로는 경로 형식, 플러그인 패키지 구조, 빌드 의존성 때문에 추가 조정이 필요할 수 있다.

## 🌍 다른 업무에 적용한다면?

이 구조는 개발 업무에만 한정되지 않는다.

- PMO 보고서 작성 과정에서 긴 회의록과 상태 로그를 압축할 수 있다.
- 여러 프로젝트의 주간 보고를 만들 때 반복되는 원문을 줄일 수 있다.
- 고객 문의 분석처럼 JSON과 표가 많은 업무에서 컨텍스트 사용량을 줄일 수 있다.
- 팀 공통 에이전트 환경에 적용하면 구성원마다 다른 “짧게 답해줘” 습관을 하나의 운영 기준으로 통일할 수 있다.

다만 업무별 정확도 기준은 달라야 한다. 아이디어 정리나 초안 작성에는 적극적으로 압축을 적용하고, 계약·보안·배포·재무 데이터처럼 한 문장이 중요한 업무에는 원문 확인 경로를 함께 두는 방식이 적절하다.

## 🚀 앞으로의 계획

다음 단계는 “설치됐다”를 넘어 실제 업무 효과를 측정하는 것이다.

앞으로 한 달 동안 업무 유형별로 다음 지표를 기록할 계획이다.

- 에이전트별 입력·출력 토큰 변화
- 컨텍스트가 임계치에 도달하기까지 걸린 시간
- 압축 전후 답변의 정확도와 누락 여부
- RTK 명령별 절감률
- Headroom 압축·복원 사용 횟수
- 작업 완료까지 걸린 시간

이 데이터를 대시보드로 만들면 “어떤 도구가 좋다”는 주관적 평가를 넘어, **어떤 업무에서 어떤 압축 단계가 효과적인지** 판단할 수 있다. 장기적으로는 일반 업무용 절약 모드와 원문이 중요한 민감 업무용 우회 모드를 분리해 운영할 예정이다.

## 📋 재사용 가능한 프롬프트

### 프롬프트 1: 여러 AI 도구에 토큰 절약 구조 설치하기

> 내가 사용하는 AI 도구는 `[Codex, Claude Code, OpenClaw 등]`이야. 토큰 절약 도구 후보의 공식 저장소, 라이선스, 최근 유지보수 상태, Windows 또는 내 운영체제 호환성, 텔레메트리, 외부 전송 가능성을 먼저 검증해줘. 기존 설정은 백업하고 최소 변경으로 설치해. 설치 후에는 새 세션에서 자동 적용되도록 전역 규칙·훅·플러그인·로컬 프록시를 구성하고, 각 도구의 실제 로드 상태를 확인해줘. 유료 API 호출이나 파일 외부 전송은 내 별도 승인 없이 실행하지 마.

### 프롬프트 2: 토큰 절약 효과 검증하기

> 현재 AI 토큰 절약 환경을 감사해줘. 도구별로 설치 여부가 아니라 실제 활성화 상태를 확인하고, 출력 압축·응답 간결화·컨텍스트 압축을 구분해 측정해줘. 테스트는 민감하지 않은 로컬 데이터로 진행하고, 절감률은 전체 비용과 개별 명령 테스트를 혼동하지 않게 측정 범위를 함께 표시해줘. 압축으로 오류·보안 경고가 누락될 위험과 원문 우회 방법도 정리해줘.

### 프롬프트 3: 한 달 운영 대시보드 설계하기

> `[Codex, Claude Code, OpenClaw]`의 토큰 효율을 한 달 동안 비교할 대시보드를 설계해줘. 입력·출력 토큰, 명령 출력 절감률, 컨텍스트 임계치 도달 시간, 작업 완료 시간, 압축 복원 횟수, 정확도 문제를 기록하게 해줘. 유료 API 사용량과 로컬 측정값을 구분하고, 업무 유형별로 어떤 절약 도구가 효과적인지 판단할 수 있는 지표와 시각화를 제안해줘.