[test-78/e2e] 인증 및 테스트 데이터 준비 구조 작성

[hm1n]

Summary

Supabase Admin API로 테스트 유저와 세션을 생성해 브라우저에 주입하는 구조를 만듭니다.
이를 통해 실제 Google·Kakao 로그인 없이 인증이 필요한 E2E 테스트를 반복 실행할 수 있게 합니다.
구현 설계서 E2E 테스트 도입 구현 설계 v2의 Task 5에 해당합니다.

---

Why

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

현재 인증이 필요한 테스트를 실행할 방법이 없습니다.

Task 4(#172)에서 Playwright 기본 설정과 랜딩 페이지 스모크 테스트 1건(e2e/landing.spec.ts)까지는 마쳤습니다. 그러나 로그인 이후 화면을 검증할 수단이 없어 그다음 단계로 넘어가지 못하고 있습니다.

지금 해결해야 하는 이유는 다음 작업이 이 구조에 막혀 있기 때문입니다.

테스트 케이스 문서화(Task 1, 2)가 끝나 자동화 대상 135건과 우선순위가 확정된 상태입니다. 이 중 가장 먼저 구현할 P0 15건의 조건은 다음과 같습니다.

• 15건 중 13건이 로그인 상태를 전제로 합니다.
• SETTLE-TOGGLE-004(일반 참여자는 다른 참여자의 납부 상태를 변경할 수 없다)와 GROUP-MEMBER-001(일반 참여자는 그룹을 수정할 수 없다)은 권한이 다른 두 개의 계정이 동시에 필요합니다.
• SETTLE-PERIOD-002(참여자 추가 시 미납 기록이 한 건 생성된다)처럼 DB 상태를 변경하는 케이스가 포함되어 있어, 정리 수단이 없으면 두 번째 실행부터 결과가 달라집니다.

해결하지 않으면 Phase 4(핵심 시나리오 자동화) 전체가 착수되지 않습니다.

E2E 테스트를 도입하려는 목적 자체가 배포 전 핵심 흐름의 회귀를 자동으로 확인하는 것인데, 정산과 그룹 권한이 전부 로그인 이후 영역이라 현재 상태로는 랜딩 페이지 외에는 아무것도 검증할 수 없습니다.

---

Goal

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

이번 작업의 목표

• 세션 주입만으로 로그인 이후 테스트인 그룹, 초대, 정산, 채팅 등을 반복 실행할 수 있습니다.
• 신규 가입과 회원탈퇴 시나리오를 실제 Google, Kakao 로그인 없이 Admin API 기반으로 매 실행마다 독립적으로 검증할 수 있습니다.
• 테스트 실패 후에도 다음 실행에 영향을 주는 사용자 및 관련 데이터가 남지 않습니다.
• 권한이 다른 두 사용자가 등장하는 시나리오를 각각의 BrowserContext로 검증할 수 있습니다.

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

• 실제 Google, Kakao 로그인 화면의 자동화는 하지 않습니다. 설계서 v2에서 폐기한 방식이며, 낮은 빈도의 수동 확인으로 대체합니다. 다만 그 수동 확인 절차를 문서로 남기는 것은 이번 작업에 포함합니다.
• 개별 테스트 케이스 코드 작성은 포함하지 않습니다. Task 6의 범위입니다.
• GitHub Actions 워크플로우 작성은 포함하지 않습니다. Task 7의 범위입니다.
• 테스트 전용 DB나 seed 시스템의 완전한 고도화는 하지 않습니다. 설계서 3장의 제외 범위입니다.

---

Approach

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

전체 구현 방향

Supabase Admin API로 테스트 유저를 생성하고 세션을 발급받은 뒤, 그 세션을 Playwright 브라우저에 주입합니다. 로그인 화면을 거치지 않고 로그인된 상태에서 테스트를 시작하는 방식입니다.

주요 변경 사항

• Supabase Admin API로 테스트 유저를 생성하고 세션을 발급하는 세션 주입 helper를 작성합니다.
• 발급받은 세션을 Playwright storageState 또는 addInitScript, addCookies로 브라우저에 주입하는 구조를 구현합니다.
• service role key는 Node.js 테스트 helper에서만 사용하고 브라우저 코드에는 노출되지 않도록 보호합니다.
• 신규 가입, 회원탈퇴 시나리오는 Admin API로 매 실행마다 새 테스트 유저를 생성하고 삭제하는 방식으로 구현합니다.
• 테스트가 중간에 실패한 경우에도 Supabase Auth 사용자 및 관련 서비스 데이터를 정리할 수 있는 cleanup helper를 작성합니다.
• 초대, 채팅 등 2인 시나리오를 위해 서로 다른 유저의 세션을 각각의 BrowserContext에 주입하는 방식을 정의합니다.
• 실제 Provider 연동 오류를 잡기 위한 낮은 빈도 수동 확인 절차를 별도로 문서화합니다.

검토한 대안과 선택 이유

기존 설계서는 Google, Kakao OAuth 로그인 자체를 각 Provider의 테스트 전용 계정으로 실제 인증 화면과 callback까지 실행해 검증하는 방식이었습니다. 설계서 v2에서 이를 폐기하고 세션 주입으로 바꾼 이유는 다음과 같습니다.

• 소셜 로그인 버튼 클릭 이후의 화면은 Google과 Kakao가 렌더링하는 영역이라 우리 코드가 아니고, 그 화면이 바뀌어 테스트가 깨져도 우리가 고칠 수 있는 부분이 아니라 테스트 가치가 낮습니다.
• 우리 앱이 실제로 처리하는 로직은 로그인 콜백 이후, 즉 세션 확인, 유저 조회, 약관 동의 체크, 리다이렉트 분기입니다. 실제 버그도 대부분 이 구간에서 발생합니다.
• Google과 Kakao 모두 자동화된 브라우저의 로그인 시도를 탐지해 CAPTCHA를 띄우거나 로그인을 차단하는 경우가 많아, CI에서 안정적으로 돌리기 어렵고 반복 시도로 테스트 계정이 잠길 위험도 있었습니다.

이 선택의 트레이드오프

세션 주입은 로그인 이후 로직 검증에는 강하지만, redirect URI 오설정이나 OAuth 클라이언트 설정 오류처럼 실제 Provider 연동 자체가 어긋나는 문제는 잡아내지 못합니다. 이 부분은 CI와 무관하게 낮은 빈도의 수동 확인으로 별도 보완합니다.

---

Tasks

• Supabase Admin API 기반 테스트 유저 생성 및 세션 발급 helper 작성
• 발급한 세션을 브라우저에 주입하는 구조 구현 (storageState 또는 addInitScript, addCookies)
• service role key를 Node.js helper 전용으로 격리하고 브라우저 코드 노출을 차단
• 테스트 환경 변수 정의 및 .env 예시 정리
• 신규 가입, 회원탈퇴 시나리오용 테스트 유저 생성 및 삭제 구조 구현
• 테스트 실패 시에도 Auth 사용자와 관련 서비스 데이터를 정리하는 cleanup helper 작성
• 권한이 다른 두 사용자의 세션을 각각의 BrowserContext에 주입하는 방식 정의
• 실제 Provider 연동 확인을 위한 낮은 빈도 수동 점검 절차 문서화
• 인증이 필요한 테스트 1건으로 구조가 동작하는지 확인

---

Constraints

반드시 유지해야 하는 동작

• 기존 e2e/landing.spec.ts는 그대로 통과해야 합니다.
• 각 테스트는 독립적으로 실행되어야 하며, 테스트 실행 후 데이터가 다음 테스트에 영향을 주지 않아야 합니다.

변경하면 안 되는 사항

• service role key는 브라우저로 전달되는 코드에 포함되면 안 됩니다.
• Secret과 .env 파일은 커밋하지 않습니다.
• 운영 환경 Supabase에는 테스트 유저가 생성되지 않아야 합니다.

기술적 제약사항

• 세션 주입 방식으로는 redirect URI 오설정과 OAuth 클라이언트 설정 오류를 검출할 수 없습니다.
• Supabase Schema 변경이 발생하는 경우 Type을 최신 상태로 유지합니다.

---

Definition of Done

• 세션 주입만으로 로그인 이후 테스트를 반복 실행할 수 있음
• 신규 가입과 회원탈퇴 시나리오를 실제 소셜 로그인 없이 매 실행마다 독립적으로 검증할 수 있음
• 테스트 실패 후에도 다음 실행에 영향을 주는 사용자 및 관련 데이터가 남지 않음
• 권한이 다른 두 사용자 시나리오를 검증할 수 있음
• npm run lint 통과
• npm run build 통과
• 수동 점검 절차 문서 작성 완료

---

확인 필요

• CI 실행 범위를 이 이슈에 포함할지 결정이 필요합니다. 설계서 v2의 Task 5 완료 조건에는 CI 실행 범위를 문서에 명시하는 항목이 있었으나, 2026-08-28 문서 정정으로 feat→dev와 dev→main이 같은 케이스 세트를 실행하고 뷰포트 matrix만 다르게 가는 것으로 기준이 바뀌었습니다. 실행 범위 구분이 사라졌으므로 이 항목은 Task 7(GitHub Actions 워크플로우)에서 다루는 것이 맞아 보이며, 위 Tasks에는 넣지 않았습니다.
• 테스트 대상 Supabase 환경을 확정해야 합니다. 운영과 개발 환경 분리([feature-76/supabase-environment] Supabase 운영 및 개발 환경 분리 #198)가 완료된 상태이므로 개발 환경을 사용할 것으로 보이나, 설계서에 명시된 내용은 아닙니다.
• playwright.config.ts의 CI workers: 1 설정을 유지할지 확인이 필요합니다. 세션 주입 구조가 테스트마다 별도 유저를 만드는 방식이면 병렬 실행이 가능해질 수 있습니다.