이번 프로젝트에서는 우리는 React만 사용하는 방법을 채택했어요.
그렇다면 왜 Next.js를 사용하지 않았을까요?

먼저, Next.js의 장점과 이를 도입했을 때 어떤 점이 유리할 수 있었는지를 살펴본 뒤,
우리 팀의 상황에 맞춰 어떤 판단을 했는지를 설명드리겠습니다.

---

✅ Next.js의 주요 장점

Next.js는 React 기반의 프레임워크로, 다음과 같은 강력한 기능들을 제공합니다

• SSR을 통해 페이지를 서버에서 렌더링하여 초기 로딩 속도가 빠르고 SEO에 유리해요.
• SSG를 통해 정적 페이지 생성을 통해 매번 서버에 데이터 요청을 날리지 않아도 되어 빠른 응답 속도와 높은 캐싱 효율을 가질 수 있어요.
• 파일 기반 라우팅을 통해 디렉토리 구조만으로 라우팅이 자동 구성돼요.
• 이미지 최적화, 미들웨어 등 최신 기능을 지원해요.

만약 우리가 Next.js를 도입했다면 다음과 같은 이점이 있었을 것 같아요

• 우리는 체험을 소개하고, 사용자가 예약 및 후기를 남기는 서비스예요.
• 각 체험의 상세 페이지를 SSG / SSR로 구성함으로써,
  → 검색 엔진에 더 잘 노출되어 사용자 유입 경로를 늘릴 수 있었고,
  → 초기 페이지 로딩을 서버에서 미리 처리함으로써,
  → 모바일 환경이나 느린 네트워크에서도 빠른 반응성을 제공할 수 있었을 거예요.

---

❌ 우리가 Next.js를 선택하지 않은 이유

CSR의 단점을 보완하기 위한 고민을 했어요.

CSR의 대표적인 단점은
👉 초기 로딩 시 JS 번들 크기에 따라 흰 화면이 뜰 수 있다는 거예요.

이를 고려해 우리는 라이브러리 사용을 최소화하려고 노력하기로 했고,
초기 번들 크기를 줄이기 위해 여러 시도를 했어요.

즉, 초기에 번들 크기를 최소화시키면,
초기 로딩 속도가 느리다는 CSR의 문제를 어느 정도 해결할 수 있을 것이라고 판단했어요.

또한, 이미지 최적화를 적용해봤어요.
Next.js를 사용하면 이미지 최적화가 자동으로 되지만,
React만 사용했기에 직접 이미지 최적화를 통해

• LCP 성능: 25.1초 → 5.5초로 약 78% 감소
• Speed Index 성능: 13.3s → 5.7s로 약 57% 감소

👉 성능 개선 경험을 해볼 수 있었어요.
이미지 크기를 줄이고 싶어요

---

이미 백엔드 API가 구축되어있어요.

우리 프로젝트의 백엔드는 이미 별도로 존재했고,
우리는 Swagger 문서를 기반으로 다음과 같은 방식으로 데이터를 주고받았어요.

• GET: 정보 조회
• POST: 새 데이터 생성
• PATCH: 데이터 수정
• DELETE: 삭제 요청

Next.js의 API Routes 기능을 사용할 이유가 없었어요.
프론트엔드 역할에 집중해야 했던 만큼,
SSR / SSG를 활용한 서버 컴포넌트 구성보다
UI / UX 완성도와 협업 중심 개발에 더 초점을 맞췄어요.

---

기술 도입의 현실성을 고려했어요.

우리 팀은 다양한 학습 수준의 구성원으로 이루어져 있었고,
Next.js 도입 시 팀 전체의 이해도와 숙련도에 따라 기술 부채가 생길 수 있다고 판단했어요.

과거 중급 프로젝트에서 Next.js를 충분히 활용하지 못했던 경험이 있었어요.

Next.js는 분명 좋은 프레임워크이지만,
우리는 이번 프로젝트에서
👉 실제로 필요한 기술
👉 팀이 안정적으로 사용할 수 있는 범위에 집중하는 판단을 했어요.

---