Next.js 로그인, Supabase로 붙일 때 정리해둔 것

사이드 프로젝트를 만들다 보면 로그인부터 막히곤 해요. 화면은 금방 그리는데, 새로고침하면 세션이 풀리고 서버 컴포넌트에서는 유저 정보가 안 잡히죠. 혼자 운영하면서 같은 데서 몇 번 헤맸던 터라, Next.js에 Supabase 인증을 붙일 때 순서를 정리해뒀어요.

왜 Supabase부터 보게 되나

인증을 직접 만들려고 하면 비밀번호 해싱, 세션 저장, 소셜 로그인 콜백까지 손댈 게 많아요. Supabase는 이걸 데이터베이스와 묶어서 주고, 무료 구간이 있어서 MVP를 빨리 세우기 좋아요. 이메일·비밀번호, 매직 링크, 구글 같은 소셜 로그인을 같은 방식으로 다룰 수 있고요.

환경변수→클라이언트·서버 분리→미들웨어 세션 갱신→RLS

준비물은 환경변수 두 개

프로젝트를 만들면 프로젝트 URL과 anon 키가 나와요. 이 둘을 NEXT_PUBLIC_ 접두어로 넣어두면 브라우저 쪽에서도 쓸 수 있어요. 조심할 건 service_role 키예요. 이건 서버 전용이라 클라이언트 코드나 저장소에 올리면 안 돼요.

클라이언트와 서버를 나눠서 만들기

App Router에서는 브라우저용과 서버용 클라이언트를 따로 두는 게 편해요. @supabase/ssr 패키지가 이 구분을 도와줘요. 예전에 쓰던 auth-helpers는 지금 권장에서 빠졌으니, 새로 시작한다면 ssr 쪽을 보는 게 맞아요.

• 브라우저: createBrowserClient로 클릭·폼 이벤트에서 로그인 처리
• 서버: createServerClient로 쿠키를 읽어 서버 컴포넌트에서 유저 확인

진짜 함정은 세션 유지

로그인은 됐는데 새로고침하면 로그아웃되는 문제, 대부분 세션 갱신을 안 걸어둬서예요. 미들웨어에서 요청마다 세션을 확인하고 쿠키를 다시 심어줘야 서버와 클라이언트가 같은 상태를 봐요. 이 한 겹이 빠지면 서버 컴포넌트에서 유저가 계속 null로 잡혀요.

마지막은 RLS

Supabase는 테이블 접근을 Row Level Security로 막아요. 켜두지 않으면 anon 키만으로 남의 데이터까지 읽힐 수 있어요. 로그인을 붙이자마자 테이블마다 정책을 정하고, 로그인한 사용자가 자기 행만 보도록 걸어두는 걸 먼저 하는 게 안전해요.

• ✓anon 키만 노출
• ✓service_role은 서버 전용
• ✓RLS 먼저 켜기

혼자 여러 서비스를 굴리다 보면 이 인증 골격을 계속 재사용하게 돼요. 저도 플랜씨(plan-c)나 플랜티(plan-t) 같은 도구를 만들 때 같은 순서로 붙여요. 로그인은 화려할 필요 없어요. 세션이 안 풀리고 데이터가 안 새면 충분하거든요.