프론트엔드 프레임워크: 등장 배경, 주요 트렌드, 그리고 프레임워크에 집착할 필요가 없는 이유

04.08.2025.유상훈 매니저

#frontend

#framework

#JavaScript

#React

#프론트엔드

#프레임워크

Report

프론트엔드 프레임워크

: 등장 배경, 주요 트렌드, 그리고 프레임워크에 집착할 필요가 없는 이유

안녕하세요. AiNEWT에서 프론트엔드 개발을 담당하고 있는 유상훈 매니저 입니다.

프론트엔드 개발을 하다 보면 React나 Vue 같은 프레임워크 이야기를 자주 듣게 되죠.
오늘은 프론트엔드 프레임워크가 왜 등장하게 되었는지 과거를 살펴보고, 현재 많이 쓰이는 주요 프레임워크들을 알아본 다음, 앞으로 주목할 만한 새로운 프레임워크들은 무엇이 있는지 얘기해보겠습니다.

프레임워크에 대해 많은 얘기를 하겠지만, 마지막에서는 프레임워크에 그렇게 집착하지 않아도 되는 이유에 대해서도 이야기해볼게요. 🛋️

1. 프레임워크 등장 이전의 웹 개발

옛날옛적(?) 웹 개발 시절로 잠깐 돌아가볼까요? 초창기 웹은 Vanilla JS (순수 자바스크립트)와 jQuery로 동적인 기능을 구현하곤 했습니다. jQuery는 2006년에 등장한 혁신적인 라이브러리로, 복잡한 DOM 조작을 간편하게 해줘서 당시 개발자들에게 큰 환영을 받았어요. 다양한 브라우저간 호환성 문제를 알아서 처리해주고, 애니메이션이나 AJAX(비동기적으로 서버와 통신 지원해주는 기술) 같은 기능도 쉽게 쓸 수 있게 해줬죠.

"와, 이제 자바스크립트 코딩이 즐거워졌다!" 😃

라는 말이 나올 정도였으니까요.

옛날이라고 해봤자 생각보다 오래되지 않았다...

하지만 웹이 점점 복잡한 애플리케이션으로 진화하면서, jQuery만으로는 한계가 드러나기 시작했습니다. 🥲

개발자들이 직접 DOM을 이리저리 조작하고, 이벤트마다 수동으로 UI를 업데이트하다 보니 규모가 커질수록 코드가 스파게티처럼 복잡해지는 문제가 있었어요. 상태 관리도 골칫거리였습니다. 화면 여기저기에 동일한 데이터가 표시되는데 이를 일일이 업데이트하고 일관성 유지하기가 너무 힘들었죠.

실제로 과거의 명령형(imperative) 방식에서는 개발자가 UI 상태를 직접 관리해야 해서, 규모가 큰 앱일수록 유지보수하기 어려운 스파게티 코드가 되기 일쑤였습니다

게다가 프로젝트마다 코드 구조가 제각각이라, 새로운 사람이 투입되면 코드를 이해하기까지 시간이 많이 걸렸어요. 공통 문제를 해결할 수 있는 일관된 아키텍처의 필요성도 대두됐습니다.

2. 프론트엔드 프레임워크의 등장

이러한 배경에서 등장한 것이 바로 프론트엔드 프레임워크들입니다.

예를 들어 2010년에 나온 AngularJS는 처음으로 본격적인 MVC 아키텍처를 프론트엔드에 도입하여 큰 주목을 받았습니다. 화면과 데이터를 양방향으로 자동 동기화해주는 양방향 바인딩(two-way binding) 이라든가, 의존성 주입(DI), 라우팅 등의 기능을 제공하면서, 개발자가 일일이 DOM을 조작하지 않아도 데이터 변화에 따라 UI가 알아서 갱신되는 편리함을 선사했죠.

같은 시기 등장한 Backbone, Ember, Knockout 등도 각자 구조화된 개발 방법을 제시하며 인기를 끌었습니다.

이들 초기 프레임워크의 공통된 목표는 점점 커져가는 웹 앱을 더 쉽게 만들고 관리하자는 것이었습니다. 다시 말해, 프레임워크는 직접 DOM을 다루는 번거로움과 상태 관리의 어려움을 해결하고자 탄생한 해결사들이었던 거죠.

