프론트엔드의 등장 배경

웹의 세대 구분

프론트엔드는 처음부터 있던 직군이 아니다. 2000년대 초에 생겼고, 웹이 바뀐 흐름과 같이 보면 이해하기 쉽다.

세대	시기	성격	필요했던 사람
Web 1.0	1990년대 ~ 2004	정적인 사이트. 사용자는 읽기만 한다	웹 디자이너. 페이지 제작 기술은 단순했다
Web 2.0	2004 ~	사용자가 콘텐츠를 만들고 고치는 상호작용 사이트	숙련된 웹 개발자
Web 3.0	앞으로	AI·블록체인·IoT 기반의 지능형·시맨틱 웹	정의가 아직 논쟁 중이다

프론트엔드를 만든 기술들

flowchart LR
  n1["1991 HTML 태그"] --> n2["1993 #lt;img#gt;"] --> n3["1994 CGI"] --> n4["1995 JavaScript"] --> n5["1996 CSS"]
  n5 --> n6["2004~05 AJAX<br/>(Gmail, Google Maps)"] --> n7["2010 무렵 Flash 퇴장"]
  n7 --> n8["트래픽·데이터 증가"] --> n9["프론트엔드 / 백엔드 분리"]

기술	바꾼 것
`<img>` 태그 (1993)	페이지가 풍성해졌다. 아직은 전문가가 따로 필요할 만큼 복잡하지 않았다
CGI (1994 무렵)	사용자가 입력한 값을 서버로 보내 서버가 동적으로 페이지를 만들게 했다. PHP 같은 서버 스크립트 언어가 뒤따랐다. 방문자 카운터와 방명록이 붙었고, 방명록은 게시판으로, 게시판은 커뮤니티로 자랐다
CSS (1994 제안, 1996 공개, 1998 W3C 권고)	문서 구조와 시각 디자인을 분리했다
JavaScript (1995)	사용자와 페이지가 상호작용할 수 있게 했다. Web 2.0의 바탕이 됐다
AJAX	페이지 전체를 다시 불러오지 않고 일부만 비동기로 갱신한다. Gmail(2004)과 Google Maps(2005)가 보여 줬고, Jesse James Garrett이 이름을 붙였다. JavaScript의 위상이 크게 올라갔다
Flash의 퇴장 (2010 무렵)	그 자리를 HTML5와 AJAX가 채웠다

문서를 공유하던 웹은 곧 좋은 문서를 찾는 일로 커졌다. 유용한 링크를 모은 웹 디렉터리가 검색엔진으로, 인기 정보를 한곳에 모은 포털로 발전했다. 언제 어디서든 정보를 보낼 수 있다는 성질은 언제 어디서든 주문을 받는 e-커머스로 이어졌다.

닷컴 버블(2000년대 초)로 웹 사업이 재편되며 Web 2.0이라는 말이 생겼다. 프론트엔드와 가장 가까운 키워드는 RIA(Rich Internet Application), 정적인 문서를 넘어 사용자와 상호작용하며 화면이 바뀌는 웹이었다. 당시 IE의 스크립트 능력은 열악했고, ActionScript를 쓰는 Flash가 디자인·애니메이션·인터랙션 모두에서 앞섰다. 웹 디자이너 대부분이 Flash를 배웠고 화려한 사이트가 쏟아졌으며, 이것이 웹의 미래라고 보는 사람이 많았다.

하지만 애니메이션·이미지·사운드로 가득한 사이트는 사람을 피로하게 했고 긴 로딩을 요구했다. Flash는 결국 게임과 인터랙티브 콘텐츠 쪽으로 고립됐고, 애플이 아이폰에서 Flash를 받지 않기로 하면서 웹에서 물러났다. 다만 웹에도 동적 스크립트가 필요하고, 표준 안에 그 대안이 있어야 한다는 것을 알린 계기였다.

Flash가 밀려난 이유

보안 취약점이 잦았다.
모바일에서 성능이 나쁘고 배터리를 많이 썼다.
스크린 리더가 읽지 못해 접근성이 떨어졌다.
검색 엔진이 내용을 색인하기 어려웠다.
HTML5와 AJAX라는 표준 대안이 생겼다.

웹을 앱으로 만든 동력

기술만으로 직군이 생기지는 않았다. 웹으로 돈을 벌려는 회사들이 브라우저를 앱 플랫폼으로 밀어붙였고, 그 과정에서 화면 쪽 일이 전문 영역이 됐다.

