프론트엔드의 역사 with React,Typescript,Next.js

개발을 아예 모르거나 다른 개발은 알고있지만 프론트엔드와 웹에대한 지식은 없는 분들에게 프론트엔드의 기술스택이 나온 이유를 쉽게 설명하기위해 작성된 글입니다.

아래부터는 나오는 모든 이야기는 픽션입니다. 웹2.0까지는 웹전반, 그리고 그 이후부터는 프론트엔드에 대해 이야가 합니다. 정확하지 않은 표현은 댓글로 남겨주시면 감사하겠습니다!

0. 등장인물

모든게 귀찮은 천재개발자 A

1. 웹의 등장 - 웹1.0

웹이 없던 시절 개발자A에게 업무가 주어집니다. 우리 회사를 소개하는 문서를 만들었으니 목록에 있는 1000명에게 메일을 보내라는 업무입니다. 50개쯤 메일을 보내다가 개발자A는 이런 생각을 하게됩니다.

"굳이 이걸 한명한명 한테 다 보내야하나? 공지사항을 마을 게시판에 걸어놓듯이 인터넷에서도 그런 문서를 올려놓고 보라고하면 안되나?"

개발자A는 문서들을 특정 주소에 올려놓을 수 있도록 개발했고 문서들끼리도 링크를 통해 다른 문서로 이동할 수 있게 만들었습니다.

이렇게 문서들이 링크로 연결된 모습이 마치 거미줄같아서 웹이라는 이름을 가지게 되었습니다.

이 때 기존에 문서를 작성하던 규칙과 다른 규칙이 필요해서 여러 기술을 사용해 규칙을 정합니다.

1) 페이지에 어떤 요소가 들어있는지를 작성하기위해서 HTML이 등장합니다.

2) 해당 요소를 디자인적으로 꾸며주기 위해서 CSS가 등장합니다.

3) 단순한 페이지의 이동이 아닌 특수효과를 개발하기 위해 JS가 채택됩니다.

이렇게 탄생한 웹1.0은 정보를 제공해주고 간단한 상호작용을 할 수 있었습니다.

2. 웹의 발전 - 웹 2.0(1)

행복하게 직장생활을 하던 개발자A에게 새로운 업무가 주어집니다. 이번에는 우리 웹 사이트를 보고 오는 문의 메일들을 하나하나 정리해서 다시 문서로 만들어달라는 지시였죠.

그러자 A는 귀찮아서 견딜 수 없었고 그러다 문득 이런 생각이 듭니다.

"내가 작성한 정보만 올려놓지 말고 다른 사람들도 내가 올려놓은 문서에 정보를 추가할 수 있게 해놓으면 되지 않을까?"

그러고 나서 생각해보니 지금은 그냥 내가 html로 작성해놓은 문서만 올려놓으면 됐었는데, 사용자들이 정보를 추가하면 html을 직접 수정할 수 없어서 문제가 생겼습니다.

그러다 "아 그러면 특정 데이터를 모아놓은 곳을 만들고 사용자들은 데이터를 모아놓은곳에 정보를 추가하고 나는 그 데이터를 모아놓은 곳에서 데이터를 가져와서 html로 다시 작성하면 되겠다" 라는 생각을 하게됐죠

그 저장소를 데이터베이스라고 부르게 되었고, 그러면서 자연스럽게 현재 백엔드 라고 부르는 기술들이 발전하게 되었습니다.

3. 웹의 전성기 시작 - 웹2.0(2)

이렇게 여러 업무를 멋지게 소화해낸 개발자A는 이제는 쉴 일만 남았다고 생각했습니다. 그런데 이제 여러 웹사이트들이 생기다 보니 웹 사이트에 들어가야 할 정보가 중요해졌습니다. 그래서 회사에서는 어떤 정보를 우리가 제공해줄지 계속 생각하라고 했습니다. 그렇게 고통받던 A는 다시한번 천재적인 생각을 하게됩니다.

