"회원가입 화면을 안 만드는 것보다 서비스 단에서도 막는 게 안전하다"
로그인 기능을 구현하기 전에, 인증 서비스 자체가 아무것도 준비되지 않은 0 상태였습니다. Supabase 프로젝트를 새로 만들면서 리전을 ap-northeast-2로 선택했고, 이 과정에서 Project URL 위치를 찾지 못하거나 key 체계가 바뀐 부분(2025년 11월 이후 신규 프로젝트는 sb_publishable_/sb_secret_ 체계로 변경) 등 몇 차례 안내가 필요했습니다.
회원가입 화면을 아예 만들지 않는 방식도 고려했지만, 그것만으로는 API를 직접 호출하는 경로까지 막을 수 없다고 판단해 Supabase Authentication 설정에서 회원가입 자체를 비활성화했습니다. 화면 단과 서비스 단 양쪽에서 막아두는 이중 방어 구조를 선택한 것입니다.
테스트 계정은 Auto Confirm 옵션으로 생성한 뒤, SQL Editor에서 email_confirmed_at 값이 채워져 있는지 직접 조회해 확인했습니다. 이후 Connect 메뉴에서 URL과 key를 확보해 .env.local을 작성하는 것으로 준비를 마쳤습니다.
이 항목은 코드를 작성한 것이 아니라 외부 서비스를 설정한 작업이라, 다른 구현 작업과 구분해 별도로 기록해두었습니다. 로컬 환경 대신 원격 프로젝트를 선택한 것도 Windows에서 Docker를 새로 설치하는 것 자체가 리스크라고 봤기 때문입니다.
로컬 Supabase는 Docker가 필요한데, Windows 환경에서 Docker 설치 자체가 별도의 리스크를 추가한다고 판단해 원격 프로젝트를 선택했습니다. 회원가입 차단도 화면(UI) 단에서만 막는 것보다 서비스 설정 단에서도 함께 막아두는 이중 방어가 더 안전하다고 봤습니다. 이 항목은 코드 작업이 아니라 외부 서비스 설정 작업이라, 별도 작업 단위로 분리해 기록했습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(BPR)을 지원하는 한국어 기반 웹 애플리케이션. 컨설팅 프로젝트의 AS-IS 프로세스 분석부터 TO-BE 설계, Blueprint 승인까지의 전체 워크플로우를 디지털화하는 플랫폼으로, EPIC 단위로 구조화된 백로그를 기반으로 개발 중. 역할 및 워크플로우 PM / Architect / Reviewer 역할 수행 Codex(구현 담당)에게 Task 단위 구현 프롬프트 설계 Codex 구현 결과를 git log, git grep, git status로 직접 검증 후 승인 승인 전에는 Codex가 commit하지 않는 엄격한 게이팅 프로세스 운영 한 번에 하나의 Backlog Task만 진행, Task 완료 전 다음 Task 착수 금지 기술적 의사결정 및 성과 워크스페이스/프로젝트 접근 권한을 DB 레벨(복합 FK, SECURITY DEFINER 트리거)과 애플리케이션 레벨(Server Action 권한 검증)의 이중 방어 구조로 설계 Hard Delete 미구현 원칙 하에 배열 필드 전체교체(replace)를 단일 트랜잭션 RPC로 처리하는 패턴 확립 및 재사용 AS-IS 프로세스 그래프의 순환 참조 탐지에 Tarjan SCC 알고리즘 적용, 차단 오류(Error)와 경고(Warning)를 분리한 이중 Validator 아키텍처 설계 도메인 규칙 위반을 커스텀 Postgres 에러 코드 체계(SIA0104)로 문서화하여 거버넌스 문서와 코드베이스 간 정합성 유지 AI 생성 데이터와 사람이 검증한 데이터를 구분하는 generatedbyai / verified 메타데이터 패턴을 여러 도메인 테이블에 일관되게 적용 진행 상태 ✅ EPIC-01 (인증 / 워크스페이스 / 프로젝트 접근) ✅ EPIC-02 (조직 / 산업 / 프로젝트) 🚧 EPIC-03 (AS-IS 프로세스 그래프) — 그래프 검증, Input/Output 스키마, Business Rule 스키마 구현 완료