Kimi K2.7 Code: 토큰 30% 절감이 청구서를 낮출까요? (2026)

요약(TL;DR). Kimi K2.7 Code는 K2.6과 동일한 토큰당 비용을 지불합니다 ($0.95/M 입력, $4.00/M 출력), 그리고 캐시 읽기 비용이 약간 더 높습니다 ($0.19/M 대 $0.16/M). 따라서 청구서가 낮아지는 것은 Moonshot의 모델이 추론(thinking) 토큰을 약 30% 적게 사용한다는 주장에 전적으로 달려 있습니다. 이 절감액은 추론 작업이 지출에서 우위를 점하는 경우에만 실질적인 돈입니다. 추론 중심 작업에서는 청구서가 30%가 아니라 약 13% 떨어집니다. 입력(input) 중심 작업에서는 1% 미만 떨어집니다. 텍스트 전용 추론 작업을 위해서는 K2.7 Code (moonshotai/kimi-k2.7-code)를 선택하고, 이미지 처리나 짧은 출력이 필요한 작업에는 K2.6 (moonshotai/kimi-k2.6)을 유지하세요. 이 과장된 주장의 근거가 되는 벤치마크는 모두 공급업체 보고 자료이며 검증되지 않았으므로, 신뢰해야 할 유일한 숫자는 본인의 청구서입니다.

요약(TL;DR): 어떤 것을 선택해야 할까요?

한 문장 결론: 코딩 트래픽이 텍스트 전용이고 추론 중심이라면 K2.7 Code가 실질적인 비용 절감을 가져오지만, 다른 모든 경우에서

1. 토큰당 가격(Per-token price)은 동일합니다. 두 모델 모두 입력(in) $0.95, 출력(out) $4.00입니다. 이미 K2.6의 가격을 산정했다면, K2.7 Code의 토큰당 요율도 이미 산정한 셈입니다.
2. K2.7 Code의 캐시 읽기(Cache reads) 비용이 더 비쌉니다. $0.16/M 대비 $0.19/M입니다. 만약 귀하의 파이프라인이 캐시된 컨텍스트(cached context)를 많이 재사용한다면, K2.7 Code는 해당 항목에서 더 비싼 모델이 됩니다. 작은 차이지만, "더 저렴하다"는 프레임워크에 반하는 부분입니다.
3. K2.7 Code는 텍스트 전용입니다. 사람들이 놓치는 세부 사항은 ofox의 Code 변형 모델은 이미지를 지원하지 않는다는 점입니다. K2.6은 지원합니다. 또한 동일한 가격의 moonshotai/kimi-k2.7-code-highspeed 변형 모델이 있지만, 이 역시 텍스트 전용입니다.

따라서 가격 동일성에 더해 더 나쁜 캐시 요율을 고려하면, 청구 금액을 낮출 수 있는 레버(lever)는 정확히 하나뿐이며, 그것은 바로 추론 토큰(thinking-token)의 감소입니다. 이 포스트의 나머지 내용은 그 레버가 귀하의 특정 인보이스(invoice)를 실제로 변화시킬 수 있는지에 관한 것입니다.

코딩 벤치마크: Moonshot이 보고한 내용 (그리고 검증되지 않은 내용)

K2.6 대비 K2.7 Code에 대한 Moonshot의 출시 수치는 강력해 보입니다. 각 행에 주의 사항이 첨부된 수치는 다음과 같습니다.

벤치마크 (Benchmark)	K2.6	K2.7 Code	보고된 이득 (Reported gain)	제3자에 의해 검증되었는가?
Kimi Code Bench v2	50.9	62.0	+21.8%	아니오
...

마지막 열을 두 번 읽어보십시오. 세 가지 모두 **Moonshot 자체의 독점 벤치마크(proprietary benchmarks)**입니다. 독립적인 재현 결과는 없으며, 6월 12일 출시 시점 기준으로 업계의 다른 모델들이 실제로 비교 대상으로 삼는 SWE-bench Verified, LiveCodeBench 또는 GPQA에 대한 공개 결과는 없었습니다.

