gan-style-harness

GAN 스타일 하네스 스킬

Anthropic의 장기 실행 애플리케이션 개발을 위한 하네스 설계 (2026년 3월 24일)에서 영감을 얻음

**생성(generation)**과 **평가(evaluation)**를 분리하여, 단일 에이전트가 달성할 수 있는 수준을 훨씬 뛰어넘는 품질을 이끌어내는 적대적 피드백 루프를 생성하는 멀티 에이전트 하네스입니다.

핵심 통찰

자신의 작업물을 평가하라는 요청을 받으면 에이전트는 병적인 낙관주의자가 됩니다. 평범한 결과물을 칭찬하고 정당한 문제들을 무시하곤 하죠. 하지만 별도의 평가자를 엄격하게 설계하는 것은 생성자에게 자기 비판을 가르치는 것보다 훨씬 다루기 쉽습니다.

이것은 GAN(Generative Adversarial Networks)과 동일한 역학입니다. 생성자가 생성하고, 평가자가 비판하며, 그 피드백이 다음 반복(iteration)을 주도합니다.

사용해야 할 때

• 한 줄의 프롬프트에서 전체 애플리케이션 구축
• 높은 시각적 품질이 필요한 프론트엔드 디자인 작업
• 단순히 코드가 아닌 작동하는 기능이 필요한 풀스택 프로젝트
• "AI 조잡함(AI slop)" 미학을 수용할 수 없는 모든 작업
• 프로덕션 품질의 결과물을 위해 $50-200를 투자하려는 프로젝트

사용하지 말아야 할 때

• 빠른 단일 파일 수정 (표준 claude -p 사용)
• 예산 제약이 엄격한 작업 (<$10)
• 단순 리팩터링 (대신 de-sloppify 패턴 사용)
• 테스트가 이미 잘 정의된 작업 (TDD 워크플로우 사용)

아키텍처

                    ┌─────────────┐
                    │   PLANNER   │
                    │  (Opus 4.6) │
                    └──────┬──────┘
                           │ Product Spec
                           │ (features, sprints, design direction)
                           ▼
              ┌────────────────────────┐
              │                        │
              │   GENERATOR-EVALUATOR  │
              │      FEEDBACK LOOP     │
              │                        │
              │  ┌──────────┐          │
              │  │GENERATOR │--build-->│──┐
              │  │(Opus 4.6)│          │  │
              │  └────▲─────┘          │  │
              │       │                │  │ 실시간 앱
              │    피드백               │  │
              │       │                │  │
              │  ┌────┴─────┐          │  │
              │  │EVALUATOR │<-test----│──┘
              │  │(Opus 4.6)│          │
              │  │+Playwright│         │
              │  └──────────┘          │
              │                        │
              │   5-15회 반복          │
              └────────────────────────┘

세 가지 에이전트

1. 기획자 에이전트 (Planner Agent)

역할: 제품 관리자 — 짧은 프롬프트를 전체 제품 사양으로 확장합니다.

주요 동작:

• 한 줄 프롬프트를 받아 16개 기능, 멀티 스프린트 사양을 생성합니다.
• 사용자 스토리, 기술 요구 사항 및 시각적 디자인 방향을 정의합니다.
• 의도적으로 야심차게 계획합니다 — 보수적인 계획은 미흡한 결과로 이어집니다.
• 나중에 평가자가 사용할 평가 기준을 생성합니다.

모델: Opus 4.6 (사양 확장을 위한 깊은 추론 필요)

2. 생성자 에이전트 (Generator Agent)

역할: 개발자 — 사양에 따라 기능을 구현합니다.

주요 동작:

• 구조화된 스프린트(또는 최신 모델의 경우 연속 모드)로 작업합니다.
• 코드를 작성하기 전에 평가자와 "스프린트 계약"을 협상합니다.
• 풀스택 도구(React, FastAPI/Express, 데이터베이스, CSS)를 사용합니다.
• 반복 작업 간의 버전 관리를 위해 git을 관리합니다.
• 평가자 피드백을 읽고 다음 반복에 반영합니다.

모델: Opus 4.6 (강력한 코딩 능력 필요)

3. 평가자 에이전트 (Evaluator Agent)

역할: QA 엔지니어 — 코드뿐만 아니라 실행 중인 실시간 애플리케이션을 테스트합니다.

주요 동작:

• Playwright MCP를 사용하여 실시간 애플리케이션과 상호 작용합니다.
• 기능을 클릭하고, 양식을 채우고, API 엔드포인트를 테스트합니다.
• 네 가지 기준(구성 가능)에 따라 점수를 매깁니다:
  1. 디자인 품질 — 전체적으로 일관성이 느껴지는가?
  2. 독창성 — 템플릿/AI 패턴 대비 맞춤형 결정이 있는가?
  3. 완성도(Craft) — 타이포그래피, 간격, 애니메이션, 마이크로 인터랙션?
  4. 기능성 — 모든 기능이 실제로 작동하는가?
• 점수와 구체적인 문제가 포함된 구조화된 피드백을 반환합니다.
• 무자비하게 엄격하도록 설계되었습니다 — 결코 평범한 작업을 칭찬하지 않습니다.

