🥕 Byebye Vue.js

gon Kim

·

Follow

Published in

elecle

·

10 min read

·

Dec 27, 2021

--

Share

일레클 웹프론트팀에서는 어드민 페이지를 react기반의 next.js로 마이그레이션하기로 결정했어요. 왜 굳이 안정적으로 개발되고 있는 Vue.js를 포기하고 React 프레임워크로 넘어가는 걸까요?

🥕 3년간 고생한 Vue.js/Nuxt.js

• 일레클에서는 지난 2019년 3월부터 함께한 Vue.js를 통해 단순하게 javascript코드를 조합하는 방식으로 내부 어드민 웹에 손쉽고 빠르게 다양한 기능을 추가할 수 있었어요.
• 특히 1인팀으로 사업 확장에 따른 기능 추가를 위해서 최소한의 유지보수, 관리가 가능한 상태로, 빠르고 풍부한 기능 개발을 위해 현실적인 타협을 할 수 밖에 없었어요
• Vue.js로 구성된 프로젝트는 더욱 더 유연하고 규칙없이 확장에 용이한 방식으로 개발을 할 수 있어요. 그래서 최소한의 디렉토리 규칙을 가지고, 페이지 단위로 손쉽게 관리할 수 있는 Nuxt.js를 2019년 10월경 도입했어요.
• Nuxt.js는 페이지 단위 개발이 강제되어, 수십개의 페이지를 가진 어드민 페이지 개발 속도를 한층 더 높여주었고, 라우팅이나 상태관리 등의 추가 리소스를 많이 줄일 수 있어 기능 개발에 용이했어요.
• Nuxt.js는 자체 검증된 @nuxtjs 레포지토리 아래 3rd party 라이브러리가 풍부하여 상대적으로 안전하고 쉽게 import하여 사용할 수 있는 경우가 많았어요. 예를 들어, localStorage나 cookie, axios등의 ‘어차피 안정적으로 사용되는 라이브러리’는 @nuxtjs의 prefix를 단 채로 제공되고 있어요.

💻 Vue.js/Nuxt.js의 한계

• Vue.js의 option API는 html과 javascript를 분리하였고, data, methods, watch, computed등 템플릿으로 정의된 곳에서 로직을 구현해요. 다만 그렇게 로직을 구현함에 있어서 this라는 맥락의 불분명함, mixins나 filter로 전역에서 정의된 this객제의 필드나 Vue의 property 등 개발 상의 애매모호함이 커요. 특히 웹프론트 개발 팀원이 늘어나면서, 어드민 프로젝트 자체가 더욱더 확대 되면서 이 ‘애매모호함’은 개선할 필요가 커지고 있어요.
• Vue.js/Nuxt.js는 이미 프레임워크에서 최적화나 퍼포먼스를 많이 신경쓰고 있어요. 반면 React/Next.js에서는 개발자가 직접 의도적으로 렌더를 컨트롤하거나 효율적으로 진행하도록 더 많이 신경을 쓸 수가 있어요. 즉, Vue보다 React가 문제를 파악하고 직접 개선하는 데 효과적이라고 판단되었어요.
• Vue.js/Nuxt.js는 커뮤니티 자체가 아직 부족해요. React기반 웹 프론트엔드 개발자가 훨씬 더 많고, 최적화나 이슈에 있어 검색과 대응이 용이해요. (그렇지만 Next.js는 또 빈약해요..)

💻 Vue의 한계 극복 시도

• Vue에서는 위에서 설명한 애매모호함과 로직의 분리(관심사의 분리)를 위해 기존 option api과 다른 composition api를 도입하여 Vue 3.0으로 정의했어요. Nuxt.js에서도 Vue 3.0 composition api과 추가적인 개선(빌드 엔진 개선 등)이 이루어진 Nuxt 3.0을 런칭하고자 베타 버전을 만들고 출시를 준비하고 있어요.
• 일레클 어드민 프로젝트에서도 nuxt 2.0의 브릿지 개념으로 제공하는 nuxtjs/composition 라이브러리를 통해 setup에서 로직단위의 분리를 훌륭하게 진행해 왔어요. 다만 이미 vue 2.0/nuxt 2.0으로 구현된 기존의 모든 로직을 리팩토링하지는 않고 새롭게 추가 구현하는 경우에만 사용하고 있었어요. 왜냐하면 1) 기존의 모든 로직을 리팩토링 하는 것은 비효율이 매우 커요. 2) vue 3.0의 composition api를 가능하게 해주는 nuxtjs/composition 라이브러리를 통해 3.0을 맛보고 있지만, 안정적이지 않았고, 최적화되지 않은 상태로 임시적으로 vue 2.0/nuxt 2.0상에서 기능하게 해주는 것이었어요. 특히 에러트랙킹이 잘 되지 않거나 다소 안정적이지 않는 경우를 실제 개발하며 확인할 수 있었어요.
• 따라서 안정적으로 프로덕션 버전의 개발이 가능한 Nuxt 3.0을 기다리고 있었어요. 2021년 10월 Nuxt 3.0의 Beta버전이 안정적으로 발표 되었고, 프로덕션 버전만을 기다리고 있었어요. 오픈 소스로 개발되는 Nuxt 인 만큼 많은 개발자 분들이 issue와 discussion, pull request를 통해 참여하고 있어요. 그렇지만 실제 도입하여 사용하고자 하는 상황에서 중요한 것은 Production버전의 안정성이에요. 그래서 언제 정식 출시가 될까? 트랙킹하고 있었는데.. https://github.com/nuxt/framework/discussions/2198 2022년 1월까지 RC(최종 시험판) 출시가 완료되고 2022년 연말 production 버전이 출시될 것이라고 해요……..

