Supabase 7점검: RLS·마이그레이션·백업 기준

Supabase을 찾는 분이 가장 먼저 구분해야 할 기준부터 실제 순서까지 정리했습니다. Supabase 프로젝트는 테이블이 만들어지고 API가 응답하는 것만으로 운영 준비가 끝나지 않습니다. Postgres 스키마, Row Level Security, Auth 권한, 마이그레이션 기록, Edge Functions, Storage 정책, 백업과 복구 절차를 같은 기준으로 확인해야 데이터 사고를 줄일 수 있습니다.

읽는 시간 약 7분 · 가이드: 판단 기준 · 실행 순서 · 구매와 보관

Supabase 문제 정의: 먼저 기준을 세워야 하는 이유

Supabase 프로젝트는 테이블이 만들어지고 API가 응답하는 것만으로 운영 준비가 끝나지 않습니다. Postgres 스키마, Row Level Security, Auth 권한, 마이그레이션 기록, Edge Functions, Storage 정책, 백업과 복구 절차를 같은 기준으로 확인해야 데이터 사고를 줄일 수 있습니다.

개발 중에는 서비스 키나 넓은 권한으로 동작해도 운영 사용자는 RLS 정책과 Auth 상태에 따라 다른 결과를 봅니다. 권한 문제를 성능 문제처럼 고치거나, 스키마 변경과 정책 변경을 동시에 하면 원인을 추적하기 어렵습니다.

첫 확인	역할 3종

현실 차이: 겉으로 비슷해도 결과가 달라지는 지점

API 응답과 권한 안전의 차이

데이터가 보인다는 사실과 올바른 사용자에게만 보인다는 사실은 다릅니다.

Supabase의 API 응답과 권한 안전의 차이 단계에서는 역할별 readback을 따로 실행하세요. 이때 다른 조건은 유지해야 API 응답과 권한 안전의 차이에서 생긴 차이를 분리해 확인할 수 있습니다.

현실 관점의 판정 신호는 역할별 결과입니다. API 응답과 권한 안전의 차이의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

API 응답과 권한 안전의 차이 확인은 역할별 readback을 따로 실행하세요. 이후 역할별 결과 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 API 응답과 권한 안전의 차이 결과가 한 번 더 재현되는지 확인하세요.

현실 확인	역할별 결과

스키마 변경과 마이그레이션의 차이

대시보드에서 바꾼 구조가 코드와 동기화되지 않으면 재현성이 떨어집니다.

이 항목의 스키마 변경과 마이그레이션의 차이 단계에서는 마이그레이션 파일과 적용 로그를 남기세요. 이때 다른 조건은 유지해야 스키마 변경과 마이그레이션의 차이에서 생긴 차이를 분리해 확인할 수 있습니다.

현실 관점의 판정 신호는 변경 기록입니다. 스키마 변경과 마이그레이션의 차이의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

스키마 변경과 마이그레이션의 차이 확인은 마이그레이션 파일과 적용 로그를 남기세요. 이후 변경 기록 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 스키마 변경과 마이그레이션의 차이 결과가 한 번 더 재현되는지 확인하세요.

현실 확인	변경 기록

Storage와 Database 정책의 차이

파일 접근 정책과 테이블 정책은 별도로 확인해야 합니다.

이 항목의 Storage와 Database 정책의 차이 단계에서는 업로드·다운로드·삭제 권한을 각각 테스트하세요. 이때 다른 조건은 유지해야 Storage와 Database 정책의 차이에서 생긴 차이를 분리해 확인할 수 있습니다.

현실 관점의 판정 신호는 정책 분리입니다. Storage와 Database 정책의 차이의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

Storage와 Database 정책의 차이 확인은 업로드·다운로드·삭제 권한을 각각 테스트하세요. 이후 정책 분리 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 Storage와 Database 정책의 차이 결과가 한 번 더 재현되는지 확인하세요.

현실 확인	정책 분리

