보통 이럴 때 어떻게 해야하는지는 잘 모르겠습니다만, 제 경험상 효과적이었던 것 같은 방법 공유합니다. 8년 쯤 된 레거시 시스템을 한번에 신규 시스템으로 교체하는 것은 대단히 어려운 일입니다.

보통 이럴 때 어떻게 해야하는지는 잘 모르겠습니다만, 제 경험상 효과적이었던 것 같은 방법 공유합니다. 8년 쯤 된 레거시 시스템을 한번에 신규 시스템으로 교체하는 것은 대단히 어려운 일입니다. 8년 동안 쌓인 다양한 기능들을 모두 재구현하는 시간적/인력적 비용도 매우 크고, 교체 후 기존 잘 되던 기능이 잘 안돼서 오히려 놔두니만 못한 일이 생기기 십상이죠. 거기까지도 가기도 전에, 그 모든 기능을 다시 구현하는데에 너무 많은 기간이 소요되기 때문에 중간에 프로젝트가 좌초될 위험도 큽니다. 당장 레거시 시스템을 유지보수하는데 스트레스가 커서 시작된 프로젝트지만, 정작 그 개선 프로젝트가 더 큰 스트레스를 가져오는데다, 그 결과가 잘 나오기도 쉽지 않습니다. 결국 신규시스템이 새로운 레거시가 되겠죠. 제 경험에 효과적이었던 방법 소개드립니다. 8년쯤 전이니까, 예를들어 HTTP REST API 서버라고 가정하면, 앞단에 L7 라우터를 하나꽂아서 (nginx나 traefik 따위) 전체 트래픽을 일단 레거시 서버로 보냅니다. 그 상태에서, 새로 추가하는 기능이나, 기존 기능 중 버그픽스를 하는 엔드포인트를 하나씩 신규 시스템에 구축해서, 해당 엔드포인트만 신규 서비스 풀로 라우팅합니다. 이 과정을 반복하면서, 시간이 날 때마다, 주요 엔드포인트 위주로 하나씩 옮깁니다. 자잘한 엔드포인트는 그냥 놔둬도 됩니다. 결국 기존 레거시 시스템의 버그를 해결하기 어렵고 신규 기능을 추가해서 벌이는 일이니까, 그런 작업에 대해서만 신규 시스템에 구축해나가는 방법입니다 결국 레거시와 신규 시스템을 둘 다 관리해야 하는 부담이 있지만, 결국 파레토 법칙으로 대부분의 트래픽은 20%정도의 엔드포인트에서 발생할 것이기 때문에, 그런 엔드포인트만 다 신규 시스템으로 넘기면, 레거시 시스템의 장비 대수를 줄일 수 있을 겁니다. API서버가 아니더라도, 비슷한 방식의 전환 추천드립니다.