사내 간단한 페이지 추천 스택

사내에서 필요한 페이지는 대개 생각보다 작다.

공지 몇 개를 모아 보여주거나, 링크와 표를 정리하거나, 숫자를 입력하면 결과를 계산해 주거나, API에서 현재 상태를 읽어오는 정도다.

그런데 만드는 순간부터 거대한 서비스처럼 생각하면 일이 커진다.

회원 시스템은 뭘 쓰지?
서버는 어디에 두지?
DB부터 만들어야 하나?
관리자 페이지도 있어야 하나?

간단한 사내 페이지라면 이 질문들을 전부 먼저 풀 필요가 없다.

그래서 메디빌더의 사내 간단한 페이지에는 아래 조합을 추천한다.

읽기 중심: Astro + Tailwind CSS + Cloudflare Pages
상호작용 중심: SvelteKit + Tailwind CSS + Cloudflare Workers
사내 접근 제한: Cloudflare Access

핵심은 프레임워크의 우열이 아니다.

페이지가 주로 읽히는가, 아니면 사용자의 행동을 받아 처리하는가?

이 질문 하나로 대부분 결정할 수 있다.

왜 이 조합을 추천하는가

이 스택의 가장 큰 장점은 작게 시작해도 버리는 작업이 적다는 점이다.

문서 한 장은 Astro로 가볍게 만들 수 있고, 입력과 서버 로직이 필요한 화면은 SvelteKit으로 만들 수 있다. 둘 다 Tailwind를 쓰고 Cloudflare에서 배포하므로, 프로젝트마다 디자인 언어와 운영 방식을 처음부터 다시 정할 필요가 없다.

1. 서버를 직접 운영하지 않는다

간단한 사내 페이지를 위해 VPS를 만들고, 웹서버를 설정하고, 보안 업데이트와 프로세스 재시작을 관리할 필요가 없다.

정적 파일은 Pages가 제공하고, 서버 로직은 Workers가 요청 단위로 실행한다. 작은 페이지 때문에 새로운 상시 서버 한 대를 운영 목록에 추가하지 않아도 된다.

2. 문서와 작은 앱을 같은 경계에서 다룬다

Astro와 SvelteKit은 역할이 다르지만 배포, 도메인, Access, 로그 같은 바깥 운영 경계는 Cloudflare로 모을 수 있다.

콘텐츠 페이지: Astro
상호작용 페이지: SvelteKit
디자인 언어: Tailwind
배포·접근·edge: Cloudflare

스택을 하나로 억지 통일하는 대신, 역할은 나누고 운영 경계는 통일한다.

3. 변경 근거가 남는다

Notion이나 웹 빌더처럼 화면에서 바로 고치는 방식은 빠르지만, 무엇이 어떻게 바뀌었는지 코드와 함께 검증하기 어렵다.

이 조합은 Git diff, pull request, build 결과, preview URL을 남길 수 있다. AI가 만든 페이지도 어떤 파일이 바뀌었고 실제 빌드가 통과했는지 확인한 뒤 배포할 수 있다.

4. 내부 공개를 별도 회원 시스템 없이 시작한다

사내 페이지마다 회원가입, 비밀번호 찾기, 세션 관리부터 만들 필요가 없다.

Cloudflare Access를 앞단에 두면 허용된 회사 계정이나 지정된 사용자만 통과시킬 수 있다. 앱은 필요한 경우 전달받은 사용자 정보를 서버에서 다시 확인한다.

5. 필요한 만큼만 JavaScript를 쓴다

읽기만 하는 페이지는 Astro로 정적 HTML을 만들고, 실제 상호작용이 필요한 화면만 SvelteKit을 쓴다.

모든 페이지를 full-stack 앱으로 만들지 않기 때문에 구조와 브라우저 실행량을 목적에 맞게 줄일 수 있다.

다른 선택지와 비교하면

다른 도구가 나쁘다는 뜻은 아니다. 다만 사내 간단 페이지의 반복 가능한 기본값으로 놓았을 때 생기는 비용을 비교해야 한다.

비교안	간단 페이지의 기본값으로 둘 때 단점	오히려 더 잘 맞는 경우
Notion·Google Sites	디자인·URL·라우팅·API 연동·자동 검증의 자유도가 낮다	여러 비개발자가 브라우저에서 문서를 수시로 공동 편집할 때
순수 HTML/CSS/JS	첫 한 장은 가장 빠르지만 페이지와 공통 요소가 늘면 복제와 스타일 드리프트가 생긴다	수명이 짧고 상호작용 없는 단일 안내 페이지
Next.js·React	간단한 내부 화면에는 렌더링 방식과 라이브러리 선택지가 많고 구조가 쉽게 커진다	React 컴포넌트 자산과 운영 경험이 이미 조직 표준일 때
Rails	DB·권한·업무 흐름이 없는 페이지에는 초기 애플리케이션 구조와 운영 책임이 무겁다	데이터 정본, 승인, 감사 이력, 복잡한 권한이 필요할 때
Retool류 내부도구 SaaS	좌석 비용, vendor 종속, UI·배포·권한 경계의 제약이 생긴다	표준 CRUD 화면을 아주 빨리 조립하는 것이 최우선일 때
직접 운영하는 VPS	작은 페이지에도 OS, 프로세스, TLS, 패치, 장애 대응 책임이 생긴다	상시 프로세스나 특정 runtime, 사설망, 장기 실행 작업이 꼭 필요할 때

