공식문서와 프로젝트 로그인 및 UI를 구현하며 next.js를 이번 기회에 더 깊이 알아보았다. next.js로 프로젝트를 진행하면서 우리가 만드는 웹 서비스 (목표 달성 웹 서비스)가 서버 사이드 렌더링이 필요할까 하는 의문이 계속 들었다. 당연히 Js의 bundle 크기를 줄이면 좋을 것이고, 이미지도 Next에서 제공해주는 Image 컴포넌트를 사용하면 좋을 것이고 static한 데이터들을 캐싱하고 next·JS에서 제공해주는 여러 기능들을 사용하면 좋을 것이다. 더 나아가 컴포넌트 단위의 렌더링을 이번 13.4 버전에서는 제공해주니 잘만 사용하면 더 효율적이고 빠른 UX 경험을 선사하는 웹 서비스가 될 것이지만!!!
개인적인 소견으론 리액트를 사용하여 부드러운 웹앱을 만드는 게 훨씬 나은 선택지인 것 같다고 판단했다.
이유는 다음과 같다.
JS의 번들 크기 문제 : 생각보다 크지 않은 웹 서비스이기에 번들 크기는 걱정하지 않아도 된다. 하지만 확장하여 나중에 서비스가 커지면 그때 Next.js로 마이그레이션 하면 될 것 같다.
SEO 불리 : 우리의 서비스를 생각해보면 landing page만 구글과 네이버 상단에 등장하면 된다. 모든 페이지를 검색 엔진에 최적화할 필요는 없다고 생각된다. 그래서 react의 라이브러리 중 react-helmet이나 react-snap을 사용해서 해결하면 될 것 같다.
이미지 최적화 : 이 부분은 기본적인 alt를 잘 넣어주고 찾아서 이미지를 S3에 올려 cache 하는 방식으로라도 이미지를 최적화할 생각이다. 아니라면 CDN 서버를 사용할 수도 있고 정적 파일의 용량을 줄일 수 있다. 굳이 next.js의 Image 컴포넌트를 사용하기 위해 Next.js를 사용할 필요는 없다고 생각한다.
초기 로딩 속도 : JS 번들 크기가 크면 React·lazy와 Suspense 리액트의 라이브러리와 업데이트된 개념을 활용해서 코드를 초기 렌더링시 split 하면 될 것 같다.
Next-auth : next-auth는 기본적으로 서버리스를 지향한다. 그래서 next.js 프론트 서버를 통해 간편 소셜 로그인을 구현할 수 있다. 하지만 이번 알리고 올리고 프로젝트는 자바 스프링 프레임워크로 만들어진 서버가 있으며 굳이 또 다른 서버를 프론트에 만들어야 하는지에 대한 의문이 들었다. 또한 이런 서버도 비용이라 생각하여 react로 기본적인 로그인과 조금 복잡할 수 있지만 정석적인 소셜 로그인을 구현하는 게 나을 것 같다고 생각했다.
MVP : 목표 달성 웹 서비스를 사람들이 사용할지 모르는 상황에서 MVP를 만드는데 있어 굳이 Next.js를 활용하여 성능까지 신경써 완벽하게 만드는 것보다 react를 활용하여 사람들이 찾는 서비스인지 가설 검증이 이루어진 후, 필요할 경우, Next.js로 마이그레이션 해도 좋을 것 같다고 생각했다.