[test-81/e2e] E2E 테스트의 service role key 의존 제거

[hm1n]

Summary

E2E 테스트가 Supabase service role key를 직접 쓰지 않도록 seed와 cleanup 경로를 좁힙니다.
현재 CI는 이 키를 PR 코드가 실행되는 환경에 그대로 주입하고 있어, 저장소 쓰기 권한이 개발 DB 전권으로 이어집니다.
#209의 Codex 리뷰에서 확인된 문제이며, 해당 PR에서는 근거를 남기고 수용한 뒤 이 이슈로 분리했습니다.

---

Why

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

PR 코드가 service role key와 같은 환경에서 실행됩니다.

.github/workflows/ci-e2e-test.yml의 테스트 단계는 SUPABASE_SERVICE_ROLE_KEY를 환경변수로 주입합니다. pull_request 이벤트는 제안된 병합 커밋의 코드를 실행하므로, 그 단계에서 도는 playwright.config.ts, e2e/**, next start가 띄우는 서버 코드는 모두 PR이 가져온 코드입니다. 리뷰보다 실행이 먼저입니다.

저장소 쓰기 권한이 개발 DB 전권으로 이어집니다.

조직에 브랜치를 만들 수 있는 사람은 키를 외부로 보내는 코드를 PR에 넣을 수 있습니다. fork PR을 배제한 설정은 이 경로를 막지 못합니다. 공격자가 fork가 아니라 같은 저장소의 브랜치를 쓰기 때문입니다. 이 키는 RLS를 우회하므로 유출되면 개발 Supabase 프로젝트 전체에 제한 없이 접근됩니다.

지금 당장의 위험은 낮지만 조건이 바뀌면 달라집니다.

현재 개발 DB에는 실제 고객 데이터가 없고(user 행 4개) 조직에서 이 DB를 쓰는 사람이 사실상 한 명이라 실질 피해가 작습니다. 그래서 #209에서는 수용했습니다. 그러나 참여 인원이 늘거나 개발 DB에 의미 있는 데이터가 쌓이면 같은 구조가 그대로 위험이 됩니다. 조건이 바뀌기 전에 처리해야 합니다.

---

Goal

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

이번 작업의 목표

• CI 환경에 service role key가 존재하지 않습니다.
• 테스트가 쓰는 자격증명은 E2E 테스트 계정과 그에 딸린 데이터만 만들고 지울 수 있는 범위로 제한됩니다.
• 자격증명이 유출되어도 피해가 그 범위를 넘지 않습니다.
• 로컬 실행과 CI 실행이 같은 경로를 씁니다.

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

• 개발 DB와 분리된 별도 테스트 전용 Supabase 프로젝트 구성은 포함하지 않습니다. 권한 상승 경로 자체를 없애지 못해 이 이슈의 목표와 다릅니다.
• GitHub Environment 승인 게이트 도입은 하지 않습니다. 매 PR 수동 승인이 생겨 자동 게이트라는 목적과 충돌합니다.
• 테스트 케이스 추가 구현은 포함하지 않습니다.

---

Approach

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

전체 구현 방향

seed와 cleanup을 테스트 프로세스에서 떼어내 서버 쪽 진입점 뒤로 옮깁니다. 테스트는 그 진입점을 호출하고, 호출에 필요한 자격증명만 CI에 둡니다. service role key는 서버 쪽에만 남습니다.

주요 변경 사항 (확인 필요)

• seed와 cleanup을 수행하는 진입점을 만듭니다. Supabase Edge Function과 Next.js API route 중 어느 쪽이 맞는지 판단이 필요합니다.
• 진입점은 E2E 테스트 계정 규칙(@nbread-e2e.test 이메일 등)에 해당하는 대상만 다루도록 제한합니다.
• 호출자 인증용 시크릿을 새로 만들고 GitHub Secrets에 등록합니다.
• e2e/fixtures/seed.ts가 admin 클라이언트 대신 이 진입점을 호출하도록 바꿉니다.
• 워크플로우에서 SUPABASE_SERVICE_ROLE_KEY 주입을 제거합니다.

검토한 대안과 선택 이유

#209에서 검토한 대안은 다음과 같습니다.

• GitHub Environment 필수 승인자: 실행 전에 사람이 승인하므로 노출은 막습니다. 그러나 매 PR마다 수동 승인이 필요해 자동 게이트 도입 이유가 사라집니다.
• 개발 DB와 분리된 테스트 전용 프로젝트: 유출 시 잃을 데이터가 줄지만, 저장소 쓰기 권한이 그 프로젝트 전권으로 이어지는 구조는 그대로입니다.
• 현 상태 유지: 조건이 바뀌면 그대로 위험이 됩니다.

권한 자체를 좁히는 방식만이 구조를 바꿉니다. 설계서 v2 12장의 "테스트 계정 관리 방식 개선"과도 같은 방향입니다.

---

Tasks

• seed와 cleanup 진입점의 형태 결정 (Edge Function / API route)
• 진입점 구현 및 대상 범위 제한 (E2E 테스트 계정과 그 데이터만)
• 호출자 인증 방식 결정 및 시크릿 등록
• e2e/fixtures/seed.ts가 진입점을 호출하도록 변경
• 워크플로우에서 SUPABASE_SERVICE_ROLE_KEY 주입 제거
• 로컬과 CI에서 기존 16건이 그대로 통과하는지 확인
• e2e/README.md의 실행 준비 절 갱신

---

Constraints

반드시 유지해야 하는 동작

• 기존 E2E 테스트 16건은 그대로 통과해야 합니다.
• 테스트 실패 후에도 만든 데이터가 되돌려져야 합니다.
• 로컬 실행 방식이 지나치게 번거로워지면 안 됩니다.

변경하면 안 되는 사항

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

기술적 제약사항

• Supabase Admin API(auth.admin.createUser, deleteUser)는 secret key를 요구합니다. 키를 없애는 것이 아니라 서버 쪽으로 옮기는 것이 목표입니다.
• 진입점이 새로운 공격면이 되지 않도록 호출자 인증과 대상 범위 제한이 함께 필요합니다.

---

Definition of Done

• CI 환경에 service role key가 주입되지 않음
• 테스트가 쓰는 자격증명으로는 E2E 테스트 계정과 그 데이터 외에 접근할 수 없음
• 로컬과 CI에서 16건 통과
• 실행 후 개발 DB 잔여 데이터 0건
• npm run lint 통과
• npm run build 통과

---

확인 필요

• 진입점의 형태가 미정입니다. Edge Function은 앱 배포와 무관하게 존재해 CI에서 항상 호출 가능하다는 장점이 있고, API route는 이미 진행 중인 app/api 이관([refactor-63/api] supabase client → app/api 마이그레이션 #170) 흐름과 맞습니다. 어느 쪽이 맞는지 판단이 필요합니다.
• 개발 DB에 실제 데이터가 쌓일 예정인지 확인이 필요합니다. 현재 위험 평가는 "잃을 데이터가 없다"는 전제에 기대고 있어, 전제가 바뀌면 우선순위를 올려야 합니다.
• 이 작업의 우선순위가 미정입니다. [cicd-80/e2e] GitHub Actions E2E 테스트 워크플로우 추가 #209 시점의 판단은 "지금은 수용"이었으나, 언제까지 수용할지는 정해지지 않았습니다.

[hm1n]

결정: 지금은 수용하고 트리거를 정해 닫습니다

현행 유지와 이 작업을 다시 비교한 결과, 지금 시점에서는 작업 비용이 얻는 안전보다 큽니다.
Not planned로 닫되, 아래 조건 중 하나라도 발생하면 다시 엽니다.

지금 수용하는 이유

위험의 두 항이 모두 낮습니다.
피해 규모는 개발 DB에 실고객 데이터가 없어(user 4행) 사실상 0이고,
발생 가능성은 "저장소 쓰기 권한자가 악의적 코드를 PR에 넣는다"인데 현재 쓰기 권한자가 사실상 한 명입니다.

반대편 비용은 실재합니다.

• Edge Function 신규 구현(action 10종)과 e2e/fixtures/seed.ts 전면 전환.
• seed 헬퍼를 추가할 때마다 함수 수정과 수동 배포가 따라옵니다. 일회성이 아니라 지속 비용입니다.
• src/app/api/auth/delete-account/route.ts가 service role key를 씁니다. CI에서 키를 빼면 이 라우트는 500이 되고, 회원 탈퇴 E2E는 구조상 검증할 수 없게 됩니다. 지킬 자산이 없는 상태에서 테스트 능력을 잃는 교환입니다.

다시 여는 조건

아래 중 하나라도 발생하면 즉시 착수합니다.

• 저장소 쓰기 권한자가 2명 이상이 됨
• 개발 DB에 되돌릴 수 없는 데이터가 생김 (실사용자 유입, 운영 데이터 복제 등)
• E2E 워크플로가 pull_request_target을 쓰거나 fork PR을 다루게 됨
• e2e/fixtures/seed.ts의 seed/cleanup action이 15종을 넘음 (이관 비용이 더 커지기 전 한계선)

착수하게 될 경우의 방향

이번 검토에서 이슈 본문의 "확인 필요" 1번(Edge Function / API route)은 결론이 났습니다.

API route는 이 문제를 해결하지 못합니다. 워크플로에서 next start를 띄우는 주체가 Playwright의 webServer이고, 그 서버는 PR이 가져온 코드입니다. API route를 만들면 secret key를 그 프로세스의 환경변수로 넣어야 하므로 PR 코드가 그대로 읽습니다. 구조가 지금과 같습니다.

Edge Function이 맞습니다. 현재 함수 배포 워크플로가 없어 함수 코드가 PR 통제 밖에 있고, secret key는 Supabase 함수 환경에만 남습니다. CI에는 호출용 시크릿만 둡니다.

• 함수는 POST { action, payload } 단일 진입점으로 두고 action을 현 Seeder 메서드와 1:1로 맞춥니다. 그러면 Seeder의 public 시그니처를 유지할 수 있어 spec 5개 파일은 수정하지 않아도 됩니다.
• 대상 범위 제한은 함수 안의 불변식으로 겁니다. 이메일은 함수가 생성해 @nbread-e2e.test를 강제하고, user 대상 action은 이메일 접미사를, nbread 대상 action은 leader_id가 e2e 계정인지 확인합니다. cleanup도 삭제 전 같은 검증을 거칩니다.
• E2E_FIXTURES_ENABLED가 true가 아니면 즉시 거부해, 운영 프로젝트에 배포되더라도 동작하지 않게 합니다.
• 남는 위험은 시크릿이 유출되어도 e2e 계정 무제한 생성 정도이며, 필요하면 생성 수 상한을 둡니다.

함께 처리하면 좋은 것

현행 유지의 위험 계산을 더 견고하게 만드는, 비용이 거의 없는 항목입니다. 별도 이슈로 다룹니다.

• service role key 정기 교체 절차 문서화 (유출 감지 시 대응 시간 단축)
• 개발 Supabase 프로젝트 백업 상태 확인 (전권 유출의 최악은 삭제이므로, 복구 가능하면 피해 규모가 더 내려감)