Supabase Clerk 연동: RBAC 설계와 RLS 정책

 

클라우드 네이티브 환경은 더 이상 단일 서비스가 모든 기능을 독점하는 구조를 지양합니다. 우리는 필요한 기능을 모듈처럼 조립하는 '모듈형 백엔드' 시대를 살고 있으며, 그 중심에는 인증(Authentication)과 데이터 관리(Data Management)의 완벽한 결합이 있습니다. 특히 기업용 SaaS나 복잡한 관리자 시스템을 구축할 때, 사용자 경험이 뛰어난 Clerk을 '신분증 발급처(Identity Issuer)'로 활용하고, 강력한 DB 엔진인 Supabase를 '보안 구역(Secure Zone)'으로 설정하는 전략이 각광받고 있습니다. 이 글에서는 두 서비스를 연동할 때 가장 까다로운 지점인 '아이덴티티 매핑(Identity Mapping)'을 해결하고, Clerk ID를 기반으로 내부 권한(RBAC)을 철저히 통제하는 실무 보안 아키텍처를 살펴보겠습니다.

Supabase Clerk 연동을 위한 Clerk ID 연동 스키마

전통적인 Supabase 개발 방식은 내부 auth.users 테이블을 중심으로 모든 관계를 설계합니다. 하지만 Clerk을 외부 인증처로 사용할 경우, Supabase 내부의 인증 테이블을 거치지 않고 직접 Clerk의 고유 식별자인 Clerk ID(Text 타입)를 DB 스키마의 기본 키(PK)로 활용하는 것이 훨씬 효율적입니다. 이는 데이터 동기화의 복잡성을 줄이고, 인증 엔진과 데이터베이스 사이의 결합도를 낮추는 핵심 전략입니다.

• 프로필 테이블 구축: Supabase의 public 스키마에 profiles 테이블을 생성하고, id 컬럼을 uuid가 아닌 text 형식으로 설정하여 Clerk의 user_id를 그대로 수용합니다.
• ID 우회의 이점: auth.users 테이블에 의존하지 않으므로, Clerk에서 유저가 생성될 때 복잡한 DB 트리거 없이도 애플리케이션 레벨에서 즉시 프로필 정보를 관리할 수 있습니다.

 -- Clerk ID를 기반으로 한 프로필 테이블 설계 예시 CREATE TABLE public.profiles ( id text PRIMARY KEY, -- Clerk의 user_id 저장 email text UNIQUE NOT NULL, role text DEFAULT 'viewer' CHECK (role IN ('admin', 'editor', 'viewer')), updated_at timestamp with time zone DEFAULT now() ); 

모듈형 백엔드를 위한 효율적인 RBAC 설계 전략

RBAC(Role-Based Access Control) 설계의 핵심은 사용자의 역할(Role)을 어디에 저장하고 어떻게 검증하느냐에 있습니다. 2026년형 아키텍처에서는 Clerk의 publicMetadata에 사용자 역할을 저장하고, 이를 JWT(JSON Web Token) 클레임에 포함시켜 Supabase로 전달하는 방식을 선호합니다. 하지만 진정한 보안을 위해서는 DB 내부의 profiles 테이블에 저장된 역할 정보와 대조하는 이중 검증(Double-Check) 로직이 필수적입니다.

Clerk에서 발행한 JWT는 Supabase의 미들웨어에서 복호화되며, 그 안에 담긴 sub(Clerk 유저 ID) 정보는 Supabase의 RLS 엔진이 인식할 수 있는 유일한 단서가 됩니다. 이때 관리자 시스템을 위한 admin 역할을 부여받은 사용자만이 특정 테이블에 접근할 수 있도록 권한 매트릭스를 설계해야 합니다. 이는 마치 신분증 발급처에서 '관리자' 직인이 찍힌 신분증을 받아 보안 구역 입구에서 DB 내부의 명단과 대조하는 과정과 같습니다.

실전 RLS 정책을 활용한 관리자 권한 제어 기법

Supabase의 가장 강력한 무기인 RLS 정책(Row Level Security)은 이제 Clerk의 JWT 클레임을 직접 해석하여 동작합니다. auth.jwt() ->> 'sub' 함수를 사용하면 JWT 세션에 담긴 Clerk ID를 즉시 추출할 수 있습니다. 이를 통해 관리자 테이블에 접근하는 모든 요청이 실제 profiles 테이블에서 admin 역할을 가졌는지 실시간으로 검증할 수 있습니다.

• JWT 클레임 활용: 외부 인증의 정보를 SQL 레벨에서 직접 참조하여 성능 최적화를 이룹니다.
• 강력한 접근 제어: 단순한 로그인을 넘어, 각 행(Row) 단위로 쓰기, 읽기, 삭제 권한을 세밀하게 제어합니다.

 -- 관리자 전용 테이블에 대한 RLS 정책 예시 ALTER TABLE public.admin_logs ENABLE ROW LEVEL SECURITY;

CREATE POLICY "관리자만 모든 로그를 조회 및 생성 가능" ON public.admin_logs FOR ALL -- SELECT, INSERT, UPDATE, DELETE 모두 포함 TO authenticated USING ( -- 현재 요청한 Clerk ID가 profiles 테이블에서 admin인지 확인 EXISTS ( SELECT 1 FROM public.profiles WHERE profiles.id = (auth.jwt() ->> 'sub') AND profiles.role = 'admin' ) ); 

 

인증과 인가를 분리하는 것은 시스템의 유연성을 확보하고 보안 사고 발생 시 영향 범위를 최소화하는 최고의 선택입니다. Clerk을 통해 사용자 경험을 극대화하고, Supabase의 RLS 정책으로 데이터 주권을 지키는 아키텍처는 1인 창업가부터 대규모 엔터프라이즈 팀까지 모두에게 유효한 표준이 되었습니다. 기술적 복잡함에 매몰되지 않고, 서비스의 목적에 맞는 '보안 구역'을 설계하는 리더가 되십시오. 데이터의 흐름을 통제하는 자가 비즈니스의 신뢰를 지배합니다.