WildFly 9 배포 시 Unsupported major.minor version 52.0 오류 원인과 해결 방향

WildFly 9 배포 시 Unsupported major.minor version 52.0 오류 원인과 해결 방향

WildFly 9.0.2.Final에서 DataServer.war와 ReportingServer.war를 배포하는 과정에서 다음 오류가 발생할 수 있습니다.

java.lang.UnsupportedClassVersionError:
org/quartz/SchedulerException : Unsupported major.minor version 52.0

또는 다음과 같이 JDBC Driver를 로딩하는 과정에서도 동일한 오류가 발생할 수 있습니다.

java.lang.UnsupportedClassVersionError:
org/hsqldb/jdbc/JDBCDriver : Unsupported major.minor version 52.0

이 오류의 핵심은 WildFly 자체가 아니라 WildFly를 실행하는 Java 버전과 WAR 내부 클래스의 컴파일 버전이 맞지 않는 것입니다.

현재 실행 환경

WildFly 시작 로그를 보면 현재 서버는 다음 Java를 사용하고 있습니다.

JBOSS_HOME: /data/wildfly-9.0.2.Final

JAVA: /opt/jdk1.7.0_80/bin/java

WildFly Full 9.0.2.Final
(WildFly Core 1.0.2.Final)

즉 현재 구조는 다음과 같습니다.

WildFly 9.0.2.Final
        │
        └── Java 7
            /opt/jdk1.7.0_80/bin/java

WildFly 서버 자체는 Java 7 JVM에서 기동되고 있습니다. 실제 로그에서도 Undertow가 8080 포트를 열고 관리 인터페이스가 9990 포트에서 시작되는 단계까지 진행됩니다.

WFLYUT0006: Undertow HTTP listener default listening on /0.0.0.0:8080

WFLYSRV0060: Http management interface listening on
http://127.0.0.1:9990/management

따라서 이번 장애를 단순히 WildFly가 실행되지 않는 문제로 보면 안 됩니다. WildFly 프로세스는 올라왔지만 애플리케이션 배포 과정에서 문제가 발생한 것입니다.

Unsupported major.minor version 52.0의 의미

Java의 .class 파일에는 해당 클래스가 어떤 Java 버전을 대상으로 컴파일됐는지 나타내는 Class File Version이 들어 있습니다.

Java 버전과 Class File Major Version

Java 버전	Major Version
Java 7	51
Java 8	52
Java 11	55
Java 17	61
Java 21	65

따라서 다음 오류는 의미가 명확합니다.

Unsupported major.minor version 52.0

Java 8용으로 컴파일된 클래스를 현재 Java 7 JVM이 읽으려고 했다는 의미입니다.

DataServer.war가 실패한 직접 원인

DataServer.war에서는 Quartz의 SchedulerException을 로딩하는 과정에서 오류가 발생했습니다.

Failed to define class org.quartz.SchedulerException

java.lang.UnsupportedClassVersionError:
org/quartz/SchedulerException :
Unsupported major.minor version 52.0

실행 구조를 단순화하면 다음과 같습니다.

Java 7
  │
  └── WildFly 9
       │
       └── DataServer.war
            │
            └── Quartz
                 │
                 └── SchedulerException.class
                      major version 52
                      ↑
                      Java 8 bytecode

Java 7 JVM
    ↓
Java 8 bytecode 로딩
    ↓
UnsupportedClassVersionError

결국 DataServer.war의 애플리케이션 초기화 과정이 중단됩니다.

ReportingServer.war도 같은 문제

ReportingServer.war에서는 다른 라이브러리에서 동일한 문제가 발생합니다.

Failed to define class org.hsqldb.jdbc.JDBCDriver

java.lang.UnsupportedClassVersionError:
org/hsqldb/jdbc/JDBCDriver :
Unsupported major.minor version 52.0

이번에는 HSQLDB JDBC Driver가 Java 8 bytecode를 포함하고 있고, Java 7 JVM이 해당 클래스를 읽지 못한 것입니다.

ReportingServer.war
        │
        └── HSQLDB
             │
             └── JDBCDriver.class
                  │
                  └── major version 52
                       ↓
                    Java 8 필요

