웹 프론트엔드를 처음 시작하는 분을 위한 출발점입니다. 브라우저가 화면을 그리는 원리, HTML·CSS·JavaScript의 역할, React·Vue 같은 프레임워크가 필요한 이유, 렌더링 방식(CSR·SSR·SSG), 그리고 JavaScript 기초부터 Next.js·Nuxt 배포까지 이어지는 학습 로드맵을 정리합니다.
웹 프론트엔드를 처음 시작하는 분을 위한 출발점입니다. 브라우저가 화면을 그리는 원리, HTML·CSS·JavaScript의 역할, React·Vue 같은 프레임워크가 필요한 이유, 렌더링 방식(CSR·SSR·SSG), 그리고 JavaScript 기초부터 Next.js·Nuxt 배포까지 이어지는 학습 로드맵을 정리합니다. 이 가이드는 개념을 나열하기보다, 실제 프로젝트에서 판단해야 하는 순서대로 내용을 따라갈 수 있게 구성했습니다.
화면을 그리는 법에서 멈추지 않고, 상태, 데이터 요청, 라우팅, 접근성, 배포 단위까지 함께 봅니다.
글로 읽은 내용을 머릿속에 오래 남기려면 먼저 흐름을 그림으로 잡는 편이 좋습니다. 아래 두 그림은 Frontend 입문 & 로드맵를 학습할 때 계속 되돌아볼 수 있는 기준 지도입니다.
Frontend 입문 & 로드맵를 처음 펼칠 때는 세부 명령보다 큰 그림이 먼저입니다. 이 섹션에서는 앞으로 배울 개념들이 어떤 문제를 풀기 위해 등장했는지부터 잡아봅니다.
| 프론트엔드 개발자의 관심사 | 예시 |
|---|---|
| UI 구현 | 디자인 시안을 반응형 레이아웃으로 구현 |
| 상호작용 | 폼 입력 검증, 드래그 앤 드롭, 모달 |
| 데이터 통신 | API 호출, 로딩·에러 상태 처리, 캐싱 |
| 성능 | 초기 로딩 속도, 이미지 최적화, 코드 분할 |
| 접근성 | 키보드 조작, 스크린 리더 지원, 색 대비 |
| SEO | 검색 엔진이 읽을 수 있는 페이지 구조, 메타데이터 |
HTML · CSS · JavaScript: 웹의 3요소은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 언어 | 역할 | 핵심 학습 주제 |
|---|---|---|
| HTML | 문서의 구조와 의미 | 시맨틱 태그(header, nav, main, article), 폼, 접근성 속성 |
| CSS | 모양과 배치 | 박스 모델, Flexbox, Grid, 반응형(미디어 쿼리), 변수 |
| JavaScript | 동작과 데이터 처리 | DOM 조작, 이벤트, 비동기(Promise, async/await), fetch |
| TypeScript | JavaScript + 타입 시스템 | 타입 정의, 인터페이스, 제네릭 — 대규모 코드의 안정성 |
브라우저가 화면을 그리는 법은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 단계 | 무슨 일이 일어나나 | 성능 포인트 |
|---|---|---|
| 1. HTML 파싱 | HTML을 읽어 DOM 트리 생성 | 불필요하게 깊은 DOM 줄이기 |
| 2. CSS 파싱 | CSS를 읽어 CSSOM 생성 | CSS는 렌더링을 막으므로 핵심 CSS 우선 |
| 3. JavaScript 실행 | 스크립트가 DOM을 수정할 수 있음 | defer / async로 파싱 차단 방지 |
| 4. 렌더 트리 & 레이아웃 | 각 요소의 크기와 위치 계산 | 레이아웃을 반복 유발하는 코드 피하기 |
| 5. 페인트 & 합성 | 픽셀로 그려 화면에 표시 | transform·opacity 애니메이션이 가벼움 |
왜 프레임워크인가: 상태와 UI의 동기화은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
여기서는 첫 컴포넌트: 상태가 바뀌면 화면이 바뀐다을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
setCount로 상태만 바꾸면 React가 화면을 다시 그립니다. 이것이 선언형 UI입니다.import { useState } from 'react';
type Props = { label: string; step?: number };
export default function Counter({ label, step = 1 }: Props) {
const [count, setCount] = useState(0); // 상태 선언
return (
<div className="counter">
<p>{label}: {count}</p>
{/* 상태만 바꾸면 React가 화면을 다시 그린다 */}
<button onClick={() => setCount(count + step)}>+{step}</button>
<button onClick={() => setCount(0)} disabled={count === 0}>초기화</button>
</div>
);
}
// 사용: <Counter label="방문자" step={5} />렌더링 전략: CSR · SSR · SSG은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 전략 | HTML 생성 시점 | 장점 | 단점 | 적합한 페이지 |
|---|---|---|---|---|
| CSR (Client-Side) | 브라우저에서 JS 실행 후 | 서버 부담 적음, 앱 같은 상호작용 | 초기 로딩 느림, SEO 불리 | 관리자 대시보드, 로그인 후 화면 |
| SSR (Server-Side) | 요청마다 서버에서 | 최신 데이터 + SEO | 서버 비용, 응답 지연 | 상품 상세, 개인화 페이지 |
| SSG (Static) | 빌드 시 미리 | 가장 빠름, CDN 배포, 저렴 | 데이터 변경 시 재빌드 | 블로그, 문서, 랜딩 페이지 |
| ISR / 하이브리드 | 정적 + 주기적 재생성 | SSG 속도 + 적당한 최신성 | 캐시 전략 설계 필요 | 뉴스, 카탈로그 |
개발 도구 생태계은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 분류 | 도구 | 역할 |
|---|---|---|
| 런타임 | Node.js | 개발 서버·빌드 도구 실행 환경 |
| 패키지 관리 | npm, pnpm, yarn | 라이브러리 설치·버전 관리 |
| 빌드 도구 | Vite, Turbopack, webpack | 모듈 번들링, 개발 서버, 최적화 |
| 스타일링 | CSS Modules, Tailwind CSS | 컴포넌트 단위 스타일 관리 |
| 상태·데이터 | TanStack Query, Zustand, Pinia | 서버 데이터 캐싱, 전역 상태 |
| 품질 | ESLint, Prettier, Vitest, Playwright | 린트, 포맷, 단위·E2E 테스트 |
| 배포 | Vercel, Cloudflare Pages, Netlify | 정적·SSR 앱 배포 |
시작 전 준비물은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 영역 | 무엇을 | 어느 정도 |
|---|---|---|
| HTML/CSS | 시맨틱 태그, Flexbox, Grid, 반응형 | 간단한 랜딩 페이지를 직접 구현 |
| JavaScript | 변수, 함수, 배열 메서드, 객체, 비동기 | 필수 (JavaScript) |
| 브라우저 개발자 도구 | Elements, Console, Network, Performance 탭 | 요청 실패 원인 찾기 |
| Git | commit, branch, PR | 필수 |
| HTTP 기초 | GET/POST, 상태 코드, JSON, CORS | API 연동 시 필요 |
단계별 로드맵: 웹 기초부터 프로덕션 배포까지은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 단계 | 목표 | 학습 내용 | 가이드 | 완료 체크 |
|---|---|---|---|---|
| 0. 웹 기초 | HTML·CSS로 화면 만들기 | 시맨틱 HTML, Flexbox/Grid, 반응형 | - | 반응형 자기소개 페이지 |
| 1. JavaScript | 동작하는 페이지 | DOM, 이벤트, 비동기, fetch, 모듈 | JavaScript | 순수 JS 할 일 앱 + API 연동 |
| 2. TypeScript | 안전한 코드 | 타입, 인터페이스, 제네릭, 유니온 | TypeScript | JS 앱을 TS로 전환 |
| 3. 프레임워크 | 컴포넌트 기반 UI | 컴포넌트, props, 상태, 이펙트, 라우팅 | React 또는 Vue | API 연동 SPA |
| 4. 데이터 & 상태 | 실무 수준 데이터 처리 | 서버 상태 캐싱, 전역 상태, 폼 검증 | React | 로딩·에러·빈 상태 처리 |
| 5. 메타 프레임워크 | 성능과 SEO | SSR/SSG, 파일 기반 라우팅, 서버 컴포넌트 | Next.js, Nuxt | SEO 메타데이터 갖춘 블로그 |
| 6. 품질 | 신뢰할 수 있는 UI | 테스트, 접근성, Lighthouse 성능 측정 | - | Lighthouse 90점 이상 |
| 7. 풀스택 & 배포 | 서비스 완성 | API 라우트, 인증, 배포, 모니터링 | Node.js, Cloudflare | 커스텀 도메인 배포 |
12주 학습 플랜: 하루 1~2시간 기준은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 주차 | 주제 | 결과물 |
|---|---|---|
| 1~2주 | HTML·CSS·반응형 | 모바일 대응 포트폴리오 페이지 |
| 3~4주 | JavaScript 핵심 + 비동기 | 날씨 API를 쓰는 검색 페이지 |
| 5주 | TypeScript | 4주차 결과물 TS 전환 |
| 6~7주 | React 기초 (컴포넌트, 상태, 이펙트) | 영화 검색 SPA |
| 8주 | 라우팅 + 폼 + 서버 상태 | 로그인 + 게시판 UI |
| 9~10주 | Next.js (SSR/SSG, 서버 컴포넌트) | 마크다운 블로그 |
| 11주 | 테스트·접근성·성능 | 테스트 + Lighthouse 리포트 |
| 12주 | 배포 + 회고 | 도메인 연결 배포 + README |
프로젝트 아이디어: 난이도별은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 난이도 | 프로젝트 | 배우는 것 |
|---|---|---|
| ★☆☆ | 반응형 포트폴리오 사이트 | HTML/CSS, 레이아웃 |
| ★☆☆ | 할 일 앱 (로컬 저장) | 상태, 이벤트, localStorage |
| ★★☆ | 영화·도서 검색 앱 | API 연동, 디바운스, 로딩·에러 처리 |
| ★★☆ | 마크다운 블로그 (SSG) | Next.js, 라우팅, SEO |
| ★★★ | 실시간 협업 칸반 보드 | 드래그 앤 드롭, 낙관적 업데이트, WebSocket |
| ★★★ | 데이터 대시보드 | 차트, 대용량 목록 가상화, 성능 최적화 |
프론트엔드 입문자가 자주 하는 실수은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 실수 | 문제 | 대신 이렇게 |
|---|---|---|
| JavaScript 기초 없이 React부터 | 문법과 프레임워크 규칙 구분 불가 | JS 비동기·배열 메서드부터 확실히 |
| 모든 것을 div로 작성 | 접근성·SEO 저하 | button, nav, main 등 시맨틱 태그 |
| 로딩·에러 상태 누락 | 빈 화면, 멈춘 듯한 UX | 로딩·에러·빈 결과 3가지 상태 항상 처리 |
| 모든 상태를 전역으로 | 불필요한 리렌더링, 복잡도 증가 | 가까운 컴포넌트에 두고 필요할 때만 끌어올리기 |
| useEffect 남용 | 무한 루프, 중복 요청 | 파생 값은 계산으로, 서버 데이터는 쿼리 라이브러리로 |
| 이미지 최적화 무시 | 느린 초기 로딩 | 적절한 크기·포맷(WebP/AVIF), lazy loading |
| API 키를 프론트엔드 코드에 포함 | 브라우저에서 누구나 열람 가능 | 비밀 키는 반드시 서버에서만 사용 |
핵심 용어 사전은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 용어 | 한 줄 설명 |
|---|---|
| DOM | 브라우저가 HTML을 해석해 만든 문서 객체 트리 |
| 컴포넌트 | 화면을 구성하는 재사용 가능한 UI 조각 |
| Props | 부모가 자식 컴포넌트에 전달하는 입력값 |
| 상태 (State) | 시간에 따라 바뀌며 화면에 영향을 주는 데이터 |
| Hydration | SSR로 받은 HTML에 JavaScript 동작을 연결하는 과정 |
| 번들러 | 여러 모듈 파일을 브라우저용으로 묶고 최적화하는 도구 |
| CORS | 다른 도메인 API 호출을 브라우저가 허용할지 정하는 보안 정책 |
| Core Web Vitals | LCP·INP·CLS 등 Google이 정의한 사용자 경험 성능 지표 |
| 반응형 디자인 | 화면 크기에 따라 레이아웃이 자연스럽게 바뀌는 설계 |
| 시맨틱 HTML | 의미에 맞는 태그를 사용해 구조를 표현하는 작성법 |