레거시 자바 JDK 1.6에서 1.8로 이관할 때 라이브러리를 정말 다 갈아야 할까 (한 번에 변수 하나만 검증)

오래된 자바 웹 애플리케이션을 JDK 1.6에서 1.8로 올릴 때, 이관 가이드가 시키는 라이브러리 교체가 정말 필요한지 최소 변경으로 검증하는 방법입니다.

1. 체크리스트는 참고지 지시가 아니다
JDK 이관 가이드나 체크리스트를 보면 "이 라이브러리들을 전부 최신으로 교체하라"고 적혀 있는 경우가 많습니다. 그런데 그대로 다 갈아 버리면, 나중에 문제가 생겼을 때 JDK 때문인지 라이브러리 교체 때문인지 구분할 수가 없습니다. 그래서 처음에는 원본 소스와 기존 라이브러리를 그대로 두고, 컴파일 타깃(JDK)만 1.8로 올려서 스모크 테스트부터 돌리는 게 맞습니다. 변수를 한 번에 하나만 바꿔야 무엇이 진짜 원인인지 드러납니다.

- 체크리스트는 참고, 무조건 실행 지시가 아님
- 원본·기존 라이브러리 그대로 + 컴파일 타깃만 1.8
- 변수를 한 번에 하나만 바꿔야 원인이 보임

2. JDK만 올렸을 때 실제로 터지는 것
막상 JDK만 올려서 돌려 보면 대부분 그냥 동작합니다. 실제로 걸리는 건 JDK나 런타임 변화에 직접 닿는 소수뿐입니다. 대표적으로 상위 JDK에서 아예 제거된 내부 API(예전 이미지 코덱 같은 com.sun 내부 클래스)를 쓰던 코드는 컴파일 자체가 안 됩니다. 또 서블릿 컨테이너가 3.x로 올라가면, 코드로 서블릿을 등록하는 초기화 클래스와 기존 web.xml 설정이 겹쳐 중복 등록으로 실행 중 예외가 나기도 합니다. 이런 것들은 라이브러리 버전 문제가 아니라 JDK/컨테이너 자체가 바뀌어서 생기는 것이라, 스모크에서 바로 잡힙니다.

- 대부분은 JDK만 올려도 그대로 동작
- 진짜 걸리는 건 제거된 내부 API, 서블릿 중복 등록 같은 런타임 변화
- 라이브러리 버전이 아니라 JDK/컨테이너 변화가 원인인 경우가 많음

3. "필수"라던 라이브러리 교체는 대부분 불필요
가이드가 "호환 안 되니 필수 교체"라고 표시한 라이브러리도, 실제로는 안 갈아도 되는 경우가 많습니다. 클래스 파일의 바이트코드 버전은 Java 5가 49, Java 8이 52인데, JDK 8의 JVM은 낮은 버전으로 컴파일된 옛날 클래스도 그대로 실행합니다(하위 호환). 그러니 "바이트코드가 낮아서 라이브러리를 갈아야 한다"는 건 대개 추측입니다. 기존 라이브러리가 1.8에서 그대로 돌아가는지 스모크로 확인하고, 정말 실패할 때만 교체하면 됩니다.

- 바이트코드 버전: Java 5 = 49, Java 8 = 52
- JDK 8 JVM은 옛 버전 클래스도 그대로 실행(하위 호환)
- "호환 안 될 것 같다"는 추측 말고 스모크로 확인

4. 정말 필요한 것만, 근거를 남기고 바꾼다
이렇게 하면 실제로 손대야 하는 건 스모크에서 실패한 소수로 줄어듭니다. 각 변경마다 "이걸 안 하면 이런 장애가 난다"는 재현 근거를 같이 남겨 두면, 나중에 왜 바꿨는지 설명할 수 있고 불필요한 교체도 막습니다. 리스크를 최소화하는 이관은 많이 바꾸는 게 아니라, 꼭 필요한 것만 근거를 갖고 바꾸는 것입니다.

- 실제 손댈 대상 = 스모크에서 실패한 소수로 축소
- 각 변경에 재현 근거(안 하면 나는 장애)를 남김
- 최소 변경 = 리스크 최소 이관

5. 정리
JDK 이관에서 라이브러리를 다 갈지 말지는 추측이 아니라 검증으로 정합니다. 체크리스트는 참고로만 받고, 원본 그대로 JDK만 올려 스모크부터 돌린 뒤, 실제로 터지는 것만 근거를 남기고 고치면 됩니다. 이렇게 하면 "필수"라던 교체의 상당수가 실은 불필요했다는 걸 확인하게 되고, 이관 리스크도 크게 줄어듭니다.

- 라이브러리 교체 여부는 추측이 아니라 스모크로 결정
- 원본 + JDK만 -> 실패한 것만 최소 교체
- 한 번에 변수 하나, 각 변경엔 재현 근거

여기까지 레거시 자바를 JDK 1.6에서 1.8로 이관할 때 라이브러리 교체를 최소 변경으로 검증하는 방법에 대해서 작성해봤습니다. 여기까지 읽어주셔서 감사합니다!