코드베이스를 조였다면, 이제 에이전트 쪽 차례다

전편에서 헥사고날·ArchUnit·커버리지 같은 코드베이스 쪽 하네스를 다뤘다. 규율이 기계적으로 강제되는 코드베이스는 에이전트에게 최고의 가드레일이라는 이야기였다.

그런데 가드레일은 도로의 절반이다. 나머지 절반은 에이전트 자신에게 채우는 하네스 — 어떤 절차로 일하고, 몇 명이 어떻게 협업하고, 무엇을 만들지 어떻게 확정하는가다. Claude Code 플러그인 생태계에서 이 절반을 담당하는 세 도구를 실제로 함께 굴려본 경험을 정리한다: Superpowers, OMC(oh-my-claudecode), Ouroboros.

결론부터: 셋은 경쟁 관계가 아니다. 서로 직교하는 세 개의 축이고, 겹치는 지점은 단 한 곳뿐이다.

3축 좌표계

축 도구 답하는 질문 핵심 장치
HOW Superpowers 어떤 절차와 규율로 일하는가 프로세스 스킬(브레인스토밍→계획→TDD→검증)
WHO OMC 누가(몇 명이, 어떤 모델이) 일하는가 멀티에이전트 편성·모델 티어 매칭
WHAT Ouroboros 무엇을 만들지 어떻게 확정하는가 소크라테스식 인터뷰→불변 스펙(Seed)→평가 루프

HOW — Superpowers, 절차의 하네스

Superpowers는 에이전트의 작업 순서를 강제한다. “만들어줘”라고 하면 곧장 코드부터 쓰는 LLM의 본능을 브레인스토밍 스킬이 가로막고, 요구사항을 한 번에 하나씩 확정한 뒤에야 설계→계획→태스크별 TDD→독립 리뷰→검증의 파이프라인을 태운다. 각 단계에 게이트가 있다: 설계는 승인 전 구현 금지(HARD-GATE), TDD는 RED 증거 필수, 완료 선언은 검증 출력 첨부 필수. 단독편에서 자세히 다뤘다.

WHO — OMC, 편성의 하네스

OMC는 에이전트 하나로 부족할 때의 레이어다. 작업을 전문화된 서브에이전트들에게 나누고, 태스크 난이도에 모델 티어를 매칭하고(기계적 전사면 저가 모델, 판단이 필요하면 상위 모델), 오케스트라 전체의 진행을 관측 가능하게 만든다. 역시 단독편이 있다.

WHAT — Ouroboros, 명세의 하네스

이번 글의 새 축이다. Ouroboros의 슬로건은 도발적이다: “Stop prompting. Start specifying.”

이 도구의 통찰은, AI 코딩 실패의 대부분이 출력이 아니라 입력에서 발생한다는 것이다. 모호한 프롬프트를 받으면 에이전트는 추측으로 빈칸을 메우고, 그 추측은 PR 리뷰에서야 드러난다. Ouroboros는 이 순서를 뒤집는다:

interview → seed → execute → evaluate → evolve
    ↑                            │
    └────── 진화 루프 ────────────┘
  • interview: 소크라테스식 질문으로 숨은 가정을 폭로한다. “태스크 CLI 만들어줘” 한 줄에서 12개의 미확정 가정을 끄집어낸다.
  • seed: 답변을 불변 스펙으로 결정화한다. 모호성 점수가 기준(≤0.2)을 넘으면 코드 작성 자체가 차단된다.
  • evaluate: 3단 게이트 — 기계 검증(무료)→의미 검증→다중 모델 합의.
  • evolve/ralph: 평가 출력이 다음 세대 스펙의 입력이 되는 루프를 온톨로지가 수렴할 때까지(유사도 ≥0.95) 돌린다. ralph는 이 루프를 세션 경계를 넘어 지속시킨다 — 각 스텝이 무상태고 이벤트 스토어가 계보를 복원하므로 머신이 재시작해도 이어진다.

상관관계 — 직교하는 세 축, 겹침은 한 곳

세 도구를 같이 켜보면 역할 분담이 자연스럽게 그려진다:

Ouroboros (WHAT) ──"이걸 만든다"──▶ 불변 스펙
                                      │
Superpowers (HOW) ──"이 순서로"──▶ 계획→TDD→리뷰 게이트
                                      │
OMC (WHO) ──"이 편성으로"──▶ 태스크별 서브에이전트 + 모델 티어

스펙이 흔들리면 절차가 아무리 좋아도 엉뚱한 것을 정확하게 만든다(WHAT의 실패). 스펙이 좋아도 절차가 없으면 테스트 없는 그럴듯한 코드가 쌓인다(HOW의 실패). 둘 다 좋아도 800줄 파일을 에이전트 하나가 다 들고 있으면 컨텍스트가 터진다(WHO의 실패). 세 축은 서로의 실패 모드를 메꾼다.

겹침은 정확히 한 곳이다: 평가 게이트. Ouroboros의 evaluate(3단 검증)와 Superpowers의 태스크별 독립 리뷰는 같은 자리를 노린다. 둘 다 켜면 이중 게이트가 되는데, 실무에선 이렇게 조율했다 — 태스크 단위 게이트는 Superpowers 리뷰(빠르고 diff 스코프), 스펙/산출물 단위 게이트는 Ouroboros식 독립 채점(신선한 컨텍스트로 완결성·모호성·테스트가능성 점수화). 층이 다르면 중복이 아니라 보강이다.

