(2) RLS부터 심는다 — 권한이 화면 뒤에서 일어나려면

커뮤니티 서비스는 게시글 하나에 조회 권한이 얽힌다 — 팔로우/친구/차단/모더레이터 등. 이걸 화면 코드에 분기로 심으면 사고 대열이 무한하다. 이 프로젝트는 Postgres RLS를 제일 먼저 심었다 — 화면은 권한을 몰라도 조회 자체가 필터된 채 돌아온다. 화면이 실수하면 침묵으로 막힌다. "화면이 맞는데 권한이 뚫리는" 실수가 더 큰 사고다. 규칙 한 개는 깨지 않는다: 세션 변수는 반드시 트랜잭션 안에서 set_config(..., true)(is_local)로 주입한다. 세 번째 인자 true가 없으면 PgBouncer 트랜잭션 모드에서 다음 요청이 앞 사용자의 권한을 상속한다 — 화면상 아무 증상이 없다. 커넥션 역할도 격리시켰다 — 앱은 비소유 롤풀(app_exists/app_arrays)로만 붙는다. 소유자(community_owner)로 붙으면 FORCE ROW LEVEL SECURITY마저 무력화되어 조회는 필터 없이 넘어간다. owner 롤은 마이그레이션·배치 전용으로 고립했다. "화면이 멀쩡한데 권한이 파열된다" 실무 사례는 전부 실물 관찰이었다. 아쉬운 것 — 정책이 두 세트(배열 변형·EXISTS 변형)로 유지된다. 같은 논리를 두 곳에서 유지하는 건 부담이지만, 동일 SQL을 두 방식으로 쓰는 선택은 성능 트레이드오프 문제라 운영 실험으로만 해소될 문제다.