[TIL] 차근차근 CS (2) - Frontend 역사와 발전 과정

Today I Learned

인터넷과 웹의 탄생

오늘날 우리가 사용하는 인터넷은 1980년대 초 공식 정립된 TCP/IP를 기반으로 발전해, 1990년대 중반 즈음 전 세계 전자기기를 연결하는 물리적 네트워크 인프라로 대중화됐다. 사실 인터넷은 웹의 동의어가 아니고, 웹은 그 위에서 작동하는 하나의 서비스 중 하나다.

 

1970년대부터 인터넷이라는 개념은 이미 존재했지만 이는 연구용, 군사용, 혹은 대학에서 사용되던 폐쇄망이었다. 그러나 점차 전 세계로 보급되고 하이퍼텍스트(Hypertext; 링크가 달린 텍스트) 개념을 적용한 초기 웹이 등장하면서 폭발적인 인기를 누렸다. 그전까지만 해도 이메일(SMTP)이나 파일 전송(FTP) 용으로 사용했지만, 문서와 이미지를 볼 수 있는 '화면'인 웹 브라우저가 등장하나 너도나도 사용하기 시작했다.

 

웹의 3대 핵심 기술은 다음과 같다.

• HTML: 문서의 구조를 정의하는 마크업 언어다. 마크업 언어란 프로그래밍 언어처럼 복잡한 연산이나 논리 처리를 하는 게 아니라, 문서에 태그를 달아 브라우저에게 문서 구조만 알려주는 언어다. XML, HTML, SGML 등이 대표적.
• URL: 인터넷상 존재하는 문서, 자원의 고유 주소다. 통신규칙, 서버위치, 파일경로가 들어간다.
• HTTP: 웹 브라우저와 서버가 문서를 주고 받기 위해 준수하는 통신 규칙이다. 단방향 형태로, 요청은 Request, 응답은 Response로 구성된다.

정적 웹의 한계와 JavaScript의 등장

다만 정적 페이지에는 한계가 있었다. 서버에 미리 저장된 HTML 파일을 그대로 브라우저에 보여주는 방식인데, 인쇄된 전단지와 같아서 화면 변경이 불가능했다. 웹이 발전하면서 페이지를 시각적으로 꾸미려는 요구가 커졌고, 초기에는 HTML 태그 내 직접 스타일 코드를 삽입해 꾸미는 방식을 취했으나 만약 페이지 파일이 100개 있을 때 폰트를 하나 바꾸기 위해서는 100개의 파일을 모두 수정해야 하는 치명적인 비효율이 발생했다. 게다가 디자인 코드가 HTML 파일에 섞이면서 코드가 엄청 비대해지고, 유지보수가 거의 불가능한 상태에 놓이게 됐다.

 

따라서 웹 문서의 구조(HTML)와 표현(CSS; 디자인, 레이아웃 등)을 분리하는 방식이 고안됐고, 여기에 정적 웹 페이지가 사용자 행동에 반응해 동적으로 움직이게 만드는 JavaScript가 생겨났다. Netscape에서 10일 만에 개발된 언어로, HTML과 CSS가 단순 렌더링 마크업 파일인 반면 JS는 브라우저 내 실시간 실행되는 프로그래밍 언어였다.

 

브라우저는 HTML 파일을 읽는 즉시 페이지에 존재하는 모든 요소를 트리 구조 형태의 내부 지도로 메모리에 저장하는데, 이를 DOM 트리라고 부른다. JS는 이벤트(클릭, 키보드 입력, 스크롤 등) 기반으로 이 DOM 지도를 실시간 탐색해 원하는 요소를 찾아 내용을 바꾸거나 삭제하거나 새 요소를 추가한다. 새로고침 없이(페이지를 재로딩) 실시간 교체가 가능한 셈이다.

브라우저 렌더링 원리와 웹 표준

렌더링의 원리는 다음과 같다.

