14강: 인증

로그인 만들기

오늘 끝나면 이런 걸 갖게 돼요. 12강의 할 일 목록에 이메일 로그인과 로그아웃이 생겨요. 계정이 다르면 서로의 할 일은 보이지 않아요.

1단계: 이메일 로그인을 준비해요

Supabase 대시보드에 로그인하고 12강에서 만든 프로젝트를 여세요. 왼쪽의 Authentication(인증, 사용자의 로그인을 관리하는 곳)에서 이메일 로그인이 켜져 있는지 확인해요.

연습 중에는 Confirm email을 꺼두세요. 켜져 있으면 가입 뒤 확인 메일을 눌러야 하고, 기본 메일 서비스는 시간당 2통까지만 보내요. 실제 서비스를 공개할 때는 다시 켜고 별도 메일 서버를 연결해 발송 제한을 조정하세요.

현재 무료 플랜에는 월 활성 사용자 5만 명까지 포함돼요. 이번 연습은 무료 범위로 충분해요.

프로젝트 로그인과 Confirm email 설정 저장은 직접 해야 해요. 이것만 직접 하시면 나머지는 클로드가 해요.

2단계: 클로드에게 도어락을 맡겨요

12강의 todos 테이블에는 누구나 드나드는 연습용 정책이 남아 있어요. 이번에는 RLS(Row Level Security, 행마다 주인을 확인하는 보안 규칙)로 바꿔요.

34줄짜리 SQL(데이터베이스를 바꾸는 명령문)을 직접 다룰 필요는 없어요. 클로드가 현재 상태와 복구 방법을 설명한 뒤, 승인을 받아 적용하게 하세요.

12강에서 만든 Supabase 프로젝트의 todos 테이블에 사용자별 권한을 붙여 줘.

먼저 현재 테이블 구조와 정책을 읽기 전용으로 확인해 줘.
Supabase가 연결되어 있지 않다면 연결 방법을 안내하고,
로그인이나 브라우저 승인이 필요한 화면에서 멈춰 줘.
아직 아무것도 바꾸지 말고 아래 내용을 쉬운 한국어로 보여 줘.
1. 삭제되거나 바뀔 기존 정책
2. 주인이 없는 연습 데이터의 개수
3. 적용할 권한 정책
4. 문제가 생겼을 때 되돌리는 방법

내가 승인하면 안전하게 다시 실행할 수 있는 변경안을 만들고 적용해 줘.
1. 12강의 "연습용 전체 허용" 정책 제거
2. todos에 사용자를 연결하는 user_id 추가
3. 로그인한 사용자에게 조회·추가·수정·삭제 권한 부여
4. RLS 활성화
5. 조회·추가·수정·삭제 모두 로그인한 사람의 ID와 user_id가 같을 때만 허용

주인이 없는 기존 연습 데이터는 내 승인 없이 지우지 마.
Supabase 로그인이나 브라우저 승인이 필요하면 그 화면에서 멈춰서 알려 줘.
SQL은 내가 직접 입력하게 하지 말고, 적용 결과와 남은 정책을 다시 확인해 줘.

주인 없는 데이터는 12강에서 만든 연습 기록이에요. 목록과 개수를 보고 지워도 되는지 결정하세요. 권한 변경을 승인할 때는 대상이 todos인지 확인해요.

3단계: 로그인 화면을 만들어요

권한을 먼저 걸면 할 일 목록이 잠시 비어 보일 수 있어요. 아직 로그인 화면이 없어서 생기는 정상적인 과정이에요.

아래 문장을 클로드에게 보내세요.

Supabase Auth로 이메일 로그인과 회원가입을 만들어 줘.

요구사항:
1. 로그인과 회원가입을 한 화면에서 할 수 있게 해 줘.
2. 이메일 형식과 비밀번호 6자 이상을 확인해 줘.
3. 로그인하면 todos 화면으로 이동하게 해 줘.
4. 로그인하지 않은 사람이 todos에 들어오면 로그인 화면으로 보내 줘.
5. todos 화면 위에 로그인한 이메일과 로그아웃 버튼을 보여 줘.
6. 할 일을 추가할 때 현재 사용자의 user_id가 연결되게 해 줘.
7. 기존 디자인은 유지하고 소셜 로그인과 새 외부 라이브러리는 추가하지 마.

현재 프로젝트 구조와 Supabase 연결 방식을 먼저 확인해 줘.
바꿀 파일과 동작 순서를 보여 준 뒤 내 승인을 받아 수정해 줘.
완료하면 실행과 확인도 맡고, 오류가 있으면 원인을 설명한 뒤 고쳐 줘.

