최근에 마이그레이션 프로젝트를 진행하면서 느낀 점들과 어떻게 하면 좋을지 나의 생각을 정리해 보면 좋을 것 같아서 적어봤다. 물론 아직 인턴으로 주니어도 아닌 개발자의 입장에서 적은 생각이다… 🌱

Legacy To Modern Thumbnail

레거시 프로젝트와 현대 프로젝트

레거시 프로젝트와 현대 프로젝트는 무엇으로 구분하는 것일까에 대해서 생각을 해봤다. 간단하게는 개발 언어와 프레임워크 등의 발전이 있을 수 있겠다. JSP에서 React 혹은 jQuery에서 React가 여기에 해당하지 않을까.

좀 더 크게 본다면 개발 방법론에도 차이가 있을 것 같다. 이전에는 처음 기획을 픽스하고 그대로 개발하는 워터폴 방식의 개발 방법을 적용을 했으니 개발 과정에서 생기는 문제점이나 품질 등을 외면하는 경우가 있었을 것 같다.

→ 워터폴 방식으로 개발하는 경우

→ 이미 다 만들어졌는데 생긴 문제가 100개다.. 이 경우에는 정말 치명적인 문제만 50개 고치고 나머지는 외면할 수 있을 것 같다고 생각했다.

이것보다 더 큰 범위로 생각해 본다면 개발자에 관한 문화가 있지 않을까 생각이 들었다. 회사에서 코드를 보면서 알게 된 사실로는 이 프로젝트가 SI 업체에 맡겨 탄생한 점이라는 것이다. 코드를 작성한 사람이 누군가 따라가보니 SI 회사에서 만들어준 프로젝트였다.

이것처럼 이전에는 처음부터 개발자가 회사에 포함되어 프로덕트를 만드는 구조보다는 외주를 통해 외부에서 제작해주는 형태의 개발이 많았다고 한다. 초기 구현하는 개발자 따로, 유지보수하는 개발자 따로.. 이렇게 책임이 분리되어있는 형태가 되면 레거시를 개선하려는 시도가 생기지 않을 것 같다는 생각을 하게 되었다.

레거시의 특징

레거시를 보고 당황했던 경험이 있다. 하지만 보고 생각하면 할 수록 이렇게 될 수 밖에 없는 이유가 있지 않았을까 라는 생각을 하게 되었다.

    레거시 프로젝트의 특징에는 어떤 것들이 있을까. 처음에 내가 생각했던 특징은 아래와 같다.

• 구조화 없는 코드
• 분리가 없거나 일관적이지 않음
• 서버와 강하게 결합되어 있음
• 문서화 부족으로 인해 유지보수 어려워짐
• 확장성 부족해 새로운 시도가 힘들어짐
• 보안 취약성을 가진 코드가 그대로
• 구형 기술의 구조적 문제로 인한 성능 문제

이 중에서 가장 큰 문제는 확장성과 유지보수성이 아닐까 싶다. 물론 보안 취약성은 정말 경제적 피해를 입힐 수 있는 문제로 가장 치명적이지만, 중요한 문제는 확장성과 유지보수성이라고 생각한다.

보안 취약성 같은 잠재적인 문제를 해결하려면 유지보수를 하기 쉬워야하고, 유지보수를 쉽게 하고 기능을 쉽게 추가하기 위해서는 처음부터 확장성을 고려한 설계가 필요하다고 생각하기 때문이다.

문서화와 확장성이 좋다면 잠재적인 위험과 알려진 위험요소들을 해결할 수 있는 의지가 생긴다고 믿는다.

이렇게 적고 보니 구조화 없는 코드가 분리 부족을 유발하고, 이는 곧 확장성 저하와 유지보수 어려움을 만드는 것 같다..? 물론 너무 많은 분리는 오히려 독이라고 생각하는 편이기는 하다.

레거시와 모던의 차이점

현대 프로젝트의 특징

현대에서는 이런 레거시들의 특징이자 문제점을 많이 개선한 모습으로 보인다.