1. Parsing: HTML 파일을 위부터 쭉 읽으면 문서의 구조, 제목, 이미지 등 요소를 체크하고 DOM 트리를 만듦.
2. Render Tree: 파싱된 요소 중 실제 화면에 노출될 요소만 솎아냄.
3. Layout(Reflow): 화면에 표시될 요소가 브라우저 화면상 어느 좌표에 어떤 크기로 배치될지 기하학적 위치를 계산. 웹 최적화의 핵심이 바로 이 부분. 리플로우 연산이 빈번하게 일어나면 화면이 끊기고 버벅거리는 현상이 발생한다. 이 발생 빈도를 최대로 줄이는 것이 목표다.
4. Paint: 계산된 자리에 맞춰 색상, 이미지, 테두리, 그림자 등 시각적 스타일을 실제로 그림. 요소의 위치나 크기가 아닌 단순 색상만 변경될 때는 무거운 Reflow 대신 Repaint라는 작업을 수행하기도 한다.

하지만 Microsoft나 Netscape 등이 자기 브라우저 점유율을 굳히기 위해 표준을 무시하고 각자 고유 기능을 추가하며 서로 호환이 안되게 싸움을 벌였는데, 그 결과 크로스 브라우징 이슈가 발생하며 개발자들에게 고통을 안겨주던 '브라우저 전쟁' 시기가 있었다. 이 혼란을 막기 위해 W3C 국제 기구가 만들어지고, 모든 브라우저는 이 규칙대로 화면을 그려야 한다는 공식 웹 표준이 생겨났다.

프론트엔드 생태계 진화, jQuery에서 React로

이후 웹이 점차 대형화되면서 쇼핑몰, 웹메일, SNS 등 복잡한 대규모 애플리케이션으로 진화했고, 10일 만에 급하게 설계된 JavaScript 만으로는 유지보수가 어려워지는 단계에 도달했다. 2006년 등장한 것이 jQuery다. 브라우저마다 제각각이던 복잡한 DOM 조작 방법을 간결한 코드로 통일시켰고, 크로스 브라우징 이슈를 해결함과 동시에 코드 단축을 혁명적으로 이뤄냈다.

 

그럼에도 규모가 더 커지자 페이스북에서 오픈소스 React를 개발. 핵심 철학은 '데이터(State)가 바뀌면 화면(UI)가 알아서 바뀌게 한다'. 그전까지는 개발자가 변경해야 할 부분을 DOM에서 찾아 수정해야 했지만, 이제는 데이터만 관리하면 되는 자동 동기화 구조가 탄생한 것이다. 가상 DOM이라는 개념이 등장하는데, 화면을 바꿀 때마다 무겁게 Reflow를 하는 대신 메모리상에 가짜 DOM 지도를 띄워두고 변경된 부분만 한 번에 모아 실제 화면에 반영하는 기술을 적용해 성능을 극대화했다.

 

사실 이건 모든 개발 영역에 적용되는 영역이지만, Frontend 라이브러리의 핵심 요소는 다음과 같다.

• 추상화: 내부 복잡한 구동 원리는 숨기고, 단순하고 직관적인 인터페이스만 제공.
• 재사용성: 독립 부품을 '컴포넌트'로 쪼개고, 필요한 곳에 레고 블록처럼 재사용.
• 상태 관리: 복잡한 웹 앱 내부 데이터(State) 흐름을 체계적으로 통개. UI와 데이터가 불일치하는 버그를 원천 차단. 예를 들어 쇼핑몰 장바구니 같이 실시간 유지되고 변하는 데이터가 그 예시다.

이 과정에서 웹 페이지를 출판하듯 찍어내던 '웹 퍼블리셔'는 어느덧 복잡한 애플리케이션 로직과 상태를 다루는 'Frontend 개발자'로 정착하게 된다.

Node.js와 모던 웹 빌드 시스템

2009년 Node.js가 등장하면서 브라우저 내부에서만 돌아가던 JavaScript를 어느덧 브라우저 바깥(OS, 컴퓨터)에서도 범용적으로 실행할 수 있게 해주는 JS 런타임이 등장했다. 이로 인해 JS 진영의 도구 생태계가 폭발적으로 성장했는데, NPM(Node Package Manager)가 그 예시다. 프로그래밍 세계의 앱스토어로, 전 세계 개발자들이 만들어 둔 라이브러리 패키지가 여기에 등록되어 있다. 명령어 한 줄로 편리하게 외부 라이브러리를 다운로드할 수 있고, 만약 서비스 빌드를 했다면 명세서와 같은 package.json 파일이 생겨나는 것을 볼 수 있다. 어떤 라이브러리를 설치했는지, 이 라이브러리가 원활하게 작동하기 위해서는 어떤 하위 라이브러리가 필요한지(의존성 계산) 계산한 명세서와 같다. 내부에 보면 dependencies 항목이 있는데, 이게 requirements.txt와 같은 역할을 한다.

 

