omo 속의 Kimi — 오케스트레이터 기본값과 전용 프롬프트 3벌

omo 속의 Kimi — 오케스트레이터 기본값과 전용 프롬프트 3벌

Claude 말고 다른 모델로 에이전트를 굴리면 프롬프트를 얼마나 고쳐야 하나. omo 저장소에는 이 질문을 세 세대에 걸쳐 답한 기록이 있다 — Kimi 전용 시스템 프롬프트 3벌이다.

답부터. 처음엔 금지 목록과 예산 478줄을 썼고, 다음 세대엔 그걸 기질 서술 한 문단으로 압축했고, 마지막 세대엔 문장 하나만 보탰다. 고칠 양은 세대가 지날수록 줄었다. 오늘 읽을 것은 셋이다 — omo가 Kimi에게 준 자리, 프롬프트 3벌의 진화, 그리고 내 설정에서 도는 모습. 1편이 예고한 모델별 시리즈의 첫 대상이다.

수입차 정비소 벽에 특정 차종 전용 공구 세트가 세 벌 걸려 있는 그림을 떠올리면 된다. omo에서 Kimi가 받는 대접이 그렇다.

누가 읽으면 좋은가

Claude 말고 다른 모델로 에이전트를 굴리면 뭘 바꿔야 하나 궁금했던 적이 있다.

오픈 웨이트 모델이 실제 하네스에서 어떤 자리까지 올라왔는지 확인하고 싶었던 적이 있다.

모델을 바꿀 때마다 시스템 프롬프트를 어디서부터 고쳐야 하나 막막했던 적이 있다.

셋 중 하나라도 겹치면 아래가 지도다. Kimi 모델 자체의 사용기는 4월에 따로 적었다 — 오늘의 관심은 모델이 아니라 모델이 앉는 자리다.

omo가 Kimi에게 준 자리부터 살펴보자

자리는 문서, 코드, 프롬프트 디렉토리 세 군데서 확인된다.

먼저 문서. omo README는 자기 하네스가 가장 잘 도는 모델로 Claude와 Kimi를 나란히 세운다 — “We run best on Opus or Kimi K3”. 메인 오케스트레이터 Sisyphus의 권장에도 “Claude Opus 5 and Kimi K3 are the recommended defaults”라고 명시한다. “Kimi K3 + GPT-5.6 Sol already beats vanilla Claude Code”라는 문장도 있다.

다음은 코드다. 기본 모델표에서 sisyphus의 폴백 체인은 claude-opus-5 다음이 kimi-k3로, gpt-5.6-sol보다 앞에 온다. 권장 구독 스택에는 Kimi Code $19가 들어 있다.

마지막으로 프롬프트 디렉토리. atlas 변형 8벌 중 3벌이 Kimi 몫이다. gpt·gemini·glm·opus-4-7이 각 1벌인데 Kimi만 세대별로 kimi·kimi-k2-7·kimi-k3 세 벌 — 단일 계열 최다다. 감지도 전용이다. 정규식 세 개가 모델명에서 세대를 갈라 맞는 벌을 입힌다.

전 포지션 주전은 아니어도 명단 여러 곳에 이름이 오른 선수인 셈이다. 그 위에 전용 프롬프트 세 벌이 얹힌다.

전용 프롬프트 3벌 — 금지 목록이 문장 하나가 되기까지

파일 대상 줄수
kimi.md K2.6 478
kimi-k2-7.md K2.7 326
kimi-k3.md K3 326

1세대 kimi.md(478줄)는 모델의 버릇을 이름 붙이고 시작한다.

K2.6 ships with thinking mode ON and is post-trained to decompose → compare → verify → critique → revise → answer. That loop wins benchmarks. It also overthinks orchestration decisions where the answer is mechanical.

그 사고 루프가 벤치마크는 이기는데, 답이 뻔한 오케스트레이션 결정까지 돌린다는 진단이다. 처방이 흥미롭다. “간결하게”가 아니라 숫자 예산이다 — “Plan analysis: 1 read, 1 dependency map, then dispatch”. 계획 분석은 읽기 1회에 의존성 맵 1개까지다.

그리고 켤 곳과 끌 곳을 가른다.

Trust the trained prior on the hard 30% (verification reasoning, failure diagnosis, dependency analysis). Disable it on the easy 70% (mechanical dispatch, checkbox marking, parallel batching).

