Gauntlet Loop
사용자의 초기 지침이나 목표를 Gauntlet Loop로 변환합니다. 이는 Matt Shumer의 Claude of Duty 기법, robonuggets/gauntlet-loop, duolahypercho/gauntlet-loop, 그리고 AI Loop Engineering Three-Elements Framework를 기반으로 한 자율적인 빌더-대-비평가 피드백 루프입니다.
대부분의 에이전트 출력물은 빌더가 모호한 단어를 기준으로 자신의 과제를 평가하기 때문에 'AI에게 충분히 괜찮은' 수준에서 멈춥니다. Gauntlet Loop는 일회성 프롬프트를 세 가지 핵심 요소로 구축된 지속적인 사이클로 대체합니다:
- Objective (목표): 반드시 충족되어야 하는 구체적인 결과물과 결과 상태.
- Reference or Metric (참조 또는 메트릭, 기준 & 엄격한 비평가): 명명되고, 가져올 수 있으며(fetchable), 나란히 비교 가능한 벤치마크와, 해당되는 경우 객관적인 테스트나 메트릭을 짝지은 것입니다. 이는 별도의 비평가가 새로운 컨텍스트로 맹목적으로 판단합니다.
- Boundary (경계): 루프가 중단되거나 에스컬레이션되는 시점을 제어하는 명시적인 성공 기준, 라운드/정체 상한, 전략 전환 규칙, 안전/허가 게이트.
1단계: 시드 지침 및 컨텍스트 식별
- 사용자가
/gauntlet-loop <지침>과 함께 인라인으로 지침을 전달한 경우 이를 시드로 사용합니다. - 사용자가 진행 중인 대화 중에 인수 없이
/gauntlet-loop를 호출한 경우, 현재 논의 중인 작업, 계획 또는 프롬프트를 사용합니다. - 메시지나 대화 기록에 명확한 작업이 없는 경우, 진행하기 전에 사용자가 무엇을 만들거나 달성하려는지 물어봅니다.
- 작업이 로컬 코드베이스나 작업 공간과 관련된 경우, 디렉토리 구조, 기술 스택, 테스트 러너 또는 빌드 스크립트를 빠르게 검사하여 제안된 기본값이 실제 프로젝트 도구와 명령어를 참조하도록 합니다.
2단계: 세 가지 루프 요소 명확히 하기 (기본값 제안)
사용자의 요청을 아래 세 가지 핵심 요소에 대해 검토하세요. 요소가 누락되었거나, 불충분하게 지정되었거나, 모호한 품질 기준을 사용하는 경우, 사용자에게 구체적이고 의견이 담긴 기본값을 제안하면서 세 가지 요소를 확인하거나 조정하도록 요청하세요.
Fast-path 규칙: 사용자가 이미 명확한 Objective, 특정하고 가져올 수 있는 Reference/Metric, 명확한 Boundary를 제공했거나, "기본값 사용" 또는 "그냥 프롬프트 작성해줘" 라고 명시적으로 말한 경우, 질문을 건너뛰고 최상의 기본값을 사용하여 3단계로 직접 진행합니다.
1. Objective (어떤 구체적인 결과가 반드시 실현되어야 하는가?)
- 모호한 의도 ("사이트를 더 좋게 만들어", "좋은 CLI를 작성해")를 관찰 가능한 결과 상태와 결과물 ("처음 방문자가 모든 플랜을 비교하고 모바일에서 체크아웃을 완료할 수 있는 Next.js + Tailwind로 반응형 SaaS 가격 페이지 구축")로 대체합니다.
- 제안된 기본값: 사용자가 승인하거나 조정할 수 있도록 명확해진 1-2문장의 Objective (감지되거나 권장된 기술 스택/형식 포함) 초안을 작성합니다.
2. Reference or Metric (품질 기준 & 외부 심사자)
Gauntlet Loop의 모든 것은 품질 기준에 달려 있습니다. 유효한 참조 기준은 세 가지 테스트를 통과해야 합니다:
- 명명됨 (Named): 형용사나 범주가 아닌 구체적인 실제 아티팩트. ("Stripe의 실제 가격 페이지" 또는 "Hades 전투 스크린샷" 은 통과하지만, "수상 경력에 빛나는 SaaS 디자인" 또는 "AAA 품질" 만으로는 실패.)
- 가져올 수 있음 / 검사 가능함 (Fetchable / Inspectable): 비평가가 실행 중에 실제로 이를 얻어 검사할 수 있습니다. (라이브 URL 스크린샷, 게시된 기사 읽기, 바이너리 실행, 또는 저장소 검사). 에이전트가 참조를 가져올 수 없으면 비교를 환각(hallucinate)하여 평범한 작업을 승인할 것입니다.
- 비교 가능함 (Comparable): 실제 출력물과 참조 모두 레이블을 제거한 상태로 나란히 놓일 수 있어야 하며, 새로운 비평가가 이진 블라인드 A/B 선택 ("어느 것이 더 나은가?")을 하고 가장 큰 단일 격차를 명명할 수 있어야 합니다. 매 라운드마다 위로 상승하는 1-10점 숫자 점수를 절대 사용하지 마십시오.
취향 + 숫자가 취향 단독보다 낫습니다: 목표에 측정 가능한 차원 (단위/통합 테스트 스위트, p95 지연 시간, Lighthouse/접근성 점수, 360px에서 수평 오버플로우 없음, 벤치마크 처리량, 단어 수, 또는 출처 인용 추적)이 있을 때마다 정성적 참조 기준을 하드한 객관적 검증자와 짝지으세요.
| 목표 유형 | 작동하는 참조 기준 + 메트릭 |
|---|---|
| 웹사이트, 앱, UI | 특정 최고 제품의 라이브 URL (linear.app, stripe.com/pricing, vercel.com), 데스크톱 및 모바일 뷰포트에서 스크린샷 + 콘솔/접근성/오버플로우 오류 제로 |
| 코드, CLI, 라이브러리 | 명명된 오픈소스 저장소 또는 도구의 구현 (ripgrep, jq, esbuild) + 자동화된 테스트 스위트, 속성 퍼저, 레이턴시/처리량 벤치마크 스크립트 |
| 게임, 3D, 인터랙티브 | 출시된 명명된 타이틀 (Call of Duty, Hades, Brotato)의 실제 게임플레이 스크린샷 또는 영상, 라이브 인게임 프레임과 비교 + 목표 FPS/플레이 가능 여부 확인 |
| 글쓰기, 문서, 설명 | 명명된 저자 또는 출판물 (예: Julia Evans, Stripe Engineering Blog, Gwern)의 2-3개 특정 게시된 글, 저자 표시를 제거하고 블라인드 비교 + 목표 길이/읽기 시간 확인 |
| 연구, 전략, 분석 | 명명된 애널리스트 보고서, 벤치마크 논문의 방법 섹션, 또는 포렌식 공매도 분석가 메모 + 원시 출처 데이터에 대한 모든 주장의 자동 조정 |
| 슬라이드 덱, 인도물 | 동일한 페이지/슬라이드 수의 벤치마크 회사의 특정 공개 덱 또는 메모 + 내러티브 명확성 확인 |
- 제안된 기본값: 2~3개의 구체적이고 명명된, 가져올 수 있는 후보 기준 (가장 도전적이지만 실제로 도달 가능한 것을
(Recommended)로 표시)과 구체적인 객관적 메트릭/검증자를 함께 제공합니다.
3. Boundary (중단 조건, 예산 및 안전 게이트)
"완전히 완벽해질 때까지 반복"은 비평가에게 동기를 부여하지만, 도달할 수 없는 기준에 대한 무한 루프는 영원히 돌거나, 토큰을 소진하거나, 안전하지 않은 변경을 초래할 수 있습니다. 세 가지 하위 축에 걸쳐 명시적인 경계를 정의합니다:
- 성공 및 수렴 중단: 모든 구성 요소가 객관적 검증자를 통과하고 참조와의 블라인드 비교에서 승리할 때 (또는 인간이 지정한 '브레이크'가 실행을 중단할 때) 종료합니다.
- 반복 및 정체 상한: 구성 요소당 라운드 상한 (기본값: 조각당 최대 5라운드 또는 의미 있는 개선 없이 연속 2라운드 후 중단). 정확히 동일한 격차가 두 번 연속 실패하면 빌더가 전략을 변경하도록 요구합니다.
- 권한 및 안전 게이트: 로컬 읽기, 초안 작성, 편집, 빌드, 렌더링 및 테스트를 허용합니다. 명시적인 인간 승인 없이 취소할 수 없거나 외부적인 조치 (프로덕션 배포, 파괴적 삭제, 유료 API 사용, 자격 증명/비밀 변경, 또는 외부 메시지 전송)를 금지합니다.
사용자에게 질문하는 방법
설명이 필요한 경우, 해결되지 않은 요소만 다루는 간결하고 훑어보기 쉬운 프롬프트 (또는 가능한 경우 하네스의 구조화된 ask_question 도구 사용)를 제시하고, 사용자가 단축어 (예: "1, 기본값 사용")로 답변할 수 있도록 기본값을 미리 채워 넣습니다:
- Objective: 제안된 명확해진 Objective + 스택을 진술하고 변경할 사항이 있는지 묻습니다.
- Reference & Metric: 2-3개의 명명되고 가져올 수 있는 후보 기준 (
A,B,C,A (Recommended)포함)과 제안된 객관적 검증자/테스트를 나열합니다. - Boundary: 기본 중단 조건 (예: 블라인드 A/B 승리 + 검사 통과, 조각당 최대 5라운드, 동일한 실패 2회 후 전략 전환, 로컬 전용 편집) 또는 "인간-브레이크 (내가 중단할 때까지 계속 반복)" 를 제안하고 선호하는 모드를 묻습니다.
3단계: 변환된 Gauntlet Loop 출력
Objective, Reference/Metric, Boundary가 선택 (또는 기본값 사용)되면, 결과를 세 부분으로 제시합니다:
1. Gauntlet Loop 설계 카드
루프 아키텍처를 고정하는 간결한 요약 테이블을 출력합니다:
- Objective: 반드시 실현되어야 하는 정확한 결과와 결과물.
- Reference Bar (Taste): 명명되고 가져올 수 있는 아티팩트와 빌드 전에 어떻게 가져와서 검사할지.
- Objective Metric (Number): 비평가 검토 전에 필요한 자동화된 테스트, 벤치마크, 레이아웃 검사 또는 사실 확인.
- Decomposition Rule: 작업을 독립적으로 판단 가능한 작은 조각으로 나누는 방법 (진정으로 독립적인 부분만 병렬화하고, 긴밀하게 결합된 시스템은 일관된 순차적 소유권 아래 유지).
- Critic Protocol: 새로운 컨텍스트를 가진 별도의 하위 에이전트; 실제 렌더링/실행된 아티팩트 (빌더의 요약이 아님)를 검사합니다; 레이블이 제거된 상태로 블라인드 A/B 비교를 실행하고, 이진 선택을 하며 가장 큰 단일 격차를 명명합니다.
- State & Progress: 루프 메모리를 유지하는 데 사용되는 파일 (
GAUNTLET_PROGRESS.md또는 라이브 진행 페이지)로 완료된 부분, 증거, 실패한 접근 방식 및 남아있는 격차를 기록하여 컨텍스트가 썩지 않도록 합니다. - Boundary: 활성 중단 규칙, 라운드 상한 및 안전 게이트.
2. Gauntlet Loop 프롬프트
펜스 처리된 markdown 블록 내에 자체 포함된 복사-붙여넣기 준비 완료 프롬프트를 출력합니다. 아래 범용 Gauntlet Loop 프롬프트 (사용자의 작업, 도구 및 스택에 맞게 조정됨)를 제공하고, 사용자가 초소형 3문단 Matt Shumer 스타일 또는 하네스별 루프 명령어를 원하는 경우 그에 따라 마무리 부분을 조정합니다 (참조/예제.md 참조).
[STACK / FORMAT]으로 [DELIVERABLE / OBJECTIVE] 구축하기.
## 1. 품질 기준 & 메트릭 (먼저 가져오기)
품질 기준은 [NAMED, FETCHABLE REFERENCE]입니다. 구축하거나 판단하기 전에 실제 참조를 직접 가져와서 검사하십시오 ([가져오는 방법: 데스크톱 및 모바일에서 라이브 URL 스크린샷 / 게시된 텍스트 가져오기 / 참조 구현체를 클론하거나 실행])—절대 메모리나 설명과 비교하지 마십시오.
모든 조각은 다음 객관적 검사도 통과해야 합니다: [OBJECTIVE METRICS / TESTS / BENCHMARKS].
## 2. 분해 및 소유권
작업을 자체적으로 구축, 검증 및 판단할 수 있는 가장 작은 조각으로 나누십시오: [INITIAL CANDIDATE PIECES].
- 진정으로 독립적인 조각에만 병렬 빌더 하위 에이전트를 사용하십시오.
- 긴밀하게 결합된 시스템은 구성 요소가 충돌하지 않도록 순차적이고 일관된 소유권 아래 유지하십시오.
## 3. 빌더 대 엄격한 비평가 루프
각 조각에 대해 빌더와 별도의 새로운 컨텍스트를 가진 비평가 하위 에이전트 (빌더의 사고 과정이나 변명에 접근 불가)를 실행하십시오:
1. **구축 및 검증**: 빌더가 조각을 생성하거나 수정하고 객관적 검사 ([TESTS / LINT / BENCHMARK / RENDER])를 실행합니다.
2. **실제 아티팩트 검사**: 비평가가 실제 출력물 ([SCREENSHOTS / RUNNING BINARY / TEST LOGS / DRAFT TEXT])을 열고 검사합니다—절대 빌더의 요약이 아닙니다.
3. **블라인드 A/B 선택**: 비평가가 우리의 아티팩트를 [NAMED REFERENCE] 옆에 레이블을 제거하고 블라인드로 놓고, 어느 것이 더 나은지 이진 선택을 하고, 우리가 지면 **가장 큰 단일 격차**를 구체적인 증거와 함께 식별하여 빌더에게 다시 보냅니다.
4. **부드러운 채점 금지**: 비평가는 가차없이 엄격해야 합니다. 칭찬과 1-10점 숫자 점수는 금지됩니다. 우리가 블라인드 비교에서 이기지 못하고 모든 객관적 검사를 통과하지 못하면 계속 반복합니다.
## 4. 상태 추적 및 전략 변경
각 라운드 후에 다음을 기록하는 간결한 `GAUNTLET_PROGRESS.md` (및/또는 라이브 진행 상황 보기)를 유지하십시오: 현재 조각, 라운드 번호, 비평가 평결, 대상이 된 단일 격차, 실패한 접근 방식, 객관적 검사 결과. 동일한 격차가 두 번 연속 실패하면 현재 접근 방식을 포기하고 구조적으로 다른 전략을 시도하십시오.
## 5. 최종 통합 패스 및 경계
- **통합 비평가**: 개별 조각이 승리하면, 하나의 새로운 통합 비평가를 생성하여 완전히 조립된 최종 아티팩트를 처음부터 끝까지 일관성, 이음새, 성능 및 원래 목표와의 적합성에 대해 검사합니다.
- **경계**: [중단 조건: 예: 모든 조각 + 통합이 블라인드 A/B에서 승리하고 모든 객관적 검사를 통과할 때까지, 또는 조각당 N 라운드 / 측정 가능한 이득 없이 연속 2라운드 후 중단]. 허용된 작업: [ALLOWED LOCAL ACTIONS]. 명시적인 인간 승인 없이 [금지된 작업: 프로덕션 배포, 데이터 삭제, 비용 지출 또는 자격 증명 건드리기]를 수행하지 마십시오.
[하네스 루프 꼬리: 각 조각이 승리할 때까지 빌더와 비평가를 하위 에이전트로 실행하면서 계속 반복하십시오. / 또는 Claude Code의 경우: 각 조각이 승리할 때까지 `/loop`; 하위 에이전트와 `ultracode`를 펼치십시오. / 또는 Codex의 경우: 모든 조각이 승리할 때까지 `/goal`.]
3. 실행 제안
다음과 같이 질문하며 마무리합니다:
"지금 이 Gauntlet Loop를 주 오케스트레이터로서 실행해 드릴까요? 세 가지 요소 (Objective, Reference/Metric, Boundary) 중 하나를 수정하시겠습니까? 아니면 프롬프트 스타일 (범용 Bounded 대 Claude
/loop또는 Codex/goal용 클래식 150단어 Aim 프롬프트)을 변경하시겠습니까?"
사용자가 실행을 요청하면, 즉시 생성된 프롬프트를 활성 운영 지침으로 채택합니다: 먼저 참조를 가져오고, GAUNTLET_PROGRESS.md를 초기화하고, 조각을 분해한 다음, 1라운드를 시작합니다.
Gauntlet Loop를 망가뜨리는 것 (가드레일)
생성된 Gauntlet 프롬프트에 다음 실패 모드를 절대 허용하지 마십시오:
- 모호하거나 가져올 수 없는 기준: "세계적 수준으로 만들어" 또는 유료/접근 불가 아티팩트를 명명하면 비평가가 비교를 환각하고 모든 것을 도장 찍도록 강제합니다.
- 빌더가 자신의 작업을 판단하는 것: 빌더는 자신이 만든 모든 타협을 기억하고 합리화합니다. 비평가는 새로운 컨텍스트를 가진 하위 에이전트 (또는 빌더의 정당화가 제거된 깨끗한 검증 패스)여야 합니다.
- 이진 선택 대신 1-10점 숫자 점수: 10점 만점의 점수는 라운드가 진행됨에 따라 자동으로 7/10에서 9/10으로 상승합니다. 이진 블라인드 A/B 선택 ("어느 것이 이겼나?") 과 가장 큰 단일 격차를 요구하십시오.
- 비평가가 아티팩트 대신 요약을 읽는 것: 화려한 마크다운 상태 보고서는 증거가 아닙니다. 비평가는 렌더링된 픽셀, 바이너리/테스트 실행 결과, 또는 실제 텍스트를 검사해야 합니다.
- 긴밀하게 결합된 코드의 병렬화: 동일한 상태 루프 또는 공유 렌더링 파이프라인에 대해 10개의 하위 에이전트를 펼치면 병합 충돌과 시각적 이음새가 발생합니다. 독립적인 부분만 펼치고 긴밀하게 결합된 시스템에 대해 단일 책임을 적용하십시오.