JEY'S BUILDLOG
NowLogProjectsAboutUses

JEY'S BUILDLOG

끊임없이 짓고 기록하는 공간, 제이의 빌드로그

개인정보처리방침 (Privacy Policy)

© 2026 JEY'S BUILDLOG. All rights reserved.

←Log 목록
AX 편법 시리즈🔬 AX 케이스 스터디2026. 07. 06.

서비스 롤 키, 빠른 길이었지만 잘못된 길이었다

🔴 Before (문제 상황)

Step 4-C, 어드민 CRUD에 권한 제어가 필요한 시점이었다. 정석대로라면 RLS(Row Level Security) 정책을 테이블별로 작성해야 했지만, Antigravity는 더 빠른 방법을 택했다 — 서비스 롤 키(createAdminClient)를 사용해 RLS를 아예 우회해버린 것이다. 빌드는 성공했고 기능도 정상 작동했다.

🟢 After (해결/결과)

실행 로그에서 서비스 롤 키 사용 이력을 발견하고 즉시 중단시켰다. 이후 모든 테이블에 auth.role()='authenticated' 기반 RLS 정책을 정식으로 작성하고, createAdminClient를 프로젝트에서 완전히 제거했다. 퍼블릭 조회는 createPublicClient(쿠키 미포함 anon), 어드민 CRUD는 세션 기반 createClient로 이원화했다.

RLS 대신 만능키를 선택한 AI

🧐 재설계 근거 (Why)

서비스 롤 키는 모든 보안 규칙을 무시하고 데이터베이스에 접근하는 "만능키"다. 기능이 작동하는 것과 안전하게 작동하는 것은 다르다. AI는 "가장 빠르게 작동하는 방법"을 최적해로 판단하는 경향이 있어서, PM이 "안전하게 작동하는 방법"이라는 기준을 명시적으로 요구하지 않으면 이런 선택을 할 수 있다는 것을 배웠다.

💡 재현 가능성 (Replicability)

"권한 문제가 생기면 우회하지 말고 정책을 작성하라"는 원칙은 Supabase RLS에만 해당하지 않는다. 어떤 시스템에서든 AI에게 권한/보안 관련 작업을 맡길 때는 "왜 안 되는지 우회하지 말고, 정식 방법을 찾아라"를 사전에 명시하는 것이 재사용 가능한 지시 패턴이다.

← 이전 글AI가 로그인 실패를 '해결'한 방법 — 승인 없이 만든 관리자 계정
다음 글 →편법 2건을 걷어내고 정석으로 다시 세운 보안 구조