[번역] 프론트엔드에는 무슨 일이 일어났나?
원문: https://davidpoblador.com/deep-dives/what-happened-to-the-frontend/
작성자: David Poblador i Garcia
하강: 당신이 한눈판 사이에 프론트엔드에 일어난 일
(The Descent — What Happened to the Frontend While You Weren't Watching)
마지막으로 프론트엔드를 작성했을 때 그건 그저 <button>과 FTP 업로드였습니다. 20분만 투자해서 당신이 한눈을 판 사이에 웹이 이뤄낸 모든 변화를 파악해 보세요.
옛날 옛적에...
마지막으로 프론트엔드를 작성하셨을 때의 모습은 대략 이랬을 것입니다.
서버 렌더링 · 2009년
<?php foreach ($cart as $item): ?> <li><?= $item->name ?><button>Buy</button></li> <?php endforeach; ?>
혹은 직접 작성한 코드
<!-- 수작업 스타일, 빌드 없음 --> <button class="buy">Buy</button> <style> .buy { padding: 4px 10px; border: 1px solid #999; } </style>
어느 쪽이든 빌드 단계도 없고 의존성도 0개였습니다. 그리고 모든 브라우저에서 영원히 잘 작동했습니다.
그리고 한눈을 판 사이...
도대체 무슨 일이 일어난 걸까요?
20년의 세월, 44미터 높이로 쌓인 빌드 도구들, 그리고 매우 혼란스러워진 하나의 <button>이 남았습니다. 이제 그 뒤에 숨겨진 이야기를 들려드리겠습니다. 딱 20분만 투자하시면 흐름을 완전히 따라잡을 수 있습니다.
2008년, 여러분은 index.html이라는 파일을 저장하고, 이를 FTP 클라이언트에 드래그 앤 드롭한 뒤, 작은 진행 표시줄이 오른쪽으로 기어가는 모습을 지켜보았습니다. 업로드가 완료되면 웹사이트가 세상에 존재하게 되었습니다. 그 웹사이트는 인터넷 익스플로러(Internet Explorer), 파이어폭스(Firefox), 그리고 크롬(Chrome)이라 불리는 신생 브라우저에서도 잘 작동했습니다. "빌드"를 실행할 필요도 없었습니다. 1,400개의 패키지를 설치할 필요도 없었죠. 마크업을 작성하고, 스타일을 적으면 브라우저는 여러분이 지시한 대로 정확히 수행했습니다.
여러분은 이 일에 꽤 능숙했습니다. 그러다 아이폰 출시와 지금 사이의 어느 시점에 여러분이 깜빡 눈을 붙인 사이, 실제 제품을 배포하느라 바쁜 와중에 프론트엔드라는 분야 전체가 뼈대부터 완전히 재건축되었습니다. 이제 초보자용 튜토리얼은 들어본 적도 없는 16가지 도구로 시작하며, 그 중 절반은 "빠르다"는 뜻의 일본어 단어에서 이름을 따왔고, 첫 번째 명령어는 그저 문의 폼(contact form) 하나를 렌더링하기 위해 아폴로 우주선의 유도 컴퓨터가 실행했던 것보다 더 많은 코드를 다운로드합니다.
여기에 좋은 소식이 있으며, 이것이 이 하강(descent) 전체의 논지입니다. 이 중 어떤 것도 제멋대로 만들어진 것은 없다는 사실입니다. 이제부터 만나보실 모든 도구는 실제 상처 위에 자라난 흉터 조직입니다. 누군가가 실질적인 문제에 부딪혀 해결책을 만들었고, 그 해결책이 다시 다음 문제를 낳았으며, 또 그에 대한 해결책이 만들어졌습니다. 지난 20년 동안 거쳐 온 타당한 단계들이 합쳐져 오늘날 우리가 마주하고 있는 이 웅장하고도 지치게 만드는 '광기의 대성당'이 탄생한 것입니다.
그러니 도구 목록을 무작정 외우지는 않겠습니다. 순서대로 파고 내려가면서, 그 도구의 존재를 정당화하는 고통이 찾아오는 바로 그 시점에 각각의 도구를 만나보겠습니다. 우리는 이 하강의 여정 내내 하나의 표본인 보잘것없는 <button> 하나를 계속 관찰하며, 업계가 이 버튼에 어떤 짓을 저지르는지 지켜볼 것입니다. 그리고 우리가 마침내 암반(bedrock)에 다다랐을 때 여러분은 웃음을 터뜨리게 될 것입니다. 왜냐하면 2026년의 최전선은 여러분이 옛날에 FTP로 업로드했던 그 파일과 아주 많이 닮아있기 때문입니다.
모든 도구는 실제 상처 위에 돋아난 흉터 조직입니다. 상처를 따라가다 보면 지도가 스스로 그려집니다.
레이어 I — 깊이 4m (2006 – 2010)
가려움증 (The Itch)
"전체 페이지를 새로고침하지 않고 페이지의 일부만 바꾸고 싶어요."
첫 번째 상처는 작고 합리적이었습니다. 페이지 전체를 새로고침할 때 생기는 하얀 깜빡임 없이, 페이지의 일부분만 변경하거나, 메뉴를 열거나, 폼을 검증하거나, 특정 섹션을 불러오고 싶었던 것이죠. 브라우저는 까다로운 XMLHttpRequest와 브라우저마다 다르게 작동하는 번거로운 DOM 메서드 뭉치를 통해 이를 지원하고 있었습니다.
그래서 그 시대는 jQuery를 선택했고, 그것은 정말 훌륭했습니다. $("#cart").load(...) 한 줄이면 브라우저 간의 차이점이 눈 녹듯 사라졌습니다. 새로고침 없이 데이터를 가져오는 AJAX가 주류로 자리 잡았습니다. 몇 년의 황금기 동안은 이것으로 충분했습니다.
하지만 애플리케이션은 점점 더 야심 차졌고, 그 밑바닥에서 더 깊은 상처가 벌어졌습니다. 데이터가 JavaScript 변수에도 존재하고 화면에도 나타나게 되면서, 여러분 스스로가 동기화 기계가 되어야 했습니다. 가격을 바꾸셨나요? 장바구니 합계, 헤더의 배지, 결제 버튼, 그리고 작은 요약 박스까지 모두 직접 수동으로 업데이트하는 것을 잊지 말아야 합니다. 하나라도 놓치면 UI는 사용자에게 거짓말을 하게 됩니다. 애플리케이션이 커짐에 따라 손으로 직접 DOM을 찔러 대는 이 수동 동기화가 바로 이 레이어 이후의 모든 기술이 속죄하고자 하는 '원죄'입니다.
- 도구들: jQuery (유산), Backbone.js (유산)
- 현실: jQuery는 여전히 웹의 거대한 지분을 차지하고 있지만, 아무도 새 프로젝트를 jQuery로 시작하지는 않습니다.
레이어 II — 깊이 9m (2010 – 2015)
프레임워크의 등장 (The Frameworks Arrive)
"더 이상 화면과 데이터를 수동으로 동기화하게 만들지 마세요."
동기화 상처에 대한 해결책은 참신하고 거대한 아이디어였습니다. 바로 선언형 UI(declarative UI)입니다. 페이지를 업데이트하는 단계("배지를 찾아서 텍스트를 설정한다")를 작성하는 대신, 특정 데이터 상태에서 페이지가 어떻게 보여야 하는지를 묘사하면 프레임워크가 단계를 알아서 찾아내는 방식입니다. 개발자는 더 이상 DOM을 건드리지 않게 되었습니다. 데이터를 바꾸면 화면이 알아서 따라왔습니다. 이것이 여러분이 계속 보게 되는 '반응형(reactive)'이라는 단어의 의미입니다.
구축의 기본 단위는 **컴포넌트(component)**가 되었습니다. 컴포넌트는 마크업, 동작, 자체적인 상태(state)를 가지고 있어 레고 블록처럼 조합할 수 있는 독립적인 UI 조각입니다. 2013년 페이스북이 내놓은 React는 컴포넌트를 JSX(JavaScript 내부에서 작성되는 HTML처럼 생긴 문법으로, 여전히 사람들을 불편하게 만듭니다)와 **가상 DOM(Virtual DOM)**이라는 영리한 기법과 결합하여 시대를 평정했습니다. 가상 DOM은 메모리에 가벼운 페이지 사본을 유지하고, 변경 사항이 있을 때마다 이를 비교(diff)하여 실제로 변경된 진짜 DOM 노드만 건드리는 방식입니다.
이후 수많은 프레임워크가 꽃을 피웠습니다. Vue는 진입 장벽을 낮추었습니다. Angular(2010년의 죽은 "AngularJS"가 아닌, 성숙하게 재작성된 버전)는 기업형 구조와 TypeScript를 제공했습니다. Svelte는 왜 프레임워크 자체를 브라우저로 보내야 하는지 의문을 제기하며 스스로를 컴파일하여 사라지게 만들었습니다. Solid는 JSX를 유지하되 가상 DOM을 버리고 정밀한 직접 업데이트를 선택했습니다. 오늘날 이들 모두가 수렴하고 있는 개념은 바로 **시그널(signal)**입니다. 시그널은 자신에게 의존하는 대상이 누구인지 알고 있어 정확히 그 대상만 업데이트하고 나머지는 건드리지 않는 값입니다.
표본 01 — 버튼이 컴포넌트가 되다 (2013년)
- 레이어 깊이: 6m
- 더 이상 마크업이 아닙니다. 마크업인 척하는 JavaScript입니다.
function Buy() { return ( <button onClick={addToCart}> Buy </button> ) }
이제 버튼은 상태(state), 속성(props), 부모 트리를 가집니다. 브라우저 내에 프레임워크 런타임 없이는 존재할 수 없습니다. 이 버튼을 화면에 띄우기 위해서는 조만간 빌드 단계가 필요해집니다.
-
코드 소스 크기: 약 140 바이트
-
동반 설치 파일: React 런타임 약 45 KB
-
필요 빌드 단계: 1개 (앞으로 계속 늘어납니다)
-
프레임워크들: React, Vue.js, Angular, Svelte, Solid, Preact, Qwik, Lit
공룡의 탈출구
모두가 이 길을 선택한 것은 아닙니다. htmx, Alpine.js, Rails의 Hotwire 같은 고집스럽고 점점 세력을 넓혀가는 진영은 애초에 서버를 떠난 것 자체가 원죄였다고 주장하며, 'HTML-over-the-wire'(네트워크를 통한 HTML 전송)를 다시 가져오고 있습니다. 이 레이어를 보며 향수에 젖으셨다면 이 진영이 여러분에게 딱 맞을 것이며, 암반(bedrock) 단계에서 다시 다루겠습니다.
레이어 III — 깊이 15m (2012 – 2018)
빌드 단계 (The Build Step)
"왜 이제는 그냥 파일을 더블 클릭해서 열 수 없나요?"
여러분이 가장 원망하는 레이어일 테니, 이게 왜 존재하는지 솔직하게 털어놓아 봅시다. JavaScript가 페이지 '전체'를 구축하게 되었을 때, 두 가지 사실이 충돌했습니다. 첫째, JavaScript는 생애 대부분 동안 코드를 여러 파일로 쪼개는 실질적인 방법(import)이 없었습니다. 그래서 커뮤니티는 서로 경쟁하는 모듈 시스템(Node의 CommonJS require, 그리고 훗날 공식 표준이 된 ES Modules import)을 발명했고, 이들은 오늘날까지도 완전히 호환되지 않습니다. 둘째, 여러분은 구형 브라우저가 이해하지 못하는 최신 문법과 JSX를 작성하고 싶어 했습니다.
그리하여 번역 레이어가 등장했습니다. Babel은 내일의 JavaScript(및 JSX)를 어제의 브라우저가 이해할 수 있는 JavaScript로 트랜스파일(transpile)하여 어떤 브라우저에서도 실행되도록 했습니다. 그리고 번들러(bundler)(과거의 왕은 webpack)는 수백 개의 작은 파일들을 몇 개로 꿰맸습니다. 이전 버전의 HTTP 프로토콜 하에서는 수백 개의 요청을 개별적으로 보내는 것이 느렸기 때문입니다. 그 과정에서 코드를 [압축(minify)](https://en.wikipedia.org/wiki/Minification_(programming), 공백 제거)하고, [트리 쉐이킹(tree-shaking)](https://en.wikipedia.org/wiki/Tree_shaking, 쓰이지 않는 코드 삭제)을 수행하며, 결과를 덩어리(chunk)로 쪼개고, 원본 코드를 디버깅할 수 있도록 소스 맵(source map)을 내보냅니다. 이러한 작업들의 묶음이 바로 우리가 말하는 "빌드"입니다.
그리고 그 대가는 무엇일까요? 바로 node_modules 폴더입니다. 여러분의 의존성, 그 의존성의 의존성, 그리고 또 그 의존성의 의존성들이 모여 사는 곳이죠. 아무것도 없는 시작용 프로젝트조차 통상 25만 개의 파일을 다운로드합니다. 우주에서 가장 무거운 물체이며, 지금 이 순간에도 여러분의 프로젝트 폴더에 자리 잡고 있습니다.
여러분의 22바이트짜리 버튼은 이제 여러분이 작성하지도 않았고 읽을 수도 없는 설정 파일에 의해 조립되어 2메가바이트 크기의 번들로 제공됩니다.
레이어 IV — 깊이 21m (2018 – 2024)
도구들의 군비 경쟁 (The Tooling Arms Race)
"좋아요, 빌드가 있는 건 인정할게요. 하지만 제발 90초씩 걸리게 하지는 마세요."
빌드는 성공적이었지만 느렸고, webpack 설정은 개발자들 사이에서 저주받은 두루마리처럼 전수되는 흑마법이 되어버렸습니다. 다음 상처는 순전히 도구의 불편함에서 오는 고통이었습니다. 해결책은 이 도구들을 JavaScript가 아닌, 컴파일 속도가 빠른 언어인 Go와 Rust로 다시 작성하는 것이었습니다.
esbuild(Go)는 번들링 속도를 10~100배 빠르게 만들며 기존 도구들을 무색하게 만들었습니다. SWC(Rust)는 주요 프레임워크 내부에서 Babel을 대체했습니다. 그리고 Vite는 이 모든 것을 결합하여 오늘날 대부분의 사람들이 기본적으로 선택하는 도구가 되었습니다. 개발 단계에서의 즉시 시작(브라우저 고유의 모듈 기능과 esbuild를 활용), 프로덕션용 최적화 빌드, 그리고 코드를 수정하고 저장하면 화면을 새로고침하지 않고도 변경 사항을 즉시 반영해 주는 HMR(Hot Module Replacement)을 제공합니다. 2026년 현재 Vite의 프로덕션 번들러는 Rust 기반의 Rolldown으로 대체되고 있으며, 전체 스택은 Cloudflare가 인수한 VoidZero라는 회사 아래로 통합되고 있습니다.
이러한 "속도를 위한 재작성" 바람은 패키지 매니저(pnpm과 영리한 공유 저장소 기법, 올인원 툴인 Bun)와 프레임워크용 번들러(Turbopack, Rspack)에도 불어닥쳤습니다. 이 레이어를 단 한 문장으로 요약한다면 모든 기술 컨퍼런스에서 메아리쳤던 이 말일 것입니다.
"Rust로 새로 짰더니 50배 빨라졌습니다."
- 도구들: Vite, esbuild, SWC, Rolldown, Turbopack, Rspack, Oxc, VoidZero, pnpm, Bun, Deno
- 요약: 이 레이어의 거의 모든 것이 Rust 또는 Go로 작성되었습니다. 그것이 핵심입니다.
레이어 V — 깊이 28m (2014 – 2026)
서버로의 회귀 (The Server Homecoming)
"제 멋진 앱이 하얀 빈 화면만 보여주고 구글 검색 엔진이 인식하지 못해요."
이제 모든 것을 JavaScript로 처리하는 앱은 피할 수 없는 문제에 직면했습니다. 서버가 빈 <div>와 산더미 같은 JS만 보내주었기 때문에, 사용자는 그 막대한 JS가 다운로드되고 실행될 때까지 하얀 빈 화면을 멍하니 쳐다보고 있어야 했습니다. 검색 엔진 크롤러 역시 빈 <div>만 보고 아무것도 없는 페이지라고 판단했습니다. 콘텐츠 비즈니스에 있어 이는 치명적이었습니다. (심지어 구글은 Core Web Vitals라는 지표로 성능을 수치화하여, 페이지가 느리면 검색 순위에서 불이익을 주기 시작했습니다.)
해결책은 다시 서버에서 HTML을 렌더링하는 것이었습니다. 즉, 2008년에 여러분이 하던 짓을 정확히 그대로 하는 것입니다. 이 시점에서 알파벳 약어들이 우후죽순 생겨났으니, 한 번에 정리해 드리겠습니다.
- SSR (Server-Side Rendering): 요청이 들어올 때마다 서버에서 페이지를 렌더링합니다.
- SSG (Static Site Generation): 빌드 시점에 페이지를 미리 렌더링해 둡니다(옛날의 정적 사이트에 도구가 추가된 형태).
- ISR (Incremental Static Regeneration): 정적으로 생성된 페이지를 백그라운드에서 주기적으로 갱신합니다.
그리고 이 모든 것을 조율하는 **메타 프레임워크(meta-framework)**가 오늘날 대부분의 개발자가 개발을 시작하는 실질적인 기준이 되었습니다. 바로 Next.js(React), Astro(콘텐츠 중심, JS 거의 배송 안 함), SvelteKit, Nuxt(Vue), Remix(현재 React Router에 병합됨) 등이 이에 해당합니다.
하지만 브라우저용으로 설계된 프레임워크에 서버가 생성한 HTML을 전달하는 방식은 현대 프레임워크 역사상 가장 뼈아픈 상처인 **하이드레이션(hydration)**을 낳았습니다.
하이드레이션의 3단계
- 서버에서 요리하기: 서버가 컴포넌트를 실행하여 완성된 HTML을 보냅니다. 화면이 즉시 그려집니다. 완성된 것처럼 보입니다.
- 하지만 작동하지 않음: 아직 아무 버튼도 작동하지 않습니다. 이 HTML은 UI의 '사진'일 뿐 진짜 UI가 아닙니다. 이벤트 핸들러가 연결되어 있지 않기 때문입니다.
- 대가를 다시 지불하기: 브라우저는 모든 JS를 다시 다운로드하고 동일한 앱을 한 번 더 실행하여 화면을 "깨웁니다". 그 순간 동안 사용자는 작동하는 것처럼 보이지만 실제로는 먹통인 버튼을 분노의 클릭질(rage-click)을 하게 됩니다.
하이드레이션은 한 번은 서버에서 요리하고, 또 한 번은 브라우저에서 똑같은 요리를 해서 먹을 수 있는 건지 확인하는 방식으로, 밥값을 두 번 내는 꼴입니다.
이후 유행하는 모든 기술은 이 하이드레이션을 어떻게든 줄여보기 위한 설계입니다.
- 아일랜드 아키텍처(Islands)(Astro): 페이지를 정적으로 유지하고 실제 상호작용이 필요한 몇몇 '섬'들만 하이드레이션합니다.
- 재개 가능성(Resumability)(Qwik): 하이드레이션 단계를 완전히 생략합니다.
- React Server Components (RSC): 현대 React에서 가장 혼란스러운 개념으로, 컴포넌트가 서버에서만 실행되도록 하고 브라우저에는 자바스크립트를 전혀 전송하지 않으며, 상호작용이 필요한 부분에만
"use client"표시를 달아둡니다.
매우 영리하지만 그만큼 어렵습니다. 여러분이 자리를 비운 사이 세상이 바뀌었음을 실감하게 해주는 단 하나의 단어를 고르라면 바로 RSC일 것입니다.
레이어 VI — 깊이 34m (2015 – 2026)
어른들을 위한 추가 도구들 (The Grown-up Bolt-ons)
"코드베이스를 도저히 유지보수할 수 없고, 매번 똑같은 드롭다운을 처음부터 다시 만들고 있어요."
앱이 이 정도로 커지면서 두 가지 새로운 상처가 생겼습니다. 안전하게 리팩토링을 할 수 없다는 점과, 똑같은 위젯을 끝없이 다시 만들고 있다는 점이었습니다. 솔직히 이곳의 해결책들은 가장 도입할 가치가 있는 기술들입니다.
TypeScript는 JavaScript에 타입 시스템을 장착하여 코드를 작성하는 동안 수많은 버그를 잡아주고 에디터에 강력한 자동완성을 제공합니다. 여러분이 떠난 이후 일어난 가장 큰 단일 변화이며, 완벽히 승리하여 이제는 도구 체인들이 성능 향상을 위해 컴파일러를 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년의 버튼
- 레이어 깊이: 47m
- 타입이 지정되고, 하이드레이션되며, 디자인 토큰이 적용되고, 패키지 설치가 아닌 직접 복사해 넣었으며, 서버 바운딩된 버튼.
<Button variant="default" size="sm" onClick={addToCart} > Buy </Button>
(여기에 빌드 설정, 타입 시스템, CSS 엔진, 접근성, 런타임을 위한 47개의 파일이 배경으로 작동하고 있습니다)
기본적으로 접근성을 지원하며, 디자인 토큰을 통한 테마 관리와 끝에서 끝까지 보장되는 타입 검사를 탑재하고 있습니다. 솔직히 말해 훨씬 더 나은 버튼입니다. 다만 "Buy"라는 글자 하나를 렌더링하기 위해 전체 생태계가 동원되어야 했을 뿐입니다.
-
코드 소스 크기: 약 90 바이트
-
동반 설치 파일: node_modules 내부의 약 25만 개 파일
-
필요 빌드 단계: 필수적으로 필요
-
보완 도구들: TypeScript, Tailwind CSS, shadcn/ui, Radix UI, MUI, daisyUI, TanStack Query, Zod, Vitest, Playwright, ESLint, Prettier, Biome, Storybook
레이어 VII — 깊이 39m (2015 – 2026)
다시 쉬워진 배포 (Deploying Like It's Easy Again)
"좋아요. 그럼 이걸 인터넷에 어떻게 올리나요?"
오로지 좋은 소식만 가득한 레이어입니다. 파일질라(FileZilla)로 파일을 끌어다 넣고 기도하던 시절을 기억하시나요? 이제는 과거의 일입니다. 이제는 Git 저장소를 Vercel, Netlify, 또는 Cloudflare에 연결하기만 하면 git push를 할 때마다 사이트가 자동으로 빌드되고 배포됩니다. 풀 리퀘스트(PR)를 생성하면 해당 변경 사항이 적용된 실제 작동하는 프리뷰 URL을 즉시 받게 됩니다. 미래의 이 부분은 2008년에 비해 논란의 여지없이 훨씬 훌륭합니다.
기억해야 할 두 가지 개념이 있습니다. 서버리스(Serverless) 함수는 서버를 직접 운영하지 않고도 백엔드 코드를 실행할 수 있게 해 줍니다. 에지(Edge) 컴퓨팅은 단 하나의 데이터센터가 아닌, 전 세계에 흩어진 사용자 근처의 수백 개의 데이터센터에서 코드를 실행하여 지구 전체를 원천(origin)으로 사용합니다.
웹 기술로 모바일이나 데스크톱 앱을 만들고 싶다면 네이티브 앱 개발을 위한 React Native/Expo, 데스크톱 앱을 위한 Tauri나 Electron이 있습니다. (Electron은 채팅 창 하나를 띄우기 위해 브라우저 전체를 동봉하는 반면, Tauri는 컴퓨터에 이미 설치된 브라우저 엔진을 활용합니다.)
- 호스팅 및 에지 기술: Vercel, Netlify, Cloudflare, GitHub Pages, Expo, React Native, Tauri, Electron
레이어 VIII — 깊이 44m (2023 – 2026)
로봇이 코드를 씁니다 (The Robot Writes It Now)
"솔직히 기계가 저 대신 React 코드를 다 짜줄 수는 없나요?"
가장 깊고 최신의 레이어이자, 많은 이들이 다시 이 생태계를 들여다보게 만든 계기입니다. 이제 평범한 영어로 만들고 싶은 UI를 묘사하면 v0, Lovable, Bolt가 실제로 작동하는 프론트엔드를 뚝딱 만들어 줍니다. 그리고 Cursor, Claude Code, Copilot 같은 에디터 도구들은 여러분이 타이핑하는 동안 반복적인 상용구 코드(boilerplate)를 채워줍니다. 안드레 카파시(Andrej Karpathy)가 이름 붙인 **바이브 코딩(vibe coding)**이라는 신조어도 등장했습니다. 단, 생성된 결과물이 어떻게 돌아가는지 여전히 이해하고 있어야 한다는 단서 조항은 잊지 마세요.
이 때문에 개발 분야 간의 경계도 모호해지고 있습니다. 백엔드나 시스템 엔지니어도 반나절 만에 그럴듯한 프론트엔드를 빚어낼 수 있게 되었습니다. 이는 훌륭하지만 동시에 묘한 어지럼증을 선사합니다. 인공지능이 생성한 코드는 조용히 여러분이 위에 설명한 8개의 레이어 지식을 전부 꿰뚫고 있다고 가정하기 때문입니다. 로봇이 작성한 코드와 여러분이 실제로 이해하는 지식 사이의 간극, 바로 그 간극을 메우기 위해 이 지도가 존재하는 것입니다.
- AI 및 코드 생성: v0, Lovable, Bolt, Cursor, Claude Code, GitHub Copilot, Windsurf
암반 (Bedrock) — 깊이 44m · 2026년
44미터를 팠고, 마침내 자기 집 앞마당에 도달했습니다.
이 지하 깊은 곳에 있는 것이 바로 우리가 이 여정을 떠날 가치가 있었던 이유입니다. 2026년의 최전선, 업계에서 가장 예리한 사람들이 흥분하고 있는 대상은 바로 서버에서 HTML을 렌더링하고, 자바스크립트를 거의 전송하지 않으며, 웹 플랫폼과 싸우는 대신 웹 플랫폼을 그대로 활용하는 것입니다. Astro, 아일랜드 아키텍처, 서버 컴포넌트, htmx, 그리고 "추가 다시 돌아오고 있다"는 외침들. 이 모든 것들이 한곳을 가리키고 있습니다. CDN에서 제공되는, 대부분 HTML로만 구성된 빠른 웹 페이지입니다.
즉, 20년의 세월과 44미터에 달하는 빌드 도구, 번들러, 하이드레이션 설계의 숲을 해치고 달린 끝에, 업계는 거대한 원을 그리며 질주하여 마침내 조금 숨을 헐떡이며 여러분이 FTP로 올리곤 했던 그 파일과 아주 비슷한 지점에 도달한 것입니다. 우리의 본능은 사라지지 않았습니다. 땅이 움직인 데에는 다 실질적인 이유가 있었고, 이제 땅은 원래 자리로 되돌아왔습니다.
동네 책방 (The Corner Bookshop)
환영합니다. 책장을 살펴보거나 책을 바로 구매해 보세요.
빌드 단계 없이 HTML로만 제공되며, 크기는 약 3KB입니다. 이 캡션을 다 읽기도 전에 이미 로딩이 완료되었습니다.
이 거대한 성당 전체를 다시 배울 필요는 없습니다. 전체 구조물에서 하중을 버티는 핵심 20%가 무엇인지 학습하고, 나머지 80%는 그냥 지나쳐도 무방한 뷔페 음식으로 여기면 됩니다. 다음 섹션은 바로 이를 돕기 위한 필드 키트입니다. 돌아오신 것을 환영합니다. 여러분은 늦은 것이 아니라 오히려 너무 빨리 오셨던 것입니다.
필드 키트 (The Field Kit)
처방전이 아니라 시작할 때 골라 잡을 수 있는 뷔페입니다. 다음은 널리 쓰이고 잘 지원되는 기본 조합이며, 유일한 정답은 아닙니다.
1. 콘텐츠 사이트 / 블로그 / 마케팅
직관에 가깝게 유지하기
- 프레임워크: Astro (자바스크립트를 거의 배송하지 않음)
- 스타일링: Tailwind CSS 또는 현대적인 일반 CSS
- 배포: Vercel · Netlify · Cloudflare (git push로 배포)
혹은 더 단순하게 가도 좋습니다. 여러분이 이미 잘 알고 있는 백엔드에 htmx를 얹거나, CDN에 직접 손으로 작성한 HTML을 띄우는 것입니다. 2026년에도 여전히 완전히 유효한 방식입니다.
2. 실제 웹 애플리케이션 (로그인 기반 서비스)
안전하고 대중적인 길
- 메타 프레임워크: React + Next.js (가장 문서화가 잘된 조합)
- 인프라: TypeScript · Tailwind CSS · shadcn/ui
- 데이터 및 상태: TanStack Query + Zustand
- 검증: Zod (모든 입출력 데이터 검증)
인공지능 도구들이 기본적으로 추천하는 조합이기도 합니다. 이는 곧 수많은 튜토리얼과 구인 정보가 존재하며, 막혔을 때 답변을 얻기 가장 쉽다는 뜻입니다.
3. 어떤 경로든 하단에 위치할 도구 벨트
한 번 고르고 잊어버리세요
- 빌드 툴: Vite 또는 사용 중인 프레임워크의 CLI
- 패키지 매니저: pnpm 또는 Bun (npm보다 빠른 속도)
- 포맷터 & 린터: Prettier + ESLint 혹은 둘을 모두 대체하는 Biome
- 테스트: Vitest + Playwright (단위 테스트 및 E2E 테스트)
git push로 배포해 보세요. 아마도 여러분의 인생에서 webpack 설정을 직접 열어볼 일은 다신 없을 것입니다. 아주 좋은 변화죠.
약어 및 개념 해독기 (The Acronym Decoder)
- 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/export)과 Node.js의 과거 표준(require/module.exports). - JSX: 자바스크립트 내부에 HTML 형태로 작성하는 문법. 브라우저가 직접 해석할 수 없어 컴파일 단계를 거쳐야 합니다. 진짜 HTML이 아닙니다.
- CWV (Core Web Vitals): 구글이 정의한 웹 페이지 속도 측정 지표(렌더링 속도, 반응성, 레이아웃 흔들림 등). 검색 순위 결정의 중요한 요소가 되었습니다.
- The edge (에지): 하나의 원격 데이터센터가 아닌, 전 세계에 흩어진 사용자 근처의 수백 개 CDN 노드에서 서버 코드를 바로 실행하는 방식.
댓글
댓글을 작성하려면 이 필요합니다.