8월, 2026의 게시물 표시

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 thr...