따라서 두 WAR에서 서로 다른 클래스가 실패하고 있지만 현재 로그에서 확인되는 직접적인 원인은 동일합니다.

WildFly 로그의 Deployed 메시지만 보면 안 되는 이유

로그 중간에는 다음 메시지가 있습니다.

WFLYSRV0010: Deployed "ReportingServer.war"
WFLYSRV0010: Deployed "DataServer.war"

이 메시지만 보면 두 WAR가 정상적으로 배포된 것처럼 보일 수 있습니다. 하지만 이후 최종 상태를 보면 서버는 다음과 같이 시작됩니다.

WFLYSRV0026:
WildFly Full 9.0.2.Final
started (with errors)

또한 실패한 서비스가 명확하게 기록되어 있습니다.

Services which failed to start:

jboss.deployment.unit."ReportingServer.war".INSTALL

jboss.undertow.deployment.default-server.default-host./DataServer

이후 두 Deployment가 중지되고 undeploy되는 로그까지 나타납니다.

Stopped deployment DataServer.war
Stopped deployment ReportingServer.war

Undeployed "DataServer.war"
Undeployed "ReportingServer.war"

따라서 이 상태를 정상 배포 완료로 판단해서는 안 됩니다.

META-INF/versions/9/module-info.class 경고는 무엇인가?

같은 로그에서는 다음과 같은 경고도 반복적으로 나타납니다.

Could not index class
META-INF/versions/9/module-info.class

java.lang.IllegalStateException:
Unknown tag!

실제 대상 라이브러리로 다음과 같은 파일들이 확인됩니다.

commons-beanutils-1.11.0.jar
commons-codec-1.19.0.jar
gson-2.13.2.jar
commons-email-1.6.0.jar
jsch-2.27.9.jar

META-INF/versions/9는 Java 9 이후 도입된 Multi-Release JAR 구조에서 사용될 수 있는 경로입니다. 반면 WildFly 9.0.2.Final은 오래된 JBoss Modules 및 Jandex를 사용합니다.

따라서 이 로그는 상대적으로 오래된 WildFly 9 환경에 훨씬 최근의 라이브러리가 포함된 WAR를 배포하고 있다는 점도 함께 확인할 필요가 있음을 보여줍니다.

다만 이 경고와 Unsupported major.minor version 52.0 오류는 구분해서 봐야 합니다. 현재 배포를 실제로 실패시키는 직접적인 오류로 확인되는 것은 Quartz와 HSQLDB 클래스를 Java 7이 읽지 못하는 문제입니다.

Java 8로 변경하면 해결되는가?

현재 로그에서 나타난 major version 52.0 오류만 놓고 보면 Java 8 이상의 JVM으로 실행하면 해당 클래스 파일을 읽을 수 있습니다.

현재

Java 7
  ↓
major version 52 로딩
  ↓
실패


Java 8 이상

Java 8+
  ↓
major version 52 로딩
  ↓
가능

하지만 Java 8로 변경하면 전체 애플리케이션이 반드시 정상 배포된다고 단정할 수는 없습니다.

WAR 내부에는 여러 라이브러리가 포함되어 있으며, 현재 오류 때문에 뒤쪽 로딩 단계까지 진행하지 못했을 가능성이 있습니다. Java 8로 첫 번째 문제를 해결한 뒤 다른 버전 호환성 문제가 추가로 나타날 수도 있습니다.

Java 버전을 올리기 전에 WAR의 요구 버전을 확인하는 방법

현재 상황에서는 무조건 Java 21부터 설치하기보다 실제 WAR 내부 클래스가 어느 Java 버전을 요구하는지 먼저 확인하는 것이 좋습니다.

예를 들어 애플리케이션 클래스의 Major Version을 다음과 같이 확인할 수 있습니다.

/opt/jdk1.7.0_80/bin/javap -verbose \
/data/wildfly-9.0.2.Final/standalone/deployments/DataServer.war/WEB-INF/classes/m2soft/ers/data/core/Server.class \
| grep "major version"

결과가 다음과 같다면 Java 7 대상으로 컴파일된 클래스입니다.

major version: 51

다음과 같다면 Java 8입니다.

major version: 52

