검증 루프 설계
Anthropic과 gstack 사례를 바탕으로 planner, builder, evaluator, QA를 언제 분리해야 하는지 설명합니다.
하네스의 성능 차이는 문서 구조뿐 아니라 검증 루프에서 크게 납니다. Anthropic과 gstack이 특히 강하게 보여주는 것도 이 영역입니다.
왜 builder-only 루프는 쉽게 무너지는가
에이전트 하나가 계획, 구현, 자기평가, QA를 모두 맡으면 속도는 빠를 수 있지만 다음과 같은 문제가 자주 생깁니다.
- 스코프를 과소추정함
- 요구사항을 너무 빨리 충족했다고 판단함
- 브라우저나 실제 동작을 충분히 검증하지 않음
- 리뷰어가 발견해야 할 실패를 스스로 놓침
Anthropic 글은 이런 문제를 "어떤 scaffolding이 load-bearing인가"라는 질문으로 다룹니다.
기본 루프
루프 설계 옵션 비교
장점:
- 가장 빠름
- 문서와 역할 분리 비용이 적음
단점:
- 자기평가 편향이 큼
- 고위험 작업에서 누락이 늘어남
추천 상황:
- 로컬 실험
- 일회성 스크립트
- 영향 범위가 매우 작은 작업
장점:
- 스코프 과소추정을 줄임
- 시작 전에 완료 정의를 고정하기 쉬움
단점:
- 여전히 품질 검증이 낙관적일 수 있음
추천 상황:
- 중간 크기 기능 개발
- 리팩터링
- 구조 변경 전 탐색 작업
장점:
- 요구사항 충족과 실제 동작 검증을 분리함
- 브라우저, 테스트, release gate까지 연결하기 좋음
단점:
- 비용과 지연이 늘어남
- 역할 간 계약이 불명확하면 오히려 느려짐
추천 상황:
- 사용자 노출 기능
- 큰 변경
- 배포 위험이 있는 작업
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 분리를 검토할 가치가 큽니다.
결론
좋은 하네스는 복잡한 루프를 사랑하지 않습니다. 대신 실제로 품질을 떠받치는 검증 단계만 남기고, 나머지는 줄이는 것을 목표로 합니다.