사례: revfactory/harness
revfactory/harness를 하네스를 만드는 하네스로 보고, 생성 파이프라인과 validation 관점에서 해석합니다.
핵심 요약
- revfactory/harness는 제품을 만드는 하네스가 아니라 프로젝트에 맞는 하네스를 설계·생성하는 메타 하네스(L3 Meta-Factory)입니다.
- Domain Analysis → Team Architecture → Agent/Skill Generation → Integration → Validation의 6단계로, 노하우를 agent·skill 파일 구조로 외재화합니다.
- 도구나 프롬프트가 아니라 도메인(위험·반복 작업·불변식)부터 모델링하는 domain-first 설계가 첫 단계입니다.
- 협업·handoff가 필요하면 Agent Teams, 독립적 일회성 작업이면 더 가벼운 Subagents로 실행 모드를 구분합니다.
- README의 n=15 author-measured A/B 결과는 third-party replication pending이므로 성능 보장이 아니라 도입 가설로만 쓰고 팀 내부 pilot으로 다시 검증해야 합니다.
revfactory/harness는 다른 사례와 결이 조금 다릅니다. 직접 제품을 만드는 하네스라기보다 프로젝트에 맞는 하네스를 설계하고 생성하는 메타 하네스에 가깝습니다.
하네스 설계 자체를 반복 가능한 산출물로 다룬다는 점에서 살펴볼 만합니다.
2026년 5월 기준 README에서는 이 포지션이 한층 또렷해졌습니다. revfactory/harness는 스스로를 Claude Code 생태계의 L3 Meta-Factory / Team-Architecture Factory로 소개하고, domain sentence를 agent team과 skills로 바꾸는 도구라고 말합니다. 노리는 건 "좋은 프롬프트를 생성"하는 게 아니라 팀 아키텍처를 생성하는 쪽입니다.
해결하려는 문제
- 프로젝트마다 필요한 역할 조합이 다름
- 팀이 하네스를 새로 만들 때 매번 바닥부터 설계함
- 문서만 만들고 실제 agent/skill 구조로 안 내려감
- Agent Teams와 Subagents 중 어느 실행 구조가 맞는지 판단 기준이 없음
기술적 메커니즘
README를 보면 revfactory/harness는 대략 아래 6단계 워크플로우로 돌아갑니다.
이 파이프라인은 하네스를 설명으로 끝내지 않고 실제 에이전트와 스킬 파일 구조까지 만들어냅니다. 바로 거기에 의미가 있습니다.
산출물 중심으로 보면
| 단계 | 만드는 것 |
|---|---|
| Domain Analysis | 도메인 제약, 용어, 위험, 반복 작업 패턴 |
| Team Architecture Design | pipeline, fan-out/fan-in, expert pool, producer-reviewer, supervisor, hierarchical delegation 같은 팀 구조 |
| Agent Definition Generation | 역할별 에이전트 정의 |
| Skill Generation | 역할 수행용 스킬 |
| Integration & Orchestration | handoff와 협업 규칙 |
| Validation & Testing | 실제로 유효한지 검증 |
README는 실행 모드도 분리합니다.
| 모드 | 맞는 경우 |
|---|---|
| Agent Teams | 2개 이상의 agent가 협업하고 서로 메시지를 주고받아야 하는 경우 |
| Subagents | 일회성 전문 작업처럼 inter-agent communication이 필요 없는 경우 |
모든 역할 분리가 곧 팀 아키텍처는 아니라서 이 구분이 중요합니다. 협업 상태와 handoff가 필요하면 Agent Teams가 맞고, 독립적인 검토나 분석이면 Subagents가 더 가볍습니다.
예상 디렉터리 구조는 대략 이런 형태입니다.
왜 이게 엔지니어링인가
revfactory/harness는 하네스를 한 번 쓰고 끝나는 프롬프트 모음이 아니라
생성 가능한 시스템 구성요소로 봅니다.
하네스 설계 문제를 아래처럼 재정의하는 셈입니다.
- 도메인 분석은 requirements engineering
- 팀 구조 선택은 architecture design
- agent/skill 생성은 code generation
- validation은 test engineering
이렇게 보면 하네스는 추상적인 철학이 아니라 요구사항에서 구조와 아티팩트로 내려가는 설계 프로세스가 됩니다.
도메인 분석이 첫 단계인 이유
많은 팀이 하네스를 도구 목록이나 프롬프트 템플릿에서 시작합니다. revfactory/harness는 그보다 먼저 도메인을 봅니다.
domain_profile:
risk:
- "pricing"
- "schema migration"
recurring_tasks:
- "review pull request"
- "verify browser flow"
invariants:
- "auth boundary must not change without approval"
preferred_patterns:
- "producer-reviewer"
- "pipeline"이 입력이 있어야 "어떤 agent team이 필요한가"가 결정됩니다. 하네스 설계는 도구 선택이 아니라 도메인 모델링에서 시작합니다.
validation 단계가 중요한 이유
하네스가 생성됐다고 해서 곧바로 좋은 하네스는 아닙니다. revfactory/harness가 validation을 따로 명시하는 건 하네스도 결국 실험하고 비교해야 하는 대상이라서입니다.
예를 들면:
- skill을 썼을 때와 안 썼을 때 결과 차이
- subagent 구조와 team structure의 차이
- validation loop가 실제 누락을 줄이는지 여부
- 내부 2~4주 파일럿에서 팀 고유 지표가 개선되는지 여부
이 단계가 없으면 생성된 하네스는 템플릿 더미가 됩니다.
수치 해석 주의
README에는 sister repo의 15개 소프트웨어 엔지니어링 task를 기준으로 한 A/B 결과가 나옵니다. 다만 저자 측정, n=15, third-party replication pending이라는 caveat와 함께 읽어야 합니다. 이 책에서는 이 수치를 일반 성능 보장으로 쓰지 않고, 하네스 자체도 측정 대상이라는 근거로만 씁니다.
우리 팀으로 옮길 것
| 옮길 요소 | 적용 방식 |
|---|---|
| domain-first 설계 | 도구보다 위험, 반복 작업, 용어부터 정리 |
| agent/skill 산출물화 | 노하우를 파일 구조와 스킬로 외재화 |
| architecture pattern 선택 | pipeline, reviewer, expert pool 등을 의식적으로 선택 |
| harness validation | 하네스 자체의 효과를 비교 실험 |
| marketplace/plugin 배포 | 팀 설치와 업데이트 경로를 명시 |
그대로 복제하면 안 되는 점
- 생성만 해놓고 실제 운영 관측이 없으면 금방 드리프트합니다.
- agent team 구조는 도메인에 따라 과할 수 있습니다.
- 생성된 스킬은 팀이 직접 다듬는 후속 편집이 필요합니다.
- author-measured benchmark는 도입 가설로 쓰고, 팀 내부 pilot 지표로 다시 검증해야 합니다.
revfactory/harness 사례가 보여주는 건, 하네스를 "만들어 쓰는 것"에서 한 단계 더 나아가 설계하고 생성하고 검증할 수 있는 아키텍처 자산으로 다룬다는 대목입니다.
참고
- revfactory/harness README, 2026-05-23 열람 기준
- GitHub API 기준
revfactory/harnesspushed_at: 2026-05-15