[오라클 에러] ORA-01017 사용자명/비밀번호 무효 - 6가지 원인과 해결방법 (12c, 19c, 21c 차이까지)

[오라클 에러] ORA-01017 사용자명/비밀번호 무효 - 6가지 원인과 해결방법 (12c, 19c, 21c 차이까지)

테스트 환경: Oracle 11g / 12c / 19c / 21c 

DBA 업무 중 가장 자주 받는 문의가 "비밀번호 분명히 맞는데 ORA-01017이 떠요" 입니다. 단순 오타라면 한 번에 풀리겠지만, 오라클 버전별 인증 방식이 다르고 특수문자 처리 문제까지 겹치면서 의외로 시간을 잡아먹는 에러입니다.

특히 12c 이상에서 비밀번호 대소문자 구분이 강제되고, 21c부터는 케이스 무시 옵션 자체가 제거되면서 예전 매뉴얼대로 처리하다 막히는 경우가 늘었습니다.

이번 글에서는 ORA-01017의 6가지 원인을 분류하고, 버전별 차이점까지 정리했습니다.

 

에러 메시지 전문

ORA-01017: invalid username/password; logon denied
ORA-01017: 사용자명/비밀번호가 부적합. 로그온할 수 없습니다.

SQL*Plus, JDBC, ODBC, 애플리케이션 로그 어디에서나 동일하게 발생합니다.

참고: 이 에러는 "로그인 실패" 만 알려줄 뿐, "왜 실패했는지" 는 알려주지 않습니다. 보안상 의도된 동작이며, 진짜 원인은 직접 진단해야 합니다.

 

 

ORA-01017 빠른 진단 체크리스트

본격적인 해결법 전에, 30초 만에 원인을 좁히는 순서입니다.

1. 사용자명 대소문자, 비밀번호 대소문자 정확히 입력? → 원인 1
2. dba_users에서 계정 존재하나? → 원인 2
3. 계정 상태가 OPEN인가? (LOCKED는 ORA-28000, EXPIRED는 ORA-28001) → 원인 3
4. 비밀번호에 특수문자(@, $, !, # 등) 포함? → 원인 4
5. SYS 계정 접속인데 as sysdba 빠뜨림? → 원인 5
6. 최근 DB 업그레이드(11g → 12c+) 했나? → 원인 6 (가장 까다로움)

하나씩 보겠습니다.

 

< 원인 1> 단순 오타 + 비밀번호 대소문자

가장 흔한 원인이고, 동시에 가장 간과되는 원인입니다.

Oracle 11g부터 비밀번호는 기본적으로 대소문자를 구분합니다. 11g 이전 환경에 익숙한 분들이 자주 놓치는 부분입니다.

-- 둘은 서로 다른 비밀번호로 취급됨
SQL> conn scott/Tiger
SQL> conn scott/tiger

진단 방법

• 사용자명을 다른 곳에 그대로 타이핑해서 오타 확인
• 비밀번호를 메모장에 한 번 쳐서 시각적으로 확인 (특히 l(엘) ↔ 1(일), O ↔ 0 혼동)
• 키보드 한/영 키 상태 확인
• CapsLock 상태 확인

해결 방법

비밀번호를 모른다면 DBA 권한으로 재설정합니다.

ALTER USER scott IDENTIFIED BY NewPassword2026;

비밀번호에 영문 대소문자, 숫자, 특수문자를 섞었다면 반드시 입력 시에도 정확히 동일하게 입력해야 합니다.

 

< 원인 2> 계정 자체가 없음

생각보다 흔한 케이스입니다. 신규 환경 구축, 스키마 이름 오기재, 또는 사용자가 다른 DB 사용자명과 혼동했을 때 발생합니다.

진단 방법

DBA 권한 계정으로 접속해서 확인합니다.

SELECT username, account_status, created
FROM dba_users
WHERE UPPER(username) = UPPER('찾는_사용자명');

행이 0건이면 계정 자체가 없는 것입니다.

해결 방법

계정이 없다면 생성합니다.

CREATE USER scott IDENTIFIED BY Tiger2026;
GRANT CONNECT, RESOURCE TO scott;
GRANT UNLIMITED TABLESPACE TO scott;

실무 팁

운영 환경에서 "있어야 할 계정이 사라진 경우"라면 누군가 DROP USER를 실행했을 가능성이 있습니다. dba_audit_session 또는 통합 감사(unified_audit_trail) 로그를 확인하세요. 작업 이력 추적은 사후 대응에 매우 중요합니다.

 

< 원인 3> 계정이 잠겼거나 만료됨 (다른 에러와 혼동)

엄밀히 말하면 다음 두 케이스는 별도의 에러 코드가 뜨지만, 일부 클라이언트나 애플리케이션 로그에서 ORA-01017으로 묶여서 표시되는 경우가 있어 같이 다룹니다.

• ORA-28000: 계정이 잠겨 있음 (LOCKED)
• ORA-28001: 비밀번호 만료 (EXPIRED)

진단 방법

SELECT username, account_status, lock_date, expiry_date
FROM dba_users
WHERE UPPER(username) = UPPER('사용자명');

account_status 컬럼이 가능한 값:

상태 의미

OPEN	정상
LOCKED	수동 잠금
LOCKED(TIMED)	로그인 실패 횟수 초과로 잠김
EXPIRED	비밀번호 만료
EXPIRED(GRACE)	만료 임박 (유예기간)
EXPIRED & LOCKED	둘 다

해결 방법

-- 잠금 해제
ALTER USER scott ACCOUNT UNLOCK;

-- 비밀번호 재설정 + 만료 해제
ALTER USER scott IDENTIFIED BY NewPassword2026;

상세한 잠금/만료 처리는 다음 글에서 따로 다룹니다.

 

< 원인 4> 비밀번호에 특수문자 포함 (쉘 escape 문제)

비밀번호에 @, $, !, #, & 같은 특수문자가 포함되어 있으면, OS 쉘이 해당 문자를 먼저 해석해버려서 오라클에 잘못된 값이 전달됩니다.

가장 악명 높은 @ 문자

# 비밀번호가 'Tiger@123' 인 경우
sqlplus scott/Tiger@123@ORCL

이건 오라클이 사용자명=scott, 비밀번호=Tiger, DB=123@ORCL로 해석합니다. 당연히 ORA-01017 발생.

해결 방법

1) 큰따옴표로 비밀번호 묶기

