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

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

이 글에서 다루는 내용

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

0L000 invalid grantor 는?

PostgreSQL 에러 코드 0L000 invalid grantor는 권한을 부여(GRANT)하거나 철회(REVOKE)하는 과정에서 권한을 위임하는 주체(grantor)가 유효하지 않을 때 발생하는 에러입니다. 즉, 특정 사용자가 자신이 보유하지 않은 권한을 다른 사용자에게 부여하려 할 때, 혹은 권한 위임 체계(grant chain)가 올바르지 않은 상태에서 GRANT 명령을 실행할 때 이 에러가 트리거됩니다. 주로 복잡한 역할(Role) 계층 구조를 가진 대규모 데이터베이스 환경이나, 권한 마이그레이션 작업 중에 자주 마주치게 됩니다.

주요 발생 원인

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

가장 흔한 원인으로, 어떤 사용자가 WITH GRANT OPTION 없이 권한을 받은 상태에서 해당 권한을 다른 사용자에게 전달하려 할 때 발생합니다. PostgreSQL에서 권한을 제3자에게 위임하려면 반드시 해당 권한이 WITH GRANT OPTION과 함께 부여되어 있어야 하며, 그렇지 않으면 시스템은 해당 사용자를 유효한 grantor로 인정하지 않습니다.

2. 권한 부여 체인(Grant Chain)이 끊긴 경우

권한 위임 계층 구조에서 중간 역할(Role)이 삭제되거나 해당 역할의 권한이 철회된 경우, 그 역할로부터 권한을 이어받은 하위 사용자가 권한을 부여하려 할 때 grantor 체인이 유효하지 않게 됩니다. 예를 들어 superuser → role_a → role_b 형태로 위임된 상태에서 role_a의 GRANT OPTION이 REVOKE되면 role_b는 더 이상 유효한 grantor가 아니게 됩니다.

3. 역할 전환(SET ROLE) 없이 다른 역할의 권한을 행사하려는 경우

현재 세션의 실제 실행 역할(current_role)이 아닌, 단순히 멤버십으로 포함된 상위 역할의 권한을 직접 행사하려 할 때 이 에러가 발생할 수 있습니다. PostgreSQL은 권한 부여 시점에서 현재 세션의 유효 역할을 기준으로 grantor를 판단하기 때문에, SET ROLE 없이는 상위 역할로서의 GRANT가 불가능합니다.

해결 방법

원인 1 해결: WITH GRANT OPTION 확인 및 재부여

먼저 해당 사용자가 보유한 권한에 GRANT OPTION이 포함되어 있는지 확인합니다.

-- 특정 테이블에 대한 권한 및 GRANT OPTION 확인
SELECT grantee, privilege_type, is_grantable
FROM information_schema.role_table_grants
WHERE table_name = 'your_table_name'
  AND grantee = 'your_user';

-- GRANT OPTION이 없다면, superuser 또는 테이블 소유자가 WITH GRANT OPTION으로 재부여
GRANT SELECT ON TABLE your_table_name TO your_user WITH GRANT OPTION;

-- 이후 your_user가 다른 사용자에게 권한 위임 가능
SET ROLE your_user;
GRANT SELECT ON TABLE your_table_name TO another_user;
RESET ROLE;

원인 2 해결: 끊긴 Grant Chain 복구

권한 체인이 끊긴 경우, superuser 또는 오브젝트 소유자가 직접 권한 체인을 재구성해야 합니다.

-- 현재 권한 체인 상태 점검
SELECT grantor, grantee, privilege_type, is_grantable
FROM information_schema.role_table_grants
WHERE table_name = 'your_table_name'
ORDER BY grantor, grantee;

-- 끊긴 체인 복구: role_a에게 GRANT OPTION 재부여
GRANT SELECT ON TABLE your_table_name TO role_a WITH GRANT OPTION;

