같은 에이전트에 프롬프트가 여덟 벌 — 68k 스타 omo 하네스 해부

같은 에이전트에 프롬프트가 여덟 벌 — omo 에이전트 하네스 해부

코딩 에이전트를 두 개 이상 써 본 사람은 안다. 규칙 파일, 서브에이전트 구성, 모델 설정을 도구마다 다시 짜게 된다.

그 문제를 통째로 받아주는 물건이 하나 앉아 있다. omo(oh-my-openagent). 스타 68,275개짜리 공개 저장소다.

결론부터 적는다. omo의 알맹이는 에이전트 하네스(에이전트를 부리는 작업 틀)고, 내가 읽기에 이 하네스는 세 가지로 조립돼 있다. 역할을 나눈 에이전트 11종, 모델 대신 카테고리를 고르게 하는 라우팅, 그리고 같은 에이전트에 모델별로 갈아 끼우는 시스템 프롬프트 여덟 벌.

오늘은 이 셋을 차례로 읽고, 마지막에 이 조립품이 실제로 굴러간다는 증거를 하나 붙였다. omo 모델별 하네스 시리즈의 1편이다.

이름 그대로 풀면 된다. oh-my-zsh가 zsh 위에 얹는 설정 모음이듯, omo는 코딩 에이전트 위에 얹는 하네스다. 하네스라는 말이 낯설면 5월 글부터 읽는 게 낫다.

배포는 세 에디션으로 나뉘는데 숙주가 셋이어도 하네스는 하나다. 에디션 차이는 아래 Q&A에 표로 정리했다.

누가 읽으면 좋은가

Claude Code·Codex·로컬 모델을 오가며 같은 설정을 도구마다 다시 짠 적이 있다.

서브에이전트를 몇 개까지, 어떤 기준으로 쪼개야 하나 고민한 적이 있다.

남이 만든 하네스 구현을 열어 보고 내 설정에 옮길 게 있는지 궁금했던 적이 있다.

셋 중 하나라도 겹치면 아래 내용을 지도로 쓸 수 있다. 설치 방법은 다루지 않는다. 그건 공식 문서와 기존 한국어 가이드들이 이미 잘 한다.

첫째 조각부터 살펴보자 — 역할을 나눈 에이전트 11종

omo는 일을 에이전트 11종에 나눠 시킨다. 이름은 전부 그리스 신화다.

메인 오케스트레이터 Sisyphus가 일을 쪼개 전문가들에게 위임한다. 계획은 Prometheus가 잡는데, 코드를 건드리기 전에 사용자를 인터뷰해서 범위부터 확정하는 방식.

자율 워커 Hephaestus는 목표만 받고 끝까지 알아서 간다. 그 밖에 실행 담당 Atlas, 아키텍처 상담역 Oracle, 검색 담당 Librarian과 Explore 같은 보조들이 붙는다.

역할 분담 위에 모드가 얹힌다. 끝까지 검증하며 완주하는 ultrawork, 팀 단위로 병렬 작업하는 Team Mode, 그리고 hyperplan.

hyperplan의 설명문이 이 하네스의 성격을 압축한다. “5 hostile agents tear apart your plan from orthogonal angles” — 코드 한 줄 쓰기 전에 적대적 에이전트 다섯이 계획을 서로 다른 각도에서 뜯는다는 뜻이다.

이 섹션의 소개는 저장소 문서 기준이다. 내가 직접 밟아본 건 ultrawork 한 번. 완료 선언까지 가는 길에 code-review·completion-audit 같은 게이트 산출물 여섯 개가 쌓였다.

둘째 조각 — 모델이 아니라 카테고리를 고른다

Sisyphus가 일을 위임할 때 모델명을 고르지 않는다. 카테고리를 고른다.

quick, deep, writing 같은 카테고리가 설정에서 모델로 매핑되는 구조다. 모델이 바뀌어도 위임 로직은 안 바뀐다는 게 이 추상화의 값.

말로만 하면 밋밋하니 내 설정을 그대로 보인다. 맥스튜디오의 ~/.omo/omo.jsonc에서 작업 에이전트들은 kimi k2p6로, 추론·문서 계열은 로컬 ollama 모델 네 종으로 갈라 두었다. 로컬 모델 고르는 기준은 4월 글에 적었고, 그때 손으로 하던 라우팅 고민을 omo에서는 설정 파일 하나가 흡수한다.

