PostgreSQL 0L000 오류 원인과 해결 방법 완벽 가이드

0L000
2026년 06월 02일 | DBMS Error 가이드

이 글에서 다루는 내용

0L000 에러의 원인 분석, 해결 SQL, 예방 방법을 실무 관점에서 정리합니다.

0L000 invalid grantor 는?

PostgreSQL 에러 코드 0L000 invalid grantor는 권한(GRANT)을 부여하려는 사용자가 해당 권한을 위임할 수 있는 적절한 자격을 갖추지 못했을 때 발생하는 에러입니다. 쉽게 말해, A라는 사용자가 B에게 특정 객체에 대한 권한을 부여하려 할 때, A 자신이 그 권한을 “WITH GRANT OPTION”과 함께 보유하고 있지 않거나 객체의 소유자가 아닌 경우에 이 에러가 트리거됩니다. 주로 복잡한 권한 위임 구조를 가진 멀티 테넌트 환경이나 역할(Role) 기반 접근 제어 시스템에서 자주 마주치게 됩니다.

주요 발생 원인

1. GRANT OPTION 없이 권한을 재위임하려는 경우

가장 흔한 원인으로, 사용자가 특정 테이블이나 스키마에 대한 권한을 부여받았지만 WITH GRANT OPTION 없이 받은 경우입니다. 이 상태에서 해당 사용자가 제3의 사용자에게 동일한 권한을 위임하려 하면 invalid grantor 에러가 발생합니다. 데이터베이스 관리자가 초기 권한 설계 시 위임 가능 여부를 명확히 정의하지 않은 경우에 빈번하게 발생합니다.

2. 객체 소유자가 아닌 사용자가 권한을 부여하려는 경우

PostgreSQL에서는 객체의 소유자(owner)만이 해당 객체에 대한 모든 권한을 자유롭게 부여할 수 있습니다. 소유자가 아닌 사용자가 WITH GRANT OPTION 없이 부여받은 권한을 다시 다른 사용자에게 넘기려 할 때도 이 에러가 발생합니다. 특히 DBA가 중간 역할(intermediate role)을 통해 권한을 체인처럼 연결하는 구조에서 소유권과 권한 위임 관계가 혼동될 때 주로 발생합니다.

3. 역할(Role) 계층 구조에서의 권한 위임 오류

PostgreSQL의 역할 기반 접근 제어에서 여러 역할이 중첩될 때, 상위 역할이 가진 권한이 하위 역할에게 자동으로 WITH GRANT OPTION과 함께 전달되지 않습니다. 중간 역할이 권한을 보유하고 있더라도 그 권한을 위임할 수 있는 GRANT OPTION이 없다면, 해당 역할을 통해 다른 객체나 사용자에게 권한을 부여하려 할 때 에러가 발생합니다.

해결 방법

원인 1: GRANT OPTION 없는 권한 재위임 해결

먼저 현재 권한 상태를 확인한 후, 슈퍼유저 또는 객체 소유자가 WITH GRANT OPTION을 포함하여 권한을 재부여해야 합니다.

-- 현재 테이블 권한 확인
SELECT grantee, privilege_type, is_grantable
FROM information_schema.role_table_grants
WHERE table_name = 'orders'
  AND table_schema = 'public';

-- 슈퍼유저 또는 소유자가 GRANT OPTION과 함께 권한 부여
GRANT SELECT, INSERT ON TABLE public.orders TO middle_user WITH GRANT OPTION;

-- 이제 middle_user가 다른 사용자에게 권한 위임 가능
SET ROLE middle_user;
GRANT SELECT ON TABLE public.orders TO end_user;
RESET ROLE;

원인 2: 객체 소유자 변경 또는 권한 재구성

객체의 소유자를 변경하거나, 소유자가 직접 권한을 부여하도록 프로세스를 수정합니다.

