🙏🏻 1주일 동안 준비한 내용을 바탕으로 발표를 준비했습니다.
틀린 내용이 있다면 피드백 부탁드립니다.

🔗 좀 더 자세한 정리 자료
https://velog.io/@remon/Web-브라우저의-역사
https://velog.io/@remon/Web-브라우저-구조
https://velog.io/@remon/V8-엔진이-대체-뭐야
https://velog.io/@remon/Web-DOM-이란-feat.-BOM
https://velog.io/@remon/Web-브라우저-렌더링-과정

1. 브라우저 역사

브라우저의 역사를 알아보기전에 브라우저가 뭔지에 대해서 간략하게 얘기해보자면 브라우저란 웹상에 있는 페이지들의 HTML 언어를 해석해서 내용을 화면에 정리하여 보여주는 응용 프로그램입니다.
이 브라우저의 역사는 인터넷이 발전되면서부터 시작되었는데요
1989년 CERN(유럽 입자 물리 연구소)에서 근무하던 팀 버너스리는 직원들의 정보를 관리하는 일을 했었는데, 연구소 내에 인사 이동 많았습니다. 인사 이동을 하면서 자리이동을 하기때문에 자료도 같이 이동했었는데, 이동 과정에서 서류 분실이 잦았습니다. 이러한 문제점을 해결하기 위해 연구원들의 정보들을 네트워크 상에서 클릭만하면 그 사람 정보에 바로 접근하는 기술을 만들어서 사용했는데, 생각보다 너무 편리해서 세계적으로 사용할 수 있게 만들기 위해서 무료로 공개하게 됩니다. 이걸 계기로 인터넷이 발전할 수 있게 되었습니다.
팀 버너스리는 1990년 세계 최초의 웹 브라우저도 함께 만드는데, 이 브라우저에도 월드와이드웹(WorldWideWeb) 이라는 이름을 붙였습니다. 이게 위에서 말한 WWW와 혼동의 여지가 있었기 때문에, 나중에는 이름을 Nexus로 바꾸게 됩니다.

이후 전세계적으로 인터넷 보급 시작된 1993년 슈퍼컴퓨터 연구진 마크 앤드리슨은 인터넷에 사진을 보여주면 좋을 것 같다는 생각으로 최초로 그림과 텍스트를 함께 보여주는 브라우저 Mosaic 만들었습니다. 출시하자마자 어마어마한 성공을 거두었고,

다음해인 1994년에 제임스 H. 클라크의 사업제안을 받아들여 같이 넷스케이프라는 회사를 설립합니다. Mosaic로 사업을 시작할까 했지만 법률적으로 NCSA(슈퍼컴퓨터 연구소) 재산이기 때문에 팔지 못하게 되어서 Mosaic의 코드를 한줄도 카피하지않고 훨씬 보안된 웹브라우저 프로그램인 넷스케이프 네비게이터를 출시합니다.

출시되고 얼마 지나지 않아 시장 점유율 90%를 달성하고, 브라우저 시장을 거의 독점하고 있었는데, 이때 마이크로소프트가 인터넷 익스플로러 브라우저의 시장 진출 선언합니다. 마이크로소프트의 빌게이츠는 넷스케이프를 이기기 위해 3가지 전략을 짭니다.

첫번째 윈도우 운영체제에는 익스플로러를 기본으로 설치시키고,
두번째 인터넷 익스플로러 개발진 대폭 증가시키고,
세번째 윈도우 OS를 넣고 컴퓨터를 조립해서 파는 거래처들에게 윈도우를 주는 계약 조건으로 넷스케이프를 탑제 못하게 했습니다.

이런 방법으로 결국 인터넷익스플로럴이 시장 점유율 역전에 성공합니다.

2002년 인터넷 익스플로럴은 시장 점유율 90%를 달성했습니다.

