Intro

최근 참여중인 프로젝트에서 랜딩페이지를 개발해서 배포하는 업무를 진행중입니다.
백오피스는 Vite + React 를 활용해 개발중이지만, 랜딩 페이지는 SEO 최적화를 위해 SSR 을 활용하면 좋겠다 생각했고, Next.js 프레임 워크를 선택했습니다.

라우터 선택

Next.js 에는 현재 두 가지 방식으로 개발이 가능합니다. Pages router, App router 입니다. 저는 그 중 Pages router 을 선택을 했습니다.

왜!?

최근 14버전이 릴리즈 됐지만 아직 App router 에 대한 레퍼런스가 부족하다고 생각했습니다. 프로젝트 또한 랜딩 페이지기 때문에 Pages router 로 작성된 코드를 App router 로 리팩토링 해야할 경우 공수가 크지 않다고 생각했습니다. 현 시점에서는 Pages router 로 코드를 작성하고 추후 App router 에 대한 충분한 레퍼런스가 생기고 Pages router 를 더 이상 지원하지 않는다면 리팩토링 하기로 결정했습니다.

라우터 선택 시 고려 했던 내용

Pages router 을 사용할 경우

• 경험이 있는 라우터이기에 빠르게 개발할 수 있음
• 사용하고자 하는 라이브러리 중 호환이 안되는 라이브러리가 없음
• 최신 라우터인 App router 가 나온 상황이고 최신 React 기능을 App router 가 지원하기 때문에 프로젝트가 커진 상황에서 리팩토링을 한다면 공수가 많이 들어갈 가능성을 인지해야함

App router 을 사용할 경우

• style 라이브러리인 Emotion 은 App router 을 아직 지원하지 않습니다.

• MUI 도 내부에서 Emotion 을 사용하고 있기 때문에 App router 과 호환이 어려울수도 있습니다. (방법이 있는지 찾아봐야합니다..)

• 만약 React 의 최신 기능인 서버 컴포넌트를 사용하고 싶다면 App router 을 선택하는 것이 좋아보이네요!

• 14 버전에서 Server action 으로 출시된 기능은.. 제가 만약 현업에서 개발중인 프로젝트라면 사용하지 않을것 같습니다. 프론트 단에서 커넥션을 직접 연결해서 쿼리를 날리는 것 같은데 보안 상 문제가 없을까 하는 생각이 있습니다. (지극히 개인적인 의견입니다.)

배포

배포에는 두 가지 선택지를 고민했습니다. 현재 마미든든의 인프라는 MSA 구조로 AWS ECS에 배포된 상태입니다. 인프라를 구축하신 개발자께서 파드 하나 추가될때마다 한 달에 4-5만원의 비용이 과금된다고 했고, 파드간 통신이 필요하지 않기 때문에 AWS 에 배포한다면 EC2 위에 Next 프로젝트를 실행하는 형식으로 배포할 예정이었습니다.

하지만 EC2 위에 배포한다면 github actions, code deploy 를 통해 CI/CD 자동화를 구축 해야하고 고려해야 할 부분들이 어느정도 있었습니다. 프론트엔드 개발자도 혼자인 상태에서 백오피스를 개발하면서 해당 작업을 한꺼번에 하기에 부담이 되는 상황입니다.

그래서 두 번째 선택지인 Vercel 호스팅을 선택했습니다. Vercel 은 Next 프레임워크를 만든 회사이고 PaaS 를 제공해줌으로써 프론트엔드 프로젝트를 아주 쉽게 호스팅 할 수 있게 도와줍니다.

Github 에 연결을 하면 호스팅 된 프로젝트의 main 브랜치에 머지 될 때 마다 자동으로 CI/CD 해주고 PR 을 날리면 머지하기 전 pre-building 을 통해 미리 프로덕션 페이지를 확인할 수 있게 해줍니다.

Out

다음 포스팅에서는 Vercel 에 호스팅하고 AWS Route 53 도메인에 레코드를 등록하는 과정을 살펴보겠습니다.