브라우저는 뭐야?

라고 친구가 묻는다면 어떻게 대답할 지 생각해 보신 적 있나요?
‘인터넷 들어가게 해주는 거, 사이트 들어갈 때 사용하는 거’라고 대답하시려고 했나요? 틀린 말은 아니죠ㅎㅎ

근데… 면접관이 브라우저에 대해 물었는데 똑같이 대답하실건가요?
그럼 브라우저가 아니라면 우리는 웹 사이트에 들어갈 수 없을까요?

우리는 브라우저와 붙어 살며 브라우저 위에서 돌아가는 장난감을 뚝딱하는 프론트엔드 엔지니어잖아요? 브라우저가 무엇인지 멋지게 대답하는 프론트엔드 엔지니어의 모습을 보여주자 이말입니다.

⛓️‍💥 역사

저만 그런지는 모르겠으나 뭐든 진득하게 알아보려면
그것의 ‘역사’부터 알아보는게 진정한 배움의 자세라고 생각합니다ㅋㅋ
그래서 간단하게 역사를 좀 보도록 하죠.

세계 최초의 웹 브라우저는 1990년, 오늘날에도 웹 표준화를 주도하고 있는 W3C라는 회사의 감독자였던 팀 버너스 리가 발명하였습니다. 바로 WWW 월드 와이드 웹입니다.

월드 와이드 웹은 전 세계를 연결하는 거대한 컴퓨터 네트워크로, 하이퍼텍스트 문서, 이미지, 음악, 영상, 리소스 등으로 서로 연결되어 있습니다. 월드 와이드 웹을 줄여서 웹이라고 부르기도 하죠.

팀 버너스 리는 1989년 CERN(유럽 입자 물리 연구소)에서 근무하던 중 세계의 여러 대학과 연구 기관에서 일하는 직원들과 정보를 공유하는 것에 어려움을 느꼈습니다. 당시 전 세계의 CERN 직원들은 각자 다른 하드웨어와 소프트웨어를 사용하고 있었는데, 각 직원이 작성한 자료와 기술 문서는 다양한 컴퓨터에 서로 다른 파일 형식으로 저장되어 있어 원하는 정보를 찾기 어려웠었습니다.

이런 어려움을 해소하기 위해 만든 것이 인콰이어(Enquire)라는 이름의 시스템입니다.
팀 버너스 리는 인콰이어를 기반으로 여러 가지 정보를 찾는 방법을 통일하는 시스템을 개발했습니다. www로 시작되는 주소를 입력하거나 하이퍼링크(Hyper Link)를 클릭하며 원하는 정보를 찾을 수 있게 만든 것이죠. 이 시스템이 바로 월드 와이드 웹입니다.

그 이후로 1993년 NCSA에서 개발한 Mosaic, 1995년 Mosaic 개발자들이 만든 Netscape Navigator와 마이크로소프트의 Internet Explorer가 치열한 경쟁을 펼치는 시대가 왔고 이 시기에 Netscape에서 우리가 밥먹듯이 보게 되는 언어인 JavaScript를 개발하게 됩니다. 동적 웹 페이지의 시대를 열게 된거죠! 1년 뒤인 1996년에는 웹 문서의 스타일링을 위한 CSS도 등장합니다!

이어서 웹 표준화도 활발히 진행되었고, 오늘날까지 사용되고 있는 브라우저들이 하나씩 출시되었습니다.

2003년 – Mozilla Firefox, Safari
2008년 – Google Chrome
2022년 - Arc

⛓️‍💥 개념

누가 물으면 뭐라고 할까?

인터넷에 들어갈 수 있는 거! 사이트에 접속하게 해주는 프로그램!이라고 해도 의미는 통하지만 웹 페이지에 액세스한 뒤 정보를 탐색하고 여러 콘텐츠를 우리에게 표현해주는 소프트웨어라고 말해주세요!

무슨 차이냐구요? 브라우저가 정보를 탐색하고 표현해주는 일을 한다는 걸 프로답게 표현했잖아요!
여러분은 IE, Chrome, Firefox, Safari, Edge 중에서 뭐 쓰시나요? 저는 Chrome이랑 Firefox를 씁니다!
(혹시 Tor라는 엄청난 브라우저는 써보셨나요 ㅋㅋ)

브라우저가 하는 일은 뭐라 해?

우리가 브라우저를 키면, 입력된 웹 주소로 접속해서 해당 주소의 자원을 불러오기 위해 서버로 자원을 요청하고 가져온 다음 우리에게 보여주죠. 여기서 자원은 일반적으로 HTML 문서 를 가리킵니다. 우리가 보는 웹 페이지는 HTML 문서이기 때문이죠! 물론 HTML만 가져오는 것은 당연히 아닙니다.

