2026년 프론트엔드 로드맵: 신입이 진짜 배워야 할 것

"프론트엔드 로드맵"을 검색하면 다 비슷한 그림이 나온다. HTML → CSS → JavaScript → React → Next.js, 그 옆에 가지치기처럼 뻗어나가는 수십 개의 기술 이름들. 나도 1년 전에 저 그림을 보면서 공부 순서를 짰다. 그리고 6개월을 낭비했다.

Webpack config를 직접 짜보겠다고 3주를 썼다. CSS-in-JS 라이브러리를 세 개나 비교하면서 블로그 글을 읽었다. jQuery도 "혹시 모르니까" 하면서 튜토리얼을 돌렸다. 결과? 면접에서 "이 컴포넌트의 re-render 조건이 뭔가요?"라는 질문에 제대로 대답을 못 했다. 기초가 안 잡힌 채로 가지만 넓히고 있었던 거다.

지금 우리 팀에 들어오는 신입 면접을 보면서, 그리고 옆 팀 채용 과정을 지켜보면서 느낀 점이 있다. 한국 프론트엔드 시장에서 신입에게 요구하는 건 생각보다 범위가 좁다. 대신 그 좁은 범위를 제대로 아는지를 본다. 그래서 이 글은 "무엇을 배워야 하는가"보다 "무엇을 어디까지 배워야 하는가"에 집중한다.

Phase 1: 기초 — 근데 진짜 필요한 것만#

HTML: 태그 외우기가 아니다#

HTML을 "다 안다"고 생각하는 사람이 많다. 나도 그랬다. div랑 span 차이 알고, form에 input 넣을 줄 알면 끝이라고 생각했다.

그런데 실무에서 처음으로 접근성 관련 QA 피드백을 받았을 때 당황했다. 스크린 리더에서 우리 페이지의 네비게이션이 전혀 인식이 안 됐다. div에 onClick을 달아서 버튼처럼 쓰고 있었기 때문이다. semantic HTML이 뭔지는 알았는데, 왜 중요한지 체감한 적은 없었던 거다.

신입이 HTML에서 확실히 알아야 할 것:

시맨틱 태그: header, nav, main, section, article, aside, footer. 이걸 적재적소에 쓸 줄 알면 된다. div soup을 만들지 않는 감각.
form 요소: input 타입들, label과 for 연결, fieldset, 폼 validation의 기본 동작. React에서 form 라이브러리 쓰더라도 네이티브 동작을 이해하고 있어야 한다.
메타 태그와 SEO 기본: title, meta description, Open Graph 태그. Next.js에서 metadata 객체를 채울 때 이게 뭔지 모르면 곤란하다.

"HTML 공부"에 일주일 이상 쓸 필요 없다. 프로젝트 만들면서 자연스럽게 익히면 된다.

CSS: Flexbox와 Grid면 실무의 80%다#

CSS 전체를 마스터하려고 하면 끝이 없다. float 레이아웃의 역사부터 시작해서 BEM 방법론, CSS 변수, 애니메이션 키프레임까지. 하지만 실무에서 내가 매일 쓰는 CSS는 놀라울 정도로 범위가 좁다.

반드시 익숙해야 하는 것:

Flexbox: justify-content, align-items, flex-grow, flex-shrink, gap. 이것만 자유자재로 쓸 수 있으면 레이아웃의 70%는 해결된다.
Grid: 2차원 레이아웃이 필요할 때. 대시보드, 카드 리스트, 갤러리 같은 것. grid-template-columns와 fr 단위, repeat(), minmax() 정도.
반응형 디자인: media query 기본, rem/em 단위 이해, 모바일 퍼스트 사고방식. 한국 서비스 대부분이 모바일 트래픽이 60~70%다.
position: relative, absolute, fixed, sticky의 차이. 모달, 드롭다운, 툴팁 만들 때 매번 나온다.

