“겹쳐 쓰는 스택”에서 “고르는 주축”으로

며칠 전 나는 Superpowers × OMC × Ouroboros를 3축 하네스 스택으로 소개했다. 세 개를 겹겹이 얹으면 시너지가 난다는 톤이었다. 그런데 실전 마일리지가 쌓이니 결론이 바뀌었다. 하네스는 겹쳐 쓰는 게 아니라, 주축을 고르고 나머지는 부품으로 쓰는 것이다.

이유는 단순하다. 하네스끼리도 자원을 두고 경합한다. 컨텍스트 예산, 토큰, 제어권 — 이 셋은 유한한데, 하네스를 한 겹 얹을 때마다 셋을 다 조금씩 먹는다. 여러 겹을 순진하게 쌓으면 비용과 드리프트가 더해지는 게 아니라 곱해진다. 그래서 “무엇을 얹을까”보다 “무엇을 주축으로 삼을까”가 먼저다.

이 글은 세 하네스를 실제로 굴려본 뒤의 개인적 평가, 그리고 앞으로 왜 Ouroboros를 주축으로 두려 하는지에 대한 고찰이다.

Superpowers — 쉽지만, 메타스킬이 드리프트를 ‘만든다’

Superpowers의 진입장벽은 낮다. 스킬을 설치하고 대화를 시작하면 끝이다. 그게 장점이자 함정이다.

핵심은 using-superpowers 같은 메타스킬이다. “어떤 작업이든 스킬을 먼저 확인하고 호출하라”는 강제 규칙이 매 턴 컨텍스트의 앞자리를 선점한다. 문제는 두 가지다.

  • 컨텍스트를 잡아먹는다. 메타 규칙과 스킬 지시문이 컨텍스트 예산을 먼저 가져가면, 정작 풀어야 할 본 작업의 정보가 뒤로 밀린다. 예산이 빠듯한 긴 작업일수록 손해가 크다.
  • 바이어스를 만든다. “무조건 스킬 먼저”는 편향이다. 스킬이 정한 절차 쪽으로 사고가 쏠리면, 그 절차가 이 상황에 안 맞아도 끌려간다. 절차에 대한 순응이 누적되면 원래 목표에서 이탈(drift)한다.

역설적이다. 하네스는 드리프트를 줄이려고 쓰는 건데, Superpowers의 메타 계층은 오히려 드리프트를 만든다. 쓰기 쉬워서 초보 단계엔 좋지만, 주축으로 추천하지는 않는다. 개별 스킬만 골라 쓰고 메타스킬은 끄는 정도가 현실적이다.

OMC — 강력한 멀티에이전트, 그러나 유지보수 공백

oh-my-claudecode(OMC)는 결이 다르다. 서브에이전트를 많이 쓴다. 팀을 꾸리고, 병렬로 굴리고, 오케스트레이션한다. 멀티에이전트 설계의 교과서에 가깝다.

두 가지 현실을 인정해야 한다.

  • 비용. 서브에이전트를 많이 띄운다는 건 토큰·조정 비용이 크다는 뜻이다. 병렬성은 공짜가 아니다.
  • 유지보수. 지금 OMC는 전담 메인테이너가 따로 없는 상태다. 프로덕션 주축으로 삼기엔 유지보수 리스크가 있다.

그래서 내 결론은 이렇다. OMC는 공부용으로 보는 걸 추천한다. 멀티에이전트를 어떻게 나누고 합치는지, 팀 오케스트레이션을 어떻게 짜는지 — 그 패턴을 배우는 참고서로는 최고다. 다만 “매일 기대는 주축”과 “패턴을 배우는 참고서”는 다른 자리다.

Ouroboros — 드리프트를 ‘만드는’ 대신 ‘재는’ 축

여기서 Ouroboros가 갈린다. 앞의 둘이 각각 드리프트를 만들거나(Superpowers) 비용을 키우는(OMC) 지점에서, Ouroboros는 정반대 방향의 설계를 갖고 있다.

1) spec-first + measure_drift — 드리프트를 측정 가능한 지표로

Ouroboros의 루프는 이렇다: 인터뷰 → 불변 스펙(seed) → 실행(execute) → 개선(evolve_step, Wonder+Reflect) → 평가(evaluate/measure_drift) → 계보(lineage).

여기서 결정적인 건 measure_drift다. 목표를 먼저 불변 seed로 굳혀 놓고, 실행 결과가 그 seed에서 얼마나 벗어났는지를 수치로 잰다. Superpowers가 드리프트를 은근히 만든다면, Ouroboros는 드리프트를 1급 관측 대상으로 올린다. 이 차이가 크다. 잴 수 없으면 관리할 수 없다.