요약하자면, 프론트엔드 프레임워크가 등장한 배경에는 DOM 조작의 어려움, 복잡한 상태 관리, 유지보수성 부족이라는 초창기 웹 개발의 문제가 있었습니다. jQuery로도 부족해진 이 문제들을 해결하고 보다 구조적이고 유지보수하기 쉬운 앱을 만들기 위해 AngularJS 같은 프레임워크가 나타났고, 이것이 프론트엔드 개발 패러다임을 크게 바꾸기 시작했습니다.

3. 주요 프론트엔드 프레임워크 소개 (현재의 주류)

현재 프론트엔드 세계에서는 몇몇 대표 선수들이 오랫동안 사랑받고 있습니다.
그 중에서 React, Angular, Vue.js 이 세 가지에 대한 얘기를 해볼까요?

각각 조금씩 철학과 구현 방법은 다르지만, 공통적으로 컴포넌트 기반으로 UI를 구성하고 필요한 부분만 효율적으로 업데이트한다는 목적을 지니고 있어요. 이번에는 이 인기 프레임워크들의 특징과 트렌드를 살펴볼게요.

3.1 React(리액트)

전세계 웹 프레임워크 중 약 40%를 점유 [Most Popular Front-End Frameworks in 2023]

React는 프론트엔드 개발자라면 모르는 사람이 없을 정도로 가장 널리 쓰이는 라이브러리(혹은 프레임워크)입니다. 2013년 Facebook(메타)에서 공개한 이후 혁신적인 아이디어로 폭발적인 관심을 끌었어요.

특히 가상 DOM(Virtual DOM) 개념을 도입하여, 실제 DOM을 직접 다루는 대신 메모리상에 가상의 DOM을 두고 변화가 생긴 부분만 한 번에 실제 DOM에 반영하는 방식으로 UI 업데이트 성능을 향상시켰습니다.

또, 단방향 데이터 흐름을 채택해 데이터가 한쪽 방향으로만 흐르도록 함으로써 복잡한 화면 상태를 예측 가능하게 만들었죠. 이러한 아키텍처 덕분에 Facebook이 겪던 UI 버그들을 효과적으로 줄일 수 있었다고 해요.

React는 등장 직후부터 빠르게 인기를 얻어 현재까지도 사실상의 표준처럼 자리 잡았습니다. 2010년대 중반 이후로 React 생태계가 폭발적으로 성장해서, 필요한 거의 모든 기능에 대한 라이브러리가 존재한다고 해도 과언이 아닙니다. 실제로 설문조사를 보면 현업 개발자의 절반 이상이 React를 사용한다는 결과도 있습니다 (JetBrains 개발자 설문에서 약 57% 가 React를 사용한다고 응답).

최근에는 React Hooks가 도입되어 함수형 컴포넌트에서 상태와 생명주기 로직을 더욱 깔끔하게 관리할 수 있게 되었고, SSR(서버사이드 렌더링)과 CSR(클라이언트사이드 렌더링)을 조합한 Next.js 같은 프레임워크도 함께 각광받는 등 꾸준히 트렌드를 이끌고 있습니다.

결론적으로, React는 성능, 생산성, 방대한 커뮤니티를 고루 갖춘 프레임워크라고 할 수 있습니다.

3.2 Vue.js (뷰)

Vue.js는 2014년 Evan You라는 개발자가 개인 프로젝트로 시작한 프로그레시브 프레임워크입니다. "프로그레시브"라는 말처럼, 필요한 부분만 점진적으로 적용할 수 있고 다른 라이브러리와도 쉽게 통합할 수 있다는 유연성이 큰 장점이에요.

Vue는 Angular와 React의 장점을 절묘하게 결합했다고들 많이 얘기하는데, Angular처럼 템플릿 기반으로 직관적으로 UI를 설계하면서도 React처럼 컴포넌트 단위로 쪼개서 관리합니다. 또 React의 단방향 흐름과 Angular의 양방향 바인딩을 선택적으로 활용할 수 있도록 해주는 등 중간 쯤의 철학을 가지고 있죠.

Vue는 경량이고 배우기 쉬워서 진입장벽이 낮다는 평가를 받습니다. 국내에서도 Vue로 입문했다는 초보 개발자를 심심찮게 볼 수 있어요. 업계 인기 면에서는 React, Angular보다는 살짝 뒤처지지만, *State of JS 설문 등에서 만족도 높은 프레임워크로 상위권에 늘 위치하곤 합니다.

