omo 속의 Claude — 전용 프롬프트는 구세대 몫이다

omo 속의 Claude — 전용 프롬프트는 구세대 몫이다

자동차 리콜 통지서를 떠올려 보자. 통지서는 최신 모델 앞으로 오지 않는다. 문제가 확인된 특정 연식 앞으로만 온다. omo 저장소에서 Claude가 받은 전용 프롬프트가 정확히 그런 문서다.

요약부터. Atlas 오케스트레이터 프롬프트 8벌 중 Claude 몫은 opus-4-7.md 하나다(494줄, 2026-09-08 dev 브랜치 실측). 4.6 대비 4.7에서 달라진 버릇 두 개를 보정하는 파일이고, 정작 폴백 1순위 다섯 자리를 차지한 현역 Claude(opus-5·sonnet-5·fable-5-1)는 전부 default(496줄)를 받는다.

omo 소개는 1편, Kimi의 세대 파일 3벌은 2편, GPT의 계약서는 4편에서 다뤘다. 오늘 읽을 것은 넷이다. 하나뿐인 전용 변형과 그 이력을 보고, 보정하는 버릇 두 개를 읽는다. 같은 버릇을 지렛대로 돌려 쓰는 수법을 짚고, 현역 Claude가 실제로 받는 프롬프트가 뭔지로 끝낸다.

이런 경험이 있다면

모델을 업그레이드했더니 에이전트가 서브에이전트를 덜 띄우는 걸 본 적이 있다. “모든 태스크에 적용하라”고 썼는데 첫 번째에만 적용하고 넘어가는 것도 봤다. 새 세대 모델이 나왔는데 전용 프롬프트는 옛 세대 것뿐인 저장소를 본 적도 있다.

세 가지 다 프롬프트가 아니라 모델 기본값이 움직인 경우다. omo를 만드는 code-yeongyu가 Claude용 파일에 적어 둔 진단이 이 계열이다. 오늘 그 파일을 default와 겹쳐 읽는다.

여덟 벌 중 Claude 몫은 한 벌이다

숫자부터 살펴보자. GPT는 atlas 변형에 더해 ultrawork까지 전용 2벌을 받았고, Kimi는 세대별로 3벌을 받았다. Claude는 atlas의 opus-4-7.md 하나다. ultrawork에는 Claude 변형 자체가 없어서, Claude가 ultrawork 모드를 돌면 “ABSOLUTE CERTAINTY REQUIRED” 헤딩이 붙은 default 337줄을 그대로 받는다.

이력도 짧다. 이 파일은 5월 24일에 만들어졌고, 내용을 실제로 고친 마지막 커밋은 7월 17일이다. 이후는 저장소 전체를 훑는 정리 커밋 2건뿐, 총 커밋 6개. 9월 5일에도 손질된 GPT판과 나란히 놓으면 갱신이 가장 뜸한 축이다.

방치라고 단정할 수는 없다. 4.7의 행동이 안 변하니 고칠 이유가 없다는 해석도 성립한다. 확인되는 것은 하나다 — 오케스트레이터 1순위를 전부 차지한 모델의 전용 파일이, 두 달 가까이 같은 내용이다.

보정하는 버릇은 두 개다

파일 도입부에 다른 변형에 없는 <opus_47_counter_defaults> 블록이 있다. 제목부터 목적을 말한다 — “Two Opus 4.7 defaults you MUST counter”. 첫째는 문자 그대로 해석하는 버릇이다.

  1. LITERAL INSTRUCTION FOLLOWING. When this prompt says “every task”, “all batches”, “for each independent item” — apply to EVERY case, NEVER infer “first item only”, NEVER silently scope down.

둘째는 병렬을 덜 쓰는 버릇이다.

  1. FEWER SUBAGENTS BY DEFAULT. Opus 4.7 spawns fewer subagents than Opus 4.6 unless told otherwise. Counter this aggressively. When the plan has N independent tasks, fire N task() calls in ONE message. Not N sequentially. Not N/2 then N/2. ALL N AT ONCE. Fan-out is your job description.

버전을 특정한 세대 보정이라는 점에서 2편의 Kimi 파일들과 같은 유형이다. 4.6에서 4.7로 넘어가며 달라진 지점만 겨냥한다. 금지 목록 추가행도 구체적이다.

  • Dispatch 1 task per response when 4 are independent — that is the Opus 4.7 default failure

병렬 독려는 본문 중간에서 한 번 더 온다. 4개가 남았는데 1개만 보내고 있으면 멈추고, 이번 응답에 4개를 다 보내라는 지시다. 원문은 그 습관에 이름까지 붙였다.

The “I’ll just do this one first and then think about the others” instinct is the bias you must counter.

버릇을 결함이자 지렛대로 쓴다

여기가 이 파일의 수법이다. 2편의 Kimi는 눌렀고, 3편의 Gemini는 몰아붙였고, 4편의 GPT는 멈춰 세웠다. Claude판은 네 번째 길을 간다 — 같은 버릇의 방향만 돌려 쓴다.

