ROW POLICY — RBAC를 행 단위로 한 단계 더 세밀하게
ClickHouse ROW POLICY 및 PostgreSQL/MySQL 테이블 엔진 공식 문서 종합 (웹 리서치, 2026) — ClickHouse 공식 문서(knowledgebase/row-column-policy, engines/table-engines/integrations/postgresql, mysql) ClickHouse 공식문서 Row-level and column-level security
이 모듈을 다 읽으면
- ROW POLICY가 clickhouse-learn-33의 RBAC(테이블 단위 GRANT)와 무엇이 다른지 설명할 수 있다
- 정책이 하나라도 정의되면 기본이 'deny'로 바뀐다는 함정과 PERMISSIVE/RESTRICTIVE 조합 규칙을 설명할 수 있다
clickhouse-learn-33에서 다룬 RBAC(테이블 전체 단위로 접근을 허용·차단)를 전제로, 같은 테이블 안에서도 '어떤 행까지' 보여줄지를 세밀하게 통제하는 ROW POLICY를 정리한다.
동작 원리 — 쿼리에 필터를 자동으로 덧붙인다
ROW POLICY는 테이블에 필터 표현식을 하나 붙여두는 것이다. 그 정책이 적용되는 사용자가 그 테이블을 조회하면, ClickHouse가 서버 단에서 자동으로 이 필터를 WHERE 절에 덧붙여 실행한다 — 애플리케이션 쪽에서 SQL을 바꿀 필요가 전혀 없이 투명하게 적용된다는 점이 핵심이다. clickhouse-learn-33의 RBAC가 '이 테이블 자체를 볼 수 있는가'를 결정한다면, ROW POLICY는 그 테이블을 볼 수 있는 사용자라도 '그중 어떤 행까지만' 보이게 할지를 결정하는, 한 단계 더 세밀한 레이어다.
핵심 포인트
- ROW POLICY: 테이블에 필터 표현식을 붙여두면, 적용 대상 사용자의 쿼리에 서버가 자동으로 WHERE 조건을 덧붙여 실행 — 애플리케이션의 SQL 수정 불필요
- RBAC(module33)가 '테이블 자체 접근 가능 여부'라면, ROW POLICY는 그 안에서 '어떤 행까지 보이는지'를 결정하는 더 세밀한 레이어
가장 중요한 함정 — 정책이 하나라도 생기면 기본은 '거부'로 바뀐다
운영에 투입하기 전 반드시 알아야 할 핵심 동작이 있다 — 어떤 테이블에 ROW POLICY가 하나라도 정의되고 나면, 그 정책과 매칭되지 않는 사용자는 행을 아예 하나도 못 보게 된다(default-deny). 즉 '정책을 안 만들었으면 다 보였는데, 정책을 하나 만드는 순간 그 정책 대상이 아닌 다른 모든 사용자까지 갑자기 아무것도 못 보게 되는' 상황이 생길 수 있다 — 배포 전에 반드시 확인해야 하는 함정이다.
핵심 포인트
- 테이블에 ROW POLICY가 하나라도 정의되면, 그 정책에 매칭 안 되는 사용자는 행을 전혀 못 보는 default-deny로 전환됨
- 정책 배포 전 '이 정책 대상이 아닌 다른 사용자들이 갑자기 아무것도 못 보게 되지 않는지' 반드시 확인 필요
PERMISSIVE vs RESTRICTIVE — 여러 정책이 겹칠 때의 결합 규칙
한 테이블에 여러 ROW POLICY가 동시에 적용될 수 있는데, 이때 PERMISSIVE 정책들끼리는 OR로 결합된다(여러 정책 중 하나라도 매칭되면 그 행이 보임) — '여러 조건 중 하나만 만족해도 허용'이라는 뜻이다. RESTRICTIVE 정책들끼리는 AND로 결합된다(모든 RESTRICTIVE 조건을 다 만족해야 함) — '추가 제약을 겹겹이 쌓는' 용도다.
핵심 포인트
- PERMISSIVE 정책끼리는 OR 결합(하나라도 매칭되면 허용) / RESTRICTIVE 정책끼리는 AND 결합(전부 만족해야 허용)