"굳이 내가 어떤 정보를 제공해줄지 생각하지 않아도 사용자들이 작성한 정보를 또다른 사용자들에게 제공하면 되지 않나?"

기존에는 사용자들에게 정보를 받기는 했지만, 단지 정보를 받을 뿐이지 여전히 사이트 소유자의 정보 제공이 목적이였습니다.

하지만 A가 새롭게 생각한 사이트는 사용자들에게 입력 받는 정보 자체가 콘텐츠가 되는 사이트였습니다.

이전까지는 웹사이트의 소유자가 방문자들에게 일방적으로 정보를 제공했는데, 이제는 웹사이트를 방문한 사람들도 소유자에게 정보를 전달할 수 있게 되면서, 버튼을, 인풋, 체크박스 같은 UI요소들과 그 UI를 컨트롤하기 위해서 자바스크립트가 점점 복잡해 졌습니다.

4. 제이쿼리의 시대

사용자들에게 다양한 인터렉션을 제공해주기 위해서 자바스크립트로 개발하던 A는 생각보다 본인이 끔찍한 개발 언어를 선택했다는 사실을 깨닫습니다.

기존에 간단한 작업을 할 때에는 아무런 문제가 없었는데, 복잡한 작업을 수행할수록 작성해야하는 코드는 길어지고 헷갈렸습니다.

그러다가 이렇게는 안되겠다 싶어서 언어를 잘 쓸 수 있는 라이브러리를 만들기로 했습니다. 여전히 언어로써의 문제는 있었지만 라이브러리를 사용하니 그래도 쓸만했습니다.

그 라이브러리의 이름은 제이쿼리라고 부르기로 했습니다.

5. SPA 프레임워크의 탄생

A는 여러가지 사업 아이템을 시도하다 마침내 얼굴책 이라는 서비스를 만들었습니다. 해당 서비스는 각자 글과 사진을 공유하며 채팅도 할 수 있고, 좋아요도 할 수 있고, 댓글도 달 수 있고 등등 수없이 많은 기능이 존재했습니다.

기존에는 페이지별로 나눠서 하나의 html파일이 있었고 그 html들을 링크로 이동하며 옮겨다니는 방식이였습니다.

그런데 이렇게 많은 기능을 하나의 화면에서 수행하다보니 html을 수없이 커졌고 안그래도 좋지 자바스크립트로 인해 아무리 천재개발자인 A라도 점점 버거워 졌습니다.

그렇지만 A는 천재이기 때문에 해결책을 생각해냅니다.

"하나의 화면이라고해도 하나의 html에서 개발하지 말고 작은 단위로 나누어서 개발하면 어떨까? 하지만 html자체는 나눌 수가 없으니 자바스크립트로 html의 일부를 수행하는 코드를 작성해야겠다!"

이렇게 나눈 작은 단위를 컴포넌트 라고 부르기로 했습니다. 그리고 이렇게 나눠놓은 컴포넌트들을 조합해서 화면을 만들었습니다.

마침 A는 다른 문제도 가지고있었는데요, 기존에 하나의 html에서 다른 html로 넘어갈때 인터넷에서 새로운 파일을 가져오는 것이기 때문에 화면이 깜빡이던 현상이 있었습니다.

마침 이제 html 단위로 개발하는것이 아니라 여러 컴포넌트를 조합해서 html을 구성하는 것이기 때문에 html파일의 갯수는 몇개든 상관이 없었습니다. 그래서 하나의html에서 불러오는 방식으로 개발해야겠다고 A는 생각했습니다.

그래서 이렇게 개발하는 방식을 html페이지가 하나라고해서 Single page Application 줄여서 SPA라고 부르게 되었습니다.

그리고 A는 이 SPA라이브러리의 이름을 리액트라고 지었습니다.

6. 타입스크립트

A는 페이스북으로 대박이났고 엄청난 부자가 되었습니다. 그리고 수백명의 개발자들도 고용했죠.