Tailwind CSS를 쓰는 회사가 많아졌는데, Tailwind를 쓰더라도 위에 적은 개념을 모르면 클래스 이름을 의미 없이 복붙하게 된다. 기본 CSS를 이해한 상태에서 Tailwind를 쓰면 생산성이 폭발적으로 올라간다. 순서가 중요하다.

JavaScript: 면접에서 물어보는 건 정해져 있다#

JavaScript는 범위가 넓어서 뭘 어디까지 해야 할지 막막한 언어다. 내가 면접 보면서, 그리고 면접관으로 들어가면서 느낀 패턴이 있다.

거의 무조건 나오는 것:

비동기 처리: Promise, async/await, then 체이닝. API 호출 한 번이면 반드시 쓴다. 에러 핸들링(try/catch)까지 포함.
배열 메서드: map, filter, reduce, find, some, every. 데이터를 가공하는 일이 프론트엔드 업무의 절반이다.
구조 분해 할당과 스프레드 연산자: React에서 props 다루고, 상태 업데이트할 때 매 순간 쓴다.
클로저와 스코프: 왜 setTimeout 안에서 변수가 예상과 다른 값을 갖는지. React의 stale closure 문제를 이해하려면 이게 기초다.
이벤트 루프: 깊이 있게 알 필요는 없지만, "JavaScript는 싱글 스레드이고 비동기를 이벤트 루프로 처리한다"는 정도는 설명할 수 있어야 한다.

알면 좋지만 신입 면접에서 잘 안 나오는 것:

프로토타입 체인의 내부 동작
Symbol, WeakMap, WeakSet
제너레이터 함수

여기까지가 Phase 1이다. 이 정도면 프론트엔드 부트캠프 수료 수준이고, 인턴이나 아주 초기 스타트업에 지원할 수 있는 단계다. 하지만 여기서 멈추면 서류 통과가 어렵다.

Phase 2: React + TypeScript#

왜 하필 React인가#

2026년 현재, 한국 채용 공고에서 프론트엔드 프레임워크 요구사항의 체감 70% 이상이 React다. 원티드에서 "프론트엔드"로 검색하면 대부분의 공고에 React 또는 Next.js가 적혀 있다. Vue.js를 쓰는 곳도 있고(특히 네이버 계열), Svelte를 도입한 팀도 있다. 하지만 신입이 "하나만 제대로 하겠다"고 할 때, React가 가장 안전한 선택이라는 건 부정하기 어렵다.

React에서 신입이 알아야 하는 수준:

컴포넌트 설계: 어떤 단위로 컴포넌트를 나누는지. props로 뭘 내리고, 상태를 어디에 둘지.
hooks: useState, useEffect, useRef, useMemo, useCallback. 이 다섯 개를 자유롭게 쓰면 실무에서 만나는 상황 대부분을 처리할 수 있다.
상태 관리 기본: 전역 상태가 왜 필요한지, Context API의 한계가 뭔지. Zustand나 Jotai 같은 라이브러리 하나를 경험해보면 좋다. Redux는 여전히 레거시 프로젝트에 많지만, 신규 프로젝트에서 선택하는 비율은 줄었다.
데이터 페칭: TanStack Query(구 React Query)는 거의 필수다. 캐싱, 로딩/에러 상태, refetch 로직을 직접 구현하는 것과 라이브러리를 쓰는 것의 차이를 한 번이라도 겪어보면 왜 쓰는지 바로 이해된다.
라우팅: React Router 또는 Next.js의 App Router. SPA에서 페이지 전환이 어떻게 동작하는지.

TypeScript: 제네릭 고수가 될 필요는 없다#

TypeScript 얘기를 하면 "어디까지 공부해야 하나요?"가 가장 많이 나오는 질문이다. 답부터 말하면, 신입 수준에서 advanced generics를 자유자재로 쓸 줄 알 필요는 없다.

내가 입사하고 처음 3개월 동안 TypeScript에서 주로 한 일:

typescript

// 1. 컴포넌트 props 타입 정의
interface ProductCardProps {
  title: string;
  price: number;
  imageUrl: string;
  onAddToCart: (productId: string) => void;
}

