내가 생각하는 프로젝트 규모에 따른 프론트 기술스택 선정기준

웹 에이전시를 다니다 보니 클라이언트의 요구사항과 재정에 따라 프로젝트의 기술스택을 정하는 것이 효율적인 개발에 있어 중요하다고 생각하게 되었다. 회사를 운영하는 관점에서는 더욱 중요하겠지만, 개인적인 프로젝트를 할 때에도 빠른 배포가 목적이라면 기획자의 요구사항에 가장 적합한 기술스택을 선정해 진행하는 것이 옳다고 생각한다.

 

이전에는 Nuxt.js를 쓰면 CSR, SSR, SEO 다 대응 가능하니까 무조건적으로 좋은 기술을 쓰는게 좋지 않은가? 라고 생각했었다. 하지만 다양한 기술을 지원한다는 것은 그것들을 핸들링 하기 위한 배경지식이 마련되어 있어야 한다는 것을 느꼈다. 배경지식 없이 일단 진행하기엔 차후 에러를 일으킬 가능성과 삽질을 하게될 가능성이 높아지기 때문이다. 이러한 부분은 개발 속도와 단가가 올라가는데 영향을 미치기에 더 조심해야 한다.

 

물론 현재 팀의 기술스택 상황과 이해도와 같은 변수들에 따라 달라질수도 있다. 하지만 이번 글은 어디까지나 라이브러리나 프레임워크의 특징과 장단점, 경험을 바탕으로 작성해보려고 한다.

 

웹플로우(Webflow)

웹플로우 랜딩페이지

웹플로우(Webflow)는 대표적인 노코드 웹빌더이다. 

다른 노코드 툴인 아임웹, Wix에 비해서 자율성이 매우 높고 노코드 툴 중에서는 난이도가 있는 편인것 같다. 하지만, 개발자라면 사용법만 익히면 하루만에 사용할 수 있을 것 같다.

 

개발을 할 줄 아는 개발자 입장에서는 왜 노코드 툴을 써야하냐는 의문이 들 수도 있을 것 같은데 이것이 이번 글을 쓰게된 이유중 하나이다.

React와 Webflow를 사용해서 단순 보여주기용 랜딩 페이지를 만든다고 한다면 나는 Webflow를 사용할 것 같다. 왜냐면 React를 사용하면 프로젝트 설정부터 신경을 써야하지만, Webflow는 웹 페이지만 만들면 되고 쉽기 때문에 빠른 개발이 가능해 개발 단가를 줄일 수 있다. 

 

그 외에도 몇가지 장점들을 얘기하자면 다음과 같다.

• 쉬운 웹 제작 난이도 
• SEO 대응이 좋음
• 인터렉션을 다루기가 편함. 
• Code Embed 기능을 통해 커스터 마이징 가능.
• 자체 CMS를 통해 간단한 DB구조를 짤 수 있음.

그래서 회사소개, 안내 페이지, 랜딩 페이지 등과 같이 데이터 핸들링을 크게 필요로 하지 않고 정보를 제공하기 위한 웹 페이지 정도라면 Webflow를 써보는 것도 좋다고 생각한다. 

 

Vue.js

Vue.js 개발 문서 페이지

Vue 부터는 본격적인 프론트 개발을 필요로 하는 상황에서 쓰면 좋을 것 같다.

 

React와 Vue는 보통 회사 내부에서 둘 다 쓰기보단 어떤 기술스택을 쓰느냐에 따라서 갈릴것 같다. 둘 다 SPA와 CSR 정도로 해결가능한 요구사항일 경우 적합할 것 같다.

 

React와 Vue의 최대의 차이는 라이브러리와 프레임워크라는 점이다. 그래서 두 개를 다 써본 입장에서 얘기하면 Vue를 썻을 때 조금 더 간편하게 웹을 제작할 수 있었던 것 같다.

 

그 이유는 Vue는 어떤 형태로 제작해야하는지가 React보다 명확해서 크게 고민할 부분이 적었다. 

이게 무슨 소리냐면 React는 hooks, 폴더 구조, 디자인 패턴 등 사용자의 역량과 설계에 따라 난이도와 성능이 천차만별로 나뉘게 된다. 그래서 개발을 하면서도 고민해야할 부분이 많은데, Vue의 경우에는 정해둔 SFC(Single File Component) 문법이 있다보니 상대적으로 고민할 부분이 적었다. 

 

이러한 점 때문에 만약 사내 직원이 자주 바뀌는 경우 React로 짜여져 있는 코드를 읽고 유지보수 하는 것 보다 Vue로 개발을 하는데 통일감이 있고 쉽게 적응할 수 있다고 느끼기도 했다. (뭐.. 물론 요즘은 다 React만 공부하기 때문에 Vue를 새로 공부해야 한다는 리스크가 있지만..)

 

그래서 다음과 같은 경우 Vue를 추천하고 싶다.

• SSR을 제공할 필요가 없는 경우
• SEO를 크게 신경쓰지 않아도 되는 경우 (SPA의 단점, 보완 방법이 있음)
• 유저의 행동의 따라 UI가 자주 바뀌어야 하는 경우 (SPA의 장점)
• 신입이 많은 상황에서 프론트를 해야할 경우
• 사내 개발자가 많이 바뀌는 경우 (유지보수 및 코드 품질 유지적 측면에서)
• 사내 Vue를 쓰고있는 집단의 경우

React.js

react 랜딩페이지

React는 그야말로 가장 대중적인 프론트엔드 개발 라이브러리가 아닐까 싶다.

React는 Vue보다 자율성이 높기 때문에 개발자에게 다양한 책임을 요구한다. 구조부터 설계까지 개발자의 역량이 중요하다는 생각이 들었고 그렇기 때문에 Vue보다 러닝커브다 높다고 생각한다.

 

하지만 Vue는 SFC 문법에 따라 한 파일에 하나의 컴포넌트를 지향한다. 또 파일을 만들게 되면 기본적으로 script template script 태그를 만들어 줘야 한다. 하지만 React에서는 이런 컴포넌팅에 대한 부분이 자유롭다 보니 조금 더 효율적인 구조를 구성할 수 있다.

 

또 hook을 통해 UI와 기능의 분리 또한 가능해 SRP(단일 책임 원칙)를 적용하기에도 좋아 보였다.

 

React는 무겁다. SPA와 CSR의 특징이기도 하지만 React는 특히 성능관리를 잘 해주지 않으면 초기 로딩이 꽤나 무거워 진다. 그래서 useMemo, useCallback등 캐싱 훅들을 이용해서 렌더링을 잘 관리 해주어야 한다. 만약, 간단한 랜딩페이지만 만든다고 한다면 React는 별로 좋은 선택이 아니다.

 

이런 경우 React를 추천한다.

• SSR을 제공할 필요가 없는 경우
• SEO를 크게 신경쓰지 않아도 되는 경우 (SPA의 단점, 보완 방법이 있음)
• 유저의 행동의 따라 UI가 자주 바뀌어야 하는 경우 (SPA의 장점)
• 사내 개발자들의 역량이 뛰어난 경우
• 사내 React에 대한 확고한 컨벤션이 있는 경우
• 당장 취업이 급한 경우

Nuxt.js 또는 Next.js (SSR & SSG 지원 프레임워크)

두 프레임워크는 큰 틀에서 본다면 크게 차이는 없다. 단지 설정이나 폴더 구조 및 자율성 부분에서 일부 차이가 있을 뿐이다.

다만, Nuxt.js는 Vue.js를 기반으로 한 프레임워크이며, Next.js는 React.js를 기반으로 한 프레임워크이다 보니 자율성 적인 특징들이 Nuxt.js와 Next.js에도 반영되어 있다.

 

두 프레임 워크는 SSR(Server Side Rendering)과 SSG(Static Site Generation)을 해야하는 경우 사용하면 된다.

단지 두 프레임워크를 이용해서 CSR, SPA를 구현해도 되지만 오버 스택일 수 있다. 그렇기 때문에 SEO 같은 부분을 잘 생각해서 선택해야 한다.

 

이런 경우 Nuxt.js나 Next.js를 추천한다.

• SEO를 고려해야 하는 경우
• SSR를 해야하는 경우 (백으로 부터 많은 양의 데이터를 불러와야 하는 경우)
• SSG로 웹사이트를 만들어야 할 경우

마무리

이처럼 React를 쓴다고 해서 다 좋은 것도 아니고 노코드 툴을 쓴다고 해서 나쁜 것도 아니다.
어떤 기술을 특정해서 써야하는 경우가 아니라면 본인이 개발해야 하는 프로젝트의 규모와 특징에 따라 어떤 것을 써야하는지 고민해볼 필요가 있을 것 같다.

 

요즘은 취업적인 측면때문에 아무래도 React를 많이 공부하는 것 같은데 하나의 종속되어 있지말고 기술의 장단점을 잘 파악해 새로운 기술을 경험해 보는것도 중요한 것 같다.