또한 Vue는 공식적으로 지원하는 에코시스템 (Vuex 상태관리, Vue Router 등)이 잘 갖춰져 있어서, 규모가 커져도 비교적 일관된 개발이 가능합니다. 요약하면, Vue는 배우기 쉽고 가볍지만 필요한 기능은 다 갖춘 균형 잡힌 프레임워크라고 할 수 있겠네요.

*전 세계의 JavaScript 개발자들을 대상으로 공개 온라인 설문조사를 실시하여 응답 데이터를 취합, 분석한 결과 자료를 발표하는 프로젝트

4. 미래에 주목할 만한 프레임워크와 기술

프론트엔드 세계는 늘 빠르게 변하고 있습니다. 새로운 프레임워크나 접근법이 계속 등장하면서 “다음에 뜰 것은 무엇인가”에 대한 관심도 뜨거운데요. 몇 년 전부터 슬슬 이름이 들리기 시작하더니, 이제는 꽤 주목받는 신예 프레임워크 두 개와, 아예 프레임워크 없이 개발하는 방식에 대해서 이야기해볼게요.

4.1 Svelte (스벨트)

Svelte는 기존의 React나 Vue와는 접근 방식이 사뭇 다른, 흥미로운 프레임워크입니다.

2019년경부터 본격적으로 주목받기 시작했는데, 창시자인 Rich Harris는 Svelte를 "컴파일러"라고 부르기도 해요. 왜냐하면 Svelte로 작성한 코드는 런타임에 동작하는 프레임워크가 아니라 빌드 시점에 Vanilla JS로 컴파일되어 버리거든요.

쉽게 비유하자면, 일반 프레임워크는 통역사와 함께 외국에 가는 것과 같아요. 통역사(프레임워크)가 계속 옆에서 번역해줘야 하죠! 하지만, Svelte는 출발 전에 미리 모든 표현을 번역해 놓고, 번역본만 가지고 여행하는 것과 같습니다. 통역사가 더 이상 필요하지 않죠.

덕분에 결과물의 번들 크기가 작고, 실행 속도가 빠르며, 메모리 효율도 높다는 장점이 있죠. 가상 DOM을 쓰지 않고도 프레임워크 수준의 개발 편의성을 제공하면서, 결과물은 프레임워크를 거치지 않은 것처럼 가볍다는 게 Svelte의 매력입니다.

또 Svelte는 문법도 비교적 직관적이어서 배우기 쉽다는 평이 많습니다. 컴포넌트 파일 하나 안에 HTML, CSS, JS를 모두 작성하고, 반응형으로 동작하게 할 수 있어서 개발 생산성도 높습니다. 2020년대 들어 여러 개발자 설문조사 에서 Svelte는 만족도 1위를 다툴 정도로 호평을 받고 있어요.

아직 React처럼 대중화되었다고 보기는 어렵지만, 차세대 프레임워크의 강력한 후보로 손꼽히고 있습니다.

비교 항목	React/Vue	Svelte
빌드 과정	트랜스파일링 → 번들링 → 런타임 실행	컴파일 → 번들링 → 즉시 실행
JS 변환 후 특징	여전히 React/Vue의 런타임 코드 필요	완전한 바닐라 JavaScript로 변환
실행 방식	가상 DOM을 사용하여 상태 변경 감지	컴파일된 코드가 직접 DOM 조작
성능	비교적 무거움 (가상 DOM 연산 필요)	가볍고 빠름 (런타임 없음)
파일 크기	React 라이브러리 포함 → 상대적으로 큼	런타임 없음 → 더 작음

리액트보다 높은 만족도를 가진 Svelte!

4.2 SolidJS (솔리드)

SolidJS도 최근 화제가 되고 있는 신흥 프레임워크입니다. Solid의 철학은 한마디로 말해 "반응성의 극한"이라 할 수 있어요. React처럼 컴포넌트와 JSX 문법을 사용하지만, 내부 동작은 오히려 옛날 KnockoutJS처럼 정교한 반응형 시스템에 가깝습니다.

SolidJS는 애플리케이션의 상태 변화를 세밀하게 추적해서 정말 필요한 부분만 직접 DOM 업데이트를 합니다.