VentureBeat는 실무자들이 해당 벤치마크를 신뢰할 수 없다고 말한다는 헤드라인으로 이번 출시를 다루었습니다. 연구원 Elliot Arledge는 공개 GPU 커널 벤치마크인 KernelBench-Hard에서 K2.7 Code를 K2.6과 비교 실행했으며, 튜닝이 더 좋지 않은 상태에서 MoE-커널 점수가 K2.6의 0.222에서 0.157로 하락(regressed)했습니다. 따라서 Moonshot 외부에서 보는 모습은 기껏해야 엇갈린 반응이며, 최악의 경우 적어도 하나의 공개 테스트에서는 정반대의 결과를 가리키고 있습니다.

이러한 수치들을

만약 추론 (thinking) 비용이 전체 청구서의 전부라면, 30%에 가까운 절감 효과를 얻을 수 있습니다. 반대로 추론이 아주 일부분이라면, 그만큼의 아주 작은 절감 효과만 얻게 됩니다. 결과(outcome)를 결정하는 변수는 전체 지출 중 추론 (reasoning)에 할당되는 비중이며, 이는 거의 전체에 달하는 경우(에이전트형 (agentic), 다단계 코딩)부터 거의 제로에 가까운 경우(긴 입력, 한 줄 답변)까지 다양합니다.

Moonshot은 에이전트형 예시를 통해 이를 구체적으로 설명합니다. 12시간 동안 실행했을 때 추론 토큰 (reasoning tokens)이 약 200만 개에서 약 140만 개로 감소하며, 이것이 바로 30%라는 수치입니다. 이는 벤더(vendor) 측의 예시일 뿐 귀하의 트래픽을 직접 측정한 결과는 아니지만, 추론 토큰이 지배적인 작업이야말로 이번 비용 절감이 설계된 핵심 영역이라는 점을 보여줍니다.

실수는 이 12시간짜리 에이전트 실행 사례를 모든 작업에 일반화하는 것입니다. 20만 토큰을 읽고 200 토큰을 쓰는 요약 (summarization) 호출은 정반대의 프로필을 가지며, 절감 효과를 거의 보지 못할 것입니다. 다음 섹션에서는 양극단의 사례에 대해 달러($) 단위로 계산해 보겠습니다.

추론 지출 비중을 추측할 필요는 없습니다. API가 알려주기 때문입니다. 모든 응답에는 prompt_tokens와 completion_tokens가 포함된 usage 객체가 포함되어 있습니다. 추론 토큰은 완료 토큰 (completion tokens)에 포함되어 있으므로, 귀하가 관심을 가져야 할 비중은 completion_tokens × $4.00/M을 전체 청구 금액으로 나눈 값입니다. 실제 트래픽이 발생하는 대표적인 일주일 동안 이를 기록하면, 모델 문자열을 단 하나도 바꾸기 전에 귀하가 1%에서 26% 사이의 범위 중 정확히 어디에 위치하는지 알 수 있습니다. Moonshot의 예시가 아니라, 바로 이 측정된 비율이 전환의 경제성을 결정합니다.

가격 산출 방식: 실제 월간 청구서

$0.95/$4.00 요율을 기준으로 재계산한 두 가지 실행 예시입니다. 캐시 히트 (cache hits)는 가정하지 않았으므로, 이를 통해 추론 토큰 (thinking-token)의 효과만을 분리하여 확인할 수 있습니다. 산식은 의도적으로 단순하게 구성했으므로 직접 다시 계산해 보셔도 좋습니다.

예시 1: 추론 집약적 코딩 작업

프로필: 입력 토큰 50,000개, 출력 토큰 20,000개. 이 중 70%(14,000개)는 추론 (thinking)이고 30%(6,000개)는 가시적인 답변입니다. 이는 계획, 추론, 수정 과정을 거치는 에이전트형 코딩 (agentic coding)의 형태입니다.

항목	K2.6	K2.7 Code
입력 (50,000 × $0.95/M)	$0.0475	$0.0475
...

