AI 에이전트 팀을 자동으로 설계하는 5.3K 스타 프로젝트

오늘 GitHub Trending을 둘러보다가 저를 멈춰 서게 만든 무언가를 발견했습니다.

revfactory/harness — 단 5.3K 개의 스타를 보유하고 있지만(신규 프로젝트입니다), 그 아이디어는 제가 멀티 에이전트 (multi-agent) 분야에서 본 것 중 가장 강력한 것 중 하나입니다.

사용자가 작업 중인 도메인 (domain)을 알려주면, 이 프로젝트는 팀 구조를 설계하고, 각 에이전트의 직무 기술서 (job description)를 생성하며, 업무 수행에 필요한 기술/참조 문서 (skills/reference docs)를 작성합니다.

핵심 아키텍처: L3 메타-팩토리 (L3 Meta-Factory)

Harness는 메타-팩토리 (meta-factory)로서 작동합니다.

Phase 0: 기존 에이전트/기술 감사 (Audit existing agents/skills)
Phase 1: 도메인 분석 (Domain analysis)
Phase 2: 팀 아키텍처 설계 (6가지 패턴) (Team architecture design)
Phase 3: 에이전트 정의 (Agent definitions)
Phase 4: 기술 생성 (Skill generation)
Phase 5: 오케스트레이터 통합 (Orchestrator integration)
Phase 6: 검증 (Validation)

6가지 아키텍처 패턴

1. 파이프라인 (Pipeline) — 순차적 의존 작업
2. 팬아웃/팬인 (Fan-out/Fan-in) — 병렬 독립 작업
3. 전문가 풀 (Expert Pool) — 온디맨드 (On-demand) 전문가 선택
4. 생산자-검토자 (Producer-Reviewer) — 생산 + 품질 게이트 (quality gate)
5. 감독자 (Supervisor) — 중앙 디스패처 (central dispatcher)
6. 계층적 위임 (Hierarchical Delegation) — 재귀적 위임

대부분의 실제 시스템은 2~3가지 패턴을 혼합하여 사용하는 것만으로 충분합니다.

3가지 핵심 요점

1. Phase 0: 구축 전 감사 (Audit Before Building) — 새로운 것을 만들기 전에 항상 이미 존재하는 것이 무엇인지 확인하십시오.

2. 기술을 위한 점진적 공개 (Progressive Disclosure for Skills) — 3단계 로딩 방식은 컨텍스트 오염 (context pollution)을 방지합니다.

3. '왜(Why)' 우선 원칙 (The Why-First Principle) — 무엇(what)을 하는지뿐만 아니라 왜(why) 하는지를 설명하십시오. LLM (Large Language Models)은 컨텍스트 (context)가 있을 때 더 잘 추론합니다.

나쁜 예: "항상 pdfplumber를 사용하세요. PyPDF2는 절대 사용하지 마세요."
좋은 예: "PyPDF2는 행/열 구조를 보존하지 못하므로 pdfplumber를 사용하세요."

큰 교훈

멀티 에이전트 시스템 설계는 기술을 설계하는 기술입니다. 에이전트를 직접 만드는 것보다 에이전트를 만드는 메타-프레임워크 (meta-framework)를 구축하는 것이 훨씬 더 영향력이 큽.

확인하기: revfactory/harness | 내 컬렉션