🔥 Kimi K2.6 — 혼자 12시간 일하는 모델이 왔다

#kimi#moonshot-ai#LLM#open-source#agent-swarm

993자

13분

강의 목차

뭐가 풀렸나
12시간짜리 런이 말하는 것
벤치마크는 솔직하게 읽어야 한다
300-에이전트 스웜은 정말 필요한가
가격과 라이선스의 현실
내가 생각하는 것
참고 자료

Kimi K2.6 히어로 비주얼
출처: Kimi K2.6 Tech Blog

오늘 아침에 Kimi K2.6 릴리스 블로그를 읽다가 스크롤을 멈췄다. 벤치마크 표 때문이 아니었다. 한 문장 때문이었다.

"4,000+ tool calls, over 12 hours of continuous execution, and 14 iterations."

모델이 혼자 12시간을 일했다. 4천 번 넘게 툴을 호출했다. 그런데 궤도를 이탈하지 않았다. 진짜인지 선뜻 믿기가 어려웠다.

뭐가 풀렸나

Moonshot AI가 Kimi K2.6을 2026년 4월에 공개했다. 1조 파라미터 MoE, 활성 32B, 256K 컨텍스트, Modified MIT 라이선스 (verified 2026-04-21). K2.5 대비 "조용한 마이너 업데이트" 같은 버전 번호지만, 읽어보면 전혀 그렇지 않다.

세 가지가 달라졌다.

첫째, 오래 돌아간다. K2.5에서 100 sub-agent · 1,500 step이 천장이었던 Agent Swarm이 K2.6에서는 300 sub-agent · 4,000 step까지 동시에 움직인다. 수직 스케일링이 아니라 수평 스케일링이라는 점이 포인트다.

둘째, 코딩이 단순 패턴 완성을 넘는다. 블로그에 실린 exchange-core 사례에서 모델은 13시간 동안 1,000번 넘게 툴을 호출하며 4,000줄 이상을 수정했다.

셋째, SWE-Bench Pro에서 58.6%로 GPT-5.4(57.7%), Claude Opus 4.6(53.4%), Gemini 3.1 Pro(54.2%)를 모두 눌렀다 (verified 2026-04-21).

Kimi Code Bench 내부 벤치마크 비교
출처: Kimi K2.6 Tech Blog

마지막 줄은 조심해서 읽어야 한다. Kimi 자체 숫자다. SiliconANGLE 리포트와 the-decoder가 같은 숫자를 그대로 인용해 실은 상태고, 제3자 독립 재현 보고는 공개 자료에서 아직 충분히 모이지 않은 듯하다. 그래도 Vercel이 내부 Next.js 벤치에서 "K2.5 대비 50% 이상 향상"을 Kimi 블로그에 직접 인용으로 붙여준 건 쉽게 볼 일이 아니다.

12시간짜리 런이 말하는 것

나는 벤치마크 표보다 사례 연구가 더 흥미로웠다. 블로그에 실린 두 건이 있다.

하나는 Mac에서 Qwen3.5-0.8B를 돌리는 추론 엔진을 Zig로 새로 짜는 실험이다. 12시간, 4,000번 이상의 tool call, 14번의 iteration을 거쳐 throughput을 약 15 tokens/sec에서 약 193 tokens/sec까지 끌어올렸다고 한다. 최종적으로는 LM Studio보다 20% 빠른 결과를 냈다고 명시했다 (verified 2026-04-21).

Zig라는 선택이 재미있다. 훈련 데이터에 Python, Rust, Go는 넘쳐나도 Zig 샘플은 희소할 것이다. out-of-distribution 일반화를 일부러 보여주려는 의도가 읽힌다. 실제로 그 일반화가 된 건지, 아니면 훈련 말미에 특수하게 섞은 건지는 외부에서 알 수 없다. 의심해봐야 할 부분이다.

다른 하나가 더 세다. exchange-core는 LMAX Disruptor 기반의 실제 오픈소스 매칭 엔진이다. Kimi 블로그 표현으로 "8년 된" Java 프로젝트이고, 단일 오더북에서 초당 5M 오퍼레이션을 처리하는 물건이다. K2.6은 13시간 동안 혼자 돌며 플레임 그래프를 읽고, 코어 스레드 토폴로지를 4ME+2RE에서 2ME+1RE로 뜯어고치고, medium throughput을 0.43 MT/s에서 1.24 MT/s로 끌어올렸다. 185% 상승이다. 이미 성능 한계 근처에 있던 시스템이었다고 한다 (verified 2026-04-21).

이게 진짜면 게임이 바뀐다. 정확히는, 이미 바뀌었다는 뜻이다. 시니어 엔지니어가 하루 꼬박 붙어서 할 최적화를, 적어도 플레임 그래프를 읽고 가설을 세우고 반복하는 파트를, 모델이 혼자 끝까지 끌고 간다. 중간에 context를 잃지 않은 채로.

벤치마크는 솔직하게 읽어야 한다

표를 눈으로 훑다 보면 K2.6이 전부를 이긴 것처럼 보이지만 자세히 보면 그렇지 않다.

