omo 속의 Gemini — 실패 모드 두 개를 명명한 하네스

omo 속의 Gemini — 실패 모드 두 개를 명명한 하네스

같은 절차를 쓰는데 왜 어떤 모델에겐 경고를 늘려 쓰나. omo 저장소의 Gemini 전용 프롬프트가 이 질문에 답이 되는 문서다. Atlas 오케스트레이터 프롬프트 8벌 중 Gemini판이 526줄로 가장 길다(2026-09-09 실측, default 496줄).

답부터. 길어진 정체는 새 절차가 아니라 강조고, 그 강조는 반대 방향의 실패 모드 두 개를 겨냥한다. 강조어 MUST·NEVER·MANDATORY·NON-NEGOTIABLE을 세면 default 17개, gemini판 23개다. ultrawork 쪽은 더 벌어진다 — default 25개, gemini판 35개.

공장 안전수칙을 떠올려 보자. 절차는 모든 기계가 같은데, 유독 한 기계 앞에만 경고판이 빽빽하게 붙어 있다. 그 기계가 위험해서가 아니라, 그 기계에서 반복된 사고 유형이 다르기 때문이다.

omo가 뭔지는 1편에서, 같은 방법론이 Kimi에겐 어떻게 적용됐는지는 2편에서 다뤘다. 오늘 읽을 것은 셋이다. 실패 모드 두 개와 장치를 읽고, 설명문이 명령문이 되는 지점을 짚고, 이 모델이 omo 안에서 받은 자리로 끝낸다. 이하 진단은 전부 omo 저자 code-yeongyu가 프롬프트에 적은 관측이다.

이런 경험이 있다면

에이전트가 “확인했습니다”라고 답했는데 실제로는 파일을 읽지 않은 걸 발견한 적이 있을 것이다. “이 버그 좀 봐줘”라고 했더니 조사 대신 코드를 바로 고쳐버린 적도 있을 것이다. 그리고 그런 버릇이 모델마다 다르다는 것도 느꼈을 것이다.

omo는 그 버릇의 차이를 모델별 프롬프트 파일로 만들었다. Gemini용 파일 두 개에는 그 버릇이 실패 모드라는 이름으로 하나씩 명명돼 있다.

실패 모드 두 개부터 살펴보자 — 방향이 반대다

첫째는 atlas판의 TOOL_CALL_MANDATE 블록이다. 원문 그대로 옮긴다.

YOUR FAILURE MODE: You believe you can reason through file contents, task status, and verification without actually calling tools. You CANNOT. Your internal state about files you “already know” is UNRELIABLE.

도구를 안 부르고 머리로만 검증하는 버릇을 겨냥한다. 처방은 강제다. “A response without tool calls is a FAILED response.” 병렬 실행도 예외가 아니다 — 전용 부록은 병렬 작업 3개를 말했으면 응답에 task() 호출 블록이 3개 있어야 한다고 개수까지 적는다.

2편에서 본 Kimi K3의 추가 문장 하나(“말만 하고 호출 없는 턴 = 실패”)와 같은 증상이다. 다만 Kimi에겐 문장 하나를 보탰고, Gemini에겐 섹션을 통째로 배정했다.

둘째는 ultrawork판(323줄)의 GEMINI_INTENT_GATE다.

YOUR FAILURE MODE: You see a request and immediately start coding. STOP. Classify first.

요청을 보자마자 코딩부터 시작하는 버릇이다. 처방은 억제다. 어떤 도구 호출보다 먼저 의도를 6가지(research/implementation/investigation/evaluation/fix/open-ended)로 분류해 선언하게 한다. “explain how X works”에 코드를 고치는 응답을 WRONG으로 규정한 대조표까지 붙였다. 건너뛰면 “다음 도구 호출은 무효”다.

두 파일을 겹쳐 보면 재미있는 긴장이 나온다. 첫째 실패 모드는 행동을 안 해서 문제고, 둘째는 행동을 너무 빨리 해서 문제다. 같은 모델에 “도구를 불러라”는 강제와 “코딩부터 하지 마라”는 억제가 동시에 걸려 있다. 모순이 아니라 국면 분리다 — 검증 국면에선 행동을 강제하고, 착수 국면에선 행동을 막는다.

설명문이 명령문이 되는 곳

