레거시 서비스 갈아엎을때 기존 코드는 어떻게 하나요?

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

안녕하세요 :) 경험을 비춰봤을때 기존 코드를 리팩터링 진행해서 레거시 코드에 반영된 축척된 히스토리들이 제거되지 않도록 했습니다! 도움이 될지 모르겠지만 관련 포스팅을 한게 있어서 공유드립니다 :) https://m.blog.naver.com/nextwebresearchlab/223151413126 https://m.blog.naver.com/nextwebresearchlab/223158736264

새로운 설계에 맞춰서 새로 코드를 작성한다고해도 종반에 데이터 마이크레이션은 까다로워 보이네요..

답변은 아니지만 저도 10년 전 레가시를 마이그해야 하는 판..

규모가 큰 서비스라 하셨으니, 이슈가 크겠네요. 아키텍처 변경이 아마 타팀에도 영향을 미칠거구요. 상위조직 소속으로 아키텍처팀이 따로 존재한다면, 거시적 시점의 아키텍처 검토를 받으시는게 좋긴 할 것 같은데요. 제 의견을 말씀드려 보자면, (1) 장애/이슈 포인트에 해당되는 부분만 리팩토링하거나, (2) 아키텍처를 새 판으로 짜야 한다면, 대규모 프로젝트가 될테니 비즈니스와 기능을 잘게 쪼개어 리스트업 한뒤, 레거시 테스트케이스를 재점검 합니다. (3) 배포 방식을 정합니다. 빅뱅으로 할지, 순차적으로 할지, 순차적으로 한다면 우선순위를 결정합니다. 반드시 배포 이후 안정화 기간의 공수까지 그 중요성을 잘 설득하셔서 예산으로 잡아야 합니다.

레거시 서비스의 재설계와 마이그레이션은 중요하고 복잡한 작업입니다. 일반적으로 다음과 같은 접근 방식을 고려할 수 있습니다. 1. 전면 재작성 (Rewrite): 기존 코드를 완전히 폐기하고, 새로운 아키텍처와 기술 스택을 사용하여 서비스를 처음부터 다시 작성하는 방법입니다. 이는 규모가 크고 복잡한 서비스의 경우에는 많은 비용과 시간이 소요될 수 있으므로 신중한 판단이 필요합니다. 2. 점진적인 리팩토링 (Incremental Refactoring): 기존 코드를 점진적으로 개선하면서 새로운 아키텍처에 맞게 변경하는 방법입니다. 이는 기존 코드를 유지하면서 부분적으로 개선하는 것으로, 비용과 리스크를 분산시킬 수 있습니다. 단계적인 접근법으로 진행되므로 전체 서비스 중 일부 모듈이나 기능을 우선적으로 리팩토링할 수 있습니다. 3. 혼합 방식 (Hybrid Approach): 전면 재작성과 점진적인 리팩토링을 조합한 방법입니다. 이는 주요 기능 또는 모듈을 전면 재작성하고, 나머지 기능은 점진적인 리팩토링으로 개선하는 방식입니다. 이 방법은 전체 서비스를 새로 작성하는 비용과 시간을 줄이면서도 핵심 기능을 빠르게 개선할 수 있습니다. 이 선택은 여러 요인을 고려해야 합니다. 예산, 시간 제약, 인력 리소스, 비즈니스 요구사항, 기술 스택 등을 고려하여 가장 적합한 전략을 선택해야 합니다. 복잡한 경우에는 완전히 새로 작성하는 것보다는 점진적인 리팩토링 방식을 선호하는 경우가 많습니다. 이는 작은 개선 단위로 기능을 향상시키며, 안정성과 성능을 지속적으로 개선할 수 있기 때문입니다. 또한, 리팩토링이나 재작성을 수행할 때는 테스트와 검증을 충분히 진행해야 합니다. 테스트 커버리지를 확보하고, 기능의 일관성과 안정성을 확인하기 위해 QA 프로세스를 충분히 수행하는 것이 중요합니다.