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

ORA-04043
2026년 08월 21일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-04043 object does not exist 는?

ORA-04043 에러는 Oracle 데이터베이스에서 참조하려는 객체(테이블, 뷰, 시퀀스, 프로시저 등)가 실제로 존재하지 않을 때 발생하는 에러입니다. 주로 DDL(Data Definition Language) 작업이나 객체를 조회할 때 잘못된 객체명을 입력하거나, 해당 스키마에 객체가 생성되지 않은 경우에 발생합니다. 데이터베이스 마이그레이션, 개발 환경 전환, 또는 타 스키마 객체를 참조할 때 특히 자주 마주치는 에러입니다.

주요 발생 원인

1. 객체명 오타 또는 대소문자 불일치

Oracle은 기본적으로 객체명을 대문자로 저장합니다. 따라서 객체를 생성할 때 큰따옴표(")를 사용하여 소문자로 생성한 경우, 이후 참조 시 반드시 동일하게 큰따옴표와 소문자를 사용해야 합니다. 예를 들어 "myTable"로 생성한 테이블을 MYTABLE로 조회하면 ORA-04043이 발생합니다.

2. 잘못된 스키마(소유자) 참조

현재 세션의 사용자 스키마와 다른 스키마에 객체가 존재하는데, 스키마명 없이 객체명만 사용하는 경우 에러가 발생합니다. 예를 들어 HR 스키마의 테이블을 SCOTT 계정에서 스키마 접두사 없이 조회하면 Oracle은 해당 객체를 찾지 못합니다. 또한 PUBLIC SYNONYM이 없거나 GRANT가 부여되지 않은 경우에도 이 에러가 발생할 수 있습니다.

3. 객체가 실제로 삭제되었거나 아직 생성되지 않은 경우

개발 및 운영 환경에서 테이블이나 프로시저가 DROP된 이후 관련 코드가 수정되지 않아 삭제된 객체를 참조할 때 발생합니다. 또한 배포 순서 오류로 인해 의존 객체(예: 뷰가 참조하는 테이블)가 아직 생성되지 않은 상태에서 컴파일을 시도할 때도 동일한 에러가 발생합니다.

해결 방법

원인 1: 객체명 확인 및 대소문자 점검

먼저 DBA_OBJECTS 또는 ALL_OBJECTS, USER_OBJECTS 뷰를 통해 실제 객체가 존재하는지 확인합니다.

-- 현재 사용자 소유 객체 확인
SELECT object_name, object_type, status
FROM user_objects
WHERE object_name = UPPER('employees');  -- 대문자로 변환하여 조회

-- 전체 스키마에서 객체 검색 (DBA 권한 필요)
SELECT owner, object_name, object_type, status
FROM dba_objects
WHERE object_name = UPPER('employees')
ORDER BY owner;

-- 소문자(큰따옴표)로 생성된 객체 확인
SELECT object_name, object_type
FROM user_objects
WHERE object_name = 'employees';  -- 소문자 그대로 검색

객체가 소문자로 생성되어 있다면 항상 큰따옴표를 사용하여 참조합니다.

-- 소문자 객체명 참조 방법
SELECT * FROM "employees";  -- 반드시 큰따옴표 사용

원인 2: 스키마명 및 권한 확인

타 스키마의 객체를 참조할 경우 스키마명을 명시하거나, PUBLIC SYNONYM을 생성합니다.

-- 스키마명을 명시하여 객체 참조
SELECT * FROM hr.employees;

-- 현재 세션의 스키마 확인
SELECT sys_context('USERENV', 'CURRENT_SCHEMA') AS current_schema FROM dual;

-- 특정 객체에 대한 권한 확인
SELECT grantee, owner, table_name, privilege
FROM dba_tab_privs
WHERE table_name = 'EMPLOYEES'
  AND owner = 'HR';

-- 권한 부여 (DBA 권한 필요)
GRANT SELECT ON hr.employees TO scott;

-- PUBLIC SYNONYM 생성으로 스키마 접두사 없이 접근
CREATE PUBLIC SYNONYM employees FOR hr.employees;

-- 이후 스키마 없이 조회 가능
SELECT * FROM employees;

원인 3: 객체 존재 여부 확인 및 재생성

RECYCLE BIN(휴지통)에서 복구하거나, 스크립트를 통해 재생성합니다.

-- 삭제된 객체가 RECYCLE BIN에 있는지 확인
SELECT object_name, original_name, type, droptime
FROM recyclebin
WHERE original_name = 'EMPLOYEES';

-- RECYCLE BIN에서 복구
FLASHBACK TABLE employees TO BEFORE DROP;

-- 객체 존재 여부를 동적으로 확인하는 방법 (PL/SQL)
DECLARE
  v_count NUMBER;
BEGIN
  SELECT COUNT(*)
  INTO v_count
  FROM user_objects
  WHERE object_name = 'EMPLOYEES'
    AND object_type = 'TABLE';

  IF v_count = 0 THEN
    DBMS_OUTPUT.PUT_LINE('테이블이 존재하지 않습니다. 생성이 필요합니다.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('테이블이 존재합니다.');
  END IF;
END;
/

-- INVALID 상태 객체 재컴파일
ALTER TABLE employees COMPILE;
ALTER PROCEDURE my_procedure COMPILE;

-- 스키마 전체 INVALID 객체 재컴파일 (DBA 권한)
EXEC UTL_RECOMP.RECOMP_SERIAL('HR');

예방 방법

1. 배포 전 의존성 체크 자동화

DDL 스크립트 배포 전 반드시 객체 의존성을 사전에 점검하는 검증 스크립트를 CI/CD 파이프라인에 포함시켜야 합니다. DBA_DEPENDENCIES 뷰를 활용하여 참조 객체 존재 여부를 자동으로 확인하고, INVALID 상태의 객체가 있을 경우 배포를 차단하는 정책을 수립하세요.

-- 특정 객체가 의존하는 객체 목록 확인
SELECT name, type, referenced_owner, referenced_name, referenced_type
FROM dba_dependencies
WHERE owner = 'HR'
  AND name = 'MY_PROCEDURE';

-- INVALID 상태 객체 모니터링 쿼리 (정기 점검용)
SELECT owner, object_name, object_type, last_ddl_time, status
FROM dba_objects
WHERE status = 'INVALID'
ORDER BY owner, object_type, object_name;

2. 명명 규칙(Naming Convention) 표준화 및 소문자 객체명 사용 금지

팀 내 데이터베이스 객체 명명 규칙을 문서화하고, 반드시 대문자 또는 일관된 표기법을 사용하도록 강제합니다. 큰따옴표를 이용한 소문자 객체명은 유지보수 시 혼란을 유발하므로 사용을 금지하고, 코드 리뷰 체크리스트에 이를 포함시켜 관리합니다.