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

ORA-12599
2026년 09월 15일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-12599 TNS: cryptographic checksum mismatch 는?

ORA-12599 에러는 Oracle Net Services(TNS)에서 데이터 전송 중 암호화 체크섬(Cryptographic Checksum) 값이 일치하지 않을 때 발생하는 오류입니다. 클라이언트와 서버 간의 네트워크 통신에서 데이터 무결성을 검증하는 체크섬 알고리즘이나 설정이 서로 맞지 않을 경우 연결 자체가 거부되며, 이로 인해 애플리케이션이 Oracle 데이터베이스에 접속하지 못하는 심각한 장애로 이어질 수 있습니다. 주로 sqlnet.ora 파일의 잘못된 설정, 클라이언트와 서버 Oracle 버전 간의 불일치, 또는 네트워크 장비에 의한 패킷 변조가 의심될 때 이 에러가 발생합니다.

주요 발생 원인

1. sqlnet.ora 파일의 CHECKSUM 설정 불일치

가장 빈번하게 발생하는 원인으로, 클라이언트 측과 서버 측 sqlnet.ora 파일에 설정된 SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT와 SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER 값이 서로 호환되지 않을 때 발생합니다. 예를 들어 서버는 SHA256을 필수(REQUIRED)로 요구하는데 클라이언트는 MD5만 지원하도록 설정되어 있거나, 한쪽은 REQUIRED이고 다른 쪽은 REJECTED로 설정된 경우 연결이 완전히 차단됩니다. 특히 Oracle 클라이언트를 업그레이드한 직후, 또는 보안 정책 강화로 인해 서버 설정만 변경하고 클라이언트 설정을 동기화하지 않은 상황에서 집중적으로 발생합니다.

2. Oracle 클라이언트와 서버 버전 간의 알고리즘 지원 차이

Oracle 버전에 따라 지원하는 암호화 알고리즘의 종류가 다르며, 구버전 클라이언트가 신버전 서버에 접속하거나 그 반대의 경우에 체크섬 알고리즘 협상이 실패할 수 있습니다. 예를 들어 Oracle 12c 이전 클라이언트는 SHA-256 이상의 알고리즘을 지원하지 않을 수 있으며, 서버가 SHA-256 이상만 허용하도록 설정되어 있다면 핸드셰이크 단계에서 ORA-12599가 발생합니다. 이 경우 단순히 설정을 맞추는 것만으로는 해결이 안 되며, 클라이언트 바이너리 자체를 업그레이드해야 합니다.

3. 네트워크 장비 또는 중간 프록시에 의한 패킷 변조

방화벽, 로드밸런서, SSL 오프로딩 장비, 또는 DPI(Deep Packet Inspection)를 수행하는 네트워크 장비가 Oracle TNS 패킷의 내용을 변조하거나 재조합할 경우, 수신 측에서 체크섬을 재계산했을 때 원본 값과 달라져 ORA-12599가 발생합니다. 이 케이스는 개발 환경에서는 문제가 없다가 운영 환경에서만 에러가 발생하는 패턴을 보이는 경우가 많으며, 네트워크 팀과 협력하여 패킷 캡처 분석을 통해 원인을 규명해야 합니다. 특히 Oracle Advanced Security Option(ASO)이 적용된 환경에서 이중 암호화 구간이 생기면 이 문제가 더욱 두드러집니다.

해결 방법

원인 1 해결: sqlnet.ora 설정 동기화

서버와 클라이언트 양측의 sqlnet.ora를 열어 CHECKSUM 관련 파라미터를 확인하고 정합성을 맞춥니다.

서버 측 $ORACLE_HOME/network/admin/sqlnet.ora 설정 예시:

-- 서버 sqlnet.ora 설정 (권장 보안 수준 유지하면서 호환성 확보)
SQLNET.CRYPTO_CHECKSUM_SERVER = ACCEPTED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA1, MD5)

-- 만약 즉각적인 장애 복구가 필요하다면 임시로 NONE 설정 가능 (보안 주의)
-- SQLNET.CRYPTO_CHECKSUM_SERVER = NONE

클라이언트 측 sqlnet.ora 설정 예시:

-- 클라이언트 sqlnet.ora 설정
SQLNET.CRYPTO_CHECKSUM_CLIENT = REQUESTED
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (SHA256, SHA1, MD5)

현재 적용된 설정 확인 쿼리 (서버 파라미터 뷰 활용):

-- Oracle 네트워크 설정 관련 파라미터 확인
SELECT NAME, VALUE
FROM   V$PARAMETER
WHERE  NAME LIKE '%crypto%'
    OR NAME LIKE '%checksum%'
    OR NAME LIKE '%sqlnet%'
ORDER BY NAME;

sqlnet.ora 설정 변경 후 리스너 재기동 없이 적용 여부 확인:

-- 리스너 상태 확인 (OS 명령어이나 DBA가 반드시 확인해야 하는 항목)
-- lsnrctl status
-- lsnrctl reload  (대부분의 sqlnet.ora 변경은 reload로 반영 가능)

