Java 현대화: 엔터프라이즈 업그레이드를 실현 가능하게

대기업——은행, 항공사, 통신사——에 들어가면 Java가 대부분의 무거운 작업을 처리하고 있습니다. 핵심 뱅킹 시스템, 사기 탐지 파이프라인, 주문 관리, 일출 전 수백만 건의 트랜잭션을 처리하는 야간 배치 작업. 잘 동작하고 확장도 됩니다——바로 그 이유로 많은 시스템이 여전히 Java 8 이하에서 실행되고 있습니다.

동작한다는 것과 건강하다는 것은 다릅니다. 프레임워크는 더 이상 보안 패치를 받지 못하는 버전에 머물러 있습니다. 원래 개발자들은 오래전에 떠났습니다. "건드리지 마, 잘 돌아가잖아"가 아키텍처 원칙으로 굳어버렸습니다. 격차는 계속 벌어지고 있습니다. records, sealed classes, pattern matching, virtual threads, G1/ZGC 컬렉터, 향상된 컨테이너 지원, 더 빠른 시작——이 모든 것이 아무도 일정을 잡고 싶어하지 않는 업그레이드의 저편에 기다리고 있습니다.

이 글은 그 격차를 좁히는 방법에 관한 이야기입니다. 애플리케이션이 왜 막히는지 설명하고, Premium Package for Java의 다섯 가지 기능——JDK 버전 업그레이드, Liberty 리플랫포밍, UI 현대화, 단위 테스트 생성, 보안 수정——각각이 어떻게 결정론적 자동화와 AI 사이에서 작업을 분담하는지 설명합니다. 마지막에는 최대 효과를 내기 위해 리포지토리에 필요한 것, 접근 방법, 시작 방법을 안내합니다.

왜 많은 Java 앱이 10년 뒤처져 있는가

현대화가 이렇게 분명히 가치 있다면, 왜 많은 엔터프라이즈 Java 애플리케이션이 아직도 2014년에 멈춰 있어 보이는 걸까요? 원인은 구조적입니다——조직의 관성과 실제 엔지니어링 위험.

• 유기적 성장, 계획된 성장이 아님. 이 시스템들은 기능 하나하나, 인수 하나하나씩 성장했습니다. 코드 레이어가 오래된 레이어 위에 쌓이고, 각각 다른 마감일과 관례 아래 작성되었습니다. 오늘 물려받는 것은 지질학적 퇴적물과 비슷합니다——10년에 걸쳐 수십 팀이 내린 결정들.
• 핵심 모듈을 작성한 엔지니어들은 떠나갔고 암묵적 지식도 함께 사라졌습니다. 남은 것은 빈약한 문서와 "저 모듈이 어떻게 작동하는지 대충 기억한다"는 몇몇 시니어 엔지니어들뿐입니다.
• Java 업그레이드는 의존성 감사, 프레임워크 업그레이드(Spring, Hibernate, Jakarta EE 네임스페이스 마이그레이션), 더 이상 사용되지 않는 API 제거, 모든 환경에서의 재검증을 의미합니다——수개월의 노력, 실제 예산, 실제 기회 비용. 시스템이 이미 잘 돌아가고 있다면 정당화하기 어렵습니다.
• Java 8 → 17 또는 21로의 점프만으로도 모듈 시스템 충돌, 제거된 내부 API(sun.misc.Unsafe), 하드 오류로 변하는 reflection 경고, 가비지 컬렉터 동작의 미묘한 변화가 나타날 수 있습니다. 종이 위의 버전 범프가 실제로는 수 주간의 조사가 됩니다.
• 회귀 주기가 깁니다. 방대한 테스트 스위트——단위, 통합, 성능, UAT, 때로는 수동 승인——는 단일 업그레이드가 출시 전에 수 주간의 테스트를 촉발할 수 있음을 의미합니다.
• 이 모든 것의 밑바닥에는 동작하는 것을 망가뜨리는 것에 대한 두려움이 있습니다. 애플리케이션이 하루에 수백만 달러를 처리한다면 잘못된 배포 비용이 업그레이드하지 않는 비용을 훨씬 초과하므로 업그레이드 논의는 다음 분기로 미뤄집니다. 그리고 또 그 다음 분기로.

출구는 점진적이며 재작성이 아닙니다. 적절한 도구가 있다면 각 단계가 안전하게 출시할 수 있을 만큼 작은 단계로 기술 부채를 갚아나갈 수 있습니다.

Premium Package for Java