Notion이나 Google Sites보다 나은 점

Notion과 Google Sites는 가장 빠른 문서 도구다. 회의 메모나 공동 편집 문서라면 굳이 코드로 옮길 이유가 없다.

하지만 페이지가 아래 조건을 가지면 한계가 빨리 온다.

브랜드에 맞는 정보 구조와 화면이 필요하다.
외부 API나 현재 데이터를 읽어야 한다.
사용자 입력에 따라 결과가 달라져야 한다.
특정 URL 구조와 redirect가 필요하다.
배포 전 자동 검증과 preview가 필요하다.
나중에 다른 시스템의 일부로 연결될 가능성이 높다.

이때는 처음부터 Astro나 SvelteKit으로 두는 편이 이전 비용을 줄인다.

Next.js보다 작은 기본값이다

Next.js는 강력한 full-stack React 프레임워크다. React가 조직 표준이고 기존 컴포넌트를 재사용할 수 있다면 좋은 선택이다.

다만 사내 간단 페이지 하나를 위해 React 생태계 전체를 기본값으로 가져오면 선택지가 많아진다. 서버와 클라이언트 경계, 데이터 fetching, 상태 관리, UI library를 어느 수준까지 쓸지 결정해야 한다.

SvelteKit도 full-stack이지만 작은 화면에서 필요한 코드량과 개념을 비교적 낮게 유지하기 쉽다. 읽기 중심이면 그보다 더 작은 Astro로 내려갈 수 있다는 점도 이 조합의 장점이다.

Rails보다 가볍지만, Rails를 대체하지는 않는다

Rails는 사내 페이지의 경쟁자가 아니라 사내 업무 시스템으로 승격할 때의 다음 선택지다.

글과 표를 보여주는 페이지에 Rails 앱 전체를 만드는 것은 무겁다. 반대로 돈, 계약, 인사, 고객 기록처럼 데이터가 정본이 되고 승인과 이력이 필요해지면 SvelteKit 화면과 작은 D1 테이블을 계속 붙이는 것이 더 위험하다.

따라서 경계는 분명하다.

정보를 보여준다 -> Astro
입력에 반응하고 외부 상태를 조회한다 -> SvelteKit
업무 상태와 기록을 책임진다 -> Rails

만들려는 것	추천 스택
공지, 가이드, 핸드북, 프로젝트 설명서	Astro + Tailwind + Pages
링크 모음, 사례집, 회고, 읽기 전용 리포트	Astro + Tailwind + Pages
필터가 있는 현황판, 계산기, 입력 폼	SvelteKit + Tailwind + Workers
외부 API에서 현재 상태를 읽는 화면	SvelteKit + Tailwind + Workers
데이터 수정, 승인 이력, 복잡한 권한, 핵심 업무 원장	Rails 같은 정식 업무 앱 검토

Astro는 ‘읽는 페이지’에 쓴다

Astro는 콘텐츠 중심 사이트에 잘 맞는다.

Markdown 파일로 글을 쓰고, 빌드할 때 HTML을 만들어 배포한다. 브라우저에 불필요한 JavaScript를 많이 보내지 않는 것이 기본이라 공지, 문서, 가이드, 사례집처럼 읽는 일이 중심인 페이지에 자연스럽다.

예를 들면 이렇다.

팀 온보딩 가이드
프로젝트 소개와 운영 원칙
월간 회고와 사례 모음
자주 묻는 질문
사내 링크 디렉터리
변경이 하루 한두 번 이하인 읽기 전용 현황판

문서가 여러 장으로 늘어난다면 Astro 위에 Starlight를 얹으면 된다. 이 조각글 사이트도 그 구조다.

Astro의 장점은 단순하다.

글 한 편 = Markdown 파일 하나
수정 = 파일 수정
검토 = Git diff
발행 = build 후 deploy

콘텐츠가 정본인 페이지에서 이보다 복잡한 CMS를 먼저 둘 이유는 많지 않다.

SvelteKit은 ‘움직이는 페이지’에 쓴다

SvelteKit은 화면이 사용자의 행동을 받아 처리해야 할 때 쓴다.

예를 들면 이렇다.

날짜나 담당자로 목록을 거르는 현황판
숫자를 입력하면 결과가 바뀌는 계산기
제출 버튼이 있는 간단한 폼
Asana, Slack, Google Sheets 같은 외부 원천을 조회하는 화면
URL마다 다른 데이터를 불러오는 상세 페이지
서버에서 토큰을 숨긴 채 API를 호출해야 하는 도구

SvelteKit은 화면과 서버 endpoint를 같은 프로젝트 안에서 다룰 수 있다. Cloudflare의 @sveltejs/adapter-cloudflare를 쓰면 Workers에 맞춰 배포할 수 있고, 필요하면 D1, KV, R2 같은 Cloudflare 자원도 binding으로 연결할 수 있다.

