Supabase로 로그인 있는 MVP 만드는 방법: Next.js 예제

로그인 하나 붙이려다 하루를 다 쓴 적, 혹시 있나요? 세션 관리, 토큰 저장, 비밀번호 재설정까지 직접 짜다 보면 정작 만들려던 기능은 손도 못 대게 돼요.

혼자 운영하면서 제일 아꼈던 게 이 부분이에요. 인증은 바퀴를 다시 발명할 자리가 아니라서, Supabase에 맡기고 남는 시간을 제품 로직에 쓰는 편이 나았어요.

준비물은 두 가지

Next.js 프로젝트와 Supabase 프로젝트만 있으면 시작할 수 있어요. Supabase 대시보드에서 프로젝트를 만들면 URL과 anon 키가 나오는데, 이 두 값을 .env.local에 넣어두면 돼요. anon 키는 클라이언트에 노출돼도 되는 키라 부담이 적어요. 반대로 service_role 키는 서버에서만 쓰고, 절대 브라우저로 내보내면 안 돼요.

Next.js에서 세션을 다루는 방법

App Router에서는 서버 컴포넌트와 브라우저에서 각각 Supabase 클라이언트를 만들어 써요. @supabase/ssr 패키지가 쿠키 기반 세션을 대신 처리해줘서, 새로고침해도 로그인이 풀리지 않아요.

브라우저에서는 createBrowserClient로 클라이언트를 만들고, 서버 컴포넌트나 라우트 핸들러에서는 createServerClient에 쿠키를 넘겨줘요. 로그인 자체는 이메일·비밀번호 방식이면 signInWithPassword 한 줄, 구글 같은 소셜 로그인이면 signInWithOAuth 한 줄이면 동작해요.

const { data, error } = await supabase.auth.signInWithPassword({
  email,
  password,
});

여기서 중요한 건, 로그인 여부를 화면에서만 판단하지 않는 거예요. 실제 권한 검사는 서버에서 getUser()로 확인하고, 데이터 접근은 Supabase의 RLS(행 수준 보안)로 한 번 더 막아둬요. 이렇게 두 겹을 두면 클라이언트 코드를 아무리 뜯어봐도 남의 데이터엔 손이 안 닿아요.

MVP에는 이 정도가 딱 맞아요

처음부터 이메일 인증, 소셜 로그인 세 종류, 2단계 인증까지 다 넣을 필요는 없어요. 이메일·비밀번호 로그인 하나로 시작해서, 사용자가 실제로 쓰기 시작하면 그때 필요한 방식만 얹는 게 반복을 줄이는 길이었어요.

라이프케어로그의 백엔드인 플랜티(plan-t)도 이 구조 위에서 인증을 처리하고 있어요. 화면 검증과 서버 검증, RLS를 나눠 두는 작은 습관 하나가 나중에 보안 사고를 크게 줄여줘요.

로그인은 제품의 첫인상이면서, 가장 오래 방치하기 쉬운 부분이기도 해요. 직접 다 짜기 전에, 이미 잘 만들어진 도구에 기대는 선택도 한 번 저울질해보세요.