프론트엔드의 역사

3년 차 프런트엔드 개발자로서, 요즘 많은 개발자들이 사용하는 React와 Next.js 같은 프레임워크를 나도 사용하고 있다.

그러다 문득, 내가 현재 쓰고 있는 기술 스택들이 왜 등장하게 되었는지, 그리고 어떤 문제를 해결하거나 개선했기에 지금까지 널리 사용되고 있는지 궁금해졌다. (재미있게도, 일부는 과거 방식으로 되돌아가는 것처럼 보이기도 한다.)

참고로, 이 글에서는 WEB 1.0이나 IE 등장 등 웹의 초기 역사보다는, JSP 등의 백엔드 중심 개발에서 프런트엔드 직군이 본격적으로 생겨난 시점부터 이야기를 시작해 보려고 합니다.

---

프런트엔드 직군의 탄생: 백엔드 중심에서 프런트엔드로

• 초기 웹 개발: 웹 개발 초기에는 프런트엔드와 백엔드의 경계가 불분명했습니다. JSP, PHP, ASP 같은 서버 사이드 기술을 사용해 서버에서 HTML을 렌더링하고 이를 클라이언트에 전달하는 방식이 주류였습니다.
• 사용자 경험(UX)의 중요성 대두: 웹이 점점 더 복잡해지면서 사용자 인터랙션의 중요성이 강조되었고, 더 나은 사용자 경험을 제공할 필요가 생기면서 프론트엔드 개발이 전문 분야로 발전하기 시작했습니다.
• AJAX의 등장과 동적 웹페이지: AJAX가 등장하면서 페이지 전체를 다시 로드하지 않고도 서버와 데이터를 주고받는 비동기 처리가 가능해졌습니다. 이로 인해 웹 애플리케이션은 더욱 동적이고 사용자 친화적인 방식으로 발전할 수 있었습니다.

---

jQuery와 그 한계

• DOM 조작의 편리함: jQuery는 JavaScript로 DOM을 쉽게 조작할 수 있는 라이브러리로, 복잡한 크로스 브라우저 이슈를 해결하며 큰 인기를 끌었습니다. 
  
  
• 상태 관리의 어려움: 하지만 프로젝트가 커질수록 DOM 조작과 상태 관리는 점점 복잡해졌고, 이로 인해 코드의 유지보수성이 떨어졌습니다. 특히 데이터를 관리하고 이를 UI에 일관되게 반영하는 것이 큰 문제였습니다.
  이와 더불러 javascript 자체 DOM 조작 API도 점점 발전해 굳이 사용할 필요가 없어지기도 한 것 같다.

하지만 jQuery는 여전히 리액트 다음으로 인기가 있다.

 

---

AngularJS: 프레임워크의 시작 (2010년)

AngularJS는 구글에서 2010년에 출시한 프레임워크로, 기존의 jQuery로 해결하기 어려운 대규모 애플리케이션의 복잡한 로직과 데이터 관리를 해결하기 위해 만들어졌습니다. (사실상 MVVM 패턴을 사용하는 것 같지만 앵귤러 공식사이트는 MVW(whatever)라고 표현한다.)

 

• 양방향 데이터 바인딩 (Two-way Data Binding): AngularJS는 양방향 데이터 바인딩을 도입하여, 모델(데이터)과 뷰(UI)가 자동으로 동기화되었습니다. 즉, 데이터가 변경되면 UI가 자동으로 업데이트되고, UI의 변화도 데이터에 즉시 반영됩니다. 이 기능은 개발 생산성을 크게 향상했습니다.

 

개선점: AngularJS는 jQuery의 단순한 DOM 조작 방식을 넘어서, 애플리케이션 전체의 구조를 체계적으로 관리할 수 있는 프레임워크로 개발되었습니다. 데이터와 UI의 일관성을 자동으로 유지하고, 대규모 애플리케이션에서도 쉽게 확장할 수 있도록 했습니다.

 

---

 

React의 등장: 컴포넌트 기반 개발

• Virtual DOM과 컴포넌트 기반 아키텍처: Facebook에서 개발한 React는 Virtual DOM을 도입하여 DOM 조작의 성능 문제를 해결하고, 컴포넌트 기반 아키텍처를 통해 UI를 모듈화 했습니다. (가상돔이 항상 효율적이라고 볼 순 없다.)
• 효율적인 상태 관리: React의 상태 관리 시스템은 데이터가 변경될 때마다 UI를 효율적으로 업데이트할 수 있게 했습니다. 이를 통해 대형 애플리케이션에서도 일관된 UI와 상태 관리를 할 수 있었습니다.

 