sqlplus scott/\"Tiger@123\"@ORCL

Linux/Mac에서는 백슬래시 escape도 같이 써야 합니다.

2) 비밀번호를 분리해서 프롬프트로 입력

sqlplus scott@ORCL
# Enter password: 프롬프트에서 입력

이 방법이 가장 안전합니다. 비밀번호가 셸 히스토리에도 안 남고, 특수문자 escape도 신경 쓸 필요 없습니다.

3) Windows cmd에서는 따옴표 사용

sqlplus scott/"Tiger@123"@ORCL

실무 팁

쉘 스크립트에서 sqlplus를 호출할 때 비밀번호가 특수문자를 포함하면 매번 사고가 납니다. 운영 자동화 스크립트는 비밀번호를 평문 대신 wallet(시큐어 외부 비밀번호 저장소)에 저장하는 것을 강력히 권장합니다. 보안과 안정성을 동시에 잡습니다.

# wallet 사용 시
sqlplus /@ORCL_ALIAS

 

 

< 원인 5> SYS 계정 접속 시 as sysdba 누락

SYS 계정은 일반 접속 방식으로는 들어갈 수 없습니다. 반드시 as sysdba 또는 as sysoper 를 명시해야 합니다.

잘못된 접속 (ORA-01017 발생)

sqlplus sys/manager@ORCL

올바른 접속

sqlplus "sys/manager@ORCL as sysdba"

또는

sqlplus / as sysdba

/만 쓰면 OS 인증(운영체제 계정으로 인증)으로 접속합니다. 서버에 직접 oracle 계정으로 들어와 있다면 비밀번호 없이도 SYS로 접속 가능합니다.

실무 팁

SYSTEM 계정도 가끔 ORA-01017이 나는데, 이건 단순히 비밀번호 문제일 가능성이 높습니다. SYS는 인증 방식 차이, SYSTEM은 일반 계정과 동일하게 다루면 됩니다.

 

< 원인 6> DB 업그레이드 후 발생 (12c+ 인증 모드 변경) ★ 핵심

이 케이스가 ORA-01017 트러블슈팅에서 가장 까다롭습니다. 다른 블로그에서 가장 자주 빠뜨리는 부분이기도 합니다.

무엇이 변했나

Oracle 12c Release 2 (12.2)부터 인증 프로토콜이 "Exclusive Mode"로 기본 설정되었습니다. 이 모드에서는 10G 패스워드 버전(케이스 무시)을 사용할 수 없습니다.

