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

27000 triggered data change violation 는?

PostgreSQL 에러 코드 27000, triggered data change violation은 트리거(Trigger) 실행 중 허용되지 않는 데이터 변경이 발생했을 때 나타나는 에러입니다. 주로 AFTER 트리거 또는 뷰(View)에 정의된 INSTEAD OF 트리거에서 잘못된 방식으로 원본 테이블의 데이터를 변경하려 할 때 발생합니다. 이 에러는 PostgreSQL이 트리거 로직의 무결성을 보호하기 위해 특정 컨텍스트에서 데이터 변경을 명시적으로 차단할 때 발생하며, 트리거 설계 오류나 잘못된 뷰 업데이트 로직에서 자주 목격됩니다.

---

주요 발생 원인

1. AFTER 트리거에서 트리거를 유발한 테이블을 직접 수정하려는 경우

PostgreSQL의 AFTER 트리거는 원래의 DML(INSERT, UPDATE, DELETE) 작업이 완료된 이후에 실행됩니다. 하지만 AFTER 트리거 함수 내부에서 트리거를 발생시킨 바로 그 테이블(triggering table)에 대해 추가적인 데이터 변경을 시도하면, PostgreSQL은 이를 무결성 위반으로 판단하고 triggered data change violation 에러를 발생시킵니다. 이는 특히 Row-Level AFTER 트리거에서 자주 나타나며, 재귀적 트리거 호출이나 예상치 못한 부작용(side effect)을 방지하기 위한 PostgreSQL의 안전장치입니다.

2. 뷰(View)에 정의된 INSTEAD OF 트리거에서 잘못된 베이스 테이블 수정

복잡한 뷰에 INSTEAD OF 트리거를 정의하여 DML을 처리할 때, 트리거 함수 내에서 뷰의 베이스 테이블이 아닌 다른 테이블이나 또 다른 뷰를 잘못 수정하거나, 트리거 체인이 순환(cycle)을 형성하는 경우에 이 에러가 발생할 수 있습니다. INSTEAD OF 트리거는 뷰 자체에 대한 DML을 가로채서 처리하는 것이 목적인데, 그 처리 과정에서 허용 범위를 벗어난 데이터 변경이 일어나면 PostgreSQL은 이를 차단합니다. 뷰 트리거 로직이 복잡할수록 이 에러가 발생할 가능성이 높아집니다.

3. 트리거 함수 내에서 트리거를 유발한 테이블에 대한 TRUNCATE 또는 DDL 실행 시도

트리거 함수 내에서 TRUNCATE 명령이나 DDL(예: ALTER TABLE, DROP TABLE)을 실행하려 할 때도 이 에러가 발생할 수 있습니다. PostgreSQL은 트리거 실행 컨텍스트 내에서 특정 종류의 명령을 허용하지 않으며, 특히 트리거를 발생시킨 테이블 자체에 대한 구조 변경이나 전체 데이터 삭제는 엄격히 제한됩니다. 이러한 작업은 트랜잭션 무결성과 데이터 일관성을 심각하게 훼손할 수 있기 때문입니다.

---

해결 방법

원인 1 해결: AFTER 트리거에서 자기 테이블 수정 회피

AFTER 트리거에서 동일 테이블을 수정해야 하는 경우, BEFORE 트리거로 전환하거나 NEW 레코드를 직접 조작하는 방식으로 변경하세요.

잘못된 예시 (에러 발생):

-- orders 테이블에 AFTER INSERT 트리거 정의
CREATE OR REPLACE FUNCTION trg_after_insert_orders()
RETURNS TRIGGER AS $$
BEGIN
    -- 에러 발생: 트리거를 유발한 테이블(orders)을 직접 UPDATE 시도
    UPDATE orders SET status = 'processed' WHERE id = NEW.id;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER after_insert_orders
AFTER INSERT ON orders
FOR EACH ROW EXECUTE FUNCTION trg_after_insert_orders();

올바른 예시 (BEFORE 트리거로 전환):

-- BEFORE 트리거로 변경하여 NEW 레코드를 직접 수정
CREATE OR REPLACE FUNCTION trg_before_insert_orders()
RETURNS TRIGGER AS $$
BEGIN
    -- NEW 레코드를 직접 수정하여 INSERT 전에 값을 변경
    NEW.status := 'processed';
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER before_insert_orders
BEFORE INSERT ON orders
FOR EACH ROW EXECUTE FUNCTION trg_before_insert_orders();

만약 반드시 AFTER 트리거를 사용해야 한다면, 다른 테이블(예: 로그 테이블)을 수정하는 방식으로 로직을 재설계하세요:

-- AFTER 트리거에서는 다른 테이블(audit_log)만 수정
CREATE OR REPLACE FUNCTION trg_after_insert_orders_log()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO audit_log (table_name, action, record_id, changed_at)
    VALUES ('orders', 'INSERT', NEW.id, NOW());
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER after_insert_orders_log
AFTER INSERT ON orders
FOR EACH ROW EXECUTE FUNCTION trg_after_insert_orders_log();

---

원인 2 해결: 뷰 INSTEAD OF 트리거 로직 재설계

뷰에 대한 INSTEAD OF 트리거에서 베이스 테이블만 정확히 수정하고, 트리거 체인이 순환되지 않도록 설계하세요.

-- 복잡한 뷰 생성 예시
CREATE VIEW employee_details AS
SELECT e.id, e.name, e.department_id, d.department_name
FROM employees e
JOIN departments d ON e.department_id = d.id;

