대부분의 마이그레이션 프로젝트는 하나의 결정에서 시작됩니다. Oracle Java SE에서 OpenJDK로 전환하거나, 지원이 종료된(EOL) Linux 배포판을 교체하거나, 서버를 프라이빗 클라우드로 통합하는 것입니다. 계획은 대개 문서상으로는 단순해 보입니다. 그런데 막상 시작하면 프로젝트 팀은 아무도 몰랐던 Java 런타임, 담당자가 없는 서버, 오래된 버전에 조용히 의존하고 있는 애플리케이션을 발견하게 됩니다. 일정은 밀리고 예산은 늘어납니다.

이를 피하려면 현황 조사(디스커버리)부터 시작해야 합니다. 즉, 실제로 무엇이 설치되어 있는지 사실에 기반해 빠짐없이 정리한 인벤토리를 만드는 것입니다. 이 글에서는 무엇을 수집해야 하는지, Windows와 Linux에서 어떻게 수집하는지, 어떤 예상 밖의 상황에 대비해야 하는지, 그리고 결과를 어떻게 마이그레이션 계획으로 연결하는지 설명합니다.

마이그레이션보다 현황 조사가 먼저인 이유

마이그레이션의 품질은 그 바탕이 되는 정보의 품질을 넘어설 수 없습니다. 인벤토리가 없으면 기억, 오래된 스프레드시트, 라이선스 기록을 바탕으로 범위를 추정하게 되는데, 이 중 어느 것도 현재 실제로 실행 중인 것을 반영하지 못합니다.

잘 만든 인벤토리는 다음 세 가지를 제공합니다.

• 범위: 영향을 받는 머신, 런타임, 애플리케이션의 수. 이를 통해 작업량과 비용을 현실적으로 추정할 수 있습니다.
• 위험: 어떤 시스템이 지원되지 않거나 패치되지 않은 버전으로 실행 중인지, 어떤 시스템이 업무상 중요한지.
• 소유권: 각 시스템의 책임자. 테스트와 승인의 주체가 명확해집니다.

라이선스 협의에서도 도움이 됩니다. 벤더가 설치 수를 물어 오더라도 최신 인벤토리가 있으면 추측이 아닌 사실로 답할 수 있습니다.

수집할 정보: 버전, 벤더, 경로, 담당자

모든 Java 설치에 대해 최소한 다음 정보를 수집하세요.

• 호스트: 머신 이름, IP 주소, 그리고 서버·가상 머신·데스크톱 PC 중 무엇인지.
• 버전: “Java 8″이나 “Java 17″만이 아니라 1.8.0_202 또는 17.0.10 같은 전체 버전 문자열.
• 벤더: Oracle 또는 특정 OpenJDK 배포판 등 해당 런타임을 빌드한 곳. 버전만으로는 이를 알 수 없습니다.
• 유형과 경로: 전체 JDK인지 JRE만 있는지, 그리고 설치된 디렉터리.
• 용도: 파악할 수 있다면, 이를 사용하는 애플리케이션이나 서비스.
• 담당자: 해당 머신이나 애플리케이션을 책임지는 팀 또는 담당자.

Linux 서버의 경우 배포판과 버전, 커널 버전, 주요 설치 패키지, 실행 중인 서비스도 수집하세요. 이를 통해 Java 마이그레이션뿐 아니라 Linux 마이그레이션 대상이기도 한 서버가 어느 것인지 알 수 있습니다.

Windows, Linux, 데스크톱 PC: 환경별 접근 방식

환경마다 조금씩 다른 방법이 필요합니다. 아래 명령은 출발점일 뿐이며, 실무에서는 이를 스크립트로 묶어 기존 관리 도구로 모든 머신에서 실행합니다.

Windows 서버

설치된 Java 런타임은 Windows 레지스트리 키 HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft에 등록되는 경우가 많지만, 모두 그런 것은 아닙니다. 파일 시스템을 검색하는 편이 더 확실합니다.

Get-ChildItem -Path C:\ -Filter java.exe -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, @{n='Version'; e={$_.VersionInfo.ProductVersion}}

