공식 참고 자료: Best Practices · Subagents · Review
왜 Ralph 루프가 필요한가
빠른 출력은 완료와 다릅니다. Ralph형 지속 루프는 다음 두 가지 실패를 막기 위해 존재합니다.
- 부분 구현을 완료로 보고하는 실수
- 새 수정 이후에도 오래된 검증 로그를 재사용하는 실수
Ralph는 "요구사항 충족 + 신선한 증거 + 리뷰 승인"이 모일 때까지 계속 진행하도록 강제합니다.
50회 루프 설계 원칙 (무한 루프 금지)
긴 루프일수록 종료 조건이 더 명확해야 합니다.
50회 턴 실행 전, 아래 제어점을 먼저 정의하세요.
- 작업 경계: 무엇을 업데이트하고 무엇은 범위 밖인지
- 증거 경계: 어떤 커맨드가 완료를 증명하는지
- 재시도 정책: 복구 가능한 실패와 하드 블로커 기준
- 종료 계약:
완료,실패,취소판정 조건
"계속하기"보다 "멈추는 조건"이 명확할수록 지속 실행은 안전해집니다.
루프 필수 단계
1) 실행 전 컨텍스트 스냅샷
구현 전에 .omx/context/에 스냅샷을 남깁니다.
최소 항목:
- 작업 진술
- 기대 결과
- 확인된 사실/증거
- 제약 조건
- 미확정 사항
- 예상 영향 지점
모든 레인이 같은 사실 기반에서 시작하게 만드는 장치입니다.
2) 실행 단계: 오너십 분리
독립 작업은 병렬로 실행하되, 책임을 분리합니다.
- 구현 레인: 콘텐츠/코드 수정
- 증거 레인: 검증 커맨드 실행 및 로그 수집
- 승인 레인: 아키텍트 관점의 승인/반려 판단
병렬성은 "누가 무엇을 검증하는지"가 분리될 때 효과가 납니다.
3) 검증 단계: 신선한 증거 확보
오래된 로그를 재사용하지 마세요. 마지막 의미 있는 수정 이후 lint/test/build 같은 증명 커맨드를 재실행하고, 현재 출력만 근거로 사용합니다.
4) 수정-완료 게이트
- 리뷰어 반려 시: 결함 목록을 기준으로 수정 단계로 복귀
- 리뷰어 승인 + 모든 체크 통과 시: 완료 처리 및 상태 정리
확장 가능한 위임 패턴
중간/고난도 작업은 레인을 고정하세요.
- Executor 레인: 산출물 생성/갱신
- Verifier 레인: 체크 실행 및 결과 해석
- Architect 레인: 가정 반박 후 승인/반려
"수정했다"와 "증명했다"를 분리하면 품질이 안정됩니다.
자주 실패하는 패턴
"잘 된 것 같아서" 완료 선언
확신형 문장은 증거가 아닙니다. 완료 주장은 반드시 커맨드 출력과 묶어야 합니다.
하나의 레인이 전부 담당
같은 레인이 수정/검증/승인을 모두 하면 독립 검증이 없습니다.
진단 없이 무한 재시도
같은 결함이 3회 이상 반복되면 블라인드 재시도 대신 원인 재정의를 먼저 하세요.
Ralph 실행 체크리스트
시작 전:
- 컨텍스트 스냅샷 저장
- 반복 상한과 종료 조건 정의
- 검증 커맨드 목록 확정
완료 전:
- 미해결 항목 0개
- 신선한 검증 출력 확보
- 아키텍트 리뷰 판정 기록
- 모드 상태 완료 처리 및 정리 수행
Ralph의 핵심은 턴 수가 아닙니다. 각 턴이 검증 가능한 책임 단위가 되도록 만드는 것이 핵심입니다.