맥락#
첫 만남 형식과 승인 절차의 세부 기획은 진행 중이지만 로그인·사용자 프로필·참가자 채팅은 어떤 안에서도 필요한 공통 기반이다. 프로젝트 오너는 기획 완료를 기다리지 않고 이 기본 기능과 Supabase 설정을 시작하기로 했다. [1]
기술 스택은 이미 Supabase와 Vercel로 정했지만 실제 제품 웹에는 Supabase SDK, 환경 변수 계약, migration과 인증 연결이 없었다. 화면만 더 만드는 것보다 Auth·Postgres·RLS·Realtime을 잇는 최소 수직 흐름이 먼저 필요하다.
결정#
- 제품 웹
apps/web에서 이메일·비밀번호와 카카오·구글·Apple 기반 Supabase Auth를 제공한다. 공급자 흐름과 환경 계약은 인증 기반과 소셜 로그인에서 관리한다. [2] - Next.js 서버와 브라우저가 세션을 공유하도록
@supabase/ssr의 쿠키 기반 클라이언트를 사용한다. [3] profiles에는 Auth 사용자와 연결된 최소 표시 이름만 저장한다.- 채팅은
chat_rooms,chat_room_members,messages로 분리하고 승인된 방 멤버만 읽고 쓸 수 있게 RLS를 적용한다. [4] - 첫 실시간 기능은 방별
messagesINSERT 구독만 사용한다. 측정된 병목 없이 별도 메시지 서버나 Broadcast를 먼저 도입하지 않는다. [5] - Supabase 설정과 migration은
services/backend/supabase/에서 버전 관리해 향후 모바일도 같은 데이터·권한 계약을 사용한다. - 만남 생성·참여·호스트 승인 기획이 확정되기 전에는 채팅방과 만남 모델을 강하게 결합하지 않는다. 승인 흐름이 정해지면 승인된 참가자를
chat_room_members에 연결한다.
검증 단계 운영#
- 원격 Supabase 프로젝트는 다른 제품 프로젝트를 재사용하지 않고 오프테이블 전용으로 만든다.
dev.offtable.kr과offtable.kr은 빠른 검증 중에도 서로 다른 Supabase 프로젝트를 사용한다. 개발 데이터·Auth 사용자는 운영 환경으로 이동하지 않는다. [6]- 로컬과 Vercel에는 Project URL과 publishable key만 연결한다. service role key와 데이터베이스 비밀번호는 브라우저 변수나 저장소에 넣지 않는다.
- 원격 연결 전에도 빌드와 배포는 성공하고, 데이터 기능 화면은 Supabase 연결 대기 상태를 명시한다.
- 검증 편의를 위해 로컬 이메일 확인은 끌 수 있다. 제품 규칙은 이메일 가입 확인 뒤에만 서비스를 연다. ADR-0032
지금 구현하지 않는 것#
- 휴대전화 인증, 수동 계정 병합과 공급자 연결 해제
- 사진·자기소개·회사·정확한 위치를 포함한 확장 프로필
- 무제한 1:1 메시지, 파일 업로드와 메시지 삭제
- 관리자용 service role API와 운영자 화면
- 만남 생성·참여 요청·호스트 승인 도메인 모델
재직 인증은 당시 제외였으나 2026-08-18 ADR-0031이 가입 시 회사 인증을 제품 요구로 바꿨다. 구현은 이 기반 ADR의 범위가 아니다.
결과#
기획이 바뀌어도 재사용할 수 있는 인증·프로필·채팅 저장 기반을 확보한다. 동시에 대화방 멤버십을 만남 승인과 느슨하게 분리해 아직 정해지지 않은 제품 흐름을 데이터베이스에 성급히 고정하지 않는다.
관련 문서: 초기 MVP Supabase·Vercel 스택, 보안 전환 게이트, offtable.kr 배포 주소, Supabase 환경 격리, 제품·MVP, 프로젝트 오너 지시