// 2. API 응답 타입 정의
interface ApiResponse<T> {
  data: T;
  message: string;
  status: number;
}

// 3. 유니온 타입으로 상태 표현
type Status = 'idle' | 'loading' | 'success' | 'error';

이 정도다. interface와 type의 차이, 유니온 타입, 제네릭의 기본적인 사용법, as const, 유틸리티 타입 중 Partial, Pick, Omit 정도. 나머지는 필요할 때 찾아서 쓰면 된다.

TypeScript를 "잘 모르겠으니까 나중에"라고 미루는 분들이 있는데, 이건 좋은 전략이 아니다. React 프로젝트를 TypeScript로 시작하면 처음엔 빨간 줄이 많아서 짜증나지만, 2주만 버티면 오히려 JavaScript로 돌아가기 싫어진다. 에디터가 자동완성을 해주고, 실수를 실시간으로 잡아주니까.

여기까지 하면 대부분의 주니어 프론트엔드 포지션에 지원할 수 있다. 채용 공고의 "자격 요건"에 적힌 기술 스택 대부분을 커버하는 수준이다. 포트폴리오 프로젝트 하나를 React + TypeScript + TanStack Query로 만들어서 GitHub에 올려놓으면 서류 통과율이 확 달라진다.

Phase 3: 실무에서 모르면 당황하는 것들#

면접에서는 안 물어보는데 입사 첫 주에 필요한 것들이 있다. 나는 이걸 "면접 사각지대"라고 부른다.

Git: rebase를 모르면 첫 PR부터 막힌다#

git add, git commit, git push 정도는 다들 안다. 문제는 실무에서 그것만으로는 안 된다는 거다.

입사 첫 주에 PR을 올렸더니 리뷰어가 "rebase 해서 커밋 정리해주세요"라고 했다. 나는 rebase가 뭔지 몰랐다. 구글링하면서 했는데 conflict가 나서 30분을 헤맸다. 옆자리 동기는 나보다 먼저 입사했는데, 아직도 merge만 쓰고 있어서 커밋 히스토리가 스파게티였다.

신입이 Git에서 알아야 하는 것:

branch 전략 (최소한 feature branch 워크플로우)
rebase와 merge의 차이, interactive rebase로 커밋 정리
conflict 해결
stash: 작업 중에 급하게 다른 브랜치로 가야 할 때
.gitignore 관리

패키지 매니저와 번들러#

npm install만 할 줄 아는 것과 package.json을 읽을 줄 아는 건 다르다. dependencies와 devDependencies 차이, ^와 ~의 의미, lock 파일이 왜 있는지. pnpm을 쓰는 회사가 빠르게 늘고 있으니 한 번쯤 써보면 좋다.

번들러는 Vite를 기본으로 알면 된다. Webpack은 설정을 직접 짤 줄 알 필요 없다. 레거시 프로젝트에서 webpack.config.js를 만나면 그때 읽으면 된다. "번들러가 무슨 일을 하는가"를 개념적으로 이해하는 것이 중요하다. 모듈을 합치고, 코드를 변환하고, 최적화한다. 이 정도.

브라우저 DevTools#

Chrome DevTools를 얼마나 잘 쓰느냐가 디버깅 속도를 결정한다. 우리 팀에서 신입 온보딩할 때 가장 먼저 알려주는 것 중 하나다.

Elements 탭: DOM 구조 확인, 스타일 실시간 수정, computed 스타일 보기
Console 탭: 당연히 쓰겠지만, console.table, console.group 같은 것도 알면 편하다
Network 탭: API 요청/응답 확인, 상태 코드, 응답 시간, 페이로드 크기. 이걸 자유롭게 볼 줄 알면 백엔드와 소통할 때 "API가 이상한 것 같아요"가 아니라 "이 엔드포인트가 500 내려주고 있어요, response body는 이거예요"라고 말할 수 있다.
Performance 탭: 당장 깊게 파지 않아도 되지만, 한 번쯤 프로파일링을 돌려보면 "렌더링이 느리다"는 게 구체적으로 무슨 뜻인지 감이 잡힌다

