1인 기업 프런트엔드 스택: Astro, Next.js, React, Tailwind, shadcn/ui 선택법

프로젝트에 /blog, /tools/image-resizer, /dashboard/settings, /pricing 네 종류의 페이지가 있습니다. 모두 Next.js에 넣을지, Astro 블로그와 Next.js 대시보드로 나눌지 애매합니다. 이미 운영 중인 Astro 블로그에 로그인, 결제, 기록을 추가하려면 이전을 고민하게 됩니다. 반대로 Markdown 20개뿐인 Next.js 프로젝트도 캐시, Server/Client Components, 배포 설정을 이해해야 합니다.

1인 기업의 프런트엔드 선택은 최고의 프레임워크를 고르는 대회가 아닙니다. 페이지 유형, 동적 데이터, 유지보수 비용이 프레임워크와 저장소 경계, 복사한 shadcn/ui 코드의 책임을 결정합니다. Astro islands가 충분한 때, App Router 비용이 이점보다 큰 때, React + Vite가 더 단순한 때를 구분해야 합니다.

백엔드, 배포, 데이터베이스, 결제와 인증은 후속 글에서 다룹니다.

프레임워크 선택표

인기보다 페이지 유형에서 시작합니다.

페이지 유형	동적 데이터	유지보수	권장 출발점	예시
콘텐츠, 블로그, 문서	낮음, Markdown/YAML	낮음	Astro 우선	블로그, 제품 문서, landing page
독립 도구	중간, 클라이언트 상태	중간	React + Vite 또는 Astro islands	이미지 압축, JSON 포매터, Markdown 편집기
SaaS 대시보드	높음, 사용자와 API	높음	Next.js App Router	설정, 주문, 분석
상호작용 제품	높음, 클라이언트 라우팅과 실시간	높음	Next.js 또는 React + Vite	협업, 채팅, 편집기
마케팅과 가격	낮음, 정적	낮음	Astro 또는 Next.js SSG	/pricing, /features, /about

한 제품에 여러 페이지 유형이 있을 때

콘텐츠 80%, 대시보드 20%라면 Astro를 중심으로 두고 React islands나 별도 Next.js 앱을 붙일 수 있습니다.

애플리케이션 80%, 블로그 20%라면 Next.js가 제품을 맡고 블로그를 정적으로 생성할 수 있습니다.

반반이라면 Astro 콘텐츠 앱과 Next.js 대시보드 앱으로 경계를 명확히 합니다. monorepo 안에서도 이 경계를 유지할 수 있습니다.

두 앱은 의존성과 배포를 늘리지만 한 화면의 캐시 규칙이 전체 페이지에 퍼지는 것을 막습니다.

유지보수 비용 주의

Next.js 캐시, Server/Client 경계, Vercel, Cloudflare, 자체 서버 차이는 검증이 필요합니다. 동적 페이지가 적다면 Astro나 React + Vite가 더 저렴할 수 있습니다.

Astro와 Next.js 비교에서 아키텍처를 더 자세히 볼 수 있습니다.

콘텐츠 사이트: Astro와 Islands 아키텍처

Astro는 블로그, 문서, 마케팅 등 콘텐츠 중심 사이트에 맞습니다. server-first와 zero JS by default는 HTML을 빌드나 서버에서 만들고 명시한 상호작용 컴포넌트만 브라우저 JavaScript를 불러온다는 뜻입니다.

Content collections는 Markdown과 구조화 데이터를 조직하고 검증하며 타입을 제공합니다. frontmatter와 날짜, 태그, 분류 조회를 빌드에서 확인할 수 있습니다.

Islands: 정적 HTML과 국소 상호작용

대부분은 HTML로 두고 작은 상호작용 영역만 island로 만듭니다. client:load나 client:visible로 로드 시점을 정합니다.

전송 버튼만 client:load React 컴포넌트로 만들 수 있습니다.

테마 전환은 localStorage를 읽고 CSS 변수를 바꿉니다.

이미지 뷰어는 client:visible까지 기다릴 수 있습니다.

폼 하나 때문에 페이지 전체를 hydration하지 않아도 되는 것이 장점입니다.

Astro가 전부 맡지 말아야 할 때

거의 모든 경로가 신원을 확인하고 비공개 데이터를 읽으며 큰 공유 상태와 복잡한 클라이언트 라우팅을 요구한다면 Astro가 자동으로 단순한 선택은 아닙니다. 인증 island로 가득한 대시보드는 Next.js나 별도 React 앱이 자연스럽습니다.

Astro 5 Lighthouse 사례는 collections와 islands의 실제 구성을 다룹니다.

도구와 상호작용 제품: React + Vite vs Next.js

도구는 보통 한 동작에 집중하고, 상호작용 제품은 여러 경로, 공유 상태, 협업이나 편집기를 추가합니다.

React + Vite가 맞을 때

서버 렌더링이 없는 클라이언트 SPA나 독립 도구에 맞습니다.