Premium Package for Java는 엔터프라이즈 Java 현대화를 위한 다섯 가지 워크플로우 스위트입니다. 각각은 동일한 분업 원칙으로 구축되어 있습니다——결정론적 자동화가 예측 가능한 기계적 작업을 수행하고, AI가 레시피로 인코딩할 수 없는 상황별 결정을 처리합니다.

OpenRewrite와 같은 규칙 기반 엔진은 수천 개의 파일에 걸친 기계적 리팩토링에 신뢰할 수 있습니다. AI는 지저분한 부분——빌드 오류 해석, 비즈니스 로직에 대한 추론, 트레이드오프 간 선택——에 더 능합니다. Bob은 중요한 단계를 사람이 승인하는 단계별 워크플로우로 둘 다를 조율합니다.

그 배후의 전문성이 중요합니다. 워크플로우는 JIT 컴파일러를 구축하고 WebSphere와 Open Liberty를 출시하고 Quarkus 개척에 기여하고 OpenJDK, Jakarta EE, MicroProfile에 공헌한 IBM과 Red Hat 엔지니어들에 의해 형성되었습니다. 도구는 이 팀들이 마이그레이션에 어떻게 접근하는지를 인코딩합니다——모델이 눈앞의 코드에서 재구성할 수 없는 지식입니다.

다섯 가지 기능에 걸친 분업이 어떻게 이루어지는지 살펴보겠습니다.

기능 1: JDK 버전 업그레이드——Java 8에서 11, 17, 21 또는 25로

JDK 업그레이드는 가장 일반적인 현대화 작업이자 가장 과소평가된 것입니다. Bob은 이것을 단일 명령이 아닌 다단계 증거 기반 여정으로 처리합니다.

• 먼저 프로젝트 인텔리전스. Bob은 빌드 도구(Maven 또는 Gradle), 모듈 토폴로지, 현재 Java 버전, 프레임워크 발자국을 분석하고 실행 가능한 업그레이드 경로(8→17, 8→21, Jakarta EE 유무)를 제안하며 각각에 난이도 등급과 예상 기술적 과제를 주석으로 답니다.
• 선택된 대상에 대해 엄선된 OpenRewrite 레시피가 기계적 변환을 안전하게 대규모로 처리합니다.
• 레시피는 실제로 40~50% 정도까지 진행시켜 줍니다. 나머지——이국적인 의존성 충돌, 제거된 내부 API, 라이브러리별 오류——가 에이전틱 루프가 개입하는 곳입니다. Bob은 프로젝트를 컴파일하고 Maven/Gradle 빌드 로그를 파싱하여 근본 원인별로 예외를 그룹화하고 AI에게 모듈별로 정확한 수정을 요청합니다.
• 의도를 존중하는 가드레일. AI는 javax와 jakarta 네임스페이스 사이를 조용히 전환하거나, "컴파일되게 하려고" 코드를 주석 처리하거나 파일을 이동하거나, 패키지나 의존성 변경 전에 명시적 승인을 요청하지 않도록 지시받습니다.

자동화할 수 있는 곳은 빠르게, 할 수 없는 곳은 신중하게——마지막에 완전한 감사 추적이 남는 업그레이드를 얻을 수 있습니다.

기능 2: Liberty 리플랫포밍——전통적인 WebSphere에서 Liberty로

전통적인 WebSphere Application Server에서 WebSphere Liberty 또는 Open Liberty로의 마이그레이션은 더 낮은 메모리 발자국, 컨테이너 친화적인 패키징, 더 빠른 시작, 현대적인 Jakarta EE 지원을 제공합니다. 또한 수동으로 시도하기 가장 복잡한 마이그레이션 중 하나이기도 합니다.

• AMA 기반 평가. Bob은 IBM의 Application Modernization Accelerator 출력을 수집하여 규칙 기반 수정 지침과 함께 파일 수준의 구체적인 마이그레이션 문제로 파싱합니다.
• 각 AMA 규칙에는 규범적인 지침이 포함되어 있습니다——"com.ibm.websphere.*를 Jakarta EE 표준 동등물로 교체", "ibm-web-ext.xml 구성을 server.xml로 마이그레이션". Bob은 이 문제들을 근본 원인별로 그룹화하여 규칙의 도움말 텍스트와 함께 AI에게 전달하므로 모델이 추측하지 않고 알려진 수정 사항을 적용합니다.
• 마이그레이션에 Jakarta 점프가 포함된 경우 동일한 OpenRewrite 레시피 라이브러리가 네임스페이스 메커니즘을 결정론적으로 처리합니다.
• 빌드, 배포, 검증. Bob은 WAR/EAR을 빌드하고 liberty-maven-plugin 또는 liberty-gradle-plugin을 통해 배포하며 시작 및 클래스 로딩 실패를 위해 서버 로그를 추적하고 반복적으로 해결합니다. REST 엔드포인트에 대한 curl을 사용한 기능 검증은 표준 플로우의 일부입니다.

