서론

처음에는 React로도 포트폴리오를 만들 수 있다고 생각했다. 실제로 UI 자체는 React만으로도 충분히 구현 가능했다.
하지만 “포트폴리오”라는 성격상 보여주는 방식(SEO, 초기 로딩, 정적 배포, 데이터 관리) 이 더 중요했고, 시간이 지나면서 이런 요구들이 하나씩 쌓였다.

이 글은 “Next.js가 좋아서”가 아니라, 내가 마주친 문제들을 해결하는 과정에서 어떤 Next 기능을 적용했고, 그 결과 왜 Next.js를 선택하게 되었는지를 정리한 회고다.

본론

1) 문제: 페이지가 늘어나며 라우팅/레이아웃 중복이 커졌다

• About, Projects, Blog, Skills처럼 섹션이 늘어나면서 라우팅이 복잡해지고
• 공통 레이아웃(헤더/메타/전역 스타일) 중복이 늘었다

적용: App Router + 중첩 레이아웃

이 프로젝트는 Next.js App Router 구조로 라우트를 구성했고, 레이아웃을 경로 단위로 나눠 재사용할 수 있게 만들었다.
결과적으로 “페이지를 추가할 때마다 라우팅/공통 UI를 다시 붙이는” 비용이 줄었다.

---

2) 문제: 블로그/프로젝트는 SEO와 공유(OG)가 핵심인데, SPA만으로는 한계가 있었다

블로그 글은 검색 유입과 공유가 중요하다. 그런데 SPA로만 구성하면,

• 검색 엔진이 콘텐츠를 제대로 수집하기 어렵거나
• 공유 시 OG 이미지/설명이 안정적으로 나오지 않는 문제가 생길 수 있다.

적용: SSG(정적 생성) + 동적 라우트

이 프로젝트의 블로그는 /blog/[slug] 형태의 동적 라우트를 사용하면서도, 빌드 시점에 정적으로 생성(SSG)되도록 구성되어 있다.
즉, “동적 주소를 갖는 글”이면서 “정적 페이지로 미리 만들어지는 글”이 된다.

적용: Metadata 기반 메타 태그 구성

공유/SEO에 필요한 메타 정보를 Next의 메타데이터 방식으로 관리하면서, 페이지별 제목/설명을 안정적으로 만들 수 있었다.

---

3) 문제: 데이터가 흩어지고, 프론트에서 처리해야 할 일이 늘어났다

블로그 목록, 태그/시리즈, 프로젝트 목록 같은 데이터는 UI와 분리되어야 관리가 쉽다.
React SPA에서는 “어디서 데이터를 만들고, 어디서 가공해서 내려줄지”를 팀/프로젝트마다 다르게 만들기 쉽다.

적용: Route Handlers(API Routes)

이 프로젝트는 /api/blog, /api/projects 같은 API 엔드포인트를 함께 운영한다.
페이지는 UI를 담당하고, 데이터 가공/응답은 API가 담당하도록 분리하면서 “데이터를 어디서 책임지는지”가 명확해졌다.

---

4) 문제: 초기 로딩 성능과 이미지 최적화가 필요했다

포트폴리오는 이미지가 많고, 첫 인상이 곧 UX다.
하지만 이미지는 용량이 크고, 최적화를 놓치면 LCP가 쉽게 느려진다.

적용: next/image

이 프로젝트는 next/image를 사용해 이미지 로딩/사이즈를 최적화하고, 화면 크기별로 sizes를 지정해 불필요한 비용을 줄였다.

---

5) 문제: “인터랙션(클라이언트)”과 “콘텐츠(서버/정적)”가 섞이면 복잡도가 급격히 올라간다

모달, 애니메이션, 상태 관리처럼 브라우저에서만 필요한 기능은 클라이언트에서 돌아가야 한다.
반면, 콘텐츠 중심 페이지는 가능한 한 가볍게 유지하는 편이 좋다.

적용: "use client"로 경계 분리

이 프로젝트에서는 필요한 컴포넌트에만 "use client"를 선언해서, 인터랙션이 필요한 영역과 그렇지 않은 영역의 경계를 명확히 했다.
이 과정 자체가 “어디까지가 UI이고, 어디부터가 데이터/콘텐츠인가”를 다시 생각하게 만들었다.

---

6) 개발 경험: 빌드/개발 파이프라인이 안정적이어야 꾸준히 개선할 수 있다

프로젝트는 결국 “계속 고치는 것”이 핵심이다.
DevServer가 빠르고, 빌드/타입체크가 안정적으로 돌아가야 개선이 습관이 된다.

적용: Next.js 빌드/타입체크 플로우 + Turbopack

Next 빌드 과정에서 타입 체크와 정적 생성이 함께 돌아가고, 개발 서버도 빠르게 반응하는 구조라서 개선 사이클이 짧아졌다.

결론

그래서 왜 Next.js였나

정리하면, 내가 Next.js를 선택한 이유는 “React를 대체하기 위해서”가 아니라, 포트폴리오/블로그라는 요구를 가장 적은 비용으로 만족시키기 위해서였다.

• App Router: 라우팅/레이아웃 중복을 줄이고 구조를 단순하게 유지
• SSG + 동적 라우트: 블로그/프로젝트를 검색/공유 친화적으로 제공
• Route Handlers: 데이터 가공/응답을 UI와 분리해 유지보수성을 확보
• next/image: 이미지 중심 사이트에서 성능을 기본값으로 끌어올림
• 클라이언트/콘텐츠 경계 분리: 인터랙션은 가볍게, 콘텐츠는 안정적으로

결국 Next.js는 “새 기술을 써보고 싶어서”가 아니라, 내가 해결해야 했던 문제들의 합을 가장 현실적으로 해결해 준 선택지였다.