-- 현재 테이블 소유자 확인
SELECT tablename, tableowner
FROM pg_tables
WHERE schemaname = 'public'
  AND tablename = 'orders';

-- 필요하다면 소유자 변경 (슈퍼유저만 가능)
ALTER TABLE public.orders OWNER TO app_owner;

-- 소유자로서 권한 부여
SET ROLE app_owner;
GRANT SELECT, UPDATE ON TABLE public.orders TO reporting_role WITH GRANT OPTION;
RESET ROLE;

-- reporting_role이 다시 위임할 수 있는지 확인
SET ROLE reporting_role;
GRANT SELECT ON TABLE public.orders TO analyst_user;
RESET ROLE;

원인 3: 역할 계층 권한 위임 오류 해결

역할 계층에서 권한을 올바르게 전달하려면 각 단계에서 WITH GRANT OPTION을 명시해야 합니다.

-- 역할 계층 구조 생성
CREATE ROLE data_owner;
CREATE ROLE data_manager;
CREATE ROLE data_analyst;

-- 테이블 소유자(슈퍼유저)가 data_owner에게 GRANT OPTION과 함께 권한 부여
GRANT ALL PRIVILEGES ON TABLE public.sales TO data_owner WITH GRANT OPTION;

-- data_owner가 data_manager에게 GRANT OPTION 포함 위임
SET ROLE data_owner;
GRANT SELECT, INSERT ON TABLE public.sales TO data_manager WITH GRANT OPTION;
RESET ROLE;

-- data_manager가 data_analyst에게 SELECT 권한 위임
SET ROLE data_manager;
GRANT SELECT ON TABLE public.sales TO data_analyst;
RESET ROLE;

-- 전체 권한 체인 확인
SELECT grantor, grantee, privilege_type, is_grantable
FROM information_schema.role_table_grants
WHERE table_name = 'sales'
  AND table_schema = 'public'
ORDER BY grantor, grantee;

긴급 상황: 슈퍼유저로 일괄 권한 재설정

-- 슈퍼유저로 연결 후 일괄 처리
-- 기존 권한 회수 후 재부여
REVOKE ALL PRIVILEGES ON TABLE public.orders FROM middle_user;
GRANT SELECT, INSERT, UPDATE ON TABLE public.orders TO middle_user WITH GRANT OPTION;

-- 스키마 내 모든 테이블에 GRANT OPTION과 함께 권한 부여
GRANT SELECT ON ALL TABLES IN SCHEMA public TO reporting_role WITH GRANT OPTION;

-- 향후 생성될 테이블에도 적용
ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT SELECT ON TABLES TO reporting_role;

예방 방법

1. 권한 위임 매트릭스를 문서화하고 초기 설계 시 WITH GRANT OPTION을 명확히 정의하기

권한 설계 단계에서부터 어떤 역할이 다른 역할에게 권한을 위임할 수 있는지를 명확히 정의한 매트릭스를 작성하세요. 아래와 같이 주기적으로 현재 권한 위임 상태를 점검하는 쿼리를 스케줄링하면 권한 체계의 이상 징후를 조기에 발견할 수 있습니다.

-- 권한 위임 가능 현황 정기 점검 쿼리
SELECT
    table_schema,
    table_name,
    grantor,
    grantee,
    privilege_type,
    is_grantable
FROM information_schema.role_table_grants
WHERE is_grantable = 'YES'
ORDER BY table_schema, table_name, grantor;

2. 최소 권한 원칙(Principle of Least Privilege)을 적용하고 역할 기반 접근 제어를 체계적으로 관리하기

WITH GRANT OPTION은 반드시 필요한 경우에만 최소한으로 부여하고, 중간 역할(intermediate role)을 적극 활용하여 권한 위임 체계를 단순하게 유지하세요. 또한 pg_audit 또는 PostgreSQL 로그를 활용하여 GRANT 명령 실행 이력을 감사(Audit)함으로써 무분별한 권한 위임을 사전에 차단할 수 있습니다.