워크플로우는 일반적인 프롬프트에 맡기는 것이 아니라 Liberty 엔지니어들이 마이그레이션에 어떻게 접근하는지를 인코딩합니다.

기능 3: UI 현대화——JSP/Struts에서 현대적인 SPA로

대부분의 레거시 Java 앱은 여전히 JSP, Struts 또는 서블릿을 통해 UI를 구동합니다. Bob은 이것을 5단계 파이프라인으로 분할합니다.

• 아키텍처 추출. 코드가 재작성되기 전에 Bob은 애플리케이션을 분석하고 모든 컨트롤러, 액션, 서블릿, 페이지, 폼, 유효성 검사 규칙, 데이터 흐름 경로를 목록화한 architecture.md를 생성합니다. 이 문서가 나머지 마이그레이션의 진실의 원천이 됩니다.
• 레거시 프레젠테이션 레이어(Struts 액션, 서블릿, JSP 컨트롤러)는 데이터베이스 무결성을 보호하기 위해 원래 DAO와 모델 클래스를 그대로 두고 현대적인 백엔드——Spring Boot, Quarkus 또는 Liberty——의 REST 엔드포인트로 변환됩니다.
• 프론트엔드 스캐폴딩. 새 TypeScript 프로젝트(Angular, React 또는 다른 프레임워크)가 선택된 디자인 시스템——Carbon, Material UI 또는 shadcn/ui——에 연결되며 기능 작업이 시작되기 전에 HTTP 클라이언트, 테마, 라우팅, 상태 관리, 에러 바운더리, CORS가 설정됩니다.
• JSP 폼과 테이블은 원래 비즈니스 규칙을 유지하면서 디자인 시스템 동등물——DataTable, Card, DatePicker, 검증된 폼——에 매핑됩니다.
• 각 단계의 검증 게이트. Bob은 애플리케이션 자체를 시작하지 않습니다. 각 단계 후에 개발자에게 빌드/시작 명령을 실행하고 확인하도록 요청하여 검증을 인간의 손에 맡깁니다.

AI는 JSP 태그 수프에서 현대적인 컴포넌트로의 상황별 번역을 처리하고, 자동화는 스캐폴딩, 의존성, 빌드 검증을 처리합니다.

기능 4: 단위 테스트——전략 먼저, 그 다음 생성

테스트 커버리지는 종종 현대화의 가장 큰 단일 장애물입니다——안전하게 검증할 수 없는 것은 안전하게 업그레이드할 수 없습니다. Bob은 테스트를 생성하기 전에 테스트 전략을 생성합니다.

• 전략 생성. Bob은 프로젝트를 분석하고 아키텍처, 커버리지가 필요한 모듈, 권장 프레임워크(JUnit 5, Mockito, AssertJ), 명명 규칙, 커버리지 임계값, 커버리지 보고서 유무로 테스트를 실행하는 정확한 명령을 다루는 UNITTEST.md를 생성합니다.
• 후보 선택은 여러 세분화 수준에서 작동합니다——전체 패키지, 특정 클래스, 개별 메서드——git diff에서 실행하여 최근 변경된 코드에 작업을 집중할 수도 있습니다.
• 생성, 실행, 수정. 모든 테스트 프롬프트는 동일한 지침으로 끝납니다. 테스트를 실행하고 실패를 수정합니다. AI는 실행하고 실패를 관찰하며 코드 생성에서 멈추는 것이 아니라 스위트가 녹색이 될 때까지 반복합니다.
• Bob은 JaCoCo와 통합되어 루프가 단순한 녹색 테스트 실행이 아닌 측정된 커버리지를 목표로 합니다.

자동화가 테스트를 실행하고, AI가 테스트를 작성하고 실패를 추론합니다. 결과적인 커버리지가 다른 네 가지 워크플로우를 열어줍니다.

기능 5: 보안 수정——동일한 루프의 일부로서의 CVE

CVE가 가득한 의존성을 여전히 포함하는 현대화된 애플리케이션은 절반밖에 완성되지 않은 것입니다. 보안 수정은 취약점을 대상으로 JDK 업그레이드와 동일한 아키텍처를 재사용합니다.