Oracle 21c부터는 SEC_CASE_SENSITIVE_LOGON 파라미터 자체가 제거(desupported) 되었습니다. 즉, 21c에서는 케이스 구분을 끄는 옵션이 아예 없습니다.

어떤 상황에서 문제 되나

11g 또는 그 이전 버전에서 운영하던 DB를 12.2+로 업그레이드한 경우, 다음 조건의 계정은 업그레이드 직후 로그인이 안 됩니다.

• 비밀번호를 11g 이전부터 한 번도 변경하지 않은 계정
• → password_versions 컬럼이 10G만 가지고 있는 상태

진단 방법

SELECT username, password_versions
FROM dba_users
WHERE UPPER(username) = UPPER('사용자명');

결과 해석:

password_versions 의미

10G	케이스 무시 (12.2+에서 로그인 불가)
10G 11G	11g 이상 호환 가능
10G 11G 12C	최신 (가장 안전)
11G 12C	12c 이후 생성/변경된 계정

10G만 있는 계정이 12.2+ 환경에서 ORA-01017이 뜨는 정확한 원인입니다.

해결 방법

1) 비밀번호 재설정 (권장)

ALTER USER scott IDENTIFIED BY NewPassword2026;

비밀번호를 변경하면 현재 인증 모드에 맞는 password version이 자동 생성됩니다. 이게 가장 깔끔합니다.

2) 임시 우회 (12c~19c에서만 가능, 21c 불가)

sqlnet.ora 파일에 다음 설정 추가:

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 11

리스너 또는 DB 재시작 후 적용됩니다. 단, 이건 임시 조치이며 보안 수준을 낮추는 것입니다. 운영 환경에서는 가능한 빨리 비밀번호 재설정 방식으로 전환하세요.

3) 일괄 점검 쿼리 (★ 운영자 필수)

업그레이드 전에 영향받을 계정을 미리 식별합니다.

-- 10G 버전만 가진 계정 식별
SELECT username, password_versions
FROM dba_users
WHERE password_versions = '10G';

이 결과에 있는 모든 계정은 업그레이드 전에 비밀번호를 한 번씩 변경해 두면 사고를 막을 수 있습니다.

실무 팁

운영 DB 업그레이드 직후 갑자기 여러 애플리케이션에서 ORA-01017이 동시 다발로 발생한다면 99% 이 케이스입니다. 당황하지 말고 위 쿼리부터 돌려보세요.

 

그래도 안 풀린다면

위 6가지로도 해결되지 않는 드문 케이스:

• 클라이언트 charset과 서버 charset 불일치로 한글 비밀번호 깨짐: 비밀번호에 한글이 들어있다면 가능한 영문/숫자/특수문자로만 재설정 권장
• failed_login_attempts 정책으로 추가 잠금: 비밀번호 틀린 직후 LOCKED로 전환되어 ORA-01017이 잠시 후 ORA-28000으로 바뀜
• 외부 인증 (OS, LDAP, Kerberos) 환경: dba_users의 authentication_type 컬럼 확인 필요
• PDB 접속 시 service_name 누락: 12c+ 멀티테넌트 환경에서 sqlplus user/pw@host:port/PDB명 형식 필요

---

마무리

ORA-01017은 단순 오타부터 업그레이드 후 인증 모드 변경까지 원인의 폭이 매우 넓은 에러입니다. 한 번에 해결되지 않는다면 위 6가지 원인을 순서대로 짚어보세요. 특히 운영 DB에서 갑자기 발생했다면 최근 변경 이력(업그레이드, 패치, 보안 정책 변경)을 먼저 확인하는 것이 가장 빠른 길입니다.

비밀번호 정책과 password_versions 관리는 평소에 신경 쓰지 않다가 업그레이드 시점에 한꺼번에 터지는 경우가 많습니다. 분기에 한 번씩 dba_users 점검하는 루틴을 권장합니다.

비슷한 케이스를 겪으셨거나, 위 방법으로 해결되지 않은 상황이 있다면 댓글로 공유해 주세요. 함께 진단해 보겠습니다.

---

관련 글

• ORA-12541: TNS 리스너가 없습니다 - 5가지 원인과 해결방법
• ORA-28000: 계정이 잠겼습니다 - 잠금 해제와 재발 방지 (작성 예정)