내배캠 최종 프로젝트에서 Next.js 대신 React+TypeScript를 채택한 이유

규갓 God Gyu·2024년 4월 16일

TIL

목록 보기

61/74

오늘은 최종 프로젝트 BOOKER에서 기술 의사 결정에서 React+TypeScript를 채택한 이유를 설명해보려한다.

일단 Next.js란?

풀스택 웹 애플리케이션을 구축하기 위한 React 프레임워크!!!

즉 개발 과정을 간소화할 수 있게 된다.

Vercel에서 개발되었으며 SSR, SSG, API개발에 대한 쉬운 솔루션을 제공하는데 중점을 두었다.
심지어 SEO 친화적인 웹 애플리케이션을 구축할 수 있다는 사실!!

SSR(서버 사이드 렌더링)

서버에서 페이지를 사전 렌더링하여 초기 로딩 시간을 줄이고 검색 엔진 최적화(SEO)를 향상시킨다

SSG(정적 사이트 생성)

빌드 시점에 정적인 페이지를 생성하여 성능을 향상시킨다.
CDN캐싱을 사용하여 더 빠른 페이지 로딩 속도를 제공할 수 있다.

CDN 캐싱이란?
Content Delivery Network(콘텐츠 전송 네트워크)의 약자로, 웹 사이트에서 사용되는 정적 콘텐츠(이미지, CSS, JavaScript 파일 등)를 전 세계에 분산된 서버 네트워크를 통해 더 빠르게 전달하는 기술
이러한 CDN은 사용자가 웹 사이트에 접속할 때, 해당 컨텐츠를 더 빠르게 로드하게 도와줌.
CDN 캐싱은 이러한 CDN 서비스에서 사용되는 기술 중 하나로,
캐싱은 요청된 콘텐츠를 사용자와 더 가까운 위치에 있는
서버에 저장해두는 것을 의미.
이는 콘텐츠를 다시 요청할 때 원본 서버로부터 데이터를 받아오는 대신,
사용자와 가까운 위치의 서버에서 데이터를 불러오기 때문에 로딩시간을 줄여줌.
웹 사이트의 성능을 향상시키고, 사용자 경험을 개선할 수 있음

(대충 이런 느낌!!)

개발 경험 향상

Hot 모듈 리플레이스먼트(HMR)와 같은 개발 시간 동안의 기능을 제공하여 개발자들이 신속히 반복하고 테스트 할 수 있도록 함

HMR이란?
Hot Module Replacement(핫 모듈 교체)의 약자로,
개발자들이 웹 애플리케이션을 개발하고 수정할 때 유용한 기능
일반적으로 웹 애플리케이션을 개발 시, 변경된 내용 확인 위해 매번 새로고침 해야하지만, HMR은 이러한 번거로움을 덜어줌.
HMR은 전체 페이지 새로고침 없이도 코드 변경 사항을 실시간으로 확인할 수 있게 해줌.
주로 웹팩과 같은 모듈 번들러와 함께 사용되며, 개발 환경에서는 코드 수정에 대한 실시간 반영을 제공하고,
프로덕션 환경에서는 성능에 미치는 영향을 최소화하며 빠른 수정 및 배포를 가능하게 함

유연성

어떤 데이터 소스와도 함께 사용할 수 있으며, 기존 프로젝트에 쉽게 통합할 수 있어 다양한 웹 개발 요구에 유연하게 대응 가능

생태계

크고 활발한 커뮤니티가 있어, 애플리케이션 구축 유지보수하기 위한 다양한 리솟, 타사 라이브러리 및 도구를 활용할 수 있음

여기서 프레임워크 vs 라이브러리 차이는??
<프레임워크>
프로그램이 필요한 것을 개발자에게 알려줌으로써 제어권을 역전하고
<라이브러리>
개발자가 필요할 때 마다 설치, 혹은 호출함으로써 개발자가 능동적으로 사용하게 됨

이렇게 next.js만의 강점이 너무나도 좋은데 굳이 우리 프로젝트에서는 react+typescript로 진행 한 이유는 뭘까??

