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

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

이 글에서 다루는 내용

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

0L000 invalid grantor 는?

PostgreSQL 에러 코드 0L000 invalid grantor는 권한(GRANT)을 부여하려는 사용자가 해당 권한을 위임할 자격이 없을 때 발생하는 에러입니다. 즉, 어떤 객체에 대한 권한을 다른 사용자에게 부여하려 할 때, 권한을 부여하는 주체(grantor)가 GRANT OPTION을 가지고 있지 않거나 슈퍼유저가 아닌 경우에 이 에러가 트리거됩니다. 주로 복잡한 다단계 권한 위임 구조나 역할(Role) 기반 접근 제어 환경에서 자주 발생하며, 권한 체계가 잘 정립되지 않은 운영 환경에서 특히 빈번하게 나타납니다.

주요 발생 원인

1. GRANT OPTION 없이 권한 재위임 시도

가장 흔한 원인은 GRANT OPTION을 보유하지 않은 사용자가 다른 사용자에게 권한을 넘기려 할 때입니다. PostgreSQL에서 권한을 제3자에게 위임하려면 반드시 해당 권한에 대해 WITH GRANT OPTION이 명시적으로 부여되어 있어야 합니다. 이 옵션 없이 GRANT 명령을 실행하면 invalid grantor 에러가 발생합니다.

2. 권한을 부여한 역할(Role)이 삭제되거나 비활성화된 경우

권한을 최초로 부여한 역할(grantor role)이 데이터베이스에서 삭제되거나 해당 역할의 멤버십이 변경된 경우, 기존 권한 체인이 끊어지면서 이 에러가 발생할 수 있습니다. PostgreSQL은 권한의 출처(grantor)를 내부적으로 추적하기 때문에, grantor가 사라지면 관련 권한 구조가 불일치 상태가 됩니다. 이런 상황은 특히 역할을 자주 생성하고 삭제하는 CI/CD 환경에서 자주 나타납니다.

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

복잡한 역할 계층 구조에서 상위 역할이 하위 역할에게 권한을 부여할 때, 중간 역할이 GRANT OPTION을 보유하지 않으면 에러가 발생합니다. 예를 들어 role_a → role_b → role_c로 이어지는 권한 위임 체인에서, role_b가 GRANT OPTION 없이 role_c에게 권한을 넘기려 하면 invalid grantor가 발생합니다. 이는 권한 설계가 복잡할수록 추적이 어려워지는 문제입니다.

해결 방법

원인 1 해결: GRANT OPTION 부여

권한을 위임해야 하는 사용자에게 WITH GRANT OPTION을 명시적으로 추가하여 권한을 재부여합니다.

-- 슈퍼유저 또는 객체 소유자가 실행
-- 기존 권한 확인
SELECT grantee, privilege_type, is_grantable
FROM information_schema.role_table_grants
WHERE table_name = 'orders';

-- WITH GRANT OPTION을 포함한 권한 부여
GRANT SELECT, INSERT ON TABLE orders TO role_manager WITH GRANT OPTION;

-- 이제 role_manager는 다른 사용자에게 권한을 위임할 수 있음
SET ROLE role_manager;
GRANT SELECT ON TABLE orders TO role_readonly;
RESET ROLE;

원인 2 해결: grantor 역할 복구 또는 권한 재설정

삭제된 grantor 역할로 인한 고아 권한(orphaned privilege)을 정리하고 권한을 다시 설정합니다.

-- 고아 권한 확인 (grantor가 존재하지 않는 경우)
SELECT acl.*
FROM pg_class c,
     aclexplode(c.relacl) AS acl
WHERE NOT EXISTS (
    SELECT 1 FROM pg_roles r WHERE r.oid = acl.grantor
)
AND c.relname = 'orders';

-- 기존 권한 전체 회수 후 재부여
REVOKE ALL PRIVILEGES ON TABLE orders FROM role_readonly;
REVOKE ALL PRIVILEGES ON TABLE orders FROM role_manager;

-- 슈퍼유저 또는 소유자로서 권한 재설정
GRANT SELECT ON TABLE orders TO role_readonly;
GRANT SELECT, INSERT, UPDATE ON TABLE orders TO role_manager WITH GRANT OPTION;

-- 권한 체인 재확인
SELECT grantee, grantor, privilege_type, is_grantable
FROM information_schema.role_table_grants
WHERE table_name = 'orders';

원인 3 해결: 역할 계층의 권한 체인 재구성

역할 계층에서 중간 역할에게 올바르게 GRANT OPTION을 부여하여 체인을 복구합니다.

-- 현재 역할 구조 확인
SELECT r.rolname AS role,
       m.rolname AS member_of
FROM pg_roles r
JOIN pg_auth_members am ON am.member = r.oid
JOIN pg_roles m ON m.oid = am.roleid;

-- 역할별 권한 확인
\dp orders

-- role_a (소유자/슈퍼유저)가 role_b에게 GRANT OPTION 포함하여 권한 부여
GRANT SELECT, INSERT ON TABLE orders TO role_b WITH GRANT OPTION;

-- role_b가 role_c에게 권한 위임 (이제 유효함)
SET ROLE role_b;
GRANT SELECT ON TABLE orders TO role_c;
RESET ROLE;

-- 전체 권한 구조 재확인
SELECT grantee, grantor, privilege_type, is_grantable
FROM information_schema.role_table_grants
WHERE table_name = 'orders'
ORDER BY grantor, grantee;

예방 방법

1. 권한 위임 정책을 문서화하고 중앙 집중식으로 관리하라

권한 부여 체계를 스프레드시트나 ERD 형식으로 문서화하고, 슈퍼유저 또는 전담 DBA 역할만이 GRANT OPTION이 포함된 권한을 부여할 수 있도록 정책을 제한하는 것이 중요합니다. 아래와 같이 주기적으로 GRANT OPTION 현황을 모니터링하는 쿼리를 cron job 등으로 실행하면 이상 징후를 조기에 발견할 수 있습니다.

-- GRANT OPTION이 부여된 모든 권한 정기 감사
SELECT table_schema, table_name, grantee, grantor, privilege_type
FROM information_schema.role_table_grants
WHERE is_grantable = 'YES'
ORDER BY table_schema, table_name, grantee;

2. 역할 삭제 전에 반드시 의존 권한을 먼저 정리하라

역할을 삭제하기 전에 해당 역할이 grantor로 등록된 권한이 있는지 반드시 확인하고, REASSIGN OWNED 또는 명시적 REVOKE 명령으로 권한을 정리한 후 삭제해야 합니다. 자동화 스크립트나 배포 파이프라인에서 역할을 삭제할 때 이 절차를 반드시 포함시키세요.

-- 역할 삭제 전 해당 역할이 grantor인 권한 확인
SELECT table_name, grantee, privilege_type
FROM information_schema.role_table_grants
WHERE grantor = 'role_to_delete';

-- 소유 객체 재할당 후 권한 정리
REASSIGN OWNED BY role_to_delete TO postgres;
DROP OWNED BY role_to_delete;

-- 이후 역할 삭제
DROP ROLE role_to_delete;