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

42501
2026년 09월 07일 | DBMS Error 가이드

이 글에서 다루는 내용

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

42501 insufficient privilege 는?

PostgreSQL 에러 코드 42501은 insufficient privilege, 즉 권한 부족 에러로, 현재 데이터베이스 사용자가 요청한 작업을 수행하기에 충분한 권한을 가지고 있지 않을 때 발생합니다. 이 에러는 테이블 조회, 데이터 삽입/수정/삭제, 함수 실행, 스키마 접근 등 거의 모든 데이터베이스 오퍼레이션에서 발생할 수 있습니다. 특히 애플리케이션 배포 초기나 새로운 DB 오브젝트를 생성한 직후에 빈번하게 나타나며, 잘못된 권한 설계가 원인인 경우가 많습니다.

주요 발생 원인

1. 테이블 또는 뷰에 대한 SELECT/INSERT/UPDATE/DELETE 권한 미부여

가장 흔한 원인으로, 특정 사용자가 테이블에 접근하려 할 때 해당 테이블에 대한 DML 권한이 없는 경우입니다. PostgreSQL은 기본적으로 테이블 소유자와 슈퍼유저를 제외한 모든 사용자에게 테이블 접근 권한을 부여하지 않습니다. 즉, 새 테이블을 생성하면 명시적으로 GRANT 명령어를 실행하지 않는 한 다른 사용자는 해당 테이블에 접근할 수 없습니다.

2. 스키마(Schema)에 대한 USAGE 권한 누락

테이블 권한이 있더라도 해당 테이블이 속한 스키마에 대한 USAGE 권한이 없으면 동일한 42501 에러가 발생합니다. 많은 DBA들이 테이블 권한만 부여하고 스키마 권한을 빠뜨리는 실수를 자주 합니다. public 스키마가 아닌 커스텀 스키마(예: app, reporting, audit 등)를 사용하는 환경에서 특히 자주 발생합니다.

3. 함수(Function) 또는 프로시저(Procedure) 실행 권한 미부여

SECURITY DEFINER로 정의된 함수가 아닌 일반 함수의 경우, 호출자가 해당 함수에 대한 EXECUTE 권한이 없으면 에러가 발생합니다. PostgreSQL 14 버전부터는 기본적으로 PUBLIC에게 함수 실행 권한이 부여되지 않도록 보안이 강화되었기 때문에, 버전 업그레이드 후 이 에러를 마주치는 경우도 많습니다.

해결 방법

원인 1: 테이블/뷰 권한 부여

특정 사용자에게 테이블에 대한 DML 권한을 명시적으로 부여합니다.

-- 특정 테이블에 대한 SELECT 권한 부여
GRANT SELECT ON TABLE public.orders TO app_user;

-- 여러 권한 한 번에 부여
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE public.orders TO app_user;

-- 스키마 내 모든 테이블에 권한 부여 (현재 존재하는 테이블 대상)
GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_user;

-- 향후 생성될 테이블에도 자동으로 권한 부여 (DEFAULT PRIVILEGES 설정)
ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_user;

-- 현재 사용자의 권한 확인
SELECT grantee, table_schema, table_name, privilege_type
FROM information_schema.role_table_grants
WHERE grantee = 'app_user';

원인 2: 스키마 USAGE 권한 부여

테이블 권한과 함께 반드시 스키마 USAGE 권한을 부여해야 합니다.

-- 스키마 USAGE 권한 부여 (필수)
GRANT USAGE ON SCHEMA app TO app_user;

-- 스키마 내 테이블 접근 권한도 함께 부여
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app TO app_user;

-- 스키마에 대한 권한 확인
SELECT nspname AS schema_name,
       pg_catalog.has_schema_privilege('app_user', nspname, 'USAGE') AS has_usage
FROM pg_catalog.pg_namespace
WHERE nspname NOT LIKE 'pg_%' AND nspname <> 'information_schema';

-- 특정 사용자가 접근 가능한 스키마 목록 확인
SELECT schema_name
FROM information_schema.schemata
WHERE schema_name IN (
    SELECT nspname FROM pg_namespace
    WHERE pg_catalog.has_schema_privilege('app_user', oid, 'USAGE')
);

원인 3: 함수/프로시저 실행 권한 부여

-- 특정 함수에 EXECUTE 권한 부여
GRANT EXECUTE ON FUNCTION public.calculate_discount(numeric, numeric) TO app_user;

-- 스키마 내 모든 함수에 EXECUTE 권한 부여
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO app_user;

-- 향후 생성될 함수에도 자동으로 권한 부여
ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT EXECUTE ON FUNCTIONS TO app_user;

-- 함수 권한 확인
SELECT routine_name, privilege_type, grantee
FROM information_schema.routine_privileges
WHERE grantee = 'app_user' AND routine_schema = 'public';

권한 문제 종합 진단 쿼리

현재 접속한 사용자의 권한을 빠르게 점검할 수 있는 쿼리입니다.

-- 현재 사용자와 역할 확인
SELECT current_user, session_user;

-- 현재 사용자가 가진 역할(Role) 목록 확인
SELECT rolname
FROM pg_roles
WHERE pg_has_role(current_user, oid, 'member');

-- 특정 테이블에 대한 권한 확인
SELECT has_table_privilege('app_user', 'public.orders', 'SELECT') AS can_select,
       has_table_privilege('app_user', 'public.orders', 'INSERT') AS can_insert,
       has_table_privilege('app_user', 'public.orders', 'UPDATE') AS can_update,
       has_table_privilege('app_user', 'public.orders', 'DELETE') AS can_delete;

-- 권한 박탈이 필요한 경우
REVOKE INSERT, UPDATE, DELETE ON TABLE public.orders FROM app_user;

예방 방법

1. Role 기반 권한 관리 체계 구축 (RBAC)

개별 사용자에게 직접 권한을 부여하는 방식 대신, 역할(Role)을 중간에 두는 계층적 권한 관리 체계를 도입하세요. 예를 들어 readonly_role, readwrite_role, admin_role 등의 역할을 만들고 각 역할에 적절한 권한을 부여한 뒤, 사용자에게는 역할만 부여하는 방식을 사용합니다. 이렇게 하면 권한 관리가 단순해지고, 새로운 사용자 추가 시 역할만 부여하면 되므로 실수를 줄일 수 있습니다.

-- 역할 생성 및 권한 부여
CREATE ROLE readonly_role;
GRANT USAGE ON SCHEMA public TO readonly_role;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_role;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonly_role;

-- 사용자에게 역할 부여
GRANT readonly_role TO report_user;
GRANT readonly_role TO analytics_user;

2. DEFAULT PRIVILEGES를 활용한 자동 권한 관리

새 오브젝트가 생성될 때마다 수동으로 권한을 부여하는 것은 누락의 위험이 있습니다. ALTER DEFAULT PRIVILEGES 명령어를 사용하면 특정 사용자가 오브젝트를 생성할 때 자동으로 다른 사용자에게 권한이 부여됩니다. CI/CD 파이프라인에 권한 검증 스크립트를 포함시켜, 배포 후 권한이 올바르게 설정되었는지 자동으로 확인하는 프로세스를 구축하는 것도 강력히 권장합니다.

-- app_owner가 생성하는 모든 오브젝트에 대해 app_user에게 자동 권한 부여
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
    GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_user;

ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
    GRANT EXECUTE ON FUNCTIONS TO app_user;

ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
    GRANT USAGE ON SEQUENCES TO app_user;