검증 루프 설계
Anthropic과 gstack 사례를 바탕으로 planner, builder, evaluator, QA를 언제 분리해야 하는지 설명합니다.
핵심 요약
- 하네스 성능 차이는 문서 구조만큼이나 검증 루프에서 크게 벌어집니다. builder 하나가 계획·구현·자기평가·QA를 다 맡으면 스코프를 너무 작게 잡고 자기평가도 편향됩니다.
- 루프는 Builder only, Planner+Builder, Planner+Builder+Evaluator+QA로 나뉘며 작업의 영향 범위·배포 위험에 맞춰 선택합니다.
- planner/evaluator는 항상 쓰는 것이 아니라 "builder가 혼자서 자주 놓치는 실패"가 있는 구간에서만 load-bearing입니다.
- browser QA는 텍스트 self-check가 못 잡는 실제 인터랙션·화면 깨짐·엣지 상태를 드러내기 때문에 UI 제품에서 자주 load-bearing이 됩니다.
- handoff 전에 goal·non_goals·constraints·validation·escalation을 담은 sprint contract가 있어야 evaluator가 무엇을 검증할지 분명해집니다.
하네스의 성능 차이는 문서 구조뿐 아니라 검증 루프에서 크게 벌어집니다. Anthropic과 gstack이 특히 분명하게 보여주는 영역도 여기입니다.
왜 builder-only 루프는 쉽게 무너지는가
에이전트 하나가 계획, 구현, 자기평가, QA를 모두 맡으면 속도는 빠르지만 다음과 같은 문제가 자주 생깁니다.
- 스코프를 과소추정함
- 요구사항을 너무 빨리 충족했다고 판단함
- 브라우저나 실제 동작을 충분히 검증하지 않음
- 리뷰어가 발견해야 할 실패를 스스로 놓침
Anthropic 글은 이런 문제를 "어떤 scaffolding이 load-bearing인가"라는 질문으로 다룹니다.
기본 루프
루프 설계 옵션 비교
Anthropic에서 배울 것
Anthropic 글이 특히 유용한 이유는 "planner / evaluator를 항상 써라"라고 말하지 않고 언제 이들이 실제로 성능을 떠받치는지를 본다는 데 있습니다.
핵심 메시지:
- planner는 과소한 스코핑을 줄일 수 있다
- evaluator는 생성기와 다른 관점에서 실패를 찾는다
- 모델이 좋아질수록 일부 scaffolding은 줄일 수 있다
- 하지만 줄일 수 있는지는 감이 아니라 실험으로 판단해야 한다
핵심 해석
planner와 evaluator가 있느냐 없느냐가 중요한 게 아닙니다. "builder가 혼자서는 자주 놓치는 실패"가 있는 구간에서 이들이 load-bearing인지가 중요합니다.
gstack에서 배울 것
gstack은 이 루프를 더 실전적인 sprint 흐름으로 보여줍니다.
| 단계 | 의미 |
|---|---|
| Think | 문제 정의와 가설 |
| Plan | 구현 범위와 접근 결정 |
| Build | 실제 구현 |
| Review | 코드/설계/보안 점검 |
| Test | 브라우저와 테스트 검증 |
| Ship | 릴리즈와 문서 반영 |
| Reflect | 배운 점과 개선점 축적 |
여기서 중요한 것은 "역할 이름"이 아니라 테스트와 배포 직전의 검증을 별도 단계로 존중한다는 점입니다.
어떤 루프를 어디에 써야 하는가
| 작업 유형 | 권장 루프 | 이유 |
|---|---|---|
| 텍스트 초안, 메모, 내부 조사 | Builder only | 실패 비용이 낮음 |
| 문서 정리, 리팩터링, 중간 크기 기능 | Planner + Builder + Reviewer | 스코프와 정합성 관리가 중요 |
| UI 변경, 사용자 노출 기능 | Planner + Builder + Reviewer + Browser QA | "보였다"와 "됐다"를 분리해야 함 |
| 배포, 마이그레이션, 권한/보안 변경 | Planner + Builder + Evaluator + HITL | 승인과 rollback 기준이 필수 |
sprint contract를 먼저 만든다
루프가 잘 작동하려면 handoff 전에 계약이 있어야 합니다.
task_contract:
goal: "무엇을 끝낼 것인가"
non_goals:
- "이번에 하지 않을 것"
constraints:
- "깨면 안 되는 규칙"
validation:
- "반드시 통과해야 할 검증"
escalation:
- "멈추고 사람에게 넘길 조건"이 계약이 없으면 reviewer나 evaluator도 무엇을 검증해야 할지 모호해집니다.
browser QA는 왜 자주 unlock이 되는가
텍스트 기반 self-check는 대개 "의도대로 구현했다"는 가정에서 멈춥니다. 반면 브라우저는 아래를 곧바로 드러냅니다.
- 실제 인터랙션이 되는지
- 화면이 깨지는지
- 로딩/에러/엣지 상태가 처리되는지
- 눈으로 보면 바로 이상한데 코드만 봐서는 놓치는 문제가 있는지
그래서 UI가 있는 제품에서 browser QA는 자주 load-bearing입니다.
evaluator를 추가할지 판단하는 질문
- builder가 같은 종류의 실패를 반복하는가
- release 직전에서만 발견되는 문제 비율이 높은가
- 브라우저/로그/테스트를 보지 않고도 자주 "완료"라고 판단하는가
- 리뷰어가 요구사항 누락을 자주 잡는가
- 사람 승인이 항상 마지막 안전장치 역할을 하는가
위 질문 중 2개 이상이 예라면 evaluator나 QA 분리를 검토할 만합니다.
결론
좋은 하네스는 복잡한 루프를 좋아하지 않습니다. 대신 실제로 품질을 떠받치는 검증 단계만 남기고 나머지는 줄이는 것을 목표로 삼습니다.