여기까지 하면 실무 투입이 가능한 수준이다. 시니어가 옆에서 도와주는 환경이라면, 이 정도 준비로 첫 번째 티켓을 잡을 수 있다.

Phase 4: 차별화 — 여기서부터 경쟁력이 갈린다#

Phase 1~3은 "기본"이다. 취업을 위한 최소 요건이라고 봐도 된다. Phase 4는 선택이지만, 이걸 하느냐 안 하느냐에 따라 이력서에서 눈에 띄는 정도가 확연히 다르다.

테스트#

"신입한테 테스트를 기대하냐?"라고 물을 수 있다. 기대하지 않는다. 그래서 오히려 차별화가 된다.

포트폴리오 프로젝트에 테스트 코드가 있으면, 면접관 입장에서는 "이 사람 혼자서도 코드 품질을 챙길 줄 아는구나"라고 생각하게 된다. 전체를 커버할 필요 없다. 핵심 유틸 함수에 단위 테스트 몇 개, 중요한 유저 플로우에 통합 테스트 하나. 이것만으로 충분하다.

Vitest: 단위 테스트. Jest보다 설정이 간단하고 Vite 프로젝트와 찰떡이다.
React Testing Library: 컴포넌트 테스트. "사용자가 보는 것"을 기준으로 테스트하는 철학이 실무와 맞다.
Playwright 또는 Cypress: E2E 테스트. 하나만 가볍게 경험해보면 된다.

성능#

웹 성능은 깊게 파면 한도 끝도 없는 분야인데, 신입 수준에서 알면 좋은 건 이 정도다.

Core Web Vitals가 뭔지 (LCP, CLS, INP). 이미지 최적화 (next/image나 srcset). 코드 스플리팅의 개념 (React.lazy와 Suspense). Lighthouse를 돌려보고 점수를 읽을 줄 아는 것. 이 정도만 해도 "성능에 관심 있는 신입"이라는 인상을 줄 수 있다.

한국에서 웹 접근성을 신경 쓰는 회사가 확실히 늘었다. 특히 공공기관, 금융, 대기업 서비스. "접근성 준수"가 프로젝트 요구사항에 들어가는 경우가 많아졌다.

신입 수준에서는 ARIA 스펙을 다 외울 필요 없고, 키보드 네비게이션이 되는지 확인하는 습관, semantic HTML을 쓰는 습관, 색상 대비를 체크하는 습관. 이 세 가지 습관만 가져도 충분하다.

CI/CD#

GitHub Actions로 간단한 파이프라인 하나 만들어본 경험. push하면 lint 돌리고, 테스트 돌리고, 빌드가 성공하는지 확인하는 워크플로우. 이걸 포트폴리오 프로젝트에 넣어두면 "이 사람은 개발 프로세스를 이해하고 있구나"라는 인상을 준다. YAML 파일 하나 작성하는 데 30분이면 된다.

여기까지 하면 경쟁력 있는 신입이다. 면접에서 "테스트 경험 있으세요?"라는 질문에 자신 있게 대답할 수 있고, "성능 개선 해본 적 있나요?"에도 할 말이 있다. 대기업, 유명 스타트업을 포함해서 어디든 지원할 수 있는 수준이다.

과감하게 건너뛸 것들#

시간은 유한하다. 아래 항목들은 2026년 신입 기준으로 우선순위가 낮다.

jQuery: 레거시 프로젝트에서 만날 수는 있다. 하지만 미리 배울 필요는 전혀 없다. 필요하면 그때 5분이면 기본 문법을 파악할 수 있다.

Webpack 설정 직접 작성: Vite가 대세가 된 지금, Webpack config를 처음부터 짤 줄 아는 건 신입에게 기대하는 역량이 아니다. 면접에서도 안 물어본다.

