omo 속의 GPT — 협박을 빼고 계약을 넣은 하네스

이미지
팀장 두 유형을 떠올려 보자. 한 명은 등 뒤에 서서 “절대 실수하지 마라”를 반복한다. 다른 한 명은 계약서 한 장을 주고 자리를 비운다 — 지켜야 할 조건 네 개, 끝났다고 판정하는 기준 하나. omo의 GPT 전용 프롬프트는 후자다. 요약부터. omo 공개 저장소의 GPT용 ultrawork 프롬프트는 191줄로 모델 변형 중 가장 짧다(2026-09-07 실측, default 337줄). 강조어 MUST·NEVER·MANDATORY·NON-NEGOTIABLE은 default 25개에서 7개로 줄었다. Atlas 오케스트레이터 프롬프트도 461줄로 default(496줄)보다 짧다. 그런데 짧아진 자리가 비어 있지 않다. 계약이 들어왔다. omo가 뭔지는 1편 , Kimi 3세대는 2편 , Gemini의 경고 증폭은 3편 에서 다뤘다. 오늘 읽을 것은 넷이다. 협박어가 빠진 자리에 들어온 계약을 읽고, 시리즈 처음으로 말이 아니라 도구 인자가 달라진 지점을 확인한다. “멈춰라”를 가르치는 규칙을 보고, 이 가족이 omo 안에서 받은 자리로 끝낸다. 이런 경험이 있다면 답이 이미 나왔는데 에이전트가 탐색을 한 바퀴 더 도는 것을 본 적이 있다. 테스트가 다 통과했는데 검증 패스를 또 도는 것도 봤다. 요청한 적 없는 리팩토링이 diff에 섞여 온 적도 있다. 세 가지 다 “게으름”이 아니라 “과잉”이다. omo를 만드는 code-yeongyu가 GPT용 파일에 적어 둔 진단이 정확히 이 계열이다. 오늘 그 파일 두 개를 줄 단위로 읽는다. 협박어 25개가 7개가 됐다 숫자부터 살펴보자. ultrawork/default.md의 헤딩은 이렇게 생겼다. ABSOLUTE CERTAINTY REQUIRED - DO NOT SKIP THIS NO EXCUSES. NO COMPROMISES. DELIVER WHAT WAS ASKED. 같은 파일의 마지막 섹션 제목은 “ZERO TOLERANCE FAILURES”다. GPT판에는 이 대문자 헤딩들이...

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

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에게 준 자리 자리는 문서, 코드, 프롬프트 디렉토리 세 군데서 확인된...