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

42830
2026년 09월 08일 | DBMS Error 가이드

이 글에서 다루는 내용

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

42830 invalid foreign key 는?

PostgreSQL 에러 코드 42830은 invalid foreign key 에러로, 외래 키(Foreign Key) 제약 조건을 정의할 때 참조 대상 테이블이나 컬럼이 올바르지 않을 경우 발생합니다. 주로 참조되는 컬럼이 고유(UNIQUE) 또는 기본 키(PRIMARY KEY) 제약 조건을 가지지 않거나, 데이터 타입이 불일치할 때 이 에러가 발생합니다. 실무에서는 데이터 모델 설계 초기 단계나 마이그레이션 작업 도중 빈번하게 마주치는 에러 중 하나입니다.

주요 발생 원인

1. 참조 대상 컬럼에 PRIMARY KEY 또는 UNIQUE 제약 조건이 없는 경우

가장 흔하게 발생하는 원인으로, 외래 키는 반드시 참조 대상 테이블의 PRIMARY KEY 또는 UNIQUE 제약 조건이 설정된 컬럼을 가리켜야 합니다. 참조 대상 컬럼에 이러한 제약 조건이 없으면 PostgreSQL은 고유성을 보장할 수 없으므로 외래 키를 허용하지 않습니다. 예를 들어 orders 테이블이 customers 테이블의 email 컬럼을 참조하려 할 때, email에 UNIQUE 제약 조건이 없다면 이 에러가 발생합니다.

2. 참조하는 컬럼과 참조되는 컬럼 간의 데이터 타입 불일치

외래 키를 구성하는 컬럼과 참조 대상 컬럼의 데이터 타입이 반드시 호환되어야 합니다. 예를 들어 자식 테이블의 컬럼이 VARCHAR 타입인데 부모 테이블의 참조 컬럼이 INTEGER 타입이라면 이 에러가 발생합니다. 단순히 타입 이름이 다를 뿐만 아니라 INT vs BIGINT처럼 암묵적 변환이 가능해 보이는 타입 간에도 PostgreSQL은 엄격하게 타입을 검사합니다.

3. 복합 외래 키(Composite Foreign Key) 정의 시 컬럼 수 또는 순서 불일치

복합 외래 키를 사용할 때, 참조하는 컬럼의 수와 참조되는 컬럼의 수가 일치하지 않거나 순서가 잘못된 경우에도 이 에러가 발생합니다. 복합 키는 컬럼의 순서와 각각의 데이터 타입이 정확히 매핑되어야 하며, 하나라도 어긋나면 PostgreSQL은 유효하지 않은 외래 키로 간주합니다. 특히 레거시 시스템에서 테이블을 마이그레이션하거나 ERD 없이 작업할 때 자주 실수하는 부분입니다.

해결 방법

원인 1 해결: 참조 대상 컬럼에 UNIQUE 또는 PRIMARY KEY 추가

먼저 참조 대상 컬럼의 현재 제약 조건을 확인하고, 필요한 경우 제약 조건을 추가합니다.

-- 현재 제약 조건 확인
SELECT conname, contype, conrelid::regclass, confrelid::regclass
FROM pg_constraint
WHERE conrelid = 'customers'::regclass;

-- 잘못된 외래 키 정의 (email에 UNIQUE 없음)
-- 아래 구문은 42830 에러 발생
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_email VARCHAR(255),
    CONSTRAINT fk_customer_email
        FOREIGN KEY (customer_email)
        REFERENCES customers(email)  -- email 컬럼에 UNIQUE 없으면 에러
);

-- 해결 방법 1: 참조 대상 컬럼에 UNIQUE 제약 조건 추가
ALTER TABLE customers
    ADD CONSTRAINT uq_customers_email UNIQUE (email);

-- 해결 방법 2: PRIMARY KEY를 가진 컬럼을 참조하도록 변경
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INTEGER,
    CONSTRAINT fk_customer_id
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)  -- PRIMARY KEY 컬럼 참조
);

원인 2 해결: 데이터 타입 일치시키기

-- 문제 상황: 타입 불일치로 인한 42830 에러
CREATE TABLE departments (
    dept_id BIGINT PRIMARY KEY,
    dept_name VARCHAR(100)
);

-- 아래는 에러 발생: employees.dept_id가 INTEGER인데 departments.dept_id는 BIGINT
CREATE TABLE employees (
    emp_id SERIAL PRIMARY KEY,
    dept_id INTEGER,  -- BIGINT와 타입 불일치
    CONSTRAINT fk_dept
        FOREIGN KEY (dept_id)
        REFERENCES departments(dept_id)
);

-- 해결 방법: 자식 테이블의 컬럼 타입을 부모와 동일하게 맞춤
CREATE TABLE employees (
    emp_id SERIAL PRIMARY KEY,
    dept_id BIGINT,  -- BIGINT로 변경
    CONSTRAINT fk_dept
        FOREIGN KEY (dept_id)
        REFERENCES departments(dept_id)
);

