Next.js App Router 블로그 MVP 설계

도입

블로그 MVP는 빠르게 출시하는 것이 목표지만, 초기 구조를 잘못 잡으면 기능이 늘어날수록 콘텐츠 처리, SEO, 배포 안정성이 함께 무너진다. App Router는 서버 컴포넌트 중심 개발에 유리하지만, 라우트 파일에 비즈니스 로직이 몰리기 쉬운 구조이기도 하다.

이 글은 App Router 기반 MVP를 Clean Architecture 레이어 분리로 설계해, 출시 속도와 확장 가능성을 동시에 확보하는 방법을 다룬다.

문제 정의

초기 MVP에서 자주 생기는 문제는 다음과 같다.

app/** 라우트 파일에 데이터 접근/검증/가공 로직이 섞임
SEO 메타데이터 생성 규칙이 페이지마다 분산됨
콘텐츠 파싱 실패가 런타임에서만 드러남
배포 파이프라인은 통과했지만 실제 페이지 데이터가 불완전함

핵심은 "라우팅"과 "유스케이스"를 분리하고, 콘텐츠 모델을 단일 경로로 유지하는 것이다.

개념 설명

MVP에서 필요한 최소 레이어

레이어	책임	파일 예시
Presentation	route/page 구성, 요청/응답 바인딩	`app/posts/[slug]/page.tsx`
Application	유스케이스, 정렬/필터 정책	`lib/application/get-post-list.ts`
Domain	포스트 모델, 태그 규칙, 날짜 정책	`lib/domain/post.ts`
Infrastructure	파일 읽기, MDX 파싱, 배포 연동	`lib/posts.ts`

MVP 기능 범위

콘텐츠: content/posts/*.mdx
라우트: /, /posts, /posts/[slug], /tags, /about
SEO: generateMetadata + sitemap + rss
검증: 빌드 단계 frontmatter 체크

코드 예시

예시 1: Route Handler에서 유스케이스 호출

import { getPostListUseCase } from "@/lib/application/get-post-list";

export default async function PostsPage() {
  const posts = await getPostListUseCase({
    sortBy: "date_desc",
    limit: 20,
  });

  return <PostList posts={posts} />;
}

예시 2: Application 계층에서 경계 고정

import { postRepository } from "@/lib/infrastructure/post-repository";

type Params = {
  sortBy: "date_desc" | "date_asc";
  limit: number;
};

export async function getPostListUseCase(params: Params) {
  const items = await postRepository.findAll();
  const sorted = [...items].sort((a, b) =>
    params.sortBy === "date_desc"
      ? new Date(b.date).getTime() - new Date(a.date).getTime()
      : new Date(a.date).getTime() - new Date(b.date).getTime(),
  );

  return sorted.slice(0, params.limit);
}

아키텍처 설명

App Router MVP에서는 요청 흐름과 콘텐츠 흐름을 별도로 보아야 한다.

Mermaid diagram rendering...

Clean Architecture 레이어 구조

실무에서 유지보수 가능한 MVP를 만들려면 아래 경계를 명확히 유지해야 한다.

Presentation: 라우팅, 사용자 입력 바인딩, 페이지 단위 조합
Application: 유스케이스 오케스트레이션, 정렬/필터링 정책
Domain: 핵심 규칙(태그/날짜/slug 정책), 타입 불변성
Infrastructure: 파일 시스템 접근, MDX 파싱, 외부 플랫폼 연동

인프라 구성도