마이그레이션 - 完

이 프로젝트는 Spring/eGov/iBatis 기반 레거시 시스템을 Spring Boot 3.5 + Java 17 + Spring Security 6 + MyBatis/JPA 구조로 전환한 마이그레이션 프로젝트다.

중요하게 생각한 건 단순히 코드를 옮기는게 아니라, 레거시 시스템을 항상 같은 기준으로 분석하고, Codex를 활용해 반복 작업을 줄이고 확보한 시간을 비즈니스 로직 검증에 사용하는 게 핵심이었다.

결과

왜 마이그레이션이 필요했는가

기존 시스템은 전자정부 프레임워크 기반으로 시작했지만, 현재 개발/운영 흐름에서는 전자정부 프레임워크를 사용하지 않는 상태였다. 그럼에도 eGov 관련 설정, 보안 XML, 공통 유틸, 참조 코드가 죽은 코드처럼 남아 있어 구조를 이해하기 어렵고, 변경 시 실제 영향 범위와 잔존 의존성을 구분하기 어려웠다.

또한 Controller에 요청 처리, 검증, 분기 로직이 집중되어 있었고, Service 계층은 주로 iBatis SQL 호출을 위임하는 구조였다. SQL Map은 조회, 저장, 통계, 레거시 연동 쿼리가 섞여 있어 기능 별 변경 영향 범위를 파악하기 어려웠다.

기술부채도 많이 누적되어 기능 하나를 수정할 때마다 화면, Controller, Service, SQL Map, 보안 설정을 함께 확인해야 했다. 기능을 구현하는 시간보다 기존 구조를 깨뜨리지 않기 위한 확인 비용이 커지는 상태였고, 이런 부분들이 마이그레이션을 결정하게 된 배경이다.

분석 기준 정형화

레거시 코드를 분석할 때 Codex에게 단순히 "이 코드 설명해줘"라고 요청하지 않았다.

분석 기준은 다음과 같다.

• 이 코드는 어떤 역할을 담당하는가

• 어떤 비즈니스 흐름의 일부인가

• 변경 시 영향을 받는 범위는 어디까지인가

• 외부 시스템과의 접점은 무엇인가

• 기존 URL, 화면, DB 계약 중 보존해야 할 것은 무엇인가

이 기준을 반복적으로 적용하면서 분석 결과는 기능 단위로 정리되기 시작했다.

그 결과, “누가 분석했느냐”보다 “어떤 기준으로 분석했느냐”가 더 중요해졌고, 코드 이해의 속도와 일관성을 높일 수 있었다.

시작점·종료점·Flow 중심의 구조 이해

레거시 시스템을 클래스 단위로만 읽으면 전체 흐름을 파악하기 어려웠다.

그래서 시스템을 이해할 때 다음 세 가지를 기준으로 정리했다.

Codex에게 클래스 목록이나 메서드 설명을 요청하는 대신, 위 세 가지 관점을 중심으로 시스템의 흐름을 시퀀스 형태로 정리하도록 했다.

이 방식 덕분에 코드를 단순히 읽는 것이 아니라, 어떤 흐름은 유지해야 하고 어떤 부분은 새 구조로 옮겨도 되는지 판단할 수 있었다.

분석·판단 분리

AI를 활용하면서 가장 중요하게 둔 원칙은 역할 분리였다.

Codex는 레거시 코드 흐름을 요약하고 반복적인 이관을 하는 데 활용했다.

하지만 다음 판단은 직접 수행했다.

• 계층 책임을 어떻게 나눌 것인가

• 트랜잭션 경계는 어디에 둘 것인가

• JPA와 MyBatis를 어떤 기준으로 나눌 것인가

• 기존 URL과 화면 계약 중 무엇을 유지할 것인가

• 보안/권한 흐름이 깨지지 않았는가

• 어떤 테스트로 변경 위험을 고정할 것인가

이 방식은 단순히 개발 속도를 높이는 것을 넘어, 변경 리스크가 있는 영역을 먼저 식별하고 통제하는 데 도움이 되었다.

병렬 세션을 활용한 작업 단축

기존 방식에서는 하나의 기능을 완료한 뒤 다음 기능으로 넘어가는 순차 작업이 일반적이었다.

하지만 마이그레이션 작업에는 서로 의존성이 낮은 기능 단위 이관 작업이 많았다.
그래서 먼저 기능을 분석해 병렬 처리가 가능한 단위로 분리했다.

그다음 각 기능마다 독립적인 Codex 세션을 생성하고, 다음 정보를 주입했다.

• 해당 기능의 요구사항

• 관련 코드 컨텍스트

• 유지해야 할 기존 계약

• 계층 분리 기준

• 테스트 기준

• 변경 시 주의할 제약 조건

AI가 각 기능의 분석과 초안 작성을 동시에 진행하는 동안, 난 결과물을 리뷰하고, 비즈니스 규칙과 변경 리스크를 판단하는 역할에 집중했다.

확보한 시간을 어디에 사용했는가

병렬 작업의 핵심 가치는 단순한 속도 향상이 아니었다.

시간을 줄인 만큼, 확보한 시간을 다음과 같이 사용했다.

• 비즈니스 로직의 빈틈 확인

• 레거시 결과와 신규 결과 비교

• 권한별 접근 흐름 검증

• 트랜잭션 경계 확인

• 정적 리소스와 파일 경로 검증

• 배포 전 스모크 체크 항목 정리

• 롤백 가능성 확인

AI는 시간을 줄이는 도구이기도 하지만, 더 중요한 일에 집중할 시간을 만들어주는 도구였다.

정리

이 프로젝트를 통해 가장 크게 배운 것은 AI를 어떻게 쓰느냐보다, AI에게 맡길 일과 사람이 판단해야 할 일을 어떻게 나누느냐가 더 중요하다는 점이다.

AI는 레거시 분석과 이관 속도를 높이는 데 큰 도움이 되었다.
하지만 변경 영향 범위 판단, 트랜잭션 경계, 데이터 접근 전략, 보안 흐름, 운영 반영 여부는 사람이 직접 판단해야 했다.

결국 AI의 진짜 가치는 코드를 대신 작성하는 데 있는 것이 아니라, 반복 작업을 줄이고 더 중요한 판단에 집중할 시간을 만들어주는 데 있었다.

이 프로젝트에서는 그 시간을 비즈니스 로직 검증, 배포 전 점검에 사용했고, 결과적으로 더 안정적인 마이그레이션 구조를 만들 수 있었다.