Claude Code의 비용 절감을 실측으로 연결하기 — 1개씩 단계적으로 도입하여 전주 대비를 측정하는 운영 설계

시산은 「단계적 도입」을 통해 실측으로 변한다

전작 「Claude Code의 비용을 30% 삭감하는 시산」에서는 모델 선택, 프롬프트 캐싱 (Prompt Caching), 출력 감소의 3개 축을 통해 월간 30%의 절감 잠재력을 추산했다.

하지만 시산은 시산일 뿐이다.

30%라는 수치는 전제 조건(실행 횟수, 캐시 히트율, 출력 단축률) 위에 올라간 숫자이며, 실제 운영 환경에서 그대로 나타난다는 보장이 없다.

결론부터 말하겠다.

시산을 실측으로 바꾸는 방법은, 대책을 하나씩 도입하여 전주 대비를 측정하는 것뿐이다.

이는 SRE의 카나리 배포 (Canary Release)와 같은 사고방식이다.

1개의 대책을 1개의 카나리로 간주하고, 변경 전후의 차이(Difference)만을 관측한다.

본 기사는 그 「측정 방법」의 운영 설계를 다룬다.

시산의 내용(어떤 대책으로 몇 %를 줄일 수 있는가)은 전작에 맡기고, 여기서는 「도입한 대책이 정말로 효과가 있었는지를 어떻게 확인하는가」에 집중한다.

먼저, 왜 한꺼번에 도입하면 효과를 측정할 수 없는지 확인해 보자.

왜 여러 대책을 한꺼번에 도입하면 효과가 사라지는가

대책을 한꺼번에 도입하면, 비용이 절감되었는지는 알 수 있어도 어떤 대책이 효과를 냈는지는 알 수 없게 된다.

원인은 세 가지 「혼선」 때문이다.

첫째, 대책 간의 교란 (Confounding).

모델 전환과 캐시 도입을 같은 주에 실시하면, 낮아진 비용을 어느 쪽의 기여로 할당해야 할지 알 수 없다.

효과가 없었던 대책이 효과가 있었던 대책의 그늘에 숨어 살아남게 된다.

둘째, 실행량의 변동.

총비용은 「단가 × 실행 횟수」로 결정된다.

대책을 통해 단가를 낮추더라도, 해당 주에 배치 (Batch) 횟수가 늘어나면 총액은 올라간다.

총액의 전주 대비만 보면, 효과가 있었던 대책이 「효과가 없다」고 오판될 수 있다.

셋째, 모델 측의 변화.

Anthropic의 가격 개정이나 모델 업데이트가 대책을 도입한 주와 겹칠 수 있다 (Anthropic API Pricing).

자신의 변경 사항과 외부 요인이 섞이면 차이에 대한 해석이 어긋나게 된다.

이 세 가지를 분리하지 않으면, 전주 대비 수치는 거짓말을 한다.

카나리 배포에서 「한 번에 하나씩만 바꾼다」는 철칙이 있는 것과 마찬가지로, 비용 대책도 한 번에 하나씩만 도입해야 한다.

이하에서는 혼선을 제거하는 측정 방법을 관측 단위, 도입 순서, 평가 창 (Evaluation Window), 롤백 (Rollback) 기준 순으로 설계한다.

측정 단위를 총액이 아닌 「단위 비용」으로 한다

총비용은 실행 횟수에 휘둘린다.

대책의 효과를 보려면, 1회 실행당 또는 1개 기사당 「단위 비용 (Unit Cost)」으로 변환하여 확인해야 한다.

FinOps에서 말하는 cost per unit (단위 비용)의 개념이다 (Cost per Unit — FinOps School).

왜 단위 비용으로 보아야 하는가? 총액은 실행량에 따라 흔들리지만, 대책이 움직이는 것은 단가이기 때문이다.

예를 들어, 콘텐츠 자동화 파이프라인이라면 「기사 1개를 생성하는 데 들어간 금액」을 단위로 설정한다.

