hanarang-rails/.plans/failure-audit.md

Failure Audit — hanarang-harness (구)

증거 기반 실패 분석. 추측 아님. 2026-04-10 실제 대화 로그에서 추출.

분석 대상

• 대상 시스템: hanarang/openclaw-harness (현재 private)
• 증거 1: 2026-04-10 새벽 아랑(Arang) 프로젝트 Sprint 001 디스코드 세션 로그
• 증거 2: ~/.openclaw/workspace/memory/ 의 *timed-out*, ESCALATED, 실패 기록
• 증거 3: hanarang-harness 커밋 히스토리 — 63c6d76 fix: thinking tier 되돌림 — xhigh는 무한 대기 유발 등 fix 커밋 패턴

실패 모드 정리

F1 — 하네스 Skill Bypass

증상

• 나랑이가 "worker 스폰해서 바로 시작한다" 라고 말하고 구현 진입
• hanarang-harness skill 의 구조화된 진입 경로(plan-sprint.lobster → implement-sprint.lobster)를 거치지 않음
• 자매 본인이 직접 처리 → 결과물의 품질이 skill 템플릿에 묶이지 않음

증거

나랑이: 프론트엔드+백엔드 풀세팅이니까 worker 스폰해서 바로 시작한다.
        worker 스폰한다. Sprint 001 전체 구현 들어간다.

근본 원인

• Skill 은 "권고"일 뿐 강제 메커니즘이 없음
• OpenClaw system prompt 에 "반드시 skill 을 거쳐야 한다" 는 강제문이 약하거나 없음
• skill 바이패스를 감지하는 post-hook 이 없음
• skill 진입 여부가 artifact 에 기록되지 않아 사후 검증 불가

영향

• 파이프라인 일관성 상실
• 결과물이 스프린트 템플릿과 어긋남
• 리뷰어(다랑이)가 체크할 기준이 없어짐

처방 → Sprint 002 (Skill Enforcement)

---

F2 — DoD 자동 강제 실패

증상

• 나랑이가 "build 검증 통과" 만 하고 "완료" 보고
• 실행 검증, E2E, DB 마이그레이션, env 확인 등 없이 "커밋 푸시할까?" 물어봄
• 하랑이가 수동으로 "build만 통과한 건 좋아. 근데 아직 완료 판정은 아니야" 라고 되돌림

증거

나랑이: Backend tsc + nest build 통과
        Frontend next build 통과
        Prisma generate 완료
        커밋 푸시할까? @하랑이

하랑이: 아니야, 아직은 안 돼.
        지금 상태는 build 검증까지야. 내가 준 Sprint 001 완료 기준은 실행 검증 포함이었어.

근본 원인

• 스프린트의 "완료 기준" 이 markdown 텍스트로만 존재 (기계가 검증 불가)
• Sprint Contract 객체가 없음 → validator 가 없음
• "완료" 판정이 자매의 주관에 맡겨짐

영향

• 매 스프린트마다 하랑이가 수동 감사
• 하랑이가 빠뜨리면 부실 완료가 통과됨
• 사용자가 "커밋 푸시는 기본이고 다랑이한테 QA" 라고 수동 개입해야 함

처방 → Sprint 003 (Sprint Contract + Zod validator)

---

F3 — QA 단계 자동 라우팅 누락

증상

• 나랑이가 build 완료 → 바로 푸시 시도
• QA(다랑이) 단계가 파이프라인에서 선택적으로 설계됨
• 사용자(나봄하랑)가 "다 완료됐으면 다랑이한테 보고해서 QA 피드백받고 다시 개발해" 라고 직접 명시해야 발동

증거

나봄하랑: 커밋 푸쉬는 기본이고, 다 완료됐으면 다랑이한테 보고해서 QA 피드백받고 다시 개발해

근본 원인

• review-sprint.lobster 는 존재하지만 auto-trigger 되지 않음
• 하랑이가 "@다랑이" 멘션을 명시적으로 안 걸면 다랑이가 깨지 않음
• 파이프라인이 LLM 의 분기 판단에 의존

영향

• QA 단계가 실질적으로 옵셔널
• 결과물 품질이 하랑이의 "이번엔 QA 필요할까?" 판단에 의존
• 사용자가 지속적으로 리마인드

처방 → Sprint 004 (상태 전이 기반 핸드오프 — Impl 완료 → QA 강제 전이)

---

F4 — 핸드오프 멘션 불안정

증상

• Gap 감지 루프에서 "APPROVE → 이랑이 / REQUEST_CHANGES → 나랑이" 분기가 LLM 판단에 맡겨짐
• 잘못된 자매 호출, 멘션 씹힘 사례 발생
• Lobster 워크플로우의 분기 로직이 언제나 예측 가능하지 않음

증거

• 사용자 증언: "멘션도 제대로 안되고", "잘못 자매를 호출"
• 커밋 dd07c67 refactor: Lobster 하이브리드 구조로 재설계 — Lobster 자체가 여러 번 재설계됨

근본 원인

