웹 브라우저 엔지니어링 (2021)

 (browser.engineering)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Web Browser Engineering은 네트워킹부터 JavaScript까지 다루며, Python 수천 줄로 기본적이지만 완전한 웹 브라우저를 직접 만들어 보는 책임
  • 학습 흐름은 페이지 로딩에서 문서 표시, 애플리케이션 실행, 현대 브라우저 기능으로 이어지며 HTTP, HTML, CSS, DOM, 보안, 렌더링 파이프라인을 순서대로 연결함
  • 초반부는 URL과 HTTP 요청, 창 생성과 캔버스 그리기, 텍스트 줄바꿈과 줄 간격처럼 브라우저 기초 구현에 집중함
  • 중후반부는 HTML 트리 구성, 레이아웃, 스타일 적용, 폼 제출, 이벤트 반응, 쿠키와 로그인, XSS와 CSRF까지 포함함
  • 후반부는 합성, 이벤트 루프, GPU 애니메이션, 접근성 트리, iframe, 무효화와 편집 정확성으로 이어져 현대 브라우저 구현 요소를 폭넓게 살펴볼 수 있음

직접 구현하며 배우는 브라우저 구조

  • Web Browser Engineering은 웹 브라우저가 어떻게 동작하는지 이해하기 위해 기본적이지만 완전한 브라우저를 직접 구현하는 방식으로 구성됨
  • 구현 언어는 Python이며, 전체 구현 규모는 수천 줄 수준임
  • 범위는 네트워킹에서 JavaScript까지 이어짐
  • 종이책은 Bookshop, B&N, Amazon에서 구매 가능함
  • 번역판은 한국어판 Hanbit, 일본어판 O’Reilly로 나와 있음
  • 업데이트는 blog, Mastodon, Twitter에서 확인할 수 있으며, GitHub discussion forum도 있음