Terminal-Bench 2.0 (Terminus-2)에서는 K2.6이 66.7, Gemini 3.1 Pro가 68.5다. LiveCodeBench v6에서도 K2.6 89.6 vs Gemini 3.1 Pro 91.7로 밀린다. SWE-Bench Verified는 K2.6 80.2 vs Claude Opus 4.6 80.8로 거의 동률이다. 순수 추론 벤치인 HLE-Full(툴 없이)에서는 34.7로 Gemini 3.1 Pro의 44.4에 크게 뒤진다. BabyVision w/ python은 K2.6 68.5 vs GPT-5.4 80.2로 간극이 크다 (모두 Kimi 공식 블로그 표, verified 2026-04-21).

정리하면 이렇다. K2.6은 agentic coding과 long-horizon execution에서 프런티어급이다. 그런데 순수 reasoning, vision, 일부 tool-heavy 벤치에서는 한 칸씩 밀린다. "오픈소스가 드디어 GPT-5.4와 Claude를 잡았다" 같은 헤드라인은 맞기도 하고 틀리기도 하다. 쓸 작업 도메인에 따라 완전히 다른 답이 나온다.

불만의 목소리도 있다. Hacker News 스레드 같은 커뮤니티에서는 "생각하기 모드가 오히려 반응을 둔하게 만든다"는 식의 의견이 섞여 나온다. 인상 수준의 피드백이라 가중치는 조심해서 둘 일이다. K2.5 계열이 제기됐던 long-context degradation 이슈가 K2.6에서 얼마나 해결됐는지도, 외부 reproducibility 보고가 쌓이기 전까지는 판단이 이르다.

300-에이전트 스웜은 정말 필요한가

이 부분에서 나는 조금 망설여진다.

K2.6은 Agent Swarm을 300 에이전트·4,000 스텝까지 확장하고, 거기에 Claw Groups라는 새 개념을 연구 프리뷰로 얹었다. Claw Groups는 한마디로 이기종 에이전트 협업 공간이다. 내 노트북에서 돌아가는 에이전트, 네 모바일 에이전트, 클라우드 에이전트가 같은 워크스페이스에서 K2.6을 코디네이터로 삼아 협업한다는 그림이다.

멋진데, 질문이 있다. 300개를 동시에 띄울 만한 과제가 개인 개발자에게 얼마나 있을까. Moonshot이 소개한 예시도 기업 마케팅 워크플로우 중심이다. McKinsey 스타일 PPT를 자동화하거나, LA에서 웹사이트 없는 30개 매장을 스크래핑해 각각 랜딩 페이지를 만드는 식이다. 확실히 현실적인 수요이긴 하다. 하지만 개인 프로젝트로 내려오면 "코드 한 덩어리를 깔끔하게 고쳐주는 한 에이전트"가 훨씬 쓸모있다.

스웜은 과제가 본질적으로 병렬일 때 빛난다. 직렬 의존성이 강한 디버깅 세션에서 300 에이전트는 오히려 노이즈다. 마케팅 측면에서는 좋은 숫자지만, 엔지니어링 측면에서는 "내 워크로드가 진짜 병렬화 가능한가"를 먼저 물어야 한다.

가격과 라이선스의 현실

내가 쓸 수 있냐는 관점에서 보자.

OpenRouter 기준 Kimi K2.6은 입력 $0.60 / 출력 $2.80 per 1M tokens다 (verified 2026-04-21). K2.5가 $0.38 / $1.72였던 걸 생각하면 올랐다. 그래도 Claude Opus 4.6이나 GPT-5.4 tier에 비하면 여전히 훨씬 저렴하다. Cloudflare Workers AI에서 바로 돌릴 수 있고, Hugging Face에서 가중치도 받을 수 있다. 자기 인프라에 얹고 싶으면 얹을 수 있다.

라이선스는 Modified MIT다. 월 활성 사용자 1억 명 이상이거나 월 매출 2천만 달러 이상인 상용 제품에서 사용하면 UI에 "Kimi K2.6" 크레딧을 표시해야 한다 (verified 2026-04-21). 대부분의 개발자와 스타트업은 해당되지 않는다. 조심해야 할 쪽은 빅테크다.

내가 생각하는 것

밤에 이 블로그를 다시 읽으면서 느낀 건 숫자보다 방향이다.

예전에는 모델 업그레이드가 "파라미터 더 많이, 벤치마크 더 높게"였다. K2.6을 읽으면 "얼마나 오래 자율적으로 도는가, 얼마나 툴을 제대로 쓰는가, 얼마나 여러 에이전트가 엮일 수 있는가"로 스코어보드가 이동했다는 느낌이 든다. Moonshot은 여기에 오픈웨이트로 카드를 내밀었다. 2025년 중반까지 "오픈소스는 프런티어를 영원히 못 따라잡는다"는 말이 정설처럼 돌았는데, 그게 조금씩 틀려가는 중이다.

그래도 나는 아직 프로덕션 디버깅을 K2.6에게 12시간 맡길 용기는 없다. 블로그에 실린 사례는 성공 사례고, 실패한 13시간짜리 런은 당연히 보여주지 않는다. 이번 주말에 작은 리팩토링 하나에 Kimi Code CLI를 붙여 한 세션만 돌려볼 생각이다. context를 어떻게 관리하는지, tool call을 어떻게 고르는지 내 눈으로 확인하고 나서 신뢰를 쌓고 싶다.

벤치마크 표는 가끔 거짓말을 한다. 12시간 런은 거짓말을 하기 어렵다. 그 런을 내 레포에서 한 번 돌려보는 게 다음 할 일이다.