-- 세션 레벨에서 현재 암호화/체크섬 정보 확인
SELECT SID,
       SERIAL#,
       USERNAME,
       NETWORK_SERVICE_BANNER
FROM   V$SESSION_CONNECT_INFO
WHERE  NETWORK_SERVICE_BANNER LIKE '%Checksum%'
    OR NETWORK_SERVICE_BANNER LIKE '%checksum%';

원인 2 해결: 버전 호환성 확인 및 알고리즘 조정

클라이언트 버전이 낮아 최신 알고리즘을 지원하지 않는 경우, 서버 측 허용 알고리즘 목록에 하위 호환 알고리즘을 추가합니다.

-- 현재 데이터베이스 버전 확인
SELECT BANNER FROM V$VERSION;

-- 클라이언트 접속 정보 및 사용 중인 서비스 배너 확인
SELECT SID,
       SERIAL#,
       USERNAME,
       PROGRAM,
       MACHINE,
       NETWORK_SERVICE_BANNER
FROM   V$SESSION_CONNECT_INFO
WHERE  SID IN (
    SELECT SID FROM V$SESSION WHERE USERNAME IS NOT NULL
)
ORDER BY SID;

-- 접속 실패 이력 확인 (Audit가 활성화된 경우)
SELECT OS_USERNAME,
       USERNAME,
       USERHOST,
       TERMINAL,
       TIMESTAMP,
       ACTION_NAME,
       RETURNCODE
FROM   DBA_AUDIT_SESSION
WHERE  RETURNCODE = 12599
ORDER BY TIMESTAMP DESC
FETCH FIRST 20 ROWS ONLY;

원인 3 해결: 네트워크 장비 우회 및 체크섬 비활성화 테스트

네트워크 장비에 의한 패킷 변조가 의심될 경우, 임시로 체크섬을 비활성화하여 원인을 격리합니다.

-- [진단 목적 임시 설정 - 운영 반영 전 보안팀 승인 필요]
-- 서버 sqlnet.ora에서 체크섬 비활성화 (원인 격리용)
-- SQLNET.CRYPTO_CHECKSUM_SERVER = NONE

-- 비활성화 후 접속 테스트를 통해 네트워크 장비 원인 여부 확인
-- 원인 확인 후 반드시 원복 필요

-- 특정 IP 대역에서 오는 세션만 모니터링
SELECT S.SID,
       S.SERIAL#,
       S.USERNAME,
       S.MACHINE,
       S.OSUSER,
       S.PROGRAM,
       S.STATUS,
       CI.NETWORK_SERVICE_BANNER
FROM   V$SESSION S
JOIN   V$SESSION_CONNECT_INFO CI ON S.SID = CI.SID
WHERE  S.USERNAME IS NOT NULL
  AND  CI.NETWORK_SERVICE_BANNER IS NOT NULL
ORDER BY S.LOGON_TIME DESC;

예방 방법

1. 클라이언트-서버 sqlnet.ora 변경 관리 프로세스 수립

sqlnet.ora 파일은 서버와 클라이언트 양측이 항상 동기화되어야 하므로, 변경 관리(Change Management) 프로세스에 반드시 양측을 함께 검토하는 절차를 포함시켜야 합니다. 보안 정책 업그레이드나 패치 적용 시 서버와 클라이언트 설정 변경을 배포 계획에 동시에 포함시키고, 변경 전 테스트 환경에서 반드시 양방향 접속 테스트를 선행하는 것이 Best Practice입니다. 또한 주요 파라미터인 SQLNET.CRYPTO_CHECKSUM_SERVER, SQLNET.CRYPTO_CHECKSUM_CLIENT, SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER, SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT는 형상 관리 도구(Git 등)로 버전 이력을 관리하는 것을 권장합니다.

2. 정기적인 접속 감사 및 알림 체계 구축

ORA-12599는 보안 사고의 전조 증상일 수도 있으므로, alert.log와 listener.log를 주기적으로 모니터링하고 ORA-12599 패턴이 감지될 때 즉시 알림이 발송되도록 모니터링 체계를 구축해야 합니다. 아래 쿼리를 활용하여 DBA_AUDIT_SESSION을 정기적으로 점검하고, 특정 IP나 사용자로부터 반복적으로 12599 에러가 발생하는 경우 보안팀에 에스컬레이션하는 절차를 정립하십시오.

-- 주기적 모니터링용 쿼리 (Cron 또는 DBMS_SCHEDULER로 자동화 권장)
SELECT USERHOST,
       USERNAME,
       COUNT(*) AS FAIL_COUNT,
       MIN(TIMESTAMP) AS FIRST_FAIL,
       MAX(TIMESTAMP) AS LAST_FAIL
FROM   DBA_AUDIT_SESSION
WHERE  RETURNCODE = 12599
  AND  TIMESTAMP >= SYSDATE - 1  -- 최근 24시간
GROUP BY USERHOST, USERNAME
HAVING COUNT(*) >= 3
ORDER BY FAIL_COUNT DESC;