소셜 로그인(OAuth, 구글·카카오 같은 다른 서비스의 인증을 빌리는 방식)은 이번 실습에서 만들지 않아요. 먼저 이메일 로그인부터 확인해요.

4단계: 두 계정으로 확인해요

도어락을 달았다면 다른 사람 열쇠로 열리지 않는지도 확인해야 해요. 계정 A가 만든 할 일이 계정 B에서 보이지 않는지 검사해요.

로그인과 RLS가 함께 안전하게 동작하는지 확인해 줘.

먼저 개발 화면을 준비해 줘. 내가 직접 열어야 한다면 주소를 알려 줘.
두 계정으로 검사할 순서를 한 단계씩 안내해 줘.
비밀번호는 읽거나 기록하지 마.

확인할 항목:
1. 계정 A로 가입하고 할 일 하나 추가
2. 로그아웃한 뒤 계정 B로 가입
3. 계정 B에서 계정 A의 할 일이 보이지 않는지 확인
4. 계정 B의 할 일을 추가한 뒤 다시 계정 A로 로그인
5. 계정 A에서 계정 B의 할 일이 보이지 않는지 확인
6. 로그인하지 않은 상태에서 todos에 들어가면 로그인 화면으로 이동하는지 확인

각 단계가 끝날 때까지 다음으로 넘어가지 마.
실패하면 데이터를 지우거나 권한을 넓히지 말고 원인과 고칠 부분을 먼저 설명해 줘.
마지막에는 "내 데이터는 나만 보이는지" 항목별로 통과 여부를 정리해 줘.

회원가입과 로그인 버튼은 직접 누르고, 비밀번호도 직접 입력하세요. 서로의 할 일이 보이지 않고, 로그인하지 않은 상태에서 로그인 화면으로 이동하면 성공이에요.

마지막으로 지금 상태를 저장해요.

로그인과 사용자별 데이터 분리가 모두 통과했는지 다시 확인해 줘.
API 키나 비밀번호가 코드와 저장 대상에 들어가지 않았는지도 검사해 줘.
문제가 없으면 지금 상태 저장하고 깃허브에 올려 줘.
실행 전에 무엇을 할지 먼저 보여 줘.

브라우저 로그인이나 권한 승인 창은 직접 마치세요.

인증과 RLS는 무엇이 다른가요?

인증은 놀이공원 입장 팔찌와 같아요. 로그인하면 팔찌를 받고, 로그아웃하면 반납해요.

RLS는 아파트 도어락이에요. 건물에 들어온 사람도 자기 집만 열 수 있듯, 로그인한 사용자도 자기 데이터만 볼 수 있어요. 로그인은 입장 확인, RLS는 데이터 주인 확인이에요.

오토프로그 랩스처럼 누구나 읽는 공개 자료에는 로그인이 필요 없어요. 직원 출퇴근 기록이나 거래처 문서처럼 사람마다 보여 줄 내용이 다르면 인증과 RLS가 함께 필요해요.

보안은 세 곳만 확인해요

1. API 키(외부 서비스 연결용 비밀값)는 코드에 쓰지 않고 .env.local에 보관해요.
2. todos의 옛 연습용 전체 허용 정책이 없어졌는지 확인해요.
3. 계정 A와 B가 서로의 데이터를 볼 수 없는지 직접 검사해요.

비밀번호 저장과 확인은 Supabase Auth가 처리해요. 서비스를 공개하기 전에는 Confirm email을 다시 켜고 메일 발송 설정도 점검하세요.

이런 분께 추천해요

할 일 목록·가계부·일기처럼 개인 데이터를 다루는 서비스를 만드는 분께 필요해요. 팀원이나 고객마다 다른 내용을 보여 주려는 분도 같은 구조를 쓸 수 있어요.

참고 링크

• Supabase Auth 공식 문서
• Supabase 이메일/비밀번호 인증 가이드
• Supabase 소셜 로그인(OAuth) 가이드
• Supabase Google OAuth 설정
• Supabase RLS(Row Level Security) 가이드
• Supabase 인증 일반 설정 (Confirm email 등)
• Supabase 이메일 발송 한도 안내
• Supabase 데이터베이스 역할 (anon / authenticated)
• PostgreSQL CREATE POLICY 문서 (정책이 OR로 합쳐지는 규칙)
• Supabase JavaScript 클라이언트 - Auth
• Next.js + Supabase Auth 퀵스타트

다음 강

15강: 디버깅 — 에러는 과정이다에서는 에러 메시지를 클로드에게 건네고, 원인을 찾고, 안전하게 복구하는 순서를 배워요.

15강으로 넘어가기