같은 검증 절차를 두 파일이 어떻게 다르게 쓰는지 비교하면 이 하네스의 방법이 제일 잘 보인다. default판 검증 섹션의 제목은 “Why You Verify Personally”다. 서브에이전트의 보고를 왜 직접 확인해야 하는지 이유를 설명하는 산문이다. gemini판에서 같은 섹션은 이렇게 시작한다.

THE SUBAGENT LIED. VERIFY EVERYTHING.

이어지는 문장도 같은 결이다. “THEIR WORK IS EXTREMELY SUSPICIOUS”, “This is NOT a warning - this is a FACT based on thousands of executions”. 절차 자체는 코드 읽기, 자동 검사, 직접 QA, 게이트 판정 4단계로 동일하다. 다른 건 서술 방식뿐이다. 이유를 설명하던 문장이 단정 명령문이 됐다.

게이트 판정의 마지막 줄이 이 톤의 정점이다.

ALL three must be YES. “Probably” = NO. “I think so” = NO.

바뀐 모든 줄을 설명할 수 있는가. 동작을 직접 봤는가. 기존 기능이 안 깨졌다고 확신하는가. 세 질문에 “아마도”라는 답을 허용하지 않는다.

스코프 확장 검사도 gemini판에만 있다. “Do NOT invent new requirements” 아래 “Your creativity should go into ORCHESTRATION QUALITY, not implementation decisions”가 붙는다. 창의성을 금지하는 게 아니라 쓸 자리를 지정하는 문장이다. 2편에서 Kimi의 사고 모드를 “어려운 30%에 쓰라”고 지정하던 것과 같은 수법이다.

자리는 후순위, 장비는 가장 무겁다

그럼 omo는 이렇게 공들인 Gemini를 어디에 쓰나. 기본 모델 테이블 실측으로는 oracle 에이전트 폴백 3순위(gemini-3.1-pro)와 momus 후순위가 전부다. 오케스트레이터의 폴백 체인에는 아예 없고, 초판(8/28) 실측 때 있던 writing 카테고리 3순위 자리는 그 사이 체인 개편으로 사라졌다. 어느 자리에서도 1순위가 아닌데 전용 프롬프트는 전 변형 중 가장 길다. 출전 순서는 뒤인데 장비가 가장 무거운 선수인 셈이다.

왜 이런 배분인지 저장소엔 설명이 없다. 폴백까지 감안해 안전장치를 두껍게 깔았다고 볼 수도 있고, 강한 프롬프트가 필요할 만큼 통제가 어려웠다고 볼 수도 있다. 둘 다 추정이다.

Q&A

Q. 왜 Gemini에게만 이렇게 강하게 썼나.
A. 모른다. 저장소에 설명 문서가 없고, 저자에게 물은 것도 아니다. 확인되는 건 결과물뿐이다 — default와의 diff에서 대문자 강조와 “FAILED response” 류 단정이 반복해 확인되고, 강조어 수(17→23, 25→35)로도 계측된다.

Q. 이 관측에서 가져갈 만한 패턴은.
A. omo가 쓴 기법으로 한정하면 셋이다. 버릇을 실패 모드라는 이름으로 명명하고 시작한다. 금지 대신 “쓸 자리 지정”으로 창의성과 사고를 배치한다. 같은 절차라도 모델에 따라 설명문과 명령문을 갈아 끼운다. 갈라 쓰기 전의 판단 기준은 시리즈 결산에 정리했다.

Q. 그래서 이 프롬프트는 효과가 있나.
A. 검증 못 했다. A/B 비교도 없고 내 설정엔 Gemini가 없다. 이 시리즈가 확인하는 건 “omo가 무엇을 썼는가”까지고, “그게 작동하는가”는 별도 실험이 필요하다.

확인 범위

  • 진단(“머리로만 추론한다” 등)은 전부 code-yeongyu가 프롬프트에 적은 관측이다. Gemini 모델의 실제 결함으로 읽지 않는다.
  • 내 Mac Studio omo 설정엔 gemini 라우팅이 0건(grep 실측)이라, 이번 편은 런타임 관측 없는 순수 저장소 리딩이다.
  • 수치는 2026-09-09 dev 브랜치 재실측이다(초판 8/28의 525/502/325줄에서 갱신 — 파일과 폴백 테이블이 그 사이에도 편집됐다). 계속 움직이는 저장소라 이 수치도 금방 낡을 수 있다.

관련 글

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

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

댓글

댓글 쓰기

이 블로그의 인기 게시물

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개 속도 비교 — 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 ...
자세한 내용 보기