개선점: 앵귤러와 달리 데이터가 부모에서 자식으로 흐르는 단방향 데이터 흐름을 채택하여 데이터의 흐름이 명확하고 예측 가능해졌고,

상태와 생명주기를 관리할 수 있는 hooks 방식을 채택해 코드의 간결함과 재사용성을 높임, JSX을 사용하여 UI를 선언적으로 작성할 수 있게 됨

 

주의해야 할 점

CSR로 인한 SEO 저하 ,리렌더링 성능 문제(props 가 변경되면 컴포넌트도 리렌더링), 타 SPA 프레임워크 대비 right-way 기준이 모호함

---

상태 관리의 진화 Flux 패턴, Redux, Zustand... 의 등장

웹 애플리케이션이 복잡해짐에 따라 컴포넌트 간의 상태 공유와 관리가 어려워졌습니다. 데이터의 흐름을 명확히 하고, 예측 가능한 방식으로 상태를 관리할 필요성이 대두되었습니다.

Flux 패턴

• 출현 배경: 페이스북에서 대규모 애플리케이션의 상태 관리를 위해 개발.
• 주요 특징: 단방향 데이터 흐름. 상태가 변할 때마다 액션을 통해 Dispatcher가 상태를 업데이트하도록 하여 데이터 흐름을 명확히 함.
• 해결하는 문제: 복잡한 상태 관리 및 컴포넌트 간의 비동기적 데이터 처리 문제.
  
  

Redux

• 출현 배경: Flux의 복잡성을 단순화하고, 상태 관리를 더 직관적으로 만들기 위해 탄생.
• 주요 특징: 단일 스토어, 불변성, 미들웨어 지원. 상태를 관리하기 위해 순수 함수인 리듀서를 사용.
• 해결하는 문제: 대규모 애플리케이션에서 상태를 더 쉽게 관리하고 디버깅할 수 있도록 지원. 개발자 도구와의 통합으로 상태 변화를 쉽게 추적 가능. props drilling문제 해결

현재는 zustand, recoil, jotai 등의 전역상태관리 도구들이 생겼다.

 

주의해야할 점

물론 전역 상태를 사용할 때 메모리 사용량 증가, 상태의 비효율적인 관리, GC 등의 문제를 고려해야 하는 번거로움도 생겼다.

 

---

Next.js: 서버사이드 렌더링과 정적 사이트 생성

• SEO와 초기 로딩 성능 문제 해결: Next.js는 React 기반의 프레임워크로, 서버사이드 렌더링(SSR)과 정적 사이트 생성(SSG)을 지원하여 검색 엔진 최적화(SEO)와 첫 화면 로딩 성능 문제를 해결했습니다.
• 하이브리드 애플리케이션: Next.js는 클라이언트사이드 렌더링(CSR)의 문제를 보완하면서도, SSR과 SSG를 유연하게 사용할 수 있는 하이브리드 애플리케이션을 가능하게 했습니다.

 

이외에도 Nextjs에서 여러 기술을 도입해 성능을 개선하고 있다.

 

Incremental Static Regeneration (ISR)

• 개념: ISR은 SSG의 확장으로, 정적 페이지를 생성하되, 특정 시간 간격으로 페이지를 재생성하여 최신 콘텐츠를 제공하는 기능입니다. 이는 정적 사이트의 장점과 동적 사이트의 유연성을 결합한 것입니다.
• 사용 예: 뉴스 사이트나 블로그에서 최신 기사를 주기적으로 업데이트할 때 유용합니다. 예를 들어, 10분마다 새로 고침 하여 콘텐츠를 최신 상태로 유지할 수 있습니다.

 

서버 컴포넌트

• 개념: Next.js 13에서 도입된 서버 컴포넌트는 서버에서 직접 렌더링 되며, 클라이언트에게 전달되는 HTML을 최소화하여 성능을 향상하는 기능입니다. 서버에서 데이터를 가져오고, 해당 데이터를 기반으로 UI를 구성합니다.
  
  쉽게 말해, 서버 컴포넌트(Server Components)는 서버사이드 렌더링(SSR)을 컴포넌트 단위로 세분화한 방식으로 볼 수 있습니다.
  
  
