Oracle ORA-01449 오류 원인과 해결 방법 완벽 가이드

ORA-01449
2026년 07월 15일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-01449 column contains NULL values; cannot alter to NOT NULL 란?

ORA-01449 에러는 기존 테이블의 특정 컬럼을 NOT NULL 제약 조건으로 변경하려 할 때, 해당 컬럼에 이미 NULL 값이 존재하는 경우 Oracle 데이터베이스가 발생시키는 오류입니다. 즉, NULL을 허용하던 컬럼을 ALTER TABLE ... MODIFY 구문을 통해 NOT NULL로 바꾸려는 시도가 실패하는 상황입니다. 운영 중인 시스템에서 데이터 정합성을 강화하거나 스키마를 변경할 때 자주 마주치는 에러로, 사전에 데이터를 정제하지 않으면 반드시 발생하게 됩니다.

주요 발생 원인

기존 데이터에 NULL 값이 존재하는 상태에서 NOT NULL 제약 조건 추가 시도

가장 흔한 원인입니다. 테이블이 처음 생성될 때 NULL을 허용하도록 설계되었거나, 오랜 기간 데이터가 쌓이면서 특정 행에 NULL이 포함된 경우입니다. 예를 들어, 레거시 시스템에서 마이그레이션된 데이터나 배치 작업 중 누락된 값이 그대로 남아 있는 경우가 대표적입니다. 이 상태에서 ALTER TABLE MODIFY 명령을 실행하면 Oracle은 기존 데이터를 검증하며 NULL이 발견되는 즉시 ORA-01449를 발생시킵니다.

애플리케이션 레이어에서의 데이터 입력 누락

애플리케이션 코드에서 특정 컬럼 값을 항상 입력하도록 강제하지 않고, 데이터베이스 레이어에도 NOT NULL 제약이 없었던 경우입니다. 이로 인해 오랜 기간 NULL 데이터가 누적되어 있다가, 스키마 강화 작업 시 문제가 드러납니다. 특히 여러 팀이 협업하는 대형 프로젝트에서 컬럼 설계 기준이 문서화되지 않았을 때 자주 발생합니다.

대량 데이터 로딩(ETL, SQL*Loader 등) 시 NULL 처리 미흡

외부 시스템에서 데이터를 적재할 때 소스 데이터에 존재하지 않는 값이 NULL로 삽입되는 경우입니다. SQL*Loader, External Table, Data Pump 등을 통한 대량 적재 과정에서 NULL 값에 대한 기본값 처리나 변환 로직이 누락되면 이 에러로 이어집니다. ETL 파이프라인에서 데이터 품질 검증 단계가 없을 때 특히 위험합니다.

해결 방법

1단계: NULL 값 존재 여부 먼저 확인

-- NULL 데이터 건수 확인
SELECT COUNT(*)
FROM   employees
WHERE  department_id IS NULL;

-- NULL이 있는 실제 데이터 조회
SELECT employee_id, first_name, last_name, department_id
FROM   employees
WHERE  department_id IS NULL;

2단계-A: NULL 값을 기본값으로 UPDATE 후 NOT NULL 적용

가장 권장되는 방법입니다. NULL 값을 적절한 기본값으로 채운 뒤 제약 조건을 추가합니다.

-- NULL 값을 기본값으로 업데이트
UPDATE employees
SET    department_id = 99  -- 기본 부서 ID (미지정 부서)
WHERE  department_id IS NULL;

COMMIT;

-- 이후 NOT NULL 제약 조건 추가
ALTER TABLE employees
MODIFY (department_id NUMBER NOT NULL);

2단계-B: DEFAULT 값을 지정하면서 NOT NULL 변경

Oracle 11g 이상에서는 DEFAULT와 NOT NULL을 동시에 지정하면 기존 NULL 값도 자동 처리됩니다.

-- DEFAULT 값 설정과 함께 NOT NULL 적용 (Oracle 11g 이상)
ALTER TABLE employees
MODIFY (department_id NUMBER DEFAULT 99 NOT NULL);

> ⚠️ 단, 이 방법은 기존 NULL 데이터를 일괄 업데이트하므로 대용량 테이블에서는 Undo 세그먼트 및 Redo 로그 공간을 충분히 확보해야 합니다.

2단계-C: NULL을 제거할 수 없는 경우 – CHECK 제약 조건 활용

비즈니스 로직상 NULL을 완전히 제거하기 어렵다면, 조건부 NOT NULL을 적용하는 대안을 고려합니다.

-- 특정 조건에서만 NOT NULL 강제 (CHECK 제약 활용)
ALTER TABLE orders
ADD CONSTRAINT chk_shipping_date
CHECK (status != 'SHIPPED' OR shipping_date IS NOT NULL);

2단계-D: 대용량 테이블에서의 안전한 처리

-- 배치로 나눠서 NULL 업데이트 (대용량 처리 시 권장)
BEGIN
  LOOP
    UPDATE employees
    SET    department_id = 99
    WHERE  department_id IS NULL
    AND    ROWNUM <= 10000;  -- 10,000건씩 처리
    
    EXIT WHEN SQL%ROWCOUNT = 0;
    COMMIT;
  END LOOP;
END;
/

-- 모든 NULL 제거 확인
SELECT COUNT(*)
FROM   employees
WHERE  department_id IS NULL;

-- NOT NULL 제약 추가
ALTER TABLE employees
MODIFY (department_id NUMBER NOT NULL);

예방 방법

신규 테이블 설계 시 NOT NULL 여부를 명시적으로 결정하고 문서화한다

테이블 설계 단계에서 각 컬럼의 NULL 허용 여부를 비즈니스 요건에 맞게 명확히 정의해야 합니다. 처음부터 NOT NULL이 필요한 컬럼은 반드시 DEFAULT 값과 함께 NOT NULL 제약을 적용하여 데이터 공백이 생기지 않도록 합니다. 또한 DDL 변경 이력을 형상 관리(Git 등)로 관리하여 스키마 변경 시 영향도를 사전에 파악할 수 있도록 합니다.

“`sql

— 올바른 테이블 생성 예시: 중요 컬럼에 DEFAULT + NOT NULL 명시

CREATE TABLE orders (

order_id NUMBER NOT NULL,

customer_id NUMBER NOT NULL,

order_date DATE DEFAULT SYSDATE NOT NULL,

status VARCHAR2(20) DEFAULT ‘PENDING’ NOT NULL,

created_by VARCHAR2(50) DEFAULT USER NOT NULL

);

“`

스키마 변경 전 데이터 품질 점검 스크립트를 자동화한다

운영 DB에 DDL 변경을 적용하기 전, NULL 데이터 현황을 점검하는 스크립트를 CI/CD 파이프라인 또는 배포 프로세스에 포함시켜야 합니다. 이를 통해 사전에 문제를 발견하고 데이터 정제 작업을 선행할 수 있습니다.

“`sql

— 스키마 변경 전 데이터 품질 점검 예시

SELECT column_name,

nullable,

num_nulls,

num_rows,

ROUND(num_nulls / NULLIF(num_rows, 0) * 100, 2) AS null_pct

FROM user_tab_col_statistics

WHERE table_name = ‘EMPLOYEES’

ORDER BY null_pct DESC NULLS LAST;

“`