모델: Opus 4.6 (강력한 판단력 + 도구 사용 필요)

평가 기준

기본 네 가지 기준, 각 1-10점:

## 평가 루브릭

### 디자인 품질 (가중치: 0.3)
- 1-3: 일반적이고 템플릿 같으며 "AI 조잡함" 미학
- 4-6: 유능하지만 평범함, 관습을 따름
- 7-8: 독특하고 응집력 있는 시각적 정체성
- 9-10: 전문 디자이너의 작업으로 간주될 수 있음

### 독창성 (가중치: 0.2)
- 1-3: 기본 색상, 스톡 레이아웃, 개성 없음
- 4-6: 일부 맞춤형 선택, 대부분 표준 패턴
- 7-8: 명확한 창의적 비전, 독특한 접근 방식
- 9-10: 놀랍고 즐거우며 진정으로 참신함

### 완성도 (가중치: 0.3)
- 1-3: 깨진 레이아웃, 누락된 상태, 애니메이션 없음
- 4-6: 작동하지만 거친 느낌, 일관성 없는 간격
- 7-8: 세련되고 부드러운 전환, 반응형
- 9-10: 픽셀 단위로 완벽하며 즐거운 마이크로 인터랙션

### 기능성 (가중치: 0.2)
- 1-3: 핵심 기능이 깨졌거나 누락됨
- 4-6: 기본 경로는 작동하지만 예외 사례는 실패함
- 7-8: 모든 기능 작동, 우수한 오류 처리
- 9-10: 견고하며 모든 예외 사례를 처리함

채점

• 가중 점수 = 각 (기준 점수 * 가중치)의 합
• 합격 임계값 = 7.0 (구성 가능)
• 최대 반복 횟수 = 15회 (구성 가능, 일반적으로 5-15회면 충분)

사용법

명령어를 통한 사용

# 전체 3단계 에이전트 하네스
/project:gan-build "Kanban 보드, 팀 협업 및 다크 모드가 포함된 프로젝트 관리 앱 구축"

# 사용자 정의 구성 사용
/project:gan-build "레시피 공유 플랫폼 구축" --max-iterations 10 --pass-threshold 7.5

# 프론트엔드 디자인 모드 (생성자 + 평가자만, 기획자 제외)
/project:gan-design "암호화폐 포트폴리오 추적기를 위한 랜딩 페이지 생성"

쉘 스크립트를 통한 사용

# 기본 사용법
./scripts/gan-harness.sh "음악 스트리밍 대시보드 구축"

# 옵션 포함
GAN_MAX_ITERATIONS=10 \
GAN_PASS_THRESHOLD=7.5 \
GAN_EVAL_CRITERIA="functionality,performance,security" \
./scripts/gan-harness.sh "작업 관리를 위한 REST API 구축"

Claude Code를 통한 사용 (수동)

# 1단계: 계획
claude -p --model opus "당신은 제품 기획자입니다. PLANNER_PROMPT.md를 읽으십시오. 'Kanban 보드 앱 구축'이라는 짧은 내용을 전체 제품 사양으로 확장하고 spec.md에 작성하십시오."

# 2단계: 생성 (반복 1)
claude -p --model opus "당신은 생성자입니다. spec.md를 읽고 Sprint 1을 구현하십시오. 3000번 포트에서 개발 서버를 시작하십시오."

# 3단계: 평가 (반복 1)
claude -p --model opus --allowedTools "Read,Bash,mcp__playwright__*" "당신은 평가자입니다. EVALUATOR_PROMPT.md를 읽으십시오. http://localhost:3000에서 실행 중인 앱을 테스트하고 루브릭에 따라 점수를 매기십시오. feedback-001.md에 피드백을 작성하십시오."

# 4단계: 생성 (반복 2 — 피드백 반영)
claude -p --model opus "당신은 생성자입니다. spec.md와 feedback-001.md를 읽으십시오. 모든 문제를 해결하고 점수를 높이십시오."

# 합격 임계값에 도달할 때까지 3-4단계를 반복합니다.

모델 기능에 따른 진화

모델이 개선됨에 따라 하네스는 단순화되어야 합니다. Anthropic의 진화를 따릅니다:

1단계 — 약한 모델 (Sonnet급)

• 전체 스프린트 분해 필요
• 스프린트 간 컨텍스트 초기화 (컨텍스트 불안 방지)
• 최소 2개 에이전트: 초기화자 + 코딩 에이전트
• 모델의 한계를 보완하기 위한 과도한 스캐폴딩

2단계 — 유능한 모델 (Opus 4.5급)

• 전체 3단계 에이전트 하네스: 기획자 + 생성자 + 평가자
• 각 구현 단계 전 스프린트 계약
• 복잡한 앱을 위한 10단계 스프린트 분해
• 컨텍스트 초기화는 여전히 유용하지만 덜 중요함

3단계 — 프런티어 모델 (초기 Opus 5급 이상)

• 평가자가 보조가 아닌 핵심이 됨
• 자율적인 "지속적 생성" 모드
• 에이전트가 자체적으로 하네스 인프라를 구축함
• 인간은 사양 수준에서만 개입함