네이버 홈의 쇼핑 탭

HTML, svg+xml, JavaScript 파일, CSS 파일, 이미지, 폰트, favicon 등을 서버로부터 받게 되죠.
위의 이미지를 보시면 좌측은 HTML 문서만 있을 때의 모습이고, 오른쪽은 필요한 파일들을 다운로드 후 스타일이 적용된 모습입니다.

❓ 웹과 인터넷의 의미 차이는 뭐에요

은근 많은 사람들이 웹 = 인터넷으로 개념을 잡고 있는데 확실히 짚고 넘어가보면 좋겠네요.
웹은 인터넷에서 동작하는 하나의 서비스이고, 인터넷은 전 세계적으로 연결된 컴퓨터 네트워크 통신망을 의미합니다. 웹이 하위의 개념인 셈이죠. 인터넷에는 웹, 이메일, 동영상 스트리밍, 모바일 애플리케이션 등이 모두 포함되어있습니다. (웹 < 인터넷)

⛓️‍💥 구조

GUI

브라우저를 버튼을 클릭하면서 편하게 조작할 수 있는 것은 GUI를 사용하기 때문입니다.
GUI는 운영체제를 공부하셨을 때도 들어보셨을거에요.
까만 화면에 명령어만 입력하여 조작하는 CLI와 반대죠.

우리가 뒤로가기/앞으로 가기, 새로고침, 홈 이동, 주소창 입력, 북마크 버튼 등등 간편하게 조작할 수 있는 이유입니다. 렌더링 엔진이 HTML, CSS, JavaScript를 해석하여 시각적으로 표현한 결과물을 사용자에게 보여주는 인터페이스라고 생각하시면 됩니다!

UI 백엔드

• 기본적인 위젯을 그리는 인터페이스로, 플랫폼에서 명시하지 않은 일반적인 인터페이스입니다.
• 운영체제의 UI 체계를 활용하거나 별도로 구현할 수 있습니다.

UI 프론트엔드

• 주소창, 즐겨찾기, 뒤로/앞으로 가기 등과 같은 UI 구성 요소를 담당합니다.
• 사용자의 입력을 처리하고, 렌더링 엔진에게 명령을 내리는 역할을 합니다.

렌더링 엔진

• 요청한 콘텐츠 HTML, CSS, JavaScript 등의 코드를 parsing하여 화면에 렌더링하는 역할입니다.
• Chromium/Blink(Chrome, Opera), WebKit(Safari), Gecko(Firefox), Trident/EdgeHTML
  (Internet Explorer, Microsoft Edge)

자바스크립트 엔진

• 자바스크립트 코드를 해석하고 실행합니다.
• V8(Chrome, Edge), SpiderMonkey(Firefox), Chakra(Edge 78ver 까지)

네트워크

• HTTP 요청과 같은 네트워크 요청을 처리하는 역할을 합니다.
• 브라우저는 네트워크 스택(Network Stack)을 통해 이 기능을 구현합니다.

데이터 스토리지

• 로컬 스토리지, 세션 스토리지, 쿠키와 같은 메모리를 사용하여 데이터를 저장하는 영역입니다.

브라우저 보안

• 브라우저는 사용자의 개인정보 보호를 위해 보안 기능을 제공합니다.
• CORS(Cross-Origin Resource Sharing), 샌드박스(Sandbox), HTTPS

Critical Rendering Path

자 브라우저의 개념과 구조에 대해서 전체적인 그림을 봤습니다. 재밌죠? 감사합니다!
그럼 브라우저가 어떻게 콘텐츠를 표시하는지 HTML, CSS, JavaScript를 가지고 어떻게 화면에 콘텐츠를 렌더링하는지 프론트엔드 엔지니어가 할 수 있어야 하는 설명을 위해 Critical Rendering Path에 대해서 알아볼겁니다!

참고로 Critical Rendering Path에서 중요한 역할인 자바스크립트의 핵심 개념 자바스크립트 실행 컨텍스트는 다루지 않을 예정입니다. 궁금하시다면 아래의 제 포스트를 참고해주세요.

🔗 https://velog.io/@windowook/JavaScript-JavaScript-Engine-Essentials

⛓️‍💥 구조

Critical Rendering Path, 우리말로 중요 렌더링 경로는 다음을 의미합니다.

브라우저가 HTML, CSS, Javascript를 화면에 픽셀로 전환하는 일련의 단계

• 브라우저에서 웹 페이지에 대한 요청은 HTML 요청으로 시작됩니다.
• 요청을 받은 서버가 HTML을 포함한 응답을 전달합니다.
  • 브라우저는 HTML을 파싱하고 DOM 트리로 변환하죠.