1. 5명의 프론트엔드 개발자

2. 명확한 마감날짜

3. 하나하나 쉽지 않은 기능개발

4. 한번 실패했었던 next.js 토이프로젝트

5. 프로젝트 퀄리티

약 5가지 정도로 크게 분류를 할 수 있을 것 같다.

1번,2번 같은 경우 그동안 4개월 반의 과정을 마무리 짓는 최종 프로젝트인데 우리 팀은 총 5명의 프론트엔드 개발자와 1명의 디자이너 즉 6명으로 진행을 하게 되었다.

총 6주동안 진행되는 프로젝트에서 프론트엔드만 5명은 생각보다 작은 숫자가 아니라 리더로써 판단하였고,
그만큼 프로젝트 규모도 커져야한다 생각하였다.

3번 같은 경우 위의 같은 내용을 고려한 결과 각자 6주의 시간을 들일만큼 다양한 컨텐츠를 개발하자는 결론이 다다랐고,

그동안 해왔던 다양한 프로젝트들은 항상 배워가면서 기능 개발을 하였다면,

최종 프로젝트만큼은 next.js로 진행한 프로젝트가 없었다보니 기존의 방식과 똑같이 배워가면서 기능 개발을 하는게 전혀 문제되진 않았지만,

퀄리티 vs 배움

이 두 가지의 큰 고민이 있었다고 생각할 수 있다.

즉 우리가 그동안 배운걸 뽐낸다는 개념의 프로젝트 퀄리티

그래도 취업을 위한 공부과정이기에 next에 익숙해져야한다의 배움

이 갈등은 실제로도 팀내에서 의견이 반반으로 갈릴만큼 쉽게 결정내릴 수 있는 사항이 아니였다.

그러다 최종 프로젝트를 하기 전,

next.js의 앱 라우터를 활용하여 투두리스트를 디벨롭해보는 1주일의 시간을 팀원들끼리 가졌던 적이 있는데 그게 바로 4번이다.

앱 라우터란??
next.js 13에서 업데이트된 내용으로써,
기존에 pages/ 디렉토리에서 라우팅 되던 방식과 다르게,
app/ 디렉토리로 라우팅하는 방식이 추가 되었다.
app/ 디렉토리를 생성하여 라우팅을 설정할 수 있으며,
라우팅 환경 개선뿐 아니라, 레이아웃, 서버 컴포넌트, 스트리밍, 데이터 패칭까지도 지원하는 형태로 향상

Layout:리렌더링 방지를 위한 레이아웃제공

Server Component: app 디렉토리 내 파일은 디폴트로 서버 컴포넌트로 동작

Streaming: app 디렉토리는 렌더링되는 UI단위를 점진적으로 렌더링 & 스트리밍 할 수 있는 기능 제공

Data Fetching지원:fetch() Web API를 사용할 수 있게 되어, 컴포넌틑 레벨에서도 SSR 적용 가능

그러나 page router에 비해 app router가 상대적으로 커뮤니티 형성이 많이 되어 있지 않았고, 참고사항도 없이 구현하기가 생각보다 어려웠었다.

그러다보니 최종 프로젝트에서 공부하면서 구현을 하자니 코드 퀄리티 뿐만 아니라 전반적인 기능 및 완성도가 떨어질 것이라 판단하여 우리가 가장 잘 할 수 있는 React+typescript로 택하게 되었다.

5번도 앞서말한 이유로 중요하다 여겼는데, 우리가 노렸던건 전체 프로젝트에서 3위안에 들고싶었었고, 결과는 실패했었다.

수 많은 프로젝트에서 우리는 분명 더 많은 기능을 넣었겠지만, 애초에 기획 자체가 책에 관련된 것이다보니 대중성을 잡기보다는 책에 관심 있는 사람들에게만 흥미가 있는 프로젝트였고, 개발자 관점에서 바라보자니 좀 더 어려운 기술을 택하지 않았던게 기술적 메리트도 없던 프로젝트가 아니였을까..?