• Lobster 분기 문법이 LLM 해석에 의존
• 결정론적 state machine 이 없음
• 핸드오프 방식이 "디스코드 멘션" 이라서 멘션 파싱 / 알림 전달 / 자매 wake 라는 3단계를 거침 — 각 단계가 실패 지점

영향

• 같은 입력 → 다른 결과
• 디버깅이 사실상 불가능 (재현성 없음)
• 사용자가 파이프라인 신뢰 상실

처방 → Sprint 001 (XState FSM 스켈레톤) + Sprint 004 (상태 전이 핸드오프)

---

F5 — 중간 끊김 / 타임아웃 무한대기

증상

• request-timed-out 메모리 파일 여러 건 존재
• 과거 "thinking tier xhigh 는 무한대기 유발" 이력 (fix 커밋 존재)
• 재시도 정책이 없거나 약함

증거

~/.openclaw/workspace/memory/2026-04-04-request-timed-out-before-a-res.md
~/.openclaw/workspace/memory/2026-04-08-request-timed-out-before-a-res.md
커밋: 63c6d76 fix: thinking tier 되돌림 — xhigh는 무한 대기 유발

근본 원인

• 자매 호출에 명시적 timeout 이 없거나 기본값이 과도함
• timeout 발생 시 재시도 정책 부재
• 파이프라인이 타임아웃 자매를 기다리며 좀비 상태가 됨

영향

• 사용자가 수동으로 죽이고 재시작
• 중간에 끊기면 어디까지 진행했는지 복구 경로 없음

처방 → Sprint 005 (Resilience policy — exponential backoff + auto retry + escalation)

---

F6 — 환경 검증 누락

증상

• 나랑이가 "Docker/MariaDB 실기동 미검증 (서버에 Docker 없음)" 를 리스크 항목으로만 보고하고 넘어감
• "환경이 없어서 skip" 이 용인됨

증거

나랑이: 남은 리스크:
        Docker/MariaDB 실기동 미검증 (서버에 Docker 없음)
        WebSocket 실연결은 브라우저 필요
        OpenClaw Gateway 실연결은 Gateway 있어야 함
        Frontend next build 미검증

근본 원인

• 스프린트 시작 전 환경 전제 검사(pre-flight) 가 없음
• "환경 없음 = 검증 skip" 이 contract 에서 허용됨
• 자매가 검증 불가 항목을 "리스크" 로 포장해 통과시킴

영향

• 실제로 안 돌아가는 코드가 "완료" 로 표시됨
• 프로덕션 직전에 발견되어 롤백
• QA 가 검증할 수 있는 환경이 없는데도 파이프라인이 진행됨

처방 → Sprint 003 (Sprint Contract 의 environment_prerequisites 필드) + Sprint 000 의 환경 감사

---

요약 매트릭스

코드	실패	처방 Sprint	원칙 참조
F1	Skill bypass	Sprint 002	원칙 4 (Skill 진입 강제)
F2	DoD 강제 실패	Sprint 003	원칙 3 (Sprint Contract)
F3	QA 자동 라우팅 누락	Sprint 004	원칙 2 (결정론적 FSM)
F4	핸드오프 멘션 불안정	Sprint 001 + 004	원칙 2 (결정론적 FSM)
F5	타임아웃 무한대기	Sprint 005	원칙 7 (재시도/에스컬레이션)
F6	환경 검증 누락	Sprint 003 + 000	원칙 6 (환경 검증 선행)

안 깨진 것 (유지/계승)

hanarang-harness 의 모든 것이 실패는 아니었다. 다음은 유지/계승한다:

자산	상태	계승 방식
scaffold.sh (.plans/ 스캐폴딩)	✅ 잘 동작	Rails 의 rails init 로 포팅
install.sh --role (자매별 에이전트 격리)	✅ 잘 동작	rails install --role <role> 로 포팅
에이전트 md 파일 (planner/worker/reviewer/deploy-manager)	✅ 내용 좋음	템플릿으로 계승, FSM actor 시스템 프롬프트 소스
doctor.sh (환경 체크)	✅ 유용	rails doctor 로 포팅 + environment_prerequisites 로 확장
hanarang/*.md (자매별 전문화 프롬프트)	✅ 유지	그대로 계승
디스코드 포럼 포스트 자동 생성	⚠️ 재검토	discord.js 로 재구현
Hook 3종 (파이프라인 자동화)	⚠️ 아이디어 계승	hanarang-rails hook 체계로 재작성

교훈 (Lessons Learned)

1. "권고" 는 강제가 아니다. LLM 은 명시적 강제가 없으면 가장 짧은 경로를 택한다.
2. 인간이 중재자가 되면 파이프라인은 실패다. 자동화의 목적은 개입 최소화.
3. "완료" 의 정의는 기계가 판정해야 한다. 자매의 주관 = 불일치 = 부실 완료.
4. 핸드오프는 데이터 구조이지 메시지 교환이 아니다. 멘션은 UI, 핸드오프는 state transition.
5. 재시도 없는 타임아웃은 좀비를 만든다. fail-fast + retry + escalate.
6. 환경이 없으면 스프린트를 시작하지 마라. skip 용인 = 거짓 완료.