🍊 기초(LV28)#바이브코딩#Supabase#RLS#보안#데이터베이스#비개발자
5분·2026. 4. 9.·조회 27
오늘도 AI 한입 하세요 🍊
새 아티클이 발행되면 이메일로 알려드릴게요.
댓글을 남기려면 로그인이 필요합니다.
아직 댓글이 없습니다. 첫 댓글을 남겨보세요!
API(에이피아이)란 프로그램끼리 데이터를 주고받는 통로입니다. 카카오 로그인, 날씨 앱, 배달 앱 결제까지 — 비개발자도 이미 매일 쓰고 있는 API의 뜻과 원리를 쉽게 설명합니다.
클로드 코드(Claude Code)가 파일 수정할 때마다 Yes를 물어봐서 답답하다면, 권한 자동 허용(bypassPermissions)을 켜면 됩니다. 설정법부터 Shift+Tab 전환, 위험성, plan mode 활용, settings.json 영속화까지 한 글로 끝냅니다.
클로드 코드(Claude Code)에게 매번 같은 커밋·PR·배포 지시를 반복하고 계신가요? 클로드 코드 스킬(Claude Code Skill)을 직접 만들면 /commit, /pr, /deploy 같은 한 단어 명령으로 반복 업무를 끝낼 수 있습니다. 슬래시 커맨드와의 통합, 5분 핸즈온, 자동 호출 트리거, 인자 처리, 실시간 컨텍스트 주입까지 한 번에 정리합니다.
클로드 코드에서 매번 똑같은 지시를 반복 중이라면, 스킬·커맨드·서브에이전트·에이전트팀 중 뭘 써야 할지 헷갈릴 때가 옵니다. 이 글에서 네 가지 사용법과 선택 기준을 한 번에 정리합니다.
Supabase(수파베이스)로 서비스를 만들기 시작하면 대시보드에 위와 같은 노란 경고가 뜹니다. "RLS is not enabled on these tables."
RLS는 Row Level Security의 줄임말입니다. 직역하면 "행 단위 보안"인데, 쉽게 말하면 "데이터 한 줄 한 줄에 자물쇠를 거는 것"입니다.
이 경고를 무시하고 넘어가는 분이 많습니다. 서비스가 잘 돌아가니까요. 하지만 이 경고를 무시하면, 내 서비스에 가입한 모든 사용자의 데이터가 다른 사용자에게 그대로 노출될 수 있습니다.
Supabase의 가장 큰 단점으로 꼽히는 것이 바로 이 보안 문제입니다. 결론부터 말씀드리면, RLS는 "내 데이터는 나만 볼 수 있게" 만드는 장치입니다. 이름은 어려워 보이지만 개념은 단순합니다.
택배 보관함을 떠올려 보겠습니다.
아파트에 사는 분이라면 1층 택배 보관함을 쓰셔봤을 겁니다.
모든 세대의 택배가 같은 보관함에 들어갑니다.
김철수의 택배는 1번 칸에 들어갑니다.
이영희의 택배는 2번 칸, 박지민의 택배는 3번 칸에 들어갑니다. 모든 택배가 같은 보관함 안에 있지만, 각자의 칸에 나뉘어 있습니다.
그리고 각 칸마다 자기만의 열쇠가 있습니다.
김철수는 자기 열쇠로 1번 칸만 열 수 있습니다. 옆집 이영희의 2번 칸은 열 수 없고, 박지민의 3번 칸도 열 수 없습니다.
이것이 RLS입니다. Supabase 사용법 중 가장 먼저 알아야 할 보안 설정입니다.
만약 보관함에 자물쇠가 없다면 어떻게 될까요?
아무나 아무 칸이나 열어서 남의 택배를 가져갈 수 있습니다. 김철수가 이영희의 택배를 가져가도, 모르는 사람이 박지민의 택배를 가져가도, 막을 방법이 없습니다.
RLS를 끈 상태가 바로 이것입니다. 보관함 문을 전부 열어놓은 것과 같습니다.
보관함 앞에 "본인 것만 가져가세요"라는 안내문을 붙여놓으면 해결될까요? 양심적인 사람은 지키겠지만, 무시하면 그만입니다.
진짜 해결책은 각 칸에 자물쇠를 거는 것입니다. 안내문이 아니라 자물쇠입니다. 맞는 열쇠가 없으면 아무리 시도해도 열리지 않습니다.
지금까지 택배 보관함 이야기를 했습니다. 이제 실제 데이터베이스가 어떻게 생겼는지 살펴보겠습니다.
데이터베이스는 여러 개의 테이블(표)로 이루어져 있습니다. users 테이블, posts 테이블, comments 테이블처럼 종류별로 나뉘어 있습니다.
users 테이블을 열어보면, 모든 사용자의 데이터가 한 줄씩 나란히 들어있습니다. 택배 보관함에 모든 세대의 택배가 들어있는 것과 같습니다.
여기서 RLS를 켜면 각 줄마다 자물쇠가 걸립니다. 김철수가 로그인하면, 김철수의 줄만 열 수 있습니다. 이영희의 데이터, 박지민의 데이터는 아예 보이지 않습니다.
RLS를 켜면, 다음 단계로 정책(Policy)을 만들어야 합니다. 정책은 "누가 어떤 데이터에 접근할 수 있는지"를 정한 규칙입니다. 택배 보관함으로 치면, "열쇠가 맞는 칸만 열 수 있다"는 규칙을 명시적으로 적어놓는 것입니다.
가장 흔한 정책은 이렇습니다.
"로그인한 사용자의 ID와 데이터의 user_id가 같은 경우에만 읽을 수 있다."
쉽게 말하면, "김철수가 로그인했으면, 김철수 데이터만 보여줘라"입니다.
이 규칙 한 줄이 RLS 정책의 핵심입니다. 데이터베이스가 모든 요청마다 이 규칙을 자동으로 검사합니다. 앱 코드에서 실수로 필터를 빠뜨려도, 데이터베이스가 마지막 관문에서 걸러줍니다.
Supabase 대시보드에서 RLS를 켜는 방법은 간단합니다. Table Editor로 이동해서, 보호할 테이블을 선택합니다. 상단에 보이는 "RLS disabled" 경고를 클릭하고 Enable RLS를 누르면 됩니다. 이것만으로 테이블에 자물쇠가 걸립니다.
그런데 여기서 한 가지 주의할 점이 있습니다.
RLS를 켜기만 하고 정책을 안 만들면, 아무도 데이터에 접근할 수 없게 됩니다. 보관함 전체에 자물쇠를 걸어놓고 열쇠를 아무에게도 안 알려준 것과 같습니다.
RLS를 켠 직후에는 반드시 정책을 함께 추가해야 합니다.
"개발 중이니까 나중에 켜야지." 이 생각으로 서비스를 배포하면, 누구나 anon key 하나로 모든 사용자의 데이터를 그대로 가져갈 수 있습니다. 위 화면은 anon key로 users 테이블을 호출했을 때 실제로 돌아오는 응답입니다. 김철수, 이영희, 박지민의 이메일까지 전부 그대로 노출됩니다.
켜기만 하면 안전할 거라 생각하지만, 정책 없이 RLS를 켜면 PostgreSQL이 모든 접근을 거절합니다. 서비스가 갑자기 빈 배열 []만 돌려보내기 시작합니다. "왜 데이터가 안 오지?" 싶을 때 가장 먼저 의심해야 할 부분입니다.
RLS를 켜고 정책까지 추가하면, 로그인한 사용자의 ID와 일치하는 행만 응답에 포함됩니다. 이것이 유일하게 안전한 상태입니다.
| 상태 | 결과 |
|---|---|
| RLS 끔 | 모든 데이터가 모두에게 공개 |
| RLS 켬 + 정책 없음 | 아무도 데이터에 접근 못 함 |
| RLS 켬 + 정책 있음 | 규칙에 맞는 데이터만 접근 가능 |
RLS는 데이터베이스의 행(row) 단위 자물쇠입니다.
택배 보관함에 자물쇠를 거는 것처럼, 데이터베이스 테이블에 접근 규칙을 설정하는 장치입니다. Supabase 사용법의 첫 번째 단계라고 해도 과언이 아닙니다.
이것만 기억하시면 됩니다.
다음 글에서 Supabase 대시보드에서 RLS 정책을 직접 설정하는 방법을 다룹니다.
