Supabase RLS 설계 시 실제로 실수한 패턴 3가지

[예시 글] 실제 프로젝트에서 겪은 RLS 관련 실수를 정리했어요.

실수 1: CREATE TABLE 후 명시적 REVOKE를 안 했어요

Supabase에서 CREATE TABLE을 하면 anon과 authenticated 롤에 자동으로 ALL privileges가 부여돼요. RLS를 켜도 이 기본 grant가 남아 있어요.

-- 테이블 생성 직후 반드시 실행
REVOKE ALL ON TABLE public.user_health_logs FROM anon, authenticated;
 
-- 필요한 권한만 다시 부여
GRANT SELECT, INSERT, UPDATE ON TABLE public.user_health_logs TO authenticated;

RLS만 설정하고 REVOKE를 안 하면, RLS 정책이 우회될 수 있는 상황이 생길 수 있어요.

실수 2: auth.uid() 패턴 혼동

RLS 정책에서 현재 사용자를 확인할 때 올바른 패턴을 써야 해요:

-- 올바른 패턴 (Supabase 2026 기준)
CREATE POLICY "users see own data"
ON public.user_health_logs
FOR SELECT
TO authenticated
USING ((SELECT auth.uid()) = user_id);

auth.uid()를 서브쿼리로 감싸는 게 성능상 더 좋아요. 매 행마다 함수를 호출하는 대신 한 번 평가해서 재사용하거든요.

실수 3: 마이그레이션 파일 존재 ≠ DB 적용

마이그레이션 파일을 만들었다고 DB에 적용된 건 아니에요. Supabase CLI로 실제 적용됐는지 확인해야 해요:

# 적용 상태 확인
supabase db diff
 
# 또는 직접 쿼리
SELECT tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public';

정리

RLS 설계 순서: REVOKE 먼저 → RLS ENABLE → 정책 추가 → DB에서 확인. 이 순서를 지키면 대부분의 함정을 피할 수 있어요.