React가 가상 DOM을 통해 변경 사항을 일괄 처리한다면, Solid는 각 상태 값(signal)에 연결된 DOM을 알아서 찾아 정밀 타격하는 셈이죠. 이렇게 하니 불필요한 연산을 최소화할 수 있어서 성능이 매우 뛰어납니다. 실제로 여러 벤치마크에서 SolidJS는 상위권, 종종 1위를 차지할 정도의 렌더링 성능을 보여주고 있어요

SolidJS는 2021년에 1.0이 나온 비교적 새로운 프레임워크이지만, 개발자들 사이에서 입소문을 타고 점점 인지도가 올라가고 있습니다. React 개발자라면 친숙한 문법을 대부분 그대로 활용할 수 있어서 (예: JSX, 훅 비슷한 패턴들), 배우기도 수월하다고 합니다. 다만 React와는 달리 Solid만의 반응형 패러다임을 이해해야 해서 초기에 개념을 전환하는 데 시간이 좀 들 수는 있겠어요. 그럼에도 불구하고,

"React의 성능에 지쳤다면 Solid를 보라!"

는 말이 나올 만큼, 고성능 프레임워크의 대표 주자로 주목받고 있습니다.

JS 프레임워크 벤치마킹 점수 (낮을수록 성능지표가 좋은 것) https://www.solidjs.com

4.3 Web Components와 프레임워크 없는 개발

바닐라 자바스크립트

앞으로의 프론트엔드에서는 프레임워크 자체를 사용하지 않는 방향도 가능성이 거론됩니다. 키워드는 바로 웹 컴포넌트(Web Components) 인데요. 웹 컴포넌트는 브라우저가 제공하는 표준 기술로, 사용자 정의 HTML 태그를 만들고 자체적으로 캡슐화된 기능과 스타일(Shadow DOM)을 갖게 해주는 기술입니다.

예를 들어, <user-card> 같은 나만의 태그를 만들어놓으면, 그것을 그냥 일반 HTML처럼 페이지 여기저기에서 사용해도 내부 기능이 알아서 동작하는 식이죠. 이미 모든 현대 브라우저가 웹 컴포넌트를 지원하고 있기 때문에, 이론적으로 어떤 프레임워크와도 호환되고 또 프레임워크 없이도 UI 구성 요소를 만들 수 있습니다.

이런 이유로 일각에서는 "굳이 큰 프레임워크를 쓰지 않고, 웹 컴포넌트 조합과 필요하면 약간의 경량 라이브러리로도 충분하지 않을까?" 하는 목소리가 있습니다. 실제로 Lit 같은 라이브러리는 웹 컴포넌트 제작을 더 쉽게 해주고 있고, 마이크로 프론트엔드나 디자인 시스템 분야에서는 웹 컴포넌트가 유용하게 쓰이고 있어요.

물론 이에 대해서는 논쟁이 있습니다. 웹 컴포넌트만으로 복잡한 애플리케이션 전반을 관리하기에는 아직 한계가 있고, 프레임워크가 제공하는 상태관리나 라우팅 같은 부가 기능은 별도로 구현해야 할 수도 있거든요. 아마 웹 컴포넌트와 프레임워크의 조화가 미래의 한 방향이 될 것 같습니다. 프레임워크들도 점차 웹 컴포넌트를 포용하고, 또 웹 컴포넌트로 구현된 부분을 프레임워크가 쉽게 다룰 수 있도록 서로 보완하는 식이죠.

어쨌든 "프레임워크 없이 개발"이라는 화두는 앞으로 꾸준히 나올 것이고, 웹 표준이 발전함에 따라 언젠가는 지금의 React나 Vue 없이도 대부분의 일을 할 수 있는 날이 올지도 모릅니다.

5. 결국 프레임워크에 집착할 필요가 없는 이유

결국 모두 자바스크립트

자, 여기까지 프레임워크의 과거부터 현재, 미래 후보들까지 훑어봤습니다. 정리를 하다 보니 프레임워크 세계도 유행이 돌고 돌며 변화무쌍하죠? 🙂 이러한 변화를 보고 느낄 수 있는 점은 "역시 프레임워크는 그때그때 도구일 뿐." 이라는 것입니다. 왜 특정 프레임워크에 너무 목매달 필요가 없다고들 하는지, 마지막으로 그 이유를 정리해볼게요.

