JPA와 MyBatis를 같이 쓰기로 한 이유
레거시 iBatis 기반 프로젝트를 Spring Boot 3로 옮기며 등록·수정·삭제처럼 도메인 규칙과 변경 의도가 코드에 드러나는 부분은 JPA로 옮기고, 대시보드·검색·통계처럼 결과 모양을 SQL이 직접 만들어내는 조회는 MyBatis로 유지하기로 했습니다. 핵심은 기술을 섞는 것이 목적이 아니라 전환 리스크와 기능 성격에 따라 바꿀 것과 유지할 것을 명확히 나누는 현실적인 결정이었습니다.
만들고, 고치고, 배우는 것들을 짧은 글로 남길려고 합니다.
04
레거시 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를 활용해 단계적으로 마이그레이션해보려 한다.