v5.5.0: Ask-First 요구사항 정렬 — 에이전트가 원치 않는 것을 더 이상 만들지 않습니다¶
빠른 답변: 에이전트는 자율 실행이 가능했지만 때때로 사용자가 실제로 원하는 것과 반대되는 것을 전달했습니다. 근본 원인: 요구사항 명확화는 사용자가 우연히 "인수 기준", "요구사항 불명확" 같은 키워드를 말했을 때만 발동했고, "랜딩 페이지 최적화" 같은 모호한 요청은 명확화를 건너뛰고 곧바로 계획 수립으로 들어가 모델이 목표를 추측했습니다. v5.5.0은 워크플로 수준에서 이를 수정합니다. 모호한 변경 요청은 계획 전에 자동으로 요구사항 명확화로 들어가고, 에이전트는 "조사 → 추론 → 가정 → 질문" 우선순위 체인(질문은 마지막 수단)을 따르며, 모든 질문에는 기본 답변이 붙고, 명확화 예산(3라운드) + 가정 폴백으로 대화에 하드한 출구를 만들어 무한 루프를 구조적으로 방지합니다.
실패 패턴: 유능한 에이전트, 어긋난 결과물¶
워크플로는 실행할 수 있었습니다. 테스트도, diff도, 리뷰도 이루어졌습니다. 그런데 반복해서 발생한 것은 돌아온 결과물이 사용자가 원하는 것이 아니었다는 점입니다.
- 요청 도착: "优化一下前端页面" / "Improve the landing page."
- requirements 역량은 메시지에 명시적 키워드(
acceptance criteria,需求不清,clarify the requirements…)가 있을 때만 발동. - 키워드 없음 → 명확화 없음 → 모델은 계획 수립에 들어가 목표를 스스로 가정.
- 모델은 가정을 완벽하게 실행 — 그래서 잘못된 것이 "확실하게" 만들어집니다.
이것은 전형적인 요구사항 검증 결여입니다. 소프트웨어 공학 규범은 설계·구현 전에 "올바른 것을 만들고 있는가(Are we building the right thing?)"를 검증하라고 합니다. 우리의 증거 기반 역량 체인은 후자만 보장했습니다.
v5.5.0의 변경 사항¶
1. 모호한 요청의 구조적 감지 (키워드 불필요)¶
derive-facts는 이제 문구가 아니라 구조로 "요구사항 누락"을 판정합니다:
- 일반적 최적화 목표("优化", "improve", "优化一下前端页面")
- 그리고 관찰 가능한 인수/결과 서술이 없음("要求首屏加载时间降低到 2 秒以内")
- 그리고 특정 기능 엔티티가 없음("支付模块", "login", "checkout")
→ 자동으로 acceptance-criteria-missing 생성 → 계획 전에 rex-requirements(Grilling 모드)로 라우팅.
오탐 방지 내장: 완료 시제 문장("我们把上次讨论的优化方案提交了")과 명사구("optimization plan")는 명확화를 발동하지 않습니다.
2. Ask-First 우선순위 체인 — 질문하기 전에 생각¶
- 조사 — 환경에서 확인(파일, 코드, 기존 requirements decision)
- 추론 — 맥락에서 유추(이전 결정, 저장소 제약, 도메인 관례)
- 가정 — 합리적 기본값 채택 후 "이것은 가정입니다"라고 명시
- 질문 — 위 세 가지가 모두 실패하고, 그 질문이 구현·인수 방식을 바꿀 때만
모든 질문에 가설 + 기본값 첨부: "목표가 페이지 전환율 개선이라고 이해했습니다. 아니라면 A인가요 B인가요? (답이 없으면 A로 진행하겠습니다)". 답이 없으면 기본값으로 진행 — 답변 부재로 멈추지 않음.
3. 명확화 예산 — 무한 루프 방지의 하드 보장¶
요구사항 증거 계약에 anyOf 수렴 그룹 추가:
{
"expectedEvidence": [
{ "anyOf": ["acceptance-criteria-recorded", "assumptions-recorded"] },
{ "anyOf": ["non-goals-recorded", "assumptions-recorded"] },
"first-slice-identified",
"requirements-decision-recorded"
]
}
- 인수 기준 또는 가정 기록으로 그룹 충족.
- 3라운드 미수렴 → 질문 중단, 미결 항목을 가정 목록(
assumptions-recorded)으로 기록 후 구현 잠금 해제. - 가정 목록은 결과물과 함께 전달되어, 사용자는 인수 시점에 무엇이 가정되었는지 한눈에 확인.
요구사항당 한 번만 명확화하고, 타입화된 requirements-decision 아티팩트가 정렬을 기록 — 같은 요구사항의 재요청에서 재발동하지 않습니다.
이전 흐름 vs 새 흐름¶
이전: "优化一下前端页面" → 계획 → "스타일 리팩터 + 성능 + 다크 모드" → 전달 → "나는 전환율이 필요했는데."
현재: "优化一下前端页面" → 자가 점검: 목표 모호(무엇을? 누구를 위해? 성공 기준은?) → 기본값 있는 질문: "이 페이지의 전환율 개선이 목표라고 이해했습니다. 아니라면 A인가요 B인가요?" → 확인 → requirements-decision 기록 → 개발 잠금 해제 → 전달되는 것은 사용자가 요청한 것.
검증¶
- rex-harness 200개 테스트 통과(199/200. 유일한 실패는 macOS
/private경로 환경 베이스라인으로 이 변경과 무관). - 메인 저장소 워크플로 테스트 103/103 전부 통과. 신규 케이스 포함: 모호한 중국어 요청→명확화, 모호한 영어 요청→명확화, 인수 서술 있음→명확화 없음, 특정 기능 대상→명확화 없음, 명확화 완료→재발동 없음, 가정 수렴→단계 완료.
- 수렴 계약 테스트 추가: 완전 인수 증거(호환 경로), 가정 폴백(루프 출구), 그룹 누락 시 blocked(계약 완화 없음).
rex-harness doctor가ready보고.
업그레이드 메모¶
- 이는 동작 변경입니다. 요청이 구조적으로 모호하면 워크플로가 멈추고 질문합니다. 그 멈춤이 바로 기능입니다.
- 기존 타입화된 requirements decision(
requirements-decision-recorded)은 존중되며 재명확화를 억제. - UI 작업에는 방향 확인 단계 추가: 구현 전에 1-2개의 스타일/레이아웃 방향 제시.
의도적으로 모호한 요청으로 시도해 보세요. 손을 움직이기 전에 정렬하는 워크플로를 확인할 수 있습니다.