🥕 Nuxt 3.0은 너무 멀고, 기술 부채는 쌓여 가고 있어요.

• Vue.js/Nuxt.js 2.0에서의 기술 부채(최적화, 기능 개발을 더 우선으로 한 코드 상태)를 Nuxt 3.0에서 해결하고자 미루어 두고 있었지만, 2022년 연말은 너무 늦다고 판단했어요.
• 2.0에 3.0을 얹어서 잘 사용하고 있었지만, 불안정해요. 결국 어떠한 형태든 기술 부채 해소가 필요해요. 다만 Vue 2.0자체의 한계는 명확하고, Nuxt 3.0은 불안정해요. 결국 선택지는 React가 남았어요.

🥕 React/Next.js를 도입하기로 결정했어요.

• 기술적인 측면만 고려한 것이 아니라 서비스, 이미 안정적으로 작동하는 기능의 유지/보수등을 적극적으로 고려했다는 점을 말씀드리고 싶어요! 현재까지 잘 작동한 웹이지만, React를 도입하여 개발적으로도 challenging하면서도 프로덕트 기획/디자인 측면에서도 더 많은 가능성이 생겨요.
• 따라서 아래 설명드리겠지만, 점진적으로 기존 어드민 사이트 이용에 전혀 문제가 없게 안정적으로 변경하고자 해요. 변경 가능한 작은 단위의 의미있는 마이그레이션 대상을 선정한 후, 이용상 문제가 없게 변경하고 이를 점진적으로 확대하여 최종적으로는 모든 프로젝트가 React로 대체될 것이라고 기대해요.
• 또한 서비스웹은 안정적으로 React/Next.js로 제공되고 있어요. 각각의 장단점에 의해 여러가지 스택을 활용하는 것도 좋지만, 단일 프레임워크를 사용하는 것이 개발의 유지/보수 측면에서도 안정성을 가져올 수 있을 것이라 생각해요.
• 이제부터가 시작이에요. 구체적인 계획을 마련중이고, 문제 없이, seamless하게 마이그레이션 하는 것을 최우선 목표로 삼고 있어요. 또한 컴포넌트나 UI/UX 개선 등도 함께 진행하고자해요.

🥕 React로 무엇이 가능할까? 걱정도 분명 있어요.