이미지 압축기는 브라우저에서 파일을 처리합니다.

JSON 포매터는 입력을 로컬에서 분석합니다.

Markdown 편집기는 편집, 미리보기, localStorage를 결합합니다.

정적 배포와 Next.js 캐시 경계가 없다는 점이 단순합니다. 검색 유입이 중요하면 클라이언트 SPA에 별도 SEO 전략이 필요합니다.

Next.js가 맞을 때

서버 렌더링, 여러 경로, 혼합 렌더링이 필요할 때 유용합니다.

홈, 도구, 결과를 각각 렌더링된 경로로 만들 수 있습니다.

설명 페이지는 SSG나 SSR로 색인될 수 있습니다.

소개는 정적이고 비공개 결과는 동적으로 만들 수 있습니다.

React + Vite를 고르는 조건

핵심 동작이 Browser APIs, localStorage, Canvas로 끝납니다.

Node.js 없이 정적 파일로 배포합니다.

Next.js routing, 캐시, SSR이 필요하지 않습니다.

클라이언트와 백엔드의 분리가 더 관리하기 쉽습니다.

검색과 서버 경로가 핵심이면 그 이점이 추가 복잡성을 상쇄해야 합니다.

React 19 Actions에서 폼과 비동기 동작을 자세히 설명합니다.

SaaS 대시보드: Next.js Server와 Client Components

App Router는 서버 작업과 브라우저 상호작용을 나눕니다. 'use client'가 클라이언트 경계를 표시합니다.

Server Components vs Client Components

Server Components는 서버나 빌드에서 실행되고 컴포넌트 로직을 브라우저 JavaScript bundle에 추가하지 않습니다.

정적 콘텐츠, 데이터베이스 조회, API 호출에 맞습니다.

localStorage, window, useState, useEffect, onClick을 사용할 수 없습니다.

Client Components는 브라우저에서 상호작용, 상태와 Browser APIs를 처리합니다.

폼, 버튼, 실시간 업데이트에 맞습니다.

경계 파일은 'use client'를 선언합니다.

Server Components는 Client Components를 import할 수 있습니다. 반대 방향의 직접 import는 안 되지만 서버에서 렌더링한 내용을 전달할 수 있습니다.

SaaS 대시보드 사용 사례

App Router는 인증, 동적 데이터와 많은 폼에 맞습니다.

설정은 사용자 데이터를 읽고 환경설정을 저장합니다.

주문은 목록, 상세와 상태 변경을 처리합니다.

분석 화면은 보호된 데이터를 서버에서 불러오고 브라우저에서 그래프를 조작합니다.

신원과 권한이 중심이면 데이터 계층에 직접 접근하는 구성이 유용합니다.

유지보수 비용 주의

정적·동적 렌더링, revalidate, 컴포넌트 경계와 runtime은 사용 중인 Next.js 버전에 맞아야 합니다. 오래된 예제보다 현재 문서를 확인합니다.

동적 페이지가 몇 개뿐이면 React + Vite와 별도 Node.js 또는 Supabase 백엔드가 더 단순할 수 있습니다.

App Router 시리즈는 routing, migration, Middleware, Auth, Dark Mode를 별도로 다룹니다.

스타일 계층: Tailwind와 utility-first

Utility-first는 HTML이나 JSX에서 작은 class를 조합합니다. <div class="bg-blue-500 text-white p-4 rounded-lg">에서는 각 class가 한 속성을 맡습니다.

Tailwind는 협업 계층이지 제품 디자인을 대신하지 않습니다.

CSS 이름을 만드는 부담을 줄입니다.

스타일을 사용하는 markup 가까이에 둡니다.

사람과 에이전트가 인터페이스를 수정할 공통 어휘를 제공합니다.

Tailwind만으로 디자인 품질이 생기지 않는다

색, 글꼴, 간격, radius에는 일관된 규칙이 필요합니다.

무작위 기본 utility보다 제품 token이 낫습니다.

버튼, 카드, 행의 반복 class는 컴포넌트로 만듭니다.

제약이 없으면 markup만 복잡해지고 제품은 일관되지 않습니다.

Tailwind는 프레임워크와 독립적이다

Astro, Next.js, React + Vite에서 모두 쓸 수 있습니다. 현재 Tailwind CSS v4의 Vite 경로는 @tailwindcss/vite와 @import "tailwindcss";를 사용하며 Astro도 같은 plugin을 쓸 수 있습니다. 구현 시 공식 가이드를 확인합니다.

컴포넌트 계층: shadcn/ui 소유권과 통합

shadcn/ui는 고정 구현을 package에 숨기지 않습니다. CLI가 소스를 프로젝트로 복사하고 프로젝트가 이를 유지합니다.

프로젝트가 소스를 소유한다

upstream 업데이트는 복사본을 자동으로 바꾸지 않습니다.

키보드, ARIA, screen reader를 실제 조합에서 시험합니다.

색, radius, 간격을 디자인 시스템에 맞춥니다.