다만 애플리케이션 클래스 하나만 검사해서 전체 WAR의 최소 Java 버전을 확정할 수는 없습니다. WEB-INF/lib 아래의 라이브러리에도 더 높은 버전으로 컴파일된 클래스가 존재할 수 있기 때문입니다.

Java 7을 계속 유지해야 한다면?

기존 운영 환경 때문에 반드시 Java 7을 유지해야 한다면 WAR에 포함된 라이브러리 역시 Java 7과 호환되는 버전으로 맞춰야 합니다.

Java 7 유지
   ↓
WildFly 9 유지
   ↓
WAR 내부 라이브러리 조사
   ↓
Java 8+ 요구 라이브러리 식별
   ↓
Java 7 호환 버전으로 변경
   ↓
애플리케이션 재빌드 및 테스트

하지만 현재 WAR에는 비교적 최근 버전의 라이브러리들이 포함되어 있으므로 단순히 Quartz나 HSQLDB 하나만 교체해서 끝난다고 보기는 어렵습니다.

기존 Java 7과 신규 WildFly 환경을 분리하는 방법

기존 Tomcat 등의 서비스가 Java 7을 반드시 사용해야 한다면 시스템 전체의 Java를 변경할 필요는 없습니다.

예를 들어 다음과 같이 별도의 JDK를 병렬로 구성할 수 있습니다.

/opt/jdk1.7.0_80
    │
    └── 기존 Tomcat
        → Java 7 유지

/opt/jdk-21
    │
    └── 신규 WildFly
        → Java 21 사용

이때 /etc/profile, 시스템 전역 JAVA_HOME, alternatives 등을 변경하지 않고 WildFly 프로세스에만 별도의 JAVA_HOME을 지정하면 기존 Java 7 기반 서비스와 분리할 수 있습니다.

WildFly 41과 Java 21을 사용할 경우

현재 WildFly 41 계열은 Java SE 17과 Java SE 21에서 호환성 검증이 이루어져 있으며, 공식 WildFly 41 릴리스 설명에서도 Java 17·21 환경에서 Jakarta EE 호환성이 명시되어 있습니다.

또한 2026년 9월 기준 WildFly 프로젝트의 현재 유지보수 계열은 WildFly 41이며, 이전 WildFly 릴리스들은 프로젝트 차원에서 더 이상 유지보수되지 않는다고 안내하고 있습니다.

따라서 신규 환경을 구성한다면 오래된 WildFly 9와 Java 7 조합을 계속 확장하는 것과 별개로 현재 애플리케이션의 Java/Jakarta EE 호환성을 검증하면서 신규 WildFly 환경으로 이전하는 방안도 함께 검토할 수 있습니다.

다만 WildFly 9에서 WildFly 41로 이동하는 것은 단순한 JVM 교체가 아닙니다. Java EE 시대의 오래된 애플리케이션을 최신 Jakarta EE 서버로 옮기는 과정에서는 API, 라이브러리, 설정, 보안 서브시스템, 데이터소스, 배포 구조 등의 호환성을 별도로 검증해야 합니다.

정리

이번 로그에서 가장 먼저 확인되는 문제는 WildFly 9 자체의 기동 실패가 아닙니다. Java 7에서 실행 중인 WildFly 9가 WAR 내부의 Java 8 bytecode를 읽지 못하면서 애플리케이션 배포가 실패한 상황입니다.

WildFly 9.0.2.Final
        │
        ├── Java 7로 서버 기동 → 성공
        │
        ├── DataServer.war
        │      └── Quartz 클래스 → Java 8 bytecode → 실패
        │
        └── ReportingServer.war
               └── HSQLDB 클래스 → Java 8 bytecode → 실패

따라서 Unsupported major.minor version 52.0만 해결하려면 Java 8 이상이 필요합니다. 하지만 실제 운영 방향을 결정하기 전에는 WAR 내부 클래스와 라이브러리가 요구하는 Java 버전을 먼저 조사하는 것이 안전합니다.

특히 기존 서비스가 Java 7을 사용하고 있다면 시스템 Java를 직접 교체하기보다 기존 Java 7은 유지하고 신규 JDK와 WildFly를 별도 경로로 구성하여 프로세스 단위로 분리하는 방식이 기존 서비스에 미치는 영향을 최소화할 수 있습니다.