# Kimi K2.6 공개 - 오픈소스 코딩의 발전

> Clean Markdown view of GeekNews topic #28736. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28736](https://news.hada.io/topic?id=28736)
- GeekNews Markdown: [https://news.hada.io/topic/28736.md](https://news.hada.io/topic/28736.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-21T09:59:52+09:00
- Updated: 2026-04-21T09:59:52+09:00
- Original source: [kimi.com](https://www.kimi.com/blog/kimi-k2-6)
- Points: 1
- Comments: 1

## Topic Body

- **장기 구간 코딩**과 에이전트형 작업에서 성능을 끌어올린 모델로, 여러 언어와 프런트엔드·devops·성능 최적화 전반에서 **일반화 성능** 강화
- 복잡한 엔지니어링 작업을 **지속 실행형 코딩**으로 처리하며, 수천 회 도구 호출과 12시간 이상 연속 실행을 거쳐 Zig 추론 최적화와 exchange-core 전면 개편에서 큰 폭의 처리량 향상 기록
- 단순 프롬프트를 **완전한 프런트엔드 인터페이스**로 바꾸고 이미지·영상 생성 도구까지 활용하며, 인증·데이터베이스 작업을 포함한 **간단한 풀스택 워크플로우** 지원
- **Agent Swarm** 구조를 300개 서브에이전트와 4,000개 조정 단계 규모로 확장해 검색·리서치·문서 작성·파일 생성 작업을 병렬 실행하고, PDF·슬라이드·스프레드시트·Word 문서의 형식과 스타일을 재사용 가능한 skills로 전환
- **능동형 에이전트**와 Claw Groups까지 범위를 넓혀 장시간 자율 운영, 다중 에이전트 협업, 작업 재할당을 수행하며, 벤치마크와 기업 베타 테스트에서 코딩·도구 호출·장기 실행 신뢰성 개선 확인

---

### 장기 구간 코딩
- **장기 구간 코딩 작업**에서 성능 향상 확인, Rust·Go·Python 같은 여러 언어와 프런트엔드·devops·성능 최적화 같은 여러 작업 전반에서 **일반화 성능** 강화
  - 내부 코딩 벤치마크인 **Kimi Code Bench**에서 복잡한 엔드투엔드 작업 전반을 대상으로 Kimi K2.5 대비 큰 폭의 개선 기록
- 복잡한 엔지니어링 작업에서 **지속 실행형 코딩** 수행
  - Mac 로컬 환경에 **Qwen3.5-0.8B** 모델 다운로드와 배포 성공
  - 비교적 특수한 언어인 **Zig**로 모델 추론을 구현하고 최적화, 분포 밖 일반화 성능 입증
  - **4,000회 이상 도구 호출**, **12시간 이상 연속 실행**, **14회 반복**을 거쳐 처리량을 약 15 tokens/sec에서 **약 193 tokens/sec**로 끌어올림
  - 최종 속도는 **LM Studio 대비 약 20% 빠름**
- 8년 된 오픈소스 금융 매칭 엔진 **exchange-core** 전면 개편 수행
  - **13시간 실행** 동안 12개 최적화 전략 반복, **1,000회 이상 도구 호출**로 4,000줄 이상 코드를 정밀 수정
  - CPU 및 메모리 할당 **flame graph** 분석으로 숨은 병목 식별
  - 코어 스레드 토폴로지를 **4ME+2RE에서 2ME+1RE**로 재구성
  - 이미 성능 한계에 근접한 엔진에서 **중간 처리량 185% 상승**(0.43→1.24 MT/s), **성능 처리량 133% 상승**(1.23→2.86 MT/s) 달성
- 베타 테스트의 기업 평가에서도 **장기 코딩 신뢰성**과 **도구 호출 품질** 관련 긍정적 평가 다수 확인
  - Baseten은 선도적 비공개 모델과 유사한 수준의 코딩 작업 성능, 서드파티 프레임워크 이해 기반의 강한 도구 호출 품질, 복잡하고 장기적인 엔지니어링 작업 적합성 언급
  - Blackbox는 장기·에이전트형 코딩 워크플로우에서 오픈소스 모델의 새 기준, 복잡한 다단계 작업 처리, 높은 코드 품질, 장시간 세션 안정성, 비명백한 버그 탐지 능력 언급
  - CodeBuddy는 K2.5 대비 **코드 생성 정확도 12% 증가**, **장문맥 안정성 18% 개선**, **도구 호출 성공률 96.60%** 기록
  - Factory는 자체 벤치마크와 나란히 비교한 평가에서 **15% 향상** 보고
  - Fireworks는 장기 구간 신뢰성과 지시 이행 능력을 가장 큰 개선 지점으로 언급
  - Hermes Agent는 도구 호출과 에이전트 루프의 긴밀함, 코딩 향상, 창의적 범위 확대 언급
  - Kilo는 **낮은 비용 대비 SOTA급 성능**과 코드베이스 전반의 장문맥 작업 강점 언급
  - Ollama는 코딩과 에이전트 도구 적합성, 긴 다단계 세션 안정성, 기존 통합과의 즉시 연동 언급
  - OpenCode는 작업 분해와 도구 호출의 안정성, 반복 오버헤드 감소, 엔드투엔드 경험의 신뢰성 언급
  - Qoder는 도구 호출과 모델 호출 빈도 증가, 작업 실행 중 능동성 강화, 사용자 중단과 대기 시간 감소 언급
  - Vercel은 **Next.js 벤치마크 50% 이상 개선**, 플랫폼 상위권 성능, 비용 대비 효율 기반의 에이전트형 코딩과 프런트엔드 생성 적합성 언급

### 코딩 중심 설계
- 강한 **코딩 능력**을 기반으로 단순 프롬프트를 **완전한 프런트엔드 인터페이스**로 변환 가능
  - 미적인 **hero section**, 상호작용 요소, 스크롤 트리거 효과를 포함한 풍부한 애니메이션 등 구조화된 레이아웃 생성
- **이미지·영상 생성 도구 활용 능력**을 바탕으로 시각적으로 일관된 자산 생성 지원
  - 더 높은 품질과 더 눈에 띄는 hero section 제작에 기여
- 정적 프런트엔드를 넘어 **간단한 풀스택 워크플로우**까지 확장
  - 인증, 사용자 상호작용, 데이터베이스 작업 포함
  - 거래 기록이나 세션 관리 같은 경량 사용 사례 지원
- 내부 **Kimi Design Bench** 구축
  - **Visual Input Tasks**, **Landing Page Construction**, **Full-Stack Application Development**, **General Creative Programming** 네 범주로 구성
  - Google AI Studio와 비교해 여러 범주에서 유망한 결과와 양호한 성능 기록
- **K2.6 Agent** 예시 생성물 제공
  - 하나의 프롬프트와 미리 구성된 harness·도구를 사용해 결과 생성
  - 미적 측면에서는 풍부한 상호작용을 갖춘 아름다운 프런트엔드 디자인 포함
  - 기능 측면에서는 내장 데이터베이스와 인증 포함
  - 도구 활용 측면에서는 이미지·영상 생성 도구를 사용한 정제된 웹사이트 생성 포함

### 향상된 Agent Swarm
- **수직 확장만이 아닌 수평 확장** 중심 구조 채택
  - Agent Swarm은 작업을 이질적인 하위 작업으로 동적으로 분해하고, 스스로 생성한 도메인 특화 에이전트들이 이를 병렬 실행
- **K2.5 Agent Swarm** 연구 프리뷰를 기반으로, **Kimi K2.6 Agent Swarm**에서 경험의 질적 도약 제시
  - 넓은 검색과 깊은 리서치 결합
  - 대규모 문서 분석과 장문 작성 결합
  - 여러 형식의 콘텐츠 생성을 병렬 실행
  - 단일 자율 실행 안에서 문서·웹사이트·슬라이드·스프레드시트를 아우르는 엔드투엔드 산출물 제공
- 아키텍처의 **수평 확장 규모** 확대
  - **300개 서브에이전트**가 **4,000개 조정 단계**를 동시에 실행
  - K2.5의 **100개 서브에이전트**, **1,500단계** 대비 큰 폭의 확장
  - 대규모 병렬화로 엔드투엔드 지연 감소, 출력 품질 향상, Agent Swarm 운영 경계 확장
- PDF·스프레드시트·슬라이드·Word 문서 같은 고품질 파일을 **Skills**로 전환 가능
  - 문서의 구조와 스타일 특성을 캡처하고 유지
  - 이후 작업에서 동일한 품질과 형식을 재현 가능
- 예시 작업 다수 제시
  - **100개 글로벌 반도체 자산**을 대상으로 5개 퀀트 전략 설계·실행, **McKinsey 스타일 PPT**를 재사용 가능한 skill로 도출, 상세 모델링 스프레드시트와 완전한 경영진 발표 자료 제공
  - 풍부한 시각 데이터를 가진 고품질 **천체물리학 논문**을 재사용 가능한 학술 skill로 전환, 추론 흐름과 시각화 방식을 도출, **40페이지·7,000단어 연구 논문**, **20,000개 이상 항목의 구조화 데이터셋**, **천문학 수준 차트 14개** 생성
  - 업로드된 이력서를 바탕으로 **100개 서브에이전트**를 생성해 California의 관련 직무 100개 매칭, 구조화된 기회 데이터셋과 **100개의 맞춤형 이력서** 제공
  - Google Maps에서 Los Angeles의 공식 웹사이트가 없는 소매점 30곳 식별, 각 매장에 대해 전환율 중심 랜딩 페이지 생성

### 능동형 에이전트
- **OpenClaw**와 **Hermes** 같은 자율적·능동적 에이전트에서 강한 성능 기록
  - 여러 애플리케이션을 가로질러 **24시간 7일 연속 실행**되는 유형 지원
- 단순 채팅 기반 상호작용과 구분되는 워크플로우 대응
  - 일정 관리, 코드 실행, 플랫폼 간 작업 오케스트레이션을 **지속적 백그라운드 에이전트**로 수행 필요
- RL 인프라 팀은 **K2.6 기반 에이전트**를 사용해 **5일간 자율 운영** 진행
  - 모니터링, 사고 대응, 시스템 운영 담당
  - 지속 컨텍스트 유지, 멀티스레드 작업 처리, 경보 발생부터 해결까지 전 주기 실행 입증
  - 민감 정보 제거를 거친 작업 로그 존재 언급
- 실제 환경의 **신뢰성 개선** 측정
  - 더 정확한 API 해석
  - 더 안정적인 장시간 실행 성능
  - 장기 리서치 작업 중 향상된 안전 인식
- 내부 평가 스위트 **Claw Bench**로 성능 향상 정량화
  - **Coding Tasks**, **IM Ecosystem Integration**, **Information Research & Analysis**, **Scheduled Task Management**, **Memory Utilization**의 다섯 영역 포함
  - 전 지표에서 Kimi K2.5 대비 **작업 완료율**과 **도구 호출 정확도** 크게 향상
  - 특히 사람 감독 없이 지속 자율 운영이 필요한 워크플로우에서 강한 개선 기록

### Bring Your Own Agents
- 강한 **오케스트레이션 능력**을 바탕으로 능동형 에이전트를 **Claw Groups**로 확장
  - Agent Swarm 아키텍처의 새로운 구현 형태로 연구 프리뷰 제공
- **개방적이고 이질적인 생태계** 수용
  - 여러 에이전트와 사람이 실제 협업자로 함께 작동
  - 사용자는 어떤 기기에서든, 어떤 모델로 실행되든 에이전트를 온보딩 가능
  - 각 에이전트는 고유한 도구 모음, skill, 지속 메모리 컨텍스트 보유
  - 로컬 노트북, 모바일 기기, 클라우드 인스턴스 등 다양한 환경의 에이전트가 공유 운영 공간에 자연스럽게 통합
- 중앙에서 **Kimi K2.6**이 적응형 조정자 역할 수행
  - 각 에이전트의 skill 프로필과 사용 가능한 도구를 기준으로 작업 동적 배분
  - 적합한 역량에 맞춰 작업 최적화
  - 에이전트 실패나 정체 발생 시 이를 감지하고 작업 재할당 또는 하위 작업 재생성 수행
  - 시작부터 검증, 완료까지 산출물 전 생애주기 적극 관리
- **Claw Groups**의 자체 활용 사례 포함
  - 인간-에이전트 워크플로우를 실제로 다듬기 위해 에이전트 마케팅 팀을 내부 사용
  - Demo Makers, Benchmark Makers, Social Media Agents, Video Makers 같은 특화 에이전트들이 함께 작동
  - 엔드투엔드 콘텐츠 제작과 출시 캠페인 운영
  - K2.6이 중간 결과 공유와 아이디어의 일관된 완성형 산출물 전환 조정
- 인간과 AI의 관계를 질문 응답이나 단순 작업 할당을 넘어 **실질적 협업 파트너십**으로 확장
  - "my agent", "your agent", "our team"의 경계가 협업 시스템 안에서 자연스럽게 사라지는 미래 지향점 제시

### 벤치마크 표
- **Agentic** 영역 주요 수치
  - HLE-Full w/ tools **54.0**, GPT-5.4 52.1, Claude Opus 4.6 53.0, Gemini 3.1 Pro 51.4, Kimi K2.5 50.2
  - BrowseComp **83.2**, BrowseComp(agent swarm) **86.3**, Kimi K2.5는 각각 74.9, 78.4
  - DeepSearchQA f1-score **92.5**, accuracy **83.0**
  - WideSearch item-f1 **80.8**
  - Toolathlon **50.0**, Kimi K2.5 27.8
  - MCPMark **55.9**
  - Claw Eval pass^3 **62.3**, pass@3 **80.9**
  - APEX-Agents **27.9**
  - OSWorld-Verified **73.1**
- **Coding** 영역 주요 수치
  - Terminal-Bench 2.0 (Terminus-2) **66.7**
  - SWE-Bench Pro **58.6**
  - SWE-Bench Multilingual **76.7**
  - SWE-Bench Verified **80.2**
  - SciCode **52.2**
  - OJBench (python) **60.6**
  - LiveCodeBench (v6) **89.6**
- **Reasoning & Knowledge** 영역 주요 수치
  - HLE-Full **34.7**
  - AIME 2026 **96.4**
  - HMMT 2026 (Feb) **92.7**
  - IMO-AnswerBench **86.0**
  - GPQA-Diamond **90.5**
- **Vision** 영역 주요 수치
  - MMMU-Pro **79.4**, MMMU-Pro w/ python **80.1**
  - CharXiv (RQ) **80.4**, CharXiv (RQ) w/ python **86.7**
  - MathVision **87.4**, MathVision w/ python **93.2**
  - BabyVision **39.8**, BabyVision w/ python **68.5**
  - V* w/ python **96.9**
- 공식 **Kimi-K2.6 벤치마크 결과 재현**에는 공식 API 사용 권장
  - 서드파티 제공자 선택에는 **Kimi Vendor Verifier (KVV)** 참고 안내 포함

### 각주
- ## 일반 테스트 세부 사항
  - Kimi K2.6과 Kimi K2.5는 **thinking mode enabled**, Claude Opus 4.6은 **max effort**, GPT-5.4는 **xhigh reasoning effort**, Gemini 3.1 Pro는 **high thinking level** 조건에서 결과 보고
  - 별도 표기가 없는 한 Kimi K2.6 실험은 **temperature 1.0**, **top-p 1.0**, **262,144 tokens 컨텍스트 길이**로 수행
  - 공개 점수가 없는 벤치마크는 Kimi K2.6과 같은 조건으로 재평가했고 **별표(*)** 로 표시
  - 별표가 없는 결과는 공식 보고서 인용
- ## 추론 벤치마크
  - GPT-5.4와 Claude 4.6의 **IMO-AnswerBench** 점수는 z.ai 블로그에서 취득
  - **Humanity's Last Exam (HLE)** 및 기타 추론 작업은 최대 생성 길이 **98,304 tokens**로 평가
  - 기본 보고값은 **HLE full set**
  - 텍스트 전용 하위 집합에서 Kimi K2.6은 도구 없이 **36.4% accuracy**, 도구 포함 시 **55.5% accuracy** 기록
- ## 도구 보강 및 에이전트형 작업
  - HLE with tools, BrowseComp, DeepSearchQA, WideSearch에서 **search**, **code-interpreter**, **web-browsing** 도구 장착
  - HLE-Full with tools는 최대 생성 길이 **262,144 tokens**, 단계별 한도 **49,152 tokens**
  - 컨텍스트 창이 임계값을 넘으면 가장 최근의 도구 관련 메시지 라운드만 유지하는 단순 컨텍스트 관리 전략 사용
  - BrowseComp 점수는 Kimi K2.5 및 DeepSeek-V3.2와 동일한 **discard-all 전략**의 컨텍스트 관리로 획득
  - DeepSearchQA에서는 Kimi K2.6 테스트에 컨텍스트 관리를 적용하지 않았고, 지원 컨텍스트 길이를 초과한 작업은 실패로 직접 집계
  - Claude Opus 4.6, GPT-5.4, Gemini 3.1 Pro의 DeepSearchQA 점수는 **Claude Opus 4.7 System Card** 인용
  - WideSearch는 **hide tool result** 컨텍스트 관리 설정으로 결과 보고
  - 테스트 시스템 프롬프트는 **Kimi K2.5 technical report**와 동일
  - Claw Eval은 **version 1.1**, **max-tokens-per-step 16384**로 수행
  - APEX-Agents는 공개 480개 작업 중 **452개 작업** 평가
    - Artificial Analysis와 동일하게 **Investment Banking Worlds 244, 246** 제외
    - 제외 이유는 외부 런타임 의존성
- ## 코딩 작업
  - Terminal-Bench 2.0 점수는 기본 에이전트 프레임워크 **Terminus-2**와 제공된 **JSON parser**를 사용해 **preserve thinking mode**로 획득
  - SWE-Bench 계열 평가(Verified, Multilingual, Pro 포함)는 **SWE-agent**를 바탕으로 개조한 사내 평가 프레임워크 사용
  - 해당 프레임워크 도구 구성은 **bash tool**, **createfile tool**, **insert tool**, **view tool**, **strreplace tool**, **submit tool**의 최소 집합
  - 코딩 작업의 보고 점수는 모두 **독립 실행 10회 평균값**
- ## 비전 벤치마크
  - **max-tokens 98,304**, **3회 실행 평균(avg@3)** 적용
  - Python 도구 사용 설정은 **max-tokens-per-step 65,536**, **max-steps 50**으로 다단계 추론 수행
  - MMMU-Pro는 공식 프로토콜을 따르며 입력 순서를 유지하고 이미지를 앞에 배치

## Comments



### Comment 55944

- Author: neo
- Created: 2026-04-21T09:59:54+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47835735) 
- OpenRouter로 붙여 써봤더니 이 모델이 SVG 펠리컨을 그냥 그리는 데서 끝나지 않고, 애니메이션 속도 조절까지 되는 HTML로 감싸서 내보낸 점이 인상적이었음. 대화 기록과 HTML은 [여기 gist](https://gist.github.com/simonw/ecaad98efe0f747e27bc0e0ebc669...)에 있고, 실행 예시는 [이 링크](https://gisthost.github.io/?ecaad98efe0f747e27bc0e0ebc669e94...)에서 볼 수 있음
  - 이제는 이런 **펠리컨 SVG**가 학습 데이터셋에 들어갔을 것 같다는 생각이 듦
  - 이건 완전히 **과잉 성실형** 느낌이었고, Kimi라는 이름도 왠지 모범생 같게 들림
  - 아쉽게도 펠리컨의 **다리와 발**에는 같은 공을 들이지 않은 것 같음. 왼쪽 다리는 마비된 것처럼 안 움직이고, 오른쪽 발목은 불안할 정도로 휙휙 돌아감
  - 베타 때 써봤는데 꽤 괜찮은 모델이었고, 어떤 순간에는 내가 Opus나 GPT가 아닌 다른 모델을 쓰고 있다는 걸 잊을 정도였음. 그래도 **Opus**가 여전히 더 낫고, 내 기준에선 GPT 쪽이 더 버거워 보였음. 백엔드 작업에서는 약간의 틈새가 있지만, 실력이 있으면 Opus로도 비슷하게 해결 가능했고 전반적으로는 부족한 면이 더 많았음
  - 진지하게 궁금한데, 거의 모든 새 모델 스레드마다 이걸 올리는 목적이 무엇인지 모르겠음. 내가 좀 늙고 까칠한 걸 수도 있지만, 한참 전에 이미 **식상해졌고** 저노력 Reddit 댓글처럼 느껴짐

- 초반 벤치마크를 보면 Kimi K2.6이 Kimi K2 Thinking보다 크게 좋아졌음. 이전 모델은 우리 벤치마크에서 성적이 별로였고, 양자화도 최선의 설정을 썼음. 지금은 Kimi K2.6이 **원샷 코딩 추론**에서 오픈 웨이트 모델 중 최상위권이고, GLM 5.1보다 약간 좋으며, 대략 3개월 전 SOTA 모델들과도 경쟁 가능해서 Gemini 3.1 Pro Preview와 비슷한 급으로 보임. 에이전트형 테스트는 아직 진행 중이고, 오픈 웨이트 모델은 긴 컨텍스트 에이전트 워크플로에서 약한 편이지만 GLM 5.1은 꽤 잘 버텼기 때문에 Kimi의 결과가 궁금함. 다만 구버전과 신버전 모두 속도가 느린 편이라 에이전트 코딩 실사용성에는 제약이 있을 수 있음. 예전 Kimi K2는 벤치마크 최적화가 심했고 어려운 문제 해결보다는 **변주와 온도**를 늘리는 데 더 흥미가 있었는데, 이번 모델은 훨씬 강한 범용형처럼 보임. 전체적으로 오픈 웨이트 진영은 정말 좋아 보이고, 거의 매주 프런티어급 신모델이 하나씩 나오는 분위기임. 자세한 벤치마크는 [gertlabs](https://gertlabs.com/?mode=oneshot_coding)에서 확인 가능함
  - K2.6이 Sonnet 4.6과 비교해서 가격과 성능이 어느 정도인지 궁금함
  - 언어별 성능 편차가 이렇게 큰 점은 꽤 놀라웠음

- 중국이 어쩌면 세계에서 가장 중요한 기술을 **오픈소스** 방식으로 밀고 있고, 미국은 정반대로 가는 모습에 아이러니한 유머가 느껴짐
  - 내 생각엔 동기 중 하나가 **미국 기업 견제**임. OpenAI와 Anthropic이 가장 큰 플레이어이고 둘 다 미국 회사라서, 오픈 웨이트 모델이 많아질수록 이 둘의 산업 지배력이 약해짐. 중국 회사들이 미국식으로 비공개 모델 전략을 택하면 대부분 ChatGPT나 Claude를 쓸 가능성이 높아서, 어차피 큰 수익을 내기 어렵다면 오픈 웨이트로 내놓아 미국 회사의 초과 이익을 줄이는 쪽이 더 현실적이라고 봄
  - 위대한 기술 발전은 결국 **개방**을 통해 가속된다고 봄. iPhone만 봐도 GPS, 인터넷, 음성 비서, 터치스크린, 마이크로프로세서, 리튬이온 배터리 등 핵심 기술 다수가 정부 연구나 공공에 가깝게 열린 연구에서 나왔음. 민간 기업은 경쟁사에게 돌파구를 그냥 열어주지 않기 때문에, 분야 전체를 전진시키려면 결국 기술을 열어야 한다는 생각임
  - 이번 업데이트로 Kimi K2.6이 가장 강한 **오픈 멀티모달** AI 모델이 됐다고 봄. 물론 나는 관계자가 아님. 공개된 AI 벤치마크를 모아보면 Opus 4.6 max effort와 비교했을 때 에이전트는 5 대 5, 코딩은 Kimi 5 대 Opus 1, 추론과 지식은 Kimi 1 대 Opus 4, 비전은 Kimi 9 대 Opus 0이었음. 다만 벤치마크는 모델 제작사가 고르기 때문에 편향은 감안해야 하고, 그래도 코딩과 추론 항목 다수는 꽤 표준적인 편이었음
  - 꼭 그렇게만 보긴 어려움. Google도 최근 **Gemma 4**를 공개했고 Allen AI도 open Olmo 계열을 내놓고 있음. 그래도 중국 오픈 모델이 확실히 더 강하게 보이는 건 맞고, 특히 Qwen 3 계열은 체급 이상으로 잘 치고 올라오는 느낌임
  - 중국 연구소들이 왜 모델을 오픈소스로 내놓는지 여러 추측이 나오지만, 내 생각엔 이유가 단순하고 분명함. 그들에게 사실상 가능한 **상용화 전략**이 그것뿐이기 때문임. 이 점은 [내 글](https://try.works/writing-1#why-chinese-ai-labs-went-open-an...)에서 정리해둠

- 나는 Kimi가 생각보다 주목을 덜 받는 점이 늘 의외였음. 창의성이나 품질 면에서 계속 눈에 띄었고, 꽤 오랫동안 내가 가장 좋아하는 모델이었음. 물론 내가 권위자는 아님
  - 좋긴 하지만 아직 **Claude급**은 아니라고 느낌. 게다가 API는 용량 문제를 자주 겪음. 그래도 가격 대비 품질은 정말 말이 안 될 정도라서, 몇 주나 몇 달 전에 40달러 충전해둔 걸 아직도 절반도 못 썼음
  - SVG 시계를 그릴 수 있는 몇 안 되는 모델 중 하나라는 점도 재밌었음. 예시는 [이 사이트](https://clocks.brianmoore.com/)에서 볼 수 있음
  - 이 정도 성능에 OpenRouter에서 **매우 저렴한** 편이라 더 좋았음. 2.6도 그 전통을 이어가길 바람
  - Kagi Assistant에서 선택지로 써봤는데, 검색과 요약이 많은 환경에서 결과가 마음에 들었음. 특히 목록형이나 Markdown 범벅의 전형적인 LLM 문체가 아닌 **자연스러운 산문**을 부탁했을 때 좋았음. 확신 있게 비교하긴 어렵지만, 출력 흐름을 좋게 만들기 위해 원문을 과감히 재배열하는 편이었고, 때로는 따로 다뤄진 관련 아이디어를 연결하거나 요청에 제대로 답하도록 만드는 데 그런 편집이 오히려 필요했음
  - 첫 K2가 나왔을 때를 기억하는데, 한동안 **창의적 글쓰기**에서는 다른 모델보다 확실히 앞섰음

- 여기서 Kimi를 실제 업무에 써본 사람이 있는지 궁금함. 나는 한 번 써봤는데 벤치마크는 화려해 보여도 실사용 인상은 그저 그랬음. 반면 Qwen 3.6은 꽤 좋았고, Opus에는 못 미쳐도 Sonnet과는 충분히 비빌 만하다고 느낌
  - Codex 쿼터를 다 쓰면 Kimi K2.5를 대신 썼는데, 작고 중간 규모 작업은 무난했음. 하지만 **복잡한 작업**에 쓰면 나중에 Codex로 이틀 동안 뒤처리를 해야 해서, 2.6이 좀 더 나아졌길 바람
  - GLM-5.1 전에는 Opus 4.5와 Kimi 4.5를 왔다 갔다 하면서 썼고, Kimi 쪽에서도 결과가 꽤 좋았음
  - 실제로 쓰고 있을 가능성이 높음. Cursor의 composer-2 모델을 쓰면 그게 **Kimi 계열**이기 때문임. 계획 수립은 최상위권이고, 실행도 composer-2에서 잘 돌아간다고 느낌

- 벤치마크 감각과 실제 체감이 맞아떨어진다면, 이번 건 중국 AI가 미국 최상위 연구소 모델과 거의 **어깨를 나란히** 하는 DeepSeek 순간 같은 사건일 수도 있겠다고 느낌
  - 이전 세대 모델과 비교하면 그렇다고 볼 수 있지만, 이른바 **10T급 신화적 모델**과 비교하면 아직 전혀 가깝지 않다고 봄

- 내 테스트와 [aibenchy 비교](https://aibenchy.com/compare/moonshotai-kimi-k2-6-medium/moo...) 기준으로는 Kimi K2.6이 Kimi K2.5보다 약간 나은 정도였음. 특히 퍼즐, 도메인 특화 문제, 함정형 정확성 과제에서 **지시 불이행**과 오답이 자주 보였음. 코딩 모델로는 훌륭할 수 있지만, 전체적인 지능감은 여전히 최상위 SOTA보다 약간 아래라고 느낌
  - OpenRouter에서 max tokens를 8192로 두고 써봤는데, non-thinking 모드에서도 모든 응답이 **잘려서** 나왔음. 배포 문제일 수도 있지만, 네 링크에서도 출력 토큰을 엄청 많이 생성하는 걸로 보였음

- 가끔 미래에는 예전 컴퓨터가 방 하나를 차지하다가 지금은 주머니에 들어오게 된 것처럼, 언젠가 데이터센터에 해당하는 계산량이 **휴대폰 같은 단일 기기** 하나로 들어갈 수 있을지 궁금해짐. 기술 발전 속도가 해마다 빨라지는 것처럼 보이니, 그런 변화도 더 빨리 오지 않을까 하는 생각이 듦
  - 이런 방향으로는 이미 초반 작업이 있음. 예를 들어 Taalas 같은 회사는 **LLM ASIC**을 만들고 있고, HC1은 llama 8b에서 초당 17k 토큰을 낸다고 함. 아직 2.5kW 수준이라 휴대폰보다는 단일 서버에 가깝지만 첫 칩이라는 점은 의미가 큼. 광자 컴퓨팅 같은 대안도 전력을 크게 줄일 가능성이 있지만 아직은 연구 단계로 보임. AI에 돈이 워낙 많이 몰리고 기존 GPU 추론의 전력 소모가 커서, 이 영역의 개선은 꽤 빠르게 일어날 거라고 예상함
  - 나는 그렇게까지 빠를 거라고 보진 않음. 역사적으로는 대체로 **지수적 축소**가 이어졌고, 그 추세가 유지된다면 방 크기의 연산이 주머니 크기로 줄어드는 데 걸리는 시간은 비슷해야 함. 게다가 최근에는 그 지수 추세에도 못 미치고 있고, 원래 지수 성장 자체가 오래 지속되기 어려움. 기술 진보가 계속 빨라지고 계산 장치도 계속 작아질 거라는 점에는 동의하지만, 그 사실만으로 다음 축소 단계가 더 짧은 시간 안에 온다고 보긴 어렵다고 생각함

- 오늘 아침 내내 앱에 붙여 테스트해봤는데, 느낌상 결과가 Sonnet 4.6과 비슷했음. 정식 검증 없이 순전히 **바이브 기반** 인상이긴 하지만, 프런티어 모델에 실제 경쟁이 생긴 건 반가운 일임
  - K2.6과 GLM 5.1 덕분에 이제는 Sonnet급 지능을 **Haiku급 가격**에 쓰는 느낌이 듦. 이건 정말 좋음. Anthropic도 빨리 새 Haiku를 내놨으면 하고, 더 저렴한 모델들과 경쟁하려면 지금 Haiku의 3분의 1에서 5분의 1 가격대 제품이 필요해 보임. Gemma-4가 그 가격 구간에서 꽤 잘하고 있음

- 이 모델에 코딩용 정액제가 있는지 궁금했음. 즉 토큰 제한 대신 API 호출 제한만 있는 방식인지 궁금했고, 최근에는 z.ai에서 GLM 과금이 실패해서 구독이 끊겼는데 가격도 몇 달 사이에 너무 많이 올랐음
  - Kimi도 다른 서비스들과 거의 비슷한 방식의 자체 구독이 있고, [Kimi Code](https://www.kimi.com/code)에서 확인 가능함