청구 금액 절감: ($0.1275 − $0.1107) / $0.1275 = 13.2%.

무슨 일이 일어났는지 주목하세요. 사고 토큰 (Thinking tokens)은 30% 감소했습니다 (14,000 → 9,800). 하지만 전체 출력 (Output) 토큰은 21%만 감소했습니다 (20,000 → 15,800). 눈에 보이는 답변의 양은 줄어들지 않았기 때문입니다. 그리고 청구 금액 (Bill)은 단 13.2%만 감소했는데, 이는 여기서 비용의 3분의 1을 차지하는 입력 (Input) 토큰이 전혀 변하지 않았기 때문입니다. "30%"라는 헤드라인은 청구서에 도달했을 때 13%가 되었습니다. 이는 공식과 일치합니다: 0.30 × (사고 비용 $0.0560 / 총 비용 $0.1275) = 13.2%.

이를 실제 작업량인 하루 1,000개의 작업, 30일 기준으로 확장하면 다음과 같습니다:

모델	월간 청구 금액
K2.6	$3,825.00
...

한 달에 504달러를 아끼는 것은 가치가 있습니다. 다만, 단순하게 "$3,825에서 30% 할인"이라고 계산하여 $1,147를 예산으로 잡지는 마세요.

예시 2: 입력 중심 작업 (절감 효과가 거의 없음)

프로필: 입력 토큰 200,000개, 출력 토큰 4,000개, 이 중 40%(1,600개)가 사고 토큰입니다. 이는 RAG (검색 증강 생성), 긴 문서 Q&A, 또는 요약 작업과 같이 읽는 양은 많고 쓰는 양은 적은 경우에 해당합니다.

항목	K2.6	K2.7 Code
입력 (200,000 × $0.95/M)	$0.1900	$0.1900
...
청구 금액 절감: ($0.2060 − $0.2041) / $0.2060 = 0.93%.

1% 미만입니다. 출력은 입력에 비해 반올림 오차 수준에 불과하므로, 출력의 일부에서 발생하는 30%의 절감은 청구서상에서 보이지 않습니다. 이러한 부하 프로필(Load profile)의 경우, 비용 문제로 K2.7 Code로 전환하는 것은 무의미하며, 만약 캐시된 입력 (Cached input)을 사용한다면 K2.6의 더 저렴한 캐시 읽기 비용($0.16 대 $0.19) 덕분에 K2.6이 명백히 더 저렴한 모델이 됩니다.

예시 3: 12시간 에이전트 실행 (최대치)

Moonshot의 헤드라인 예시는 추론 토큰 (Reasoning tokens)이 약 2M에서 약 1.4M으로 감소하는 12시간의 에이전트 (Agentic) 실행입니다. 이는 제가 아닌 그들의 수치이지만, 30% 헤드라인에 가장 근접한 프로필이기에 비용을 산출해 볼 가치가 있습니다. 이 실행 과정에서 약 500K의 입력을 읽고 약 200K의 가시적인 출력(도구 호출 (Tool calls), 파일 편집, 최종 요약)을 생성한다고 가정합니다.

항목	K2.6	K2.7 Code
입력 (500,000 × $0.95/M)	$0.475	$0.475
...
청구 금액 절감: ($9.275 − $6.875) / $9.275 = 25.9%.

이보다 더 좋을 수는 없습니다. 여기서 청구 금액의 압도적인 비중을 차지하는 것은 추론 (Reasoning)이므로, 절감 효과가 거의 그대로 전달됩니다. 그럼에도 불구하고 30%가 아닌 26%인 이유는 입력 (Input)과 가시적 출력 (Visible Output)은 변하지 않기 때문입니다. 하루에 이 작업을 20번씩 한 달 동안 수행한다면 그 차이는 실질적입니다:

모델	월간 청구 금액 (하루 20회 × 30일)
K2.6	$5,565
...

만약 귀하의 트래픽이 진정으로 긴 자율 에이전트 (Autonomous Agent) 실행 형태를 띤다면, K2.7 Code는 제값을 합니다. 귀하의 부하 (Load)가 해당 프로필에서 벗어나 예시 2에 가까워질수록, 절감 효과는 줄어듭니다.

