사고를 끌 수 없는 OSS 코딩 모델 Kimi K2.7 Code

API에서 reasoning을 끄려고 하면 에러가 반환된다. 이것이 Kimi K2.7 Code를 접하며 가장 먼저 마주친 문제였다. 많은 추론 모델(reasoning models)은 '생각할지/즉답할지'를 요청마다 선택할 수 있는 것이 당연해졌지만, Moonshot AI가 6월 12일에 Hugging Face에 공개한 이 모델은 사고 모드(thinking mode)를 상시 온(on) 상태로 고정하여 사용자 측의 무효화를 허용하지 않는다.

moonshotai/Kimi-K2.7-Code는 해당 회사의 오픈 웨이트(open-weight) 계열 K2의 최신작에 해당하는 코딩 특화 모델이다. 라이선스는 Modified MIT이다. 대규모 배포에서도 귀속 표시만 하면 상업적 이용이 가능하다. 가중치(weights)를 손에 넣어 직접 구동할 수 있다는 점에서 GPT-5.5나 Gemini 3.5와 같은 폐쇄형(closed) 경쟁 모델과는 입지가 다르다.

아키텍처는 Mixture-of-Experts (MoE)이다. 총 파라미터(parameters) 1조 개에 대해, 토큰당 활성화(activation)는 320억 개에 머문다.

항목	값
총 파라미터	1T
...
API 요금은 다음과 같다. 캐시 히트(cache hit) 시의 입력 단가가 크게 낮아지는 것은, 긴 시스템 프롬프트(system prompt)나 코드베이스를 반복해서 읽게 하는 에이전트(agent) 용도를 명확히 의식한 설계다.

| 가격 / 100만 토큰 |
|---|---|
| 입력 | $0.95 |
| ... |
이 모델의 핵심은 성능 수치보다 설계 사상에 있다. 모델 카드(model card)에는 preserve_thinking을 True로 고정한다고 명시되어 있으며, 추론 체인(reasoning chain)은 멀티 턴(multi-turn) 대화를 가로질러 유지된다. 한 번의 응답에서 생각하고 버리는 것이 아니라, 과거에 자신이 거쳐온 추론을 문맥(context)으로 가져간다. 장기적인 소프트웨어 개발, 즉 계획을 세우고, 파일을 편집하고, 도구를 실행하고, 테스트 출력을 읽고, 디버깅하는 수십 단계의 작업을 하나의 흐름으로 다루는 것을 전제로 하고 있다.

흥미로운 점은 사고를 강제하고 있음에도 불구하고, 이전 세대인 K2.6보다 사고 토큰(thinking tokens) 소비를 약 30% 줄였다고 Moonshot이 주장하고 있다는 점이다. '항상 생각한다'와 '토큰을 소비하지 않는다'는 보통 트레이드오프(trade-off) 관계가 되지만, 여기서는 이를 양립시켰다. 추론의 중복성을 줄이는 방향으로 튜닝(tuning)되었다고 볼 수 있다. 실무에서 추론(reasoning) 계열 모델을 사용하면, 출력 토큰 과금이 사고 분량 때문에 늘어나 비용 예측이 어려워지는 것이 고민거리인데, 이 부분을 개선했다는 점은 매우 영리한 접근이라고 생각한다.

다만, 무효화할 수 없는 설계에는 부작용도 있다. 단순 보완이나 정형 변환처럼 '생각할 필요도 없는' 태스크(task)에도 추론 비용이 발생한다. 샘플링 파라미터(sampling parameters)도 temperature 1.0 / top_p 0.95로 고정되어 있어, 출력의 변동 폭을 스스로 조절할 수 없다. 결정적인 동작이 필요한 CI 상의 생성이나, 저지연(low latency)이 필요한 인라인 보완(inline completion)에는 솔직히 이 절충안이 맞지 않는다. 에이전트적인 태스크에 용도를 한정한 모델이라고 이해한 상태에서 채택 여부를 결정해야 한다.

API는 OpenAI 호환이므로, 기존 클라이언트의 base_url과 model을 교체하는 것만으로 동작한다. 모델 카드의 샘플은 다음과 같다.

import openai
client = openai.OpenAI() # API 키와 base_url을 설정
messages = [
...

주목할 점은 message.reasoning과 message.content가 분리되어 반환된다는 것이다. 사고 과정과 최종 답변을 별도의 필드로 받을 수 있으므로, 로그에는 추론 내용만 남기고 UI에는 결론만 보여주는 식의 분리 처리를 앱 측에서 수월하게 작성할 수 있다.

오픈 웨이트이므로 직접 구동할 수도 있다. 추론 서버로는 vLLM 또는 SGLang이 안내되고 있다.

pip install vllm
vllm serve "moonshotai/Kimi-K2.7-Code"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K2.7-Code"

하지만 여기서 현실적인 장벽에 부딪힌다. MarkTechPost의 측정에 따르면 1조 개의 파라미터(parameter) 가중치는 디스크 상에서 약 595GB에 달한다. 개인용 워크스테이션(workstation)에 가볍게 내려받을 수 있는 크기가 아니며, 제대로 추론(inference)을 돌리려면 멀티 GPU 노드(multi-GPU node)가 필요하다. "오픈 웨이트(open weights) = 누구나 집에서 실행 가능"이라고 단순하게 생각하기 쉽지만, K2.7 Code의 경우 API로 사용하거나, 상응하는 인프라(infrastructure)를 갖춘 팀이 사내 호스팅을 하는 선택지로 나뉜다.

Moonshot이 발표한 점수는 모두 자사의 이전 세대인 K2.6 대비 개선 폭으로 제시되었다.

벤치마크 (Benchmark)	K2.7 Code	K2.6 대비
Kimi Code Bench v2	62.0	+21.8%
...

이 부분은 냉정하게 살펴볼 필요가 있다. Kimi Code Bench v2나 MLS Bench Lite는 자사가 정의한 벤치마크(benchmark)이므로, 절대값의 비교 대상이 부족하다. 출시 직후의 보도(TechTimes)에서도 독립적인 벤치마크에 제출하지 않은 점이 지적된 바 있다. 도구 활용 능력을 측정하는 MCPMark에서 81.1이라는 수치는 에이전트(agent) 용도를 겨냥하는 모델로서 나쁘지 않은 반응이지만, 제3자의 검증이 모두 나올 때까지는 "벤더(vendor) 공표"의 범주를 벗어나지 않는다. 결국 자신의 리포지토리(repository)에 실제 코드를 적용해 측정해 보는 것이 가장 빠르다.

종합적으로 볼 때, K2.7 Code는 "항상 사고하는 에이전트용 모델"이라는 한 점에 집중한 결단력 있는 출시라고 느껴진다. 사고의 상시 활성화(always-on thinking), 토큰(token) 효율 개선, OpenAI 호환 API, 오픈 웨이트(open weights)라는 조합은 자사의 코드 에이전트 기반을 확보하려는 팀에게 시험해 볼 가치가 있다. 반면, 비활성화할 수 없는 추론과 거대한 가중치는 용도와 인프라를 가린다. 범용적인 만능 모델이 아니라, 쓰임새가 정해져 있는 도구로서 평가하는 것이 올바르다.