omo 속의 Gemini — 실패 모드 두 개를 명명한 하네스
공장 안전수칙을 떠올려 보자. 절차는 모든 기계가 같은데, 유독 한 기계 앞에만 경고판이 빽빽하게 붙어 있다. 그 기계가 위험해서가 아니라, 그 기계에서 반복된 사고 유형이 다르기 때문이다. omo의 Gemini 전용 프롬프트가 정확히 그런 문서다. 요약부터. omo의 Atlas 오케스트레이터 프롬프트 8벌 중 Gemini판이 525줄로 가장 길다(2026-08-28 실측, default 502줄·gpt 460줄). 그런데 늘어난 지면의 정체는 새 절차가 아니라 강조 블록이다. 그 강조가 겨냥하는 실패 모드는 두 개다. 방향이 서로 반대다. omo가 뭔지는 1편에서 , 같은 방법론이 Kimi에겐 어떻게 적용됐는지는 2편에서 다뤘다. 오늘 읽을 것은 넷이다. 가장 긴 프롬프트에서 뭐가 늘었는지 세고, 실패 모드 두 개와 장치를 읽는다. 설명문이 명령문이 되는 지점을 짚고, 이 모델이 omo 안에서 받은 자리로 끝낸다. 이런 경험이 있다면 에이전트가 “확인했습니다”라고 답했는데 실제로는 파일을 읽지 않은 걸 발견한 적이 있을 것이다. “이 버그 좀 봐줘”라고 했더니 조사 대신 코드를 바로 고쳐버린 적도 있을 것이다. 그리고 그런 버릇이 모델마다 다르다는 것도 느꼈을 것이다. omo 작성자는 그 버릇의 차이를 모델별 프롬프트 파일로 만들었다. Gemini용 파일 두 개에는 그 버릇이 실패 모드라는 이름으로 하나씩 명명돼 있다. 가장 긴 프롬프트부터 살펴보자 packages/prompts-core/prompts/atlas/ 디렉토리의 오늘(8/28) 기준 실측이다. default 502줄, gpt 460줄, gemini 525줄. 1편에서 실측한 8/23 수치(497·462·527)와 다른데, 8/25 커밋 하나가 atlas 디렉토리를 건드려 줄 수가 움직였다. 닷새 사이에도 편집되는, 살아있는 파일이라는 뜻이다. 그럼 default보다 긴 23줄엔 뭐가 들었을까. 새 절차가 아니다. 오히려 절차 설명은 짧아졌다. 노트 디렉토리 구조 예시는 7줄 ...