만들고, 고치고, 배우는 것들을 짧은 글로 남길려고 합니다.
05
레거시 Spring/eGov/iBatis 시스템을 Spring Boot 3.5·Java 17·Spring Security 6·MyBatis/JPA 구조로 옮기면서, 흩어진 eGov 설정과 결합된 로직 때문에 변경 시 영향 범위를 가늠하기 어려웠다는 문제가 중심이었습니다. Codex를 반복 분석과 병렬 세션에 도구로 활용해 단위별 이관을 빠르게 수행하고, 그만큼 확보한 시간을 비즈니스 로직 검증·권한·트랜잭션 경계 확인 등 판단이 필요한 영역에 투입해 더 안정적인 마이그레이션을 이뤘습니다.
레거시 iBatis 기반 프로젝트를 Spring Boot 3로 옮기며 등록·수정·삭제처럼 도메인 규칙과 변경 의도가 코드에 드러나는 부분은 JPA로 옮기고, 대시보드·검색·통계처럼 결과 모양을 SQL이 직접 만들어내는 조회는 MyBatis로 유지하기로 했습니다. 핵심은 기술을 섞는 것이 목적이 아니라 전환 리스크와 기능 성격에 따라 바꿀 것과 유지할 것을 명확히 나누는 현실적인 결정이었습니다.
레거시 eGov·XML 기반 권한을 Spring Security로 옮기면서 로그인은 되는데 이후 권한 동작(메뉴 노출 vs URL 접근 제어, 로그인 정책, 세션 연계 등)이 기존과 달라지는 문제가 생겼습니다. 해결은 단순 데이터 이식이 아니라 Authentication·SecurityContext·세션·URL 필터와 로그인 전 정책 검사(IP, 중복 로그인 등)를 다시 연결해 권한 흐름 전체를 복원하는 쪽으로 접근한 것이 핵심이었습니다.
레거시 화면을 Spring Boot 3로 옮기며 겉은 비슷해 보여도 조회 결과, 권한·세션 처리, 메뉴 노출 등에서 기존과 다른 동작이 나와 단순 코드 복사가 통하지 않는 문제를 겪었습니다. 그래서 어떤 URL·Controller·세션·SQL·DB가 결합해 결과를 만드는지 기준을 정하고 문서화한 뒤 Controller/Service 분리와 JPA/MyBatis 기준을 적용해 결과를 비교·조정하며 옮겼습니다.
레거시 Spring MVC·전자정부프레임워크·iBatis 기반 프로젝트를 들여다보며 유지보수의 난점을 느끼고 장기적으로 재사용 가능한 구조로 재작성 하기로 결심했다. Spring Boot 3·Spring Security 기반으로 의존을 줄이고, 조회와 복잡한 쿼리는 MyBatis로, 단순 CRUD와 권한 관련은 JPA로 나눠 Codex를 활용해 단계적으로 마이그레이션해보려 한다.
