마이그레이션 - 서론

신입으로 회사에 입사한 지도 어느덧 두 달이 다 되어간다.
하루하루는 길게 느껴지는데, 일주일과 한 달은 생각보다 빠르게 지나간다.

나는 메디컬 도메인의 솔루션 회사에 다니고 있다.
기본이 되는 프로젝트가 있고, 고객사마다 필요한 기능을 추가 구현해서 제공하는 방식으로 운영된다.

입사하고 처음 2주는 코드를 이해하기에 급급했다.
프로젝트는 Spring MVC, 전자정부프레임워크, iBatis 기반으로 구성되어 있었다.

MyBatis는 알고 있었지만 iBatis는 처음이었고, 전체 구조를 파악하는 데 꽤 많은 시간이 걸렸다.

코드를 보다 보니 몇 가지 아쉬운 부분들이 보였다.
운영에 필요한 값과 비밀번호 같은 정보가 설정 파일에 하드코딩되어 있었고, 테스트 코드는 아예 없었다. 기능을 하나 수정하더라도 서버를 직접 띄워 확인해야 했다.

또 전자정부프레임워크, XML 설정, SQL Map 같은 것들이 프로젝트 전반에 넓게 퍼져 있었다.
기능 하나를 이해하려고 해도 단순히 로직만 보면 되는 게 아니라, 여러 설정과 흐름을 같이 따라가야 했다.

그러다 보니 자연스럽게 이런 생각이 들었다.

'이거 유지보수하려면 쉽지 않겠는데?'

처음에는 그냥 '이게 레거시구나' 정도로 생각했다.
그런데 이 프로젝트가 앞으로도 계속 재사용되는 구조라, 지금 보이는 문제도 계속 같이 따라간다는 걸 깨달았다.

그래서 단순히 기능만 추가하는 것보다, 프로젝트를 조금 더 오래 가져갈 수 있는 구조로 바꿔보고 싶었다.

물론 모든 코드를 혼자 손으로 옮기겠다는 생각은 아니다. 이번 마이그레이션에서 Codex를 적극적으로 활용하려고 한다.

다만 Codex한테 단순히 '이거 옮겨줘'라고 맡기기보다는, 먼저 내가 기존 구조를 파악하고 어떤 방향으로 바꿀지 정리한 뒤에 작업을 맡기려고 했다.

어떤 부분은 JPA로 옮기는 게 맞는지, 어떤 조회는 MyBatis로 남기는 게 나은지,
전자정부프레임워크 의존은 어디서부터 줄여야 하는지 같은 기준은 직접 고민해야 한다고 생각했다.

Codex는 그 기준에 맞춰 코드를 분석하거나 초안을 만드는 데 도움을 주고,
나는 결과를 다시 확인하면서 실제 프로젝트에 맞는지 검토하는 방식으로 진행하고 있다.

일단 방향은 Spring Boot 3 기반으로 다시 구성하는 쪽으로 잡았다.
전자정부프레임워크 의존은 없애고, 인증과 인가는 Spring Security로 정리하려고 한다.

데이터 접근 방식도 고민이 많았다.
처음에는 하나의 기술로 통일하는 게 깔끔하지 않을까 싶었다.
그런데 실제 코드를 보다 보니, 꼭 그게 답은 아닌 것 같았다.

조회 SQL의 비중이 많고, 검색 조건이 복잡한 목록이나 통계, 집계 쿼리도 꽤 있었다.
ROW_NUMBER나 뷰를 활용하는 쿼리도 있어서, 이런 부분은 MyBatis로 가져가는 게 더 자연스럽다고 느꼈다.

반대로 단순 CRUD나 권한 관리처럼 엔티티 경계가 어느 정도 보이는 부분은 JPA가 더 잘 맞을 것 같았다.

물론 아직 모르는 것도 많다.
신입이라 조심해야 할 부분도 많고, 내가 보고 있는 게 전부가 아닐 수도 있다.
그래도 이런 경험들이 하나씩 쌓이면서 성장하는 거라고 생각한다.

레거시 프로젝트를 직접 마이그레이션 해보는 경험은 쉽게 얻기 어려운 기회라고 생각한다.

오히려 회사 규모가 작기 때문에 이런 기회를 잡을 수 있는 것 같다.

아직 갈 길은 멀다.
그래도 이 작업이 끝났을 때, 지금보다 더 성장해 있기를 바란다.