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

ORA-01722
2026년 07월 27일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-01722 invalid number 는?

ORA-01722 에러는 Oracle이 문자열을 숫자로 변환하려 할 때 변환이 불가능한 값을 만났을 때 발생하는 오류입니다. 예를 들어 숫자형 컬럼에 알파벳이나 특수문자가 포함된 문자열을 삽입하거나, 암묵적(implicit) 형변환 과정에서 숫자로 해석할 수 없는 데이터가 존재할 때 나타납니다. 특히 외부 시스템에서 데이터를 적재하거나 사용자 입력값을 그대로 SQL에 사용하는 환경에서 자주 발생하며, 운영 환경에서 갑작스럽게 배치 작업이 실패하는 원인이 되기도 합니다.

주요 발생 원인

1. 암묵적(Implicit) 형변환 실패

Oracle은 WHERE 절이나 JOIN 조건에서 데이터 타입이 다를 경우 자동으로 형변환을 시도합니다. 예를 들어 VARCHAR2 타입의 컬럼과 NUMBER 타입의 리터럴을 비교할 때, 해당 컬럼에 숫자로 변환할 수 없는 값(‘ABC’, ‘12.34.56’ 등)이 하나라도 존재하면 ORA-01722가 발생합니다. 이 경우 에러가 발생하는 행을 특정하기 어렵기 때문에 디버깅에 상당한 시간이 소요될 수 있습니다.

2. TO_NUMBER() 함수에 잘못된 문자열 전달

개발자가 명시적으로 TO_NUMBER() 함수를 사용할 때, 인자로 전달된 문자열이 숫자 포맷과 맞지 않으면 에러가 발생합니다. 예를 들어 통화 기호($, ₩)나 쉼표(,)가 포함된 문자열을 포맷 마스크 없이 변환하거나, NULL이 아닌 공백(‘ ‘) 문자열을 변환하려 할 때 발생합니다. 특히 프론트엔드에서 넘어온 가공되지 않은(raw) 입력값을 검증 없이 사용하는 경우 이 문제가 빈번하게 나타납니다.

3. INSERT/UPDATE 시 데이터 타입 불일치

NUMBER 타입으로 정의된 컬럼에 문자열 값을 직접 삽입하거나 업데이트할 때 발생합니다. 배치 프로그램이나 ETL 작업에서 소스 데이터의 품질이 보장되지 않은 상태로 대량 적재를 시도할 때 자주 발생합니다. 테이블 스키마를 잘못 이해하거나, 소스 시스템의 컬럼 타입이 변경되었음에도 애플리케이션 코드가 업데이트되지 않은 경우에도 이 에러가 유발됩니다.

해결 방법

원인 1: 암묵적 형변환 문제 해결

문제가 되는 데이터를 먼저 식별하고, 명시적 형변환으로 전환하는 것이 기본 원칙입니다.

-- 문제가 있는 쿼리 예시 (암묵적 형변환 발생)
SELECT *
FROM   orders
WHERE  order_id = '10A5';  -- order_id가 NUMBER 타입일 때

-- 개선된 쿼리: 명시적 형변환 사용
SELECT *
FROM   orders
WHERE  order_id = TO_NUMBER('1005');

-- 문자열 컬럼에 숫자가 섞여 있을 때 비숫자 데이터 찾기
SELECT employee_id, salary_text
FROM   employee_staging
WHERE  REGEXP_LIKE(salary_text, '[^0-9\.\-]');

-- 숫자 여부를 안전하게 확인하는 방법 (Oracle 12c 이상)
SELECT *
FROM   employee_staging
WHERE  VALIDATE_CONVERSION(salary_text AS NUMBER) = 0;

원인 2: TO_NUMBER() 함수 안전하게 사용하기

포맷 마스크를 명시하고, 변환 불가 데이터에 대한 예외 처리를 추가합니다.

-- 잘못된 예시: 포맷 없이 통화 문자열 변환 시도
SELECT TO_NUMBER('$1,234.56') FROM DUAL; -- ORA-01722 발생

-- 올바른 예시: 포맷 마스크와 NLS 파라미터 사용
SELECT TO_NUMBER('$1,234.56', '$999,999.99') FROM DUAL;

-- 공백 문자열 방어 처리
SELECT TO_NUMBER(NULLIF(TRIM(salary_text), ''))
FROM   employee_staging;

-- Oracle 12c 이상: DEFAULT ON CONVERSION ERROR 사용
SELECT TO_NUMBER(salary_text DEFAULT 0 ON CONVERSION ERROR)
FROM   employee_staging;

-- PL/SQL에서 예외 처리로 안전하게 변환
DECLARE
  v_num NUMBER;
BEGIN
  BEGIN
    v_num := TO_NUMBER('ABC123');
  EXCEPTION
    WHEN VALUE_ERROR THEN
      DBMS_OUTPUT.PUT_LINE('변환 불가: 숫자 형식이 아닙니다.');
      v_num := NULL;
  END;
  DBMS_OUTPUT.PUT_LINE('변환 결과: ' || NVL(TO_CHAR(v_num), 'NULL'));
END;
/

원인 3: INSERT/UPDATE 시 데이터 유효성 검사

대량 적재 전 REGEXP 또는 VALIDATE_CONVERSION으로 사전 검증합니다.

-- 적재 전 비정상 데이터 확인
SELECT COUNT(*) AS invalid_count
FROM   staging_table
WHERE  NOT REGEXP_LIKE(amount_col, '^-?[0-9]+(\.[0-9]+)?$');

-- 정상 데이터만 적재 (필터링 방식)
INSERT INTO target_table (id, amount)
SELECT id, TO_NUMBER(amount_col)
FROM   staging_table
WHERE  REGEXP_LIKE(amount_col, '^-?[0-9]+(\.[0-9]+)?$');

-- Oracle 12c 이상: VALIDATE_CONVERSION 활용
INSERT INTO target_table (id, amount)
SELECT id, TO_NUMBER(amount_col)
FROM   staging_table
WHERE  VALIDATE_CONVERSION(amount_col AS NUMBER) = 1;

-- 비정상 데이터는 별도 오류 테이블로 분리
INSERT INTO error_log (id, amount_col, error_msg, log_date)
SELECT id, amount_col, 'Invalid Number', SYSDATE
FROM   staging_table
WHERE  VALIDATE_CONVERSION(amount_col AS NUMBER) = 0;

예방 방법

1. 애플리케이션 레벨에서 입력값 검증 강화 및 명시적 형변환 원칙 준수

데이터가 Oracle DB에 도달하기 전에 애플리케이션 또는 미들웨어 레벨에서 숫자 타입 유효성 검사를 반드시 수행합니다. SQL 작성 시에는 암묵적 형변환에 절대 의존하지 말고, TO_NUMBER(), TO_CHAR(), TO_DATE() 등 명시적 변환 함수를 항상 사용하는 코딩 컨벤션을 팀 전체에 적용하고 코드 리뷰 체크리스트에 포함시킵니다.

2. 스테이징 테이블 활용 및 데이터 품질 검증 프로세스 구축

ETL 또는 배치 작업 시 소스 데이터를 바로 운영 테이블에 적재하지 말고, 모든 컬럼이 VARCHAR2인 스테이징 테이블에 먼저 적재한 후 VALIDATE_CONVERSION 함수와 REGEXP 조건으로 데이터 품질을 검증하는 단계를 의무화합니다. 검증 실패 데이터는 오류 로그 테이블에 기록하고 담당자에게 알림을 발송하는 자동화 프로세스를 구성하면 운영 안정성을 크게 높일 수 있습니다.