원래는 React.js로 프로젝트를 진행하려했다.
모바일 청첩장 편집 화면은 실시간으로 미리보기를 갱신하고 구성을 바꾸는 인터렉티브한 서비스다.
그래서 처음에는 SPA 형태로 설계하기 쉬운 React.js가 적합하다고 생각했다.
그런데 Next.js가 더 적합하다고 판단했다
처음엔 편집기 중심으로만 생각했는데, 기획을 구체화 시키면서 "실제로 내가 사용한다면? 누군가에게 초대하는 것이고.. 그러면 링크 공유가 메인 아닌가?"라는 생각이 들었다.
"모바일 청첩장 = 공유 가능한 초대장 페이지" 이때부터는 Next.js가 훨씬 적합하다고 판단했다.
이유 1. 초대장 링크 공유 시 메타정보(OG) 처리
청첩장은 대부분 카카오톡, 메시지, SNS 등에서 공유된다.
이때 미리보기 카드(제목, 이미지, 설명)가 제대로 표시되려면 서버 사이드에서 OG 메타 태그를 렌더링해야 하는데, React는 CSR(Client-Side Rendering)이라 이 처리가 어렵다.
Next.js는 SSR/SSG로 페이지를 사전에 렌더링하므로 각 초대장마다 맞춤형 미리보기를 손쉽게 설정할 수 있다.
이유 2. 이미지 최적화와 퍼포먼스
갤러리나 프로필 이미지처럼 이미지 리소스가 많은 서비스에서는 next/image의 자동 리사이징·WebP 변환·Lazy Loading 기능이 로딩 속도를 개선하고 트래픽을 절감하는 데 큰 도움이 된다.
이유 3. 편집기와 공개 페이지를 한 프로젝트에서 관리
Next.js는 클라이언트용 페이지(편집기)와 공개용 페이지(초대장), 그리고 임시저장·발행용 API(/api/~)를 한 코드베이스 안에서 통합 관리할 수 있다.
React에서는 이를 구현하려면 별도의 백엔드 서버를 추가로 구축해야 하는데, Next는 app/api 또는 Server Actions로 이를 해결할 수 있다.
이유 4. 배포와 유지보수의 단순화
Vercel에서 배포 시, 초대장 페이지는 SSG(Static Site Generation) 혹은 ISR(Incremental Static Regeneration)으로 정적 빌드되고, 편집기 화면은 CSR(Client Side Rendering)로 동작하게 할 수 있다.
즉, 하나의 도메인 안에서 서버와 클라이언트가 공존할 수 있어 별도의 배포 파이프라인을 만들 필요가 없음.