Supabase 판단 기준 3가지

RLS 정책

테이블별로 어떤 역할이 어떤 행을 볼 수 있는지 명확해야 합니다.

Supabase의 RLS 정책 단계에서는 익명·로그인·관리자 역할을 분리해 테스트하세요. 이때 다른 조건은 유지해야 RLS 정책에서 생긴 차이를 분리해 확인할 수 있습니다.

판단 관점의 판정 신호는 역할 3종입니다. RLS 정책의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

RLS 정책 확인은 익명·로그인·관리자 역할을 분리해 테스트하세요. 이후 역할 3종 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 RLS 정책 결과가 한 번 더 재현되는지 확인하세요.

판단 확인	역할 3종

마이그레이션 기록

운영 스키마를 재현하려면 변경 파일과 적용 순서가 필요합니다.

이 항목의 마이그레이션 기록 단계에서는 변경 전후 schema diff를 저장하세요. 이때 다른 조건은 유지해야 마이그레이션 기록에서 생긴 차이를 분리해 확인할 수 있습니다.

판단 관점의 판정 신호는 재현 가능입니다. 마이그레이션 기록의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

마이그레이션 기록 확인은 변경 전후 schema diff를 저장하세요. 이후 재현 가능 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 마이그레이션 기록 결과가 한 번 더 재현되는지 확인하세요.

판단 확인	재현 가능

Auth 경계

로그인 상태와 토큰 만료, 권한 실패 응답을 확인해야 합니다.

이 항목의 Auth 경계 단계에서는 성공과 실패 케이스를 모두 저장하세요. 이때 다른 조건은 유지해야 Auth 경계에서 생긴 차이를 분리해 확인할 수 있습니다.

판단 관점의 판정 신호는 권한 실패 증거입니다. Auth 경계의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

Auth 경계 확인은 성공과 실패 케이스를 모두 저장하세요. 이후 권한 실패 증거 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 Auth 경계 결과가 한 번 더 재현되는지 확인하세요.

판단 확인	권한 실패 증거

백업과 복구

백업이 있다는 사실보다 복구 절차를 실제로 읽어 본 증거가 중요합니다.

이 항목의 백업과 복구 단계에서는 복구 책임자와 절차 문서를 남기세요. 이때 다른 조건은 유지해야 백업과 복구에서 생긴 차이를 분리해 확인할 수 있습니다.

판단 관점의 판정 신호는 복구 경로입니다. 백업과 복구의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

백업과 복구 확인은 복구 책임자와 절차 문서를 남기세요. 이후 복구 경로 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 백업과 복구 결과가 한 번 더 재현되는지 확인하세요.

판단 확인	복구 경로

확인 항목	권장 신호	피할 신호
RLS 정책	역할 3종	테이블별로 어떤 역할이 어떤 행을 볼 수 있는지 명확해야 합니다.
마이그레이션 기록	재현 가능	운영 스키마를 재현하려면 변경 파일과 적용 순서가 필요합니다.
Auth 경계	권한 실패 증거	로그인 상태와 토큰 만료, 권한 실패 응답을 확인해야 합니다.
백업과 복구	복구 경로	백업이 있다는 사실보다 복구 절차를 실제로 읽어 본 증거가 중요합니다.

Supabase 실행법 3단계

1단계 · 스키마 기준선 저장

테이블, 컬럼, 인덱스, 외래키를 한 번에 기록합니다.

Supabase의 1단계 · 스키마 기준선 저장 단계에서는 변경 전 기준을 보존하세요. 이때 다른 조건은 유지해야 1단계 · 스키마 기준선 저장에서 생긴 차이를 분리해 확인할 수 있습니다.

실행 관점의 판정 신호는 schema snapshot입니다. 1단계 · 스키마 기준선 저장의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

1단계 · 스키마 기준선 저장 확인은 변경 전 기준을 보존하세요. 이후 schema snapshot 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 1단계 · 스키마 기준선 저장 결과가 한 번 더 재현되는지 확인하세요.

