팀 메모 앱에서 로그인이 잘됐다고 안심했는데, 계정 B가 주소의 메모 번호만 바꿔 계정 A의 글을 읽을 수 있다면 인증은 끝난 것이 아닙니다. 로그인은 사용자가 누구인지 확인할 뿐이고, 그 사용자가 어느 데이터를 볼 수 있는지는 별도의 권한 규칙이 막아야 합니다.

핵심 Supabase의 RLS(Row Level Security)는 데이터베이스의 각 행을 누가 읽고 고칠 수 있는지 정하는 규칙입니다. 인증 구현은 로그인 성공뿐 아니라 RLS, 세션 만료, 안전한 이동 주소, 로그아웃 이후 접근까지 두 계정으로 확인해야 끝납니다.

첫 구현은 사용자 확인만 했습니다

화면은 세션 존재 여부만 확인했고 메모 조회에는 소유자 조건이 없었습니다. 또 `service_role` 키가 브라우저 설정에 들어갈 뻔했습니다. 이 키는 RLS를 우회할 수 있는 서버 전용 비밀입니다. 브라우저에 넣어도 되는 공개 키와 같은 방식으로 다루면 안 됩니다.

두 계정으로 권한을 검증했습니다

소유자와 다른 사용자의 결과를 모두 수용 기준에 넣었습니다.

에이전트에 준 인증 경계
계정 A: 자신의 메모 읽기·수정 성공
계정 B: A의 메모 읽기·수정 거부
비로그인: 로그인 화면 이동
콜백: 허용된 내부 경로만 이동
금지: 서비스 역할 키의 클라이언트 사용

정책은 사용자 ID와 행의 소유자를 비교합니다

아래 SQL은 구조를 설명하는 최소 예시입니다. `auth.uid()`는 현재 로그인한 사용자의 ID이고 `user_id`는 메모 행의 소유자입니다. 실제 테이블명과 역할은 프로젝트에 맞춰 확인해야 합니다.

자기 메모만 읽고 고치게 하는 RLS의 핵심
alter table notes enable row level security;

create policy "read own notes" on notes
for select using (auth.uid() = user_id);

create policy "update own notes" on notes
for update using (auth.uid() = user_id)
with check (auth.uid() = user_id);

관찰 결과

계정 A로 만든 메모는 A에게만 조회·수정 결과가 돌아와야 합니다. 같은 메모 ID를 계정 B와 비로그인 상태로 요청하면 데이터가 없어야 하며 수정도 반영되지 않아야 합니다. 세션이 만료되거나 로그아웃한 뒤 이전 주소를 다시 열었을 때도 메모 본문이 잠깐이라도 화면에 남으면 실패입니다. HTTP 상태 코드와 빈 결과 형식은 프로젝트 API 규칙에 맞춥니다.

운영 설정 앞에서 멈춥니다

실제 이메일 발송, 운영 공급자 설정, 비밀 회전과 스키마 적용은 승인 없이 하지 않습니다. 교차 계정 거부 테스트가 없거나 열린 이동 주소가 남으면 로그인 화면이 작동해도 완료로 보지 않습니다.

인증 경로를 읽는 시작 명령

Claude Code에는 로그인 화면만 보지 말고 요청을 가로채는 미들웨어, RLS 정책, 키 사용 위치를 함께 읽게 합니다. 운영 Supabase에는 연결하지 않고 로컬 코드와 테스트만 조사합니다. `/path/to/project`는 자기 프로젝트 경로로 바꿔야 합니다.

인증 경계와 세션 흐름만 조사시키는 요청
cd /path/to/project
claude --permission-mode plan

첫 프롬프트: 로그인부터 메모 조회까지 인증과 RLS 경로를 읽으세요. 서비스 역할 키의 사용 위치와 교차 계정 테스트 누락을 찾되 수정하지 마세요.
읽을 대상: src/auth/, middleware/, supabase/migrations/, CLAUDE.md 또는 저장소 지침 파일
허용 도구: Read, Glob, Grep
Edit와 Bash는 검토 전 승인하지 않습니다.
반환 형식: 인증 흐름 / 키 경계 / 정책 누락 / 수정 후보 / 미검증 항목

인증 경계표를 승인한 뒤 로컬 수정만 요청합니다

리뷰어는 보고서의 키 이름을 실제 환경 설정과 대조합니다. 테스트가 소유자, 다른 사용자, 비로그인 상태를 각각 다루는지도 봅니다. 그다음 "확인한 인증 코드, RLS 정책과 관련 테스트만 수정하세요. 서비스 역할 키, 운영 프로젝트와 로그인 공급자 설정에는 접근하지 마세요"라고 수정 범위를 고정합니다.

인증 회귀와 키 경계를 따로 확인합니다

인증 테스트가 통과해도 소유자 조건이 빠진 정책이나 클라이언트 번들에 들어간 서버 비밀은 남을 수 있습니다. 교차 계정 회귀를 실행한 뒤 변경 차이에서 정책 범위, 키 이름과 승인 밖 설정 파일을 따로 확인합니다.

인증 회귀와 환경 파일 노출을 함께 확인하는 명령
npm test -- auth
git diff -- src/auth supabase/
git status --short

인증 세션을 다시 열 수 있는 범위

운영 Supabase 연결, 실제 이메일 발송이나 비밀 회전이 필요하면 현재 세션을 멈춥니다. 로컬 RLS와 인증 회귀라는 범위가 유지될 때만 실패한 역할과 마지막 테스트부터 재개하며, 공급자 설정이나 스키마 배포는 승인 주체가 다른 새 작업으로 분리합니다.

공식 출처