프로 요금제를 쓰면서 이상한 걸 발견했습니다. 일주일에 나흘쯤 쓰면 한도가 바닥납니다. 남은 사흘은 손을 놓아야 하죠.
처음엔 제가 질문을 너무 많이 해서인 줄 알았습니다. 그래서 말을 아꼈는데 별로 나아지지 않더군요. 원인은 다른 데 있었고, 엉뚱하게도 제가 아껴 쓰려고 만든 장치가 범인이었습니다.
클로드 토큰이 주 4일 만에 바닥나던 상황
저는 이 블로그의 운영 도구를 클로드 코드로 만들어 씁니다. 검수기, 업로더, 키워드 조사 도구 같은 것들이죠. 하루에 몇 시간씩 붙어 있으면 대략 나흘째에 한도 경고가 뜹니다.
궁금한 건 이거였습니다. 짧게 물어봐도 사용량이 줄지 않는다는 것. “이 함수 고쳐줘” 한 줄만 쳐도 남은 한도가 눈에 띄게 깎였습니다.
공식 문서를 찾아보니 이유가 명확히 적혀 있었습니다. 클로드 코드 비용 문서는 이렇게 설명합니다 — 매 요청마다 지금까지의 대화 전체가 함께 전송되고, 그래서 하루 종일 열어둔 창에서는 한 줄짜리 질문도 대화 전체만큼의 사용량을 끌어간다고요.
즉 제가 친 글자 수는 거의 상관이 없었습니다. 창을 얼마나 오래 열어뒀고 그 안에 뭐가 쌓였는지가 진짜 변수였죠.
이해가 안 돼서 한 번 물어볼 때 무슨 일이 벌어지는지부터 따라가 봤습니다.
돈이 드는 자리는 ③번입니다. 제가 방금 친 한 줄이 아니라 그때까지의 문맥 전체를 읽고 추론하니까요. 질문을 짧게 써도 ③번의 크기가 안 줄어들면 소용이 없습니다.
그럼 그 문맥에는 정확히 뭐가 들어 있을까요. 세 군데에서 쌓이더군요.
처음 시도한 것 — 모델을 번갈아 쓰기
가장 먼저 한 건 모델 바꿔가며 쓰기였습니다. 가벼운 작업은 작은 모델로, 어려운 것만 큰 모델로요.
어느 정도는 효과가 있었습니다. 다만 오래 못 갔습니다. 큰 작업에서는 디테일이 중요한데, 작은 모델로 돌리면 놓치는 게 생기고 그걸 다시 잡느라 왕복이 늘었거든요. 아낀 것보다 더 쓴 셈입니다.
문서에도 한계가 적혀 있었습니다. 한도 창은 모델끼리 공유라서 /model로 바꿔도 접근이 돌아오지 않는다고요. 제가 체감한 “조금 도움은 되는데 결정적이진 않다”가 정확히 이 얘기였습니다.
모델 선택은 유효한 카드입니다. 다만 한도 문제의 답은 아니었습니다.
하네스를 키웠더니 오히려 더 썼습니다
그래서 방향을 바꿨습니다. 같은 설명을 반복하지 않게 규칙을 파일에 적어두는 것 — 하네스 엔지니어링이라 부르는 그 작업이죠.
효과는 분명했습니다. 매번 “네이버 고객 ID는 이 값이 맞다”를 설명할 필요가 없어졌으니까요. 그래서 계속 적었습니다. 함정을 밟을 때마다, 판단이 바뀔 때마다.
그러다 규칙 파일이 이만큼 자랐습니다.
7월 15일 47줄
7월 21일 98줄
7월 23일 181줄
8월 1일 275줄
그런데 사용량이 줄기는커녕 늘더군요. 원인을 알고 나서 좀 허탈했습니다.
규칙 파일은 세션이 시작될 때마다 통째로 컨텍스트에 올라갑니다. 반면 스킬은 호출될 때만 로드됩니다. 공식 문서는 규칙 파일을 200줄 이하로 유지하라고 권합니다.
제 파일은 275줄이었습니다. 공식 권장치가 200줄이니 1.4배쯤 넘긴 상태로, 관계없는 작업을 할 때도 매번 전부 실어 나르고 있었던 겁니다. 워드프레스 글을 쓰는 세션에서도 다이어그램 규칙과 이미지 경로 관례가 통째로 따라다녔죠.
아껴 쓰려고 만든 장치가 고정비가 돼 있었습니다.
그래서 “무엇을 적을까”가 아니라 “어디에 둘까”로 바꿨습니다
핵심은 지침을 줄이는 게 아니었습니다. 읽히는 시점을 나누는 것이었죠.
| 성격 | 어디에 | 언제 읽히나 |
|---|---|---|
| 항상 지켜야 할 원칙 | 규칙 파일 | 세션 시작마다 (항상 비용) |
| 순서가 있는 작업 절차 | 스킬 | 그 작업을 할 때만 |
| 반복한 실수·판단 근거 | 메모리 | 필요할 때 참조 |
지금은 스킬 6개에 1,149줄, 메모리 9개 파일에 543줄이 나뉘어 있습니다. 이 1,700줄이 전부 규칙 파일에 있었다면 모든 세션이 그걸 지고 시작했을 겁니다.
같이 바꾼 습관도 있습니다.
- 주제가 바뀌면 새 창으로. 문서도 같은 걸 권합니다. 대화를 요약하는 명령은 그 대화를 다시 읽어야 해서 그 자체가 큰 요청이지만, 아예 비우는 건 비용이 들지 않습니다.
- 안 쓰는 연결을 끕니다. 붙여둔 외부 도구가 많을수록 시작 비용이 올라갑니다.
- 한 번 시킬 때 검증까지 묶습니다. 예전엔 “고쳐줘” 다음에 “테스트 돌려줘”를 따로 물었는데, 그게 왕복 한 번을 더 만듭니다. 지금은 규칙에 “작업하면 테스트까지”라고 적어뒀습니다. 왕복이 줄면 실려 나가는 대화도 줄죠.
마지막 항목이 의외로 컸습니다. 한 번 물어볼 때 얼마나 많은 일이 끝나는가 — 이게 실제 체감 한도를 좌우했습니다.
붙여둔 도구도 고정비라, 고르는 절차를 따로 만들었습니다
위에서 “안 쓰는 연결을 끈다”고 했는데, 사실 더 중요한 건 애초에 뭘 붙이느냐입니다. 외부 도구를 연결하면 그 목록이 세션마다 따라다니거든요. 공식 문서도 /context로 무엇이 자리를 차지하는지 확인하고 안 쓰는 서버는 끄라고 권합니다.
문제는 고르는 방법이었습니다. 처음엔 인기순으로 몇 개 깔았는데 대부분 겉돌더군요. 그래서 선별 절차 자체를 스킬로 만들었습니다. 세 단계입니다.
- 필요를 프로젝트에서 뽑는다 — 머리로 떠올리지 않습니다. 코드에 실재하는 위험과
git log의 수정·되돌림 이력에서 자동으로 초안을 뽑고, 사람이 고칩니다 - 전수 스크리닝 — 인기 목록이 아니라 마켓 전체를 훑습니다
- 실행 검증 — 소스를 받아 직접 돌려봅니다
세 번째가 핵심이었습니다. 문서만 보고 판단했다면 세 번 다 틀렸습니다.
| 플러그인 | 설명문 | 실제로 돌려보니 |
|---|---|---|
| hookify | 완벽해 보였음 | 한국어 윈도우에서 규칙 전멸 |
| safety-net (별 1,462) | “파괴적 명령 차단” | 제가 실제로 낸 사고 명령을 통과시킴 |
| pyright | “타입 검사” | 진짜 버그 1건 발견, 다만 오탐 50% |
별점도 적합도 순위도 실행 결과를 예측하지 못했습니다. 순위는 “열어볼 가치가 있다”까지만 말해주더군요. 실제로 2,393개에서 출발해 조건에 걸린 게 169개, 목적 설명을 직접 읽은 게 5개, 돌려본 게 4개, 남은 게 1개였습니다.
여기에 재미있는 점이 하나 있습니다. 이 절차서 자체도 규칙 파일이 아니라 스킬에 있습니다. 플러그인을 고를 때만 읽히면 되니까요. 위에서 말한 “어디에 둘까”를 이 절차에도 그대로 적용한 셈입니다. 자세한 기준은 클로드 플러그인 고르는 법에 따로 적었습니다.
원인을 스스로 알려주는 화면이 있었습니다
한참 뒤에야 알았는데, /usage를 치면 최근 사용량을 무엇이 잡아먹었는지 항목별로 보여줍니다. 긴 컨텍스트나 캐시 미스가 10% 이상을 차지하면 그것도 따로 표시해 준다고 문서에 적혀 있습니다.
추측할 필요가 없었던 겁니다. 저는 몇 주를 감으로 헤맸습니다.
한 가지 더. 구독에서는 캐시 수명이 1시간이라, 그보다 오래 쉬었다 돌아오면 첫 요청이 전체를 다시 처리합니다. 점심 먹고 와서 유난히 많이 깎이는 느낌이 들었다면 착각이 아닙니다.
정리하면
| 시도한 것 | 결과 |
|---|---|
| 질문을 짧게 쓰기 | ✗ 거의 무관 — 실려 나가는 건 대화 전체다 |
| 모델 번갈아 쓰기 | △ 도움은 되지만 한도 창은 모델 공유 |
| 규칙 파일에 다 적기 | ✗ 역효과 — 세션마다 전량 로드 |
| 규칙·스킬·메모리로 분리 | ○ 항상 드는 비용이 줄어든다 |
| 붙일 도구를 검증하고 고르기 | ○ 안 쓰는 연결이 안 쌓인다 |
| 주제 바뀌면 새 창 | ○ 비우는 건 공짜다 |
| 한 번에 검증까지 묶기 | ○ 왕복 자체를 줄인다 |
클로드 토큰을 아끼는 건 말을 아끼는 일이 아니었습니다. 지금 이 작업에 필요 없는 것을 안 실어 보내는 일이었죠.
제일 뼈아팠던 건 그 반대를 몇 주간 하고 있었다는 점입니다. 규칙을 꼼꼼히 적을수록 잘하고 있다고 믿었는데, 그게 고정비였습니다. 규칙을 적는 것과 그 규칙이 지금 필요한지는 다른 문제였습니다.
덧붙일 게 하나 있습니다. 여기까지 고치고도 결국 상위 요금제로 올렸습니다. 작업량이 늘면 구조를 아무리 다듬어도 한계가 오더군요. 다만 그 전에 구조부터 고친 건 후회가 없습니다 — 요금제를 올렸어도 오래 열어둔 창은 여전히 비싸고, 그건 돈으로 해결되는 문제가 아니었습니다.
규칙 파일을 왜 만들게 됐는지는 프롬프트 엔지니어링을 7일 해본 기록에 적었고, 검증 장치를 어떻게 짰는지는 하네스 엔지니어링 쪽에 있습니다. 어떤 작업에 어떤 모델을 쓰는지는 클로드 모델 비교에서 따로 다뤘습니다.
