서버 렌더링 HTML에서 시작해 빌드 도구, 프레임워크, 하이드레이션, 메타 프레임워크, 타입 시스템, AI 코드 생성까지, 지난 20년간 프런트엔드가 어떻게 변해왔는지 층위별로 따라가는 안내서.
강하 · 당신이 못 본 사이 프런트엔드에 무슨 일이 있었나
마지막으로 당신이 프런트엔드를 작성했을 때,
그건 이런 것들 중 하나처럼 생겼었습니다 —
서버 렌더링 · 2009
<?php foreach ($cart as $item): ?>
<li>
<?= $item->name ?>
<button>Buy</button>
</li>
<?php endforeach; ?>
혹은 그냥 손으로 직접 쓴 것
<!-- styled by hand, no build -->
<button class="buy">Buy</button>
<style>
.buy {
padding: 4px 10px;
border: 1px solid #999;
}
</style>
어느 쪽이든: 빌드 단계 0개 · 의존성 0개
모든 브라우저에서 작동했고, 영원히 그럴 것 같았습니다
도대체 무슨 일이 있었을까요?
20년, 44미터의 빌드 도구, 그리고 몹시 혼란스러운 <button> 하나가 지난 뒤, 여기 전체 이야기가 있습니다. 20분만 내주세요. 금방 따라잡게 해드리겠습니다.
강하를 시작합시다 ↓
2008년의 당신은 index.html이라는 파일을 저장하고, 그것을 FTP 클라이언트에 끌어다 놓고, 작은 진행 막대가 오른쪽으로 기어가는 모습을 지켜봤습니다. 그것이 끝나면 당신의 웹사이트는 존재하게 됐습니다. Internet Explorer와 Firefox, 그리고 Chrome이라는 새 브라우저에서도 동작했습니다. 당신은 "build"를 돌리지 않았습니다. 패키지 1,400개를 설치하지도 않았습니다. 마크업을 썼고, 스타일을 썼고, 브라우저는 당신이 말한 그대로를 실행했습니다.
당신은 이 일을 잘했습니다. 그런데 iPhone 출시와 지금 사이 어딘가에서, 당신이 실제 제품을 열심히 출시하느라 바쁜 사이, 눈 한 번 깜빡인 순간 이 분야는 골조부터 완전히 다시 지어졌습니다. 이제 초보자용 튜토리얼은 처음부터 들어본 적 없는 도구 16개로 시작하고, 그 절반은 "빠르다"를 뜻하는 일본어에서 이름을 따온 것처럼 보이며, 첫 명령 하나만으로 연락처 폼 하나를 렌더링하기 위해 Apollo 유도 컴퓨터가 돌렸던 것보다 더 많은 코드를 내려받습니다.
좋은 소식이 하나 있습니다. 그리고 이것이 이 전체 강하의 핵심 주장입니다. 이 중 어느 것도 제멋대로 생긴 게 아닙니다. 이제 곧 만나게 될 모든 도구는 실제 상처 위에 자라난 흉터 조직입니다. 누군가 진짜 문제를 맞닥뜨렸고, 해결책을 만들었고, 그 해결책이 다음 문제를 만들었고, 그 문제도 또 자기만의 해결책을 낳았습니다. 그렇게 20년에 걸친 합리적인 단계들의 총합이, 오늘 당신이 올려다보며 지쳐버린 듯한 감탄을 하게 되는 이 웅장하고 피곤한 광기의 대성당이 된 것입니다.
그러니 우리는 목록을 외우지 않을 겁니다. 순서대로 파고들면서, 각각의 도구가 그것을 정당화하는 고통이 나타나는 바로 그 순간에 등장하게 둘 겁니다. 그리고 내려가는 내내 표본 하나를 계속 관찰할 겁니다. 보잘것없는 <button> 하나가 업계에 의해 어떻게 변형되는지 지켜보는 겁니다. 그리고 바닥암반에 닿으면 당신은 웃게 될 겁니다. 2026년의 최전선은 FTP로 올렸던 그 파일과 놀랄 만큼 많이 닮아 있으니까요.
모든 도구는 실제 상처 위에 생긴 흉터 조직입니다. 상처를 따라가면 지도가 저절로 그려집니다. 모든 것을 이해하게 해주는 단 하나의 생각
LAYER I — 4 M 2006 – 2010
"페이지 전체를 다시 로드하지 않고 그냥 바꾸고 싶을 뿐인데."
첫 번째 상처는 작고도 타당했습니다. 전체 페이지가 하얗게 깜빡이며 새로고침되지 않고도, 페이지의 일부가 바뀌고, 메뉴가 열리고, 폼이 검증되고, 섹션이 로드되기를 원했습니다. 브라우저는 XMLHttpRequest라는 다루기 껄끄러운 무언가와, 브라우저마다 다르게 동작하는 까다로운 DOM 메서드 더미를 통해 이 일을 할 수 있었습니다.
그래서 그 시대는 jQuery를 선택했고, 그것은 정말 훌륭했습니다. $("#cart").load(...)라고 쓰면 브라우저 간 차이가 녹아내렸습니다. AJAX (새로고침 없이 데이터를 가져오는 것)가 대중화됐습니다. 몇 년간의 황금기 동안은 이것으로 충분했습니다.
하지만 애플리케이션은 점점 더 야심차졌고, 그 아래에서 더 깊은 상처가 벌어졌습니다. 데이터가 자바스크립트 변수 안에도 있고 화면 위에도 있을 때, 당신 이 동기화 기계가 되어야 했습니다. 가격을 바꿨나요? 장바구니 총액, 헤더 배지, 결제 버튼, 그리고 작은 요약 상자까지 손으로 업데이트하는 걸 잊지 말아야 합니다. 하나라도 놓치면 UI는 사용자에게 거짓말을 합니다. 성장하는 앱 전반에 걸쳐 이런 수작업 DOM 찌르기를 계속하는 것, 이것이 바로 이 층 이후의 모든 것이 속죄하려 하는 원죄입니다.
유물들 — jQuery는 여전히 웹의 큰 비율에서 돌아가지만, 새 프로젝트를 그것으로 시작하는 사람은 없습니다
LAYER II — 9 M 2010 – 2015
"화면을 데이터와 손으로 동기화하게 만들지 마."
이 동기화 상처에 대한 해결책은 정말로 큰 아이디어였습니다. 선언형 UI입니다. 페이지를 업데이트하는 절차 ("배지를 찾아 텍스트를 바꾼다")를 쓰는 대신, 주어진 데이터에서 페이지가 어떻게 보여야 하는지 를 기술하면 프레임워크가 그 절차를 알아서 계산합니다. 당신은 더 이상 DOM을 직접 만지지 않았습니다. 데이터를 바꾸면 화면이 따라왔습니다. 이것이 당신이 계속 보게 되는 반응형 이라는 말의 의미입니다.
구성의 단위는 컴포넌트가 되었습니다. UI의 독립적인 한 덩어리(그 마크업, 동작, 상태의 일부)를 LEGO처럼 조합하는 방식입니다. 2013년 Facebook에서 나온 React는 컴포넌트와 JSX (여전히 사람들을 불편하게 만드는, 자바스크립트 안에 쓰는 HTML처럼 생긴 문법)를 결합하고, Virtual DOM이라는 영리한 요령을 더해 이 시대를 제패했습니다. 페이지의 가벼운 복사본을 메모리에 유지하고, 변경 때마다 차이를 비교한 뒤, 실제로 달라진 진짜 DOM 노드만 건드리는 방식입니다.
그 뒤로 수많은 꽃이 피었습니다. Vue는 이를 더 친숙하게 만들었습니다. Angular는 (2010년의 사라진 "AngularJS"가 아니라 그 성숙한 재작성판입니다) 엔터프라이즈 구조와 TypeScript를 가져왔습니다. Svelte는 왜 굳이 프레임워크를 브라우저에 실어 보내야 하느냐고 물으며, 자신을 컴파일해 없애버렸습니다. Solid는 JSX는 유지하되 Virtual DOM은 버리고 정밀한 업데이트를 택했습니다. 그리고 지금 이들이 모두 수렴하고 있는 것은 signal입니다. 누가 자신에게 의존하는지 알고, 정확히 그 대상만, 그 외에는 아무것도 업데이트하지 않는 값입니다.
표본 01 — 버튼은 컴포넌트가 된다 · 2013 층수: 6
// 이제 이건 더 이상 마크업이 아닙니다. 자바스크립트입니다
// 마크업인 척하는.
function Buy() {
return (
<button onClick={addToCart}>Buy
</button>)
}
이제 버튼은 state, props, 그리고 부모 트리를 가집니다. 브라우저 안의 프레임워크 런타임 없이는 존재할 수 없습니다. 이것을 보려면 곧 빌드 단계가 필요해질 겁니다 — 계속 파봅시다.
source: ~140 bytesships with: React runtime ~45 KBbuild steps: 1 (and counting)
ReactVue.jsAngularSvelteSolidPreactQwikLit
컴포넌트 프레임워크들 — React가 지배적이지만, 나머지도 아주 생생히 살아 있습니다
공룡의 탈출구
모두가 이 길을 택한 것은 아닙니다. 완고하지만 점점 커지는 진영, htmx, Alpine.js, Rails의 Hotwire는 원죄가 애초에 서버를 떠난 데 있었다고 말하며 HTML-over-the-wire를 다시 가져옵니다. 이 층이 향수를 자극한다면, 그 진영은 바로 당신을 위해 세워졌고, 바닥암반에서 다시 돌아오겠습니다.
LAYER III — 15 M 2012 – 2018
"왜 이제는 파일을 그냥 열 수가 없는 거지?"
이 층은 당신이 가장 싫어하는 부분일 테니, 왜 존재하는지 솔직해집시다. 자바스크립트가 전체 페이지를 만들게 되자 두 가지 사실이 충돌했습니다. 첫째, 이 언어는 생애 대부분 동안 코드를 파일들로 나눌 진짜 방법, 그러니까 import가 없었습니다. 그래서 커뮤니티는 경쟁하는 모듈 시스템(CommonJS의 Node용 require, 그다음 공식 ES Modulesimport)을 발명했고, 둘은 오늘날까지도 완전히 서로 맞아떨어지지 않습니다. 둘째, 당신은 오래된 브라우저가 이해하지 못하는 최신 문법과 JSX를 쓰고 싶었습니다.
그래서 번역 계층이 등장했습니다. Babel은 트랜스파일을 통해 내일의 자바스크립트(와 JSX)를 어제의 형태로 바꿔, 어떤 브라우저에서도 실행할 수 있게 합니다. 번들러 (webpack이 왕이었습니다)는 수백 개의 작은 파일을 몇 개의 파일로 꿰매 붙입니다. 옛 HTTP 아래에서는 수백 번의 요청이 느렸기 때문입니다. 그 과정에서 minifies (공백 제거), tree-shakes (사용하지 않는 코드 제거), 결과를 청크로 나누고, 원본을 계속 디버그할 수 있도록 source maps를 만듭니다. 이 일 묶음 전체가 집합적으로 "build"입니다.
그리고 그 대가는? node_modules. 당신의 의존성과 그 의존성들, 그리고 그것들의 의존성들이 사는 폴더입니다. 텅 빈 스타터 프로젝트조차 일상적으로 25만 개 파일에 착지합니다. 그것은 우주에서 가장 무거운 물체이며, 지금 이 순간 당신의 프로젝트 폴더 안에 놓여 있습니다.
22바이트짜리 당신의 버튼은 이제 2메가바이트 번들 안에 실려 도착합니다. 당신이 쓰지 않았고 읽을 수도 없는 설정 파일이 그것을 조립했습니다. Layer III · 빌드, 요약
Node.jsnpmwebpackBabelRollupGulp· legacyGrunt· legacyBower· dead
빌드 기계장치 — 취소선이 그어진 것들은 오래된 구인 공고에서 아직도 보게 되는 화석들입니다
LAYER IV — 21 M 2018 – 2024
"좋아, 빌드가 있다 쳐. 그럼 제발 90초씩 걸리는 건 멈춰줘."
빌드는 동작했지만 느렸고, webpack 설정은 개발자들 사이를 저주받은 두루마리처럼 떠도는 암흑술이 되었습니다. 다음 상처는 순전히 고통에 관한 것이었습니다. 도구 자체가 너무 비참하게 사용하기 힘들었던 겁니다. 해결책은 그것들을 자바스크립트 대신 빠른 컴파일 언어, Go와 Rust로 다시 쓰는 것이었습니다.
esbuild (Go)는 번들링을 10–100배 더 빠르게 만들어 모두를 민망하게 했습니다. SWC (Rust)는 대형 프레임워크 내부에서 Babel을 대체했습니다. 그리고 Vite는 이것들을 하나로 묶어, 이제 대부분의 사람이 기본값처럼 집어드는 도구가 되었습니다. 개발 중 즉시 시작되는 서버(브라우저의 네이티브 모듈과 esbuild에 기대고 있습니다), 프로덕션용 제대로 최적화된 빌드, 그리고 HMR, 즉 hot module replacement가 있어 파일을 저장하면 현재 위치를 잃지 않고 변경 사항을 볼 수 있습니다. 2026년 기준 Vite의 프로덕션 번들러 자체도 Rust 기반의 Rolldown으로 대체되는 중이며, 전체 스택은 한 회사 VoidZero 아래로 통합되고 있습니다 (Cloudflare가 방금 인수했습니다).
같은 "속도를 위해 다시 쓰자"의 물결은 패키지 매니저(pnpm의 영리한 공유 저장소, 올인원 Bun)와 프레임워크 진영용 번들러(Turbopack, Rspack)에도 밀려왔습니다. 이 층을 한 문장으로 요약한다면, 모든 컨퍼런스에서 메아리치던 바로 이것입니다. "우리가 그걸 Rust로 다시 썼고, 50배 더 빠릅니다."
ViteesbuildSWCRolldownTurbopackRspackOxcVoidZeropnpmBunDeno
속도의 시대 — 여기 있는 거의 모든 것이 Rust나 Go로 작성됐고, 그게 요점의 전부입니다
LAYER V — 28 M 2014 – 2026
"내 아름다운 앱은 텅 빈 흰 화면만 보여주고 Google은 아무것도 못 보잖아."
이쯤 되자 순수 자바스크립트 앱은 더는 피할 수 없는 문제에 부딪혔습니다. 서버는 텅 빈 <div> 하나와 자바스크립트 산더미를 보냈고, 사용자는 그것들이 전부 다운로드되어 실행될 때까지 텅 빈 흰 화면을 바라봐야 했습니다. 그리고 그 텅 빈 div를 바라본 검색 엔진도 빈 페이지를 봤습니다. 콘텐츠 비즈니스에는 치명적입니다. (Google은 여기에 Core Web Vitals라는 숫자까지 붙였고, 이제 느림은 곧 검색 순위 손실이 됐습니다.)
해결책은 HTML을 다시 서버에서 렌더링하는 것이었습니다. 다시 말해, 당신이 2008년에 정확히 하던 그 일 입니다. 여기서부터 약어들이 번식하기 시작하니, 한 번에 온 가족을 정리해봅시다. SSR은 요청마다 서버에서 페이지를 렌더링합니다. SSG는 빌드 시점에 한 번 미리 렌더링합니다 (도구를 얹은 당신의 옛 정적 사이트입니다). ISR은 조용히 자신을 새로고침하는 SSG입니다. 그리고 이 모든 것을 조율하는 프레임워크, 즉 메타 프레임워크가 이제 대부분의 사람이 실제로 출발점으로 삼는 층입니다. Next.js (React), Astro (콘텐츠 우선, 자바스크립트를 거의 보내지 않음), SvelteKit, Nuxt (Vue), Remix (이제 React Router로 합쳐짐).
하지만 브라우저를 위해 만들어진 프레임워크에 서버 HTML을 보내자, 현대 시대를 대표하는 상처가 생겼습니다. 바로 hydration입니다.
STEP 1
컴포넌트를 실행해 완성된 HTML을 보냅니다. 페이지는 즉시 그려집니다. 끝난 것처럼 보입니다.
STEP 2
아직 버튼은 아무것도 하지 않습니다. 그 HTML은 UI 그 자체가 아니라 UI의 사진입니다. 핸들러가 붙어 있지 않습니다.
STEP 3
브라우저는 모든 자바스크립트를 내려받고 같은 앱을 다시 실행해 그것을 "깨웁니다." 잠깐 동안 사용자는 살아 있는 것처럼 보이지만 실제로는 죽어 있는 버튼을 분노하며 연타합니다.
하이드레이션은 식사를 두 번 계산하는 일입니다. 한 번은 서버에서 요리하기 위해, 또 한 번은 브라우저에서 똑같은 식사를 다시 요리해 먹을 수 있음을 증명하기 위해서입니다. Layer V · 하이드레이션 세금
이후의 모든 유행은 하이드레이션을 덜 하려는 계략입니다. Islands (Astro)는 페이지를 정적으로 유지하고 몇몇 상호작용 부분만 하이드레이션합니다. Resumability (Qwik)는 하이드레이션 자체를 건너뜁니다. 그리고 React Server Components (RSC), 현대 React에서 가장 혼란스러운 아이디어는, 컴포넌트가 서버에서만 실행되고 브라우저에는 자바스크립트를 0 으로 보내게 하며, 상호작용하는 잎사귀들에는 "use client"라는 줄로 표시합니다. 이건 정말 영리하면서도 정말 어렵고, 당신이 없는 사이 지반이 움직였다는 사실을 한 약어로 보여주는 것이 있다면 바로 이것입니다.
Next.jsAstroSvelteKitNuxtRemixReact RouterGatsby· declining
메타 프레임워크들 — Next와 Astro가 앞서고, Gatsby는 힘이 빠지고 있습니다
LAYER VI — 34 M 2015 – 2026
"이 코드베이스는 유지보수 불가능하고 난 같은 드롭다운을 계속 다시 만들고 있어."
앱이 이 정도로 커지자 두 가지 새로운 상처가 생겼습니다. 안전하게 리팩터링할 수 없고, 같은 위젯을 영원히 다시 만들고 있다는 점입니다. 여기서의 해결책들은, 솔직히 말해, 가장 받아들일 가치가 있는 부분들입니다. TypeScript는 자바스크립트에 타입 시스템을 덧붙여, 타이핑하는 동안 버그의 whole class를 잡아내고 에디터에 진짜 자동완성을 줍니다. 이것은 당신이 떠난 뒤 가장 큰 변화였고, 너무 완벽하게 승리해서 이제 도구 체인 자체가 따라잡기 위해 자기 컴파일러를 Go로 포팅하고 있습니다.
스타일링에서는, 공룡의 고향이라 할 그 영역에서, 가장 크게 움직인 것은 Tailwind입니다. 유틸리티 클래스들을 마크업 안에 바로 써 넣는 방식(class="px-4 py-2 rounded")인데, 이것은 당신이 피하라고 배웠던 인라인 스타일처럼 보여서 예상 가능한 반응을 정확히 일으킵니다. 그러다 어느새 많은 사람이 UI를 출하하는 가장 생산적인 방법이 되어 있습니다. 한편 네이티브 CSS는 마침내 성장했습니다. nesting, variables, container queries, :has()까지 갖추게 되면서, 예전 도구들 상당수는 더 이상 필요하지 않게 됐습니다.
그리고 컴포넌트는 설치하는 의존성이 아니라 당신이 소유하는 코드 가 되었습니다. shadcn/ui (접근성 있는 Radix 프리미티브 위에 세워졌고, 소스를 당신의 저장소로 복사해 넣는 방식입니다)는 카테고리 전체를 새로 설정해버렸습니다. 여기에 서버 데이터용 TanStack Query, 나머지용 약간의 Zustand, 검증용 Zod, 테스트용 Vitest + Playwright를 짝지으면, 당신은 2026년 앱의 실전 어휘를 본 셈입니다.
표본 02 — 버튼, 완전 발굴됨 · 2026 층수: 47
// 타입이 붙고, 하이드레이션되고, 디자인 토큰이 입혀지고,
// 설치가 아니라 복사되며, 서버 경계를 가진다.
<Button
variant="default"
size="sm"
onClick={addToCart}
Buy
</Button>// + 47 files of build, types,
// CSS engine, a11y, and a runtime.
기본적으로 접근 가능합니다. design tokens로 테마화됩니다. 끝에서 끝까지 타입 검사를 받습니다. 공정하게 말하면, 이것은 더 나은 버튼입니다. 또한 "Buy"라는 단어를 렌더링하기 위해 생태계 하나 전체가 필요했습니다.
source: ~90 bytesbehind it: ~250k files in node_modulesbuild steps: yes
TypeScriptTailwind CSSshadcn/uiRadix UIMUIdaisyUITanStack QueryZodVitestPlaywrightESLintPrettierBiomeStorybook
엔지니어링 덧붙이기들 — 진짜로 가치가 있는 층
LAYER VII — 39 M 2015 – 2026
"좋아. 그럼 이걸 그냥 인터넷에 어떻게 올리지?"
순수하게 좋은 소식만 있는 층이 하나 있습니다. FileZilla에 파일을 끌어넣고 기도하던 시절 기억하시나요? 사라졌습니다. 이제는 Git 저장소를 Vercel, Netlify, 혹은 Cloudflare에 연결하면, git push를 할 때마다 사이트가 자동으로 빌드되고 배포됩니다. pull request를 열면 그 정확한 변경 사항에 대한 실시간 미리보기 URL 도 받습니다. 미래의 이 부분은 2008년보다 명백하게 더 낫습니다.
기억해둘 아이디어 두 가지가 있습니다. Serverless 함수는 서버를 운영하지 않고도 백엔드 코드를 실행하게 해줍니다. edge 는 그 코드가 하나의 데이터센터가 아니라 사용자 가까이 있는 수백 개의 데이터센터에서 실행된다는 뜻입니다. 지구 전체가 당신의 오리진인 셈입니다. 그리고 웹 기술을 휴대폰과 데스크톱으로 가져가고 싶다면: 네이티브 앱에는 React Native/Expo, 데스크톱에는 Tauri나 Electron이 있습니다 (Electron은 채팅 창 하나를 보여주기 위해 브라우저 전체를 실어 보냅니다. Tauri는 당신이 이미 가지고 있는 것을 사용합니다).
VercelNetlifyCloudflareGitHub PagesExpoReact NativeTauriElectron
호스팅과 확장 — git push가 새로운 FTP이며, 더 낫습니다
LAYER VIII — 44 M 2023 – 2026
"솔직히 말해서, 그냥 기계가 React를 대신 써주면 안 되나?"
가장 깊고, 가장 새로운 층이며, 우리 중 많은 이들을 다시 한번 돌아보게 만든 층입니다. 이제 v0, Lovable, Bolt에 평이한 영어로 UI를 설명하면 동작하는 프런트엔드를 돌려받을 수 있고, Cursor, Claude Code, Copilot 같은 에디터는 타이핑하는 동안 보일러플레이트를 써줍니다. 이 실천에는 이름까지 붙었습니다. vibe coding이라고 하며, Andrej Karpathy가 만든 말입니다. 다만, 결과물을 여전히 당신이 이해해야 한다는 정직한 각주가 붙습니다.
이것이 또한 엔지니어링 분야들 사이 경계가 흐려지는 이유이기도 합니다. 이제 백엔드나 시스템 쪽 사람도 오후 한나절이면 그럴듯한 프런트엔드를 만들어낼 수 있습니다. 놀랍고도 약간 방향 감각을 잃게 만드는 일입니다. 왜냐하면 생성된 코드는 조용히 당신이 위의 여덟 층에 있는 모든 것을 안다고 가정하기 때문입니다. 로봇이 쓰는 것과 당신이 이해하는 것 사이의 그 간극, 바로 그것이 이 지도가 존재하는 이유입니다.
AI 코드 생성의 물결 — 우리 중 많은 이들이 다시 이쪽으로 걸어 들어오게 된 문
Bedrock — 44 m · 2026
자기 집 현관에 닿았습니다.
바닥에는 이것이 있습니다. 그리고 그것이 이 여정이 가치 있었던 이유입니다. 2026년의 최전선, 가장 날카로운 사람들이 가장 흥분하는 것들은, 서버에서 HTML을 렌더링하고, 자바스크립트는 거의 보내지 않으며, 웹 플랫폼과 싸우는 대신 그것을 사용하는 것입니다. Astro, islands, server components, htmx, "추는 다시 되돌아오고 있다"는 말, 이 모든 것은 한 방향을 가리킵니다. CDN에서 제공되는, 대부분 HTML로 이루어진 빠른 페이지를 향해서요.
즉, 20년과 44미터의 빌드 도구와 번들러와 하이드레이션 계략들을 거친 뒤, 이 산업은 거대한 원을 그리며 질주했고, 약간 숨이 찬 채, FTP로 올렸던 그 파일과 놀랄 만큼 많이 닮은 어떤 것으로 다시 돌아왔습니다. 그 직감은 만료되지 않았습니다. 땅은 정말로, 이유가 있어서 움직였고, 그러고 나서 다시 움직여 돌아왔습니다.
환영합니다. 서가를 둘러보거나 지금 책 한 권을 보세요.
HTML로 제공됨. 약 3 KB. 빌드 없음. 이 캡션을 다 읽기 전에 로드됨.
대성당 전체를 다시 배울 필요는 없습니다. 그중 어떤 20%가 하중을 받는 구조인지 배우고, 나머지 80%는 그냥 지나쳐도 되는 뷔페라는 사실을 알아보면 됩니다. 다음 섹션은 바로 그것을 위한 현장 키트입니다. 다시 오신 걸 환영합니다. 당신은 늦은 게 아니라 빨랐습니다.
처방전이 아니라, 시작용 뷔페입니다. 이것들은 인기 있고, 잘 지원되는 기본값들이지, 유일한 정답은 아닙니다. 아무 도구나 눌러 사이트를 열어보세요.
콘텐츠 사이트 / 블로그 / 마케팅
아니면 더 가볍게 갈 수도 있습니다. htmx를 이미 아는 백엔드와 함께 쓰거나, CDN 위에 손으로 쓴 HTML을 올리는 겁니다. 2026년에도 여전히 완전히 타당합니다.
실제 앱 (로그인하는 제품)
이것이 AI 도구들이 기본적으로 집어드는 조합이며, 대체로 그것은 튜토리얼도 많고, 일자리도 많고, 막혔을 때 답도 많다는 뜻입니다.
어느 쪽이든 그 아래의 도구 벨트
git push로 배포하세요. 당신은 아마 평생 webpack 설정 파일을 열 일조차 없을 겁니다. 좋습니다.
SPA Single Page Application 하나의 HTML 껍데기; 자바스크립트가 모든 것을 만들고 바꿔 끼운다; 전체 새로고침 없음. SSR Server-Side Rendering 서버가 요청마다 HTML을 만든 뒤, 브라우저가 그것을 하이드레이션한다. SSG Static Site Generation 배포 시점에 모든 HTML을 미리 빌드하고 정적 파일을 제공한다. 도구가 얹힌 당신의 옛 사이트. RSC React Server Components 서버에서만 실행되고 브라우저에는 자바스크립트를 보내지 않는 컴포넌트. Hydration—서버 렌더링된 HTML을 상호작용 가능하게 만들기 위해 브라우저에서 자바스크립트를 다시 실행하는 것. 비용이 큰 부분. Islands—대부분 정적이고, 작게 상호작용하는 "섬"들만 있는 페이지; 그 부분에 대해서만 자바스크립트를 보낸다. HMR Hot Module Replacement 파일을 저장하면 전체 새로고침 없이 즉시 변경을 본다. ESM / CJS ES Modules / CommonJS 현대적인 import 표준 대 Node의 오래된 require. JSX—자바스크립트 안에 쓰는 HTML처럼 생긴 문법. 트랜스파일링이 필요하다. 실제 HTML은 아니다. CWV Core Web Vitals Google의 속도 지표(페인트, 반응성, 레이아웃 흔들림)로, 성능을 순위 요소로 만들었다. The edge—하나의 데이터센터 대신 사용자 가까이 있는 수백 개의 CDN 위치에서 코드가 실행되는 것.