2) TraceGuard / evidence-gate — 환각을 결정론적으로 막는다

Ouroboros(그리고 그 위의 rlm-forge)는 TraceGuard로 부모의 종합(synthesis)이 자식이 만든 증거 없이는 주장을 못 하도록 결정론적으로 강제한다. LLM 판단에 기대는 게 아니라, 증거 인용 여부를 규칙으로 검사한다. 멀티에이전트를 쓰더라도 “그럴듯한데 근거 없는” 결과가 위로 새는 걸 막는다.

3) rlm-forge — 토큰 효율을 재귀로 푼다

토큰 효율을 위해 Ouroboros에는 rlm-forge(Recursive Language Models)를 적용했다. 복잡한 작업을 재귀 하위호출로 쪼개고, Hermes Agent를 inner inference로, Ouroboros를 오케스트레이션으로 쓴다. 긴 컨텍스트를 통째로 우겨넣어 truncation으로 잃는 대신, 재귀로 나눠 다루니 토큰 예산이 컨텍스트 길이에 선형으로 폭발하지 않는다. 오프라인 replay/truncation 벤치마크는 이미 통과 상태다(pytest -q 73 passed, offline replay OK).

4) MCP 서버 = 호스트 독립

Ouroboros는 MCP 서버로 표준화돼 있어 Claude Code·Codex·OpenCode 어느 호스트에서든 같은 도구 25종을 쓴다. 특정 CLI에 잠기지 않는다. 주축을 하나 고르되 그 주축이 호스트에 종속되지 않는다는 건 큰 안전마진이다.

앞으로의 사용법 — 주축 하나 + 부품 몇 개

정리하면 내가 앞으로 갈 방향은 이렇다.

  • 주축: Ouroboros. ooo auto "goal" 또는 MCP 툴 ouroboros_auto로 진입 → interview로 seed를 굳히고 → execute → evolve_step → 매 사이클 measure_drift로 이탈을 계측 → lineage로 계보를 남긴다. 드리프트를 만드는 하네스가 아니라 재는 하네스를 중심에 둔다.
  • 부품 1: Superpowers의 개별 스킬만. 메타스킬(무조건 스킬 먼저)은 끄고, 유용한 개별 스킬만 상황에 맞게 호출한다. 편향과 컨텍스트 낭비를 피한다.
  • 부품 2: OMC는 참고서로. 멀티에이전트 분할·병합 패턴을 배우되, 유지보수 공백을 감안해 프로덕션 의존은 피한다.

고찰 — 남은 열린 질문: “in-run 벤치마크”

가장 재미있는 미해결 문제는 이거다. 실제 run에서 벤치마크를 어떻게 붙일 것인가.

지금 rlm-forge의 벤치마크(replay, truncation-benchmark)는 오프라인 검증에는 잘 된다. 정해진 입력을 재생해 회귀를 잡는다. 하지만 실전은 다르다. 진짜 궁금한 건 live run 한 번 한 번의 품질과 토큰 트레이드오프다. 몇 가지 방향을 고민 중이다.

  • measure_drift를 실시간 지표로. seed 이탈도를 사후 평가가 아니라 사이클마다 실시간으로 노출하면, “토큰을 더 써서 드리프트를 줄일지”를 run 도중에 결정할 수 있다.
  • 토큰당 스펙 준수율. 같은 seed를 두 경로로 실행했을 때, 투입 토큰 대비 스펙 충족도를 비교 메트릭으로 세우면 재귀 분할이 실제로 이득인지 run별로 판정할 수 있다.
  • 벤치마크를 lineage에 심기. 계보에 벤치마크 결과를 함께 기록하면, 개선(evolve_step)이 진짜 개선인지 계보를 따라 추적할 수 있다.

아직 답은 없다. 하지만 주축을 “드리프트를 재는 시스템”으로 골랐기 때문에 이 질문을 던질 수 있다는 게 핵심이다. 드리프트를 만드는 하네스 위에서는 애초에 “얼마나 벗어났나”를 물을 수조차 없다.

한 줄 요약

하네스 엔지니어링의 성숙은 “많이 얹기”에서 “적게, 측정 가능하게”로 간다. Superpowers는 쉽지만 드리프트를 만들고, OMC는 강력하지만 유지보수가 비었다. 남는 선택은 드리프트를 재고, TraceGuard로 근거를 강제하고, rlm-forge로 토큰을 아끼는 Ouroboros다. 주축은 하나, 나머지는 부품 — 그리고 다음 숙제는 그 주축 위에서 run마다 벤치마크를 붙이는 법이다.