우리 호스팅 비교 플랫폼에서 Astro를 SvelteKit보다 선택한 이유
I’m happy to translate the article for you, but I don’t have the ability to retrieve the full text from external links. Could you please paste the content you’d like translated (excluding code blocks, URLs, and the source line you already provided)? Once I have the text, I’ll translate it into Korean while preserving the original formatting and markdown.
왜 우리는 호스팅 비교 플랫폼을 위해 SvelteKit보다 Astro를 선택했는가
우리는 HostingSift라는 호스팅 제공업체를 나란히 비교할 수 있는 플랫폼을 만들고 있습니다—가격표, 기능 상세, 필터, 사용자 리뷰 등 다양한 기능을 제공하죠. 프로젝트를 시작했을 때, 가장 중요한 선택 중 하나가 **SvelteKit과 Astro 중 어느 것을 사용할까?**였어요.
우리는 Astro를 선택했습니다. 그 이유는 다음과 같습니다.
프로젝트 컨텍스트
- 콘텐츠가 많은 사이트: 23개 이상의 호스팅 제공업체 프로필, 각각 다수의 플랜, 가격 티어, 기능 사양 및 사용자 리뷰 포함.
- 추가 페이지: 비교 페이지, 카테고리 목록, 추천 퀴즈, 블로그.
- 인터랙티브 파트: 청구 기간별 플랜 필터링, 비교 테이블 토글, 인증 흐름, 리뷰 폼.
사용자가 보는 대부분은 정적 콘텐츠이며 JavaScript 없이 렌더링됩니다. 이 비율이 이후 모든 것을 형성했습니다.
Svelte에 대한 우리의 사랑
- Svelte 5의 반응성 모델(룬)은 우아합니다.
- 개발자 경험이 환상적입니다.
- SvelteKit은 성숙하고, 파일 기반 라우팅, SSR, API 엔드포인트, 폼 액션 등을 갖춘 풀 기능을 제공합니다.
그럼 왜 바로 사용하지 않을까요?
핵심 차이점
| Feature | SvelteKit | Astro |
|---|---|---|
| 기본 동작 | 모든 페이지가 인터랙티브하다고 가정하고, 각 라우트를 하이드레이트하기 위해 JS 번들을 전송합니다. | 기본적으로 클라이언트 측 JavaScript가 전혀 없으며, 선택적으로 활성화하기 전까지 페이지는 정적 HTML로 렌더링됩니다. |
| 프리렌더링 | 기본적으로 서버 렌더링되며, 라우트별로 프리렌더링을 선택합니다. | 기본적으로 빌드 시점에 프리렌더링되며, 필요할 때 서버 렌더링을 선택합니다. |
| 하이드레이션 모델 | 전체 페이지가 하나의 하이드레이션 단위입니다. | “아일랜드” – 개별 컴포넌트가 독립적으로 하이드레이트됩니다. |
이는 사소한 차이가 아니라, 페이지를 구축하는 방식을 근본적으로 바꿉니다.
Astro가 우리에게 작동하는 방식
우리는 .astro 컴포넌트(정적 HTML, JavaScript 없음)와 Svelte 컴포넌트(인터랙티브, JavaScript 포함)를 사용해 페이지를 구성합니다. Svelte 컴포넌트는 독립적으로 하이드레이트되는 섬이 되며, 페이지의 나머지 부분은 브라우저가 즉시 렌더링하는 순수 HTML입니다.
예시: 호스팅 프로필 페이지
---
// Import static and interactive components
import Layout from '../../layouts/Layout.astro';
import PlanCard from '../../components/PlanCard.svelte';
import ReviewSection from '../../components/ReviewSection.svelte';
import SpecsTable from '../../components/SpecsTable.astro';
// Fetch data on the server
const { hosting, plans } = await fetchHostingData(slug);
---
Source: …
{hosting.name}
{hosting.description}
- **Each island hydrates on its own**. If one fails, the rest of the page still works.
- **Static parts** (layout, description, specs table, SEO metadata) ship **no JavaScript**.
실용적인 결정
- 정적 페이지 (homepage, category pages, legal pages, blog posts) are prerendered as plain HTML files—fast, cacheable, no server compute per request.
- 신선한 데이터가 필요한 페이지 (hosting profiles with live pricing, filtered listings) are marked as server‑rendered. The intent is explicit.
In contrast, SvelteKit defaults to server‑rendering everything and requires you to opt‑in to prerendering—opposite of what our site needed most.
우리가 포기한 것
| 트레이드‑오프 | 세부 사항 |
|---|---|
| 폼 액션 | SvelteKit의 프로그레시브 엔핸스먼트 폼은 좋습니다. Astro에서는 클라이언트 측 fetch와 함께 Hono API를 사용하므로 onSubmit 핸들러와 로딩 상태를 위한 보일러플레이트가 추가됩니다. |
| 학습 곡선 | 개발자는 .astro와 .svelte 파일을 모두 이해해야 합니다. 어떤 것이 정적이고 어떤 것이 인터랙티브한지 결정하는 작업이 하루에 수십 번 발생합니다. |
| 뷰 전환 | Astro의 전환은 각 네비게이션 시 인라인 스크립트를 다시 실행합니다. 우리는 Google Analytics와 vanilla‑cookie‑consent가 두 번 초기화되지 않도록 추가로 방어 로직을 작성했습니다. SvelteKit의 클라이언트 측 라우팅은 기본적으로 이를 더 우아하게 처리합니다. |
| API 레이어 | SvelteKit의 +server.ts는 긴밀히 통합된 API 라우트를 제공합니다. 우리는 향후 모바일 앱에 유용한 독립형 Hono 서버를 선택했으며, 이는 두 개의 프로세스 관리, 별도 배포 및 CORS 설정을 의미합니다. |
결과
- 홈페이지 JavaScript 페이로드: 전체 약 40 KB.
- 인터랙티브 요소 (프로바이더 그리드, 뉴스레터 폼)는 작고 독립된 번들입니다.
- 비슷한 SvelteKit 설정에서는 모든 라우트가 순수 정적 콘텐츠라 할지라도 하이드레이션 번들을 포함하기 때문에 페이로드가 훨씬 커집니다.
Bottom Line
Astro는 Svelte를 대체하는 것이 아니라, 모든 인터랙티브 컴포넌트에 Svelte 5를 유지하면서 라우팅 및 페이지 구성을 콘텐츠‑우선 사이트에 맞게 처리할 수 있게 해주는 구성 레이어입니다. 기본‑제로‑JS 철학, 섬 기반 하이드레이션, 그리고 빌드‑시 프리렌더링 덕분에 HostingSift에게는 결정이 명확했습니다.
Client‑side Router Overhead
프레임워크의 클라이언트‑사이드 라우터는 우리 코드가 로드되기 전에도 기본 오버헤드를 추가합니다.
서버‑사이드 OG 이미지 생성
Astro의 엔드포인트 모델을 사용하면 Open Graph 이미지 생성을 간단하게 할 수 있습니다:
- 동적 OG 이미지는 모든 호스팅 프로필, 비교 페이지 및 블로그 게시물에 대해 생성됩니다.
- Satori(SVG → PNG 변환)와 Sharp(이미지 처리)를 사용하여 구축되었습니다.
- 표준 API 라우트로 구현되어 PNG 버퍼를 반환합니다 – 특별한 설정이 필요 없습니다.
// src/pages/api/og-image.ts
import { satori } from 'satori';
import sharp from 'sharp';
export async function GET({ params }) {
const svg = await satori(/* … */);
const png = await sharp(Buffer.from(svg)).png().toBuffer();
return new Response(png, { headers: { 'Content-Type': 'image/png' } });
}
빌드 시간은 빠르게 유지됩니다
- Prerender 50개 이상의 정적 페이지.
- 사이트맵 생성.
- Svelte 섬 컴파일.
이 모든 작업은 30초 미만에 완료됩니다. 새로운 제공자를 추가해도 대부분의 단계가 병렬로 실행되기 때문에 빌드에 거의 영향을 주지 않습니다.
SvelteKit 배포
“SvelteKit은 이론적으로는 어디서든 작동합니다. 실제로 가장 원활한 방법은 Vercel에 배포하는 것입니다.”
- Vercel:
adapter-auto가 플랫폼을 자동으로 감지합니다; 통합이 잘 다듬어져 있습니다. - Self‑hosting:
adapter-node를 사용하면 가능하지만, Vercel이 기본 제공하는 설정을 직접 구성해야 합니다.
Hetzner ARM64 VPS에서 자체 호스팅
우리 스택은 단일 Hetzner ARM64 VPS에서 실행됩니다:
- Astro 사이트
- Hono API
- PostgreSQL
- 모두 nginx와 Cloudflare 뒤에 배치
비용: ~ €5 / 월.
배포 단계
# 1️⃣ Install the Node adapter
npm i -D @astrojs/node
# 2️⃣ Build the project
npm run build
# 3️⃣ Run with PM2 (or any process manager)
pm2 start ./dist/server/entry.mjs --name astro-site
어댑터 특이사항도 없고, 플랫폼‑특정 엣지 케이스도 없습니다 – 출력은 표준 Node.js 서버입니다.
Cost Angle
| 플랫폼 | 가격 모델 | 일반 프로 플랜 | 숨겨진 비용 |
|---|---|---|---|
| Vercel / Netlify | 사용량 기반 | $20‑$25 / mo | 함수 실행 시간, 대역폭, 초과 사용 급증(예: 봇 크롤링) |
| Fixed‑cost VPS | 월 고정 요금 | €5 / mo (Hetzner) | 예측 가능 – 트래픽이 두 배·세 배가 되어도 청구서 변동 없음 |
- 관리형 플랫폼은 CI/CD, 프리뷰 배포, 엣지 함수, 무설정 스케일링을 제공하여 인프라 관리를 원하지 않는 팀에 가치가 있습니다.
- VPS는 제어와 비용 예측 가능성을 제공하며, 스케일 업은 단순히 더 큰 서버로 옮기는 것입니다.
아키텍처 개요
- 23개의 호스팅 제공업체, 수백 개의 플랜, 비교 페이지, 퀴즈, 블로그, 사용자 인증, 관리자 패널 – 모두 단일 Hetzner 박스에.
- 새로운 제공업체 프로필 = 단순 데이터.
- 새로운 인터랙티브 기능 = 기존 페이지에 삽입된 새로운 Svelte 섬.
- 새로운 정적 페이지 = 클라이언트 측 비용이 없는
.astro파일.
프레임워크 선택
- SvelteKit이 작동했을까요? 물론입니다. 대시보드, 실시간 협업, 무거운 클라이언트 상태와 같은 앱‑같은 제품을 위해서는 주저 없이 SvelteKit을 선택합니다.
- 콘텐츠‑우선 사이트에서 인터랙티브가 예외인 경우, Svelte 섬을 활용한 Astro가 올바른 선택임이 입증되었습니다 – SvelteKit이 할 수 없어서가 아니라 Astro의 기본 설정이 우리가 원하는 방향을 이미 가리키고 있기 때문입니다.
핵심 요약: 프레임워크와 싸우지 않아도 되는 실제적인 가치가 있습니다. Astro는 필요한 최소한의 클라이언트 페이로드를 제공하면서, 인터랙티브가 중요한 부분에 Svelte를 자유롭게 섞어 사용할 수 있게 합니다.