흐름	일어난 일	프론트엔드에 남긴 것
IE 독점과 홈페이지 붐 (1995~2004)	Windows에 IE가 기본 탑재되며 홈페이지가 회사의 명함이 됐다. 게시판은 솔루션을 사서 붙였고, 눈에 띄려고 화려한 배너·디자인 수요가 몰렸다	HTML·CSS 작업은 수요가 많았지만 로직이 거의 없어, HTML·CSS만 다루는 개발자는 실력이 없다는 인식이 이때 생겼다
구글의 "웹이 OS가 되면"	오피스를 웹으로 옮기려 했고, 다른 벤더의 플러그인에 기대지 않으려고 JavaScript 비동기 화면(Google Maps)을 택했다	JavaScript가 재평가됐다
웹 표준과 접근성	여러 브라우저 벤더가 IE·ActiveX 대신 공통 표준을 만들었다	크로스 브라우징·시맨틱·접근성이 디자이너와 다른 전문 영역이 됐다. 디자인을 표준 HTML·CSS로 옮기는 일이 별도 공정이 됐다
jQuery (2006)	쉬운 문법으로 DOM 조작·크로스 브라우징·Ajax를 한꺼번에 해결했다	jQuery 문법의 상당수가 뒤에 표준 API(`querySelectorAll` 등)로 들어갔다
크롬과 V8 (2008)	빠른 JS 엔진과 디버깅 도구를 갖춘 브라우저가 나왔다	`console.log`조차 쓰기 어렵던 환경에서 디버깅 가능한 개발이 시작됐다
Node와 npm	V8이 서버로 나가고, 모듈을 패키지로 공유하게 됐다	파일을 나눠 큰 프로그램을 짤 수 있게 됐고, webpack·Babel 같은 Node 기반 빌드 도구 생태계가 열렸다
페이스북의 규모	단일 웹 서비스가 감당할 데이터와 화면이 폭증했다	React가 나오며 프론트엔드 개발의 체계가 잡혔다

프론트엔드와 백엔드의 분리

트래픽과 데이터가 커지자 한 사람이 모두 맡기 어려워졌다. 역할이 나뉘었다.

영역	맡는 일
프론트엔드	가공된 데이터를 받아 사용자가 보고 조작하는 화면을 만든다
백엔드	서버에서 데이터를 처리하고 저장한다

프론트엔드는 새로 생긴 것이 아니라 거대 웹 서비스가 등장하며 자연스럽게 세분화된 것이다. 백엔드는 대용량 데이터·배포 자동화·스케일링이라는 새 과제를 맡았고, 프론트엔드는 동적인 화면이라는 과제를 맡았다. 1인 개발이 흔하던 모바일 게임이 대형 팀 작업이 된 것과 같은 흐름이다.

프론트엔드가 맡게 된 자리

디지털 전환: 오프라인 사업이 온라인으로 옮겨 오면서, 데이터를 눈으로 보고 조작하는 백오피스·관리자 도구 수요가 크게 늘었다. 입문자가 상상하는 화려한 화면과 실제 수요가 다를 수 있다.
프로토타이핑의 최전선: 설치가 필요 없고 가볍게 만들 수 있어, 스타트업이 사업을 검증하는 첫 도구가 된다.
데이터를 다루는 앱: Notion·Figma·Slack·VS Code처럼 웹이 문서가 아닌 애플리케이션이 됐다. 서버리스와 Next.js 같은 메타 프레임워크로 데이터 로직 일부가 프론트엔드 쪽으로 옮겨 왔고, 실시간 협업이 기본 기대치가 됐다.

React 이후: 생태계가 바뀐 흐름

직군이 자리 잡은 2010년대 중반부터 프론트엔드는 도구가 빠르게 바뀌는 분야가 됐다. 해마다 「무엇을 배워야 하나」가 달라졌지만, 갈래별로 보면 방향은 일정했다.