세 가지 예시는 실제 세계를 포괄합니다. 귀하의 청구 금액 절감 폭은 트래픽이 얼마나 추론 집약적인지에 따라 약 1%에서 약 26% 사이가 될 것이며, 일반적인 혼합 코딩 워크로드 (Mixed Coding Workload)는 중간 지점인 13% 정도에 위치합니다. 출력이 전부 추론에 가까울수록 헤드라인 수치에 근접하게 되며, 청구 금액 중 입력 비중이 높을수록 절감액은 적어집니다.

캐시 항목이 K2.7 Code에 불리하게 작용하는 점

"30% 더 저렴하다"는 이야기에서 간과하고 있는 숫자가 하나 더 있습니다. 바로 캐시 읽기 (Cache reads)입니다. K2.7 Code는 캐시된 입력을 $0.19/M로 청구하는 반면, K2.6은 $0.16/M로 청구합니다. 이는 더 저렴한 선택지여야 할 모델에서 모든 캐시된 토큰에 대해 19%의 프리미엄을 지불하는 셈입니다.

컨텍스트 (Context)를 재사용할 때마다 이 점이 중요해집니다. 동일한 저장소 (Repo)에 대한 코드 리뷰 루프, 시스템 프롬프트와 코드베이스를 다시 전송하는 멀티 턴 에이전트 (Multi-turn Agent) 세션, 안정적인 코퍼스 (Corpus)에 대한 RAG 등 이 모든 것은 입력의 대부분이 캐시에 걸리게 됩니다. 캐시 효과를 격리하기 위해 두 모델 간의 출력을 동일하게 유지하고, 캐시 적중률 (Cache hit)이 80%인 300K 입력 작업을 가정해 보겠습니다:

Line	K2.6	K2.7 Code
Fresh input (60,000 × $0.95/M)	$0.0570	$0.0570
...
K2.7 Code는 입력만으로도 작업당 $0.0072 더 비쌉니다. 하루에 1,000개 이상의 캐시 사용이 많은 작업을 한 달 동안 수행할 경우, 이 비용은 절감된 추론 토큰(thinking-token)을 통해 상쇄해야 하는 약 $216/월 추가 지출을 발생시킵니다. 캐시를 통한 읽기 작업이 많고 추론 출력이 적은 작업 프로필(캐싱이 추가된 Example 2 형태)의 경우, K2.7 Code가 오히려 더 비싼 모델일 수 있습니다. '새로운 것이 = 더 저렴하다'라고 가정하기 전에 반드시 자체 캐시 적중률과 비교해 볼 가치가 있습니다.

K2.7 Code를 선택해야 할 때

다음 조건들이 모두 충족될 경우 moonshotai/kimi-k2.7-code를 선택하세요:

• 작업이 텍스트 전용일 때. 루프에 이미지가 포함되지 않아야 합니다.
• 작업이 추론 중심적(reasoning-heavy)일 때. 즉, 보이는 답변 대비 긴 사고 과정(thinking traces)을 가질 때입니다. 에이전트 코딩(Agentic coding), 다단계 디버깅, 계획 수립이 많은 작업에 해당합니다.
• **캐시 재사용(cache reuse)**에 크게 의존하지 않을 때 (만약 크게 의존한다면, K2.7 Code의 $0.19/M 캐시 읽기 비용은 K2.6의 $0.16/M보다 더 비쌉니다).

이러한 프로필에서는 30% 추론 토큰 절감이 두 자릿수 청구서 감소로 이어집니다. 이 특정 형태의 작업에 대해서는 진정한 이점입니다. 동일한 가격으로 더 높은 처리량(throughput)을 원한다면 moonshotai/kimi-k2.7-code-highspeed를 사용하세요. 토큰 계산은 변하지 않습니다.

K2.6을 유지해야 할 때

다음 조건 중 어느 하나라도 충족될 경우 moonshotai/kimi-k2.6에 머무르세요: