반갑다.

나는 흔하디 흔한 웹쟁이다.


얼마전 SSR은 JS를 서버에서 실행해! 라는 뭔 개같은 소리를 들어서 참을 수 없었다.

적어도 저기 말하는 서버부터 정확히 정의해야 듣는 사람이 이해를 편하게 할 수 있으리라 생각한다.

회사에선 협업능력 중요하게보니 부디 저런 몰이해스러운 용어는 최대한 지양하자

먹이를 주지 말껄 ㅅㅂ 왜 긁혀가지고 ㅡㅡ


그래서 적어도 웹쟁이를 지향하는 다른 친구들을 위해서라도 간단하게 브라우저에 대해 알아보려 한다.


브라우저(Browser)



브라우저 역시 프로그래밍된 하나의 응용소프트웨어다.

현대 브라우저는 멀티 프로세싱 기반으로 제작되어 내부에 코어 엔진 포함 여러 기능과 해석기를 주렁주렁 달고있다.

(크롬 램 쳐먹는것좀 봐라.)


브라우저의 멀티 프로세싱 구조를 도식화한걸 보자.


[Browser Process]

    ├─ Network Service (DNS/캐시/프록시/연결풀)

    ├─ GPU Process (합성/래스터 가속)

    └─ 탭들(Tabs)

                ├─ Renderer #1 (example.com)

                └─ Renderer #2 (cdn.other.net - OOPIF)


  • Browser Process: 탭/세션/권한 관리, 탐색 제어, 네트워크 서비스 조정
  • Renderer Process: HTML/CSS/JS 파싱·실행, 레이아웃/페인트/합성
  • GPU Process: 레이어 합성·래스터(그리기) 가속
  • Site Isolation/OOPIF: 서로 다른 출처는 다른 렌더러로 분리되어 보안 경계 강화


브라우저 프로세스는 탭과 세션, 권한뿐 아니라 브라우저라는 소프트웨어의 작업을 총칭한다.

즉, 탭 여러개 띄우면 그만큼 프로세스 늘어나는거라 생각하면 된다.


각 탭들에서는 Randerer 들이 열심히 일하고 있는데, 렌더러 내부 스레드 개요를 살펴보면


Main(파싱·JS·레이아웃),

Compositor(합성/VSync),

Raster(비트맵),

Worker(백그라운드 연산)

I/O(네트워크 콜백)


이런 스레드로 이루어져있다.

궁금한 키워드로 검색하면 내용 자세히 나오니까 공부하고 싶으면 찾아보도 좋다.


이제 브라우저의 큰 작업 흐름을 봤으니 구성요소를 살펴볼 차례다.


  • User Interface: 주소창, 뒤로/앞으로, 탭 등 사용자 인터랙션
  • Browser Engine: UI ↔ 렌더러 간 명령/결과 중개
  • Rendering Engine: DOM/CSSOM/Render Tree 생성, 레이아웃·페인트·합성
  • Networking: DNS, 캐시, 프록시, 연결 풀, HTTP/2·3 전송 관리
  • JavaScript Engine: JS 파싱/실행, 이벤트 루프, GC
  • UI Backend: OS 위젯/폰트/그래픽 API 연결
  • Data Storage: 쿠키, Storage APIs(Local/Session/IndexedDB), HTTP 캐시 등


UI는 말그대로 우리가 인터렉션하는 모든 것이다. (뒤로가기, 홈버튼, 설정, 주소창 등등)

이 UI의 인터렉션을 처리하는 것이 브라우저 엔진이며 브라우저 실행흐름의 전반을 담당한다.


그리고 우리가 맨날천날 보는 화면을 구성하는 렌더링 엔진 / JS 엔진이 포함되어 있다.

기본적으로 JS를 실행한다의 의미는 이 클라이언트에 존재하는 JS 엔진을 의미한다.

(크롬엔 V8엔진이 담당하고 있다.)


살짝 사족을 덧붙히면 굽,비나온 나는 학원에서 JS는 인터프린터 언어라고 배웠다.

요즘은 반만 맞다. 애초에 V8 내부에도 JIT 컴파일러 들어있고 컴파일 쳐서 실행시키고 있으니까.



무튼 이제 기본적인 브라우저의 작동방식을 살펴 봤으니 개멍청한 질문을 하나하나 해체해보자.



재료) SSR은 JS를 서버에서 실행하지?