실행 확인	schema snapshot

2단계 · RLS 역할 테스트

역할별로 같은 쿼리를 실행해 보이는 행과 막히는 행을 비교합니다.

이 항목의 2단계 · RLS 역할 테스트 단계에서는 서비스 키 결과와 사용자 결과를 혼동하지 마세요. 이때 다른 조건은 유지해야 2단계 · RLS 역할 테스트에서 생긴 차이를 분리해 확인할 수 있습니다.

실행 관점의 판정 신호는 역할 readback입니다. 2단계 · RLS 역할 테스트의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

2단계 · RLS 역할 테스트 확인은 서비스 키 결과와 사용자 결과를 혼동하지 마세요. 이후 역할 readback 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 2단계 · RLS 역할 테스트 결과가 한 번 더 재현되는지 확인하세요.

실행 확인	역할 readback

3단계 · 마이그레이션 적용

로컬 또는 스테이징에서 마이그레이션을 적용하고 로그를 저장합니다.

이 항목의 3단계 · 마이그레이션 적용 단계에서는 스키마와 정책을 한 변경에 섞지 마세요. 이때 다른 조건은 유지해야 3단계 · 마이그레이션 적용에서 생긴 차이를 분리해 확인할 수 있습니다.

실행 관점의 판정 신호는 단일 변경입니다. 3단계 · 마이그레이션 적용의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

3단계 · 마이그레이션 적용 확인은 스키마와 정책을 한 변경에 섞지 마세요. 이후 단일 변경 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 3단계 · 마이그레이션 적용 결과가 한 번 더 재현되는지 확인하세요.

실행 확인	단일 변경

4단계 · 운영 readback

실제 클라이언트 경로에서 Auth, Storage, Functions 요청을 다시 확인합니다.

이 항목의 4단계 · 운영 readback 단계에서는 오류 응답에 민감정보가 없는지 봅니다. 이때 다른 조건은 유지해야 4단계 · 운영 readback에서 생긴 차이를 분리해 확인할 수 있습니다.

실행 관점의 판정 신호는 운영 검증입니다. 4단계 · 운영 readback의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

4단계 · 운영 readback 확인은 오류 응답에 민감정보가 없는지 봅니다. 이후 운영 검증 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 4단계 · 운영 readback 결과가 한 번 더 재현되는지 확인하세요.

실행 확인	운영 검증

주의점: 잘못 적용하기 쉬운 부분

Supabase 적용 전 확인과 실행 중 확인을 분리해서 보세요. 아래 항목이 맞지 않으면 범위나 재시도 횟수를 늘리지 마세요.

서비스 키로만 테스트사용자 권한 문제를 놓칠 수 있습니다.
RLS를 나중으로 미루기운영 데이터가 쌓인 뒤 정책을 맞추면 위험과 비용이 커집니다.
스키마와 정책 동시 변경오류 원인이 구조인지 권한인지 분리하기 어렵습니다.
백업 존재만 확인복구 절차와 책임이 없으면 실제 장애 대응이 늦어집니다.
Storage 정책 누락파일 URL 접근이 데이터 정책과 다르게 열릴 수 있습니다.

상황별 적용: 같은 기준을 다르게 쓰는 법

사용자별 데이터 분리

같은 쿼리를 사용자별로 실행해 자신 행만 보이는지 확인합니다.

Supabase의 사용자별 데이터 분리 단계에서는 잘못된 행 접근은 즉시 차단하세요. 이때 다른 조건은 유지해야 사용자별 데이터 분리에서 생긴 차이를 분리해 확인할 수 있습니다.

상황 관점의 판정 신호는 행 단위 검증입니다. 사용자별 데이터 분리의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

사용자별 데이터 분리 확인은 잘못된 행 접근은 즉시 차단하세요. 이후 행 단위 검증 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 사용자별 데이터 분리 결과가 한 번 더 재현되는지 확인하세요.