문자 그대로 해석하는 버릇은 위에서 결함으로 명명됐다. 그런데 검증 규칙에선 그 버릇이 수단이 된다.

Apply Phase 3.4 to EVERY completed task in a batch — not the first only. Opus 4.7’s literal-following bias also means it will skip the protocol on later tasks unless reminded. So: re-read this rule before each verification.

허용 목록에는 아예 이렇게 적었다.

  • Apply rules with EVERY-frequency literally — every task, every batch, every delegation

“문자 그대로 읽는 성향이 문제라면, 규칙을 문자 그대로 읽게 쓰면 된다”는 접근이다. 강조어 수도 이 방향과 맞는다. MUST·NEVER·MANDATORY·NON-NEGOTIABLE을 세면 default 17개, opus-4-7판 20개. GPT판이 25개를 7개로 줄인 것과 반대로, Claude판은 오히려 3개를 보탰다. 대신 예시를 압축해 전체 길이는 2줄 줄었다.

현역 Claude는 default를 받는다

그럼 opus-5와 sonnet-5와 fable은 어느 파일을 받을까. 변형 선택 코드에 Claude 매처는 "opus-4-7": isClaudeOpus47Model 하나고, 이 함수는 모델명에 “claude-opus-4-7”이 있는지만 본다. opus-4-6도, opus-5도, sonnet-5도, fable-5도 매치되지 않는다. 전부 default 수신이다.

그런데 폴백 테이블의 오케스트레이터 라인은 전부 Claude가 1순위다. sisyphus는 claude-opus-5, atlas와 sisyphus-junior는 claude-sonnet-5, prometheus는 claude-fable-5-1, metis는 claude-opus-5 — 다섯 자리. 1순위 자리 수로는 4편의 GPT와 동률인데, 그 자리에 앉는 모델은 하나도 전용 변형이 없다.

두 가지를 겹치면 관측이 하나 나온다. 이건 저장소에 적힌 문장이 아니라 구성에서 내가 끌어낸 추론이다 — default.md가 사실상 현역 Claude용 프롬프트다. 1순위 모델들이 받는 게 default고, 전용 파일은 구세대 보정판뿐이다. 리콜 통지서는 특정 연식에만 가고, 나머지는 출고 상태 그대로 달린다.

Fable 얘기도 여기 붙는다. 감지 코드에 isClaudeFable5Model()이 있긴 한데 프롬프트 분기에는 안 쓰인다. 용도는 API 요청 형태 판별이다. 주석 원문은 이렇다.

Claude Fable shares the Opus 4.7+ request surface (adaptive thinking only, explicit enabled-thinking budgets rejected), so it counts as “4.7 or later”.

내 설정은 이번에도 유보다. 내 omo.jsonc에는 claude·opus·sonnet·fable 매치가 0건이다 — 오케스트레이터를 전부 Kimi와 로컬 모델로 덮어 뒀다. 오늘 내용은 3편과 같은 순수 저장소 리딩이고, 이 프롬프트로 4.7이 실제로 팬아웃을 늘리는지 A/B 비교는 없다.

Q&A

Q. omo에 Claude 전용 하네스가 있나.
A. atlas/opus-4-7.md 494줄 하나다(2026-09-08 dev 브랜치 실측). ultrawork에는 Claude 변형이 없고, opus-5·sonnet-5·fable-5는 변형 매처에 걸리지 않아 default를 받는다.

Q. 그 파일은 뭘 하나.
A. 4.6 대비 4.7의 버릇 두 개 — 문자 그대로 해석, 서브에이전트 축소 — 를 보정한다. 특이점은 첫째 버릇을 결함으로 명명하면서 동시에 “규칙을 문자 그대로 적용하라”는 지렛대로도 쓴다는 점이다.

Q. 이 진단들은 검증된 건가.
A. 아니다. “4.7이 서브에이전트를 덜 띄운다”는 code-yeongyu가 프롬프트에 적은 관측이고, 오늘 내용은 그걸 저장소 리딩으로 옮긴 것이다. 런타임 A/B 비교는 없다.

Q. 읽을 때 주의할 것은.
A. “default가 곧 Claude판”은 폴백 1순위 구성에서 끌어낸 추론이지 저장소에 적힌 문장이 아니다. 그리고 전용 파일이 조용한 것을 방치로 단정할 수 없다 — 고칠 이유가 없었다는 해석도 같이 성립한다.

남은 변형은 GLM(402줄) 하나다. 한 편을 더 쓰기보다, 여덟 벌 전체를 한 표에 겹쳐 놓고 시리즈를 닫는 결산이 어울릴 수도 있다. 다음 편에서 정한다.

관련 글

8년 차 개발자. AI 도구로 일하는 방식을 실측 기록으로 남긴다. 이 글의 수치는 2026-09-08 oh-my-openagent 저장소(dev 브랜치) 실측이다.

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

댓글

댓글 쓰기

이 블로그의 인기 게시물

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 ...
자세한 내용 보기