FastAPI와 Supabase로 로그인 MVP 만들기: 1인개발 실전 구조

혼자 MVP를 만들다 보면 기능은 금방 그리는데, 로그인과 데이터베이스 붙이는 데서 며칠씩 멈출 때가 있어요. 회원가입, 토큰, 권한 검사까지 직접 짜다 보면 정작 검증하고 싶었던 핵심 기능은 손도 못 대죠. 혹시 이런 적 없나요?

저는 라이프케어로그의 플랜씨(plan-c)·플랜비(plan-b) 같은 작은 서비스들을 만들면서, 인증과 DB는 가능한 한 직접 짜지 않는 쪽으로 정리했어요. 그 조합이 FastAPI와 Supabase예요.

역할을 나누면 단순해져요

핵심은 둘의 역할을 섞지 않는 거예요. Supabase는 인증과 데이터베이스를 맡고, FastAPI는 그 위에서 내 비즈니스 로직만 담당해요.

• Supabase: 회원가입·로그인·토큰 발급(Auth) + PostgreSQL
• FastAPI: 로그인한 사용자만 들어올 수 있는 API와 도메인 로직

회원가입 화면이나 토큰 재발급을 직접 구현하지 않아도 되니까, 처음부터 만들 코드가 확 줄어요.

클라이언트→Supabase Auth(JWT 발급)→FastAPI(토큰 검증)→DB 흐름

로그인 흐름은 이렇게 흘러요

흐름 자체는 생각보다 간단해요.

1. 클라이언트가 Supabase Auth로 로그인하고 토큰(JWT)을 받아요.
2. 이후 API 요청마다 Authorization 헤더에 그 토큰을 실어 보내요.
3. FastAPI는 받은 토큰의 서명을 서버에서 검증하고, 통과하면 사용자 정보를 꺼내 써요.

FastAPI에서는 이 검증 단계를 의존성(Depends)으로 한 번만 만들어두면, 보호가 필요한 API에 같이 끼워 재사용할 수 있어요. 로그인 검사 코드를 라우터마다 복붙하지 않아도 되는 거죠.

1인개발일수록 보안은 미리 잠가두기

빨리 만들고 싶을수록 두 가지는 처음에 맞춰두는 게 마음 편해요.

먼저 키 구분이에요. Supabase의 service_role 키는 모든 권한을 뚫는 키라서 클라이언트에 절대 노출하면 안 돼요. 브라우저·앱에는 anon(publishable) 키만 두고, service_role은 FastAPI 서버 환경변수에만 두세요.

다음은 RLS(Row Level Security)예요. Supabase는 테이블을 만들면 외부에서 접근 가능한 상태가 기본이라, 각 테이블에 "본인 행만 읽고 쓴다" 정책을 켜둬야 남의 데이터가 새지 않아요. 토큰 검증을 통과해도 RLS가 한 겹 더 막아주는 구조라고 보면 돼요.

• ✓service_role은 서버에만
• ✓클라이언트는 anon 키
• ✓모든 테이블 RLS 켜기

정리하며

이 조합의 장점은 화려함이 아니라, 직접 만들 코드가 줄어든다는 점이에요. 인증과 DB를 Supabase에 맡기면, 혼자서도 핵심 기능 검증에 시간을 더 쓸 수 있어요.

처음부터 완벽한 구조를 잡으려 하기보다, 로그인 한 번 통과하는 작은 흐름부터 끝까지 연결해보세요. 일단 돌아가는 한 줄이, 머릿속 설계도보다 훨씬 많은 걸 알려줘요.