실측 — 실제로 돌려본 것들만

이 상관관계가 종이 위의 그림이 아니라는 증거로, 최근 하루 동안 실제로 굴린 세 장면.

장면 1 — Ouroboros식 독립 스펙 채점이 구멍 6개를 잡다. lemuel-xr 섀도우 게이트 작업에서 스펙을 쓰고 셀프 리뷰까지 마친 상태였다. 그 위에 신선한 컨텍스트의 독립 채점자를 태웠더니(완결성·테스트가능성·모호성·아키텍처 제약·AC·스코프 6차원) 점수 0.78 — 통과선 0.8 미달. “에러 상태 우선순위 미정의”, “메트릭 인터페이스에 문서화 안 된 파라미터” 같은, 저자는 절대 못 보는 구멍 6개가 나왔다. 전부 문서로 명문화한 뒤 구현을 진행했고, 그 6개 중 4개는 실제로 구현 중 판단이 필요했던 지점이었다.

장면 2 — TraceGuard, 증거 없는 합성을 실제로 거부하다. Ouroboros 생태계의 실험체 rlm-forge는 “부모의 주장은 자식이 만든 증거 핸들로 뒷받침돼야 한다”는 계약을 결정론적으로 강제한다(TraceGuard). 라이브로 6분짜리 재귀 실행을 돌렸더니 마지막 합성 단계에서 모델이 계약(구조화 JSON)을 어겼고 — 게이트가 그 자리에서 실행을 하드 실패시켰다. 게이트가 없었다면 그 부실한 산문 합성이 그대로 통과했을 것이다. “그럴듯함”을 신뢰의 근거로 삼지 않는다는 하네스 철학의 가장 극단적인 실물이었다.

장면 3 — 세 축이 한 파이프라인에. 같은 작업에서 Superpowers가 절차(브레인스토밍 4결정→스펙→계획→TDD 6태스크)를, 태스크별 서브에이전트+모델 티어 매칭이 편성을, Ouroboros식 채점이 명세 게이트를 맡았다. 결과는 전편에 쓴 대로 — 수백 개 통합 테스트가 한 번도 깨지지 않은 채 하루 만에 main 머지.

기대효과 — 무엇이 실제로 좋아지는가

  1. 재작업의 위치가 앞으로 당겨진다. 가장 비싼 발견(잘못된 가정)이 PR 리뷰에서 인터뷰/채점 단계로 이동한다. 수정 비용이 자릿수로 다르다.
  2. “그럴듯한 완료”가 사라진다. 절차 게이트(RED 증거, 검증 출력)와 명세 게이트(모호성 점수, 증거 계약)가 이중으로 “봤다고 치자”를 차단한다.
  3. 속도와 품질의 트레이드오프가 완화된다. 편성 축이 병렬성을, 절차 축이 품질을, 명세 축이 방향을 담당하니 셋을 동시에 당길 수 있다.
  4. 하네스 자체가 복리로 좋아진다. 각 도구가 남기는 흔적(스킬, 이벤트 스토어, 리뷰 레저)이 다음 작업의 입력이 된다 — 플라이휠 글에서 다룬 그 사이클이다.

정직한 한계

  • 중첩 실행 제약. Ouroboros의 qa/evaluate MCP 툴은 내부에서 Claude CLI를 서브프로세스로 띄우는데, 이미 Claude Code 세션 안에서 부르면 중첩 호출로 죽는다. 실무에선 같은 채점 기준을 fresh 서브에이전트로 재현해 우회했다 — 도구는 못 썼지만 패턴은 이식 가능했다는 점이 오히려 교훈이다.
  • 학습 곡선과 의식(ritual) 비용. 인터뷰→스펙→채점은 5분짜리 수정엔 과하다. 축마다 켜야 할 최소 규모가 있다.
  • 게이트 중복 조율은 수동. evaluate와 리뷰 게이트의 역할 분담은 아직 사람이 정해야 한다.

어디부터 도입할까

경험상 순서는 이렇다. ① HOW부터 — Superpowers는 혼자서도 즉시 효과가 있고 실패 비용이 없다. ② 작업이 커지면 WHO — 태스크가 3개 이상으로 쪼개질 때 OMC식 편성이 값을 한다. ③ 요구사항이 흐릴 때 WHAT — “뭘 만들지”부터 불확실한 프로젝트라면 Ouroboros식 인터뷰·채점이 가장 큰 레버리지다.

전편의 결론과 합치면 그림이 완성된다. 코드베이스에는 위반이 스스로 드러나는 규율을(아키텍처 하네스), 에이전트에게는 절차·편성·명세의 3축을(에이전트 하네스). 도로와 차 양쪽에 가드레일이 서면, 그때부터 속도는 무섭지 않다.

시리즈: 아키텍처 규율은 어떻게 에이전트의 하네스가 되는가 · Superpowers — 프롬프트 하네스 · OMC — 오케스트레이션 레이어 · 하네스 플라이휠