[test-84/e2e] E2E 테스트 안정화 및 회귀 수정

[hm1n]

Summary

같은 커밋으로 CI를 반복 실행해 E2E 테스트 16건의 실패율을 측정하고, 흔들리는 케이스를 잡습니다.
구현 설계서 E2E 테스트 도입 구현 설계 v2의 Task 8에 해당합니다.
재시도 설정을 어떻게 둘지도 이 측정 결과를 근거로 확정합니다.

---

Why

해결하려는 문제가 무엇인가요?

안정적으로 통과한다고 말할 근거가 부족합니다.

#209에서 16건이 통과했지만 CI 실행 횟수는 두 번뿐입니다. 낮은 확률로만 재현되는 문제는 이 정도 표본에서 드러나지 않습니다. 실제로 테스트 계정의 tag 충돌은 실행당 약 3% 확률이었고 다섯 번째 실행에서야 처음 나타났습니다.

재시도가 간헐 실패를 덮고 있을 수 있습니다.

현재 CI는 retries: 2로 설정되어 있어, 첫 시도가 실패해도 재시도가 성공하면 결과는 초록으로 끝납니다. 지금 상태로는 흔들리는 케이스가 있는지 없는지를 결과만 보고 판단할 수 없습니다.

케이스를 늘리기 전에 확인해야 합니다.

P1 35건을 구현하면 실행 케이스가 세 배가 됩니다. 지금 있는 16건이 흔들리는 상태라면 그 흔들림도 함께 커지고, 원인을 나중에 분리하기가 더 어려워집니다.

---

Goal

완료되면 무엇이 달라지나요?

이번 작업의 목표

• 같은 커밋에서의 실패율을 수치로 알 수 있습니다.
• 흔들리는 케이스가 있다면 원인이 제품, 테스트, 실행 환경 중 어디인지 구분되어 있습니다.
• 재시도 횟수가 측정 결과를 근거로 정해져 있습니다.
• 실행 환경 차이로만 실패하는 케이스가 남아 있지 않습니다.

이번 작업에서 해결하지 않는 범위 (Non-goal)

