여섯 개의 도구, 하나의 경제

하네스 시리즈를 세 편 썼습니다 — Superpowers의 절차 규율, OMC의 편성 레이어, 그리고 도구함 8선. 이번 글은 그 마무리로, 도구함에서 고른 세 개(skill-creator, plugin-dev, session-report)가 이미 운영 중인 세 개(Superpowers, OMC, Ouroboros)와 만났을 때 무슨 일이 벌어지는지를 분석합니다.

결론을 먼저 말하면: 이 여섯은 겹치지 않습니다. 대신 지금까지 끊겨 있던 사이클 하나를 닫습니다.

기존 스택의 공통 전제: “좋은 스킬은 이미 존재한다”

세 기존 레이어의 성격을 한 줄씩 요약하면 이렇습니다.

Superpowers — 스킬을 소비하는 규율. “행동 전에 관련 스킬을 반드시 호출하라.”
OMC — 스킬과 에이전트를 편성하는 레이어. 69개 스킬·19종 에이전트를 작업 복잡도에 따라 라우팅.
Ouroboros — 작업을 스펙부터 굳히는 워크플로. 인터뷰 → 불변 시드 → 실행 → 평가.

강력한 조합이지만, 셋 다 숨은 전제가 있습니다. 좋은 스킬이 이미 존재한다는 것. Superpowers는 있는 스킬을 강제로 쓰게 하고, OMC는 있는 스킬을 배치하며, Ouroboros는 있는 절차 위에서 스펙을 굳힙니다. 그런데 그 스킬을 만들고, 품질을 재고, 배포 가능하게 포장하는 공정은 어디에도 없습니다.

실제로 제 환경이 그렇습니다. 클러스터 다이어그램 렌더링, JVM 진단 5종, RLM 실행 래퍼 같은 자작 스킬들이 전부 수작업으로 만들어져 ~/.claude/skills에 산재해 있죠. 작동은 하지만, 품질이 측정된 적도 버전 관리된 적도 없습니다.

새 3종이 채우는 빈칸: 생산 공정

skill-creator — 품질 공장

스킬을 생성·개선하는 도구는 흔하지만 skill-creator의 핵심은 측정입니다. 스킬이 실제로 에이전트 행동을 개선했는지 평가하는 루프까지 닫혀 있죠.

이게 Superpowers와 만나면 정확한 궁합이 됩니다. Superpowers는 “스킬이 있으면 반드시 써라”를 강제하는데 — 스킬 품질이 나쁘면 나쁜 절차를 강제하는 꼴이 됩니다. 강제 소비자 옆에는 품질 공장이 있어야 합니다. skill-creator의 측정 루프가 바로 그 안전판입니다.

Ouroboros와는 철학이 공명합니다. “주장 전에 증거, 완료 전에 평가”라는 원칙을 스킬 제작에 적용하면, 스킬 하나를 만드는 일도 인터뷰로 스펙을 굳히고 → 제작하고 → 평가하는 파이프라인이 됩니다. 스킬이 코드와 같은 대접을 받게 되는 거죠.

session-report — 비용 관측소

OMC는 이 스택에서 가장 비싼 레이어입니다. 세션마다 상시 ~3.2k 토큰을 얹고, 팀 모드가 돌면 에이전트 팬아웃으로 토큰이 곱해집니다. OMC의 HUD가 실시간 계기판이라면, session-report는 사후 해부대입니다 — 토큰 사용, 캐시 효율, 서브에이전트별·스킬별 소비를 HTML 리포트로 펼쳐줍니다.

이 관측이 있어야 답할 수 있는 질문들이 있습니다. “team 모드 한 번에 실제로 얼마 들었나?” “Superpowers 스킬 중 상시 비용만 내고 한 번도 호출 안 된 게 뭔가?” 감으로 운영하던 하네스 비용이 데이터가 됩니다. 안 쓰이는 스킬을 정리할 근거도 여기서 나옵니다.

plugin-dev — 포장과 배포

흩어진 자작 스킬들이 어느 수준을 넘으면, 버전 관리되는 정식 플러그인으로 묶는 게 맞습니다. plugin-dev는 그 전환(훅·MCP 연동 포함)을 돕는 툴킷입니다. 제 경우라면 클러스터 운영 스킬들을 “lemuel-ops” 같은 플러그인으로 묶어, Superpowers나 OMC처럼 다른 머신·세션에 한 방에 설치되는 자산으로 만드는 경로죠.

플라이휠: 여섯 개가 하나의 사이클로

이제 여섯 도구를 한 그림에 놓으면 사이클이 보입니다.

① Ouroboros ─ 스킬/작업의 스펙을 인터뷰로 굳힘
      │
      ▼
② skill-creator ─ 스킬 제작 + 품질 측정
      │
      ▼
③ Superpowers / OMC ─ 런타임에서 소비(규율)·편성(팀)
      │
      ▼
④ session-report ─ 실제 비용·호출·효과를 실측
      │
      ▼
⑤ plugin-dev ─ 검증된 스킬을 플러그인으로 포장·배포
      │
      └────────── 측정 결과가 다시 ①②의 개선 입력으로 ──┐
                                                      ▼
                                              (사이클 반복)

기존 3개가 “스킬을 잘 쓰는 체계”라면, 새 3개는 “스킬을 잘 만들고·재고·파는 공장입니다. 합치면 소비 → 생산 → 측정 → 개선이 도는 완전한 하네스 경제가 됩니다.

주의: 딱 하나 겹치는 지점

이 조합에서 유일하게 신경 쓸 중복은 OMC의 /skillify vs skill-creator입니다. 둘 다 “경험에서 스킬을 추출”하죠. 다만 대상이 다릅니다.

/skillify → OMC 자체 스킬 체계(.omc/skills/, OMC의 키워드 주입 방식)
skill-creator → Claude Code 네이티브 스킬 (Superpowers도 보는 그 스킬)

권장 분업은 명확합니다. 표준 스킬 자산은 skill-creator(네이티브)로, OMC 팀 모드 안에서만 쓰는 패턴은 /skillify로. 같은 스킬을 양쪽에 이중으로 만들지만 않으면 충돌은 없습니다.

맺으며: 도구 수집이 아니라 사이클 완성

이 시리즈 내내 반복한 원칙이 있습니다 — 도구를 쌓는 게 목적이 아니라 규율을 세우는 게 목적이라는 것. 여섯 개의 도구가 정당화되는 이유는 개수가 아니라, 각자가 사이클의 서로 다른 단계를 맡아 피드백 루프를 닫기 때문입니다.

체감 순서로는 두 가지부터 시작하는 걸 권합니다. 첫째, skill-creator로 이미 있는 자작 스킬들의 품질을 측정해보는 것 — 아마 생각보다 편차가 클 겁니다. 둘째, session-report로 오케스트레이션 비용을 가시화하는 것 — 멀티에이전트의 청구서가 처음으로 항목별로 보이게 됩니다. 생산과 관측이 서면, 나머지 사이클은 자연스럽게 돌기 시작합니다.