-- INSTEAD OF UPDATE 트리거: 오직 베이스 테이블(employees)만 수정
CREATE OR REPLACE FUNCTION trg_instead_of_update_employee_details()
RETURNS TRIGGER AS $$
BEGIN
    -- employees 베이스 테이블만 업데이트 (departments는 별도 처리)
    UPDATE employees
    SET name = NEW.name,
        department_id = NEW.department_id
    WHERE id = OLD.id;

    -- 부서명 변경이 필요한 경우 명확하게 분리하여 처리
    IF OLD.department_name <> NEW.department_name THEN
        UPDATE departments
        SET department_name = NEW.department_name
        WHERE id = OLD.department_id;
    END IF;

    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER instead_of_update_employee_details
INSTEAD OF UPDATE ON employee_details
FOR EACH ROW EXECUTE FUNCTION trg_instead_of_update_employee_details();

---

원인 3 해결: 트리거 내 DDL 및 TRUNCATE 제거

트리거 함수 내에서 DDL이나 TRUNCATE가 필요한 경우, 해당 작업을 트리거 밖으로 분리하거나 별도의 스케줄링 작업(예: pg_cron)으로 처리하세요.

-- 잘못된 예: 트리거 내에서 TRUNCATE 시도 (에러 발생)
-- CREATE OR REPLACE FUNCTION bad_trigger_func()
-- RETURNS TRIGGER AS $$
-- BEGIN
--     TRUNCATE orders; -- 절대 사용 금지
--     RETURN NEW;
-- END;
-- $$ LANGUAGE plpgsql;

-- 올바른 예: 정리 작업은 별도 프로시저로 분리하고 수동 또는 스케줄러로 실행
CREATE OR REPLACE PROCEDURE cleanup_old_orders(retention_days INT DEFAULT 90)
LANGUAGE plpgsql AS $$
BEGIN
    DELETE FROM orders
    WHERE created_at < NOW() - (retention_days || ' days')::INTERVAL;
    
    RAISE NOTICE '% 일 이전 주문 데이터 정리 완료', retention_days;
END;
$$;

-- 수동 실행
CALL cleanup_old_orders(90);

-- pg_cron을 사용한 자동 스케줄링 (pg_cron 확장 필요)
-- SELECT cron.schedule('cleanup-orders', '0 2 * * *', 'CALL cleanup_old_orders(90)');

---

예방 방법

1. 트리거 설계 원칙 확립: 단일 책임 및 방향성 명확화

트리거를 설계할 때는 단일 책임 원칙(Single Responsibility Principle)을 적용하여, 하나의 트리거 함수가 하나의 명확한 역할만 수행하도록 제한하세요. BEFORE 트리거는 데이터 유효성 검사 및 값 변환에 사용하고, AFTER 트리거는 다른 테이블에 대한 연쇄 작업(로깅, 감사 테이블 기록 등)에만 사용하는 명확한 가이드라인을 팀 내에서 공유하세요. 또한 트리거 함수를 작성하기 전에 반드시 트리거 실행 흐름도를 그려보고, 순환 참조나 자기 참조가 발생하지 않는지 사전에 검증하는 코드 리뷰 프로세스를 도입하는 것이 중요합니다.

2. 개발 환경에서 트리거 동작 철저히 테스트 및 문서화

운영 환경에 배포하기 전에 개발 또는 스테이징 환경에서 트리거의 모든 경로(INSERT, UPDATE, DELETE, 경계값 등)를 철저히 테스트하고, 각 트리거의 목적, 실행 시점, 영향 범위를 상세히 문서화하세요. 특히 뷰에 INSTEAD OF 트리거를 추가할 때는 베이스 테이블 구조와의 정합성을 반드시 확인하고, pg_trigger, information_schema.triggers 뷰를 활용하여 현재 시스템에 정의된 모든 트리거를 주기적으로 감사(audit)하는 습관을 들이세요.

-- 현재 데이터베이스의 모든 트리거 조회 (감사 목적)
SELECT 
    trigger_name,
    event_object_table AS table_name,
    action_timing,
    event_manipulation,
    action_orientation
FROM information_schema.triggers
WHERE trigger_schema = 'public'
ORDER BY event_object_table, action_timing, event_manipulation;

---

관련 에러

• 23000 (integrity_constraint_violation): 트리거 실행 중 외래 키, 유니크 제약 조건 등 무결성 제약을 위반했을 때 발생합니다. 트리거 내에서 데이터 변경 시 함께 자주 발생하는 연관 에러입니다.
• 25006 (read_only_sql_transaction): 읽기 전용 트랜잭션 컨텍스트에서 트리거가 데이터 변경을 시도할 때 발생합니다. 복제(replication) 환경의 스탠바이 서버에서 특히 주의가 필요합니다.
• 09000 (triggered_action_exception): 트리거 함수 내에서 예외가 발생하여 트리거 동작 자체가 실패했을 때 나타나는 상위 에러 클래스입니다. 27000 에러와 밀접하게 연관되어 있으며, 함께 로그를 확인해야 합니다.
• 42501 (insufficient_privilege): 트리거 함수가 실행될 때 해당 함수의 소유자 또는 실행 컨텍스트 사용자에게 대상 테이블에 대한 충분한 권한이 없을 때 발생하며, 트리거 에러 디버깅 시 권한 문제와 함께 확인해야 합니다.

본 포스트는 AI가 생성한 기술 가이드입니다. 운영 환경 적용 전 충분한 검토를 권장합니다.