다만 “나중에 필요할 것 같아서” SvelteKit을 고르지는 않는다.

현재 필요한 것이 글과 표뿐이라면 Astro가 더 정확한 선택이다.

Tailwind는 두 스택의 공통 디자인 언어다

Astro와 SvelteKit 중 무엇을 골라도 스타일은 Tailwind CSS로 맞춘다.

Tailwind를 쓰는 이유는 거창한 디자인 시스템을 만들기 위해서가 아니다. 사내 페이지마다 CSS 이름을 새로 고민하지 않고, 간격·색·글자 크기·반응형 배치를 화면 가까이에서 빠르게 조정하기 위해서다.

좋은 내부 페이지는 화려할 필요가 없다.

아래만 지키면 된다.

첫 화면에서 이 페이지의 목적이 보인다.
핵심 상태와 다음 행동이 위에 있다.
표는 모바일에서도 깨지지 않거나 가로 스크롤이 된다.
성공, 주의, 실패 상태가 색만이 아니라 텍스트로도 구분된다.
로딩이 길면 빈 화면 대신 현재 무엇을 하는지 보여준다.

공통 컴포넌트가 실제로 세 번 이상 반복되기 전에는 별도 UI 패키지를 만들지 않는다. 먼저 페이지 하나를 제대로 끝내는 편이 낫다.

Cloudflare는 배포와 출입문을 맡는다

여기서 CF는 Cloudflare를 뜻한다.

Cloudflare는 두 가지 역할을 맡는다.

첫째는 배포다.

SvelteKit full-stack 앱은 Workers를 기본으로 본다.
Astro 정적 문서처럼 Git 기반 preview와 정적 배포가 핵심이면 Pages를 쓴다.

둘째는 출입문이다.

사내 전용 페이지라면 앱 안에 급하게 비밀번호 하나를 박는 대신 Cloudflare Access로 앞단을 잠근다. 허용된 회사 이메일이나 지정된 사용자만 로그인 후 들어오게 만들 수 있다.

다만 Access만 붙였다고 모든 보안이 끝나는 것은 아니다.

민감한 데이터를 다루는 SvelteKit 앱은 서버에서도 Access가 넘긴 사용자 정보를 확인하고, 권한 없는 요청은 기본적으로 거부해야 한다. API token은 코드나 브라우저에 넣지 않고 Cloudflare secret으로 둔다.

새 도메인부터 만들지 않는다

간단한 페이지 하나를 만들 때마다 새 subdomain을 늘리면 나중에 찾기와 관리가 더 어려워진다.

먼저 기존 사내 허브의 path로 들어갈 수 있는지 본다.

/guides/campaign-review
/tools/simple-calculator
/reports/monthly-summary

별도 보안 경계, 로그인 세션, 제품 정체성, 독립 배포가 필요할 때만 subdomain을 만든다. URL은 예쁜 이름보다 “누가 소유하고, 누가 들어가며, 무엇의 정본인가”가 먼저다.

이 선을 넘으면 ‘간단한 페이지’가 아니다

SvelteKit과 Astro는 많은 일을 할 수 있다. 그렇다고 모든 업무 시스템을 여기에 욱여넣어야 한다는 뜻은 아니다.

아래 중 두세 가지가 동시에 필요해지면 Rails 같은 정식 업무 앱을 검토한다.

여러 사용자가 데이터를 계속 생성하고 수정한다.
역할별 권한이 복잡하다.
승인, 반려, 이력, 감사 로그가 필요하다.
데이터가 돈, 계약, 인사, 고객 기록의 정본이다.
백그라운드 작업과 알림이 쌓인다.
여러 화면이 하나의 업무 흐름으로 연결된다.

이 경우 문제는 페이지가 아니라 업무 시스템이다.

정적 사이트에 DB를 조금씩 붙이거나, 작은 Worker 여러 개로 핵심 원장을 나누면 처음에는 빨라도 운영이 어려워진다.

실제 시작 순서

간단한 사내 페이지는 아래 순서로 시작한다.

1. 한 문장으로 목적을 쓴다.
2. 읽기 중심인지 상호작용 중심인지 판정한다.
3. Astro 또는 SvelteKit 하나만 고른다.
4. Tailwind로 필요한 화면만 만든다.
5. 로컬에서 모바일·오류·빈 상태를 확인한다.
6. Cloudflare에 배포한다.
7. 사내 전용이면 Access로 잠근다.
8. 실제 URL에서 다시 읽어본다.

처음부터 DB, 관리자, 공통 패키지, 범용 템플릿을 만들지 않는다.

현재 문제를 해결하는 가장 작은 페이지를 먼저 배포하고, 반복되는 요구가 확인될 때 구조를 키운다.

한 줄로 다시 정리하면

읽는 페이지는 Astro.
움직이는 페이지는 SvelteKit.
스타일은 Tailwind.
배포와 출입문은 Cloudflare.
업무 원장이 되면 정식 앱으로 승격.

사내 도구의 목표는 기술 스택을 자랑하는 것이 아니다.

필요한 사람이 바로 열고, 바로 이해하고, 바로 행동하게 만드는 것이다.