세상엔 희한한 레거시가 많다.

Java 8을 사용하지만, Java 8을 온전히 활용하기 어려웠던 프로젝트

담당하던 프로젝트는 Seasar2 기반의 레거시 시스템이었다.

Seasar2는 일본에서 개발된 DI/AOP 프레임워크로, 2016년에 공식 지원이 종료되었다.

실행 환경은 Java 8이었지만, 실제 개발 환경은 달랐다.

오래된 프레임워크와 의존성 때문에 Java 8의 기능을 자유롭게 활용하기 어려웠고, 최신 라이브러리를 도입하는 데에도 제약이 많았다.

 

Java 버전은 8이지만, 개발 방식은 Java 6 시절의 제약에 머물러 있는 것 같았다.

 

이러한 문제는 신규 Excel 기능을 개발하면서 본격적으로 드러났다.

Apache POI 라이브러리를 업그레이드하자 애플리케이션이 정상적으로 실행되지 않았다.

처음에는 POI 자체의 문제라고 생각했지만, 의존성을 분석하면서 Seasar2의 AOP 구현에 사용되는 Javassist를 알게 되었다.

Javassist는 바이트코드를 조작하는 라이브러리다. 오래된 버전에서는 Java 7부터 도입된 invokedynamic과 같은 바이트코드 명령어를 처리하지 못하는 호환성 문제가 발생할 수 있었다.

이러한 호환성 문제를 의심해 Javassist 버전 변경도 시도했지만, 문제가 해결되지 않았다.

결국 특정 라이브러리 하나의 문제가 아니라, 레거시 프레임워크와 의존성 전반의 호환성을 고려해야 하는 상황이었다.

앞으로 신규 기능을 추가할 때마다 유사한 문제가 반복될 수 있다고 판단했다.

 

그래서 부분적인 라이브러리 업그레이드보다 시스템 마이그레이션이 필요하다고 생각했다.

먼저 기존 시스템의 제약과 마이그레이션 필요성을 팀장님께 공유했다.

그리고 상품 등록 기능 하나를 새로운 환경에서 구현하여 검토받은 뒤, 본격적인 전환을 진행했다.

다행히 프로젝트를 담당한 초기 3개월 동안 기존 시스템의 설계, 비즈니스 로직, 데이터 흐름과 테이블 구조를 분석해 둔 경험이 큰 도움이 되었다.

클로드 코드를 활용한 코드 분석과 개발 보조도 전환 과정에 활용했다.

약 2~3개월에 걸쳐 Java 21, Spring Boot, PostgreSQL 기반으로 시스템을 마이그레이션했다.

이번 경험을 통해 두 가지를 배웠다.

 

첫째, Java 버전만 업그레이드한다고 시스템 전체가 현대화되는 것은 아니다.

 

프레임워크와 라이브러리의 호환성, 유지보수 가능성까지 함께 고려해야 한다.

 

둘째, 기술 스택 선정은 장기적인 설계 의사결정이다.

시스템이 커질수록 기술을 교체하는 비용도 커진다. 당장의 개발 편의성뿐 아니라 지원 기간, 생태계, 호환성, 장기적인 유지보수 비용까지 고려해야 한다는 것을 느꼈다.

단순한 프레임워크 교체가 아니라, 기술적 부채가 실제 개발에 어떤 제약을 만드는지 경험할 수 있었던 프로젝트였다.