Rinda · 앱린다 E2E 하네스 검증 · 2026-06-19
네이버페이 발표 "AI 에이전트용 Playwright E2E 하네스"를 send-grid-test 레포에 실제 적용. planner→generator→healer 전 사이클을 로컬에서 돌린 단계별 시간·성과와 효과·장단점.
실측(Playwright 실행 시간) + LLM 턴. 측정 합계 ≈ 2분, 수렴까지 healer 6라운드.
| # | 단계 | 시간 | 결과·성과 |
|---|---|---|---|
| 1 | 설치 init-agents | ~3s | planner/generator/healer + 프롬프트4 + .mcp.json + seed (9산출물) |
| 2 | seed 작성→통과 | 3.1s | 로컬 fresh 인증 + /sequences 진입 PASS |
| 3 | planner 계획서 | LLM 1턴 | specs/sequences-regression.md (시나리오 2종) |
| 4 | generator spec | LLM 1턴 | campaign-list-regression.spec.ts 생성 |
| 5 | healer R1 locale | 번인 실패 | 영어 렌더 진단 → locale: ko-KR |
| 6 | healer R2~3 role·타이밍 | 번인 2회 실패 | dialog→alertdialog, 비동기 대기 강화 |
| 7 | healer R4 상태블로커 판정 | — | 모달 영구 게이트 = "API seed 필요" 결론 |
| 8 | 가드 재정의 번인 | 5.4s | 3 passed + 3 skipped(fixme) PASS |
| 9 | healer R5 API seed stub | 55.2s | route HIT하나 patch 무효 → 로그 추적 |
| 10 | healer R6 envelope 발견 | 4.4s | apiFetch {data} 구조 독해 → patch 위치 교정 PASS |
| 11 | 전체 번인 repeat3 | 31.7s | 3 passed +3 flaky (부하 타이밍) |
| 12 | 안정화 workers=2 | 12.5s | 6 passed · flaky 0 GREEN |
단순 셀렉터 교정이 아니라 trace·aria·네트워크 로그·앱 소스를 읽어 원인 규명.
| R | 진단 근거 | 수정 |
|---|---|---|
| 1 | 화면 영어 렌더 | locale: ko-KR 고정 |
| 2 | 모달이 dialog 아닌 alertdialog | role 정정 |
| 3 | 모달 비동기 늦게 등장 | 대기 강화 |
| 4 | force·Escape에도 안 닫힘 = 상태 블로커 | "API seed 필요" 판정 (발표 교훈 실증) |
| 5 | API seed stub인데 모달 잔존 → 로그 심어 추적 | route HIT하나 patch 무효 확인 |
| 6 | apiFetch가 envelope {data} 벗김 (client.ts:153) | patch를 data 레벨에 적용 → 통과 |
apiFetch 소스를 읽어 envelope 구조를 규명. 발표의 "트레이스·네트워크를 개발자도구처럼 디버깅"을 그대로 수행.| 지표 | 값 |
|---|---|
| 자동 규명한 함정 | 4종 — locale · alertdialog role · 상태 블로커 · envelope 구조 |
| 1회 구축 후 반복 실행 | CI에서 LLM 비용 $0, 12.5s/회 결정론 |
| 재사용 자산 | legal-address.ts · overlays · seed → 타 테스트 즉시 재사용 |
| 최종 재현성 | 6/6 passed · flaky 0 |
초기 구축 비용: 높음 (하네스 1회)
한계 회귀 비용: ≈ 0 (CI 무료 반복, 12.5s)
손익분기: 변경 잦은 화면일수록 급격히 유리
→ sequences(10커밋/월)는 명백히 ROI(+)