「2배를 내면 2배 빠르다」는 사실일까——Claude Code의 fast 모드를 QCD로 실측하다 (어른의 자유연구 #25)

3가지 발견

fast 모드 → 품질은 그대로, 처리 시간은 거의 절반으로 단축 (중앙값 기준 약 1.9배 빠름, xhigh에서는 2.34배 빠름)

그 대가 → 비용은 약 2배. 환산하면 「단축 1시간 ≒ 약 $40」로 시간을 사고 있는 셈

함정 → fast는 말없이 표준 모드로 전환될 때가 있음 (120회 시도 중 2건)

Q を一定に保つと、fast の点群は標準より左（速い）かつ上（高い）に並ぶ。横軸 D（実行時間 s）・縦軸 C（API 利用料金 $）の散布図で、標準（オレンジ）と fast（青）それぞれに effort 4 点がほぼ一直線に乗ることを示すグラフ

서론

Claude Code에는 fast 모드라는 기능이 있어, 대화 세션에서 /fast라고 입력하는 것만으로 전환되며, 모델은 Opus를 유지하면서 출력 속도(OTPS: output tokens per second)가 최대 2.5배 빨라진다고 합니다. 그 대신, API 단가는 표준의 정확히 2배입니다. fast 모드 자체는 Claude Code v2.1.36에서 (당초에는 Opus 4.6을 대상으로) 탑재된 기능이지만, 이번에 측정하는 「2배 요금으로 2.5배 빠른」 Opus 4.8 버전이 사용 가능해진 것은 v2.1.154부터입니다.

「2배를 내면 2배 빠르다」——이것은 사실일까요. 출력이 빨라지더라도 테스트 실행이나 파일 편집 시간은 변하지 않을 것입니다. 그리고 서두른 만큼 품질이 저하되지는 않을까요?

이번에는 지난번(#24)과 동일한 태스크와 동일한 채점 방식을 사용하고, 모델을 Opus 4.8로 고정한 상태에서 fast 유무를 QCD의 3축——품질 Q(Quality)·비용 C(Cost)·처리 시간 D(Delivery/Duration)——로 비교했습니다.

검증 환경

검증은 #17에서 셋업한 Raspberry Pi 5 환경에서 진행했습니다.

항목	값
호스트	Raspberry Pi 5 (4GB)
...

모델과 CLI를 고정하고, 변화를 주는 것은 fast의 유무와 effort level (low / medium / high / xhigh)뿐입니다. 각 조합마다 3개의 태스크를 10회씩 실행하므로, 1 패턴당 30회 시도합니다. 이것이 8 패턴 분량으로, 총 240회 시도가 이번 대상입니다.

mode	effort level	시도 횟수
표준	low / medium / high / xhigh	각 30회
fast	low / medium / high / xhigh	각 30회

실행 순서는 두 모드를 동일한 배치에 섞어서 셔플함으로써, 시간대나 온도 조건의 편중이 한쪽으로 쏠리지 않도록 했습니다. 헤드리스 실행(claude --print)을 위해, fast 활성화는 --settings '{"fastMode":true}'로 수행했습니다.

검증용으로 실행한 태스크

태스크도 지난번 #24와 동일하게, PostgreSQL + psycopg2를 주제로 한 작은 Python 모듈 3개입니다. 모두 대상 함수가 스켈레톤(skeleton) 상태로 되어 있으며, 에이전트는 사양(프롬프트)을 읽고 내용을 구현합니다. 배포되는 기본 테스트는 해피 패스(happy path)만을 확인하는 것이며, 진짜 함정은 히든 테스트(hidden test)와 pass_gate를 통해 처음으로 표면화됩니다.

태스크 개요는 이쪽

ID	테마	심어놓은 함정 (히든 테스트·`pass_gate`)
T1	원자적 송금 (`transfer` / `get_balance`)	실패 경로의 롤백 누락·트랜잭션 방치를 검출
T2	파라미터화 검색 (`search_users`)	LIKE 메타 문자의 이스케이프·빈 `IN ()`·식별자 인젝션 등, 파라미터화 누락을 검출 (프롬프트에는 「injection」이라고 적지 않음)
T3	낙관적 잠금 재고 할당 (`reserve` / `release`)	영향 행수(`rowcount`)를 확인하지 않는 가드 없는 UPDATE로 인한 lost update·초과 판매를 검출

함정의 설계 의도와 취약한 참고 구현에 의한 검증 상세 내용은 #24에 기재되어 있습니다.

품질 평가는 #16에서 설계한 ISO 25010 유래의 5개 축(Functional 0.40 / Reliability 0.20 / Security 0.15 / Maintainability 0.15 / Safety 0.10)의 가중치를 적용하여 Q를 산출하며, 게이트(gate) 통과 조건을 단 하나라도 놓치면 Q는 **50에서 상한선(cap)**이 걸립니다. 채점은 모두 자동·규칙 기반(rule-based)으로 이루어지며, 판정에 흔들림은 없습니다.

결과의 개요

먼저 8가지 패턴의 QCD를 목록으로 훑어봅니다. 품질 판정은 지난번과 마찬가지로 유일하게 차이가 발생한 태스크 2(파라미터화 누락을 찌르는 테스트)의 통과율에 따라 3단계로 나누었습니다.

effort	mode	T2 통과	품질	처리 시간(s)	단축	비용($)	비용비
low	표준	30 %	❌	26.7	—	0.137	—
low	fast	20 %	❌	13.9	1.93배	0.272	1.98배
medium	표준	100 %	✔	34.1	—	0.172	—
medium	fast	100 %	✔	20.0	1.71배	0.411	2.40배
high	표준	100 %	✔	43.1	—	0.215	—
high	fast	100 %	✔	22.5	1.91배	0.432	2.01배
xhigh	표준	100 %	✔	86.4	—	0.342	—
xhigh	fast	100 %	✔	36.9	2.34배	0.648	1.89배

✔ = 100 %: 전 시도 통과. 실전 투입 가능

△ = 50~99 %: 동작은 하나 불안정함. 리뷰나 재시도(retry)가 전제되어야 함 → 이번에는 나타나지 않음

❌ = 0~49 %: 신뢰성이 낮아 실운용이 어려움

low의 T2 통과율 차이(표준 30 % / fast 20 %)는 fast에 의한 열화가 아니라, low effort 고유의 불안정성입니다(N=10 범위 내의 변동. 상세 내용은 「품질」 절 참고).

처리 시간(s)·비용($)은 1회 시도(태스크 1개)당 중앙값(T1~T3 풀, 각 셀 N=30. fast의 medium / high는 폴백(fallback) 1건씩을 제외한 N=29).

전 240회 시도가 타임아웃(timeout)·Out of Memory(메모리 부족)·에러 없이 완주하였으며(gate 탈락 15건은 모두 모델의 로직 미통과), 인프라 기인에 의한 결측은 없습니다.

처리 속도(D): 약 1.9배 속도——단, 「2.5배」가 되지는 않는다

모든 effort를 계산하면 처리 시간의 중앙값은, 표준 모드: 41.2초 → fast 모드: 21.6초입니다. 약 1.9배 속도, 거의 절반입니다.

하지만 공식이 내세우는 「최대 2.5배」에는 도달하지 못했습니다. 이유는 단순합니다. 2.5배가 되는 것은 **출력 속도(OTPS, Output Tokens Per Second)**이지, 처리 시간이 아니기 때문입니다. 처리 시간에는 pytest 실행·파일 편집 등의 도구 실행 시간과 첫 번째 토큰이 반환될 때까지의 대기 시간이 포함되며, 이 부분은 fast 모드로 해도 빨라지지 않습니다. 빨라지는 것은 오직 「모델이 토큰을 출력하고 있는 시간」뿐이라는 뜻입니다.

이는 effort별 단축률과도 일치합니다. 단축률이 최대인 것은 xhigh의 2.34배였습니다. effort level이 높을수록 깊이 생각하여 대량의 토큰을 생성하기 때문에, 생성 시간이 처리 시간에서 차지하는 비중이 커져 OTPS 가속화의 효과도 커집니다. 즉, fast 모드는 「깊이 생각해야 하는 태스크」일수록 이득이 되는 구조입니다.

비용(C): 정확히 2배——「1분 단축」의 가격은 $0.66

비용 비율은 1.89~2.40배, 전체 시행에서는 약 2.05배입니다. 단가 배율(2배)과 거의 일치하며, 이는 fast 모드로 설정하더라도 소비 토큰량은 거의 변하지 않는다는 것을 의미합니다 (서두르더라도 「대충 짧게」 만들거나 「장황하게 길게」 만들지 않습니다). medium만 2.40배로 약간 높은 것은, fast와 표준 모드 간에 prompt cache (프롬프트 캐시)가 공유되지 않아 (별도 풀 사용) 발생하는 캐시 히트율(cache hit rate)의 변동이 원인으로 보입니다. 참고로 비용은 소비 토큰 × API 공식 단가로 산출하였으며, 이 환산값은 CLI가 보고하는 total_cost_usd와 총 240회 시행 결과가 일치합니다.

여기서 품질을 거의 일정하게 유지한 채 effort level (노력 수준)을 low → xhigh로 움직이면, (D, C)의 점들은 모드별로 거의 일직선상에 놓입니다. 서두에 제시했던 그래프를 다시 보여드립니다.

冒頭に掲げた処理時間-コストのグラフ（再掲）。横軸 D（実行時間 s）に対し縦軸 C（API 利用料金 $）をプロットすると、effort 4 点がモードごとにほぼ一直線に並ぶ。fast（青）の直線は標準（オレンジ）より左上にあり、傾きが急

그래프의 점은 3개 태스크의 합계값(각 태스크 중앙값의 합)이므로, 앞서 나온 표의 약 3배 스케일입니다.

mode	회귀식 (C = a·D + b)	기울기 a ($/1000s)	R²	n
표준	C = 0.00304·D + 0.213	3.04	0.995	4
fast	C = 0.01600·D + 0.195	16.00	0.999	4

회귀 분석은 각 모드의 effort level 4개 지점에 대한 OLS (최소제곱법)입니다. n이 작기 때문에 계수의 신뢰 구간은 넓으며, 선형성과 기울기의 대비가 주된 목적입니다.

기울기는 fast가 표준의 약 5배입니다. fast의 세계에서는 동일한 「1초」에 소요되는 비용이 높습니다. 즉, 시간축이 압축된 만큼 1초의 가격이 약 5배가 된 셈입니다.

그렇다면 이 구매는 비싼 것일까요, 저렴한 것일까요? 풀(pool) 중앙값으로 계산하면, 1회 시행당 19.6초의 단축을 $0.215에 사고 있는 것입니다. 즉:

단축 1초 ≒ $0.011, 단축 1분 ≒ $0.66, 단축 1시간 ≒ 약 $40

판단 기준은 간단합니다. 화면 앞에서 결과를 기다리는 사람의 시간이 시급 $40 이상의 가치가 있다면 fast는 흑자입니다. 반대로 야간 배치(batch) 작업이나 방치해 두는 태스크라면 대기 시간의 가치가 제로이므로, 2배를 지불할 이유가 없습니다.

품질(Q): fast로 설정해도 품질은 떨어지지 않았다

medium 이상에서는 표준·fast 모드 모두 gate (게이트) 통과율 100%, Q 중앙값 100으로 완전히 포화 상태입니다. 서두른 만큼 발생하는 누락은 관측되지 않았습니다.

low의 경우에만 두 모드 모두 T2에서 실패가 발생했습니다 (T2 통과율은 표준 30% / fast 20%, 전체 gate 통과율은 77% / 73%). 다만 이는 fast 여부와 관계없이 나타나는 low effort 고유의 현상이며, 지난 #24에서도 표준 모드의 low는 동일한 지점에서 실패했습니다.

즉 이번 태스크 범위 내에서, fast는 「대충 빠르게」 하는 것이 아니라 「같은 일을 빠르게」 하고 있음을 확인했으며, 품질을 희생하지 않는다는 점을 검증했습니다.

함정——fast는 말없이 표준 모드로 전환된다

이번에 가장 「모르면 곤란한」 발견은 이것입니다. fast를 지정한 120회의 시행 중 2건(1.7%)이 에러나 경고 없이 표준 모드로 실행되었습니다. fast mode에는 전용 rate limit (속도 제한)이 있어, 이를 초과하면 자동으로 표준 모드로 fallback (폴백)되는 사양이며, 과금 또한 자동으로 표준 모드로 처리됩니다. 병렬 실행이 아닌 순차 실행에서도 이 정도 빈도로 발생했습니다.

실운영에서의 영향:

일상적인 사용에서는 실질적인 해가 적음 (오히려 친절한 사양. 멈추지 않고 과다 청구되지도 않음)
측정·벤치마크에서는 치명적 (fast로 의도한 시행에 표준 모드가 섞임)
비용 관리·견적에서도 주의 필요 ("fast 단가로 견적을 냈는데 standard로 동작했다"의 역패턴도 발생 가능)

교훈으로서, fast 모드를 전제로 측정이나 원가 계산을 수행한다면 실행 로그의 usage.speed (실제로 어떤 속도로 응답했는지)를 시행마다 확인하는 것이 필수입니다. 본 기사의 fast 모드 통계는 이 검증을 통해 fallback으로 판명된 2건을 제외한 결과입니다.

요약

Claude Code의 fast 모드를 Opus 4.8 고정 및 240회 시행으로 QCD 비교한 결과, 세 가지 발견이 있었습니다.

D (Duration): 처리 시간은 약 1.9배 빠름 (거의 절반으로 단축). 「2.5배」는 출력 속도에 관한 이야기이며, 툴 실행(tool execution)이나 응답 대기 시간은 빨라지지 않음. 깊게 생각하는 고(high) effort 모드일수록 단축률이 큼 (xhigh에서 2.34배).
C (Cost): 비용은 거의 단가 그대로인 약 2배. 소비 토큰량은 변하지 않음.
Q (Quality): 품질은 떨어지지 않음. medium 이상은 두 모드 모두 모든 시행에서 게이트(gate) 통과.

「2배를 내면 2배 빠르다」에 대한 답은, "품질은 그대로 유지하면서 약 1.9배 빠름. 실체는 1시간 단축 ≒ 약 $40의 시간을 구매하는 것"이었습니다. 활용법도 간단하여, 급할 때는 fast, 방치할 수 있다면 표준(standard) 모드를 사용하세요. 그리고 fast 모드를 전제로 무언가를 측정하거나 견적을 낸다면, 무언의 폴백(fallback)에 주의하십시오.

태스크 설계·채점의 상세 내용과, 동일한 하네스(harness)에서의 Claude Fable 5와 Opus 4.8 비교는 이전 회차인 #24에 있습니다.

본 기사는 필자 개인의 Raspberry Pi 5 / Ubuntu 26.04 환경에서의 비공식적인 실험 기록입니다. Claude Code 및 fast mode의 일반적인 성능 우열을 나타내는 것이 아닙니다. 결과는 태스크 내용, 프롬프트(prompt), CLI 버전, 모델 지정, 네트워크 상황, 실행 순서, 온도(temperature) 조건에 따라 변화합니다. 각 명칭은 각 사 및 각 단체의 상표 또는 등록상표입니다.

이 기사는 「어른의 자유연구」 시리즈의 제25회입니다. 소비재 제조사에서 디지털 전략을 추진하는 필자가 최신 테크놀로지를 자신의 손으로 시험하며, 무엇을 할 수 있는지, 어떤 가치를 창출하는지를 검증하는 과정을 기록하고 있습니다.

※ 본 연재는 개인의 실험과 배움을 공유하는 것이며, 소속 조직의 공식 견해가 아닙니다.