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

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

omo README에는 이런 문장이 있다. “We run best on Opus or Kimi K3” — 자기 하네스가 가장 잘 도는 모델로 Claude와 Kimi를 나란히 세웠다.

수입차 정비소 벽에 특정 차종 전용 공구 세트가 세 벌 걸려 있는 그림을 떠올리면 된다. omo 저장소에서 Kimi가 받는 대접이 그렇다. 권장 기본값 자리 하나, 전용 감지 코드, 그리고 세대마다 다시 쓴 전용 시스템 프롬프트 세 벌이다.

결론부터 적는다. omo 안에서 Kimi는 손님이 아니라 주전이다. 오늘 읽을 것은 넷이다. Kimi가 어떤 모델인지, omo가 어떤 자리를 줬는지, 전용 프롬프트 3벌이 어떻게 진화했는지, 그리고 내 설정에서 그게 어떻게 도는지. 1편이 예고한 모델별 시리즈의 첫 대상이다 (실측 2026-08-27, dev 브랜치).

누가 읽으면 좋은가

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

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

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

셋 중 하나라도 겹치면 아래가 지도다.

Kimi부터 살펴보자

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

한 세대 앞 K2.6은 thinking 모드를 상시 켜고 나온 모델이다. 분해하고 비교하고 검증하는 사고 루프가 기본으로 돌아간다. 이 특성이 뒤에서 프롬프트 얘기의 출발점이 된다.

모델 자체의 사용기는 4월에 따로 적었다. 오늘의 관심은 모델이 아니라 모델이 앉는 자리다.

omo가 Kimi에게 준 자리

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

먼저 문서를 보면, 메인 오케스트레이터 Sisyphus의 권장 모델 4종에 kimi-k3가 있다. README는 “Claude Opus 5 and Kimi K3 are the recommended defaults”라고 명시한다.

계획 담당 Prometheus의 권장에도 kimi-k3가 있다. “Kimi K3 + GPT-5.6 Sol already beats vanilla Claude Code”라는 문장도 있다. omo의 주장이고 검증은 따로 없다.

다음은 코드다. 기본 모델표에서 sisyphus의 폴백 체인은 claude-opus-5 다음이 kimi-k3로, gpt-5.6-sol보다 앞에 온다.

카테고리 쪽은 더 세다. writing 카테고리 1순위가 kimi-k3고, quick 카테고리 1순위도 Kimi 계열 고속 모델인 kimi-for-coding-highspeed다. 권장 구독 스택에도 Kimi Code $19가 들어 있다.

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

정리하면 이렇다. 폴백 1순위 자리 대부분은 Claude와 GPT 몫이고, Kimi는 writing·quick의 1순위와 오케스트레이터의 첫 대안을 챙겼다.

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

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

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

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

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.

그 사고 루프가 벤치마크는 이기는데, 답이 뻔한 오케스트레이션 결정까지 돌린다는 진단이다. 물론 omo 저자 code-yeongyu의 진단이고 나는 독립 검증하지 않았다.

처방이 흥미롭다. “간결하게”가 아니라 숫자 예산이다.

“Plan analysis: 1 read, 1 dependency map, then dispatch” — 계획 분석은 읽기 1회에 의존성 맵 1개, 위임 전 툴 호출은 최대 2회로 제한한다.

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

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줄이 줄어 327줄이 됐다.

빠진 자리는 역할 문단의 기질 서술이 채운다. “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를 뜨면 모델명 빼고 추가가 문장 하나다. 줄수도 327줄로 같다.

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 전용 패턴에는 안 맞아서, 코드상 예산과 금지 목록이 빼곡한 479줄 판을 받는다. 도입의 정비소 비유로 돌아가면 내 차고엔 1세대 공구 세트가 걸려 있는 셈이다.

런타임에 실제 로드된 변형을 로그로 확인하진 않았다. 그 확인은 시리즈 뒤편의 숙제로 남겨 둔다.

Q&A

Q. 프롬프트는 왜 짧아졌나.

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

Q. 내 프롬프트에 가져갈 게 있나.

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

이게 정답이라는 검증은 없다. A/B 비교도 없다. 다만 68k 스타 저장소가 세 세대에 걸쳐 도달한 형태라는 것까지가 오늘의 관측이다.

한계

세 프롬프트가 실제로 모델 행동을 바꾸는지는 측정하지 않았다. 파일 차이만 읽었다.

K2.6의 과잉 분석 진단, “beats vanilla Claude Code” 모두 omo의 주장이다. 내 Atlas가 받는 변형은 코드 리딩 추론이고 런타임 확인 전이다.

관련 글

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

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

댓글

댓글 쓰기

이 블로그의 인기 게시물

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

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개 속도 비교 — gemma4·llama3.3·qwen3 실측

이미지
결론: M4 Max 128GB에서 가장 빠른 건 120B가 아니라 26B Dense 모델이다. 이유는 MoE 구조의 메모리 접근 패턴. 4개 모델 실측(tok/s 기준) + ChatGPT Plus 쿼터 제약 우회 대안 정리. 타이틀이 약속한 반전, 왜 생겼나 gpt-oss:120b 는 117B 파라미터짜리 MoE 구조. 총량은 117B지만 토큰 생성 한 번에 활성화되는 건 5.1B 정도. 이론적으로는 작은 모델만큼 빨라야 한다. 현실은 달랐다. MoE는 토큰마다 활성화되는 “전문가”가 바뀐다. 그래서 모델 전체(65GB)가 메모리에 상주해야 하고, 토큰마다 접근 위치가 비국소적(non-local)으로 흩어진다. 활성 파라미터 5.1B라는 숫자만 보면 훨씬 빨라야 맞다. 실제로 요구되는 메모리 대역폭은 전체 모델 크기에 가깝다는 얘기. 이 비교에서 직접 확인한 결과다. 반면 gemma4:26b 는 Dense 모델. 26B가 전부 계산에 참여한다. 파라미터 수 자체는 많지만 메모리 접근이 선형적이라 Apple Silicon의 통합 메모리 대역폭(546GB/s)을 효율적으로 쓸 수 있다. 같은 하드웨어에서 Dense가 MoE를 앞지르는 지점이 여기. 맥에서 로컬 LLM 고를 때 “MoE니까 활성 파라미터 작으면 빠르겠지” 하는 직관이 깨지는 순간. 테스트 환경 하드웨어는 Mac Studio M4 Max, 통합 메모리 128GB, 메모리 대역폭 546GB/s. 런타임은 Ollama 0.20.7 (llama.cpp 기반). 동일 프롬프트 3종 — 짧은 한국어, 짧은 수학, 긴 코드 생성. Cold start(첫 로드)와 Warm(모델 올라간 상태)을 분리 측정. 결과 4-way 비교표. 단위 tokens/second(tok/s). Prompt eval은 프롬프트 입력 처리 속도(초당 토큰 몇 개를 읽어들이는가), Generation은 응답 생성 속도(초당 토큰 몇 개를 출력하는가). 모델 크기(디스크) 활성 파라미터 Cold Load ...
자세한 내용 보기