PI_PO

SAP PO JDBC 드라이버 Deprecated 오류 원인과 해결법 정리 (SPI, Lazy vs Eager 로딩까지)

피오농부 2025. 6. 6. 23:26
반응형
SAP PO 재기동 후 갑자기 등장하는 com.mysql.jdbc.Driver is deprecated 오류 메시지. 왜 이제야 나오는 걸까요? 이 글에서 JDBC 드라이버 로딩 방식과 SPI 개념까지 초보자도 이해할 수 있도록 정리해드립니다.

목차

  1. SAP PO JDBC 드라이버 경고 메시지 현상
  2. com.mysql.jdbc.Driver Deprecated 경고의 의미
  3. Lazy Loading과 Eager Loading의 차이점
  4. SPI(Service Provider Interface)란?
  5. 왜 이번에만 경고 로그가 보였을까? 가능한 원인 분석
  6. 실제 문제인지? 해결이 필요한지?
  7. 결론 및 권장 대응 방안
  8. 마무리 요약과 체크리스트

1. SAP PO JDBC 드라이버 경고 메시지 현상

SAP Process Orchestration(PO) 서버에서 PM(정기점검) 후 재기동을 했는데, 갑자기 로그 뷰어에서 아래와 같은 메시지가 출력되었다면 놀라셨을 겁니다.
Loading class 'com.mysql.jdbc.Driver'. This is deprecated. 
The new driver class is 'com.mysql.cj.jdbc.Driver'. 
The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary.
이 오류는 무엇이고, 왜 지금에야 나타난 걸까요?

2. com.mysql.jdbc.Driver Deprecated 경고의 의미

이 메시지는 에러(Error) 가 아니라 경고(Warning) 메시지입니다.
MySQL JDBC 드라이버는 8.0 버전 이후로 구버전 클래스 com.mysql.jdbc.Driver를 더 이상 권장하지 않으며, com.mysql.cj.jdbc.Driver로 대체되었습니다.
이전 드라이버 클래스를 수동으로 로딩하거나 설정에 포함하면, 드라이버 내부에서 직접 경고를 출력합니다. 예전에는 이 로그가 안 보였다면, 그 이유는 클래스 로딩 시점이 늦어서일 수 있습니다. 이 부분은 Lazy vs Eager 로딩에서 더 자세히 다룹니다.

3. Lazy Loading과 Eager Loading의 차이점

Lazy Loading (지연 로딩)

  • JDBC 드라이버는 채널이 처음 실행될 때 로딩
  • PO 서버 재기동 시에는 드라이버 로딩이 발생하지 않음
  • 경고 로그는 메시지 폴링 시점에 출력되므로 눈에 안 띌 수 있음

Eager Loading (즉시 로딩)

  • PO 서버가 재시작될 때 JDBC 드라이버를 즉시 로딩
  • SPI나 Class.forName(...) 호출로 인해 강제 로딩
  • 로그에 경고 메시지가 부팅 직후에 바로 출력
즉: Lazy Loading 시엔 드라이버 로딩이 늦게 발생하여 로그가 묻히고,
Eager Loading 시엔 로그 초반에 보여서 "갑자기 생긴 것처럼" 보입니다.

4. SPI(Service Provider Interface)란?

SPI는 Java에서 특정 서비스 구현체를 자동으로 등록하고 로딩하기 위한 구조입니다.
JDBC 드라이버 JAR 안에는 다음 경로의 파일이 포함되어 있습니다:
META-INF/services/java.sql.Driver
여기에 com.mysql.cj.jdbc.Driver가 적혀 있으면, JVM은 별도의 로딩 코드 없이도 자동으로 드라이버를 로딩합니다. 이것이 바로 Eager 로딩을 유도하는 메커니즘입니다.
결론: SPI 파일이 존재하면 SAP PO 서버가 재기동될 때 해당 드라이버를 자동으로 로딩하게 되어, 경고 메시지가 서버 부팅 시점에 바로 출력될 수 있습니다.

5. 왜 이번에만 경고 로그가 보였을까? 가능한 원인 분석

동일한 SAP PO 버전, 동일한 JDK와 JDBC 드라이버를 수년 간 사용해왔는데, 왜 이번 재기동에만 경고 로그가 보였을까요?
아래는 가능한 원인입니다:

1. JDBC 드라이버 JAR이 다시 배포됨

  • PM 중 mysql-connector-java-8.0.11.jar 파일이 다시 업로드되었거나 경로가 변경됨
  • PO는 이를 새 파일로 인식하고 SPI 처리를 재수행

2. JDBC Sender 채널이 재기동 직후 즉시 작동

  • 과거에는 Lazy하게 동작했다면
  • 이번에는 즉시 JDBC 채널이 실행되며 드라이버가 바로 로딩됨

3. 드라이버 로딩 코드 변경 또는 활성화

  • Class.forName("com.mysql.jdbc.Driver") 같은 코드가 추가됨
  • Java Mapping, UDF, Adapter Module 중 어디선가 이 호출이 생겼을 수도 있음

4. 로그 출력 방식 변경

  • 기존엔 STDERR 로그가 콘솔에만 출력되고 로그파일엔 기록되지 않음
  • 이번엔 NWA 설정 변경이나 로깅 방식 변경으로 로그파일에 남게 됨

5. ClassLoader 캐시가 초기화됨

  • PO는 J2EE 기반이므로 ClassLoader가 캐시를 사용
  • PM 중 재기동으로 캐시 초기화 → 드라이버 클래스가 새로 로딩되며 로그 노출

6. 실제 문제인가? 해결이 필요한가?

아니요. 시스템 작동 자체에는 아무런 영향을 주지 않습니다.
하지만 경고 로그가 쌓이면 다음과 같은 운영상 이슈가 발생할 수 있습니다:
  • 로그 분석 시 불필요한 경고로 오해
  • 보안 감시 시스템에서 불필요한 알람 발생
  • 신규 운영자가 실제 오류로 오해할 가능성

7. 결론 및 권장 대응 방안

1. JDBC 드라이버 클래스 명시 변경

com.mysql.jdbc.Driver → com.mysql.cj.jdbc.Driver 로 설정 변경

2. 수동 드라이버 로딩 코드 제거

Java 코드나 UDF에 있는 Class.forName("com.mysql.jdbc.Driver") 제거

3. 로그 무시도 가능

INFO 수준 로그이므로 심각한 문제가 아니라면 운영 로그 필터링으로 관리 가능

8. 마무리 요약과 체크리스트

왜 지금에야 경고 로그가 보였나?
  • JAR 재배포 or SPI 재작동
  • JDBC 채널의 즉시 작동
  • 드라이버 수동 로딩 코드 추가
  • STDERR 로그 방식 변경
  • ClassLoader 캐시 초기화
해결 방법은?
  • 드라이버 클래스 이름 최신화
  • 수동 로딩 코드 제거
  • 로그레벨 조정 또는 무시
체크리스트로 다시 정리해봅시다:
  • [ ] JDBC 채널 설정 확인 (com.mysql.cj.jdbc.Driver 사용 여부)
  • [ ] 드라이버 수동 로딩 코드 여부 확인
  • [ ] JAR 배포 시점 및 타임스탬프 확인
  • [ ] 로그 파일 내 다른 시점 경고와 비교
  • [ ] 필요 시 로그 필터링 정책 수정
반응형