-- role_a가 role_b에게 다시 위임
SET ROLE role_a;
GRANT SELECT ON TABLE your_table_name TO role_b WITH GRANT OPTION;
RESET ROLE;

-- 전체 데이터베이스 오브젝트에 대한 권한 체인 일괄 확인 (pg_catalog 활용)
SELECT
    pr.rolname AS grantor,
    pe.rolname AS grantee,
    dp.privilege_type,
    dp.is_grantable
FROM pg_class c
JOIN LATERAL aclexplode(c.relacl) dp ON TRUE
JOIN pg_roles pr ON pr.oid = dp.grantor
JOIN pg_roles pe ON pe.oid = dp.grantee
WHERE c.relname = 'your_table_name';

원인 3 해결: SET ROLE을 활용한 권한 행사

상위 역할의 권한을 행사해야 할 때는 반드시 SET ROLE로 역할을 전환한 뒤 GRANT를 실행합니다.

-- 현재 세션의 역할 확인
SELECT current_user, current_role, session_user;

-- 상위 역할로 전환 후 권한 부여
SET ROLE admin_role;

GRANT INSERT, UPDATE ON TABLE sensitive_table TO developer_user;

-- 작업 완료 후 원래 역할로 복귀
RESET ROLE;

-- 특정 역할이 다른 역할의 멤버인지 확인
SELECT
    r.rolname AS role_name,
    m.rolname AS member_of
FROM pg_roles r
JOIN pg_auth_members am ON r.oid = am.member
JOIN pg_roles m ON am.roleid = m.oid
WHERE r.rolname = 'your_user';

예방 방법

1. 권한 체계를 역할(Role) 기반으로 표준화하고 문서화하기

개별 사용자에게 직접 권한을 부여하는 방식보다, 역할(Role)을 계층적으로 설계하여 권한을 역할에만 부여하고 사용자는 역할의 멤버로 관리하는 방식을 채택하세요. 이렇게 하면 GRANT OPTION 체인이 단순해지고, grantor 유효성 문제가 발생할 여지가 크게 줄어듭니다. 권한 설계 문서를 작성하고 정기적으로 information_schema.role_table_grants와 pg_auth_members를 조회하여 현황을 감사(audit)하는 루틴을 수립하세요.

-- 권한 현황 정기 감사 쿼리 예시
SELECT
    grantee,
    table_schema,
    table_name,
    string_agg(privilege_type, ', ') AS privileges,
    bool_or(is_grantable::boolean) AS has_grant_option
FROM information_schema.role_table_grants
WHERE table_schema NOT IN ('information_schema', 'pg_catalog')
GROUP BY grantee, table_schema, table_name
ORDER BY grantee, table_schema, table_name;

2. 권한 변경 작업은 항상 트랜잭션 내에서 실행하고 롤백 계획 수립하기

GRANT/REVOKE 작업을 수행할 때는 반드시 트랜잭션(BEGIN ... COMMIT/ROLLBACK)으로 묶어 실행하고, 변경 전 현재 권한 상태를 스냅샷으로 기록해 두세요. 특히 대규모 권한 마이그레이션 시에는 단계별로 권한 체인의 무결성을 검증하는 스크립트를 함께 실행하여 invalid grantor 에러가 발생하기 전에 사전 탐지할 수 있도록 합니다.

-- 권한 변경 작업의 안전한 실행 패턴
BEGIN;

-- 변경 전 상태 기록
CREATE TEMP TABLE privilege_snapshot AS
SELECT * FROM information_schema.role_table_grants
WHERE table_schema = 'public';

-- 권한 변경 수행
GRANT SELECT ON TABLE your_table TO target_role WITH GRANT OPTION;

-- 변경 결과 검증
SELECT * FROM information_schema.role_table_grants
WHERE table_name = 'your_table' AND grantee = 'target_role';

-- 문제 없으면 커밋, 이상 있으면 롤백
COMMIT;
-- 또는 ROLLBACK;