주	비용 총액	생성 기사 수	1개당 단가
기준 주 (대책 없음)	$11.10	10개	$1.11
모델 전환 도입	$12.50	14개	$0.89

이 예시에서는 총액이 13% 증가했다.

총액만 보면 비용이 「악화」된 것이다.

하지만 단위 비용은 $1.11 → $0.89로 20% 정도 낮아졌으므로, 대책은 제대로 작동하고 있다.

해당 주에 기사가 많았던 만큼 총액이 불어났을 뿐이다.

반대로 총액이 낮아졌더라도, 그것이 「그 주에 우연히 실행이 적었던 것」뿐이라면 단위 비용은 변하지 않는다.

이를 총액으로만 보면 환상적인 절감 효과에 속게 된다.

단위 비용의 집계는 비용 합계를 실행 횟수로 나누기만 하면 된다.

# 단위 비용 = 해당 주의 비용 합계 ÷ 해당 주에 생성한 기사 수
# cost.log의 필드 위치는 각자의 출력 형식에 맞출 것
total=$(awk -F, '$1>="2026-06-01" && $1<="2026-06-07"{sum+=$3} END{print sum+0}' cost.log)
...

분모(실행 횟수)를 확보할 수 있는 설계가 되어 있어야 한다는 것이 전제 조건이다.

이 부분은 후반부 구현에서 다루겠다.

1개 대책 = 1주일 = 1카나리로 순차적 도입

도입 순서는 절감 폭이 큰 순서로 한다.

가장 먼저 효과가 큰 모델 전환, 그다음 캐시, 마지막으로 출력 감소 순이다.

이유는 대책의 규모가 클수록 노이즈에 묻히지 않고 차이를 명확히 볼 수 있기 때문이다.

작은 대책을 먼저 도입하면 효과가 변동성 (Fluctuation)에 묻혀 판정할 수 없게 된다.

각 대책에 최소 1주일의 관측 기간을 할당한다.

기간을 짧게 잡지 않는 이유는 샘플이 적으면 신호가 노이즈에 묻히기 때문이다.

Google의 카나리 운영에서도 트래픽이 적은 카나리는 평가 창을 길게 가져간다 (Google SRE Workbook — Canarying Releases).

일일 비용은 요일별 변동(평일에 배치 작업이 많은 등)이 있으므로, 1주일 동안 요일을 한 바퀴 돌려 평균을 낸다.

운영은 다음 4단계로 진행한다.

기준 주(Baseline Week): 조치(Measure) 없이 1주일간 단위 비용의 기준값을 측정한다 -
투입 주(Implementation Week): 1개의 조치만 적용하여 1주일간 단위 비용을 측정한다 -
판정(Judgment): 기준 주와의 단위 비용 차분을 해당 조치의 효과로 간주한다 -
다음 단계(Next Step): 효과를 확정한 후 다음 조치를 투입한다

조치들을 중첩시키지 않으므로, 각 주의 차분이 그대로 해당 조치의 기여도가 된다.

이것이 교란(Confounding)을 차단하는 유일한 방법이다.

노이즈와 효과를 구분하기 — 어디서부터를 "효과가 있었다"라고 할 것인가

단위 비용에도 주별 변동(Fluctuation)이 있다.

기준 주의 변동 폭(표준 편차든 범위든 상관없다)을 초과하는 차분이 나타나야 비로소 "효과가 있었다"라고 판단한다.

왜 임계값(Threshold)을 설정하는가? 변동 폭 안에 들어오는 차분은 조치의 효과인지 노이즈인지 구분할 수 없기 때문이다.

카나리 분석(Canary Analysis)에서는 모수(Population)가 작을수록 신호가 노이즈가 되기 쉬우므로 평가 기간을 길게 가져간다.

비용 조치에서도 차분이 작은 조치(출력 감소와 같은 수 % 단위)일수록 관측 기간을 늘리거나 판정을 보류한다.

"2% 정도 떨어진 것 같다"를 효과로 기록하면, 효과가 없는 조치가 운영에 계속 남게 된다.