• P1 이하 테스트 케이스 구현은 포함하지 않습니다.
• service role key 의존 제거([test-81/e2e] E2E 테스트의 service role key 의존 제거 #212)는 포함하지 않습니다.
• 실행 시간 추가 최적화는 목표가 아닙니다. 흔들림을 없애는 것이 우선이고, 워커 수 조정은 그 과정에서 필요할 때만 다룹니다.

---

Approach

어떻게 해결할 계획인가요?

전체 구현 방향

재시도를 끈 상태로 같은 커밋에서 CI를 여러 번 실행해 실패율을 먼저 측정합니다. 실패가 나오면 그 케이스만 따로 반복해 원인을 좁힙니다.

주요 변경 사항

• 측정 기간 동안 retries를 0으로 두고 워크플로를 반복 실행합니다. workflow_dispatch 트리거를 임시로 추가하면 PR 없이 돌릴 수 있습니다.
• 실행 결과를 기록해 케이스별 실패율을 정리합니다.
• 실패한 케이스는 trace를 확인해 원인을 제품, 테스트 코드, 실행 환경으로 분류합니다.
• 분류 결과에 따라 타임아웃, 대기 조건, 데이터 준비 방식을 고칩니다.
• 측정이 끝나면 retries 최종값을 정하고 근거를 커밋 메시지에 남깁니다.

검토한 대안과 선택 이유

재시도를 켠 채로 실행 횟수만 늘리는 방법도 있습니다. 그러나 재시도가 성공하면 결과가 초록으로 끝나므로, 흔들림이 있는지 자체를 알 수 없습니다. 측정 기간에는 재시도를 꺼야 데이터가 나옵니다.

로컬에서만 반복 실행하는 방법도 검토했습니다. 그러나 #209에서 확인했듯이 실행 환경에 따라 결과가 달라지므로, CI 환경에서 측정해야 의미가 있습니다.

---

Tasks

• 측정용 workflow_dispatch 트리거 추가와 retries: 0 적용 — workflow_dispatch는 default branch에 트리거가 있어야 동작해 develop을 건드리게 되므로, 대신 PR 실행을 gh run rerun으로 반복했습니다. 커밋 SHA가 고정되어 "같은 커밋" 조건은 그대로 만족합니다.
• 같은 커밋으로 CI 10회 이상 실행하고 결과 기록 — 49c01fb으로 20회 실행
• 케이스별 실패율 정리 — 케이스 실행 320회 중 실패 1회(0.31%), 실행 단위 20회 중 1회(5.0%)
• 실패 케이스의 trace 확인 및 원인 분류 (제품 / 테스트 / 환경) — 환경. auth.spec.ts:23에서 seeder가 PostgREST를 호출할 때 PGRST303 JWT issued at future. 토큰 발급과 검증이 모두 Supabase 쪽이라 우리 코드가 시각에 관여하지 않습니다. 전체 재실행이 이전 attempt의 아티팩트를 지워 trace는 남지 않아, job 로그를 근거로 했습니다.
• 분류 결과에 따른 수정 — 코드 수정 없음. 320회 중 1회이고 재현되지 않으며 원인이 Supabase 쪽이라, seeder 재시도 대신 retries로 흡수하기로 했습니다. 재시도로 통과한 건은 flaky로 집계되므로 재발 관측은 계속됩니다.
• retries 최종값 결정 — process.env.CI ? 1 : 0
• 측정용 임시 설정 정리 — retries: 0, json reporter, 산출물 업로드 if: always() 모두 원복
• main 대상 PR에서 PC 뷰포트 matrix가 의도대로 분기하는지 확인 — base가 develop인 PR에서는 mobile 단일로 분기하므로 확인할 수 없습니다. 다음 릴리즈 PR에서 봐야 합니다.
• 실패 시 산출물 업로드가 실제로 동작하는지 확인 — attempt 19(실패)와 attempt 20(성공) 모두에서 업로드 동작 확인

---

Constraints

반드시 유지해야 하는 동작

• 기존 16건의 검증 내용은 바뀌지 않아야 합니다. 흔들림을 없애려고 검증을 느슨하게 만들지 않습니다.
• 실행 후 개발 DB에 잔여 데이터가 남지 않아야 합니다.
• 로컬 실행 방식은 그대로 유지되어야 합니다.

변경하면 안 되는 사항

• Secret과 .env 파일은 커밋하지 않습니다.
• service role key는 브라우저로 전달되는 코드에 포함되면 안 됩니다.
• 측정용 임시 설정을 develop에 남기지 않습니다.

기술적 제약사항

• 반복 실행은 테스트 계정 생성과 로그인 호출을 함께 늘립니다. 인증 요청 제한에 걸리는지 함께 확인해야 합니다.
• pull_request 이벤트는 충돌이 있는 PR에서 실행되지 않으므로, 측정 중에는 브랜치를 최신 상태로 유지해야 합니다.

---

Definition of Done

• 재시도 없이 실행한 CI의 실패율이 수치로 정리됨 — [test-84/e2e] E2E 테스트 안정화 및 회귀 수정 #216 본문에 케이스별 표
• 남아 있는 흔들림의 원인이 분류되고 조치되었거나 근거와 함께 남겨짐 — 환경으로 분류하고 retries로 흡수, 근거는 [test-84/e2e] E2E 테스트 안정화 및 회귀 수정 #216 본문
• retries 값이 측정 결과를 근거로 확정됨
• PC 뷰포트 matrix와 산출물 업로드가 실제 실행으로 확인됨 — 산출물 업로드는 확인 완료. PC 뷰포트 matrix는 main 대상 PR에서만 분기하므로 다음 릴리즈 PR에서 확인
• npm run lint 통과
• npm run build 통과 — 로컬 워크트리에는 .env.local이 없어 prerender 단계에서 막히므로, CI 워크플로의 Build 단계로 확인했습니다 (run 33708181090)

---

확인 필요

• 반복 실행 횟수가 미정입니다. 3% 수준의 확률을 잡으려면 10회로는 부족할 수 있습니다. 러너 사용량과의 균형을 보고 정해야 합니다.
• 인증 요청 제한값을 아직 확인하지 않았습니다. Supabase 대시보드의 Authentication 항목에서 확인한 뒤 반복 실행 간격을 정하는 것이 안전합니다.
• 흔들림이 없을 경우의 처리 방향이 미정입니다. 측정 결과가 깨끗하면 retries를 0으로 둘지, 러너 자체의 일시적 문제에 대비해 1을 남길지 판단이 필요합니다.