정액 플랜에서도 '비용'은 제로가 아니다
당사(合同会社ジョインクラス)는 CEO 1인 회사이며, 부서 보고서나 기획 주제 보충, 영업 리드 모니터링 같은 정형 업무를 Claude Code의 무인 실행에 맡기고 있습니다. Claude Code Max는 정액제이므로 처음에는 '무제한 사용이라면 상한 관리가 필요 없다'고 생각했습니다.
실제로 돌려보니, 정액제라 하더라도 두 가지가 실질적인 비용이 됩니다. 하나는 레이트 제한(rate limit)으로, 무인 작업이 할당량을 차지하면 제가 정말 머리를 쓰고 싶은 설계나 집필 작업에서 기다리게 됩니다. 다른 하나는 처리 시간으로, effort가 높을수록 1개 작업의 소요 시간이 늘어나서 launchd로 순서대로 배치한 작업들이 뒤로 밀려납니다.
즉 관리해야 할 것은 '청구 금액'이 아니라 '추론의 총량을 어디에 배분할 것인가'였습니다. 이 글에서는 당사가 실제로 운영하고 있는 래퍼 스크립트를 바탕으로, effort 분배 방법과 내역 집계 방법을 작성합니다.
effort 분배: 무엇을 맡기고, 무엇을 맡기지 않을 것인가
Claude Code CLI의 --effort
플래그는 claude --help에서 확인한 범위로는 low, medium, high, xhigh, max 5단계입니다. settings.json에 기본값을 설정하는 방법도 있는 것 같지만, 당사에서는 무인 실행되는 모든 작업에 호출자 측에서 --effort를 명시하고 있습니다. '이 작업은 low로 괜찮다'는 판단을 스크립트에 기록해 두고 싶기 때문입니다.
현재 분배는 다음과 같습니다. 스크립트명은 당사의 .company/scripts/에 있는 실제 파일들입니다.
| effort | 작업 (스크립트) | 내용 | 판단 이유 |
|---|
| low | auto-dept-dev.sh / auto-dept-marketing.sh / auto-dept-sales.sh / auto-dept-publishing.sh | 부서 주간 보고서 | 정형적임. 읽고 요약해서 보고만 하면 됨 |
| low | auto-replenish-articles.sh | 기획 주제 보충 | 후보를 내는 것만으로, 채택 여부는 별도 공정 |
| low | auto-sns-monitor-leads.sh / auto-lead-collect.sh | 리드 모니터링 및 수집 | 조건 대조가 중심임 |
| low | auto-sme-concerns.sh / auto-upgrade-check.sh | 외부 정보 정기 수집 | 판단을 동반하지 않음 |
| high 이상 | 기사/도서 집필, 스크립트 설계, 경영 판단 상담 | 제가 대화 세션에서 실행함 | 결과물의 질이 그대로 매출과 관련됨 |
규칙은 단순합니다. 무인으로 돌아가는 것은 전부 low, 사람이 결과를 보고 나서 다음을 결정하는 것만 high 이상입니다. `grep -rho
그것으로 대체할 수 있게 하기 위해서입니다.
호출 측은 다음과 같습니다. auto-dept-publishing.sh
파일의 시작 부분입니다.
source "/Users/kyoagun/workspace/one-ceo/.company/scripts/lib/claude-run.sh"
cd "$PROJECT_ROOT"
RESULT=$(claude_run dept-publishing --effort low -p "
...
테마 보충(theme replenishment)에서는 --allowedTools를 병용하여 읽기(Read)와 검색(WebSearch)만 허용하고 있습니다.
claude_run replenish --effort low --allowedTools "Read,WebSearch,WebFetch" -p "
다음 기존 테마 목록과 중복되지 않는 새로운 기사 주제를 생성해 주세요.
…
...
low로 설정한 작업일수록 쓰기 권한도 제한하는 대응 관계를 가지고 있습니다. 추론을 얕게 한 만큼, 문제가 생겼을 때의 피해 범위도 좁게 유지하자는 생각입니다.
월 ¥30,000 내역을 어떻게 보고 있는가
파이프의 끝에 있는 record-cost.py는 --output-format json 출력에서 total_cost_usd와 usage.cache_creation_input_tokens를 추출하여, 작업별로 cost-tracker.json에 누적합니다.
cost = float(d.get("total_cost_usd") or 0)
usage = d.get("usage") or {}
t["total_usd"] = round(before + cost, 6)
...
월이 바뀌면 전월분을 cost-tracker-YYYY-MM.json에 보관하고 다시 열어보고, 월간 합계가 $160를 넘는 순간과 $200를 넘는 순간에만 Slack으로 알림을 보냅니다. 매번 알리면 무시하게 되기 때문에 '넘어난 순간'에만 보내는 것입니다. $200는 월 ¥30,000에 거의 해당하며, 여기가 저희 회사의 상한선입니다.
작업별 내역은 한 줄로 출력할 수 있습니다.
jq -r '.jobs | to_entries[] | [.key, .value.calls, .value.usd] | @tsv' \
.company/scripts/cost-tracker.json \
| awk -F' ' '{printf "%s-%-20s %3d회 $%6.2f 1회 평균 $%.2f\n", $1, $2, $3, $4, $5}' \
...
이번 달 5일 기준 저희 회사의 수치를 반올림하면 다음과 같습니다.
| 작업 | 실행 횟수 | 누적 비용 | 1회 평균 |
|---|
| replenish (테마 보충) | 10회 | 약 $10 | 약 $1.0 |
| ... | | | |
전부 low로 돌리고 있는데도, 1회당 비용이 거의 3배 가까이 차이가 나는 것이 보입니다. 차이는 effort가 아니라, 도구 호출 횟수와 읽어들이는 파일 양 때문입니다. WebSearch를 허용하는 작업일수록 높습니다. effort를 낮춰도, 읽는 양이 많으면 싸지지는 않습니다. | | | |
함정: effort를 낮춰도 줄지 않는 것
고정 오버헤드는 깎을 수 없다
이 라퍼(wrapper)를 만들게 된 계기는 '2+2'만 물어보는 단 한 번의 호출에 $0.27~$0.47가 들었기 때문입니다. 내역은 캐시 생성에 대한 약 41,000 토큰이며, 그중 저희 회사의 CLAUDE.md, 에이전트 정의, 스킬은 5,800 토큰밖에 없습니다. 나머지는 Claude Code 측의 고정분입니다. 즉 effort를 아무리 낮춰도, 호출 횟수를 줄이지 않는 한 바닥은 내려가지 않습니다. low로 설정하는 효과는 '1회 내부 추론량'에만 국한됩니다.
자체 신고된 예상 비용은 가드를 무효화한다
이전의 시스템은 호출 측에서
처음 tolow로 돌리기 시작했을 때, 나오는 주제들이 기존 기사에서 이미 사용했던 숫자들의 변형에 불과했습니다. 장부를 살펴보니, 초기에 채워 넣었던 주제의 절반 가까이를 낭비하고 있었습니다. 해결책은 effort를 올리는 것이 아니라, 프롬프트에 기존 주제 목록을 전달하여 중복 생성을 금지하고, 장부(article-theme-ledger.tsv)에서 승인 여부를 추적하는 쪽으로 방향을 바꿨습니다. 판단이 필요 없는 작업은 추론 깊이를 더하기보다 제약을 늘리는 것이 더 안정적입니다.
변경된 검증 절차
effort를 변경할 때는 동일한 프롬프트로 다음 3가지를 비교합니다.
claude_run test-low --effort low -p "..."
와 claude_run test-high --effort high -p "..."
을 연속으로 실행하여, cost-tracker.json의 jobs.test-low와 jobs.test-high에서 실제 비용을 비교하고 - 출력을 파일에 저장한 후
diff
로 차이점을 확인하며, 떨어진 항목이 '허용 가능한 생략'인지 '판단 오류'인지를 육안으로 확인하고 -
time
으로 소요 시간을 측정합니다. 저희 부서 보고서에서는 low와 high 간에 품질 차이가 나타나지 않는 반면, 소요 시간은 high가 명확하게 길었고, 이것이 low 고정의 결정적인 계기가 되었습니다.
리트라이를 포함한 총 시간으로 보지 않으면 'low로 빨라졌지만 실패가 늘어 결국 느려짐'을 놓치게 됩니다. record-cost.py의 errors 카운트는 그 때문에 존재합니다.
상한은 절약 때문이 아니다
제 개인적인 느낌으로는, AI를 이용해 업무 비용은 1/10 수준으로 줄어들겠지만, 매출이 10배가 되는 것은 아닙니다. 비용을 아무리 줄여도 회사는 성장하지 않습니다. 따라서 추론 비용의 상한을 '싸게 하기 위해서' 설정하는 것이 아니라, 레이트 제한과 시간이라는 유한한 자원을 정말 판단이 필요한 일에 할애하기 위해 설정하고 있습니다.
정형화된 보고서가 high로 정교하게 작성되어도 매출은 1엔도 변하지 않습니다. 반면, 책의 장 구성이나 제안서 설계처럼 추론을 아끼면 그대로 결과물의 품질에 영향을 미칩니다. 무인 작업을 전부 low로 통일한 것은 그 배분을 시스템적으로 고정하는 작업이었습니다.
이 글의 원활한 운영 노하우는 당사의 Zenn 서적에 정리되어 있습니다.
이 기사는 필자(合同会社ジョインクラス)의 실제 경험을 바탕으로 합니다.
Discussion