검증, 전송, 비즈니스 로직은 앱 코드입니다.

보이고 수정 가능한 소스가 장점이지만 업데이트, 접근성, 테마와 상태도 책임집니다.

shadcn/ui와 Tailwind

현재 Astro와 Next.js 가이드는 Tailwind를 전제로 합니다. Tailwind는 스타일 언어, shadcn/ui는 유지할 컴포넌트 소스를 제공합니다.

적합한 사용 사례

대시보드, 설정, 폼 중심 페이지는 Button, Input, Select, Dialog, Table을 활용할 수 있습니다.

설정은 컨트롤과 오류 표현을 재사용합니다.

가입, 로그인, 결제는 primitive를 쓰되 검증과 상태는 앱이 맡습니다.

기존 라이브러리나 완성된 브랜드 시스템이 있으면 이점이 줄어듭니다.

Astro 통합

React 컴포넌트에는 React integration이 필요합니다.

Tailwind가 스타일을 제공합니다.

국소 폼과 Dialog에는 적합하지만 모든 콘텐츠를 React 앱으로 바꿀 이유는 아닙니다.

공식 template은 Tailwind와 React를 설정하며 실행 전 현재 CLI를 확인합니다.

Next.js 통합

Next.js template과 기존 프로젝트 초기화 경로가 있습니다.

각 컴포넌트를 적절한 Server/Client 쪽에 둡니다. 페이지 전체를 Client Component로 만들 필요는 없습니다.

CLI, preset, registry는 바뀔 수 있습니다.

shadcn/ui를 쓰지 않을 조건

primitive가 아니라 완성된 디자인 시스템이 필요할 때입니다.

코드, 업데이트, 접근성, 테마를 직접 유지하고 싶지 않을 때입니다.

Ant Design, Material UI, 내부 라이브러리가 이미 충족할 때입니다.

폼과 대시보드가 거의 없는 콘텐츠 사이트입니다.

1인 기업의 실제 유지보수 비용

페이지와 데이터뿐 아니라 프레임워크 복잡성, 컴포넌트 소유권, AI 생성 코드 검토가 장기 비용을 결정합니다.

Next.js 유지보수

렌더링과 캐시 의도가 설정과 다르면 오래된 데이터를 줄 수 있습니다.

Server/Client 경계가 상태와 데이터 접근 위치를 정합니다.

Vercel, Cloudflare, 자체 Node.js runtime을 따로 평가합니다.

대부분 정적이면 이 검토 비용이 이점보다 클 수 있습니다.

shadcn/ui 유지보수

upstream 수정과 업데이트를 검토합니다.

키보드, ARIA, screen reader를 제품 수준에서 시험합니다.

색, 밀도와 간격을 token에 맞춥니다.

검증, 전송과 상태는 자체 로직입니다.

이 책임을 원하지 않으면 package 라이브러리나 소수의 자체 primitive가 낫습니다.

AI 생성 프런트엔드 검토

React, Next.js, shadcn/ui 예제는 많지만 검수는 남습니다.

에이전트가 Server/Client 계층을 과도하게 만들 수 있습니다.

버전이나 경로와 맞지 않는 캐시를 쓸 수 있습니다.

token과 상호작용 상태를 무시할 수 있습니다.

AI는 입력 시간을 줄이지만 아키텍처, 접근성과 시각 검토를 없애지 않습니다.

한 제품에서 여러 프레임워크 사용

Astro 콘텐츠와 Next.js 대시보드는 경계를 분명히 하지만 두 앱의 의존성, 설정, CI/CD를 추가합니다.

blog.example.com과 app.example.com 같은 경로도 운영해야 합니다.

두 앱은 monorepo에 둘 수 있습니다. 콘텐츠 중심은 Astro, 앱 중심은 Next.js, 균형형은 두 개의 명확한 앱 경계를 씁니다.

다음 단계와 관련 글

공개된 글

블로그 프레임워크 선택은 Hugo, Astro, Hexo를 비교합니다.

Astro 5와 Lighthouse 100은 collections, islands, 성능을 다룹니다.

Astro vs Next.js는 아키텍처와 렌더링을 비교합니다.

React 19 Actions는 폼과 비동기 동작을 다룹니다.

Next.js App Router 시리즈

Routing, migration, Middleware, Auth, Dark Mode는 SaaS 대시보드용 개별 글에서 설명합니다.

시리즈 후속 글

이 글은 Solo Founder Tech Stack 시리즈의 다섯 번째입니다. 다음 글은 Node.js, Python, Go, Supabase와 자체 API를 비교합니다.

Cloudflare, Vercel, 자체 서버와 컨테이너 배포도 다룹니다.

데이터베이스는 PostgreSQL, Supabase, PlanetScale, MongoDB를 비교합니다.

인증은 관리형 서비스와 자체 구현의 경계를 봅니다.

페이지를 분류한 다음에는 백엔드와 배포 경계가 선택한 프런트엔드를 뒷받침하도록 정합니다.