• 구조화되어있는 코드
  • 프레임워크 단위로 구조화되기도 하는
• 책임 분리가 컨셉으로 잡혀있는
  • 이전 프로젝트들보다 최근 웹 프로젝트들에서는 책임 분리를 쉽게 들어볼 수 있게 된 것 같다. 그만큼 책임분리하는 원칙이 표준이 되었다는 의미같다.
• 서버와의 결합 약화
  • 이전에 JSP나 템플릿 언어를 활용하여 서버에서 모든 것을 처리하고 내려주던 프로젝트가 아니라 서버의 책임을 어느정도 클라이언트에 분리하여 제공하는 것과 필요한 데이터를 API 형태로 요청하고 응답하는 방식으로 해결했다.
• 개발 문화와 방법의 발전
  • 애자일한 개발 방법론, 쉽게 말하면 자주 보고 자주 고치는 방법론의 도입으로 잠재적인 문제를 좀 더 빠르게 발견하고, 빠르게 해결 할 수 있는 구조가 도입되었다.
  • CI/CD 등의 도입으로 개발 → 배포 → 테스트 과정의 주기가 짧아져 더 적은 시간 내에 많은 문제를 해결 할 수 있게 되었다.

이렇게 많은 문제가 해결되었지만 이게 정답이라고 생각하는 것은 위험하다고 생각하다. 나는 언젠가 리액트도 레거시가 되는 날이 올 수도 있다고 생각하기 때문이다.

레거시에서 현대 프로젝트로의 마이그레이션하려면..

레거시에서 현대 프로젝트로의 마이그레이션은 정말 어려운 결정이라고 생각이 들었다. 짧고 작은 부분만 보면 현대화하는 것이 어렵지 않다고 느낄 수 있다. 하지만 거대한 프로젝트이고, 이 변경이 다른 곳에도 영향을 크게 미칠 수 있다고 생각하면 버겁게 느껴지기도 한다.

• 전략적인 준비와 작은 것부터 천천히
• 점진적이고 안전한 접근

쓰다보면서 생각하니 더 어렵게 느껴진다. 백엔드에서 API 명세를 바꾸면 이 API를 활용하는 프론트엔드에서도 모두 변경을 해줘야한다. 혹은 데이터베이스에선 내려주는 필드명이 변경되거나 타입이 변경된다면? 백엔드, 프론트엔드 모두 영향이 갈 수도 있다.

처음에는 레거시는 그대로 두고, 새로운 프로젝트를 완전히 개발해서 레거시를 100% 대치해서 사용하면 안되나? 이런 생각을 했었다.

빅뱅과 점진적 마이그레이션

여러 정보를 알아보고 직접 과정을 지켜보면서 느낀 점은 말이 안된다는 것이었다. 새로운 프로젝트로 완전히 대치하면 생길 수 있는 많은 문제점에 대해서 알게 되었기 때문이다.

점진적으로 개선하는 경우에는 ABCD 앱이 있을 때 A에서 발생할 수 있는 문제에 대해서만 조사하고, 대비하고, 문제가 생겼을 때 사용할 수 있는 리소스를 적게 가져갈 수 있다.

하지만, ABCD를 한번에 만들어서 대치하는 경우에는? 예상치 못한 문제들이 동시다발적으로 터질 수 있다. 그렇게 되면 모든 리소스가 발생한 문제를 해결하는데 투입이 되어야하고, 서로 영향을 주는 사이드 이펙트가 많이 생길 수 있기 때문에 큰 문제가 된다. (BigBang 방식이라고 부르는 것 같다)

중요한 것

글을 쓰면서 느낀 점은 단순히 코드레벨에서만 성장을 위해 노력하는 것뿐 아니라 이런 더 큰 관점에서도 계속 생각해봐야겠다고 느꼈다. 레거시를 유발하는 것이 단순히 JSP, JQuery 같은 언어의 문제가 아니라는 점을 다시 한번 생각했고, 개발방법에 대한 고찰과 구조의 설계에 대해서 항상 생각해야겠다고 느꼈다!