목차 흐름

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 책에서 좋은 점 하나는 “하지 않은 것들”을 따로 다룬 부분임
    레이아웃은 정말 어렵고, CSS 없이 표만 다뤄도 어렵다. CSS까지 들어가면 레이아웃은 거의 불가능할 만큼 복잡해짐
    CSS 명세 전체와 관련 동작을 머릿속에 다 담고 있을 수 있는 사람이 있는지 의문임. 지금의 CSS+HTML+JavaScript는 동적인 페이지 기술 언어(PDL)에 가까워졌고, 오늘날 가장 복잡한 소프트웨어 중 하나일 가능성이 큼
    덧붙이면 동영상 디코딩은 하드웨어로 오프로딩되기 때문에 예전만큼 배터리를 많이 먹지는 않음

    • 프로덕션급 CSS 레이아웃을 구현하려면 엄청난 양의 코드가 필요하고, Servo 소스가 이를 잘 보여줌
      예를 들어 이 파일은 블록/인라인 컨텍스트만 구현하는데, Rust 보일러플레이트도 조금 있지만 대부분은 명세의 여러 부분을 다루는 실제 로직임. 이런 파일이 폴더 하나 가득 있음: https://github.com/servo/servo/blob/main/components/layout/f...
      그래도 레이아웃 엔진 구현은 가능함. CSS는 마법이 아니라, 꼼꼼히 코드로 옮길 수 있는 명세가 있음. CSS가 임의적으로 보인다고 답답해하는 사람들에게 이런 코드를 보여주면 실행 환경에도 논리가 있다는 걸 이해하는 데 도움이 됨
      물론 라이브러리 구현을 들여다보듯 자주 클릭해 볼 일은 없겠지만, 그런 면에서는 React 같은 것과도 크게 다르지 않다고 봄
    • 맞음, 레이아웃은 어렵고 특히 두 가지 이유가 큰 듯함
      첫째, CSS 2 같은 레이아웃의 가장 핵심 부분이 꽤 엉성하게 설계됐고, 이상한 기능들이 서로 이상하게 상호작용함. float와 clearance, 마진 병합 같은 것들임. 이 핵심 일부는 모든 레이아웃 모드에 보편적으로 쓰이도록 의도됐지만, 다른 모드에는 잘 맞지 않음. 예를 들어 margin과 padding은 grid 요소에서는 목적이 명확하지 않음
      둘째, JavaScript API처럼 잘 모듈화되어 있지 않음. JavaScript API는 독립적으로 구현되는 경우가 많지만, 레이아웃 모듈은 여러 방식으로 중첩될 수 있어서 서로 전부 영향을 줌. grid 같은 최신 명세는 더 엄격해지려 하지만, 실제 2D 화면이라는 공유 자원을 여러 레이아웃 모드가 나눠 써야 한다는 근본 난제가 있음
    • 레이아웃이 너무 어려워서 Common Lisp와 ncurses로 열정 프로젝트를 만들던 걸 그만두고, 내가 없애겠다고 맹세했던 존재인 React 개발자가 되어버림
      CSS보다 단순하면서도 지난 20년의 교훈을 반영해 단순성과 표현력의 곱을 최대화한 레이아웃 언어를 원하는 사람이 나뿐일 리 없음. 이런 걸 진지하게 설계하는 프로젝트가 있는지, 아니면 모두 CSS3를 받아들이고 LLVM 백엔드를 기다리거나 그냥 일반 텍스트로 돌아간 건지 궁금함
    • React Native에서는 Facebook 엔지니어들이 그냥 포기하고 “너희에게 주는 건 flexbox 레이아웃뿐”이라고 한 셈인데, 사람들은 꽤 괜찮아했음. 물론 display grid가 없다고 투덜대는 사람도 있음
      https://github.com/facebook/yoga
    • 이 바벨탑은 언젠가 무너질 것임
      레이아웃이 이렇게 복잡할 필요는 없음. 더 단순한 레이아웃 시스템을 가진 GUI 프레임워크가 수십 개 있고, 사람들이 쓰는 애플리케이션에는 그것들로 충분함

  • 멋져 보임. 약 15년 전에 헤드리스 브라우저를 만들기 시작해서 몇 년간 유지했음
    JavaScript 인터프리터로 SpiderMonkey를 쓰고, DOM은 직접 구현했음. 당시의 최신 JavaScript와 AJAX 등을 모두 실행했고, 나중에는 커스텀 Flash 런타임도 추가함. 화면에 그리는 것만 빼고 거의 다 했던 프로젝트라 정말 재미있었음
    이 책을 꼭 읽어보고 싶음

    • 화면에 그리려면 어떤 라이브러리를 쓸 생각인지 궁금함

  • 브라우저 엔지니어링이 이제 트렌드가 되는 것 같아 반가움
    생태계는 사실상 Google, Apple, Mozilla만 정의하는 꽤 빈약한 상태임. 앞으로는 더 많은 독립 브라우저 엔진이 있는 미래를 보고 싶음

    • HTML용 렌더링 엔진을 새로 쓰는 건 해볼 만한 일이 아니라고 봄. 절대 끝내지 못함. HTML은 이제 사실상 Google과 Apple이 완전히 소유한 명세이고, 처음부터 구현하기엔 너무 복잡함
      흥미로운 영역은 탈-HTML UI/문서 기술임. 다른 스레드의 Typst는 더 나은 LaTeX 같은 것이고, Markdown도 큰 영향을 줬음. “HTML이지만 더 나은 것”을 만들 여지는 많음. 꼭 마크업 형식일 필요도 없음. Typst와 React HTML은 코드와 데이터의 경계를 흐리고, Jetpack Compose는 Kotlin의 DSL 기능으로 UI 설명처럼 보이지만 실제로는 코드인 것을 만드는 방식을 보여줌
      물론 그러려면 그 형식용 ‘브라우저’를 배포하거나, 기존 브라우저에서 표시할 방법을 찾아야 함. 그래도 JavaScript/HTML/WASM으로 컴파일하는 건 가능함. JavaFX 같은 이식 가능한 GUI 툴킷을 써도 되고, 접근성도 얻을 수 있음. 둘 다 할 수도 있음
      자기 UI 언어를 정의하면 HTML이 잘 못하는 걸 많이 시도할 수 있음. 대표적으로 콘텐츠와 스타일의 분리임. HTML은 시도했지만 끝내 제대로 이루지 못했고, XSL:T는 더 열심히 시도했지만 XML 문법을 쓰는 이상한 순수 함수형 언어였음. React는 JSON을 박스로 바꾸는 데는 꽤 잘하지만, 밑바탕 프로토콜이 늘 임시방편으로 덧붙은 형태라 그 위에 유용한 도구를 만들기 어렵다
      또 다른 아이디어로는 기본적으로 XSS에 면역인 형식도 가능함
    • 메모리를 덜 쓰는 브라우저가 있으면 좋겠음. 그 외에는 Capital-G Google Chrome과 Capital-M Mozilla Firefox의 스파이웨어만 빼면, 엔진 수가 적은 것 자체는 큰 문제가 없다고 봄. 중복 없이 축적된 수백만 시간의 작업이니까
      다만 HTML의 대안은 원함. 내가 브라우저를 만든다면 HTML을 참을 수 없어서 대체하는 데 집중할 것 같고, JavaScript도 런타임이 무거워서 바꾸고 싶음
      예를 들어 JavaScript 런타임이 거의 없고 WASM만 실행하는 브라우저라면 꽤 웃길 듯함
    • 아예 새로운 플랫폼이나 프로토콜이 필요할 수도 있음. 지금 것은 복잡도가 완전히 포화 상태임
    • Servo, Ladybird, Goanna, NetSurf, Sciter, Flow 같은 대안 브라우저 엔진을 혹시 살펴본 적 있는지 궁금함

  • 이 책의 저자 중 한 명임. 좋은 말들 고맙고, 질문이 있으면 답할 수 있음

    • 훌륭한 책을 만들어줘서 고마움. 웹 개발자, 혹은 책에서 표현한 대로 웹 엔지니어로서 의존하고 있는 기술적 기반을 늘 더 배우고 싶었음
      브라우저 구현 언어로 Python을 선택하게 된 과정이 궁금함. Node를 통한 JavaScript가 더 관련성 있는 프로그래밍 경험을 제공했을 것 같기도 함

  • 저자가 왜 Python을 선택했는지 설명한 글: https://browserbook.substack.com/p/why-python
    일부는 Python을 JavaScript로 컴파일해서 이제 브라우저 안, 즉 “책 자체 안”에서도 실행되는 듯함
    https://browserbook.substack.com/p/compiling-python-to-js

    • Python으로 쓰였다는 점 때문에 실제로 이 책을 읽고 싶어짐. Rust나 Go였다면 아마 건너뛰었을 것이고, C++는 재미로 보는 프로젝트치고는 너무 보기 힘듦
      읽고 나서 돌아와 더 의미 있는 얘기를 할 수 있으면 좋겠음

  • 이런 자료가 만들어지는 걸 보니 정말 신남
    브라우저는 신비롭고 해독 불가능한 블랙박스처럼 보이는데, 아마 Google도 그렇게 인식되길 원할 가능성이 큼. 하지만 Ladybird 같은 프로젝트의 노력과 결과를 보면 그 벽이 갈라지고 있음
    언젠가 직접 뛰어들어 그 해자를 깨는 데 기여하고 싶고, 이 책은 훌륭한 출발점처럼 보임

    • 그 해자는 Chrome이 아닌 브라우저 엔진이 부족해서 생긴 게 아니라, Chrome이 아닌 엔진을 쓰는 사람이 너무 적어서 생긴 것임
      Firefox는 이미 존재함. 다만 거의 아무도 쓰지 않고, Firefox에서 안 되는 웹사이트를 만나면 사용자들은 그냥 Chrome을 여는 법을 배웠음
      해자가 깨지길 바라며 Ladybird 같은 브라우저 엔진에 기여하는 건 재미있겠지만, 그것만으로 해자를 깨는 데 기여한다고 보긴 어려움. 무엇이 실제로 도움이 될지 알고 싶음
    • 책의 저자 중 한 명인 Chris는 Google에서 Blink 렌더링 팀을 이끄는 사람임
    • 책의 두 저자 중 한 명이고, 다른 한 명은 Blink Rendering의 책임자임. Chrome 팀 사람들과도 여러 번 이야기해봤지만, 브라우저를 신비롭게 유지하려는 사람처럼 보인 적은 없었음
      오히려 Chrome, Firefox, Safari, Ladybird에서 일하는 사람들은 모두 브라우저와 그 동작 방식을 이야기하는 데 굉장히 신나 보임. 브라우저 개발 세계는 생각보다 작고, 엔지니어들도 회사 사이를 자주 오가므로 어떤 “음모”를 계속 유지하기는 어려울 것 같음
      다만 교육 자료가 실제로 부족하다는 점은 맞음. 그래서 이 책을 썼고, 특히 레이아웃과 래스터화 같은 핵심 단계의 브라우저 내부를 논의할 공통 어휘도 부족함. Chris와 나는 이 책으로 그런 기반을 만들고 싶었음

  • 시작할 재미있는 프로젝트를 찾고 있었는데, 이미 이 책을 정말 즐겁게 읽는 중임. 글이 특히 흥미롭게 쓰여 있어서 좋음
    Chrome이 어떻게 동작하는지 설명한 이 만화책도 시작하기 좋은 자료임: https://www.google.com/googlebooks/chrome/med_00.html

  • 브라우저 내부 구조를 배우는 중인데, 이 책은 훌륭함
    수백만 줄짜리 Chrome 코드를 파고들지 않아도 브라우저가 어떻게 동작하는지에 대한 직관을 쌓는 데 도움이 됨

  • HN용 프로모션 코드가 있는지 궁금함
    예전에 Jython [2]과 함께 HTMLUnit [1]을 만족스럽게 썼고, 앞으로는 코드 생성과 검증 기법으로 브라우저 코드 일부를 자동 생성할 수 있는 미래에 관심이 많음. Playwright/Cypress/Selenium 같은 도구는 존중하지만, HTMLUnit만큼 편하게 느껴진 적은 없었음
    [1] https://htmlunit.sourceforge.io/
    [2] https://www.jython.org/

    • 책은 아직 출간되지 않았으니 프로모션 코드는 없지만, 전체가 온라인에서 무료로 공개되어 있음

  • 좋은 책임. 9장을 두 장으로 나누는 걸 추천함
    Duktape로 JavaScript 실행하는 부분을 한 장으로 두고, DOM 및 이벤트와 상호작용하는 부분은 나중의 별도 장으로 두면 좋겠음

    • 두 번에 나눠 읽는 게 가장 좋을 수도 있음
      뒤로 갈수록 장이 길어지고 더 고급 주제를 다루며, 책을 읽어가면서 코드도 함께 따라가길 권함
답변달기