• 빌드 주도 탐지. Bob은 업그레이드 워크플로우의 Maven 및 Gradle 로그 분석기를 재사용하여 빌드 출력, dependency-check 플러그인, SBOM 도구에서 의존성 권고, 더 이상 사용되지 않는 경고, 알려진 취약 전이 의존성을 탐지합니다.
• 수정이 단순한 버전 범프가 아닌 경우——패치된 라이브러리가 서명을 변경하고 호출 사이트를 마이그레이션해야 하는 경우——에이전틱 루프가 근본 원인별로 고장을 그룹화하고 모듈 전체에 수정을 적용하며 검증을 위해 재빌드합니다.
• 동일한 가드레일이 적용됩니다. 명시적 승인 없이 의존성 변경 없음, 주석 처리된 코드 없음, 네임스페이스 서프라이즈 없음. 수정 사항은 적용되기 전에 제시되고 설명되고 확인됩니다.

보안 강화는 별도의 로드맵이 아닌 나머지 현대화 작업과 동일한 트랙에서 실행됩니다.

공통 실

다섯 가지 기능 모두에서 동일한 분업이 적용됩니다:

자동화는 결정론적인 것을 처리하고, AI는 상황적인 것을 처리하며, 사람은 중요한 것을 승인합니다——플랫폼의 기반을 구축한 IBM과 Red Hat 엔지니어들의 지원을 받으면서.

리포지토리 준비하기

이 워크플로우들은 이미 읽기 쉬운 코드베이스에서 더 멀리 나아갑니다——Bob을 돕는 것은 코드를 물려받는 모든 엔지니어를 돕는 것과 같습니다:

• 녹색이고 합리적으로 빠른 빌드. 여기의 모든 루프는 컴파일 및 테스트 출력에 고정되어 있습니다. mvn/gradle 빌드가 빠르고 신뢰할수록 생성-실행-수정 주기가 타이트해집니다.
• 기존 테스트, 부분적이라도. 커버리지는 업그레이드를 위한 안전망이자 Bob이 읽는 신호입니다. 적다면 버전 점프를 시도하기 전에 기능 4부터 시작하세요.
• 고정된 선언적 의존성 트리. pom.xml/build.gradle의 명확한 버전과 최신 의존성 잠금 파일이 깔끔한 레시피 실행과 며칠간의 충돌 추적 사이의 차이를 만듭니다.
• Bob이 구동할 수 있는 빌드 도구. Liberty 및 보안 워크플로우는 표준 플러그인(liberty-maven-plugin, dependency-check, SBOM 도구)에 의존합니다. 이를 구성해두면 자동화 절반이 자신의 역할을 할 수 있습니다.

접근 방법

Premium Package for Java는 Bob 기본 플랜에 대한 추가 기능이며 별도의 다운로드가 아닙니다.

권한 부여 방법은 플랜에 따라 다릅니다:

• 개인 플랜(Pro, Pro+, Ultra). bob.ibm.com의 요금 페이지로 이동하여 플랜을 선택하고 체크아웃 시 Java 추가 기능을 추가합니다. 주문을 완료하고 Bob IDE를 설치하면 로그인 시 자격이 감지됩니다. bob.ibm.com에서 구독을 통해 시트와 추가 기능을 관리합니다.
• 엔터프라이즈 플랜. Bob 관리자가 Bob Admin UI에서 기본 플랜 시트와 Java 추가 기능을 할당합니다. 시트가 할당되면 동일한 자동 감지가 적용됩니다——로그인하면 워크플로우가 나타납니다.

명시적으로 언급할 가치 있는 두 가지:

• 체크아웃 시 Java 추가 기능을 선택해야 합니다. 기본적으로 기본 플랜의 일부가 아닙니다. 구매 시 건너뛰면 유료 플랜에서도 워크플로우가 표시되지 않습니다.
• 트라이얼 플랜은 추가 기능을 사용할 수 없습니다. Premium Package for Java는 유료 Pro, Pro+, Ultra 또는 엔터프라이즈 플랜이 필요합니다.

시작하기

플랜에 추가 기능이 포함되어 Bob IDE에 로그인했다면:

• 먼저 단일 모듈에서 JDK 업그레이드 평가를 실행하여 목표에 커밋하기 전에 제안된 경로와 난이도 등급을 확인합니다.
• 커버리지가 부족하다면 버전 점프 전에 UNITTEST.md 전략을 생성하고 안전망을 구축합니다.
• 모듈별로 변경 사항을 승인합니다——가드레일은 네임스페이스와 의존성 변경을 여러분의 손에 유지하기 위해 있습니다.

팀이 이러한 마이그레이션을 처음부터 끝까지 어떻게 실행했는지 bob.ibm.com의 사례 연구를 참조하세요.