애플리케이션 서버는 별도의 데이터 드라이브에 설치되는 경우가 많으므로 C:뿐 아니라 모든 드라이브를 확인하세요.

Linux 서버

Linux에서는 패키지 관리자와 파일 검색을 함께 사용하세요. 많은 Java 런타임이 패키지로 설치되지 않고 아카이브에서 압축을 풀어 배치되기 때문입니다.

cat /etc/os-release
rpm -qa | grep -i -E 'jdk|jre|java'
find / -xdev -type f -name java -perm -u+x 2>/dev/null

Debian이나 Ubuntu에서는 rpm 대신 dpkg -l | grep -i -E 'jdk|jre'를 사용하세요. 찾은 각 java 바이너리를 -version 옵션으로 실행하면 버전과 대개 벤더도 표시됩니다. 또한 대부분의 JDK 디렉터리에는 구현 주체(implementor)를 명시한 release 파일이 있습니다.

데스크톱 PC

데스크톱은 인벤토리에서 가장 자주 누락되는 부분입니다. 개발자는 직접 JDK를 설치하고, 업무용 애플리케이션이 Java 런타임을 사용자 모르게 설치하기도 합니다. 데스크톱은 대수가 많으므로 가능하면 엔드포인트 관리 도구의 소프트웨어 인벤토리를 활용하고, 해당 정보가 없는 경우에만 가벼운 스크립트를 실행하세요.

흔히 겪는 예상 밖의 상황(번들 JRE, 잊힌 서버)

거의 모든 현황 조사 프로젝트에서 아무도 예상하지 못한 것이 발견됩니다. 가장 흔한 사례는 다음과 같습니다.

• 번들 런타임: 많은 상용 애플리케이션은 설치 디렉터리 안에 전용 Java 런타임을 함께 제공합니다. 이는 레지스트리나 어떤 패키지 목록에도 나타나지 않을 수 있습니다.
• 한 머신에 여러 버전: 새 런타임을 설치할 때 이전 런타임이 제거되는 경우는 드물어, 서버 한 대에 서너 개가 있을 수도 있습니다.
• 잊힌 서버: 폐기되지 않고 남아 있는 테스트 머신, 오래된 배치 서버, 가상 머신. 오래되고 패치되지 않은 버전으로 실행 중인 경우가 많습니다.
• 담당자 불명: 아무도 자기 것이라고 하지 않는 머신. 결론이 종료라 하더라도 마이그레이션 시작 전에 처리 방침을 정해야 합니다.

인벤토리에서 마이그레이션 계획으로

데이터를 수집했다면 한곳에 통합하고 시스템 담당자와 함께 검토하세요. 그런 다음 설치 항목을 다음 범주로 분류합니다.

그룹	포함 대상	조치
제거	더 이상 사용하지 않는 런타임	위험과 라이선스 노출을 줄이기 위해 지금 바로 제거
교체	직접 관리하는 런타임	테스트 후 지원되는 OpenJDK 빌드로 전환
조율	서드파티 애플리케이션에 번들된 런타임	먼저 애플리케이션 벤더의 지원 입장을 확인
조사	담당자나 목적이 불분명한 모든 것	담당자를 찾거나 종료 여부를 결정

이 그룹을 바탕으로 현실적인 일정을 세울 수 있습니다. 위험이 낮은 시스템부터 시작해 절차를 검증한 다음, 테스트를 거친 롤백 경로를 갖춘 상태에서 업무상 중요한 시스템으로 넘어가세요.

LOGIQ의 지원

LOGIQ는 Java 및 Linux 환경의 현황 조사와 마이그레이션 프로젝트를 수행합니다. Windows 서버, Linux 서버, 데스크톱 PC를 대상으로 한 실제 고객 프로젝트에서 다듬어 온 스크립트와 절차를 활용합니다. 인벤토리 구축이나 이를 마이그레이션 계획으로 연결하는 데 도움이 필요하시면 LOGIQ에 문의하세요.