최근에 예전에 만들었던 Spring 프로젝트를 다시 열어보게 됐다.

4년 전에 만들었던 프로젝트라 그런지 구조도 꽤 낡아 있었고,
요즘 기준으로 보면 유지보수가 쉽지 않은 구조였다.

그래서 자연스럽게 이런 생각이 들었다.

"이 프로젝트를 Spring Boot로 옮겨볼까?"

Spring Boot는 요즘 대부분의 프로젝트에서 사용되고 있고
설정도 훨씬 간단해졌기 때문에 리팩토링 겸 마이그레이션을 해보려고 했다.

하지만 막상 시작해보니 생각보다 고민거리가 많았다.

---

1. XML 설정을 어떻게 처리해야 할까?

예전 프로젝트를 열어보자마자 가장 먼저 보였던 건 엄청난 양의 XML 설정 파일이었다.

applicationContext.xml
dispatcher-servlet.xml
mybatis-config.xml
security-context.xml

Spring Boot는 기본적으로 Java Config 기반으로 동작하는데
이걸 전부 옮겨야 할까?

처음에는 단순하게 생각했다.

"XML을 그냥 import 하면 되는 거 아닌가?"

하지만 문제가 있었다.

Spring Boot는 Auto Configuration 기반으로 돌아가는데
기존 XML 설정이 충돌할 가능성이 있었다.

그래서 고민이 생겼다.

• 기존 XML을 유지할까?
• 아니면 Java Config로 전부 바꿀까?

지금 고민 중인 방향은 이렇다.

핵심 설정만 Java Config로 옮기고
나머지는 점진적으로 제거하는 방식

한 번에 다 바꾸면 리스크가 너무 커질 것 같다.

---

2. WAR 프로젝트를 JAR로 바꿔야 할까?

예전 프로젝트는 Tomcat에 배포하는 WAR 구조였다.

mvn package
→ war 파일 생성
→ tomcat/webapps 배포

하지만 Spring Boot는 보통 이렇게 사용한다.

java -jar application.jar

여기서 고민이 생겼다.

WAR 구조를 유지해야 할까
아니면 Boot 스타일 JAR로 바꿔야 할까?

JAR로 바꾸면 장점이 많다.

• 내장 Tomcat
• 배포 간단
• Docker 사용 쉬움

하지만 기존 프로젝트 구조가 WAR 기준으로 만들어져 있어서
생각보다 수정해야 할 부분이 많았다.

특히 다음 부분이 걸렸다.

web.xml
Servlet 설정
Filter 설정
Listener 설정

이걸 전부 Spring Boot 방식으로 바꿔야 한다.

그래서 지금은 이 부분을 어떻게 정리할지 고민 중이다.

---

3. 로그 시스템을 그대로 써도 될까?

기존 프로젝트는 로그를 이렇게 사용하고 있었다.

log4j

하지만 요즘 Spring Boot에서는 대부분

logback

을 사용한다.

그래서 또 고민이 생겼다.

기존 log4j를 유지할까?
아니면 Boot 기본 로그 시스템을 사용할까?

문제는 log4j 설정 파일이 꽤 많이 커스터마이징 되어 있다는 점이다.

log4j.xml

이걸 그대로 유지하면 빠르게 마이그레이션할 수 있지만
장기적으로 보면 Boot 기본 구조를 따르는 게 맞을 것 같기도 하다.

---

4. MyBatis 설정은 그대로 써도 될까?

이 프로젝트는 ORM 대신 MyBatis를 사용하고 있었다.

구조는 이런 식이었다.

mapper.xml
SqlSessionFactory
SqlSessionTemplate

Spring Boot에서는 mybatis-spring-boot-starter를 쓰면
설정이 훨씬 단순해진다.

하지만 또 고민이 생긴다.

기존 설정을 보면 이런 코드가 많다.

SqlSessionFactoryBean
MapperScannerConfigurer

Boot에서는 이런 설정이 대부분 필요 없어진다.

그래서 고민 중이다.

기존 설정을 유지하면서 옮길까
아니면 Boot 방식으로 새로 구성할까

---

5. 패키지 구조를 바꿔야 할까?

예전 프로젝트의 패키지 구조는 이랬다.

controller
service
dao
vo
util
common

전형적인 레이어드 구조다.

하지만 요즘은 이런 구조도 많이 보인다.

user
order
payment

즉 도메인 중심 구조

그래서 또 고민이 생겼다.

마이그레이션하면서 구조까지 바꿀까?

하지만 지금 생각은 이렇다.

구조까지 바꾸면 리팩토링 범위가 너무 커진다.

그래서 일단은

• Boot 마이그레이션 먼저
• 구조 리팩토링은 나중

이 방향으로 가는 게 맞을 것 같다.

---

6. 의존성 충돌 문제

마이그레이션을 하다 보니 가장 예상되는 문제는 이것이다.

dependency 충돌

예전 프로젝트는 이런 라이브러리를 사용하고 있었다.

spring 4.x
jackson 2.x
commons-fileupload

Spring Boot로 넘어오면
대부분 Boot가 버전을 관리한다.

그래서 이런 문제가 생길 수 있다.

ClassNotFoundException
NoSuchMethodError

이 문제는 실제로 꽤 많이 발생한다고 한다.

그래서 dependency를 하나씩 확인하면서
Boot 기준으로 정리할 필요가 있을 것 같다.

---

아직 해결하지 못한 고민

지금 이 마이그레이션을 하면서
여전히 고민 중인 것들이 있다.

• XML 설정을 어디까지 제거할까?
• WAR 구조를 유지할까?
• 로그 시스템을 바꿀까?
• MyBatis 설정을 다시 짤까?

생각보다 단순한 작업이 아니었다.

하지만 이런 고민을 하다 보니
예전에 아무 생각 없이 쓰던 Spring 구조를
다시 이해하게 되는 계기가 된 것 같다.

---

앞으로 해보고 싶은 것

Spring Boot로 옮기면서
다음 것들도 같이 해보고 싶다.

• Docker 배포
• CI/CD 구축
• 서버 구조 개선

단순히 "Spring Boot로 옮겼다"가 아니라
프로젝트 구조 자체를 한번 정리하는 과정이 될 것 같다.

아직 마이그레이션은 진행 중이다.

이 과정에서 생기는 문제들을
하나씩 기록해보려고 한다.