인턴으로서 기존 파이썬(Flask) 레거시 코드를 코틀린(Spring Boot)로 마이그레이션하는 업무를 주되게 진행하고 있습니다.
마이그레이션은 보통 다음 5단계를 거칩니다. 각 단계 옆에 적은 소요 시간은 GET API 기준이며, POST의 경우 더 늘어납니다.
마이그레이션에서 뭘 해야 하는지 코드를 분석하여 계획을 작성하는 단계입니다. 원래는 코드 분석에만 4시간이 걸렸는데, 테크스펙을 간소하게 쓰기 시작한 이후로는 1시간으로 줄었습니다.
새로운 기능을 구현하는 경우라면 테크스펙을 먼저 작성하는 것이 당연히 효율적입니다. 계획을 세워야 작업 순서도 명확해지고, 여러 명이 동시에 작업할 수도 있으니까요.
하지만 마이그레이션은 이야기가 다릅니다. 실시간으로 코드를 짜다 보면 "예상했던 계획과 다르네" 하는 순간이 비일비재합니다. API가 방대할수록 테크스펙에서 놓친 부분이 생기기 마련이고, 어차피 기존 코드의 동작을 100% 이해하려면 직접 마이그레이션을 해 봐야 합니다. 게다가 보통 1인 작업이라 테크스펙의 부재가 덜 치명적이기도 하고요.
그래서 생각했습니다. 직접 테크스펙을 쓰는 대신, AI한테 Python 레거시 코드의 분석을 맡기면 테크스펙을 쓸 필요가 없지 않을까?
파이썬 코드를 코틀린으로 옮기며 엔티티, 스키마, 서비스, 컨트롤러 등을 작성하는 단계입니다.
보통은 이미 마이그레이션이 완료된 기존 코틀린 코드를 참고하며 진행합니다. 컨벤션도 잘 지켜져 있고, 잘 동작하는 선례이기 때문에 밑바닥부터 새로 쓰기보다 적당히 재활용하는 편이 낫습니다.
문제는 인지 부하입니다. 모니터 하나에 (새로 만들 코틀린 코드) / (이미 이관 완료된 코틀린 코드) / (기존 파이썬 코드) 창을 3등분해 놓고 시선을 왔다갔다하며 작업하는 건 꽤 피곤합니다. 그래서 AI한테 기존 Kotlin 코드 선례와 이관해야 할 Python 코드 양쪽을 정보로 주고 마이그레이션을 지시하는 방식을 택했습니다. 이때 gh 명령어를 사용해 GitHub에서 직접 코드를 가져오게 했습니다.
스키마, 서비스, 컨트롤러 등 각 클래스에 대한 단위 테스트를 작성하는 단계입니다. 단위 테스트는 코드에 버그가 없는지 판단할 수 있는 마지막 보루이므로 매우 중요합니다.
보통은 Python 코드에 이미 검증된 단위 테스트가 있어 이를 그대로 마이그레이션하면 됩니다. 없는 경우에는 새로 작성하고, 마이그레이션한 테스트가 실패하면 앞 단계에서 쓴 코드 중에 오류가 있다는 뜻이므로 그걸 고쳐야 합니다.
하지만 API의 동작을 완전히 이해하는 데는 시간이 걸리기 때문에, 테스트가 실패해도 왜 실패했는지 원인을 찾는 데 상당한 시간이 소모됩니다. 그래서 AI한테 단위 테스트를 실행하게 한 뒤, 실패 시 원인을 스스로 분석하고 코드를 수정하도록 지시했습니다.
프로젝트 내 컨벤션 문서를 잘 지키며 마이그레이션했는지 동료의 코드리뷰를 통해 확인하고 수정하는 단계입니다.
컨벤션을 지키는 것은 중요하지만, 사람이 모든 컨벤션을 일일이 기억할 수는 없습니다. 보통은 다양한 티켓을 처리하면서, 동료의 리뷰를 받으면서 경험적으로 익혀 나가게 됩니다.
여기에는 세 가지 문제가 있었습니다.