습관을 통째로 없애는 게 아니라, 아껴서 쓸 자리를 지정해 주는 것이다.

2세대 kimi-k2-7.md에서 그 보정 블록이 통째로 사라진다. 152줄이 줄었다. 빠진 자리는 역할 문단의 기질 서술이 채운다 — “You are outcome-first by temperament”. 금지 목록을 외우게 하는 대신, 목록이 필요 없는 기질로 설정하는 방식이다. 문단의 마지막 문장이 1세대 전체를 요약한다. “That split — fast on the mechanical, deep on verification — is how you orchestrate well.”

3세대 kimi-k3.md는 diff를 뜨면 모델명 빼고 추가가 문장 하나다. 줄수도 같다.

a turn that ends with “so I will dispatch…” without the actual calls is a failure mode.

“디스패치하겠다”고 말만 하고 실제 호출 없이 턴을 끝내는 것을 실패 모드로 명명했다. 세대 하나를 건너는 데 전면 재작성이 아니라 새 버릇 하나를 겨냥한 패치 한 문장이었다.

내 설정에선 Kimi가 주전이다

내 맥스튜디오 omo 설정도 같은 방향이다. 작업 에이전트 넷(hephaestus·explore·atlas·sisyphus-junior)이 전부 kimi-for-coding/k2p6다. quick 계열 카테고리도 같은 모델에 맡겨 두었다.

그 k2p6가 받는 프롬프트는 정규식상 1세대다. k2[-.]?p[567] 패턴에 맞고 K2.7 전용 패턴에는 안 맞아서, 코드상 예산과 금지 목록이 빼곡한 478줄 판을 받는다. 도입의 정비소 비유로 돌아가면 내 차고엔 1세대 공구 세트가 걸려 있는 셈이다.

Q&A

Q. 프롬프트는 왜 짧아졌나.
A. 모른다. 모델이 좋아져서 금지가 필요 없어진 건지, 프롬프트 기법이 늘어서 압축된 건지 커밋 기록으로는 구분되지 않는다. 확실한 건 방향뿐이다. 478줄이 326줄이 됐고, 마지막 갱신은 문장 하나였다.

Q. Kimi K3는 어떤 모델인가.
A. 베이징 Moonshot AI의 모델로 2026년 7월 16일 공개, 7월 27일 전체 가중치가 풀렸다. 약 2.8조 파라미터 MoE 구성으로 오픈 웨이트 최대급이라는 보도가 나왔다 (Fast Company · Fortune).

Q. 내 프롬프트에 가져갈 게 있나.
A. omo가 Kimi 세 벌에서 쓴 패턴은 네 가지다. 모델의 훈련된 버릇을 프롬프트 안에서 먼저 명명한다. 형용사 대신 구체 예산을 준다. 능력을 끌 곳과 켤 곳을 나눈다. 세대가 바뀌면 전면 재작성 대신 문장 패치를 먼저 시도한다. 갈라 쓰기 전의 판단 기준은 시리즈 결산에 정리했다.

확인 범위

  • K2.6 과잉 분석 진단, “beats vanilla Claude Code” 등은 전부 omo 저자 code-yeongyu의 관측·주장이며 독립 검증하지 않았다.
  • 세 프롬프트가 실제로 모델 행동을 바꾸는지는 측정하지 않았다. 파일 차이만 읽었다. A/B 비교도 없다.
  • 내 Atlas가 받는 변형은 코드 리딩 추론이고 런타임 로그 확인 전이다.
  • 수치는 2026-09-09 dev 브랜치 재실측이다 (초판 8/27 수치 479/327/327 → 478/326/326으로 갱신 — 파일이 그 사이에도 편집됐다).

관련 글

글쓴이 — 8년 차 프론트엔드 개발자. AI 코딩 도구를 실측 기준으로 기록한다. 이 글의 인용·수치는 2026-09-09 oh-my-openagent dev 브랜치 재실측·확인값이다.

태그: #omo #Kimi #MoonshotAI #시스템프롬프트 #에이전트하네스

댓글

댓글 쓰기

이 블로그의 인기 게시물

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

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

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 이상 행 길이 변주 ...
자세한 내용 보기

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 모델의 우열로 일반화할 수는 없다. 같은 ...
자세한 내용 보기