• style sheet, script, image와 같은 외부 자원에 대한 링크를 찾으면 요청을 보냅니다.
  • 불러온 자원을 처리할 때 까지 다음 내용을 분석하는 작업 요청은 중단됩니다.
  • 브라우저는 CSSOM을 구축하는 작업이 끝날 때까지 요청을 보내고, DOM을 생성하는 HTML을 다시
    계속해서 파싱합니다. DOM과 CSSOM 구축이 완료되면 브라우저는 이 둘을 가지고 렌더 트리를
    생성합니다. 렌더 트리는 보여지는 모든 콘텐츠의 스타일을 계산해요.
• 그 후에 레이아웃이 실행되고 모든 렌더 트리 요소의 위치 및 크기가 정의됩니다.

이 과정이 끝나면 페이지는 렌더되거나 화면에 페인트됩니다.
그럼 우리는 화면으로 웹 페이지가 가져온 자원을 눈으로 볼 수 있게 되는거죠.

⛓️‍💥 리렌더링과 성능

자, 아까 말씀드린 것처럼 브라우저는 HTML과 CSS를 읽어서 화면을 구성하는 렌더 트리를 만들고, 그걸 기반으로 화면을 그려요. 그런데 여기서 자바스크립트가 등장하면 이야기가 달라집니다.

DOM과 CSSOM 사이에 보이시죠? 자바스크립트가 흐름을 멈추거나 다시 시작하게 만들 수 있습니다!
React를 사용하며 발생하는 '리렌더링'도 결국 이 흐름 안에 있어요. (VDOM을 사용하긴 하지만 본질은 같아요)

자바스크립트가 DOM이나 CSSOM 안의 내용을 바꾸게 되면, 브라우저는 기존에 만들었던 렌더 트리를 버리고 다시 처음부터 화면을 그려야 해요. 마치 그림을 다 그려놨는데, "아! 여기 색 다시 칠해야겠네" 하면서 지우개 들고 다시 시작하는 것처럼요. 당연히 다 지우고 다시 그리고 색칠까지 한다면 뭔가 오래걸리는 작업같이 느껴지시죠?

이런 리렌더링이 너무 자주 일어나거나, 한 번에 너무 많은 DOM을 바꾸면 브라우저는 화면을 다시 그리는 데 더 많은 시간과 연산을 써야 하고, 그만큼 초기 화면이 늦게 보이거나 인터랙션이 끊기는 문제가 생길 수 있어요.

우리에게 익숙한 React는 SPA잖아요? HTML 한 장만 있고, 나머지 화면은 JS가 다 처리하는 방식인거죠. 상태를 바탕으로 상태의 변화에 따라 동적으로 새롭게 부분 리렌더링을 하는 거니까 당연히 성능에 관한 문제도, 페이지 로딩 시간에 대한 문제도 존재하는겁니다!

• 자바스크립트 파일이 없을 땐 아무것도 안 보여요.
• 스크립트 파일 로딩이 늦으면 사용자는 하얀 화면만 보게 돼죠. (White Screen Problem)
• 때문에 처음에 빈 HTML을 받으니까 → 크롤러는 자바스크립트 실행을 제대로 못해서 콘텐츠를 못 읽어요.
• 상태가 자주 업데이트 되면, 그 만큼의 리렌더링 횟수가 발생합니다!

React는 유저 경험을 위해 상태를 활용한 리렌더링을 적극 활용하는 모던 프론트엔드 개발의 중요한 도구이지만, 클라이언트 사이드의 한계에 갇혀 있기 때문에 초기 렌더링이나 SEO 측면에서는 약점이 있었던 거죠.

Next.js를 쓰는 이유

Vercel은 이러한 한계를 극복하기 위한 엄청난 도구를 출시하죠. 바로 Next.js입니다.

Next.js의 정의는 이렇습니다.

풀스택 웹 애플리케이션 구축을 위한 React 프레임워크

2016년 10월 25일에 Vercel이 이름을 바꾸기 전 ZEIT이라는 기업 이름으로 오픈 소스 프로젝트인 Next.js를 처음 출시합니다. React 기반의 웹 애플리케이션 개발을 위한 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG)을 지원하여, 초기 로딩 속도 향상과 SEO 최적화를 목표로 개발되었습니다.

그렇다면 Next.js를 사용함으로써 React만 쓸 때보다 좋아진 점은 어떤게 있는걸까요?

• 초기 로딩을 빠르게
  • HTML을 미리 만들어서 사용자에게 빠르게 보여줍니다.
