맥락#
첫 만남 형식과 승인 절차의 세부 기획은 진행 중이지만 로그인·사용자 프로필·참가자 채팅은 어떤 안에서도 필요한 공통 기반이다. 프로젝트 오너는 기획 완료를 기다리지 않고 이 기본 기능과 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/에서 버전 관리해 향후 모바일도 같은 데이터·권한 계약을 사용한다. - 채팅방과 만남 모델은 느슨하게 결합한다. 최신 흐름은
댓글 신청 → 신청자별 확정 전 채팅 → 별도 참여 확정 → 확정자 조율이므로, 채팅 멤버십만으로 참여 확정을 추정하지 않는다. 구체 데이터 모델은 ADR-0054에 맞춰 후속 구현한다. [6]
검증 단계 운영#
- 원격 Supabase 프로젝트는 다른 제품 프로젝트를 재사용하지 않고 오프테이블 전용으로 만든다.
dev.offtable.kr과offtable.kr은 빠른 검증 중에도 서로 다른 Supabase 프로젝트를 사용한다. 개발 데이터·Auth 사용자는 운영 환경으로 이동하지 않는다. [7]- 로컬과 Vercel에는 Project URL과 publishable key만 연결한다. service role key와 데이터베이스 비밀번호는 브라우저 변수나 저장소에 넣지 않는다.
- 원격 연결 전에도 빌드와 배포는 성공하고, 데이터 기능 화면은 Supabase 연결 대기 상태를 명시한다.
- 검증 편의를 위해 로컬 이메일 확인은 끌 수 있다. 제품 규칙은 이메일 가입 확인 뒤에만 서비스를 연다. ADR-0032
지금 구현하지 않는 것#
- 휴대전화 인증, 수동 계정 병합과 공급자 연결 해제
- 사진·자기소개·회사·정확한 위치를 포함한 확장 프로필
- 무제한 1:1 메시지, 파일 업로드와 메시지 삭제
- 관리자용 service role API와 운영자 화면
- 만남 생성·댓글 신청·확정 전 채팅·참여 확정 도메인 모델
재직 인증은 당시 제외였으나 2026-08-18 ADR-0031이 회사 인증을 제품 요구로 바꿨고, 2026-08-19 ADR-0033이 시점을 첫 생성·참여 직전으로 옮겼다. 구현은 이 기반 ADR의 범위가 아니다.
현재 상태#
앱 출시 전까지 동일 기능은 이 제품 웹에서 구현한다. 출시 표면은 앱이다. 인증의 내부 Auth user ID·프로필 계약은 유지하되, 위 결정의 이메일 자격 증명과 로컬 이메일 확인 문장은 이력이다. 현재 자격 증명은 ADR-0055, 게스트 홈과 행동 전 로그인은 ADR-0056, 가입 본인·회사 인증은 ADR-0057을 따른다. [8]
결과#
기획이 바뀌어도 재사용할 수 있는 인증·프로필·채팅 저장 기반을 확보한다. 대화방 멤버십과 참여 확정 상태를 분리해 채팅 시작을 확정으로 성급히 고정하지 않는다.
관련 문서: 초기 MVP Supabase·Vercel 스택, RN·스토어, 보안 전환 게이트, offtable.kr 배포 주소, Supabase 환경 격리, 제품·MVP, 프로젝트 오너 지시