-- 이미 생성된 테이블의 경우 컬럼 타입 변경
ALTER TABLE employees
    ALTER COLUMN dept_id TYPE BIGINT;

-- 그 후 외래 키 제약 조건 추가
ALTER TABLE employees
    ADD CONSTRAINT fk_dept
        FOREIGN KEY (dept_id)
        REFERENCES departments(dept_id);

원인 3 해결: 복합 외래 키 컬럼 수 및 순서 맞추기

-- 부모 테이블 생성 (복합 PRIMARY KEY)
CREATE TABLE order_items_master (
    order_id   INTEGER,
    item_id    INTEGER,
    item_name  VARCHAR(100),
    PRIMARY KEY (order_id, item_id)
);

-- 잘못된 복합 외래 키 정의 (컬럼 순서 불일치)
-- 아래는 42830 에러 발생
CREATE TABLE order_details (
    detail_id SERIAL PRIMARY KEY,
    item_id   INTEGER,
    order_id  INTEGER,
    CONSTRAINT fk_order_item
        FOREIGN KEY (item_id, order_id)        -- 순서가 반대
        REFERENCES order_items_master(order_id, item_id)  -- 순서가 반대
);

-- 올바른 복합 외래 키 정의 (순서 일치)
CREATE TABLE order_details (
    detail_id SERIAL PRIMARY KEY,
    order_id  INTEGER,
    item_id   INTEGER,
    CONSTRAINT fk_order_item
        FOREIGN KEY (order_id, item_id)         -- 순서 일치
        REFERENCES order_items_master(order_id, item_id)
);

-- 이미 잘못 생성된 제약 조건 수정 방법
ALTER TABLE order_details
    DROP CONSTRAINT fk_order_item;

ALTER TABLE order_details
    ADD CONSTRAINT fk_order_item
        FOREIGN KEY (order_id, item_id)
        REFERENCES order_items_master(order_id, item_id);

예방 방법

1. 데이터 모델 설계 시 ERD 기반 검토와 마이그레이션 스크립트 사전 테스트

외래 키 관련 에러의 대부분은 설계 단계에서 충분한 검토 없이 DDL을 실행할 때 발생합니다. ERD(Entity-Relationship Diagram) 도구(예: pgModeler, DBeaver ERD)를 활용하여 외래 키 관계를 시각적으로 확인하고, 실제 운영 DB에 반영하기 전에 반드시 개발 또는 스테이징 환경에서 마이그레이션 스크립트를 검증하는 습관을 들이세요. 또한 아래와 같이 information_schema를 활용하여 참조 대상 컬럼의 제약 조건을 사전에 스크립트로 검증할 수 있습니다.

-- 참조 대상 컬럼에 PRIMARY KEY 또는 UNIQUE 제약 조건이 있는지 사전 확인
SELECT
    tc.table_name,
    kcu.column_name,
    tc.constraint_type
FROM information_schema.table_constraints AS tc
JOIN information_schema.key_column_usage AS kcu
    ON tc.constraint_name = kcu.constraint_name
    AND tc.table_schema = kcu.table_schema
WHERE tc.constraint_type IN ('PRIMARY KEY', 'UNIQUE')
  AND tc.table_name = 'customers'  -- 참조 대상 테이블명
  AND tc.table_schema = 'public';

2. 외래 키 정의 전 컬럼 타입 자동 검증 루틴 도입

팀 내 DBA 또는 개발자가 DDL을 작성할 때 외래 키 컬럼의 데이터 타입을 자동으로 검증하는 스크립트나 CI/CD 파이프라인 내 lint 도구(예: squawk, pgTAP)를 도입하면 실수를 사전에 방지할 수 있습니다. 아래 쿼리를 통해 현재 외래 키와 참조 컬럼 간의 타입 불일치를 주기적으로 점검할 수 있습니다.

-- 외래 키 타입 불일치 점검 쿼리
SELECT
    c.conname AS fk_name,
    c.conrelid::regclass AS child_table,
    a_child.attname AS child_column,
    format_type(a_child.atttypid, a_child.atttypmod) AS child_type,
    c.confrelid::regclass AS parent_table,
    a_parent.attname AS parent_column,
    format_type(a_parent.atttypid, a_parent.atttypmod) AS parent_type
FROM pg_constraint c
JOIN pg_attribute a_child
    ON a_child.attrelid = c.conrelid
    AND a_child.attnum = ANY(c.conkey)
JOIN pg_attribute a_parent
    ON a_parent.attrelid = c.confrelid
    AND a_parent.attnum = ANY(c.confkey)
WHERE c.contype = 'f'
  AND a_child.atttypid <> a_parent.atttypid
ORDER BY child_table, fk_name;