갈래	흐름	지금
프레임워크	AngularJS가 앞서다 Angular 2의 전면 재작성으로 흔들렸고, React가 대세가 됐다. Vue는 낮은 진입 장벽으로 입문용 선택지가 됐다	React가 표준에 가깝다. AngularJS는 2021년에 지원이 끝났다. Svelte·Qwik 같은 컴파일·재개 방식이 대안으로 쓰인다
상태 관리	Redux(+Redux Saga)가 표준이 됐다가 보일러플레이트 피로로 MobX·Context API 논쟁이 붙었다. Hooks(React 16.8, 2019) 이후 Recoil이 유행했다	서버 상태는 TanStack Query·SWR, 클라이언트 상태는 Zustand·Jotai처럼 나눠 쓴다. Recoil은 2025년에 저장소가 보관 처리됐다. Redux는 Redux Toolkit으로 쓴다
타입	처음엔 학습 자료가 없고 진입 장벽이 높다며 TypeScript를 꺼렸다	채용 요건에 가까운 기본기다. Node.js가 타입을 지우고 `.ts`를 바로 실행하고, tRPC·Zod처럼 타입을 런타임 경계까지 잇는 도구가 흔하다
스타일링	CSS Modules·BEM → styled-components·Emotion의 CSS-in-JS → 런타임 비용을 없앤 zero-runtime CSS-in-JS	Tailwind CSS 같은 유틸리티 우선 방식이 주류다. styled-components는 2025년에 유지보수 모드로 들어갔다
빌드 도구	webpack·Babel 설정이 가장 큰 진입 장벽이었다. ESM 기반 개발 서버, esbuild·SWC 같은 Rust·Go 도구가 나오며 Vite로 대거 옮겨 갔다	Vite 8은 Rust 번들러 Rolldown 하나로 빌드하고, Next.js는 Turbopack을 기본으로 쓴다
모노레포·패키지	Lerna로 시작해 Turborepo·Nx·Rush가 경쟁했다. 국내에서는 Yarn Berry(PnP) 도입이 유행했다	pnpm 워크스페이스 + Turborepo·Nx 조합이 흔하다
렌더링	CSR SPA가 SEO 문제에 부딪혀 Next.js·Nuxt의 SSR로 돌아왔고, ISR·스트리밍 SSR이 더해졌다	React Server Components가 Next.js App Router의 기본이 됐다
브라우저	IE 대응용 폴리필이 코드의 큰 몫이었다	IE 지원 종료(2022) 뒤로 새 표준 API를 바로 쓴다
협업·품질	팀이 커지며 Prettier·ESLint·Husky·lint-staged, Jest·Testing Library, Storybook과 디자인 시스템·디자인 토큰이 퍼졌다	프론트엔드 개발자의 영역이 CI/CD·DX·BFF·마이크로 프론트엔드까지 넓어졌다
AI	Copilot(2021) 다음 LLM(2023)이 개발 방식 자체를 흔들었다	코딩 에이전트에게 일을 맡기고 검증하는 것이 일상 업무가 됐다

이 흐름에서 남는 교훈은 셋이다.

생태계는 개발자와 함께 자란다. 한때 「너무 어렵다」며 포기하던 Redux와 TypeScript 중 하나는 레거시 취급을 받고, 하나는 기본 요건이 됐다. 지금 어려운 도구도 몇 년 뒤엔 평범해지거나 사라진다.
유행 하나하나를 좇으면 지친다. 해마다 쏟아진 라이브러리는 대개 같은 문제(상태 동기화, 빌드 속도, 스타일 충돌, 첫 화면 속도)에 대한 다른 답이었다. 문제를 이해하면 새 도구는 비교 대상일 뿐이다.
바뀌지 않는 것은 웹 플랫폼이다. 폴리필과 프레임워크가 하던 일이 계속 표준으로 흡수된다. jQuery가 그랬듯 오늘의 라이브러리 기능도 내일의 브라우저 API가 된다.

정리

프론트엔드는 한 사건이 아니라 기술이 쌓이며 생긴 영역이다.
CSS는 구조와 표현을, AJAX는 페이지와 데이터 요청을 떼어 냈다.
표준 기술(HTML5·JS)이 독자 플러그인(Flash)을 대체하면서 브라우저가 앱 플랫폼이 됐다.
사용자가 웹에 기대하는 것이 커질수록 화면을 만드는 일도 전문화됐다.
구글(웹을 OS로)과 페이스북(거대한 단일 서비스)의 필요가 V8·크롬·React를 낳았고, 이것이 직군 분리를 굳혔다.
React 이후의 도구 교체는 같은 문제에 대한 답이 바뀐 것이다. 문제를 이해하면 유행에 덜 흔들린다.

버그 제보