💡 학습 개념 정의

• 핵심 키워드: RLS (Row Level Security), Postgres, Supabase, anon/authenticated role
• 한 줄 정의: 테이블의 행(row) 단위로 "누가 어떤 조건에서 읽고 쓸 수 있는지"를 DB 자체가 직접 판단하는 접근 제어 방식.

📝 상세 학습 내용

1. 도입 배경 (Why?)

• 일반적인 백엔드 구조에서는 서버가 DB 앞 문지기 역할을 한다. 브라우저 → 서버 → DB 순으로 거치며, 권한 체크("로그인했나? 볼 자격 있나?")는 서버 코드에서 처리한다.
• 그러나 Supabase는 브라우저가 anon 키를 들고 DB에 거의 직접 접근하는 구조다. 중간 서버 코드 없이도 supabase.from('products').select() 같은 호출이 클라이언트에서 바로 나간다.
• 편리하지만, 키만 있으면 누구나 DB를 직접 긁을 수 있어 위험하다. 그래서 권한 체크를 서버가 아니라 DB 자신이 하도록 한 것이 RLS다. 서버를 우회해 들어와도 DB 레벨에서 막는다.

2. 핵심 원리 및 특징 (What?)

• Postgres가 제공하는 기능으로, 테이블에 RLS를 enable하면 기본값은 "전부 차단"이다. 정책(policy)을 명시적으로 만들어야 그만큼만 열린다. (정책 없는 테이블에 접근하면 permission denied)
• Supabase는 미리 정의된 role을 둔다:
  • anon: 익명(비로그인)
  • authenticated: 로그인 사용자
  • service_role: 모든 정책을 무시하는 관리자 (서버에서 secret 키로만 사용)
• 요청이 들어오면 어떤 키로 왔는지에 따라 role이 정해지고, 그 role에 허용된 정책만 적용된다. 여기까지는 HTTP에서 role 기반 권한과 발상이 같다.
• 차이점이자 핵심: 행 단위 조건을 걸 수 있다. "전부 아니면 전무"가 아니라, 같은 테이블·같은 role이라도 행마다 다르게 거를 수 있다. (이름이 Row Level Security인 이유)

3. 실제 활용 예시 (How?)

-- products: 익명 손님도 상품 조회는 허용
alter table products enable row level security;
 
create policy "anyone can read products"
  on products for select
  to anon
  using (true);
 
-- insights: 로그인 사용자가 '자기 소유 행'만 조회 (행 단위 격리)
alter table insights enable row level security;
 
create policy "owner reads own insights"
  on

• 두 번째 정책의 using (auth.uid() = owner_id)가 행 단위 격리의 핵심. 사장님 A는 자기 분석만 보고, 사장님 B의 행은 같은 쿼리를 날려도 결과에서 빠진다.

🔍 심화 학습 (Deep Dive)

• Q. RLS를 enable만 하고 정책을 안 만들면? A. 모든 접근이 차단된다. enable = "이제부터 정책으로만 통과", 정책 없음 = "통과 경로 없음". (단 service_role은 RLS를 무시하므로 서버에서는 계속 접근 가능)
• Q. using과 with check의 차이는? A. using은 읽기/대상 행 선별(select·update·delete 시 어떤 행이 보이나), with check는 쓰기 시 검증(insert·update할 값이 조건을 만족하나). insert 정책엔 보통 with check를 쓴다.
• Q. anon에게 conversations insert를 열어주면 위험하지 않나? A. 위험 여지가 있다(누구나 행을 만들 수 있음). 데모 단계라 단순하게 열되, 실서비스라면 visitor 단위 격리, rate limit, 봇 차단 등이 필요하다. → 트레이드오프를 인지하고 의도적으로 단순화한 것.

📌 오늘의 핵심 요약

• RLS는 권한 체크의 책임을 "서버 코드"에서 "DB 자신"으로 옮긴 것. Supabase처럼 클라이언트가 DB에 직접 접근하는 구조에서 필수.
• role(anon/authenticated/service_role)에 따라 정책을 적용하되, 행 단위 조건까지 걸 수 있는 게 HTTP 권한 체크와의 결정적 차이.
• enable 시 기본은 전면 차단. 필요한 만큼만 정책으로 명시적으로 연다.