승승장구하던 A에겐 문제가 하나 있었습니다.

다행히 자바스크립트는 많이 발전해서 쓸만한 언어가 되었습니다. 하지만 여전히 남아있는 문제중 하나는 타입이라는 개념이 없다는 것이였죠.

혼자서 개발할때는 내가 모든것을 알고있어서 상관이 없었지만, 다른 수백명의 개발자들이 동시에 개발하니 문제가 하나 둘 나오기 시작했습니다.

개발자B는 좋아요를 숫자로 저장했고, 개발자C는 좋아요를 문자로 저장했습니다.

그런데 개발자D가 두개를 더해버렸습니다.

자바스크립트는 놀라운 유연서을 발휘해서 좋아요 451과 좋아요 '121'을 더해서 '451121'로 만들어버렸죠

개발자 A는 갑자기 좋아요가 100배나 늘어나는 끔찍한 현상이 펼쳐졌지만 B,C,D누구도 탓할 수 없었고, 이대로는 안되겠다고 생각했습니다.

그렇다고 이미 너무 커져버린 자바스크립트 대신 다른 언어를 고르기에는 문제기 있었고 그러다가

"자바스크립트를 그대로 유지하면서 대신 개발할때만 타입을 정해주면어떨까?"

하는 생각이 들었고 그렇게 타입스크립트 라는 언어가 탄생하게 되었습니다.

이제 개발자B,C가 좋아요를 서로 다른 형식으로 저장하더라도 개발자D는 그것을 더할 수 없게 되었습니다.

7. 다시 멀티페이지로

이제 모든게 완벽했던 A는 이제 마음편히 놀고 먹을날만 남았다고 생각했습니다. 그런데 평소 알고지내던 또다른 천재개발자Z에게 연락이옵니다.

"A야 니 사이트 너무 좋은데 내가 만든 검색 사이트에서 검색이 잘 안돼"

알고보니 검색 사이트들은 인터넷에 올라와있는 페이지의 여러 정보를 읽어와서 검색 정보를 사용자들에게 제공하는데, SPA로 만들어진 사이트들은 초기에는 빈 html로 있다가 여러 컴포넌트들을 자바스크립트로 만들어서 구성하기 때문에 검색이 안되는 현상이 발생한 것입니다.

개발자 Z역시 엄청난 천재이기 때문에 Z의 검색 사이트는 금방 SPA로 만들어진 사이트들도 검색이 잘되도록 업데이트가 되었습니다.

하지만 모든 검색사이트들의 개발자가Z같지는 않았고, Z의 페이지 마저도 멀티페이지 보다는 검색이 조금 덜 되었기 때문에 A역시 해결책을 생각하게 되었습니다.

"음... 문제가 html이 비어있다는거면 미리 서버에서 html을 만들어서 넘겨주면 되잖아?"

천재개발자A는 천재적인 생각으로 이 문제를 해결했고 서버에서 렌더링(자바스크립트가 html을 생성하는 과정)을 한다고해서 Server Side Rendering이라고 부르고 줄여서 SSR이라고 하기로 했습니다.

마치는글

이제 정말로 행복해진A는 억만장자가 되어 업계를 떠났고. 우리에게는 아래와 같은 기술 스택이 남게 되었습니다.

제이쿼리 - 기존에 웹에서 엄청나게 많이 쓰였지만 지금은 프론트엔드에서 거의 쓰이지 않음

SSR 프레임워크 - Next.js / Nuxt.js / SveletKit ...

SPA프레임워크 - React / Vue / Svelt ...

자바스크립트에 타입을 추가 -Typescript

이 글이 프론트엔드를 시작하거나 관심이 생기신 분들에게 도움이 됐으면 좋겠습니다. 이해하기 쉽게 작성하려다보니 부정확한 내용이 있을 수 있으니, 실제로 해당 프레임워크의 탄생 스토리는 따로 확인해주시길 바랍니다! 긴 글 읽어주셔서 감사합니다