여기서 효과를 과대평가하면 다음 조치의 기준 주가 어긋나게 되어, 오차가 뒤로 전파된다.

판정은 변동성과 정면으로 마주하며 신중하게 확정해야 한다.

비용 개선이 품질을 깎아먹고 있지는 않은지 확인하기

모델을 Haiku로 전환하면 비용은 낮아진다.

하지만 분류 정확도나 문장 품질이 떨어지지 않았는지는 별도의 지표로 확인할 필요가 있다.

카나리 릴리스(Canary Release)가 레이턴시(Latency)뿐만 아니라 에러율도 확인하는 것과 같다.

비용만 보면 품질 저하를 놓치게 된다.

비용 조치의 롤백(Rollback) 기준을 투입 전에 결정해 둔다.

• 단위 비용은 낮아졌지만, editorial-review의 반려율이 높아졌다 → 모델 전환을 되돌린다
• 출력 감소로 인해 JSON이 깨지는 빈도가 높아졌다 → 출력 제약을 완화한다

비용과 품질은 트레이드오프(Trade-off) 관계가 될 수 있다.

감소한 금액만 보고 채택하면, 후속 공정의 재작업으로 인해 인간의 비용이 증가한다.

금액의 절감과 품질의 유지를 동일한 카나리 안에서 모두 관측해야 한다.

단계적 투입을 시스템화하기

측정 방법을 운영에 적용하려면 두 가지 기록이 필요하다.

첫째, 조치 투입일의 어노테이션(Annotation).

"이 날에 모델 전환을 적용했다"를 기록해 두지 않으면, 나중에 차분의 경계를 알 수 없게 된다.
조치 로그를 한 줄의 텍스트로 남기는 것만으로도 충분하다.

둘째, 실행량의 기록.

단위 비용을 산출하려면 분모(기사 수, 실행 횟수)가 필요하다.
cost.log에 실행 횟수 카운트를 병기해 두면, 나중에 주 단위로 나눌 수 있다.

이 두 가지만 있으면 기준 주와 투입 주에서 동일한 집계를 두 번 돌려 단위 비용을 비교하는 것만으로 조치의 효과를 기계적으로 도출할 수 있다.

조치 로그와 대조하면 "지난주에 넣은 조치가 얼마만큼 효과가 있었는지"를 한 줄로 말할 수 있다.

판단 재료가 갖춰지므로, 인간은 채택 여부만 결정하면 된다.

요약 — 추산치를 실측치로 바꾸는 것은 운영 설계

Claude Code의 비용 절감은 추산에서 멈추면 "절감한 것 같은 기분"으로 끝난다.

추산치를 실측치로 바꾸는 것은 조치를 하나씩 투입하며 전주 대비를 측정하는 운영 설계다.

카나리 릴리스의 방식을 그대로 빌려오면 된다.

• 한 번에 하나의 조치만 변경한다 (교란 차단)
• 총액이 아닌 단위 비용으로 측정한다 (실행량 변동 제거)
• 변동성을 초과하는 차분만을 효과로 간주한다 (노이즈와 구분)
• 비용과 품질을 동일한 창에서 관측한다 (저하를 놓치지 않음)

시스템은 Claude Code 스스로 작성하게 해도 상관없다.

집계도 단위 비용 산출도 스크립트의 역할이다.

그 위에서 인간이 쥐어야 할 판단은 다음 세 가지로 압축된다.

어떤 정확도를 타협할 수 없는가: Haiku로 전환해서는 안 되는 명령은 무엇인가 -
변동성을 어디까지 허용할 것인가: 몇 %의 차분을 "효과"로 인정할 것인가 -
언제 종료할 것인가: 1주일 만에 판정할 것인가, 변동성이 크다면 연장할 것인가

깎아내는 설계는 전작이고, 효과가 있었는지 확인하는 운영은 본 기사다.

추산과 실측이 갖춰져야 비용 절감은 비로소 운영 대상이 된다.

Discussion