바이브코딩·AI ·
바이브코딩으로 만든 앱, DB가 열려 있는지 5분 안에 확인하기
Supabase 로 만든 서비스라면 테이블마다 RLS 가 켜져 있어야 해요. 내 프로젝트의 Security Advisor 에서 열린 테이블을 찾고, AI 에게 무엇을 고쳐 달라고 할지 정리했어요.
바이브코딩으로 만든 서비스가 털렸다는 이야기가 자주 들려요. 들여다보면 어려운 해킹이 아닌 경우가 많아요. 데이터베이스 권한 설정 하나가 빠져 있었어요.
2026년 1월, 보안 기업 Wiz 가 AI 에이전트 소셜 서비스 Moltbook 의 문제를 알렸어요. Supabase 로 만든 서비스였고, RLS 라는 권한 설정이 빠져 있었어요. 브라우저 코드에 든 키만으로 데이터베이스를 읽고 쓸 수 있었어요. Wiz 는 API 키 150만 개와 사용자 이메일 3만 5천 개가 노출됐다고 밝혔어요. 운영자는 연락을 받고 곧 막았어요.
이 글은 내 프로젝트를 점검하는 방법이에요. 코드를 몰라도 5분이면 돼요.
"DB 가 열려 있다"는 게 무슨 뜻인가요
Supabase 는 브라우저가 데이터베이스에 바로 요청하는 구조예요. 그래서 브라우저 코드에 프로젝트 주소와 키가 들어가요. 이 키는 원래 공개돼도 되는 키예요.
대신 테이블마다 "누가 어떤 줄을 보고 고칠 수 있는지" 규칙을 둬요. 이 규칙이 RLS(Row Level Security)예요.
아파트로 비유하면 이래요.
- 공개 키는 공동현관 비밀번호예요. 입주민이 다 알아요.
- RLS 는 집집마다 달린 현관 잠금장치예요.
- 잠금장치가 없으면 공동현관만 통과한 사람이 모든 집에 들어가요.
Supabase 공식 문서도 같은 말을 해요. RLS 가 꺼진 public 테이블은 프로젝트 주소를 아는 누구나 모든 데이터를 읽고, 고치고, 지울 수 있다고요.
5분 안에 어떻게 확인하나요
세 단계예요. 전부 내 Supabase 대시보드 안에서 해요.
1단계 — Security Advisor 를 열어요 (1분)
대시보드에 로그인해 프로젝트를 골라요. Security Advisor 화면을 열어요. 주소 끝이 /advisors/security 인 화면이에요. ERROR 로 뜬 항목부터 봐요.
| 화면에 뜨는 이름 | 수준 | 뜻 |
|---|---|---|
| Table publicly accessible | ERROR | RLS 가 꺼진 public 테이블이에요. 누구나 읽고 · 고치고 · 지울 수 있어요. |
| Sensitive data publicly accessible | ERROR | 민감해 보이는 칸이 있는 테이블이 보호 없이 열려 있어요. |
| View bypasses row-level security | ERROR | 뷰가 높은 권한으로 돌아서 RLS 를 건너뛰어요. |
| Security policy relies on user-editable data | ERROR | 사용자가 직접 바꿀 수 있는 값으로 권한을 판단해요. |
| Security policy not enforced | INFO | 규칙은 만들었는데 RLS 를 안 켰어요. 규칙이 작동하지 않아요. |
| No access rules defined | INFO | RLS 는 켰는데 규칙이 없어요. 새지는 않지만 화면이 비어 보일 수 있어요. |
첫 줄이 가장 흔해요. 검색하면 「RLS disabled in public」이라는 이름으로도 많이 나와요.
2단계 — 테이블 목록을 한 번 더 봐요 (2분)
SQL Editor 에서 아래를 실행해요. 읽기만 하는 쿼리라 데이터는 바뀌지 않아요.
select tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;
rowsecurity 가 false 인 줄이 RLS 가 꺼진 테이블이에요.
왜 꺼져 있을까요? 대시보드 화면에서 만든 테이블은 RLS 가 기본으로 켜져요. SQL Editor 나 다른 도구로 만든 테이블은 직접 켜야 해요. AI 에게 시켜 SQL 로 만든 테이블이 여기에 들어가요.
Supabase 는 2026년 5월 30일부터 새 프로젝트에서 새 테이블이 API 에 자동으로 열리지 않게 바꾸기 시작했어요. 10월 30일부터는 기존 프로젝트의 새 테이블에도 적용돼요. 하지만 이미 있는 테이블은 그대로 열려 있어요. RLS 가 하는 일도 그대로라서 이 점검은 계속 필요해요.
3단계 — 키와 파일을 봐요 (2분)
Settings → API Keys 에서 키 종류를 확인해요.
| 키 | 브라우저 코드에 있어도 되나요 |
|---|---|
publishable 키 (sb_publishable_) · 예전 anon 키 |
돼요. 단, 모든 테이블에 RLS 가 켜져 있어야 해요. |
secret 키 (sb_secret_) · 예전 service_role 키 |
안 돼요. RLS 를 건너뛰고 모든 데이터에 접근해요. |
secret 키가 코드에 들어갔는지는 AI 에게 물어보세요.
이 프로젝트에서 sb_secret_ 로 시작하는 키나 service_role 키가 브라우저로 가는 코드, 또는 저장소에 올라간 파일에 들어 있는지 찾아 줘. 키 값은 화면에 보여 주지 말고 파일 위치만 알려 줘.
파일 저장소(Storage)도 봐요. 버킷이 Public 이면 파일 주소를 아는 누구나 내려받을 수 있어요. 신분증 · 계약서 같은 개인 파일은 Private 버킷에 둬요.
secret 키가 새어 나갔다면 어떻게 하나요
공식 문서가 권하는 순서예요.
- 서두르지 말고 새는 원인부터 고쳐요. 코드나 저장소에서 키를 빼요.
- Settings → API Keys 에서 새 secret 키를 만들어요.
- 키를 쓰는 곳을 전부 새 키로 바꿔요.
- 옛 키를 지워요. 예전
service_role키라면 비활성화해요.
경고가 떴다면 AI 에게 무엇을 시키나요
"RLS 켜 줘"만 시키면 안 돼요. RLS 만 켜고 규칙이 없으면 공개 키로는 아무것도 못 읽어요. 서비스 화면이 갑자기 비어요.
그래서 규칙부터 정해요. 코드가 아니라 운영 결정이에요.
- 로그인 안 한 사람은 무엇을 볼 수 있나요? 예: 공개 상품 목록
- 로그인한 사람은 자기 데이터만 보나요?
- 누가 쓰고, 고치고, 지울 수 있나요?
- 관리자는 누구이고, 무엇으로 판별하나요?
그다음 이렇게 시켜요.
Supabase Security Advisor 에 ERROR 로 뜬 테이블이야: (테이블 이름)
1. 테이블마다 지금 화면에서 어떻게 읽고 쓰는지 먼저 정리해 줘.
2. 누가 무엇을 읽고 쓸 수 있어야 하는지, 내가 정하지 않은 게 있으면 먼저 질문해 줘.
3. 답을 받은 뒤 RLS 를 켜고 정책을 만들어 줘. 로그인한 사용자는 자기 데이터만 다루게 해 줘.
4. 관리자 여부는 사용자가 바꿀 수 있는 값으로 판단하지 마.
5. 실서버에 적용하기 전에 테스트용 프로젝트에서 확인하는 순서를 알려 줘.
고친 뒤에는 Security Advisor 를 다시 열어 ERROR 가 사라졌는지 봐요. 그리고 내 서비스를 두 가지 상태로 직접 써 보세요. 로그아웃한 상태, 다른 테스트 계정으로 로그인한 상태요.
경고가 없으면 안심해도 되나요
아니요. RLS 가 켜져 있어도 규칙 내용이 느슨하면 소용없어요. 모든 사람에게 읽기를 허용하는 규칙처럼요. 이 밖에도 자주 빠지는 게 있어요.
- 권한 확인을 브라우저에서만 해요. 관리자인지 브라우저 저장값으로 판단하면 사용자가 값을 바꿔 관리자가 돼요.
- 서버 함수에서 secret 키를 쓰면서 권한 확인을 빼먹어요. 공식 문서는 secret 키를 자체 권한 확인이 있는 서버 코드에서만 쓰라고 해요.
- API 키를 코드에 직접 적어요. 저장소에 올라가면 퍼져요.
AI 는 새 코드를 짤 때 보안을 자주 놓쳐요. 대신 이미 있는 코드에서 문제를 찾는 건 꽤 잘해요. "이 코드에 인증 우회, 권한 확인 누락, 코드에 적힌 비밀 정보가 있는지 검토해 줘"라고 물어보세요.
솔직히 RLS 는 개발자에게도 어려워요. 저도 Supabase 로 만들 때 RLS 를 신경 써서 짰고, 같이 일하는 개발자들을 따로 훈련시켰어요. SQL 을 깊이 다루지 못하는 개발자를 위해 규칙을 만들어 주는 내부 도구까지 만들었어요.
다른 사람 서비스도 이렇게 확인해도 되나요
안 돼요. 이 글의 방법은 내 대시보드에 로그인해서 하는 점검이에요. 허락 없이 남의 서비스에 접근해 데이터를 확인하면 법적 책임을 질 수 있어요.
지인 서비스가 걱정되면 이 글을 보내 주세요. 대시보드 주인이 직접 확인하면 돼요.
브라우저가 DB 에 바로 붙는 구조, 계속 써도 될까요
RLS 를 제대로 설계하는 개발자에게는 좋은 선택이에요. 다만 비개발자가 AI 로 만든다면 구조부터 따져 볼 만해요.
| 브라우저 → DB (Supabase 등) | 브라우저 → 서버 → DB (레일즈 등) | |
|---|---|---|
| 권한을 정하는 곳 | 테이블마다 RLS 규칙 | 서버 코드 한 곳 |
| 권한 확인을 빠뜨리면 | 그 테이블 전체가 인터넷에 열려요 | 그 화면에서 새요 |
| 점검할 곳 | 대시보드 설정 + 앱 코드 | 앱 코드 |
| 규칙 쓰는 법 | SQL 로 써요 | 모델 · 컨트롤러 코드로 써요 |
레일즈 같은 풀스택 프레임워크는 모델이 데이터베이스를 한 번 감싸요. 브라우저는 데이터베이스에 직접 닿지 않아요.
- 허용한 입력만 저장해요. 사용자가 브라우저에서 "결제 완료" 같은 값을 몰래 끼워 보내도 무시해요.
- 흔한 공격을 기본으로 막아요. SQL 인젝션 · 크로스사이트 스크립팅이요.
- 권한 확인이 서버 한 곳에 모여요. AI 도 한 프로젝트 안에서 모델과 컨트롤러를 읽고 문제를 찾아요.
레일즈가 아니어도 라라벨 · 장고 · 스프링처럼 모델이 데이터베이스를 감싸는 프레임워크면 같은 장점이 있어요. 왜 레일즈를 고르는지는 왜 루비온레일즈인가에 정리했어요.
혼자 고치기 어렵다면
4시간 세션에서 화면을 같이 보며 지금 권한 구조를 점검해요. 필요하면 그 자리에서 레일즈로 다시 세워요. 로그인 · 결제 · 관리자 화면까지 실서버에 올라가요.
- 4시간 한 세션에 440만 원(부가세 포함)이에요. 2026년 9월 기준이에요.
- 소스코드와 저작권 전부, 서버 · 도메인 계정까지 대표님 명의로 넘겨요.
권한 말고도 출시 전에 확인할 게 남았다면 출시 못 하는 나머지 20%를 같이 보세요. 지금 서비스가 4시간 분량인지는 셀프 견적에서, 바로 진행하려면 예약 신청에서 시작하면 돼요.
참고한 공식 문서예요. 2026년 9월 기준이에요.
- Supabase — Security Advisor 경고 목록
- Supabase — Table publicly accessible (rls_disabled_in_public)
- Supabase — Row Level Security
- Supabase — Securing your API (대시보드에서 만든 테이블의 RLS 기본값)
- Supabase — API Keys (키 종류 · 유출 시 교체 순서)
- Supabase — Storage 버킷 (Public · Private)
- Supabase 변경 공지 — 새 테이블이 API 에 자동으로 열리지 않아요
- Wiz — Moltbook 데이터베이스 노출 보고서
이 글은 유튜브 영상 다섯 편을 정리한 거예요.
- Moltbook 150만 API 키 유출 사건으로 배우는 Supabase RLS 보안 필수 설정법
- 비상! Supabase 취약점을 조심하세요. 바이브코딩은 이 기술로 하세요
- 바이브코딩 앱 보안 결함, 해킹당하기 전 꼭 확인할 3가지
- 클로드 코드에 멀티 페르소나 에이전트 + 레일즈 MCP 세팅하는 법, Kamal 배포 설명
- Rails 8 이 PostgreSQL 대신 SQLite 를 권하는 진짜 이유
쓴 사람 — 제임스
연세대 컴퓨터과학을 전공한 23년차 개발자예요. React · Next.js 를 오래 썼고, Svelte 와 Supabase 로 2년쯤 만들다 레일즈로 정착했어요. 개발 에이전시를 운영하며 스타트업 플랫폼 350개를 만들었고, 3,000명에게 개발과 바이브코딩을 가르쳤어요.