베타라서 만난 문제도 하나 있었다. 카테고리가 카탈로그에 없는 모델을 뽑아 위임이 조용히 실패했다.

// memory reflection(quick 카테고리)이 내장표의
// openai-codex/gpt-5.6-luna-fast(카탈로그 부재)를 뽑아
// reflection spawn이 실패하던 문제 수정: 실재+인증된 모델로 고정
"quick": { "model": "openai-codex/gpt-5.6-luna" }

공정하게 적으면 이 고장은 카테고리 계층이 낸 것이다. 잘못된 모델을 뽑은 주체가 그 추상화니까.

대신 수리도 같은 계층에서 끝났다. 코드를 건드리지 않고 설정 한 줄.

추상화는 고장을 없애주지 않는다. 고장의 수리 비용을 흡수해 준다. 이번 건이 보여준 건 정확히 그만큼이다.

셋째 조각 — 같은 에이전트, 여덟 벌의 프롬프트

여기가 이 하네스의 가장 독특한 지점이다. omo는 같은 에이전트에 모델별로 다른 시스템 프롬프트를 준다.

packages/prompts-core/prompts/atlas/에 여덟 벌이 나란히 있다. default(497줄)·gpt(462)·gemini(527)·glm(403)·kimi(479)·kimi-k2-7(327)·kimi-k3(327)·opus-4-7(495). 어떤 모델이 붙었는지를 정규식으로 감지해서 맞는 프롬프트를 갈아 끼운다.

숫자만 봐도 얘깃거리가 보인다. kimi용 프롬프트는 세대가 바뀌며 479줄에서 327줄로 줄었다.

같은 회사 모델인데 세대마다 지시문을 다시 썼다는 뜻. 모델별 튜닝을 이만큼 파일로 드러낸 공개 저장소는 흔치 않다.

하네스를 만들 때 보통은 모델 공통 틀 하나를 깐다. omo는 그 틀의 바닥을 모델마다 다르게 깔았다.

이 여덟 벌을 한 장씩 읽는 게 다음 편부터의 일이다. 각 프롬프트가 그 모델의 어떤 버릇을 겨냥하는지가 시리즈의 몸통.

이 하네스는 자기를 굴리는 데도 쓰인다

마지막으로 저장소 메타데이터 한 조각. omo 기여자 목록에서 커밋 2위는 github-actionsbot, 3위 MoerAI(374), 4위 sisyphus-dev-ai(258), 5위 justsisyphus(239)다. 2위부터 5위까지 사람이 아니다.

README도 “The maintainer builds and maintains oh-my-openagent in real-time with Jobdori, an AI assistant”라고 밝혀 두었다. 작업별 red-green 영수증과 트랜스크립트가 .omo/evidence/에 커밋돼 있고, 릴리스는 8월 21일 beta.15, 22일 beta.16과 beta.17이 나왔다.

에이전트 하네스를 파는 저장소가 자기부터 그 하네스로 굴러간다. 저장소 자체가 데모인 셈이다.

만들어진 지 263일에 스타 68,275개, 하루 평균 259.6개. 성장 경로를 추적하진 못했지만, 그 배경 중 하나로 이 dogfooding을 읽는다.

Q&A

Q. 세 에디션은 뭐가 다른가.

A. 붙는 자리가 다르다. 하네스 내용물은 같다.

에디션 형태 붙는 자리
Ultimate OpenCode 플러그인 OpenCode 위
Light (lazycodex) Codex CLI 플러그인 Codex 위
native (beta) 독립 CLI omo 단독 실행

Q. omo는 오픈소스인가.

A. 소스는 전부 공개돼 있고, 라이선스는 n8n이 쓰는 것과 같은 계열인 Sustainable Use License 1.0이다. OSI 정의 기준으로는 오픈소스 목록 밖이라 공개 저장소라고 불렀다. 읽고 배우고 쓰는 데는 제약이 없다.

Q. Claude Code를 버리고 갈아탈 이유가 되나.

