프론트엔드 프레임워크 심층 가이드
서문
HTML, CSS, JavaScript 기초를 배웠고 간단한 웹페이지를 만들 수 있게 되었습니다. 하지만 웹페이지 기능이 점점 복잡해지면서 알게 될 것입니다. 네이티브 JavaScript로 코드를 작성하면 유지보수가 어렵고, 한 곳을 수정하면 여러 곳을 손봐야 하며, 여러 사람이 협업할 때 자주 충돌이 발생한다는 것을요.
이것이 바로 프론트엔드 프레임워크가 필요한 이유입니다. 코드를 더 체계적으로 만들고, 유지보수를 쉽게 하며, 더 효율적으로 개발할 수 있게 해줍니다. vibecoding에서는 AI가 대부분의 코드를 작성해 주지만, 최소한 다양한 프레임워크의 코드 스타일을 읽을 수 있고 각각의 장단점을 알아야 AI가 가장 적합한 기술 스택을 선택할 수 있도록 도와줄 수 있습니다.
이 글을 읽고 나면 다음을 할 수 있습니다:
- 프론트엔드 기술이 왜 계속 발전해야 하는지 이해한다
- Vue, React, Svelte, Angular의 각 특징을 안다
- "데이터 주도", "컴포넌트화"와 같은 핵심 개념을 이해한다
- 프로젝트에 맞는 프레임워크를 선택할 수 있다
이 글에서 무엇을 배울 수 있을까요?
| 장 | 내용 | 배우고 나면 할 수 있는 것 |
|---|---|---|
| 제 1 장 | 프론트엔드 발전에 주목해야 하는 이유 | 기술 발전이 어떤 문제를 해결하려는 것인지 이해한다 |
| 제 2 장 | 정적 웹페이지 시대 | 가장 초기의 웹페이지 개발 방식을 이해한다 |
| 제 3 장 | jQuery 시대 | "명령형" 프로그래밍의 문제점을 이해한다 |
| 제 4 장 | Vue/React 시대 | "선언형"과 "데이터 주도" 사상을 습득한다 |
| 제 5 장 | 렌더링 전략 | CSR, SSR, SSG의 차이와 적용 시나리오를 안다 |
| 제 6 장 | 엔지니어링 도구 | Webpack, Vite 등 빌드 도구의 역할을 이해한다 |
각 장은 "왜 이 기술이 필요한가"에서 시작하여 기술 발전 이면의 논리를 이해할 수 있게 합니다.
1. 프론트엔드 발전사를 주목해야 하는 이유는?
🤔 핵심 질문
왜 웹페이지는 점점 복잡해질까? 프론트엔드 기술은 왜 계속 발전해야 할까? 이 질문은 단순한 웹페이지에서 현대적인 웹 애플리케이션으로의 기술 발전 여정을 이해하도록 이끌어줄 것입니다.
1.1 "전자 포스터"에서 "데스크톱 애플리케이션"으로
거리에서 보는 포스터를 상상해 보세요:
- ✅ 콘텐츠가 있다 (텍스트, 이미지)
- ✅ 디자인이 있다 (색상, 레이아웃)
- ❌ 하지만 말을 걸어도 반응하지 않는다
- ❌ 어딘가를 클릭해도 아무 일도 일어나지 않는다
가장 초기의 웹페이지는 바로 이런 "전자 포스터"였습니다: 보기만 가능하고, 수정할 수 없으며, 콘텐츠는 고정되어 있었습니다.
현대의 웹페이지는 완전히 다릅니다. 데스크톱 애플리케이션(VS Code, Figma)과 같습니다:
- ✅ 문서 편집, 그림 그리기, 게임 플레이가 가능하다
- ✅ 모든 동작에 실시간으로 반응한다
- ✅ 오프라인에서도 작업할 수 있다
이 전환의 핵심 원인: 웹페이지의 기능이 점점 복잡해지면서 더 효율적인 기술과 개발 방식이 필요해졌다.
1.2 일상적인 비유: 집 짓기
프론트엔드 기술의 발전은 집을 짓는 방식의 진화와 같습니다:
| 시대 | 🏠 집 짓기 비유 | 실제 특징 | 장단점 |
|---|---|---|---|
| 2000년대 | 포스터 붙이기 | 정적 웹페이지, HTML만 작성하면 됨 | ✅ 간단함 ❌ 상호작용 불가 |
| 2010년대 | 인부를 불러 수동 인테리어 | jQuery 시대, 각 요소를 수동으로 조작 | ✅ 상호작용 가능 ❌ 코드가 지저분하고 유지보수 어려움 |
| 2020년대 | 레고로 집 짓기 | Vue/React 시대, 컴포넌트화 개발 | ✅ 효율적, 유지보수 가능 ❌ 학습 곡선 존재 |
💡 표에서 무엇을 알 수 있나요?
1단계 → 2단계: "움직일 수 없는 것"에서 "움직일 수 있는 것"으로. 이는 질적 도약입니다. 웹페이지에 상호작용이 생기기 시작했지만, 그 대가로 코드가 혼란스러워졌습니다.
2단계 → 3단계: "사용할 수 있는 것"에서 "잘 사용할 수 있는 것"으로. 컴포넌트화는 코드를 블록처럼 재사용 가능하게 만들어 개발 효율을 크게 향상시킵니다.
핵심 사상: 기술 발전은 "새로움을 위한 새로움"이 아니라, 이전 단계의 문제점을 해결하기 위한 것입니다.
2. 1단계: 정적 웹페이지와 "이미지 슬라이싱" (2000년대)
🤔 핵심 질문
가장 초기의 웹페이지는 어떤 모습이었을까? 왜 그때는 프레임워크가 필요 없었을까? 이 단계의 한계를 이해해야 이후 기술 발전의 필요성을 이해할 수 있습니다.
I. The Static Era
Web pages were just digital documents. The server sent HTML, and the browser rendered it. Want new content? Refresh the whole page.
<html>
<body>
<h1>Hello World</h1>
<p>Static content served by server.</p>
</body>
</html>2.1 이 시대는 어떤 모습이었나?
개발 방식:
- HTML 파일 몇 개를 작성
- CSS와 JavaScript를 인라인으로 포함
- 파일을 브라우저에 직접 드래그하면 결과를 볼 수 있음
- 폴더를 서버에 업로드하면 배포 완료
특징:
- ✅ 장점: 간단하고 직관적이며, 학습 비용이 없고, 작성하면 바로 실행됨
- ❌ 단점: 복잡한 상호작용을 구현할 수 없고, 코드가 많아지면 바로 지저분해짐
당시 프로젝트 구조 보기
project/
├── index.html
├── login.html
├── css/
│ ├── bootstrap.css
│ └── custom.css
├── js/
│ ├── jquery.js
│ └── app.js
└── images/발생한 문제들:
- 전역 변수 오염: 모든 변수가 전역 네임스페이스에 있어 서로 덮어쓰기 쉬움
- 의존성 관리 혼란: 올바른 순서로 JS 파일을 로드해야 하며, 그렇지 않으면 오류 발생
- 코드 재사용 어려움: 특정 기능을 재사용하려면 복사-붙여넣기만 가능
2.2 "이미지 슬라이싱"이란?
"이미지 슬라이싱"이라는 말을 들어본 적이 있을 것입니다. 이는 초기 프론트엔드의 주요 작업이었습니다:
이미지 슬라이싱이란?
디자이너가 Photoshop으로 페이지 디자인 → 프론트엔드 개발자가 디자인을 작은 이미지로 자름 → HTML로 이미지를 조합하여 페이지 구성
왜 이렇게 느렸을까?
웹페이지의 각 작은 이미지마다 브라우저는 네트워크 요청을 한 번씩 보내야 했습니다. 요청이 많을수록 로딩이 느려집니다.
👇 직접 해보세요: 이미지 요청이 로딩 성능에 미치는 영향을 관찰해 보세요
💡 스프라이트 이미지 (Sprite)
요청 수를 줄이기 위해 "스프라이트 이미지" 기술이 등장했습니다: 여러 작은 이미지를 하나의 큰 이미지로 합치는 것입니다.
장점은 요청 수가 줄어든다는 것이고, 단점은 제작과 유지보수가 모두 번거롭다는 것입니다.
이 단계의 교훈: 요청이 너무 많으면 성능의 적이다.
3. 2단계: jQuery 시대 - "수동 벽돌 나르기" (2010년대)
🤔 핵심 질문
왜 jQuery가 필요했을까? 어떤 문제를 해결했고, 어떤 새로운 문제를 가져왔을까? jQuery의 한계를 이해해야 Vue/React의 가치를 이해할 수 있습니다.
3.1 왜 jQuery가 필요했나?
웹페이지가 복잡해지면서 네이티브 JavaScript의 문제점이 드러났습니다:
- ❌ API가 번거로움: 간단한 작업도 많은 코드를 작성해야 함
- ❌ 브라우저 호환성: 브라우저마다 API가 달라 많은 호환성 코드를 작성해야 함
- ❌ 선택자 약함: 요소를 찾는 것이 매우 불편함
jQuery가 탄생했습니다. JavaScript를 간단하게 만들어 주었습니다:
// 네이티브 JavaScript (번거로움)
const element = document.getElementById('title')
// jQuery (간결함)
const element = $('#title')3.2 jQuery의 사고방식: 직접 페이지를 수정하기
jQuery의 핵심 사고방식은 명령형입니다: 브라우저에게 "어떻게 할지"를 알려줍니다.
// 제목 요소 찾기
$('#title').text('새 제목')
// 버튼을 찾아 비활성화
$('#submit-btn').attr('disabled', true)
// 목록을 찾아 항목 추가
$('ul').append('<li>새 항목</li>')문제점: 페이지에 어떤 요소가 있는지 기억해야 하고, 데이터가 변경될 때마다 모든 관련 요소를 수동으로 업데이트해야 합니다.
👇 직접 해보세요: jQuery와 데이터 주도 방식의 차이를 비교해 보세요
⚠️ jQuery의 문제점
장바구니를 만든다고 상상해 보세요:
// 사용자가 "장바구니에 추가" 클릭
function addToCart() {
cartCount++ // 데이터 변경
// 모든 관련 위치를 수동으로 업데이트해야 함
$('#cart-count').text(cartCount) // 오른쪽 상단 빨간 점
$('#cart-page-count').text(cartCount) // 장바구니 페이지
$('#checkout-price').text(calculatePrice()) // 결제 버튼
// 한 곳이라도 빠뜨리면 페이지가 일관되지 않게 된다!
}이것이 "수동 벽돌 나르기"의 대가입니다: 오류가 발생하기 쉽고 유지보수가 어렵습니다.
3.3 모바일 보급: 반응형 디자인의 등장
이 단계에서는 또 하나의 중요한 변화가 있었습니다: 휴대폰과 태블릿이 대중화되기 시작했습니다.
웹페이지는 다양한 화면에 적응해야 했습니다. 이를 위해 반응형 레이아웃이 필요했습니다: 동일한 HTML/CSS로 화면 너비에 따라 자동으로 레이아웃이 변경됩니다.
반응형 레이아웃의 핵심: 미디어 쿼리 (Media Query)
/* 데스크톱 화면 (640px 이상) */
@media (min-width: 640px) {
.container {
display: flex;
}
}
/* 모바일 화면 (640px 이하) */
@media (max-width: 640px) {
.container {
display: block;
}
}👇 직접 해보세요: 브라우저 너비를 조정하여 반응형 레이아웃의 효과를 관찰해 보세요
💡 반응형은 "스마트 액자"와 같습니다
서로 다른 방에서 같은 사진을 본다고 상상해 보세요:
- 넓은 거실(데스크톱 화면)에서는 사진을 크게 두고, 옆에 다른 장식품도 놓을 수 있습니다
- 작은 침실(모바일 화면)에서는 사진을 줄이고, 다른 장식품은 치워야 합니다
반응형 레이아웃은 "스마트 액자"로, 방 크기에 따라 자동으로 표시 방식을 조정합니다.
4. 3단계: "수동 벽돌 나르기"에서 "데이터 주도"로 (Vue/React)
🤔 핵심 질문
왜 Vue/React가 필요할까? jQuery와의 본질적인 차이는 무엇일까? "선언형"과 "데이터 주도"를 이해하는 것이 현대 프론트엔드 프레임워크를 습득하는 열쇠입니다.
4.1 왜 새로운 프레임워크가 필요했나?
jQuery 시대의 문제가 일정 수준까지 쌓였습니다:
- 코드가 많아지면 바로 지저분해짐: 도처에 DOM 조작이 흩어져 유지보수가 어려움
- 버그 발생 쉬움: 한 곳이라도 업데이트를 빠뜨리면 페이지가 일관되지 않음
- 협업 어려움: 여러 사람이 같은 파일을 수정하면 충돌하기 쉬움
Vue / React의 핵심 사고방식: 데이터만 변경하면 페이지가 자동으로 업데이트된다.
4.2 Vue/React의 사고방식: 선언형 UI
jQuery (명령형):
// 브라우저에게 매 단계마다 어떻게 할지 알려줘야 함
$('#title').text('새 제목')
$('#title').css('color', 'red')
$('#title').show()Vue (선언형):
// "무엇을 표시할지"만 알려주면 됨
data() {
return {
title: "새 제목",
color: "red",
visible: true
}
}👇 직접 해보세요: 명령형과 선언형의 차이를 비교해 보세요
// Manually operate the DOM
$('#count').text(val);
if (val > 5) $('#msg').show(); // Bind data only
{{ count }}
<div v-if="count > 5">...</div> 💡 명령형 vs 선언형
그림을 그리는 것에 비유하면:
- 명령형: 화가에게 "붓을 들고, 빨간 물감을 찍고, 좌표 (10,10)에 원을 그려"라고 지시하는 것
- 선언형: 화가에게 사진 한 장을 주며 "이렇게 그려줘"라고 하는 것
Vue/React는 "선언형"입니다: "페이지가 어떻게 생겼는지"를 설명하면, 프레임워크가 "어떻게 그릴지"를 책임집니다.
4.3 컴포넌트화: 레고를 조립하듯 페이지를 작성하기
Vue / React의 가장 강력한 특징은 컴포넌트화입니다: 페이지를 독립적인 "블록"으로 분해합니다.
레고를 조립한다고 상상해 보세요:
- "처음부터 모든 블록을 조각할" 필요가 없습니다 (HTML/CSS를 처음부터 작성할 필요 없음)
- "설명서에 따라 블록을 조립하기만" 하면 됩니다 (컴포넌트를 조합)
- 각 블록은 독립적이며, 다른 세트에서도 재사용할 수 있습니다
컴포넌트의 장점:
- 재사용: "상품 카드" 컴포넌트를 한 번 작성하면 100번 사용 가능
- 캡슐화: 컴포넌트 내부의 상태가 다른 컴포넌트에 영향을 주지 않음
- 유지보수: 컴포넌트 하나를 수정하면, 사용된 모든 곳이 업데이트됨
💡 식별 팁
<ComponentName />→ 컴포넌트입니다import xxx from './xxx.vue'→ 컴포넌트를 가져오는 중입니다props: {...}→ 컴포넌트가 받는 매개변수입니다emit('xxx')→ 컴포넌트가 부모 컴포넌트에 이벤트를 보내는 중입니다
4.4 SPA: 단일 페이지 애플리케이션의 탄생
Vue / React 시대의 또 다른 중요한 변화: MPA에서 SPA로.
MPA (Multi-Page Application):
- 링크 클릭 → 전체 페이지 새로고침 → 새 페이지 표시
- 책을 넘기는 것과 같습니다: 페이지를 넘길 때마다 책을 덮고, 책장에서 새 책을 가져와야 함
SPA (Single-Page Application):
- 링크 클릭 → 콘텐츠 영역만 새로고침 → 페이지는 새로고침되지 않음
- 같은 책 안에서 장을 바꾸는 것과 같습니다: 이전 내용만 지우고 새 내용을 써넣음
👇 직접 해보세요: MPA와 SPA의 차이를 체험해 보세요
SPA의 장점:
- ✅ 매끄러운 경험: 페이지 전환이 빠름
- ✅ 상태 관리 용이: 입력한 내용, 스크롤 위치가 유지됨
- ❌ 첫 화면이 느릴 수 있음: JavaScript를 먼저 다운로드해야 함
- ❌ SEO 추가 처리 필요: 검색 엔진이 콘텐츠를 수집하지 못할 수 있음 (SSR/SSG 필요)
5. 렌더링 전략: CSR에서 SSR/SSG로
🤔 핵심 질문
페이지는 서버에서 생성될까, 브라우저에서 생성될까? 렌더링 전략마다 장단점이 있으며, 적절한 전략을 선택하는 것이 성능과 SEO에 매우 중요합니다.
CSR (Client-Side Rendering) 클라이언트 사이드 렌더링:
- 브라우저가 JavaScript 다운로드 → 코드 실행 → 페이지 생성
- 장점: 상호작용이 부드럽고, 서버 부담이 적음
- 단점: 첫 화면이 느리고, SEO에 불리함
SSR (Server-Side Rendering) 서버 사이드 렌더링:
- 서버가 HTML 생성 → 브라우저에 전송 → 브라우저가 직접 표시
- 장점: 첫 화면이 빠르고, SEO에 유리함
- 단점: 서버 부담이 크고, 구현이 복잡함
SSG (Static Site Generation) 정적 사이트 생성:
- 빌드 시 모든 페이지의 HTML을 생성
- 장점: 매우 빠르고, 완전히 정적이며, CDN 친화적
- 단점: 동적 콘텐츠에 적합하지 않음
👇 직접 해보세요: 다양한 렌더링 전략의 특징을 비교해 보세요
💡 어떻게 선택할까?
- 콘텐츠 사이트 (블로그, 문서): SSG 우선
- SEO가 필요한 동적 사이트 (이커머스, 뉴스): SSR 사용
- 관리자 시스템: CSR 사용
- 혼합 요구사항: Nuxt/Next.js의 하이브리드 렌더링 고려
6. 4단계: 엔지니어링과 빌드 도구 (2015년대-2020년대)
🤔 핵심 질문
왜 프론트엔드에 "엔지니어링"이 필요할까? 빌드 도구는 도대체 무엇을 하는 걸까? 엔지니어링을 이해해야 현대 프론트엔드 프로젝트의 워크플로우를 이해할 수 있습니다.
6.1 왜 "엔지니어링"이 필요할까?
프론트엔드 프로젝트가 점점 커지면서 더 이상 "수동으로 스크립트를 도입하는" 방식으로는 안 됩니다.
엔지니어링은 도구와 규범을 사용하여 개발을 더 효율적으로, 코드를 더 신뢰성 있게, 협업을 더 원활하게 만드는 것입니다.
💡 엔지니어링 = "수작업 공방"에서 "현대화된 공장"으로
집에서 요리하는 것 vs 레스토랑을 운영하는 것을 상상해 보세요:
- 집에서 요리: 먹고 싶은 대로 만들면 되고, 매우 자유로움
- 레스토랑 운영: 표준화된 레시피, 규범화된 작업 절차, 통일된 원자재 구매가 필요함
프론트엔드 개발도 마찬가지입니다:
- 작은 프로젝트: 어떻게 작성하든 상관없음
- 큰 프로젝트: 통일된 코드 규범, 자동화 도구, 표준화된 프로세스가 필요함
6.2 빌드 도구: Webpack → Vite
Webpack (전통적):
- 작업 방식: 먼저 패키징, 그 다음 서비스
- 시작 시: 모든 코드를 패키징 → 서버 시작
- 문제점: 느림. 프로젝트가 클수록 시작이 느려짐 (30초 이상 걸릴 수 있음)
Vite (현대적):
- 작업 방식: 요청 시 컴파일
- 시작 시: 패키징하지 않고 바로 서버 시작
- 브라우저가 요청한 파일만 실시간으로 컴파일
- 장점: 빠름. 보통 1초 이내 시작
| 비교 항목 | Webpack | Vite | 향상 |
|---|---|---|---|
| 콜드 스타트 | 30s+ | <1s | 30배 빠름 |
| 핫 리로드 | 3-5s | <100ms | 30배 빠름 |
| 설정 파일 | 수백 줄 | 수십 줄 | 대폭 간소화 |
💡 왜 Vite가 이렇게 빠를까?
Webpack은 짐을 전부 챙겨 이사하는 것과 같습니다: 모든 물건을 먼저 포장한 다음 출발합니다.
Vite는 가볍게 여행하는 것과 같습니다: 필수품만 챙기고, 필요할 때마다 사서 씁니다.
개발 환경에서는 대부분 몇 개 파일만 수정하면 되므로, Vite는 그 몇 개 파일만 컴파일하니 당연히 빠릅니다.
7. 주요 프레임워크 비교
🤔 핵심 질문
Vue, React, Svelte, Angular는 각각 어떤 특징이 있을까? 자신에게 맞는 프레임워크는 어떻게 선택할까? 그들의 설계 철학과 사용 시나리오를 이해해야 현명한 선택을 할 수 있습니다.
7.1 4대 프레임워크 비교
| 특성 | Vue | React | Svelte | Angular |
|---|---|---|---|---|
| 설계 철학 | 점진적 프레임워크 | UI 라이브러리 | 컴파일 타임 프레임워크 | 완전한 플랫폼 |
| 학습 곡선 | ⭐⭐ 쉬움 | ⭐⭐⭐ 중간 | ⭐⭐ 쉬움 | ⭐⭐⭐⭐ 가파름 |
| 성능 | 빠름 | 빠름 | 매우 빠름 | 빠름 |
| 생태계 | 완성도 높음 | 가장 완성도 높음 | 성장 중 | 완성도 높음 |
| 패키지 크기 | 작음 | 중간 | 가장 작음 | 큼 |
| 적합한 시나리오 | 중소형 프로젝트 | 대형 프로젝트 | 높은 성능 요구 | 엔터프라이즈급 애플리케이션 |
| 회사 지원 | Evan You (독립) | Meta | 커뮤니티 |
7.2 Vue: 점진적 프레임워크
핵심 철학: 점진적 도입, 일부만 사용할 수도 있고全家桶(full bundle)을 사용할 수도 있음
<template>
<div>{{ message }}</div>
</template>
<script>
export default {
data() {
return {
message: 'Hello Vue'
}
}
}
</script>장점:
- ✅ 완만한 학습 곡선, 중국어 문서 완성도 높음
- ✅ 템플릿 문법이 직관적이고 이해하기 쉬움
- ✅ 단일 파일 컴포넌트(.vue) 구조가 명확함
- ✅ 빠른 개발에 적합
단점:
- ❌ 대형 프로젝트의 상태 관리는 Vuex/Pinia 추가 학습 필요
- ❌ 유연성이 React보다 약간 부족
적용 시나리오:
- 중소형 웹 애플리케이션
- 빠른 프로토타입 개발
- 중국어 팀 (문서 친화적)
7.3 React: UI 라이브러리
핵심 철학: 뷰 레이어만 담당하고, 다른 문제는 커뮤니티에 맡김
function App() {
const [message, setMessage] = useState('Hello React')
return <div>{message}</div>
}장점:
- ✅ 생태계가 가장 완성도 높고, 컴포넌트 라이브러리가 풍부함
- ✅ JSX 문법이 유연하고 표현력이 강력함
- ✅ 가상 DOM 성능이 우수함
- ✅ 대형 프로젝트에 적합
단점:
- ❌ 학습 곡선이 비교적 가파르고, 추가 개념 습득 필요
- ❌ 다양한 라이브러리를 직접 선택하고 조합해야 함
- ❌ JSX는 컴파일이 필요하며, 브라우저에서 직접 실행 불가
적용 시나리오:
- 대형 복잡 애플리케이션
- 풍부한 생태계가 필요한 프로젝트
- 크로스 플랫폼 개발 (React Native)
7.4 Svelte: 컴파일 타임 프레임워크
핵심 철학: 가상 DOM 없음, 컴파일 시 컴포넌트를 효율적인 네이티브 코드로 변환
<script>
let message = 'Hello Svelte'
</script>
<div>{message}</div>장점:
- ✅ 성능 최적 (가상 DOM 런타임 오버헤드 없음)
- ✅ 패키지 크기가 가장 작음
- ✅ 문법이 간단하고 직관적
- ✅ 반응형 시스템 네이티브 지원
단점:
- ❌ 생태계가 상대적으로 작음
- ❌ 커뮤니티 규모가 Vue/React만 못함
- ❌ 서드파티 라이브러리가 적음
적용 시나리오:
- 성능 요구가 매우 높은 애플리케이션
- 패키지 크기에 민감한 프로젝트
- 새로운 기술을 시도하려는 팀
7.5 Angular: 완전한 플랫폼
핵심 철학: 완전한 솔루션을 제공, 바로 사용 가능
@Component({
selector: 'app-root',
template: '<div>{{ message }}</div>'
})
export class AppComponent {
message = 'Hello Angular'
}장점:
- ✅ 기능이 완전하며, 라우팅, HTTP, 폼이 모두 갖춰져 있음
- ✅ TypeScript 네이티브 지원
- ✅ 대형 팀과 프로젝트에 적합
- ✅ 코드 규범이 통일되어 있음
단점:
- ❌ 학습 곡선이 가파름
- ❌ 개념이 많고 복잡도가 높음
- ❌ 패키지 크기가 큼
- ❌ 소형 프로젝트에 부적합
적용 시나리오:
- 대형 엔터프라이즈급 애플리케이션
- 엄격한 규범이 필요한 팀
- 이미 TypeScript 기술 스택을 사용 중인 프로젝트
8. 정리: 발전의 본질
프론트엔드 기술의 발전은 본질적으로 두 가지 문제를 해결하는 것입니다:
8.1 효율: 수동에서 자동으로
| 시대 | 개발 방식 | 효율 |
|---|---|---|
| 2000년대 | HTML/CSS/JS 직접 작성 | ⭐ |
| 2010년대 | jQuery + 수동 DOM 조작 | ⭐⭐ |
| 2020년대 | Vue/React + 데이터 주도 | ⭐⭐⭐ |
| 현재 | 컴포넌트화 + 엔지니어링 + 자동화 | ⭐⭐⭐⭐⭐ |
8.2 규모: 개인에서 팀으로
| 시대 | 프로젝트 규모 | 협업 방식 |
|---|---|---|
| 2000년대 | 몇 개 파일 | 혼자서 유지보수 가능 |
| 2010년대 | 수십 개 파일 | 소규모 팀, 충돌하기 쉬움 |
| 2020년대 | 수백 개 파일 | 중간 규모 팀, 규범 필요 |
| 현재 | 수천 개 파일 | 대규모 팀, 완전한 엔지니어링 체계 필요 |
9. 학습 로드맵
9.1 기초가 전혀 없다면
1단계: HTML/CSS/JavaScript 기초
- 웹페이지의 세 가지 초석을 이해한다
- 간단한 정적 페이지를 작성할 수 있다
2단계: 프레임워크 하나 배우기 (Vue 추천)
- "데이터 주도" 사상을 이해한다
- 컴포넌트화 개발을 습득한다
3단계: 실전 프로젝트
- 완전한 단일 페이지 애플리케이션을 만든다
- 라우팅, 상태 관리, API 호출에 익숙해진다
9.2 기초가 있다면
심화 방향:
- 엔지니어링: Vite/Webpack을 배우고 빌드 프로세스를 이해한다
- 성능 최적화: 지연 로딩, 코드 분할, 캐시 전략을 배운다
- TypeScript: 코드에 타입을 추가하여 신뢰성을 높인다
- 서버 사이드 렌더링: Nuxt/Next.js를 배워 SEO와 첫 화면 문제를 해결한다
10. 이제 식별할 수 있어야 할 코드
이 장을 읽음으로써 다음을 할 수 있어야 합니다:
- ✅ 프론트엔드 기술 발전의 맥락과 원인을 이해한다
- ✅ Vue, React, Svelte, Angular의 특징을 구분한다
- ✅ "명령형"과 "선언형"의 차이를 이해한다
- ✅ "데이터 주도"의 핵심 사상을 습득한다
- ✅ 컴포넌트화 개발의 가치를 안다
- ✅ CSR, SSR, SSG의 적용 시나리오를 이해한다
- ✅ 빌드 도구(Webpack, Vite)의 역할을 이해한다
- ✅ 프로젝트에 적합한 프레임워크와 기술 스택을 선택할 수 있다
💡 실제 적용
AI로 프로젝트를 할 때 이렇게 말할 수 있습니다:
- "이것은 SEO가 필요한 블로그 사이트이므로 Nuxt(Vue의 SSR 프레임워크)를 사용하세요"
- "이것은 관리자 시스템이므로 Vue + Element Plus를 사용하고, SSR은 필요 없습니다"
- "이것은 성능 요구가 높은 웹 애플리케이션이므로 Svelte 사용을 고려하세요"
- "프로젝트가 이미 React를 사용 중이므로 React 생태계의 라이브러리를 계속 사용하세요"
용어 속성 표
| 용어 | 영문 | 쉬운 설명 |
|---|---|---|
| DOM | Document Object Model | 문서 객체 모델. 객체 트리로 페이지를 표현하며 JS로 읽고 쓸 수 있음. |
| jQuery | - | 초기에 유행한 JS 라이브러리, DOM 조작을 간소화함. |
| Vue/React | - | 현대 프론트엔드 프레임워크, 데이터 주도와 컴포넌트화 개발을 채택. |
| 컴포넌트 | Component | 재사용 가능한 UI 단위, 예: 버튼, 카드, 내비게이션 바. |
| MPA | Multi-Page Application | 다중 페이지 애플리케이션. 페이지 이동 시마다 전체 페이지를 다시 로드. |
| SPA | Single-Page Application | 단일 페이지 애플리케이션. 한 번만 로드하고 이후 전환 시 페이지를 새로고침하지 않음. |
| 라우팅 | Routing | 페이지 간 전환을 관리하는 규칙과 프로세스. |
| SSR | Server-Side Rendering | 서버 사이드 렌더링. 서버가 HTML을 생성하여 브라우저에 전송. |
| SSG | Static Site Generation | 정적 사이트 생성. 빌드 시 페이지를 정적 HTML로 미리 렌더링. |
| CSR | Client-Side Rendering | 클라이언트 사이드 렌더링. 브라우저가 JS를 통해 페이지를 생성. |
| Webpack | - | 전통적인 번들링 도구, 먼저 패키징한 후 서비스. |
| Vite | - | 현대적인 빌드 도구, 요청 시 컴파일하여 속도가 매우 빠름. |
| 반응형 | Responsive Design | 페이지가 다양한 화면 크기에 자동으로 적응하는 디자인. |
| 미디어 쿼리 | Media Query | CSS의 조건 판단, 화면 너비에 따라 다른 스타일을 적용. |
| 명령형 | Imperative | 프로그램에게 "어떻게 할지"를 알려줌. |
| 선언형 | Declarative | 프로그램에게 "무엇을 원하는지"를 알려줌. |
| 데이터 주도 | Data-Driven | 데이터만 수정하면 인터페이스가 자동으로 업데이트됨. |
| Tree Shaking | - | 트리 쉐이킹 최적화. 사용되지 않는 코드를 자동으로 제거하여 패키지 크기를 줄임. |
| 코드 분할 | Code Splitting | 코드를 여러 개의 작은 청크로 나누어 필요할 때 로드. |