AI 빌더로 앱을 만들어본 경험이 있다면 이 장면이 낯설지 않을 것이다. 프리뷰에서는 완벽하게 동작하던 화면이 실제 배포 URL을 열자마자 텅 비어버린다. 콘솔에는 permission denied for table profiles 또는 code: 42501이 찍혀 있다. 코드는 한 줄도 바꾸지 않았는데.
dev.to에 올라온 Supabase RLS 배포 오류 분석 글은 이 현상의 구조를 명쾌하게 짚는다. AI 빌더는 프론트엔드를 빠르게 완성하지만, 앱과 데이터베이스 사이의 보안 경계를 절반만 완성한 채 멈추는 경우가 많다. Supabase는 기본적으로 RLS(Row Level Security)를 활성화하고, 정책은 auth.uid() = user_id 형태로 인증된 사용자만 자신의 데이터에 접근하도록 설계된다. 문제는 프리뷰 환경에서는 개발자의 세션이 자동으로 실려나갔던 요청이, 프로덕션 서버에서는 익명 클라이언트로 Supabase에 도달한다는 점이다. auth.uid()가 null이 되면 RLS 정책은 정확히 제 역할을 하며 접근을 차단한다. 보안이 작동한 것이지 버그가 아니다. 하지만 이 사실을 모르면 "아무것도 안 바꿨는데 왜 터지나"라는 미로에 빠진다.
해결 방향은 분명하다. Next.js + Supabase 조합이라면 서버 라우트나 Server Action에서 요청 범위(request-scoped) 서버 클라이언트를 사용해 인증 쿠키를 읽고, 미들웨어에서 세션을 갱신해 프로덕션 도메인에서도 쿠키가 유효하게 유지해야 한다. 그리고 RLS 정책이 실제 접근 패턴과 일치하는지, 프로덕션 도메인이 Supabase Auth 리다이렉트 허용 목록에 등록되어 있는지를 반드시 확인해야 한다. 이 글이 특히 강조하는 것은 "RLS를 끄거나 서비스 롤 키를 브라우저에 노출하는 방식으로 오류를 우회하지 말라"는 경고다. 오류 메시지가 거슬리더라도 그것은 데이터베이스가 당신을 지키고 있다는 신호다.
이 배포 오류가 단순한 설정 실수처럼 보일 수 있지만, 실제로는 AI 빌더의 구조적 한계를 드러내는 사례다. AI는 눈에 보이는 UI 레이어를 빠르게 완성한다. 하지만 인증 흐름, 데이터베이스 보안 경계, 서버-클라이언트 컨텍스트 분리처럼 배포 환경의 맥락이 달라질 때 드러나는 레이어는 AI가 자동으로 완결 짓지 못한다. 이 공백은 개발자가 설계 판단자로서 채워야 한다.
같은 맥락의 다른 신호가 중국 최대 음식 배달 플랫폼 메이투안(Meituan)의 사례에서도 포착됐다. 소셜 미디어에 삭제 버튼이 화면 절반을 차지하는 거대한 빨간 블록으로 변한 UI 스크린샷이 퍼지면서 댓글란이 들끓었다. "프론트엔드 개발자를 다시 데려와라