프론트엔드를 공부하다 보면 한 번쯤 이런 생각이 든다.
React, Vue, Svelte, Next.js, Remix
Zustand, Redux, TanStack Query
Vite, Webpack, ESLint, Prettier .....도대체 왜 이렇게 많은 걸까?
처음 프론트엔드 개발자가 되기위해서 커리큘럼을 구성해보았을 때, 생각보다 방대한 생태계에 당황을 하였던 적이 있다.
처음에는 “유행을 따라가야 해서 그런가?”
혹은 “프론트엔드가 원래 이렇게 복잡한 건가?”라는 생각이 들기도 한다.
하지만 이 현상은 단순히 트렌드 때문이 아니다.
프론트엔드 생태계가 이렇게 커진 데에는 꽤 명확한 이유들이 있다.
이 글에서는 다음 세 가지를 중심으로 이야기해보려 한다.
1. 왜 JavaScript / 프론트엔드 라이브러리는 이렇게 많아졌을까
2. 이 현상은 좋은 걸까, 나쁜 걸까
3. 그 속에서 우리는 어떤 기준으로 기술을 선택해야 할까
웹 역할의 전환
가장 큰 변화는 웹이 담당하는 역할 자체다.
예전의 웹은 다음과 같은 순서로 진행되었다.
- 문서를 보여준다
- 버튼을 누르면 페이지가 새로고침된다
- 서버가 모든 로직을 담당한다
프론트엔드는 말 그대로 “화면을 그리는 역할”에 가까웠다.
지금 우리가 사용하는 웹 서비스들을 떠올려보자.
Notion
Figma
Gmail
VS Code
이 정도면 더 이상 “문서”라고 부르기 어렵다.
사실상 웹 앱, 심지어 데스크톱 앱 수준의 복잡도다.
이 변화로 프론트엔드는 다음과 같은 문제들을 직접 해결해야 한다.
- 복잡한 상태 관리
- 클라이언트 라우팅
- 비동기 통신과 에러 처리
- 폼 관리
- 성능 최적화와 사용자 경험
문제가 늘어나면, 그 문제를 편하게 풀어주는 도구가 늘어나는 건 자연스러운 일이다.
프론트엔드 라이브러리의 증가는 이 변화의 결과라고 볼 수 있다.
JavaScript 언어 자체의 한계
두 번째 이유는 JavaScript의 역사다.
지금은 많이 좋아졌지만, 초창기 JavaScript에는 부족한 점이 많았다.
- 모듈 시스템 없음
- 표준 라이브러리 부족
- async / await 없음
- 클래스 문법 없음
이 빈칸을 메운 것이 바로 라이브러리였다.
- 모듈: Webpack, Browserify
- 유틸 함수: lodash, moment
- 비동기 통신: axios
- 최신 문법: Babel, polyfill
즉,
언어가 성숙하기 전에
생태계가 먼저 문제를 해결해온 구조
이 과정에서
같은 문제를 푸는 라이브러리가 여러 개 동시에 등장했고,
그 선택지들이 사라지지 않고 쌓이며
지금의 라이브러리 숲이 만들어졌다.
브라우저 호환성
과거 웹 개발자들은 브라우저 호환성 문제에 시달렸다.
- IE
- Chrome
- Firefox
- Safari
CSS도 다르고, DOM API도 다르고,
JavaScript 동작도 제각각이었다.
이 문제를 한 번에 해결해준 대표적인 존재가 jQuery다.
jQuery는 다음을 모든 브라우저에서 동일하게 동작하게 만들어줬다.
- DOM 선택
- 이벤트 처리
- AJAX
- 애니메이션
이 흐름은 지금도 이어진다.
- fetch를 더 편하게 쓰기 위한 axios
- CSS 호환성과 DX를 위한 styled-components, emotion, Tailwind
이를 한 문장으로 정리하면 이렇다.
표준은 느리게 움직이고,
라이브러리는 그보다 빠르게 성장했다...
Node.js와 NPM
프론트엔드 생태계를 진짜 폭발시킨 결정적 계기는
Node.js와 NPM의 등장이다.
- JavaScript가 브라우저 밖에서도 실행 가능해졌고
- NPM이 전 세계 개발자의 공유 창고가 됐다
npm init
npm install some-library이 두 줄이면
전 세계 오픈소스를 바로 가져다 쓸 수 있다.
결과적으로 라이브러리 제작 비용이 극단적으로 낮아졌고 아주 작은 기능도 모듈로 쪼개져 배포되었으며 라이브러리가 또 다른 라이브러리에 의존성을 갖게되었다.
이렇게 거대한 의존성 트리가 만들어졌고,
왠지 써야 할 것 같은 라이브러리는 계속 늘어났다.
프론트엔드 도구들의 변화 흐름
프론트엔드 생태계를 타임라인으로 정리해보자.
1단계: jQuery 시대
- DOM 조작과 브라우저 호환성 해결
- HTML + jQuery 스파게티 코드의 전성기
2단계: SPA 프레임워크 등장
- Backbone, AngularJS, Ember
- JavaScript로 화면 전체를 렌더링
- 규모가 커지며 구조의 필요성 등장
3단계: React · Vue · Angular
- 컴포넌트 기반 UI
- Virtual DOM
- 상태 관리, 라우팅, 빌드 도구 생태계 확장
4단계: Meta Framework와 DX
- Next.js, Remix, Nuxt, SvelteKit
- 라우팅, SSR/SSG, 번들링을 한 번에 제공
- 개발 경험(DX)의 비약적 향상
5단계: 번들러 전쟁
- Grunt → Gulp → Webpack → esbuild → Vite, Turbopack
- 공통 목표는 더 빠르게, 더 편하게
문제가 바뀔 때마다
그 문제를 해결하는 도구가 등장했고,
그것들이 겹치고 쌓이며 지금의 생태계가 만들어졌다.
그렇다면 우리는 뭘 기준으로 선택해야 할까?
라이브러리가 많다는 사실보다 중요한 건
그래서 우리는 어떻게 선택하느냐다.
1. 문제 먼저, 라이브러리는 나중에
라이브러리 선택의 출발점은 항상 현재 프로젝트의 문제 상황이어야 한다.
- “요즘 다 쓰던데?” ❌
- “지금 우리 프로젝트의 문제는 뭔데?” ⭕️
프로젝트의 규모, 기간, 팀 구성, 요구되는 복잡도를 먼저 고려하지 않으면
라이브러리는 오히려 과한 도구가 될 수 있다.
라이브러리를 사용하는 것이
항상 더 좋은 선택은 아니다.
문제를 직접 해결하는 비용보다
라이브러리를 도입했을 때의 복잡도와 러닝 커브가 더 클 수도 있다.
예시
- 서버 데이터 캐싱과 동기화가 핵심 문제 →
TanStack Query - 전역 UI 상태 관리 →
Zustand
2. 커뮤니티와 생존성
라이브러리를 선택할 때
스타 수 하나만 보는 것은 충분하지 않다.
더 중요한 지표는 다음과 같다.
- 최근 커밋이 꾸준히 이루어지고 있는가
- 이슈와 PR이 방치되지 않고 관리되고 있는가
- 검색했을 때 레퍼런스와 해결 사례가 잘 나오는가
이 기준을 만족하는
적당히 메이저하고, 살아있는 라이브러리가
실무에서 가장 안전한 선택이다.
라이브러리의 사용률이나 트렌드를 확인하고 싶다면
다음과 같은 사이트들을 참고할 수 있다.
또한 GitHub의 트렌딩 페이지를 통해
최근 어떤 라이브러리와 기술 스택이 주목받고 있는지도 확인할 수 있다.
3. 문서의 퀄리티
문서는 단순한 참고 자료가 아니라
곧 생산성이다.
문서의 퀄리티는 다음에 직접적인 영향을 준다.
- 러닝 커브
- 팀원의 온보딩 속도
- 문제 발생 시 해결 시간
아무리 좋아 보이는 라이브러리라도
문서가 부실하면
그 부담은 팀 전체가 떠안게 된다.
4. 팀과 일정
기술 선택은 이상적인 선택보다 현실적인 선택이 중요한 경우가 많다.
- 단기 프로젝트라면 → 팀원이 이미 익숙한 스택
- 새로운 기술 시도 → 사이드 프로젝트나 개인 학습에서 먼저한 후 적용하는 것이 Best
프로젝트 일정 안에서
안정적으로 완주할 수 있는 선택인지 항상 고민해야 한다.
5. 락인(lock-in)과 대체 가능성
라이브러리마다
프로젝트에 미치는 영향의 크기는 다르다.
- 프레임워크는 보통 락인 효과가 크다
- 상태 관리나 UI 라이브러리는 비교적 교체 가능성이 있다 그렇다하더라도 쉽지는 않은 일
따라서 도입 시점에 “나중에 바꾸기 어렵지는 않을까?” 라는 질문을
한 번쯤 던져보는 것이 좋다.
라이브러리가 많다는 건 오히려 좋은 것
라이브러리가 많다는 건 초기에는 분명 혼란스러울 수 밖에 없다고 생각한다. 하지만 다른 관점에서는 이렇게 볼 수 있다.
- 문제를 해결하려는 사람이 많다는 뜻이고
- 기존 도구의 한계를 개선하려는 시도가 계속되고 있다는 의미
우리가 목표로 해야 할 건
모든 라이브러리를 아는 개발자가 아니라,
문제를 이해하고,
상황에 맞게 선택할 줄 아는 개발자
SOPT 웹파트 활동을 진행하면서도 여러사람들이 강조했던 부분인 것같다. 라이브러리 생태계가 방대하다고해서 무분별한 사용을 해도 상관없는 것이 아니라, 필요한 라이브러리에 대해서만 학습을 하고, 적용을 하는 것이 더 유리할 것같다고 생각한다.
프론트엔드는 라이브러리 전쟁터가 아니라,
문제를 해결하는 도구다.