첫째, 프레임워크는 어디까지나 문제 해결을 돕는 도구(tool) 입니다. 중요한 것은 웹의 기본 뼈대인 HTML, CSS, JavaScript 자체에 대한 이해예요. 예를 들어, 여러분이 특정 프레임워크 사용법만 달달 외웠다면 정작 새로운 기술이 나왔을 때 크게 헷갈릴 수 있습니다. 반면에 DOM이 어떻게 동작₩하고, 브라우저 렌더링이 어떻게 이루어지며, JS로 상태를 관리하는 기본 원리를 이해하고 있다면, 어떤 프레임워크를 만나도 금방 적응할 수 있어요.

결국 알맹이는 비슷하다는 말이죠.

둘째, 특정 프레임워크에 과도하게 의존하면 위험할 수 있습니다. 프론트엔드 생태계는 워낙 변화가 빨라서, 몇 년 사이에 판도가 확 바뀌기도 합니다. 과거에 한창 인기를 끌었던 AngularJS가 급작스럽게 Angular 2로 전환되면서 많은 개발자들이 곤란을 겪고 결국 등을 돌린 사례가 있습니다!.

설령 내가 쓰던 프레임워크가 바뀌거나 사라져도 JS 자체의 이해도가 높다면, 금세 다른 대안을 찾아갈 수 있습니다. 기술 트렌드는 주기적으로 바뀌지만, 컴포넌트 기반 설계, 상태 관리, 옵저버 패턴, MVC 등의 기본 원리는 계속 모습을 바꿔가며 등장하거든요.

셋째, 프레임워크에 너무 집착하면 오히려 시야가 좁아질 수 있습니다. 가령 어떤 문제를 해결할 때, 꼭 프레임워크 기능에 맞춰 생각하다 보면 다른 창의적인 해결책을 놓칠 수 있어요. 때로는 프레임워크 없이 순수 자바스크립트로 간단히 해결할 수 있는 문제도 있는데, 무조건 프레임워크부터 적용하면 오버엔지니어링이 될 수도 있다는 뜻입니다.

그리고, 프로젝트의 성격에 따라서는 프레임워크가 과한 경우도 있습니다. 작은 위젯 하나 만드는 데 굳이 리액트 풀스택을 다 도입하면 초기 로딩도 느려지고 불필요하게 복잡해질 수 있죠. 이럴 땐 가벼운 라이브러리나 웹 컴포넌트만으로도 충분할 수 있습니다. 결국 상황에 맞게 필요한 도구를 선택하는 안목이 중요하지, 특정 프레임워크 자체에 대한 충성도가 중요한 게 아니란 거죠.

마지막으로 비유를 하나 들어볼게요. 프레임워크를 열심히 공부하는 것은 맛있는 요리 레시피를 하나 배우는 것과 비슷합니다. 예를 들어, React라는 레시피로 멋진 요리를 만들 수 있어요. 하지만 진짜 중요한 것은 요리의 기본기, 그러니까 재료 손질법, 불 조절하는 법, 양념 조합 같은 것들이겠죠. 이 기본기가 탄탄하면 새로운 레시피도 금방 익힐 수 있고, 심지어 레시피 없이도 창작 요리를 만들어낼 수 있습니다.

마찬가지로 웹 개발의 기본기가 있다면 어떤 프레임워크든 필요에 따라 쓰면 되고, 혹은 프레임워크 없이도 멋진 결과물을 만들 수 있어요. 반대로 레시피만 외우고 기본을 모르면, 재료나 도구가 조금만 바뀌어도 당황하게 될 거예요.

정리하면, 프론트엔드 프레임워크를 선택하는 것도 중요하지만, 프레임워크에 매몰되지말고 기본 역량을 키우자! 는 것이 이 글의 핵심 메시지입니다. 프레임워크는 분명 우리를 더 편하게 해주는 훌륭한 도구이고, 최신 트렌드를 따라 공부하는 것도 재미있습니다.

하지만, 언제나 염두에 둘 것은 프레임워크 너머의 기본 원리예요. 결국 멋진 웹을 만드는 것은 프레임워크 자체가 아니라 개발자의 역량이라는 사실을 기억하면서, 우리는 어떤 기술 변화가 와도 유연하게 대처할 수 있는 개발자가 되어야겠습니다! 🚀