E2E 전면 정비 계획 — CASE 39개에서 핵심 UX·복구·성능·출시 증거까지 (2026-09-07)
계획 문서화 완료 · 테스트 구현 전. 현재 번호 CASE는 39개다. 기존 CASE를 정비하면서 핵심 보강 8개, 전체 기능/환경 대표 여정 10개를 추가하는 약 57개를 계획 기준으로 잡았다. 확정된 최종 수나 구현 완료 수가 아니다.
- 기간: 2026-09-07 계획 정리·저장소 문서화. 사용자 요청: “기존 e2e 시스템 중에서도 문제있거나 없어도 되거나 보완하면 좋을거, 합치면 좋을거”를 모두 포함하고, 예상 산출물과 CASE 수를 명시한다.
- 랜딩: 이 문서 작성 시 미수행. 문서 변경만 있으며 앱·테스트·CI·DB·Edge·staging/Production 배포 변경은 없다. 날짜는 이번 계획의 문서화일이고 구현 트랙 랜딩일은 추후 기록한다.
- 설계서: E2E 마스터플랜, 기존 E2E 시스템 정비 계획. 외부 artifact에 의존하지 않고 저장소에서 전체 내용을 읽을 수 있다.
- 정본: 예상 산출물·CASE 증감은 이 문서 §5, 실행/출시 기준은 마스터플랜, 기존 39 CASE·공통 시스템 19항목의 처리는 정비 계획. 현행 제품 계약과 v0.18.0 총괄의 선행/소유권을 유지한다.
- 도구: 현재는 문서와 inventory 대조만 수행. 기존 G02 fixture/oracle, G04 측정기, G05 장부, error-case registry/fixture를 구현 단계에서 재사용한다.
- 게이트: 문서 링크·목록/산식·사이트 빌드를 검증한다. 테스트·workflow·migration 변경이 없어 이번 문서화에서 앱 E2E·pgTAP을 새로 실행한 결과는 없다.
- 버그리포트: 이 문서화에서 새 제품 버그리포트를 발행하지 않았다. 이전 감시기 재현과 소스 근거는 정비 계획에 연결했다.
- 계약: 사용자 경험·저장 충돌 정책·성능 상한을 이 문서로 변경하지 않는다. 새 UX 시간 목표와 CASE 수는 명시된 제안이며 실제 수용 조건은 M0에서 고정한다.
Phase 현황
아래는 E2E 작업 묶음이다. v0.18.0 전체 Phase 번호와 혼동하지 않는다.
| Phase | 마스터플랜 연결 | 내용 | 상태 |
|---|---|---|---|
| Phase 0 | M0 | 기존/신규 요구사항·처리 장부·환경·UX/CI 예산 확정 | 계획 문서화 완료, 구현 시 최신 기준 고정 필요 |
| Phase 1 | M1 | 오류 감시·단언·skip·실행 누락 수리, 공통 구조 정비 | 계획 |
| Phase 2 | M2 | 핵심 정상 여정과 PR smoke 구성 | 계획 |
| Phase 3 | M3 | 응답 유실·재시작·인증/owner·동시성·실패 복구 | 계획 |
| Phase 4 | M4 | 실제 제공 기능의 누락·접근성 보완 | 계획 |
| Phase 5 | M5 | 성능·WebKit/실기기·HTTPS/SW·구신 버전 호환 | 계획 |
| Phase 6 | M6 | staging 후보·populated 이관·실제 복원 리허설 | 계획 |
| Phase 7 | M7 | 배포 후 smoke·관찰·증거 마감 | 계획 |
1. 배경
CI 대기 시간을 줄이는 작업 이후, 사용자는 E2E가 사용자 핵심 UX와 예상치 못한 오류를 충분히 보호하는지 검토를 요청했다. 정상 흐름이 성공하는 것과 실패 시 입력이 보존되고 다음 행동이 가능한 것, 실제 기기에서 충분히 빠른 것은 별도 증거가 필요하다.
기존 상세 감사는 16b8e996를 기준으로 했고, 정비 대상 대조는 07c04f371b19c300524f2a404ababd26b3962609까지 반영했다. 이번 문서화의 base 48f249c2e276159fb7134f774eb37b71f171ce41에서도 manifest 39개를 확인했다. 최신 base 전체를 새로 실행·재감사한 결과는 아니다.
기존 39개는 사고 회귀와 사전에 고른 기대 행동을 함께 보호한다. 이 안의 CASE-003은 공급자 성공을 가정한 별도 경계이고, CASE-039는 구형/신형 탭의 pending 행 공존을 다룬다. Node DB 검사, viewport 검사, 독립 IDB/mirror 검사와 성능 측정은 번호 CASE와 다른 집합이다.
2. 문제 제기
좋은 개별 CASE가 있어도 전체 핵심 UX의 빈틈을 판정할 분모가 부족하다
현재 강점인 운동 저장·수정·원본/DB 재조회는 유지한다. 여기에 로그인·계획·그룹·소셜·프로필·인입 등 사용자 목표 12개와 실패/복구 경계 10개를 요구사항 장부로 연결해야 한다. 번호 CASE 수를 코드 커버리지나 출시 확신의 수치로 대신하지 않는다.
검사가 실패를 놓치거나 필요한 변경에서 실행되지 않을 수 있다
지연 텍스트 오류 감시 누락, CASE-011의 첫 폐기를 두 번째 폐기로 보완하는 단언, 오래된 영구 skip, source/API 변경의 E2E 실행 공백을 우선 정비 대상으로 잡았다. 이후 해결된 CASE-039 RPC drain·독립 mirror 검증은 재사용한다.
반복 코드와 다른 실행 경계가 섞이면 유지 비용과 통과 의미가 불명확해진다
인증 관측·편집/계획/보드 준비, config·cleanup·기하 측정의 공통화를 검토한다. 반대로 생성/수정/삭제, warm/cold 부팅, 전체/부분 계획 완료는 별도 계약이라 합쳐서 제거하지 않는다. 실제 provider·실기기·배포 증거도 local Chromium 결과와 구분한다.
3. 해결 방안
범위와 원칙
| 구분 | 결정/전제 |
|---|---|
| 사용자 지시 | 핵심 UX의 정상·오류 복구·성능·실기기·배포 후 확인을 포함한다 |
| 사용자 지시 | 기존 시스템의 문제·보완·통합·불필요한 부분 정리까지 포함한다 |
| 이번 사용자 지시 | 저장소 updates에 문서화하고 예상 산출물과 CASE 수를 명시한다 |
| 계획 제안 | 기존 39개 유지 + 신규 대표 여정 18개 = 약 57개. 최종 수와 새 CASE 번호는 구현 시 확정한다 |
| 검증 원칙 | 먼저 거짓 성공을 차단하고, 대체 증거를 확보한 뒤 중복만 제거한다 |
| 제품 계약 | LG409/40001은 현행 나중 저장 우선·무음 재전송 정책을 검증한다. 모든 충돌에 안내창을 요구하지 않는다 |
| 기존 프로그램 연결 | G02/G04/G05/U06/R02–R06 및 기능 담당 작업에 연결한다. 새 프로그램이나 기존 Phase를 건너뛰는 일정은 만들지 않는다 |
접근
| 방법 | 적용 |
|---|---|
| 요구사항을 기준으로 기존 CASE 재사용·부족한 여정 보완 | 채택. 검증의 의미를 보존하면서 빈틈을 메운다 |
| setup/관측/정리 도구 공통화·적절한 계층으로 재배치 | 채택. mutable 계정/저장소 공유 없이 반복 비용을 줄인다 |
| 파일 수를 줄이기 위한 CASE 일괄 병합/삭제 | 적용하지 않음. 독립 사고·경계·실패 증거를 잃을 수 있다 |
| 모든 PR에서 모든 CASE × 모든 플랫폼 실행 | 적용하지 않음. PR 핵심+영향 범위, 정기 전체, 후보 전체/실기기로 나눈다 |
상세 요구사항·보존 행렬·CI 실행·플랫폼·시간 예산·출시 기준은 마스터플랜에, 39 CASE별 처리·공통 시스템 19항목·번호 밖 검사·퇴역 조건은 정비 계획에 있다.
4. 적용한 내용
이번 문서화
docs/updates/2026-09-07-e2e-master-plan.md: 전체 작업 기록, 예상 산출물, CASE 증감 산식과 신규 후보.docs/testing/e2e-master-plan.md: 요구사항·정상/복구·성능·플랫폼·CI·출시 증거의 상세 실행 계획.docs/testing/e2e-system-renovation-plan.md: 기존 CASE 39개, 공통 시스템 19개 정비 항목과 통합/퇴역 기준.docs/README.md,docs/.vitepress/config.mts: 문서 인덱스와 사이드바 등록.
주요 결정과 근거
정비는 새 테스트를 모두 만든 뒤의 후속 청소가 아니다. M1의 감시기·실행 누락 수리부터 시작하고, M2/M3의 여정을 추가하며 필요한 도구를 공통화한다. CASE-036의 구 RPC 조합 같은 계층 이동 후보는 대체 DB/API 검증과 실제 거절 UX를 연결한 뒤 중복 실행을 줄인다.
작업 중 드러난 것
저장소의 기존 폴더명은 docs/updates/다. 사용자 요청에 따라 구현 완료 전의 계획을 기록하므로 일반 작업 완료 기록과 구분해 상태·랜딩·미실행 항목을 명시했다. 신규 CASE ID를 예약하지 않으며 다른 작업의 CASE 추가를 덮지 않는다.
5. 적용 결과와 예상 산출물
5.1 이번 결과와 구현 후 결과의 구분
| 항목 | 이번 문서화 결과 | 구현 완료 때 필요한 결과 |
|---|---|---|
| 번호 CASE | 기존 39개, 실제 증감 0 | 아래 신규 18개 후보와 기존 보완을 반영한 약 57개 |
| 기존 CASE 정비 | 39개 전부 처리 계획 존재 | 항목별 유지/수리/공통화/이동/퇴역 결론과 실제 증거 |
| 공통 시스템 | 19개 정비 항목 정의 | 검출·준비·cleanup·실행/보고·캐시·문서 등의 해당 개선 |
| 테스트/CI 실행 | 이번 문서화에서는 앱 E2E 미실행 | 필요한 head/환경의 실제 결과와 누락/실패/취소 판정 |
| 성능·시간 단축 | 새 개선 수치 미측정 | G04+UX 예산, CI wall time·p95·runner 비용 비교 |
| staging/실기기/운영 | 이번 문서화에서 확인하지 않음 | 후보와 일치하는 실제 실행·배포·관찰 증거 |
5.2 최종적으로 남길 산출물
| 산출물 | 예상 형태·위치 | 수용 기준 |
|---|---|---|
| 요구사항/커버리지 장부 | G05와 연결된 사용자 목표 12개·복구 경계 10개, 세부 requirement→CASE/하위 검사/환경/담당 매핑 | 사전 필수 집합에 미배정·미실행을 숨기지 않음 |
| 정비된 기존 E2E | error-cases/ 39개와 e2e/, 공통 fixture/정책/도구 | 기존 사고·고유 경계 보존, 거짓 성공 수리, 통합/퇴역 대체 증거 |
| 신규 대표 여정 | 현재 예상 신규 CASE 패키지 18개, 환경/입력 변형은 각 패키지에 명시 | UI→실제 상태/DB→복구/재조회의 해당 경계 검증 |
| 하위 행동/DB 검사 | 기존 tests/, DB 검사·fixture/oracle의 필요한 보강 | UI와 무관한 많은 조합은 빠른 계층에서 검증, 핵심 full-stack 연결 유지 |
| CI 실행/완료 체계 | scope/discovery·필수 집계·PR/정기/후보 레인·로컬과 원격 동기화 | 선택된 검사의 누락·skip·flaky·환경 부재를 통과 처리하지 않음 |
| 성능·플랫폼 증거 | G04 schema와 연결된 시간 분포·부하·WebKit·실기기·SW/버전 matrix | 측정 조건·실제 후보·표본 수·미측정 범위 명시 |
| 릴리스 증거 묶음 | 후보별 인덱스/구조 결과, staging 이관·사본 복원·smoke·관찰 보고 | 필수 UX/환경/성능 검증과 실제 배포 산출물 일치 |
| 유지보수 자료 | 생성 가능한 메타데이터, CASE 이관/퇴역 링크, 실패 진단·재현 방법 | 다음 담당자가 기존 사고와 대체 검증을 추적 가능 |
하위 테스트·viewport·실기기 조합·부하 측정의 개수는 아직 산정하지 않았다. 이들을 합산해 “57 CASE”를 부풀리거나, 해당 검증이 없어도 57개만 채우면 완료라고 판단하지 않는다.
5.3 CASE 수: 39 → 47 → 약 57
집계 단위는 error-cases/CASE-###-slug/case.json 한 개를 가진 번호 패키지다. Playwright test/variant 수, 브라우저 프로젝트 수, checkpoint/assert 수와 다르다.
| 시점 | 기존 유지 | 신규 누적 | 전체 퇴역 계획 | 예상 번호 CASE |
|---|---|---|---|---|
| 현재/이번 문서화 | 39 | 0 | 0 | 39 |
| 기존 시스템 수리·공통화 | 39 | 0 | 0 | 39 |
| 핵심 보강 8개 완료 | 39 | 8 | 0 | 47 |
| 전체 대표 여정 보강 | 39 | 18 | 0 | 약 57 |
기본 산식은 39 + 8 + 10 − 0 = 57이다. 아직 전체 퇴역을 확정한 기존 CASE는 없다. helper 통합·skip 블록 정리·API 조합 이동은 번호 CASE 전체를 없애는 것과 다르므로 임의 감산하지 않는다.
아래 NEW-*는 계획 후보 식별자이며 실제 CASE 번호가 아니다. 한 패키지가 복수 입력/동작/환경 변형을 가질 수 있고 각 변형의 결과는 따로 추적한다. 최종 배정은 M0의 요구사항 분해에서 결정한다.
| 후보 | 단계 | 새 대표 여정과 관측 경계 | 기존 CASE와의 관계 |
|---|---|---|---|
| NEW-01 | 핵심 +1 | IDB 적재 실패→저장 성공 오표시 없이 입력 유지·복구 | mirror 정상 복구와 다른 적재 실패 경계 |
| NEW-02 | 핵심 +1 | 실제 서버 commit→응답 유실→같은 요청 재전송→중복 없는 확정 | 015/029의 서버 도착 전 503과 구분 |
| NEW-03 | 핵심 +1 | pending/sending 도중 종료→같은 기기 저장소로 재진입→자동 전송 | queue 비운 뒤 reload와 구분 |
| NEW-04 | 핵심 +1 | 실제 세션 만료→held→같은 계정 재로그인→보관 기록 재개 | 013의 갱신 직후 일시 401 storm과 구분 |
| NEW-05 | 핵심 +1 | A 미전송 상태→B 로그인→A 재로그인, 화면/IDB/서버 소유권 격리 | 동일 owner 복구 사례에 흡수하지 않음 |
| NEW-06 | 핵심 +1 | 다중 탭/기기·수정 중 재수정/삭제·늦은 ACK에서 최신 의도 수렴 | 039의 구신 bundle 공존과 다른 동시 의도 경계 |
| NEW-07 | 핵심 +1 | 영구 저장 거절→blocked→규정된 사용자 복구와 입력 보존 | LG426 안내는 기존 036 보완, 일반 영구 거절을 별도 추적 |
| NEW-08 | 핵심 +1 | 저장 후 read-model 지연/조회 오류/응답 역전→정확한 최신 화면 | 004/037의 정상 갱신·초기 이름 표시를 유지하면서 실패 경계 보강 |
| NEW-09 | 전체 +1 | HTTPS/SW의 실제 offline 재진입·미전송 중 앱 갱신·복귀 | 503 주입이나 lazy chunk 복구만으로 대체하지 않음 |
| NEW-10 | 전체 +1 | 실제 지원 provider의 취소/실패·재시도·웹/native callback 복귀 | 003의 provider 성공 가정과 분리 |
| NEW-11 | 전체 +1 | 프로필 이름/아이디/사진 수정 실패→입력 유지→재시도 | 온보딩 009와 다른 기존 계정 편집 여정 |
| NEW-12 | 전체 +1 | 지원 계정 연결/해제의 취소·실패·재진입과 신원 유지 | 로그인 진입/단순 로그아웃과 다른 목표 |
| NEW-13 | 전체 +1 | 좋아요·댓글·관계 변경의 실제 UI 왕복 및 낙관적 반영 실패 복구 | 018의 신고/차단/관리자 처리와 구분 |
| NEW-14 | 전체 +1 | 실제 그룹 초대/참여 UI·권한 회수 후 열린 화면 정리 | 035의 RPC 초대 fixture와 운동 계보 검사는 유지 |
| NEW-15 | 전체 +1 | 종목 검색/관리 UI의 IME·조회 순서 역전·실패/복귀 | 001/031 생성, 038 delta 동기화와 구분. archive/restore 변형은 지원 경로 기준 |
| NEW-16 | 전체 +1 | 실제 Wodup 인입 UI→job→원본/조회, 실패·재업로드 | 저장 RPC 연속 호출의 부하 근사로 대체하지 않음 |
| NEW-17 | 전체 +1 | 실제 Motra 인입 UI→job→원본/조회, 중복/부분 실패 | parser·준비 경로가 다른 인입 경계. I01의 지원 목록과 대조 |
| NEW-18 | 전체 +1 | 내보내기 UI→실제 다운로드→원본/ID/값 대조와 실패 복구 | 계정 storage 파기나 import 성공으로 대체하지 않음 |
다음은 기존 CASE 안의 보완 또는 별도 레인으로 예상하여 위 신규 18개에 중복 가산하지 않았다.
- 온보딩 실패: 009, 계획 저장/전환 실패: 016/025/034, 계정 삭제 부분 실패: 017, 관리자/금칙어 역할 정리: 018, 업데이트 필요 UI: 036.
- 기존 CASE의 키보드/접근성·WebKit/실기기 변형, viewport 검사, 감시기 자체 행동 테스트, populated migration/복원·성능/부하 측정.
- 지원 목록에서 추가로 확인되는 인입/계정/provider 경로는 별도 평가한다. 예를 들어 I01의 다른 인입 경로가 기존 검사나 위 후보의 변형으로 충분히 검증되지 않으면 신규 CASE가 더 필요하다.
57은 현재 대표 여정 설계에 따른 예상 기준이며 최소/최대 상한이 아니다. NEW 후보를 기존 CASE 보완으로 흡수하거나 독립된 사용자 경계로 분리하면 달라진다. 구현 시작 전 최신 기존 수를 N으로 다시 고정하고 N + 확정 신규 − 증거를 갖춘 전체 퇴역으로 갱신한다. 개수 변경 사유와 요구사항 대체 위치를 함께 적으며, 57을 맞추려고 의미를 합치거나 빼지 않는다.
6. 예상 효과와 개선사항
| 기대 효과 | 구현 후 확인 방법 | 현재 상태 |
|---|---|---|
| 핵심 UX의 빈틈이 보임 | 요구사항별 정상/실패/복구·환경·증거 매핑 | 계획 작성 |
| 검사 초록의 의미가 명확해짐 | 미수집/미실행/skip/flaky·오류 감시 결함을 잡는 반례 | 구현/실행 전 |
| 회귀는 지키고 반복 유지 비용을 줄임 | 공통화/퇴역 전후 고유 요구사항·실행 비용 비교 | 미측정 |
| CI 대기 시간 관리 | PR 핵심+관련 범위, 정기 전체, 후보 검증의 wall/p95·runner 비교 | 새 레인 미구현 |
| 사용자 체감과 출시 근거를 연결 | UX 시간·실기기·staging·복원·7일 운영 관찰 증거 | 미검증 |
“모든 예상치 못한 오류가 사라진다”는 보장이 아니다. 최종 결과는 명시한 후보·지원 환경·핵심 요구사항에서 기능/보존/복구/성능 기준을 통과했고 필수 미검증 항목이 없다는 증거다.
남은 것
- M0에서 최신 요구사항·기존 CASE·지원 기능·실기기 환경을 대조하고 NEW-01–18의 흡수/분리·실제 CASE 배정을 확정한다.
- 각 정비/보강 작업을 기존 v0.18.0 담당·선행에 연결해 구현하고, 실제 결과로 위 표를 갱신한다.
- 새 UX 시간·CI 목표를 측정 조건과 함께 고정한다. 기존 G04 상한은 이 계획으로 완화하지 않는다.
- 실제 테스트 통과·성능·실기기·배포 증거가 모이기 전에는 이번 문서화 완료를 E2E 개선 완료로 표시하지 않는다.