Barbelic E2E 마스터플랜
2026-09-07 · 마스터플랜 및 v0.17.2 PR 실행 정책
2026-09-09 추가 결정: 개별 CASE의 필수 승인 조건은 테스트케이스 품질관리 기준 15개를 따른다. 실행 통과와 품질 기준 적합성, 정책 확정과 자동 강제 구현을 구분한다.
최초 예상 산출물은 계획 문서화 기록 §5의 기존 39개 + 신규 18개 = 약 57개로 남긴다. 구현 중 main에 S04의 옛 탭/새 탭 후속 행 여정 CASE-040이 먼저 추가되어, v0.17.2 신규 18개는 CASE-041–058로 정리했다(기존 개발 브랜치의 IndexedDB CASE-040 → CASE-058, 검증 범위 유지). 현재 합계는 58개 패키지, 자동 로컬 PR 집합은 57개이며 CASE-003은 별도 provider 조건부 집합이다. 구현/개별 검증과 최종 후보 전체 통과를 구분하고, 현재 결과·실패·제한은 구현 기록을 따른다.
목표는 핵심 사용자 여정이 정상 상황에서는 정확하고 빠르게 끝나고, 장애 상황에서는 입력과 소유권을 지키며 계약에 맞게 복구된다는 출시 근거를 만드는 것이다. 테스트 개수나 CI 초록 표시만으로 완료를 판단하지 않는다.
사용자 추가 요청에 따라 기존 E2E의 수리·보완·통합·계층 이동·퇴역까지 필수 범위로 포함했다. 기존 E2E 시스템 정비 계획에 CASE-001–039 전수 처리 장부, 공통 시스템 19개 정비 항목, 번호 밖 스위트·도구, 통합/삭제 조건과 실행 순서를 정리했다. 새 테스트 추가와 같은 작업 흐름에서 진행한다.
이 계획은 기존 v0.18.0 프로그램의 G02·G04·G05·U06·R02–R06에 연결한다. 별도 리팩터링 프로그램을 만들거나 기존 단계의 선행 조건을 건너뛰지 않는다. 앞서 완료한 CI 최적화의 v0.17.1 스테이징 지정과 이번 계획 전체의 릴리스 배정은 구분한다.
1. 기준과 계획의 사용법
- E2E 상세 감사 기준: main
16b8e99684a4cb152b2ff5d89b5aea10a7f055e0. 공통 감시기 누락·실행 공백·회귀 단언의 확인 내용은 이 문서와 기존 시스템 정비 계획에 반영했다. - 계획 작성 중 추가 확인: main
c2bf7f60518dcee06321065884ac75ba681d59fb의 G04 결과·성능 예산·저장 파이프라인 계약. 해당 버전 전체를 재감사하거나 실행한 것은 아니다. - 감사 당시 번호 사례 38개, 로컬 browser 목록 37개, 별도 Kakao 1개, viewport 14개였다. credential 모드 일반 browser 목록은 14개였다. 이는 당시 목록 수이며 현재 전체 개수나 이번 실행 통과 수가 아니다. 이후 계약에는 구형/신형 탭 공존 CASE-039가 연결돼 있다. 구현 시작 때 최신 목록·단언·미해결 항목을 다시 맞추고 이미 추가된 검증은 재사용한다.
- 정비 범위 추가 확인: main
07c04f371b19c300524f2a404ababd26b3962609에서 manifest 39개와 공통 시스템·번호 밖 검사를 대조했다. CASE-039의 RPC drain 및 독립 IDB/mirror 검사의 CI 연결은 기존 보강으로 반영했다. 해당 확인은 정적 처리 계획이며 전체 E2E 재실행은 아니다. - 아래 M0–M7은 이 문서의 작업 묶음이다. 새 GitHub 이슈나 CASE 번호를 생성했다는 뜻이 아니다. 실제 작업은 관련 기존 이슈와 담당 경계에 연결한다.
근거: G04 완료 기록, 최신 확인 저장 계약, 기존 실행 계획.
2. 무엇을 통과했다고 말할 것인가
출시 판정은 다음 다섯 가지 증거를 함께 요구한다.
- 기능: 로그인부터 운동 시작·입력·저장·수정·삭제·재조회까지 사용자의 목표가 실제 화면과 서버 데이터에서 완결된다.
- 보존과 복구: 응답 유실, 중복 입력, 앱 종료, 로그인 만료, 계정 전환에도 허용되지 않은 유실·중복·타 계정 노출이 없다. 임시 상태가 성공으로 위장되지 않는다.
- 체감 품질: 버튼 반응·저장 완료·조회·통계 반영이 각 측정 조건의 예산 안에 있다. 지연 중에도 진행 상태를 이해하고 다음 동작을 할 수 있다.
- 환경: 명시한 브라우저·실기기·앱 버전·오프라인·업데이트 조합에서 확인했다.
- 배포: 실제 배포 후보와 DB/함수/웹/네이티브 산출물이 검사한 버전에 대응하고, staging 리허설과 배포 후 관찰 결과가 연결된다.
완료 시 사용할 문장:
후보 [SHA 및 앱 빌드]는 [지원 환경]에서 필수 핵심 UX 요구사항과 장애 복구 시나리오를 통과했고, 지정한 성능 예산을 충족했다. 필수 검증 누락은 0건이며, 범위 밖 조건과 남은 제한은 첨부 목록에 명시했다.
이 문장은 모든 입력·모든 기기·미래의 외부 서비스 장애에서 무결함을 보장하지 않는다. 발견한 오류가 없는 것, 검증하지 않은 것, 의도적으로 지원하지 않는 것을 서로 다른 상태로 남긴다.
3. 제품 계약을 먼저 고정한다
테스트 기대값을 구현을 보고 복사하지 않는다. 사용자 행위, 제품 계약, 독립적인 입력 fixture를 기준으로 화면·원본·투영의 기대값을 정한다.
| 경계 | 지켜야 할 현재 계약 | E2E의 핵심 단언 |
|---|---|---|
| 로컬 저장 | 완료 기록은 IndexedDB 대기열에 먼저 적재한 뒤 로컬 완료를 알림 | IDB 적재 실패 시 성공 표시·초안 삭제 없음. 적재 성공 후 네트워크 실패로 입력을 잃지 않음 |
wait 저장 | 자동 완료·저장 버튼·지난 기록은 영수증을 기다리는 정책 | 정상 응답 뒤 완료. 임시 실패 때 자동 완료 화면은 동기화 후 점수 반영 상태, 다른 저장 진입점은 기기 보관 안내 등 동작별 계약 확인 |
immediate 수정·삭제 | durable enqueue 뒤 화면을 닫고 전송은 계속 | 서버 응답을 막아도 로컬 완료 가능. 뒤늦은 성공으로 화면이 재열리거나 안내가 중복되지 않음 |
| 인증 실패 | held에 남기고 같은 owner가 다시 준비되면 재개 | 로그아웃/다른 계정 진입 중 잘못 전송되지 않음. 원래 owner 복귀 뒤 정상 수렴 |
| 일시 실패 | queued로 복귀해 재시도 | 같은 논리 요청의 mutation ID·hash·payload를 재사용하고 중복 반영 없음 |
| 개정 충돌 | LG409/40001은 현재 나중 저장 우선 정책에 따라 최신 revision으로 재전송 | 계약에 맞는 최종 값과 이력, 중복 없음, 무음 복구. 모든 충돌에 안내창을 요구하지 않음 |
| 영구 거절 | blocked, 무한 자동 재시도 없음 | 해당 거절의 실제 복구 동작·입력 보존·표시 계약을 브라우저에서 확인 |
| 사용자 원본 | 사실과 계산 결과를 구분하고 사용자 행위 없이 원본을 고치지 않음 | 입력값·ID·자식 관계·과거 이력 보존. projection 재계산과 migration 전후를 별도 비교 |
앞선 감사에서 제안한 “동시 수정 충돌을 사용자에게 안내”는 너무 넓었다. 위 계약에 맞게 정정한다. 현재 동작과 v0.18.0의 claim/fence/successor·undo 등 신규 계약도 버전별로 나눈다. 아직 활성화되지 않은 기능의 기대값을 기존 앱에 강요하거나, 지원하지 않는 capability를 가짜 성공으로 처리하지 않는다.
근거: 저장·실패·안내 정책, 원본 불변 계약.
4. 요구사항 장부: MECE의 기준
파일이나 테스트 제목이 아니라 사용자가 달성해야 할 결과를 분모로 삼는다. 아래는 목표별 최상위 묶음이며, 구현 시작 때 G05의 실제 기능 목록과 대조해 세부 요구사항으로 분해한다. 공통 인증·저장 절차가 여러 테스트에 반복되는 것은 허용한다.
P0는 로그인 불능·핵심 운동 차단·데이터 손실/중복·타 계정 노출을 막는 필수 범위다. P1도 이번 후보의 제공 기능에 속하면 릴리스 필수 범위에 포함한다. 우선순위가 낮다는 이유로 자동 제외하지 않는다.
| ID | 사용자 목표 | 필수 정상 결과 | 장애·경계 결과 | 기존 증거 / 확장 지점 |
|---|---|---|---|---|
| UX-01 | 로그인·온보딩·재진입 | 첫 로그인, 기존 계정 진입, 프로필/신체 입력, 로그아웃 | provider 취소/실패, 만료 후 재로그인, 실제 지원 로그인·연결 경로의 복귀 | 003·009·010·012–014. 외부 provider 성공 가정을 실제 공급자 증거와 구분 |
| UX-02 | 운동 시작·기록 | 종목 검색/선택, 지원 기록 유형과 복합 구성, 시간·메모 입력, 초안 이어하기/폐기 | 한글 IME, 빈 값·경계값, 뒤로가기, reload, 최초 폐기 뒤 ghost 없음 | 001·011·021–024·028·030–033. 첫 동작 실패를 두 번째 동작으로 감추지 않음 |
| UX-03 | 완료 기록 저장·수정·삭제 | 모든 wait/immediate 진입점, 정확한 원본·관계·영수증, reload 후 동일 결과 | 아래 보존 행렬 전체, 중복 탭/클릭, 지연 응답, 예상 거절 | 004·015·029·032·036 + 기존 단위/DB 테스트 |
| UX-04 | 계획을 만들고 운동으로 전환 | 계획 작성·수정·삭제, 전체/부분 완료의 identity 보존 | 저장 실패, 전환 중 종료, 재시도·동시 변경 | 016·025·034. 전체와 부분 완료를 서로 대체하지 않음 |
| UX-05 | 내 기록 확인 | 홈·달력·상세·PR·리포트의 원본과 계산 결과 일치 | 빈 계정, 1/4/10년, 월·연도·시간대 경계, 오류/empty 구분, 오래된 응답 역전, 통계 지연 | 004–006·008·037, Node 빈 계정. 0건 PR records 검증 복구 |
| UX-06 | 종목 관리 | 검색·커스텀 생성·수정·archive/restore·동기화 | 검색 실패/응답 역전, 다른 owner 데이터 비노출 | 001·031·037·038. 현재 제공 경로부터 세분화 |
| UX-07 | 그룹 참여·보드 이용 | 그룹 생성·초대·수락·참여·운동 시작, owner/member 차이 | 멤버십 회수, 열려 있던 화면 권한 갱신, 동시 수정 | 019·020·026·027·035. 준비 RPC와 실제 가입 UI 여정을 구분 |
| UX-08 | 소셜 반응·안전 기능 | 피드·좋아요·댓글 작성/삭제·관계 변경·신고/차단 | 낙관적 반영 실패/재시도, 중복 입력, 차단/권한 변경 반영 | 018과 viewport 댓글 검사. 기능 왕복 추가 |
| UX-09 | 프로필·계정 관리 | 이름·아이디·사진·신체 정보 변경, 내보내기, 지원 계정 연결/해제 | 중복 아이디, 업로드 실패, 입력 유지·재시도, 연결 취소 | 실제 연결된 화면 기준. 하위 코드 번역 테스트를 UI 완료로 세지 않음 |
| UX-10 | 계정 삭제·신원 격리 | 삭제 대상 데이터 정리, 다른 계정/공용 자산 유지, 세션 종료 | 부분 실패·재시도·진행 중 화면, A→B→A의 캐시·queue·storage 격리 | 007·017·018·038. 파괴적 검증은 격리 환경 |
| UX-11 | 인입·내보내기·복구·관리 | 실제 제공 인입 UI→job→원본→조회, export 결과 정확성, 관리자 경로 | 파일 오류·부분 성공·재업로드 중복·취소/재개, 사본 복원과 projection 재생 | I01/G05 목록 대조. 미배선 기능은 현행 지원으로 세지 않음 |
| UX-12 | 어느 지원 환경에서도 조작 | 키보드·포커스·뒤로가기·overlay·확대·safe area, 정상 앱 업데이트 | 오프라인 부팅, SW 교체, 오래된 앱/IDB, 백그라운드 종료/복귀 | viewport 14개는 기하 증거. 기능·접근성·실기기 증거를 추가 |
각 세부 요구사항은 다음 필드를 가진다.
requirementId / 상위 UX / 제품 계약·버전 / 담당 / 우선순위 / 시작 상태 / 사용자 동작 / 실패 위치 / 기대 UI / 기대 원본·이력·투영 / 성능 지표 / 주 담당 CASE / 하위 테스트 / 필수 환경·CI 레인 / 최근 검증 SHA·증거 / 상태·제외 근거
장부 규칙:
- 한 요구사항의 주 담당 CASE는 하나로 지정하되 보완 증거는 여러 개 연결할 수 있다. 미세한 경우의 수는 하위 테스트로 연결한다.
- 모든 공개 기능과 중요 공유 계층에는 소유자가 있어야 한다. 새 기능/변경 계약은 같은 PR에서 요구사항과 실행 매핑을 갱신한다.
- 필수 집합의 통과율은
실제 통과한 필수 요구사항 / 사전에 지정한 필수 요구사항으로 계산한다. CASE 개수·코드 라인 커버리지를 이 수치로 대체하지 않는다. pass / fail / flaky / not-run / blocked / not-applicable을 구분한다. 필수 범위의 skip·fixme·환경 부재·불명확한 quarantine은 통과가 아니다.- 모든 조합을 곱하지 않는다. 손실·신원·핵심 차단 경계는 명시적으로 모두 지정하고, 나머지는 대표값/쌍별 조합으로 줄인다. 조합을 줄인 이유도 남긴다.
4.1 사용자에게 필요한 보장 — 핵심 UI에서 저장·진행이 막히지 않음
2026-09-08 사용자 확인: 원하는 합격 의미는 자주 사용하는 핵심 UI 플로우에서 예상치 못한 오류 때문에 저장하거나 다음 단계로 진행하지 못하는 일이 없는 것이다. 광범위한 인프라 정비보다 이 결과의 실제 단언과 실행 증거를 우선한다. 현재 사용 빈도 계측으로 순위를 산출한 것은 아니며, 우선 대상은 로그인/재진입, 운동 시작/초안 이어하기/폐기, 종목·세트 입력/완료 저장, 완료 기록 수정/삭제, 계획 생성/편집/운동 전환, 홈/달력/상세/PR·통계 조회다.
각 플로우의 합격 계약은 다음과 같다.
- 정상 경로는 실제 시작 화면에서 사용자 조작으로 목적을 끝낸다. 버튼이 보인다는 단언만으로 enabled·클릭·다음 화면 도달을 대체하지 않는다. 예상치 못한 사용자 오류·pageerror·실패 요청이 없어야 한다.
- 입력 중 저장 실패가 나면 입력값·초안이 보존되고 사용자가 취할 다음 동작에 도달해야 한다. 실제 장애를 해제한 뒤 제품 계약의 사용자 재시도 또는 자동 재전송으로 같은 일을 완료한다. 무한 로딩·계속 비활성인 버튼·열 수 없는 복구 화면·재시도해도 진행 불가 상태는 실패다.
- 완료 화면, 실제 owner의 저장 원본, 다시 열었을 때의 결과가 일치해야 한다. 오프라인 상태에서는 계약대로 기기 보관 상태를 구분하고 연결 복구 후 서버 반영까지 확인한다.
- 정상 조작과 장애 구간을 분리한다. 입력 오류를 바로 고칠 수 있는 유효성 안내와 의도적으로 주입한 실패만 정확한 문구/횟수/시점으로 허용한다. 예상 오류를 광범위하게 허용해 일반 플로우의 오류를 덮지 않는다.
- 플로우별 시작→목적 완료, 장애→보존→재시도→완료, 재진입의 실제 단언과 후보별 결과를 장부에 연결한다. 필수 플로우에 미실행·미완주가 있으면 포괄적인 핵심 UX 통과로 보고하지 않는다.
57개 번호 E2E의 필수 7신호는 공통 증거 틀이다. 각 신호가 있다고 해서 위 목록의 모든 화면 진입점·종료 상태·지원 환경까지 자동으로 검증된 것은 아니다. 6개 핵심 플로우와 실제 spec 단언의 대조 장부를 함께 사용하며, 실제 provider/native 조건은 별도 증거로 남긴다.
4.2 남은 정비의 우선순위와 산출물
다음은 구현 완료 선언이 아닌 보완 순서다. 기존 자동 57개와 viewport 14개를 PR 필수로 유지하면서 확장한다.
| 순서 | 보완 내용 | 산출물·완료 기준 |
|---|---|---|
| 1 | 핵심 UI 플로우의 종료·복구 단언 빈틈 보완 | 플로우×정상/장애/복구/재진입 장부. 화면에서 끝내지 못하는 경계가 있으면 기존 CASE에 실제 사용자 단계와 원본 대조를 추가. 재현한 제품 결함은 회귀와 함께 수리 |
| 2 | 기기·입력·장애 조합을 재현 가능한 목록으로 관리 | 지원 엔진/실기기와 웹 모사를 분리한 환경 목록, 입력 대표값·경계값, 허용 조합과 제외 근거. 핵심 정상 플로우는 지원 환경별 확인, 높은 위험의 계정 전환·저장 중단·응답 역전 순서는 명시적으로 고정. 나머지는 쌍별 조합과 하위 상태 전이/속성 검사로 확대 |
| 3 | 요구사항·CASE 메타데이터 정본 및 문서 생성 | requirement/flow ID, 담당 CASE, 환경, 실패 위치, 기대 종료 결과를 한 규격으로 정의. 목록·표를 생성하고 중복 ID·매핑 누락·생성 결과 차이를 CI에서 거절. 실제 기대값/사고 맥락까지 제품 구현으로 자동 생성하지 않음 |
| 4 | 모든 실행 레인의 결과를 요구사항별로 연결 | browser/viewport/단위/DB/native/provider/성능/복원 각각의 원본 결과를 adapter로 읽는 공통 인덱스. 후보 SHA·빌드·환경·CASE/요구사항·첫 시도·실행 시각·cleanup·artifact와 pass/fail/flaky/not-run/blocked/not-applicable을 보존. 수동 증거는 수행자·기기·시각·대상 빌드 포함. 오래된/다른 후보 증거·필수 누락은 통과로 합치지 않음 |
| 5 | fixture의 결합이 큰 책임을 순차 분리 | 계정/데이터 준비, 장애 주입, 관측, 정리, 완료 집계를 작은 모듈로 나누되 현재 entry API와 owner 격리·실패 전파를 유지. 한 경계씩 기존 사용자 단언과 완료 증거의 동등성을 확인. 전면 재작성 자체를 UX 품질 완료 기준으로 두지 않음 |
조합 수는 지원값·제약·상호작용 차수를 정한 뒤 산출하며 임의 CASE 목표를 먼저 정하지 않는다. 쌍별 검사는 높은 차수의 장애나 이벤트 순서를 보장하지 않으므로 저장/계정/업데이트의 중요한 순서는 별도 시나리오로 고정한다. 이 방법의 근거는 NIST의 조합·이벤트 순서 검증 연구다. 많은 입력 조합은 빠른 하위 검사에 배치하고 실제 UI 종료·복구를 담당하는 E2E를 유지한다.
기기 이름으로 실행한 웹 모사는 실제 OS 종료·키보드·provider 복귀의 실기기 증거가 아니다. Playwright의 모사 설정은 user agent·화면 크기·touch·locale/timezone 등의 브라우저 조건을 다룬다. 공식 reporter는 Playwright 샤드의 결과 병합을 지원하지만 DB/native/성능 결과의 의미까지 통합해 주지는 않으므로 공통 인덱스의 판정 규격은 별도로 필요하다.
확장 실행 정책은 기존 PR 필수 집합을 줄이지 않는다. 빠른 입력/상태 조합과 핵심 엔진 검사는 측정 후 PR에 추가하고, 시간이 큰 광범위 조합은 정기 실행, 실제 기기/provider/성능/복원은 고정 릴리스 후보의 필수 증거로 연결한다. 비용·실행 주기는 측정과 지원 환경 확정 후 결정하며 이 문서 수정만으로 새 예약 작업을 만들지 않는다.
5. 데이터 보존·복구 필수 행렬
각 행은 “오류 코드를 받았음”에서 끝나지 않고 사용자 동작 → 실제 저장소/서버 경계 → 화면 복구 → 독립 조회까지 연결한다. 준비와 관찰에는 API를 사용할 수 있지만, 검증 대상 사용자 동작을 API 호출로 대신하지 않는다.
| ID | 장애 위치·재진입 | 필수 변형 | 최종 합격 조건 |
|---|---|---|---|
| D-01 | IDB 적재 전 실패 | quota/transaction 실패, 지원 범위의 storage 사용 불가 | 초안/입력 유지, 저장 성공 표시 없음, 허용된 다음 동작 가능 |
| D-02 | 서버 도착 전 단절 | 생성·수정·삭제, timeout/503/429, 실제 offline | 계약별 화면과 queue 상태, 원문 유지, 연결 복귀 후 정확히 한 번 반영 |
| D-03 | 서버 commit 뒤 응답만 유실 | 생성·수정·삭제 | 실제 commit을 먼저 관찰한 뒤 해당 응답만 차단. 재전송에서 같은 mutation ID/hash, revision·이력의 이중 반영 없음, 최종 queue 수렴 |
| D-04 | pending/sending 중 앱 종료 | 두 상태, 생성·수정·삭제 | 실제 IDB를 유지한 페이지/프로세스 재시작, 부팅 전송기 재개. queue를 비운 뒤 reload하는 검사로 대체하지 않음 |
| D-05 | 인증 만료·신원 변경 | 실제 만료→재로그인, A→B→A, 대기 데이터 존재 | A의 행이 B로 전송/표시되지 않음. A 복귀 뒤 원문과 동일하게 완료. 서버/화면/기기 저장소 모두 확인 |
| D-06 | 중복·동시성·응답 역전 | 두 번 클릭, 두 탭 전송, 두 기기 수정, 보내는 중 수정/삭제, 늦은 ACK | 동일 논리 작업의 중복 없음. 최신 사용자 의도가 구 응답으로 덮이지 않음. current LWW/신규 fence 등 적용 계약별 결과 |
| D-07 | 서버의 영구 거절 | LG426·권한·유효성·제약 오류의 대표 경로 | 브라우저가 실제 거절을 받아 규정된 안내/복구를 제공. 입력 보존, 자동 재시도 폭주 없음 |
| D-08 | 저장 성공 뒤 조회 지연/실패 | 상세·홈·달력·PR/통계의 지연, 응답 순서 역전 | pending/stale/confirmed가 구분되고 저장을 다시 만들지 않음. 최신 generation의 화면으로 수렴 |
| D-09 | 구 앱·신 앱·저장소 교체 | old/old, old/new, new/old, new/new; dirty draft·미전송 queue·blocked IDB upgrade | 실제 bundle로 허용/대기/불가 capability를 증명. 강제 IDB clear 없이 보존. CASE-039 및 S01 결과 재사용 |
| D-10 | migration·복원·인입 재생 | populated 이전 DB, 부분 실패·중단/재개, 지원 구형 사본 | 값·ID·FK·출처·history 보존, 대상 외 데이터 불변, 복원 후 read-model 일치 |
D-03은 route.fetch() 등으로 실제 서버 처리를 마친 뒤 응답을 버리는 방식과 서버 관찰을 결합한다. 앱의 자동 재시도까지 관찰되도록 실패 횟수와 대상 요청을 고정한다. D-04는 browser context를 새로 만들어 빈 저장소로 시작하면 목적을 달성하지 못하므로 동일 기기 저장소를 유지한다. 모바일 OS에 의한 앱 종료는 별도 실기기 증거가 필요하다.
장애 주입은 대상 owner·mutation·endpoint·시점·횟수로 한정한다. 예상 오류 허용 목록도 동일 범위를 사용하며, 경고 전부나 console 전부를 무시하지 않는다. 각 장애 시험에 정상 대조군과 복구 후 무결성 조회를 둔다. 타 owner 대조 데이터는 정리 단계까지 유지해 부수 손상을 확인한다.
6. 계층별 역할과 테스트 신뢰성
| 계층 | 맡길 검증 | 대신할 수 없는 것 |
|---|---|---|
| 단위·속성·계약 | codec, 상태 전이, 병합, ID/hash, 오류 분류, 원본/투영 규칙의 많은 조합 | 실제 부팅·DOM·인증·IDB 연결 |
| pgTAP·DB/API 통합 | RLS, receipt replay, revision, 원자성, history, migration·복원 정합성 | 사용자가 보는 안내와 다음 조작 |
| browser full-stack | 실제 UI→인증→IDB→RPC→DB→다시 읽기, 장애 후 복구 | 네이티브 생명주기와 실제 외부 provider 전체 |
| viewport·접근성 | 레이아웃, 스크롤/확대, focus/keyboard, semantic roles, 핵심 조작 | 업무 결과와 원본 저장의 정확성 |
| 실제 네이티브·provider | 앱 종료/복귀, deep link/SSO, WKWebView/Android WebView, 실제 키보드 | 다른 버전·다른 기기 전체 |
| staging·운영 관찰 | 실제 배포 산출물 연결, 환경 차이, 실사용 오류/지연 | 실행하지 않은 시나리오에 대한 보장 |
공통 fixture는 다음을 지킨다.
- 오류 감시기는 빈 alert의 지연 텍스트·Text 수정·중첩 수정·노출 후 제거를 잡고, 정상 안내 대조군은 오탐하지 않아야 한다. 이 감시기 수리 자체에 행동 테스트를 둔다.
- 앱의 pageerror, console, 네트워크, 사용자 오류 표면, 서버 오류를 서로 다른 증거로 보존한다. 의도된 취소/오류는 해당 시나리오의 계약으로 판정한다.
- 테스트가 실패 경로를 실제로 통과했는지 확인한다. 장애가 한 번도 주입되지 않았거나 복구 코드가 실행되지 않았으면 실패다.
- 임의 sleep 대신 관찰 가능한 상태와 제한 시간을 사용한다. 재시도 통과는 flaky로 남기고 필수 검증의 합격으로 바꾸지 않는다.
- v0.17.7 예정인 #1468 시간 제한에 맞춰 Node·Playwright 케이스를 개별 준비 포함 60초 이내로 작성한다. 클릭·입력·화면 전환·페이지 접속·배치 안정화는 각각 최대 10초이며 테스트 자동 재시도는 0회다. 긴 예외를 추가하지 않고, 실제로 필요한 경우에만 단언을 보존하여 케이스를 분리한다.
- Node 개별 준비는 테스트 본문에 둔다. 공통 빌드·DB 기동·공유 준비와 정리는 별도이며, 이 제한을 pgTAP SQL·전체 CI 실행 시간의 상한으로 표현하지 않는다.
- CASE-011의 두 번째 폐기 같은 시험 내부의 수동 복구로 첫 동작 실패를 숨기지 않는다. 오래된 skip은 현재 재현과 대체 증거를 확인한 뒤 복구/정리한다.
- trace·스크린샷·요청 식별자·정제한 receipt/queue 상태를 남긴다. 인증 토큰과 사용자 메모·인입 원문을 공용 로그에 남기지 않는다.
7. 성능과 체감 품질의 합격 기준
이미 마련된 G04 측정기·fixture·증거 schema와 RELEASE_PERFORMANCE_BUDGETS를 재사용한다. mock CPU 시간, DB 서버 시간, 사용자가 화면에서 기다린 시간은 구분한다.
7.1 이미 정해진 예산
최신 확인한 G04 성능 예산은 18개 항목과 증가 추세·회복 기준을 제공한다. 대표 항목은 다음과 같다. 전체 판정은 정본의 모든 해당 항목을 사용한다.
| 항목 | 기존 상한 | 해석할 때 지킬 조건 |
|---|---|---|
| 홈 RPC 서버 시간 | p95 117ms | 정해진 로컬 DB·이력 fixture 조건. 클릭→홈 완료 시간이 아님 |
| 생성 저장 서버 시간 | p95 40ms | 정해진 혼합 부하의 서버 시간. 모바일 저장 완료 40ms를 뜻하지 않음 |
| 홈 cold ready | 1,448ms | 로컬 preview·CPU 4배·정해진 fixture. 실제 기기/배포망 측정은 별도 |
| 초기 script 전송량 | 601,434 bytes | 같은 cold 초기 요청 범위 |
| 홈 DOM | 294 nodes | 같은 홈 fixture와 관찰 시점 |
| 통계 반영 | p50 1,101ms | worker가 집은 뒤의 반영 정의. 사용자 저장부터 대기 시간을 포함한 p95와 다름 |
같은 조건에서 두 번 이상 측정하고 1/4/10년 추세, 과부하 후 backlog 소진, 다른 owner·일반 조회의 고갈 여부도 통과해야 한다. 기존 상한은 회귀 방지 기준이므로 통과 자체를 쾌적한 UX의 완성으로 해석하지 않는다. 실제 인입은 I01 경로로 측정하며, 저장 RPC 연속 호출로 근사한 부하를 실제 import 완료 증거로 쓰지 않는다.
7.2 추가할 사용자 관점 시간
측정 지점을 사용자 입력(t0) → 첫 화면 반응(t1) → IDB commit(t2) → 서버 receipt(t3) → 최신 결과 표시(t4)로 분리한다. 네트워크 정상/느림/단절, cold/warm, 짧은/긴 이력, 기기 등급별 결과를 섞지 않는다.
| 지표 | 시작·끝 | 계획 초안의 목표 | 완료 조건 |
|---|---|---|---|
| 조작 피드백 | 클릭/입력→진행 상태나 결과의 첫 표시 | p95 ≤ 200ms | 핵심 버튼·검색·탭에서 사용자에게 반응이 보임 |
immediate 저장 UX | 클릭→durable enqueue 및 계약상 화면 종료 | p95 ≤ 1초 | 네트워크 응답을 지연해도 로컬 저장 이후 완료, IDB 실패 시 성공 처리 없음 |
wait 저장 UX | 클릭→receipt가 반영된 완료 화면 | 정상망 p95 ≤ 3초 | 서버 시간과 별도로 클라이언트·전송·렌더 비용 포함 |
| 일시 실패 전환 | timeout/실패 확정→규정된 보관·pending 상태 | 전환 p95 ≤ 1초 | 전체 무응답 제한도 따로 기록. 현재 전송 timeout 10초를 빠른 UX 목표로 오인하지 않음 |
| 조회·통계 freshness | 사용자 저장→최신 상세/홈/PR 표시 | G04 계측과 연결해 M0에서 화면별 고정 | worker 내부 시간뿐 아니라 queue 대기·재조회·렌더 포함 |
위 추가 숫자는 제안값이며 현행 승인 예산이나 달성 결과가 아니다. M0에서 지원 기기·네트워크·이력 fixture, 반복 횟수, 분산, p95 산출 방법과 함께 고정한 뒤 후보를 검사한다. 기존 G04 예산은 자동으로 완화하지 않는다. 확정되지 않은 필수 UX 시간 기준은 최종 완료의 미검증 항목으로 남긴다.
p95에 가려지는 장시간 멈춤도 별도 검사한다. 예를 들어 응답을 의도적으로 오래 막고 진행 상태, 중복 클릭 방지, 다른 화면 이동, 보관 후 복귀가 계약대로 작동하는지 본다. 성능 회귀 비교에는 동일 환경과 독립 반복을 사용하고, 관측 표본 수·최댓값·실패/timeout 횟수를 함께 보고한다. 테스트 자체가 끝난 시간만 재서 사용자 반응 시간으로 기록하지 않는다.
8. PR 필수 실행 정책 — v0.17.2
사용자 결정에 따라 릴리스 직전 한 번이 아니라 PR마다 필수 검사를 적용한다. 영향 선택기의 누락 가능성이 별도로 검증되기 전까지 실행 코드나 미분류 경로가 포함된 PR은 전체 자동 집합을 실행한다. 기존 CI 병렬화와 독립 DB를 쓰는 browser 4샤드, 샤드 안 workers=1은 유지한다.
| 실행 지점 | 검사할 범위 | 통과의 의미 |
|---|---|---|
| 모든 PR | scope + 정적/계약 검사 + 단위 샤드 | 현재 비교 기준과 실제 검사하는 merge/head의 일치 |
| 앱·서버·DB·테스트·fixture·빌드/의존성/실행 설정·미분류 경로 포함 PR | 57개 자동 로컬 CASE + viewport 14개 + Node DB 여정/독립 저장소 검사 + migration replay/pgTAP | 지정된 자동 집합 전체의 실제 첫 시도 완주와 cleanup |
| 명시된 비실행 문서/기여 템플릿만 바뀐 PR | verify-only. full-ci로 전체 실행 강제 가능 | 실행 코드를 문서 예외로 분류하지 않았음 |
| 보호된 main에 머지된 뒤 | 정적·단위·문서 확인 + 별도 staging 배포/smoke. 전체 E2E 중복 실행 없음 | PR 필수 verify 성공 뒤 머지. 필요시 수동 전체 실행 가능 |
| main push·수동 full 실행 | workflow의 동일 full 집합과 evidence 집계 | 실제 해당 SHA의 결과. PR의 이전 성공을 가져오지 않음 |
| CASE-003/provider | 준비된 QA 계정의 별도 provider 가정 레인 | 공급자 성공 가정 아래 앱 세션 왕복. 실제 외부 OAuth의 전 과정 성공은 아님 |
| 릴리스 후보 | 위 자동 집합 + 실제 후보/DB/함수/웹·native 연결, 호환·복원·성능·실기기 | 후보별 필수 환경과 미검증 범위를 밝힌 출시 근거 |
| 배포 후 관찰 | 허용된 smoke·읽기 중심 오류/지연 지표 | 배포 연결과 관찰 구간의 결과 |
정기 WebKit/실기기/부하 검사의 예약은 별도 미구현 항목이다. 이 PR 정책을 기록했다고 정기 자동화나 실제 플랫폼 실행이 생긴 것은 아니다.
선택 집합과 완료 판정
사전 필수 목록은 e2e/required-coverage.json이다. runner가 우연히 발견한 목록만 다시 세어 누락 없음을 주장하지 않는다. browser는 CASE-001–058 중 CASE-003을 제외한 57개, viewport는 이름이 고정된 14개이며 각 항목은 정확히 한 번 완료되어야 한다. 새 제공 기능이나 CASE 변경은 같은 PR에서 이 목록과 실제 요구사항 매핑을 갱신한다.
E2E_REQUIRED_PROFILE=local은 로컬 URL·anon key·service role을 요구하고 환경 누락이나 credential 모드 대체를 오류로 처리한다. 실제 만료 JWT 검사는 local signer를 요구한다. 파괴적/장애 주입 사례의 local-only manifest와 별도 provider 개인정보 제한은 유지한다.
verify는 scope·static/unit뿐 아니라 migration-smoke·browser-journeys·viewport-matrix·e2e-evidence를 모두 기다린다. full이 선택된 경우 하나라도 실패·취소·skip이면 성공하지 않는다.- required reporter는 첫 시도 성공, 예상 실패/skip/fixme 없음, 실제 수집/완료 ID 일치, 사례의 7개 신호와 cleanup 증거를 요구한다. CI의 retry가 진단에 성공해도 flaky를 합격으로 바꾸지 않는다.
- 집계기는 같은 SHA/run의 모든 샤드, 정확한 필수 ID 집합, 중복/누락 없음과
journey-completion.json을 확인한다. 낡은 보고서나 환경 부족의 0건 실행은 거절한다. - 예상 장애는 method/path/status/시도 구간과 checkpoint의 정확한 표면/횟수·telemetry 영수증으로 한정한다. broad console ignore나 예상 오류 전체 무시는 허용하지 않는다.
- 실제 저장소/화면 버그를 발견한 red는 수리 후 해당 단언으로 다시 검증한다. DB/reload 성공만으로 현재 UI의 오류를 덮지 않는다.
- branch protection이 요구하는 check와 후보 SHA 연결은 릴리스 마감에서 실제 설정을 확인한다. workflow 코드만으로 원격 설정이 완료됐다고 보고하지 않는다.
로컬 운영
npm run ci:local -- --plan
npm run ci:local -- --full --sandbox <dedicated-sandbox>
npm run ci:local -- --only browser,viewport --sandbox <dedicated-sandbox>부분 실행은 개발용 재현이다. 최종 PR 집계에는 default required reporter와 전체 artifact를 사용한다. 서로 다른 테스트 프로세스가 전역 stats drain을 쓰는 같은 DB에서 겹치지 않도록 독립 sandbox 또는 테스트 슬롯을 사용한다. DB를 공유하는 진행 작업 중에는 reset하지 않는다.
시간·비용 관리
직전 동일 head 비교의 full 실행 6분34초, runner 누적 36분18초는 이전 37개 집합의 단일 캐시 적중 표본이다. 새 테스트의 소요 시간 보장으로 사용하지 않는다. CI 최적화 PR #1306.
S05/S07/A12/A13까지 통합한 v0.17.2 구현 PR의 최종 원격 CI는 57개 자동 CASE + viewport 14개 전부 첫 시도로 8분 55초에 통과했다(run 34179301795). 가장 느린 browser 3/4 job은 8분 12초, 여정 step은 5분 6초이며 runner 시간 합산은 48분 42초다. 이는 사용자 대기 시간이나 청구 금액과 다르다. 단일 성공 표본으로 p95·동일 조건의 속도 개선율·비용 절감을 주장하지 않는다. 통합 전 56개 집합의 실행 결과는 구현 기록에 별도로 보존한다. 기존 5분/10분 목표는 측정 전 제안이며 지금 충족했다고 보고하지 않는다. queue 대기, 설치/DB 준비, 실제 테스트, artifact, 집계를 나눠 기록한다. 영향 선택·샤드 재균형은 누락 없는 동등성 증거와 비용을 확보한 뒤 적용하며 느린 중요 검사를 삭제해 시간을 맞추지 않는다.
staging의 credential 모드가 로컬 full과 같은 CASE를 수집한다고 가정하지 않는다. local-auth-admin이 필요한 파괴적/장애 시험은 격리 스택에서 실행하고, staging에서는 실제 배포 API에 연결되는 허용된 별도 집합을 갖는다. Production에는 임의 사용자 쓰기, 전역 장애 주입, 계정 일괄 삭제나 부하 시험을 넣지 않는다.
9. 플랫폼·접근성·업데이트 검증
M0에서 실제 지원 정책의 OS/브라우저 최소·대표 버전과 네이티브 빌드 채널을 고정한다. 현재 확인하지 않은 기기 모델이나 지원 버전을 임의로 선언하지 않는다.
| 환경 | 최소 필수 여정 | 실행 시점 |
|---|---|---|
| Desktop Chromium + touch/mobile Chromium | 핵심 정상·보존·복구, keyboard·focus·확대·overlay | PR 핵심 및 정기 전체 |
| WebKit | 로그인·운동 입력·durable 저장·reload·offline·날짜/키보드 관련 핵심 | 관련 변경 및 정기/릴리스 |
| 실제 iOS/WKWebView | 실제 지원 SSO 왕복, 가상키보드·safe area, 백그라운드/종료·복귀, pending 재개 | native/인증/storage 관련 변경, 릴리스 필수 |
| 실제 Android/WebView | 동일 핵심 목표와 뒤로가기·앱 링크·키보드·종료 복귀 | 동일 |
| HTTPS 웹 + 실제 SW | 문서 캐시 후 offline 재진입, pending 중 SW 업데이트, 새/옛 bundle 공존 | SW/build/storage 관련 변경, 정기/릴리스 |
WebKit 자동화는 실제 WKWebView의 대체 증거가 아니다. 뷰포트에서 버튼이 화면 안에 있다는 것과 가상키보드가 열린 상태로 버튼을 누르고 저장할 수 있다는 것도 다르다. 지원하는 최소/대표 OS 조합 중 자동화하지 못한 필수 항목은 같은 후보를 대상으로 실행한 수동 증거로 남기며 미실행을 pass로 쓰지 않는다.
접근성은 핵심 경로의 키보드 전용 조작, 초점 이동·복귀, 입력 label·오류 연결, 확대 후 조작, 로딩/저장 안내 전달을 검사한다. 자동 규칙 검사는 보조로 쓰고, 지원 플랫폼의 실제 보조 기술 확인과 시각 검토를 U06 증거로 연결한다.
10. 실행 순서와 작은 PR 단위
기존 프로그램의 단계 순서를 유지한다. 아래 의존성이 풀린 작업만 시작하며, 같은 선행 단계 안에서 담당 파일이 독립적인 작업에 한해 병렬화한다. 기간은 최신 CASE 재사용 범위·장애 주입 준비·실기기 가용성을 M0에서 확인한 뒤 산정한다.
| 묶음 | 작업·권장 PR 단위 | 완료 증거 | 연결 |
|---|---|---|---|
| M0 범위·기준 확정 | 최신 inventory/계약/CASE-039 대조, 요구사항·기존 시스템 처리 장부, 후보 환경, 기존 G04+UX/CI 예산 연결 | 모든 UX·CASE·번호 밖 검사에 담당/처리 방향/필수 집합 지정. 현재 통과/미실행/공백 구분. 새 시간 기준 고정 | G02/G04/G05 |
| M1 검사 신뢰성·기존 구조 정비 | 오류 감시기·skip·CASE-011 수리, 선택 실행·집계, 공통 helper/config/cleanup/날짜/결과 규격 보강 | 재현 결함 차단, 정상 대조군 통과, 거짓 성공 없음, 기존 CASE 의미·격리 보존. 세부 정리 순서는 정비 계획 적용 | G02/G05·CI 담당 |
| M2 핵심 정상 UX | 기존 정상 CASE를 계약별 진입점과 묶고 smoke 구성, 화면→DB→reload 단언 보완 | UX-01–05 및 핵심 신원 경계의 대표 흐름을 실제 stack에서 확인 | G05/U06 |
| M3 보존·복구 | ① commit 후 응답 유실 ② pending/sending 재시작 ③ A→B→A/만료 ④ 영구 거절·동시성·late ACK | D-01–08의 적용 필수 조합 통과, 입력·owner·ID·revision·queue·화면 수렴 증거 | 저장/인증 담당·R02 |
| M4 전체 제공 기능 UX | profile/social/group/catalog/import/admin/export의 누락 보완, 상태·접근성 검사 | G05 기능 목록 전부에 담당 증거. loading/empty/stale/error/pending/confirmed 확인 | U06/I01 및 각 기능 담당 |
| M5 성능·플랫폼·호환 | G04 측정기 확장, 실제 인입 부하, WebKit/HTTPS/SW/실기기, 실제 구·신 bundle/IDB 조합 | UX 시간+기존 예산 통과, 지원 조합별 기능 증거, D-09, 실기기 필수 미확인 0 | G04/U06/R02/R04 |
| M6 staging 출시 리허설 | populated 이전 DB 이관, 중단/재개·선택 복원, 후보 전체 검증·rollback/forward-fix 확인 | D-10, R03 실복원·RPO/RTO 증거, 정확한 후보별 필수 결과 묶음 | R03/R05 |
| M7 배포 후 검증 | 실제 배포 식별·허용된 smoke·정해진 관찰 구간, 발견 회귀의 수정/회귀 편입 | 후보와 운영 증거 연결, 관찰 결과·미해결 항목 장부 마감 | R06 |
의존 관계는 M0 → M1 → M2 → M3, 이어서 해당 선행 구현이 준비된 M4·M5, 이들 증거가 모이면 M6 → M7이다. M4/M5가 기존 v0.18.0 담당 구현을 선행해서 대체하는 것은 아니다. 각 PR은 바뀐 동작·요구사항·실행 레인·검증 증거·성능/runner 영향을 설명한다.
첫 구현 묶음은 M0/M1과 M2의 기존 핵심 CASE 연결부터 시작한다. 다음 묶음은 M3의 응답 유실·재시작·신원 전환 세 경계다. 이것이 통과하면 “핵심 저장의 주요 회귀 방어선 구축”으로 보고한다. 전체 제공 기능·체감 성능·실기기·배포 검증까지 완료했다고 보고하지 않는다.
11. 릴리스 중단 조건과 증거 묶음
다음 중 하나라도 있으면 해당 후보를 출시 검증 완료로 판정하지 않는다.
- 필수 요구사항/환경의 실패·미실행·flaky·출처 불명 증거.
- 원본 유실, 중복 canonical 반영, 타 owner 노출, 핵심 흐름 차단에 해당하는 열린 결함.
- 예상되지 않은 사용자 오류, 예상 오류의 복구 계약 실패, 입력 소실이나 끝나지 않는 잠금 상태.
- 기존 성능/추세/회복 예산 또는 확정한 UX 시간 예산 초과. 필수 지표 미측정.
- populated 이전 데이터의 migration·공존·복원 증거 부재, 필요한 배포 단계 skip, 검증 후보와 실제 산출물 불일치.
복구 시험에서 실제 사본을 격리 DB로 복원하고 원본·관계·projection 결과를 확인한다. 사본 파일이 있다는 사실을 복구 성공으로 세지 않는다. RPO는 사본 최신성으로, RTO는 복원 시작→원본 복원→통계 반영 시각으로 보고한다. 아직 측정하지 않은 RTO는 숫자 0이나 무손실 복구로 표현하지 않는다.
릴리스별로 한 장의 인덱스와 기계 판독 결과를 묶는다.
| 증거 | 반드시 포함할 내용 |
|---|---|
| 후보 식별 | source/head 또는 merge SHA, 실제 web/admin asset·native build, DB migration/schema, Edge 함수 버전, 테스트 코드·계약 버전 |
| 실행 환경 | URL/환경, 브라우저·OS·기기, fixture seed·데이터량, 부하·네트워크·CPU 조건 |
| 커버리지 | 사전 필수 요구 목록, 실제 수집/실행/통과 목록, 미실행·제외 사유, 관련 CASE와 담당 |
| 결과 | 첫 실행 결과·flaky, trace·정제 로그, UI/원본/이력/투영 단언, latency 분포·표본 수 |
| 배포·복구 | DB→함수→frontend→smoke의 실제 단계 결과, populated 이관, 지원 공존/복원, rollback 가능 버전·중단 조건 |
| 운영 확인 | 배포 직후 결과, 관찰 기간, 지표별 비교, 남은 제한과 후속 책임 |
배포가 후속 main으로 교체됐다면 새 산출물에 대응하는 증거를 만들거나, 영향 분석으로 재사용 가능한 증거를 명시하고 영향받는 검사를 다시 실행한다. 단순히 “나중 main도 초록”이라는 이유로 다른 후보의 결과를 같은 결과로 합치지 않는다.
배포 후 관찰은 G04 정본의 7일·일 1회 읽기 전용 프로브 계획과 연결한다. 해당 도구가 실제 관측하는 지표만 그 증거로 사용하고, 함수별 서버 p95나 실기기 시간을 제공하지 않으면 별도 측정/미측정으로 남긴다. 제품 오류·저장 지연·queue age·stale/freshness·job 실패·사본 유효성을 후보와 연결한다. 데이터 손실·신원 노출 같은 중대한 오류는 7일 집계를 기다리지 않고 즉시 대응한다. 일반 성능 회귀는 G04의 정해진 판정 규칙으로 처리한다.
회귀가 발생하면 실패 시나리오를 보존하고 담당 기능을 수정한 뒤 같은 단언과 영향 범위를 다시 통과시킨다. 광범위 오류 무시, 재시도 증가, 요구사항 삭제, 임계값 완화로 초록을 만들지 않는다. 릴리스 범위를 조정했다면 지원 범위와 출시 문구도 함께 바뀌어야 한다.
12. 완료 시 남길 산출물
- G05와 연결된 핵심 UX 요구사항·CASE·환경·담당 장부.
- 검출기 수리와 정상 대조군, 강화한 기존 CASE 및 새 보존·복구 CASE.
- PR 선택 실행·필수 집계·정기 전체·릴리스 후보 검증 설정과 실제 시간/runner 비교.
- G04 정본을 재사용한 UX 시간·성능/혼합 부하·회복 보고서.
- 실제 지원 플랫폼·provider·SW·버전 호환 검증 결과.
- 고정 후보의 staging·migration·실제 복원·배포 후 관찰 증거 묶음과 남은 한계.
- 기존 시스템 전수 처리 장부의 최종 결과, 통합/퇴역 전후 요구사항 대조, 보존한 사고 증거와 시간·runner 비용 비교.
최종 완료는 M1–M3의 테스트가 추가됐다는 사실이 아니라, 출시 후보에 요구된 기능·복구·성능·환경·배포 증거가 모두 모였을 때 선언한다. 이 문서는 그 실행 기준이며, 이번 작성으로 구현·이슈/PR 생성·머지·배포를 수행한 것은 아니다.
13. 기존 E2E 정비를 포함한 완료 조건
정비 계획의 ‘후보’를 단순히 나열한 것으로 완료하지 않는다. 실제 실행 때 각 항목의 유지·수리·보완·공통화·이동·퇴역 결론과 증거를 남긴다.
- 먼저 수리: 오류 검출 누락, 첫 동작의 실패를 가리는 단언, 필요한 검사의 미실행/결과 누락.
- 함께 통합: 반복된 인증 관측·데이터 준비·편집/계획/보드 도구, config·cleanup·결과 형식. 서로 다른 사용자 계약과 mutable 계정/저장소는 분리 유지.
- 역할 정리: 번호 CASE와 DB/API 검사의 중복, viewport 기하와 기능 검증의 차이, 수동 profile과 릴리스 성능 검사의 차이.
- 조건부 퇴역: 오래된 skip 블록·대체된 API 조합·중복 문서 입력·의미 없는 대기·지원 종료 fixture. 필수 요구사항과 과거 회귀 증거를 대체/보존한 뒤 제거.
- 운영 정비: legacy bundle 출처/캐시 검증, 날짜 결정성, 문서와 실행 프로필의 정합, 로컬/CI 단계와 필수 결과 연결, 실제 shard 비용 최적화.
합친 뒤에도 생성/수정/삭제, warm/cold 인증, 전체/부분 계획 완료, 원 보드/멤버 운동, 원본/투영의 고유 검증은 유지한다. 최종 릴리스 검증 전에 기존 시스템 처리 장부와 신규 UX 요구사항 장부를 함께 대조해 필수 누락이 없음을 확인한다.