2004년 거의 망하게 된 넷스케이프는 마지막을 아름답게 마무리하기 위해 넷스케이프 네비게이터 소스코드를 오픈소스로 공개해서 세상에 퍼트리고 개발을 중단합니다. 이때 넷스케이프의 뒤를 이어줄 비영리 재단 mozilla foundation가 만들어집니다. 비영리 재단인 만큼 개발 속도가 느렸지만 천천히 기능을 추가했고, 파이어폭스 1.0 첫 출시하게됩니다.

2008년 사람들이 인터넷을 완전 생활화할 때입니다. 이때 과도한 플러그인과 기능 추가로 각각의 브라우저들이 웹 표준에서 많이 멀어지고 브라우저끼리의 호완성도 좋지 않았습니다. 그러자 표준을 따르고, 브라우저의 무게를 줄이자는 의견이 나오기 시작했습니다.

구글은 이때가 기회라고 생각하고 더 슬림하고 심플하게 웹 서핑을 도와주는 브라우저 만들기에 착수합니다. (이 브라우저에 레이아웃 렌더링 엔진으로 사파리의 가벼운 웹키트 엔진을 가져와서 발전시켜 블링크 엔진으로 이름을 바꾸고, 자바스크립트를 빠르게 실행하기 위한 V8 엔진을 얹어서)

크로미움1.0이라는 오픈소스 브라우저를 만들어 세상에 공개하고, 크로미움을 기반으로 구글의 색깔을 담아 크롬 브라우저를 출시합니다.

2011년 본격적인 브라우저 트렌드 변화가 일어납니다. 과도한 플로그인과 부가기능으로 인해 웹 표준과 멀어진 브라우저들을 다시 웹 표준에 가깝게 돌리려는 분위기였습니다. 이러한 분위기에 맞춰 크롬과 파이어폭스는 신세대의 가볍고 강력한 매력을 어필하면서 대용량 업데이트 진행하는 반면,

인터넷익스플로럴은 이미 수많은 기능들로 인해 너무 무거웠고, 인터넷익스플로럴끼리도 호환이 안되는 상태였기 때문에 업데이트를 하지 못했습니다 이로인해 사용자가 줄고있는 와중에 업데이트까지 하지 못해서 시장점유율에 영향을 줬고,

2015년 마이크로소프트는 패배를 인정하고 인터넷 익스플로러 개발 중단 선언합니다.

2022년 현재 브라우저의 점유율은 크롬이 65% 가장 높습니다.

브라우저 역사로 본 결론은 웹 브라우저들이 끊임없이 가볍고 강력해지기 위해 노력하고있고, 예전처럼 표준에서 벗어나서 기능을 만들기 보다는 표준을 따르기 위해 노력하고 있다는 것입니다.

2. 브라우저의 구조

브라우저의 구조는 보통 7가지로 구성되어 있습니다.

마지막으로 자바스크립트 코드를 실행하는 인터프리터가 있습니다. 크롬의 경우 V8 엔진이 자바스크립트 인터프리터입니다.

3. V8엔진

V8엔진은 구글이 개발한 오픈소스로 가장 대중적인 자바스크립트 엔진입니다.
c++로 개발되었고, Node.js 런타임 및 크롬 브라우저에서 사용되고있습니다.

자바스크립트 엔진 : 0과 1밖에 이해하지 못하는 낮은 수준의 언어를 사용하는 컴퓨터가 인간이 작성한 자바스크립트 파일을 읽을 수 있도록 기계어로 번역해주는 역할을 해줍니다.

V8엔진이 어떻게 동작하는지 알아보기 전에 프로그래밍에서 사용하는 두 가지 번역 방식에 대해 먼저 알아봐야합니다.

프로그래밍 번역 방식에는 인터프리터와 컴파일러가 있는데,
인터프리터는 자바스크립트 파일을 입력받으면 코드를 한줄 한줄 해석하면서 기계어로 바로 번역해주는 방식이고,
컴파일러는 한줄 한줄 번역하는 것이 아니라, 소스 코드 전체를 한 번에 기계어로 번역해서 CPU에게 전달하여 결과값을 만들어 내는 것입니다.
각각의 번역방식에는 장단점이 있는데, 인터프리터는 실행 속도가 빠르다는 장점이 있고, 컴파일러는 작업을 단순화 시킨다는 장점이 있습니다. 컴파일 과정에서 함수를 반복하는 것이 아니라 함수의 결과물을 반복하도록 컴파일하는데, 이처럼 불필요한 동작을 제거하는 컴파일러의 방식을 최적화라고 합니다.

v8엔진이 만들어진 이유는 웹 브라우저 내부에서 자바스크립트 수행 속도 개선 때문이었습니다. 자바스크립트 엔진은 유저와의 상호작용을 위해 즉시성이 있는 인터프리터 방식을 사용하는데, 동일한 동작을하는 함수가 여러번 나오더라도 이를 컴파일 하는 과정을 거치기 때문에 코드가 많을 수록 느려진다는 단점이 있었습니다. 이것은 매우 비효율적이었습니다. 그래서 V8엔진은 이 점을 보완하고 속도 향상을 하기 위해서 인터프리터를 사용하는 대신 JIT(Just In Time) 컴파일러를 구현했습니다.

JIT 컴파일러란 프로그램을 실제 실행하는 시점에 기계어로 번역하는 컴파일 기법으로 프로파일링을 통해 최적화 할 코드를 선별한 후 해당 코드들만 컴파일합니다.

그럼 이제 v8 엔진의 작동 방식을 살펴보겠습니다.

v8 엔진은 자바스크립트 소스코드를 가져와서 파서에게 보냅니다.
파서는 낱말 분석이라는 과정을 통해 코드를 토큰으로 분해합니다.
파서에서 분해된 토큰을 바탕으로 AST, 추상 구문 트리를 생성합니다.
AST에서 나온 코드가 인터프리터 이그니션에게 전달됩니다.
이그니션에서 코드를 빠르게 바이트코드로 중간 번역하고 실행시킵니다.

바이트코드 실행 후 v8엔진은 런타임 과정 중에 프로파일러에게 지속적으로 함수나 변수들의 호출 빈도와 같은 데이터를 모으라고 시킵니다. 이 과정에서 반복되어 사용하는 코드 등의 과열 지점을 찾고, 최적화 할 수 있는 부분을 기록합니다.

컴파일러는 프로파일러에게 전달받은 내용을 토대로 과열 코드를 터보팬으로 보내서 최적화 컴파일 작업을 거칩니다. 최적화한 코드를 수행할 차례가 되면 바이트코드 대신 컴파일러가 변환한 최적화된 코드가 그 자리를 대체하여 실행되는 과정을 거칩니다.

작동 방식으로 알 수 있는 것은
번역된 코드를 캐싱해둔 다음 똑같은 코드가 있다면 번역하지않고 캐싱해둔 값을 사용하여 매번 기계어 코드가 생성되는 것을 방지해 인터프리팅 시간을 단축시켰기 때문에 V8엔진이 자바스크립트의 수행속도를 개선할 수 있었다는 것입니다.

4. DOM

이번에는 DOM에 대해서 얘기하려고합니다.

자바스크립트는 html 문서를 조작하기 위해 만들어진 언어입니다. 어떻게 조작하는지 알기 위해서 DOM이라는 개념을 알아야합니다.

자바스크립트의 입장에서 HTML을 본다면 문자열 그 이상도 이하도 아닙니다. HTML을 컨트롤 하기 위해서는 자바스크립트가 알아들을 수 있는 형태로 바꿔야했습니다. 브라우저 구조에 있던 렌더링 엔진은 웹 문서를 해석할 수 있는데, 브라우저로 html파일을 열게 되면 렌더링 엔진이 html 로 작성한 문서를 한줄 한줄 해석합니다. 해석이 끝나면 문서를 객체화하여 자바스크립트가 접근 할 수 있도록 합니다. 이걸 문서를 객체화 했다고 해서 도큐먼트 오브젝트 모델, 즉 DOM이라고 합니다. 정리하자면 DOM은 문자일 뿐인 HTML을 의미있는 객체로 바꿔서 자바스크립트가 추가적인 작업을 할 수 있게 기능을 제공하는 것입니다.

그렇다면 dom은 어떻게 만들어질까요?

html 코드를 어떤 제품의 설계도라고 생각하고, 브라우저를 공장이라고 생각해봅시다.
공장에서 이 설계도를 해석하는 과정을 거치는데 이를 파싱이라고 합니다.
html 이란 설계도를 브라우저라는 공장으로 보내면 dom이라는 기계가 만들어진다고 비유할 수 있습니다.

html 문서를 브라우저에서 파싱하면 오른쪽과 같은 구조의 DOM이 만들어집니다.
HTML 요소들을 1개의 부모 태그와 n개의 자식 태그를 가질 수 있습니다. 이런 구조를 표현하면 나무 모양의 트리 구조를 갖게됩니다. 이것을 DOM Tree라고 하고 요소들 하나하나를 Node라고 부릅니다. 자바스크립트는 각각의 Node에 접근해서 제어할 수 있습니다.
결국 DOM의 목적은 자바스크립트를 사용해서 웹 콘텐츠를 추가, 수정, 삭제, 이벤트 처리를 정의할 수 있도록 제공되는 프로그래밍 인터페이스입니다.

DOM의 개념을 설명할 때 렌더링 엔진이 html을 한줄한줄 해석한다고 했습니다.
브라우저의 렌더링 엔진이 하는 일을 좀 더 자세히 살펴보면 브라우저 렌더링에 대해 알 수 있습니다.

5. 브라우저 렌더링

렌더링 엔진은 HTML과 CSS를 파싱하여 요청한 웹 페이지를 표시하는 역할입니다.
렌더링 엔진의 목표는 웹 페이지에 포함된 모든 요소들을 화면에 보여주는것과 업데이트가 필요할 때 효율적으로 렌더링 할 수 있도록 자료 구조를 생성하는것이 목표입니다.
여기서 업데이트는 사용자 동작으로 인한 입력 발생이나 스크롤, 애니메이션 동작, 비동기 요청으로 인한 데이터 로딩 등이 있습니다.
이런 목표를 위해서 렌더링 엔진은 크게 다음의 과정을 거쳐서 동작하는데요. 이를 크리티컬 렌더링 패스라고 합니다. 간단하게 돔트리 생성, cssom 트리 생성, 렌더트리 생성, 렌더트리 배치, 렌더트리 그리기 순서로 동작합니다.

좀 더 자세히 살펴보겠습니다.

먼저 브라우저에서 사용자가 요청한 웹페이지의 문서를 불러오고 파싱합니다. html코드는 어휘 분석을 통해서 html5 표준에 지정된 고유한 토큰으로 변환됩니다. 그리고 브라우저의 렉싱 과정을 통해서 토큰의 해당 속성과 규칙을 정의하는 노드 객체로 변환합니다. 그리고 각 노드가 서로 연관성을 가질 수 있도록 트리를 생성하는데 이게 바로 DOM 트리입니다. html의 모든 것들은 DOM을 구성하게 됩니다.

HTML을 DOM Tree로 만드는 과정과 비슷하게 CSS로는 CSSOM이라는 Tree가 만들어져요. CSSOM은 DOM이 어떻게 화면에 표시될지를 알려주는 역할을 합니다. CSS도 위에서 아래로 스타일 규칙이 정해지기 때문에 이 또한 트리 구조를 가지고있는데, 예를들어 스타일시트에서 body tag에 text-align:center; 속성을 정의했다면 body의 자식 요소들에게도 동일한 속성이 전파돼서 적용되게 됩니다. 습니다.

그리고 렌더링 엔진이 DOM트리와 CSSOM트리를 결합해 Render Tree를 만들게되는데요. Render Tree는 화면에 표시되어야 할 노드의 컨텐츠, 스타일 정보를 포함하고 있는 트리입니다.

Render Tree가 만들어지는 과정을 간략하게 설명해드리자면 도큐먼트 객체부터 각 노드를 순회하면서 각각에 맞는 CSSOM을 찾아서 규칙을 적용합니다. 그러면서 렌더와 관련된 요소들을 Render Tree에 포함을 시키게되는데요. 이때 메타 테그나 디스플레이 논 속성을 가진 요소들은 렌더와 관계가 없기 때문에 Render Tree에 포함되지 않습니다.

Render Tree가 생성되었다면 레이아웃 과정을 커칩니다. 뷰폴트 내에서 요소들의 정확한 위치나 크기를 계산하는 과정입니다. 박스모델에 따라서 텍스트나 요소의 박스가 화면에서 차지하는 영역이나 여백, 스타일 속성이 계산이 됩니다.
레이아웃 과정에서 렌더링 엔진이 각 요소들이 어떻게 생겼고, 어떻게 보여줄지 알게되면 마지막으로 화면에 실제 픽셀로 그려지도록 변환하는 과정을 거치는데 이것이 페인트 과정입니다.
이 과정에서 Render Tree에 포함된 요소들이나 텍스트, 이미지들이 실제 픽셀로 그려집니다. 이렇게 이 결과들은 레이어화 되어 관리되고 이후 합성 과정을 거쳐 사용자에게 보여집니다.
HTML과 CSS를 가지고 렌더링 엔진이 어떻게 동작하는지를 살펴보았는데요. 크리티컬 렌더링 패스의 시간을 줄이면 브라우저가 웹페이지를 보여주는데 걸리는 시간도 줄일 수 있습니다.

피드백 & 질문

느낀점

면접 질문 답변처럼 달달외우는게 아니라 직접 설명을 하기 위해서 이것 저것 자료를 찾고 이해하는 과정을 거치니 훨씬 깊게 알게되었습니다. 일주일이라는 시간이 짧게 느껴질만큼 많은 양이었어요. 브라우저 역사에 대해서 알아볼때는 옛날 이야기를 듣는것처럼 흥미로웠습니다!
줌으로 하는 간단한 발표 외에 이런 본격적인 발표는 처음이어서 엄~청 떨었어요... 발표하기 전에 청심환을 먹었는데도 긴장감이 가시지 않아서 연습때보다 1.5배속으로 빠르게 말해서 후다닥 발표가 끝났습니다😂

피드백 & 질문

• DOM과 CSSOM은 왜 트리구조일까?
  - 시간 복잡도와 관련지어서 학습해보면 좋을 것이다.
• HTML과 CSS 렌더링의 내용은 있지만 JavaScript 렌더링에 대한 내용이 없어서 아쉽다.
  - JavaScript의 렌더링의 내용을 안다면 JS로 CSS를 다루는 것이 위험한 이유를 알 수 있을 것이다.
• 네트워크에 관련해서도 정리하면 좋을 것이다.
• 추가로 알아두면 좋을 자료 추천
  - 브라우저의 사용자 에이전트는 왜 이렇게 복잡하게 생겼을까? - 재그지그의 개발 블로그

---

TMI 🗣

오늘은 2번째 과제인 React 상태 관리에 대한 세미나를 마치고 왔습니다.
비교적 무난하게 끝낸 1차 세미나와는 다르게... 아주 탈탈 털렸어요!!
인프콘에서 김영한님의 강의 중에 피드백 사이클이라는 얘기가 나오는데, 빠르게 성공과 실패를 확인할 수 있기 때문에 피드백은 빠를수록 좋다는 말이 딱 맞더라구요. 무난하게 끝났던 브라우저 렌더링 보다 React 상태 관리에 대한 발표를 통해서 받은 피드백들이 앞으로 공부하는데 방향성을 잡아준 계기가 되었습니다🔥
내일은 React 상태 관리 세미나에 대해 정리할 예정입니다!