상황 확인	행 단위 검증

스키마 변경 배포

마이그레이션 파일과 적용 로그를 남기고 rollback 가능성을 확인합니다.

이 항목의 스키마 변경 배포 단계에서는 데이터 손실 위험을 별도 표시하세요. 이때 다른 조건은 유지해야 스키마 변경 배포에서 생긴 차이를 분리해 확인할 수 있습니다.

상황 관점의 판정 신호는 변경 증거입니다. 스키마 변경 배포의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

스키마 변경 배포 확인은 데이터 손실 위험을 별도 표시하세요. 이후 변경 증거 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 스키마 변경 배포 결과가 한 번 더 재현되는지 확인하세요.

상황 확인	변경 증거

파일 업로드 기능

업로드, 조회, 삭제 권한을 Auth 상태별로 테스트합니다.

이 항목의 파일 업로드 기능 단계에서는 공개 파일과 비공개 파일을 분리하세요. 이때 다른 조건은 유지해야 파일 업로드 기능에서 생긴 차이를 분리해 확인할 수 있습니다.

상황 관점의 판정 신호는 Storage 경계입니다. 파일 업로드 기능의 실행 전후에 이 신호를 같은 위치에서 읽으면 추측 대신 관찰 결과로 판단할 수 있습니다.

파일 업로드 기능 확인은 공개 파일과 비공개 파일을 분리하세요. 이후 Storage 경계 상태를 기록하는 순서로 마칩니다. 이 주제의 다음 단계로 넘어가기 전에 파일 업로드 기능 결과가 한 번 더 재현되는지 확인하세요.

상황 확인	Storage 경계

근거를 읽는 방법과 확인 순서

Supabase 공식 문서는 Postgres 데이터베이스, Auth, Storage, Edge Functions 등 제품 영역을 나눠 설명합니다. 운영 검증은 대시보드 상태보다 역할별 요청 readback과 마이그레이션 기록이 기준입니다.

Supabase 근거는 수치 하나를 떼어 보기보다 측정 조건, 비교 대상, 적용 범위를 함께 읽어야 합니다. 짧은 소개 문구보다 공식 문서와 실제 실행 로그를 우선하면 판단 오류를 줄일 수 있습니다.

Supabase Docs – 제품 영역과 공식 문서 시작점
Supabase Database – Postgres 기반 데이터베이스 기능 확인
Supabase GitHub – 프로젝트와 오픈소스 구조 확인

Supabase에서 RLS는 꼭 켜야 하나요?

운영 데이터에서는 사용자별 접근 경계를 명확히 해야 하므로 테이블별 정책과 역할 테스트가 필요합니다.

서비스 키로 테스트하면 충분한가요?

아닙니다. 서비스 키는 일반 사용자 권한을 대표하지 않으므로 Auth 역할별 테스트가 필요합니다.

마이그레이션은 언제 기록해야 하나요?

스키마나 정책을 바꾸기 전후로 기록해야 운영 환경을 재현할 수 있습니다.

Storage 정책도 RLS와 같은가요?

역할은 비슷하게 보일 수 있지만 파일 접근 정책은 별도로 확인해야 합니다.

백업 확인은 어떻게 시작하나요?

백업 위치, 복구 절차, 책임자, 테스트 여부를 먼저 문서화하세요.

마무리: 오늘 바로 적용할 순서

Supabase 운영 점검은 스키마, RLS, Auth, 마이그레이션, Storage, Functions, 백업을 역할별 readback으로 확인하는 과정입니다. 오늘은 사용자 역할 하나를 정해 같은 요청의 성공과 실패 결과를 저장하세요.

Supabase은 한 문장으로 단정하기보다 확인할 항목을 순서대로 나누는 것이 핵심입니다. 첫 기록을 남기고 다음번 결과와 비교하면 구매, 사용, 보관에서 같은 실수를 반복할 가능성이 낮아집니다.