사례: revfactory/harness

revfactory/harness는 다른 사례와 결이 조금 다릅니다. 직접 제품을 만드는 하네스라기보다, 프로젝트에 맞는 하네스를 설계하고 생성하는 메타 하네스에 가깝습니다.

이 사례가 중요한 이유는, 하네스 설계 자체를 반복 가능한 산출물로 다룬다는 점입니다.

해결하려는 문제

• 프로젝트마다 필요한 역할 조합이 다름
• 팀이 하네스를 새로 만들 때 매번 바닥부터 설계함
• 문서만 만들고 실제 agent/skill 구조로 안 내려감

기술적 메커니즘

README 기준 revfactory/harness는 대략 아래 6단계 워크플로우를 가집니다.

이 파이프라인은 하네스를 설명으로 끝내지 않고, 실제로 에이전트와 스킬 파일 구조로 만들어낸다는 점에서 유의미합니다.

산출물 중심으로 보면

예상 디렉터리 구조는 대략 이런 형태입니다.

왜 이게 엔지니어링인가

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가 실제 누락을 줄이는지 여부

이 단계가 없으면 생성된 하네스는 템플릿 더미가 됩니다.

우리 팀으로 옮길 것

그대로 복제하면 안 되는 점

• 생성만 해놓고 실제 운영 관측이 없으면 금방 드리프트합니다.
• agent team 구조는 도메인에 따라 과할 수 있습니다.
• 생성된 스킬은 팀이 직접 다듬는 후속 편집이 필요합니다.

revfactory/harness 사례의 핵심은, 하네스를 "만들어 쓰는 것"에서 한 단계 더 나아가 설계, 생성, 검증 가능한 아키텍처 자산으로 본다는 점입니다.

참고

• revfactory/harness README, 2026-04-01 열람 기준