• vue의 ‘쉽다’는 html, js의 조합으로 이루어졌다는 점이에요. 다만 이는 프로젝트가 커질 수록 관리가 다소 불편해지는 점이 있었어요. React에서는 렌더 시점을 통제하거나 로직을 구성하는 데 용이하여 퍼포먼스 개선에 훨씬 도움이 될 것으로 기대합니다. 특히 이미 React를 도입한 서비스웹 프로덕트를 통해 이러한 점을 충분히 확인하고 있는 상황에서, 실제로 일레클 서비스에서 더 복잡한 어드민 사이트에 React를 도입하여 프로덕트를 개선하면 퍼포먼스나 유저 경험을 훨씬 더 높일 수 있고, 결과적으로 여러분들의 업무 효율이 대폭 향상시킬 수 있는 방향이 될 것이라고 기대하고 있습니다.
• React를 통해 프로젝트를 진행하면 차세대 Figma로 평가되는 Framer를 도입할 수 있어요. Figma로 디자인을 진행하여도 이를 개발 코드로 가져오는 데 추가적인 리소스가 드는데 Framer는 이조차도 자동화해주는 툴이에요.(Figma와 별도의 툴이지만, Figma의 상위호환) 특히 React기반 웹 프로젝트로 구성되어 디자인 → 개발에 반영하는 것은 기본이고, 직접 코딩되어 있는 컴포넌트를 직접 ‘이용’하여 디자인할 수 있어요. 이는 특히 어드민 프로덕트에 매우 유용할 것으로 예상되는데요, 현재 스크린샷이나 임시적인 컴포넌트를 이용하여 컴포넌트를 기획하는 환경에서 실제로 이용되고 있는 컴포넌트를 더 적극적으로, 그럼에도 훨씬 손쉽게 이용함으로써 어드민 프로덕트 기획/개발 효율이 매우 향상될 것이라 기대하고 있어요.
• React는 Vue보다 (우리나라에서) 개발자 풀 확보가 훨씬 용이해요. 언젠가 일레클 서비스가 확장될 수록, 또 어떠한 상황에서도 React 기반 개발 스택은 장점이 될 거에요.
• 다만 Vue에서 디자인 리소스를 사실상 0으로 줄여주었던 Vuetify 라이브러리는 더이상 이용이 불가능할 거에요. Vuetify는 단순한 UI디자인 이외에도 Vue자체와 강력하게 결합하여 데이터 바인딩이나 로직과 결합된 형태의 컴포넌트가 풍부했어요. 이를 React에서 처음부터 개발하는 것은 분명 리소스가 필요해요. 하지만 Vuetify도 Material UI를 기반으로 만들어진 프레임워크고, 마찬가지로 React에서도 Material UI라는 UI프레임워크는 존재해요. 이를 기반으로 로직을 정의하고 커스텀하는 과정이 필요하겠지만 Framer의 도입과 함께 훨씬 더 의미있는 방식이 될 것이라 기대하고 있습니다.

🥕 그래서 지금부터 기존 어드민 개발을 중단하는 건가요?

• 아니에요. 모든 스프린트나 현재 어드민을 사용하고 있는 상황에서 기능 중단이나 부분적 개발 중단 조차 없이 기존과 완벽하게 동일하게 기능 추가/개선/변경 등을 진행할 수 있습니다.
• 이미 어드민 프로젝트에 그러한 기능 추가/개선/변경 태스크는 이미 기존 코드는 유지/보수의 관점에서, 새로운 코드는 vue 3.0의 api를 먼저 도입하여 새로운 기술의 도입 관점에서 대응하고 있었어요. 이와 같은 기조는 리팩토링이 불가피한 상황에서 지속될 것이에요.

🥕 어떻게 도입할까요?

• 최종 목표는 모든 어드민 프로젝트의 프론트엔드 프레임워크를 react로 대체하는 거에요.
• 다만 이것이 실현가능하도록 다음과 같이 점진적으로 도입해보려고 해요

1. 고객관리 어드민 사이트의결제 내역 페이지를 react프레임워크를 이용한 결제 내역 페이지로 대체합니다.
   - 이 때, 컴포넌트를 정의하거나 Framer를 도입하는 등 react/next를 이용한 큰 틀과 개발 프로토콜을 상세히 잡아나갈 예정이에요.
   - 또한 실제로 다른 도메인에서 데이터를 확인하더라도, 동작은 기존과 동일하도록, 예를 들면 추가적으로 로그인이 필요 없게 하거나 메뉴 nav bar를 통한 다른 컴포넌트로의 이동도 두 사이트간 문제 없이 호환될 수 있도록 작업하고자 해요. seamless가 가장 큰 목표에요
   - 기능적인 변경이나 기획상의 변경은 전혀 없을 거에요.
2. 고객관리 어드민의 다른 페이지들을 react프레임워크로 대체하여 고객관리 어드민 자체를 새로운 프레임워크로 작성하여 분리합니다.
3. 운영 어드민에서 고객관리 어드민과 공유하고 있는 페이지들을 react로 대체합니다.
4. 운영 어드민의 남은 페이지도 대체합니다.
   - 이 때 특히 h3이나 지도 관련 기능은 매우 heavy하기 때문에 안정성을 최선으로 기존 기능 이용에 문제가 없도록 마지막에 대체를 할 것 같아요.

• 크게는 위 순서대로 진행하는 것을 목표로 일단 1번을 1월에 진행해보며 전체적인 타임라인을 더 구체화나가고자 해요.
• 기존 스프린트나 프로덕트 개발에도 문제 없이, 장기적인 장단점을 고려해서 내린 결정이에요! 웹프론트엔드팀은 프로덕트 적으로, 기술 적으로도 훨씬 더 나은 방향이라고 믿고 있고, react로의 마이그레이션을 기대하고 있어요. 많은 코멘트, 피드백과 응원 부탁드려요! 🥕