Supabase RLS 가이드: anon key가 노출돼도 DB가 안전한 이유

TL;DR#

• 프론트엔드의 NEXT_PUBLIC_ 환경변수는 비밀이 아닙니다. Supabase anon key는 개발자 도구 네트워크 탭에서 누구나 볼 수 있습니다.
• 그래서 보안은 키를 숨겨서가 아니라 DB 내부의 RLS(Row Level Security, 행 수준 보안) 정책으로 챙겨야 합니다.
• RLS는 데이터 한 줄마다 보안 규칙을 적용하고, Supabase Auth의 auth.uid()로 로그인 유저를 기준으로 필터링합니다.
• 별도 백엔드 서버 없이 DB 엔진 수준에서 보안을 보장하지만, 정책이 켜져 있는데 SELECT 정책이 없으면 데이터가 빈 배열로 옵니다.

문제의 배경: 내 환경변수가 노출됐다#

주니어 개발자가 흔히 하는 오해 중 하나는 "프론트엔드의 .env 파일에 적어둔 환경변수는 비밀이다"라는 생각입니다. 하지만 Next.js에서 NEXT_PUBLIC_ 접두사를 붙이는 순간, 그 값은 빌드 타임에 자바스크립트 코드 안에 평문으로 박힙니다.

사용자가 사이트에 접속해 개발자 도구(F12)를 열고 네트워크 탭만 봐도, Supabase와 통신할 때 쓰는 anon key가 그대로 노출됩니다. 즉, 전 세계 누구나 여러분의 DB API 주소와 키를 알 수 있다는 뜻입니다. 아무런 조치도 하지 않았다면, 누군가 이 키로 DB 데이터를 삭제하거나 남의 비공개 글을 열람할 수 있습니다.

해결 방안 탐색: DB 내부의 지문 인식기, RLS#

선택지는 두 가지입니다.

1. 전통적인 백엔드 서버 구축: 모든 DB 요청을 중간 서버(NestJS 등)에서 검증합니다. 안전하지만 개발 속도가 느려집니다.
2. RLS(Row Level Security) 활용: Supabase(PostgreSQL)가 제공하는 엔진 레벨 보안 정책을 사용합니다. 백엔드 코드 없이도 DB가 스스로 "누가 이 데이터를 만질 수 있는지"를 판단합니다.

Supabase의 철학을 살리면서도 보안을 챙기는 정석적인 방법은 RLS를 활성화하는 것입니다.

핵심 개념 및 아키텍처#

RLS란 무엇인가#

RLS는 행 수준 보안(Row Level Security)의 약자로, 테이블 전체에 대한 권한이 아니라 데이터 한 줄(Row)마다 개별 보안 규칙을 적용하는 기술입니다.

• 동작 원리: 사용자가 쿼리를 날리면, DB 엔진은 실행 전에 설정된 Policy(정책)를 확인합니다.
• 인증 연동: Supabase Auth와 긴밀하게 연결되어, 현재 로그인한 유저의 ID(auth.uid())를 기준으로 필터링합니다.

아파트 비유로 이해하기#

• 테이블 권한: 아파트 단지 정문 열쇠. 열쇠만 있으면 모든 집을 들어갈 수 있어 위험합니다.
• RLS: 각 집 현관문의 지문 인식기. 단지 안에 들어왔어도 자기 집 지문이 있는 사람만 문을 열 수 있어 안전합니다.

구현 및 실무 패턴#

1) RLS 활성화하기#

가장 먼저 해당 테이블의 RLS를 켜야 합니다. 기본적으로 꺼져 있으면 무법지대입니다.

복사
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

2) 대표적인 보안 정책 패턴#

패턴 A: 모든 유저가 읽을 수 있지만, 작성자만 수정 가능#

블로그 포스트나 댓글 시스템에서 가장 흔히 쓰이는 방식입니다.

복사
-- 1. 모두에게 읽기 권한 허용
CREATE POLICY "전체 읽기 허용" ON posts
  FOR SELECT USING (true);

-- 2. 로그인한 작성자에게만 수정 권한 허용
CREATE POLICY "작성자만 수정 가능" ON posts
  FOR UPDATE USING (auth.uid() = author_id);

패턴 B: 본인 데이터만 생성 가능#

남의 이름으로 글을 쓰는 것을 방지합니다.

복사
CREATE POLICY "본인 글만 작성 가능" ON posts
  FOR INSERT WITH CHECK (auth.uid() = author_id);

3) 트러블슈팅: 분명 데이터가 있는데 안 보일 때#

RLS를 켜고 데이터를 조회했는데 빈 배열([])이 온다면, 해당 유저에게 허용된 Policy가 하나도 없기 때문입니다. RLS는 "허용되지 않은 모든 것은 거부한다"는 원칙으로 동작하므로, 반드시 SELECT 정책을 명시적으로 추가해야 합니다.

결과 및 Trade-off#

• 장점: 별도 백엔드 서버 없이도 강력한 보안을 유지하고, 개발 속도가 빨라집니다. DB 엔진 수준에서 작동하므로 보안 우회가 거의 불가능합니다.
• 단점: 정책이 복잡해질수록 SQL 문법이 난해해질 수 있고, 정책이 많이 얽히면 성능에 미세한 영향을 줄 수 있습니다. 다만 일반적인 서비스 규모에서는 체감하기 어렵습니다.

마치며#

"API 키는 공개되어 있다. 그러니 보안은 DB 내부에서 챙긴다." 이것이 Supabase 환경에서의 올바른 보안 마인드셋입니다.

환경변수에 anon key를 넣는 것은 보안을 위해서가 아니라 관리를 위해서라는 점을 기억하면 좋겠습니다. 진짜 보안은 정성스럽게 작성한 RLS Policy 한 줄에서 시작합니다. 지금 여러분의 Supabase 대시보드에서 RLS가 켜져 있는지 확인해 보세요.