• SEO
  • 크롤러가 JS 없이도 콘텐츠를 읽을 수 있습니다.
• 리렌더링 최소화
  • 필요한 부분만 리렌더링하거나, 정적으로 미리 만들어 둘 수 있습니다.

⛓️‍💥 초기 로딩 성능

React만 사용할 경우, 브라우저는 JS 번들이 로드되고 실행되기 전까지는 아무런 화면도 보여주지 못합니다.
그 결과, 사용자는 화이트 스크린(White Screen)을 보면서 기다리는 시간이 생기죠.

Next.js는 이걸 이렇게 해결합니다.

• SSR(서버 사이드 렌더링)을 통해 브라우저가 JS를 받기 전에도 이미 완성된 HTML을 보여줄 수 있어요.
• 또는 SSG(정적 사이트 생성)을 이용하면, 아예 빌드 시점에 HTML을 만들어둬서 서버 부하 없이도
  빠르게 전달됩니다.
• 페이지 이동 시에는 오토 코드 스플리팅으로 필요한 JS만 불러오고, 기존 렌더 트리를 재사용해서
  빠른 반응성을 유지합니다.

결과적으로 사용자 입장에서는 화면이 바로 뜨고, JS는 뒤에서 필요한 부분만 점점 채워 넣는 구조가 돼요. 이게 우리가 아는 Next.js의 Hydration(하이드레이션)입니다.

⛓️‍💥 SEO (검색 엔진 최적화)

SPA 구조의 React는 초기에는 콘텐츠가 없는 HTML만 전달하기 때문에, 검색 엔진이 페이지 내용을 제대로 수집하지 못합니다.

Next.js는 두 가지 방식으로 이 문제를 해결합니다.

• SSR을 통해 초기 HTML에 실제 콘텐츠가 포함되므로, 크롤러가 쉽게 콘텐츠를 읽을 수 있습니다.
• 필요에 따라 메타 태그나 Open Graph 태그도 동적으로 설정할 수 있어서, 소셜 미디어 공유 시에도
  좋은 미리보기를 제공합니다.

덕분에 구글이나 네이버와 같은 포털 사이트에서 검색 결과로 콘텐츠 노출 측면에서 훨씬 유리한 구조가 됩니다.

⛓️‍💥 리렌더링 최소화 (feat. 프리렌더링, 캐싱, CDN)

자바스크립트는 DOM을 수정하면서 리렌더링을 유발하죠.
이건 유연하지만, 자주 발생하면 성능에 부담을 줍니다. 특히 모바일 환경에서는 더 크게 체감돼요.

Next.js는 이런 리렌더링을 미리 준비하고 덜어주는 구조를 제공합니다.

• 프리-렌더링 (SSG/ISR)
  빌드 타임(배포할 때)에 HTML을 미리 생성해서, 요청이 오면 서버는 그냥 그 HTML을 바로 전달해요
  자주 안 바뀌는 페이지에 적합합니다.

• 캐싱 전략
  서버 또는 CDN에 결과물을 캐싱하여 동일한 요청을 다시 처리하지 않아도 됩니다.
  서버에서 페이지나 API 응답을 생성하면, 그 결과를 캐시에 저장해요.
  다음 요청이 오면 서버는 다시 처리하지 않고, 그냥 저장된 결과만 보여줘요.

• CDN 연동
  Next.js는 Vercel과 연결하면 전 세계 어디서나 빠르게 응답할 수 있어요.
  Next.js는 기본적으로 정적 자산(JS, CSS, 이미지 등)을 CDN에 배포하고,
  SSG/ISR로 만들어진 페이지도 CDN에서 바로 서빙됩니다.

✅ 결과적으로

React만 쓸 때보다 리렌더링 횟수는 줄고

사용자에게는 항상 빠른 웹이 제공되며

서버 비용도 줄어드는 일석삼조의 효과

를 얻을 수 있습니다!

더 깊은 지식을 원한다면 찾아보기

(개인적인 생각으로 중요도 순에 따라 별점을 매겨봤습니다!)

⭐️⭐️⭐️⭐️⭐️ 자바스크립트 실행 컨텍스트
⭐️⭐️⭐️⭐️⭐️ React의 렌더링 메커니즘 - VDOM과 DOM (배치 업데이트)
⭐️⭐️⭐️ React 19 + Next.js 15로 프론트엔드 엔지니어가 할 수 있게 된 것들
⭐️⭐️⭐️ Next.js에서 Streaming SSR이란?
⭐️⭐️⭐️⭐️ Next.js 컴포넌트를 자유자재로 설계하는 시야를 넓히기 (클라이언트 vs 서버)