Kimi 전용 프롬프트 3개, 줄 수까지 세어 보니

2026-10-13 dev 브랜치 기준(commit origin/dev b78527c)으로 코드베이스 내 모델 매칭 체인과 전용 프롬프트 구성을 검토했습니다. 본 글은 프롬프트 지시 내용과 실제 관측된 효과를 구분하여, 저장소에 등록된 사실만을 다룹니다.

Kimi가 배치된 자리

새 Native 세션의 daily-normal 체인에서는 Claude Opus 5.5 → Kimi K3 → GLM 5.3 순서로 모델이 나열되어 있습니다. 각각의 모델 식별자는 claude-opus-5-5, kimi-k3, glm-5.3입니다. 시스템은 연결된 provider에서 제공하는 첫 번째 후보를 선택하므로, Kimi는 단일 고정 기본값이 아닙니다. 이 내용은 agent-model-matching.md에 명시되어 있습니다.

한편 OpenCode Sisyphus의 기본 fallback 체인은 Claude Opus 5.5 → Kimi K3 → GPT-5.6 Sol → GLM 5.2 → Big Pickle로 구성되어 있어 Native daily-normal 체인과 다릅니다.

역할 및 카테고리별 요구 사항을 정의한 agent-model-requirements.ts와 category-model-requirements.ts에 따르면 모델 배치는 다음과 같이 구분됩니다.

  • Atlas와 Sisyphus-Junior: Claude Sonnet 5 다음 순위로 Kimi K3가 배치됩니다.
  • explore 및 librarian: kimi-for-coding-highspeed가 첫 번째 후보로 지정되어 있습니다.
  • writing: Kimi 계열 모델이 포함되지 않습니다.
  • quick: GPT-6 Luna Fast 등으로 체인이 시작됩니다.

전용 파일 세 개와 줄 수

Atlas Markdown 파일은 전체 8개로 구성되어 있으며, 그중 Kimi 전용 파일은 3개입니다. 각 파일의 줄 수는 다음과 같습니다.

  • kimi.md: 478줄
  • kimi-k2-7.md: 326줄
  • kimi-k3.md: 326줄

여기서 확인된 파일 길이는 작성된 텍스트의 줄 수일 뿐이며, 모델 자체의 성능을 나타내는 수치가 아닙니다.

세대별 보정 지시

각 파일은 모델 세대별로 서로 다른 프롬프트 지침을 담고 있습니다. 이는 개발자가 모델의 동작 방식을 유도하기 위해 설정한 지시문이며, 실제 실험을 통해 측정된 모델의 고유 특성이나 효과를 의미하는 것은 아닙니다.

K2.6을 대상으로 하는 kimi.md는 thinking mode에서의 과잉 분석을 다룹니다. 계획 분석 단계를 읽기 1회 및 dependency map 1개로 제한하며, 기계적 dispatch와 검증·실패 진단 과정을 구분하여 진행하도록 안내합니다.

K2.7을 대상으로 하는 kimi-k2-7.md에는 You are outcome-first by temperament.라는 문장이 포함되어 있습니다. 기계적인 dispatch는 바로 실행하고, 분석 역량은 검증 단계에 집중하도록 지시합니다.

K3용으로 작성된 kimi-k3.md에서는 실제 호출을 수행하지 않고 so I will dispatch…라는 설명만 남긴 채 종료하는 패턴을 실패 모드로 명명하고 이를 방지하도록 요구합니다. 이 내용 역시 프롬프트 상의 지시 사항일 뿐이며, 실험으로 측정된 성능 결과가 아닙니다.

라우팅과 실제 모델 선택의 차이

라우팅 테스트 파일인 prompt-routing.test.ts와 모델 감지 로직을 다루는 model-family-detectors.ts를 살펴보면 모델 식별자와 프롬프트 파일이 1대1로 일치하지 않는 구조를 확인할 수 있습니다.

  • K2.6은 kimi로 라우팅됩니다.
  • K2.7은 kimi-k2-7로 라우팅됩니다.
  • K3는 kimi-k3로 라우팅됩니다.
  • K2.8 및 Kimi Code rolling id는 kimi-k2-7 변형을 공유합니다.

따라서 지원되는 모델 ID의 수와 프롬프트 파일의 수는 일치하지 않습니다.

또한 omo-json.md 문서에 따르면 model_profile 설정은 특정 lane 또는 provider/model 고정(pin) 역할을 합니다. 관련 설정 키로는 model_profiles, agents.*.models, categories.*.models 등이 존재합니다.

