Next.js 16으로 개인 포트폴리오+기술 블로그 아키텍처 설계하기

개인 웹사이트를 만들 때 가장 많이 하는 고민은 "예쁘게 만들기"가 아니라 계속 운영 가능한 구조로 만들기다.
이번 프로젝트에서는 Next.js 16(App Router) 기반으로 포트폴리오와 기술 블로그를 한 레포에서 운영하면서, 다국어 지원과 검색 노출, 작성 생산성까지 같이 챙기는 방향으로 설계했다.

---

목표: 한 번 만들고 오래 쓰는 개인 사이트

이 프로젝트에서 잡은 핵심 목표는 단순했다.

1. 콘텐츠 중심 운영: 글 작성은 마크다운(MDX)로 빠르게
2. 확장 가능한 정보 구조: 블로그와 프로젝트를 일관된 방식으로 관리
3. 기본기 자동화: i18n, SEO, sitemap, robots를 코드 레벨에서 처리

즉, "페이지를 만들기 쉬운 구조"보다 "콘텐츠를 쌓기 쉬운 구조"를 우선했다.

---

기술 스택 선택 이유

• Next.js 16 + App Router: 라우팅/메타데이터/서버 컴포넌트 흐름이 명확해서 콘텐츠 사이트에 유리
• TypeScript: 콘텐츠 메타 스키마와 렌더링 로직의 안정성 확보
• Tailwind CSS v4: 디자인 변경 속도와 유지보수 비용 밸런스
• MDX: 글 안에서 컴포넌트를 재사용할 수 있어 표현력이 높음
• Vercel 배포: 빌드-배포 파이프라인 단순화

개인 프로젝트는 "최신 기술"보다 운영 피로도가 낮은 조합이 더 중요하다.

---

폴더 구조에서 얻는 운영 효율

src/content/posts와 src/content/projects를 분리하고, 파일명 규칙을 {slug}.{lang}.mdx로 통일했다.

예를 들면 이런 형태다.

• nextjs-architecture.ko.mdx
• nextjs-architecture.en.mdx

이 규칙 하나로 얻는 이점이 꽤 크다.

• 언어별 콘텐츠 매핑이 단순해진다
• 슬러그 기준 링크/라우팅 처리 로직이 예측 가능해진다
• 번역 누락 파일을 찾기 쉬워진다

---

다국어(i18n) 전략: 자동 감지 + 명시적 경로

브라우저 언어를 감지해 기본 언어를 제안하되, URL에는 언어 세그먼트([lang])를 명시적으로 둔다.
이 방식은 UX와 SEO를 동시에 챙길 수 있다는 장점이 있다.

• 사용자 입장: 처음 방문 시 자연스럽게 맞는 언어로 진입
• 검색엔진 입장: 언어별 페이지가 분리되어 인덱싱이 명확

다국어를 붙일 때 가장 많이 망가지는 부분이 라우팅인데, 초기에 경로 규칙을 고정하면 이후 비용이 크게 줄어든다.

---

MDX 기반 글 작성 경험

MDX를 쓰면 단순 텍스트를 넘어 표현을 컴포넌트화할 수 있다.
이 프로젝트에서는 BlogImage, ImageGallery, CodeBlock, Giscus 같은 컴포넌트를 공통으로 제공해서, 글 작성자는 콘텐츠 자체에만 집중할 수 있게 했다.

결과적으로 "페이지 개발"과 "글쓰기"의 경계가 줄어들고, 문서 생산성이 올라간다.

---

SEO는 기능이 아니라 기본 인프라

개인 사이트는 트래픽 규모가 크지 않아도 검색 유입의 질이 중요하다.
그래서 메타데이터, Open Graph, JSON-LD, sitemap, robots를 별도 작업이 아니라 기본 인프라로 포함했다.

핵심은 한 번 잘 세팅해두고, 글을 올릴 때는 제목/요약/키워드만 관리하면 되게 만드는 것이다.

---

댓글 시스템은 Giscus로 가볍게

DB를 직접 운영하지 않고 GitHub Discussions 기반 Giscus를 붙였다.
개인 블로그에서는 이 선택이 특히 효율적이다.

• 인증/권한/운영 부담이 작다
• 개발자 독자층과 궁합이 좋다
• 콘텐츠와 토론의 연결이 자연스럽다

---

마무리: 개인 사이트도 결국 제품이다

포트폴리오 사이트를 "한 번 만드는 결과물"로 보면 유지가 어렵고 금방 낡는다.
반대로 "지속적으로 업데이트하는 제품"으로 보면, 아키텍처 결정 기준이 명확해진다.

이 프로젝트는 그런 관점에서 설계한 개인 웹사이트다.
앞으로도 새로운 글과 프로젝트를 빠르게 추가하면서, 구조는 안정적으로 유지하는 게 목표다.