oh-my-hermes
무엇인가
oh-my-hermes(OMH)는 Hermes Agent 위에 얹히는 운영 계층으로, 에이전트가 작업을 어떻게 쪼개고 어떤 모델로 돌리고 언제 완료로 선언할지를 규율한다. 사용자는 계속 Hermes에게 말을 걸고, OMH가 레인(lane)마다 스킬과 모델을 골라 병렬로 실행한다. 각 레인에는 ultrabrain, deep, visual-engineering, quick 같은 작업 카테고리 태그가 붙고, 그 카테고리가 해당 레인의 모델 체인과 추론 강도를 결정한다. /dag-ulw 명령은 목표를 작은 노드들의 그래프로 바꾸고 준비된 노드를 동시에 돌린다. 노드 그래프 실행에서 각 노드는 자기 카테고리의 모델과 추론 강도로 돌고, 별도 노드가 목표를 검사하며 실패한 노드는 보고서 앞에서 복구된다. 규율 범위는 모델 선택, 병렬 실행의 쓰기 범위, 완료 판정 근거, 장기 기억의 기록 방식까지 포함한다. 스킬 팩 형태로 배포되며 omh-* 접두사의 전문 스킬들을 라우터가 필요할 때 도구 호출로 불러온다. Hermes 자체를 패치하거나 대체하지 않는다.
어떻게 동작하나
이런 규율이 없을 때 나타나는 실패는 구체적이다. 에이전트는 계획을 세운 뒤 실행하지 않고도 완료로 보고하고, 한 모델로 성격이 다른 작업을 전부 처리하려다 실패한다. 병렬로 돌린 노드들이 같은 파일을 동시에 고쳐 쓰기 충돌을 만들고, 테스트를 돌리지 않은 채 '완료'라고 적는다. 공급자가 모델을 거부하면 조용히 더 약한 모델로 내려가고, 그 사실은 보고서에 남지 않는다. 기억은 사용자에게 묻지 않고 저장되며, 다음 세션은 무엇이 왜 기억되었는지 알 수 없다. 상태 표기도 뭉개져 '계획만 세운 것'과 '테스트로 검증된 것'이 같은 '완료'로 보인다. OMH는 이 각각을 별도 규칙으로 분리해 막는다. 특히 '계획한 일을 완료로 보고하지 않는다'는 저장소가 명시한 불변식이며, 검증 게이트를 통과하지 않은 실행은 verified로 취급되지 않는다. 검증되지 않은 실행이 verified로 표기되면 이후 판단이 그 위에 쌓이므로, 표기 규칙은 보고서 문체 문제가 아니라 신뢰 문제다.
무엇과 다른가
규칙은 대부분 하드 제약으로 쓰인다. 동시에 실행되는 노드는 쓰기 범위를 공유하지 않는다는 조건은 병렬 실행의 안전 조건이므로 예외를 두지 않는다. 모델 체인은 공급자가 모델을 거부하면 다음 항목으로 넘어가되, 조용한 다운그레이드를 금지한다. 완료 판정은 문장이 아니라 증거에 묶인다. Plan · not run, Code · reported done, Test · verified처럼 단계와 확신도를 함께 표기하고, 테스트·리뷰·CI 게이트가 실제로 통과한 실행만 verified로 센다. 기억 규칙도 같은 형태다. 후보는 보관·거부·보류 중 하나로 결정되고 그 이유가 기록으로 남으며, 다음 세션은 작업에 맞게 순위가 매겨지고 토큰 예산으로 잘린 회수 팩을 받는다. 각 레인의 카테고리 태그가 모델 체인과 추론 강도를 결정하도록 한 것도, 모델 선택을 즉흥 판단이 아니라 편집 가능한 표로 옮기기 위해서다. Hermes 자체 기억은 읽지도 패치하지도 않는다는 경계가 명시되어 있다.
어떻게 쓰나
설치는 한 번이다. macOS·Linux에서는 install.sh를 파이프로 실행하고, Windows에서는 install.ps1을 실행한 뒤 omh setup을 돌린다. Homebrew, Bun, npm 경로도 있고, 이 경우 Node 18+와 Python 3.11+가 PATH에 있어야 한다. 이후 사용자는 /dag-ulw를 입력하기만 한다. 이때 라우터가 목표를 노드 그래프로 분해하고, 필요한 omh-* 전문 스킬을 도구 호출로 실행 중에 불러온다. 스킬은 SKILL.md 형식의 묶음으로 배포되며, Hermes 스킬 탭 경로로도 붙일 수 있다. hermes skills tap add rlaope/oh-my-hermes 후 hermes skills install rlaope/oh-my-hermes/skills/omh-routing --yes를 실행한다. omh doctor로 상태를 확인하고, omh update는 설치 경로를 감지해 관리 대상 스킬과 플러그인 번들, Hermes 등록을 갱신한다. OMH Native에서는 bare omh로 자체 TUI를 열고, /dag-ulw가 박스 그래프와 레인 트리를 출력한다. Hermes 자체는 수정되지 않는다.
전제와 한계
내부 구성은 카테고리 태그, 모델 체인, 스킬 라우터, 검증 노드, 기억 파이프라인으로 나뉜다. 작업 카테고리는 ultrabrain, deep, visual-engineering, quick 등으로 태깅되고, 각 카테고리는 모델 체인과 추론 강도를 갖는다. 체인은 편집 가능한 목록이며 공급자가 모델을 거부하면 다음 항목으로 넘어간다. omh-* 접두사의 전문 스킬은 프런트엔드, 백엔드, Rust, 보안 리뷰, 검증 게이트 등으로 나뉘고 사용자가 직접 호출하지 않는다. 라우터가 실행 중에 필요한 것을 도구 호출로 불러온다. /dag-ulw는 목표를 노드 그래프로 분해하고 준비된 노드를 병렬 실행하며, 별도 노드가 목표를 검사하고 실패한 노드를 보고서 앞에서 복구한다. 상태 표기는 Plan · not run, Code · reported done, Test · verified 세 단계로 고정된다. 기억은 후보별로 보관·거부·보류 결정과 사유를 남기고, 다음 세션에 작업 순위와 토큰 예산으로 잘린 회수 팩을 넘긴다. OMH Native TUI는 /theme로 외형을 바꾸고, /dag-ulw가 박스 그래프와 레인 트리를 출력한다.
프롬프트를 직접 쓰는 방식과 구조적으로 다르다. 직접 작성한 프롬프트는 한 세션 안에서만 유효하고 모델 선택·병렬 실행·완료 판정을 규율하지 않는다. CLAUDE.md나 AGENTS.md 같은 단일 규칙 파일은 정적 텍스트로 로드되어 작업마다 같은 지침을 반복하지만, OMH는 작업 카테고리별로 모델 체인과 추론 강도를 표로 두고 실행 시점에 라우팅한다. 플러그인과도 다르다. 플러그인은 도구를 추가하지만 OMH는 실행 절차 자체를 규율한다. Hermes를 패치하거나 대체하지 않는다는 경계가 명시되어 있어 기존 Hermes 설정과 충돌하지 않는다. 스킬 팩이므로 규칙 파일 하나를 복사하는 방식이 아니라, 설치 스크립트가 관리 대상 스킬과 플러그인 번들, Hermes 등록을 함께 갱신한다. 검증 게이트와 기억 결정 사유를 남기는 절차가 기본 포함이라는 점도 단일 규칙 파일과 구분된다.
설치 후 첫 사용에서 확인할 것은 세 가지다. omh doctor로 설치 상태와 의존성을 점검하고, omh model로 카테고리별 모델 체인과 추론 강도를 확인한다. 화살표 키로 카테고리를 고르고 좌우로 헤드 모델, -/+로 강도를 조정한다. 같은 피커가 OMH TUI 안에서 /omh-model로 열린다. 새 모델 패밀리를 온보딩하려면 Hermes에서 /omh-model-setup 스킬을 쓴다. 그다음 /dag-ulw를 입력하면 목표가 노드 그래프로 분해되고 박스 그래프와 레인 트리가 출력된다. 레인 트리에서 각 레인의 모델, 추론 강도, 토큰 사용량을 확인할 수 있다. 에이전트 목록에서 실행 중인 에이전트를 조종하거나 중단할 수 있고, !로 셸 명령을 실행하며 Esc Esc로 되감는다. 업데이트는 omh update가 설치 경로를 감지해 처리한다.
Hermes Agent 위에서 도는 운영 계층이므로 Hermes가 없으면 동작하지 않는다. README는 붙는 대상으로 Claude Code를 명시하지만, 실제 실행 기반은 Hermes Agent의 게이트웨이와 스킬 시스템이다. Bun이나 npm 경로로 설치하면 Node 18+와 Python 3.11+가 PATH에 있어야 하고, Homebrew는 자체 Python을 함께 설치한다. Windows는 PowerShell 5.1+가 필요하다. Hermes 자체 기억은 읽지도 패치하지도 않는다는 경계가 명시되어 있어, 기존 Hermes 메모리와 OMH 기억은 별개로 동작한다. 모델 체인은 공급자 거부 시 다음 항목으로 넘어가지만 체인에 등록되지 않은 모델을 즉석에서 쓰지는 않는다. 검증 게이트를 통과하지 않은 실행은 verified로 표기되지 않으므로, 테스트나 CI가 없는 저장소에서는 verified 단계에 도달하기 어렵다. omh update가 소유 매니저를 찾지 못하면 패키지 매니저 명령을 직접 써야 한다.
작업 성격이 여러 갈래로 갈리고 모델 선택을 매번 즉흥 판단으로 정하고 있다면 OMH를 쓴다. 병렬로 돌릴 노드가 많고 쓰기 범위 충돌을 막아야 하는 경우에도 적합하다. 완료 보고의 신뢰가 문제라면, 즉 계획만 세운 실행과 검증된 실행이 같은 '완료'로 보인다면 표기 규칙을 강제하는 이 계층이 필요하다. 반대로 단일 파일 수정이나 한 번의 질의응답처럼 노드 그래프로 쪼갤 것이 없는 작업에는 그래프 실행이 과하다. 모델을 하나로 고정해 쓰고 있고 공급자 전환이 필요 없다면 모델 체인 관리의 이점이 없다. Hermes를 쓰지 않는 환경이라면 설치 자체가 성립하지 않는다. 기억을 세션 간에 넘길 필요가 없고 검증 게이트를 두지 않는 저장소라면, 단일 규칙 파일이나 직접 작성한 프롬프트로 충분하다.