실제 런타임에서 어떤 모델이 선택되는지는 환경에 연결된 provider와 live model registry의 상태에 따라 결정됩니다. 이미 실행 중인 세션에는 새로운 profile 설정이 소급 적용되지 않습니다. 그러므로 설정에 명시된 체인, 실제 구동되는 모델, 그리고 prompt routing 로직을 각각 구분하여 파악해야 합니다.

검증 범위와 한계

본 글은 2026-10-13 dev 브랜치 기준의 정적 소스 코드와 문서(agent-model-matching.md, agent-model-requirements.ts, category-model-requirements.ts, prompt-routing.test.ts, model-family-detectors.ts, omo-json.md, Atlas Markdown 파일군)에 기록된 명세를 기반으로 작성되었습니다.

각 모델의 공식 출시일, 파라미터 수, 구독 비용이나 타 모델 대비 성능 주장은 코드베이스 검증 범위에 포함되지 않았으므로 다루지 않습니다. 아울러 프롬프트 지시에 따른 실제 성능이나 거동 변화를 측정한 실험 근거 역시 확인되지 않았습니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

AI 코딩 스킬, 많을수록 좋을까 — 자산이 부채로 바뀌는 손익분기

이미지
AI 코딩 스킬은 자산이다. 처음 몇 개는 그렇다. 그런데 수가 늘면 세금이 붙는다. 어느 스킬이 뜰지 예측이 안 되고, 도구 출력이 컨텍스트를 먹고, 모델이 바뀌면 쌓은 걸 전부 다시 만진다. 스킬을 관리하는 앱이 시장에 나온 게 그 신호다. 만들지 말라는 게 아니다. 만든 만큼 쳐내야 자산으로 남는다. 스킬은 자산으로 시작한다, 그런데 요즘 개발자들이 자기 .claude 디렉터리를 통째로 공개한다. TypeScript 교육자 Matt Pocock도 스킬 묶음을 GitHub에 올렸다. 제목이 “Skills for Real Engineers”이고, 소개가 “내 .claude 디렉터리에서 바로”다. skills.sh 같은 스킬 레지스트리도 생겼다. 스킬이 자산인 건 맞다. 손으로 반복하던 작업을 트리거 한 줄로 줄인다. 결과도 매번 일정해진다. 그래서 다들 쌓는다. 그런데 같은 GitHub에 묘한 게 같이 뜬다. 스킬을 “관리하고 동기화하고 정리”하는 데스크톱 앱이다. skills-manager는 Cursor·Claude Code·Codex 등 15개 넘는 도구의 스킬을 한곳에서 관리한다고 소개한다. 자산을 관리하는 전용 앱이 필요해졌다는 건, 그 자산이 관리 대상이 됐다는 뜻이다. 관리 대상은 곧 부담이다. 여기서 질문이 갈린다. AI 코딩 스킬은 많을수록 좋은가. 다음 중 하나라도 있나 비슷한 일을 하는 스킬이 둘 이상이라, 어느 게 뜰지 헷갈린 적이 있다. 스킬 하나를 고쳤더니 엉뚱한 데서 다른 게 어긋난 적이 있다. 내가 무슨 스킬을 만들어뒀는지, 목록을 열어봐야 기억나는 적이 있다. 셋 중 하나라도 해당되면 이미 부채 구간에 발을 걸친 것이다. 세 신호를 하나씩 본다. 신호 1 — 어느 스킬이 뜰지 예측이 안 된다 스킬이 늘면 비슷한 트리거를 여럿이 주장한다. “리뷰”라는 말에 코드 리뷰 스킬도 반응하고, 글 리뷰 스킬도 반응한다. 그러면 매 요청마다 “어느 스킬을 부를지” 판별하는 비용이 붙는다. 자동 라우팅 점...
자세한 내용 보기

M4 Max 128GB 로컬 LLM 4종 속도 비교 — 실측 기록과 한계

