RLS는 최종 경계로만: 복잡한 인가를 서버 코드로 되돌린 이유

인가 로직을 AI 코딩 도구한테 맡기면, 대개 RLS 정책부터 늘어놓기 시작해요. "이 조건은 정책에, 저 조건도 정책에" 하다 보면 정책 하나에 분기가 네다섯 개씩 쌓이죠. 처음엔 깔끔해 보이는데, 막상 테스트를 짜려고 하면 손이 멈춰요.

혹시 인가 규칙을 고칠 때마다 실제 DB를 띄워야만 확인이 되는 상황, 겪어보셨나요?

AI가 RLS에 다 몰아넣는 이유

프롬프트에 "권한 체크 넣어줘"라고만 쓰면, 모델은 가장 가까운 경계인 RLS 정책에 조건을 붙이려 해요. 무료 티어 여부, 소유권, 팀 역할, 상태값까지 한 policy의 조건절 안에 다 들어가죠. 직접 짜 보니 조건이 4개만 넘어가도 SQL 한 줄이 사람 눈으로 읽기 힘든 길이가 되더라고요.

문제는 이걸 단위 테스트로 검증할 방법이 마땅치 않다는 거예요. RLS는 세션 컨텍스트와 실제 로우가 있어야 동작해서, 규칙 하나 바꿀 때마다 DB를 띄우고 시드를 넣어야 확인이 됩니다.

서버 코드로 되돌린 방식

그래서 복잡한 판단은 서버 코드로 옮겨 봤어요. 흐름은 세 단계예요.

요청→서버에서 인가 판단(단위 테스트 가능)→RLS 최종 소유권 확인

서버 함수 하나에 역할·티어·상태 분기를 모으니, 순수 함수라 목 데이터로 테스트가 바로 돌아가요. 적용해 봤더니 규칙 하나 고치고 확인하는 데 걸리던 시간이 눈에 띄게 줄었어요. DB를 띄우던 걸 15분쯤 잡았다면, 이제 테스트 한 번으로 몇 초면 끝나요.

RLS는 최종 경계로만

그렇다고 RLS를 지우는 건 아니에요. 서버 코드에 구멍이 나도 남의 데이터가 새지 않도록, RLS는 "이 로우가 이 사용자 소유인가" 같은 최소 조건만 남겨 뒀어요. 앱 경로가 뚫려도 마지막에 막아주는 그물인 셈이죠.

• ✓복잡한 분기는 서버
• ✓RLS는 소유권 최종 확인
• ✓정책엔 업무 규칙 넣지 않기

플랜엘(plan-l)처럼 월 3건 무료 같은 티어 규칙이 있는 서비스에선 이 구분이 특히 편해요. "무료 한도를 넘었나" 판단은 서버에서 테스트로 지키고, "내 검색 기록만 보이나"는 RLS로 지키면 각자 잘하는 자리에 놓이거든요.

AI한테 인가를 맡길 땐 프롬프트에 "복잡한 판단은 서버 함수로, RLS는 소유권 확인만"이라고 경계를 먼저 그어줘 봤어요. 돌려 보니 결과가 훨씬 안정적이더라고요. 도구가 똑똑해도 어디에 무엇을 둘지는 사람이 정해주는 게 맞았어요.