문제 정의)


 - SSR 런타임 명시가 없음.

 - 서버에 대한 정의가 없음.

 - 렌더 JS, 이벤트 리스너, 데이터 바인딩 구분 부정확

 - 하이드레이션 없이 런타임에서 전부 처리하는게 뭔 의미인지 ㅈ도 모르겠음


해석)


백번 양보해서 질문자가 브라우저에 대한 이해가 있다고 가정해보자.

그러면 적어도 node runtime 인지, template engine SSR인지 명시도 안할리 없다.


아마 리액트 들고왔으니 node runtime이라고 생각하고 진행해보자.

node.js 내부엔 Runtime(JS Engine) 이 들어있다 크롬 브라우저랑 똑같은 그 V8이 말이다.

그러면 우리는 가상의 환경을 정의해보자.


=====================


[Client]

Rect/Next (node runtime) SSR


   |


[Server]

Java/Python API Server


=====================


해당 환경 구성에서 SSR 실행 Flow를 그려보면


1. 요청이 서버로 들어옴

2. 서버 런타임(Node/Edge)의 JS 엔진이 React/Vue 렌더링 코드 실행

3. HTML 생성 → 응답

4. 브라우저는 HTML을 즉시 렌더링

5. 이후 브라우저의 JS 엔진이 번들 JS 실행 → Hydration(이벤트/상태 연결)


이런 순서로 진행된다.


개멍청한 질문 재료를 다시 한 번 보자.

'JS'는 '서버' 에서 실행되는거지?


Next 내부의 노드 런타임도 우리가 웹 개발에서 말하는 서버라고 확장해서 말할수 있으니까 맞다고 해줘야 하는거냐?

노드 런타임도 서버라면 엣지 런타임도 서버라고 하자? 앞으로?

그리고 다음에 하이드레이션 나는건 JS가 아니고? 그건 클라이언트에서 실행하는데?

SSR하면서 하이드레이션은 생각도 안 한걸까?

나도 어중이떠중이 개발자지만 적어도 인과나 내가 무얼 설명하려는지 공식문서, 자료조사, 시니어 커피챗 등등 발품 팔아서 공부한다..

그래서 더 긁혔나보다.


각설하고 SSR의 장점인 초기로딩이 빠르다. 라는 부분은 저기 보이는 1번부터 4번까지의 내용이다.

CSR은 번들 JS를 모두 내려 받은 다음에 렌더링을 하기에 초기구동이 SSR보다 느리다고 표현한다.

물론 SSR은 반대로 초기엔 아무런 이벤트가 바인딩 되어있지 않아서 유저 인터렉션이 멈출수도 있다.(하이드레이션 전까지)


나도 백엔드판에서 열심히 발버둥 치고 있지만 어느순간부터 웹 자체를 좋아하게 되기도 했고,

뭐 겸사겸사 그동안 공부한걸 나눠보는 시간을 꾸준히 가져보고 싶기도 하고..


무튼 백엔드 갤러리라고 클라가뭔데! 이러지말고 웹 기술 안에서 결국 나처럼 ㅈ소 들어가면 개잡부마냥 다해야하니까

우리모두 머리 한장 정도는 채워둘 수 있으면 좋겠다.


화이팅이다. 모두!



====


p.s. Hydration이란?


- SSR/SSG 환경에서 서버가 HTML을 내려주면, 브라우저는 화면은 보이지만(정적 HTML) 아직 인터랙션이 없는 상태로 시작

- 이 HTML에 클라이언트 JS를 붙여서 React/Vue의 컴포넌트 트리를 재구성 (이벤트 리스닝, 데이터 바인딩, 상태 관리 등등)


Hydration이 하는 일


 - 서버가 만든 HTML을 그대로 재사용

 - CSR처럼 처음부터 DOM을 통째로 다시 그리지 않고 동일한 컴포넌트 트리를 클라이언트에서 다시 실행

 - 클라이언트 런타임이 동일한 라우트/상태/props를 기반으로 렌더링 로직을 실행

 - DOM과 가상 DOM(또는 내부 렌더 트리)을 매칭

 - 서버 HTML 결과와 클라이언트가 계산한 렌더 결과가 같은지 확인

 - 이벤트 핸들러/상태/리스너를 DOM에 연결 (중요함) 이후 -> 클릭/입력/스크롤 같은 인터랙션이 동작하기 시작 -> 이후부터는 SPA처럼 동작

 - 라우팅, 상태 변경에 따른 리렌더 등은 클라이언트에서 처리