CSS-in-JS 라이브러리 비교: styled-components vs emotion vs vanilla-extract. 이 논쟁에 시간을 쓰지 마라. 회사에서 쓰는 거 쓰면 된다. 어차피 CSS 기본이 탄탄하면 어떤 도구든 적응하는 데 이틀이면 충분하다.

GraphQL: 흥미롭긴 한데, 한국 시장에서 REST가 여전히 압도적이다. GraphQL을 쓰는 회사에 지원하는 게 아니라면 나중으로 미뤄도 된다.

모노레포, 마이크로프론트엔드: 대규모 조직에서나 의미 있는 아키텍처다. 신입이 이걸 공부하는 건 운전면허 따기 전에 F1 전략을 분석하는 거랑 비슷하다.

CS 기초, 프론트엔드에 필요한가#

이 질문을 정말 많이 받는다. 그리고 답은 "어디에 지원하느냐에 따라 다르다"이다.

카카오, 네이버, 토스 같은 곳은 코딩 테스트를 본다. 알고리즘과 자료구조 문제가 나온다. 이 회사에 가고 싶으면 프로그래머스나 백준에서 실버~골드 수준 문제를 꾸준히 풀어야 한다. 피할 수 없다.

반면 많은 스타트업은 코딩 테스트 대신 과제 전형이나 기술 면접 위주다. 이런 곳에서는 "이진 탐색을 구현하세요"보다 "이 화면을 만들어보세요"가 나온다. CS 기초보다 실제 구현 능력을 본다.

그런데 하나 덧붙이고 싶은 게 있다. 자료구조와 알고리즘을 코딩 테스트 통과용으로만 보면 아깝다. Set이 왜 Array의 includes보다 빠른지, 객체를 깊은 복사할 때 재귀가 왜 필요한지, 이런 감각은 실무 코드 품질에 직접적으로 영향을 준다. 다만 우선순위의 문제다. Phase 1~3를 먼저 탄탄히 다지고, 그 다음에 알고리즘을 병행하는 게 효율적이다. 둘 다 동시에 하려다 둘 다 어중간해지는 경우를 너무 많이 봤다.

현실적인 타임라인#

사람마다 다르겠지만, 하루 4~5시간 집중해서 공부한다는 전제 하에 내가 생각하는 현실적인 기간이다.

Phase 1 (HTML/CSS/JS 기초): 2~~3개월. 이 기간에 간단한 프로젝트 2~~3개를 만들어보는 게 중요하다. 투두 앱 말고, 실제 API를 호출하는 뭔가. 공공 API 활용한 검색 서비스 같은 것.
Phase 2 (React + TypeScript): 2~3개월. 포트폴리오 프로젝트 하나를 이 기간에 완성한다.
Phase 3 (실무 도구): Phase 2와 병행 가능. 프로젝트를 만들면서 자연스럽게 Git을 쓰고, pnpm으로 패키지를 관리하고, DevTools로 디버깅하면 된다.
Phase 4 (차별화): 1~2개월. 포트폴리오 프로젝트에 테스트를 추가하고, 성능을 측정하고, CI/CD를 붙인다.

합치면 6~8개월 정도. "너무 긴 거 아니냐"고 할 수 있는데, 현실적으로 이 정도 시간을 투자해야 경쟁력 있는 포트폴리오가 나온다. 3개월 만에 취업했다는 후기가 있지만, 그건 이전 경력이 있거나 관련 전공이거나, 아니면 정말 예외적인 케이스다.

로드맵보다 중요한 한 가지#

마지막으로 하나만 더. 나도 로드맵을 열심히 따라갔는데, 결국 가장 도움이 된 건 "실제 서비스를 만들어본 경험"이었다. 튜토리얼을 따라 하는 건 공부다. 에러를 만나고, 구글링하고, 삽질하고, 결국 해결하는 건 경험이다. 면접에서 빛나는 건 후자다.

로드맵은 방향만 잡아주는 거다. 어떤 기술을 배우든, "이걸로 뭘 만들어볼까?"를 항상 같이 생각하면 좋겠다. 기술은 도구고, 도구는 써봐야 내 것이 된다.