A. 그 판단은 여기서 하지 않는다. 내 사용 범위가 native 에디션 열흘 남짓 로그와 ultrawork 한 번이라 아직 이르다.

판단 재료는 셋째 조각에 있다고 본다. 모델별 프롬프트 분기가 실제로 제 몫을 하는지 — 다음 편부터 그 파일들을 직접 읽으며 확인하려고 한다.

그 판단과 별개로 오늘 가져갈 물건은 있다. 세 조각을 질문으로 뒤집으면 어느 하네스에나 들이댈 점검표가 된다.

역할이 나뉘어 있나. 모델명이 위임 로직에 하드코딩돼 있나. 프롬프트는 자기가 어느 모델 위에서 도는지 아나.

omo가 정답이라는 보장은 없어도 이 질문 셋은 오늘부터 쓸 수 있다.

한계

OpenCode 에디션은 4월 설치 흔적만 확인했고 사용량은 측정하지 못했다. Team Mode와 hyperplan은 써 보지 않았다.

에이전트 11종 각각의 실전 품질도 아직 평가하지 않았다. 단정한 건 gh api와 저장소 파일, 내 로그에서 직접 읽은 범위까지다.

관련 글

글쓴이 — 8년 차 프론트엔드 개발자. 트렌드 수집기 trend-scout를 1년째 운영하며 AI 코딩 도구를 실측 기준으로 기록한다. 이 글의 수치는 2026-08-23 gh api와 맥스튜디오 로그 실측값이다.

태그: #omo #ohmyopenagent #에이전트하네스 #AI코딩에이전트 #멀티에이전트

댓글

댓글 쓰기

이 블로그의 인기 게시물

맥 스튜디오 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 ...
자세한 내용 보기

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 이상 행 길이 변주 ...
자세한 내용 보기

Claude Opus 4.7 출시 총정리 — 뭐가 달라졌고 지금 써야 하나

결론: Claude Opus 4.7은 "전부 업그레이드"가 아니다. 에이전트 작업에선 4.6보다 확실히 강해졌지만, 일상 코딩은 Sonnet이 여전히 3~5배 싸다. 2026-04-16 출시 후 Claude Code에서 반나절 써본 결과 3가지 체감 변화와 Qwen 3.6과의 비교까지 정리한다. Opus 4.7 핵심 변화 3가지 4.6과 비교해 체감되는 지점은 세 곳이다. 1. 에이전트 작업 체류 시간이 길어졌다 단일 지시로 파일 여러 개를 연쇄 수정할 때 중간에 “다음 단계 확인해 드릴까요?” 같은 끊김이 줄었다. 4.6은 5~6 step에서 한 번씩 끊겼는데, 4.7은 10 step 이상을 한 번에 간다. 긴 리팩터링 작업에서 체감이 크다. 2. 코딩 벤치마크 점수 상승 Anthropic 공식 블로그의 차트 기준으로 SWE-bench Verified, Terminal-bench 모두 4.6보다 올랐다. 다만 이게 실사용 속도까지 보장하지는 않는다. 3. 반론에 더 단단해졌다 4.6은 “내 말이 맞다”고 밀면 바로 물러서는 경향이 있었다. 4.7은 근거를 다시 제시한다. 디버깅 대화에서 사람이 틀린 가정을 고집할 때 이 특성이 오히려 시간을 아낀다. Qwen 3.6-35B가 Opus 4.7을 이긴다고? 같은 날 Alibaba가 Qwen 3.6-35B-A3B(오픈소스)를 공개했다. Simon Willison이 자기 노트북에서 Qwen 3.6이 Opus 4.7보다 “더 나은 펠리컨 그림을 그렸다”는 글을 올려 HN 상위에 갔다. 이 결과를 어떻게 봐야 할까. 일부 작업에서는 오픈소스가 이긴다 — 이미지 생성, 특정 추론 과제 복잡한 에이전트·장문 코딩은 Opus 4.7이 여전히 우세 비용 관점 에서 오픈소스가 매력적이지만, API 없이 로컬 돌리려면 GPU 비용이 따로 든다 즉 “Opus 4.7 vs Qwen 3.6”은 “어느 게 ...
자세한 내용 보기