• 장점: 클라이언트의 자원 사용을 줄이고, 서버에서 모든 비즈니스 로직을 처리할 수 있어 애플리케이션의 성능을 최적화합니다. 데이터 패칭과 UI 렌더링이 서버에서 이루어지기 때문에, 클라이언트 측의 부담이 크게 줄어듭니다.

---

Vue.js: Right-way가 명확한

 

명확한 right-way: 코드의 양이 많아지면 "코드짜는 법이 제한적"인건 큰 장점이 될 수 있고 vue는 react에 비해 코드 짜는 답이 정해져있습니다. 

ex) map, forEach, for in, for of > HTML안에 v-for 사용

 

쉬운 학습 곡선: Vue는 직관적인 API와 HTML 템플릿 구문을 제공하여 초보자가 쉽게 배우고 사용할 수 있습니다.
HTML, CSS, JS만 알고 있어도 비교적 배우기 쉽다.

 

명확한 컴포넌트 구조: Single File Component(SFC) 형식을 통해 HTML, CSS, JavaScript를 한 파일에서 관리할 수 있어 코드 관리가 용이합니다.

---

Svelte: 컴파일 타임에서의 최적화

• Virtual DOM 없이 빠른 성능: Svelte는 Virtual DOM을 사용하지 않고 컴파일 타임에 UI 컴포넌트를 최적화하여 더욱 빠른 성능을 제공합니다. (런타임 라이브러리의 필요성이 줄어듦)
• 러닝 타임 오버헤드 제거: 컴포넌트를 사전 컴파일함으로써 런타임 성능 이슈를 최소화하고, 가벼운 웹 애플리케이션을 구축할 수 있게 합니다.

 

---

 

현대 프론트엔드는 빠르게 변화하고 있으며, 다양한 프레임워크와 기술이 등장하고 있습니다.
개인적으로 느끼는 바는 SSR(서버사이드 렌더링)과 SPA(싱글 페이지 애플리케이션) 사이에서 회귀하는 경향이 있다는 점입니다. 초기의 SSR은 SEO와 초기 로딩 성능에서 큰 장점을 제공했지만, SPA의 사용자 경험과 인터랙티브한 요소가 점차 중요해지면서 두 방식 간의 균형을 찾고 있습니다.

Next.js와 같은 프레임워크는 이러한 변화의 좋은 예시입니다. Next.js는 SSR과 SSG(정적 사이트 생성)를 모두 지원하여 개발자가 필요에 따라 최적의 방식을 선택할 수 있도록 해줍니다. 또한, 풀스택 개발을 지원함으로써 프론트엔드와 백엔드의 경계를 허물고, 보다 통합된 개발 환경을 제공합니다.

Vue, Svelte 등은 React의 단점을 개선하는 방향으로 발전하고 있지만, React의 압도적인 점유율과 넓은 생태계는 쉽게 흔들리지 않을 것으로 보이네요

하지만 jQuery는 여전히 리액트 다음으로 인기가 있다.

 

 

 

그리고 최근엔 AI 툴의 등장으로 HTML, CSS, 심지어 JavaScript 코드 작성의 생산성을 크게 향상시켰습니다.

 

이러한 변화 속에서 프론트엔드 개발자가 갖춰야 할 능력도 변할 수 있습니다. 예를 들어, 복잡한 요구 사항을 분석하고 적절한 아키텍처를 설계하는 능력은 더욱 중요해질 것입니다. 단순한 코드 작성이 아닌, 전체 시스템을 이해하고 최적의 솔루션을 제시하는 능력이 요구됩니다.

또한, 사용자 경험(UX) 디자인에 대한 이해와 설계 능력도 필수적입니다.

AI 도구가 기본적인 UI 요소를 생성하더라도, 사용자와의 상호작용을 최적화하고 감동을 줄 수 있는 디자인은 여전히 개발자의 몫입니다.

마지막으로, 커뮤니케이션 능력 역시 중요해질 것입니다. 팀 내 협업이나 고객 요구 사항을 효과적으로 이해하고 전달하는 능력이 프로젝트의 성공에 큰 영향을 미칠 수 있습니다. AI가 도와주는 작업 속에서도 사람 간의 소통과 협력이 필요한 부분이 여전히 존재하기 때문입니다.

이처럼 AI 시대에 발맞춰 프론트엔드 개발자는 기술적 능력뿐만 아니라 다양한 소프트 스킬도 함께 발전시켜 나가야 할 것 같습니다.