Next.js로 사이드 프로젝트를 진행하면서 느꼈던 것들을 글로 정리해보았습니다.

Why Next.js?

시장의 흐름에서 React의 서버사이드 렌더링을 위한 프레임워크로 Next.js가 대세를 이루고, 백엔드 API까지 아우르는 방향으로 발전하고 있기 때문에 공부해 볼 가치가 있다고 생각했습니다.

What?

복잡한 기능보다는 간단하면서 빠르게 만들어 볼 수 있는 기능으로 만들고자 했습니다. 그래서 Todo 앱을 만들었습니다.
Todo 생성/수정/삭제 기능을 가지는 아주 심플한 앱입니다. (프로젝트 링크)

How?

다음 기술 스택을 기반으로 프로젝트를 진행했습니다.

사용한 기술 스택:

• 프론트엔드: Next.js
• 인증: Google OAuth
• 데이터베이스: AWS DynamoDB

주요 특징:

• Next.js의 API 라우터를 활용하여 별도의 백엔드 서버 없이 구현
• Vercel을 통한 서버리스 배포로 간편한 운영 환경 구축

Review

Next.js를 사용하면서 개인적으로 느낀 경험들 위주로 작성했습니다.

• 장점

- 손쉬운 서버사이드 렌더링: Next.js 없이 서버사이드 렌더링을 구현하려면 많은 수고가 듭니다.
예를 들어 직접 하이드레이션 최적화를 위한 방법을 강구해야하고 HTML을 스트리밍 방식으로 전달하는 서버를 구축해야 합니다.
- 작은 번들사이즈: 서버 사이드 렌더링을 한다는 것은 클라이언트의 js 크기가 작아짐을 의미합니다. 그래서 웹뷰와 같이 번들 사이즈에 민감한 곳에는 좋은 선택이 될 수 있습니다.
- API 라우팅 지원: 별도의 백엔드 서버를 구성하지 않아도 되는것이 너무 편했습니다. 하나의 레포지토리 안에서 백엔드와 프론트 코드를 한번에 다룰 수 있기에 생산성이 극대화 되었습니다.
- 민감한 정보 가리기: 요즘 개발자 도구를 통해 많은 데이터를 유저가 디버깅 할 수 있습니다. 데이터의 보안에 민감한 앱일 경우 이런 정보들을 서버 사이드에서 렌더링하여 보여주면 민감한 정보를 유저에게 노출하지 않을 수 있었습니다.
- 훌륭한 문서: 문서는 아주 중요한 요소입니다. 개발 간의 적절한 기능과 이슈를 해결하려면 잘 정리된 문서가 있어야 하기 때문입니다. 이런 면에서 Next.js는 기존 페이지 라우터 방식의 문서와 많은 기능들에 대해서 잘 정리 되어있는 문서를 갖추고 있습니다.

• 단점

- 코드의 파편화: 기본적으로 Next.js 컴포넌트는 서버 컴포넌트이기 때문에 useState와 같은 기능을 사용하려면 클라이언트 컴포넌트로 선언해야 합니다. 이는 유저의 이벤트나 비즈니스 로직이 존재하는 영역은 클라이언트 컴포넌트로 분리되어야 함을 의미하며, 이에 따라 많은 코드가 불필요하게 파편화되는 경향이 있습니다.
- 상태관리: 서버 컴포넌트의 이점을 누리려면 클라이언트 컴포넌트의 상태를 서버 컴포넌트에서 프리패치해야 합니다. 그렇게 서버 컴포넌트와 클라이언트 컴포넌트 상태가 공유될 수 있는데, 이러한 코드들은 코드의 복잡도를 높이고 서버와 클라이언트 컴포넌트의 경계를 개발자가 항상 인지해야 하기 때문에 개발 경험에 좋지 않았습니다.
- 기본은 서버 컴포넌트: 별도로 명시하지 않으면 기본적으로 서버 컴포넌트로 동작합니다. 기능이 많은 앱을 개발할 때는 클라이언트 컴포넌트로 선언해야 하는 경우가 많아, 많은 컴포넌트들이 클라이언트 컴포넌트로 선언됩니다. 이렇게 되면 Next.js를 사용하는 이점이 점차 줄어들 수 있습니다.
- 잦은 업데이트: 대부분의 프레임워크는 버전 업데이트 시 많은 변경 사항이 발생합니다. Next.js도 예외는 아니며, 실제로 Next.js 13+ 버전과 이전 버전 간의 차이가 큽니다. 버전에 따라 기존 코드가 동작하지 않을 수 있어 주의가 필요합니다.

작은 번들사이즈/높은 데이터 보안을 추구하며 높은 정적 페이지의 비율을 가진
앱이라면 Next.js를 사용하기에 적합하다고 느꼈습니다. 그 이외의 영역에서는
오버스펙이 될거라 생각되었으며 React만으로도 충분히 좋은 앱을 만들 수 있다고
생각합니다.