이미지
M4 Max 128GB에서 로컬 LLM은 얼마나 빠를까? 이 글의 과거 표에서는 gemma4:latest가 88 tok/s로 가장 높고, gemma4:26b는 85 tok/s다. gpt-oss:120b 47 tok/s, qwen3.6:35b-a3b 25 tok/s가 뒤를 잇는다. 처리량 표이지 정답률이나 코딩 품질 순위가 아니다. 작성자: 닥터조지. 2026년 4월 게시 당시 측정 기록 / 편집 보완: 2026-09-23. 기존 수치는 그대로 보존했고 이번에 모델을 다시 실행하지 않았다. 초판 제목의 llama3.3 표기와 “26B가 가장 빠르다”는 도입은 표와 일치하지 않아 바로잡았다. 원문의 장비·런타임·모델 표기는 당시 기록이다. 표의 qwen3.6:35b-a3b 는 원문에서 사용한 축약 표기이며, Q8과 qwen3.6:35b-a3b-q8_0 표기는 당시 본문 기록에서 가져왔다. 모델 파일이나 digest를 이번에 확인한 것은 아니다. 원 프롬프트 전문, 모델 digest, 반복 횟수와 개별 원시 응답이 이 글에 없어 표의 숫자를 그대로 재현했다고 확인할 수는 없다. 특히 latest 는 고정 버전 식별자가 아니다. 아래는 M4 Max 128GB 한 대에서 기록한 네 모델의 처리량이다. 모델 구조, 양자화, 크기가 동시에 다르므로 어느 한 요인만의 효과를 분리한 실험으로 읽으면 안 된다. 모델 크기만으로 속도를 예측하기 어려운 이유 원문은 gpt-oss:120b 를 총 117B, 활성 약 5.1B의 MoE로 기록했다. 활성 파라미터 수만으로 실제 생성 속도를 계산할 수는 없다. 모델 구조에 따른 메모리 접근 차이는 가능한 설명이지만, 이 표는 메모리 대역폭이나 접근 패턴을 직접 계측한 자료가 아니다. 생성 속도 차이만으로 병목의 원인을 확정하지 않는다. 당시 표의 gemma4:26b 는 gpt-oss:120b 보다 높은 생성 처리량을 보였다. 다만 이 결과를 모든 Dense 모델과 MoE 모델의 우열로 일반화할 수는 없다. 같은 ...
자세한 내용 보기

Opus 5는 더 잘 쓰고, 더 AI답게 쓴다 — 세 모델 첫날 실측

이미지
Claude Opus 5가 나온 다음 날, 세 모델에게 같은 시험지를 줬다. 결과부터 적는다. 글 품질 점수는 신형일수록 올랐다. 그런데 문장 리듬은 신형일수록 고르게, 그러니까 더 AI답게 변했다. 여기서 “AI답게”는 말투가 기계 같다는 뜻이 아니다. 문장 길이와 어미가 균질해진다는 뜻이고, 그 균질함이 통계 탐지기가 AI 글을 잡아낼 때 쓰는 바로 그 지문이다. 발표는 두 가지를 팔았다 새 모델이 나오면 벤치마크 표부터 보게 된다. 그 표는 전부 만든 쪽이 자기 시험지로 채점한 결과다. 내 작업에서 뭐가 달라지는지는 표에 없다. 그래서 표를 덮고 시험지를 직접 만들었다. 7월 24일 발표에서 Anthropic은 크게 두 가지를 내세웠다. 하나, 자기 작업을 검증하며 성공할 때까지 반복하는 능력이 강해졌다. 둘, 응답이 더 명확하고 간결해졌다. 벤치 수치는 여기 옮기지 않는다. 이 글이 확인할 건 저 두 문장이 내 작업물에서 어떻게 나타나느냐다. 같은 시험지 두 장 시험지는 두 장이다. 첫째는 글쓰기다. 주제·허용 사실·문체 규칙을 고정한 한국어 블로그 초안 스펙을 만들어 세 모델에 원샷으로 줬다. 둘째는 코딩 진단이다. 내 수집기에서 한 달 넘게 죽어 있던 실제 버그(reddit 수집 429 연쇄 실패)를 읽기 전용으로 진단하게 했다. 모든 주장에 파일과 행 번호 인용을 의무로 걸었다. 대상은 Opus 4.8, Fable 5, Opus 5. 각 모델의 정체는 시스템 프롬프트 자기보고로 확인했다. 채점은 사람 감이 아니다. 글은 발행 글 29편에서 뽑은 결정론 밴드(파이썬 스크립트)와 10점 감점제 루브릭으로, 진단은 미리 고정해 둔 정답표와 인용 실물 대조로 매겼다. 실측 1 — 더 잘 쓸수록 더 고르다 숫자부터 본다. 지표 Opus 4.8 Fable 5 Opus 5 발행 글 기준 문장 길이 변주(변동계수) 0.316 0.220 0.274 0.417 이상 행 길이 변주 0.266 0.23...
자세한 내용 보기