빌드란 작성한 소스코드를 배포하기 전 반드시 거쳐야 하는 정제 단계다. package.json 파일에 빌드 스크립트가 정의되어 있고, 주로 npm run build 명령어로 실행한다. 과정은 다음과 같다.

1. Transpiling: 개발자는 최신 JS, TS 코드를 사용하지만, 구형 브라우저는 이를 해석하지 못하기 때문에 이에 맞춰 하위 버전 문법으로 자동 번역해주는 과정이다. 대표적으로 Babel이 있지만 현대에는 AI 기술과 고성능 컴파일러를 도입해 비약적인 고속화를 이루고 있다고.
2. Bundling: 대규모 프로젝트는 수천 개 파일로 구성되어 있는데, 이 파일들을 하나하나 서버에 요청하면 네트워크 부하가 극심해진다. 그래서 흩어져 있는 수많은 파일들을 연관성 있는 큰 파일로 묶어 패키징하는 작업이 필요한데, 대표적으로 Webpack이 있다. 현재는 최신 도구인 Vite 등이 널리 사용되는 편.
3. Tree Shaking: npm을 통해 거대 패키지를 설치해도 실제로 사용되는 기능이 극히 일부일 수 있는데, 나무를 흔들어 죽은 잎을 떨어트리듯 한 번도 사용되지 않는 불필요한 코드를 추적해 솎아내는 작업이다. 여기서 최종 파일 무게를 대폭 줄인다.
4. Minification: 개발자가 가독성을 위해 작성한 주석, 공백, 줄바꿈, 긴 변수명을 모조리 극단적으로 압축해 파일 크기를 최소화한다. 사람이 알아보기 힘들 정도로 완전히 뭉개지지만 데이터를 극도로 적게 소모한다고.

렌더링 패러다임의 변화 (MPA, SPA, 하이브리드)

과거 웹 방식은 서비스 내 각 페이지마다 독립된 개별 HTML 파일이 서버에 존재하던 MPA(Multi Page Application) 방식으로, 사용자가 링크를 누르면 잠깐 번쩍이며 새로고침이 발생해 그 사이에 새로운 HTML 전체를 통째로 받아와 화면을 갈아 끼우는 구조였다. SPA(Single Page Application)은 마치 스마트폰 앱처럼 새로고침 없이 부드럽게 화면이 전환되기를 원하는 UX 요구에 맞춰 등장한 방식이다. 단 하나의 빈 껍데기 HTML 파일과 거대한 JavaScript 번들 파일만 최초에 다운로드한다.

 

CSR(클라이언트 사이드 렌더링) 기법을 통해 사용자가 메뉴를 클릭하면 주소가 바뀌는 하이퍼링크 이동처럼 보여도, 실제로는 JavaScript가 화면의 특정 컴포넌트만 역동적으로 교체해주는 방식을 사용. 이 덕분에 화면 전환 속도가 극도로 빨라지고 이전 화면 데이터 상태가 부드럽게 유지되며 모바일 앱과 흡사한 최적화 UX를 제공하는 것이 가능해졌다.

 

다만 최초 접속시 JS 번들을 한 번에 다 받아와야 하므로 시간이 오래 걸렸고, 구글과 네이버 등 검색엔진은 JS가 실행되기 전 아무 내용 없는 빈 HTML만 수집해 가기 때문에 SEO에 취약하다는 단점이 존재했다. 그래서 SSR(서버 사이드 렌더링) 기법이 등장해 과거 방식처럼 서버에서 미리 데이터가 채워진 완성형 HTML을 브라우저에 빠르게 던져주고, 대신 이 딱딱한 정적 HTML 위에 JS의 동적 유기물을 결합하고 주입하는 일명 Hydration(수분 공급) 방식이 인기를 끌기 시작했다. 현재는 CSR과 SSR의 장점을 섞어 쓰는 하이브리드 아키텍처가 많이 등장했고, 그중 가장 완성도가 높다고 평가받는 게 Next.js다.

---

Today I Listend to