▲

브라우저는 어떻게 동작할까

 (howbrowserswork.com)
49P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 웹 엔지니어와 일반 사용자가 브라우저의 내부 동작 원리를 직관적으로 이해할 수 있도록 만든 인터랙티브 학습 가이드
  • 주소창 입력부터 HTTP 요청 생성, DNS 해석, TCP 연결, HTML 파싱, DOM 구성, 렌더링 파이프라인까지 과정을 단계별로 시각화
  • 각 단계는 직접 입력하거나 조작할 수 있는 예제로 구성되어, 네트워크 통신과 렌더링 과정을 실험적으로 체험 가능
  • DOM의 역할과 Layout–Paint–Composite 단계의 차이를 명확히 보여주며, 성능에 영향을 주는 요소를 시각적으로 확인 가능
  • 브라우저 구조를 학습하거나 웹 성능 최적화를 이해하려는 개발자에게 핵심 개념을 체계적으로 익힐 수 있는 자료

개요

  • 이 가이드는 매일 웹을 사용하는 사람 중 브라우저의 작동 방식을 명확히 이해하지 못한 이들을 위해 제작
    • 기존 자료들이 지나치게 기술적이거나 피상적이라는 한계를 보완
    • 작은 인터랙티브 예제를 통해 기술적 세부사항을 직관적으로 학습할 수 있도록 설계
  • HTTP 버전, SSL/TLS, DNS 세부 동작 등은 생략되어 있으며, 핵심 개념 중심으로 간결하게 구성
  • 프로젝트는 오픈소스로 공개되어 있으며, GitHub를 통해 개선 제안 가능

브라우저와 URL

  • 사용자가 주소창에 입력하는 모든 문자열은 내부적으로 URL 형태로 변환
  • 입력 후 Enter를 누르면 변환 과정을 직접 확인할 수 있는 실습 인터페이스 제공

URL을 HTTP 요청으로 변환

  • 브라우저는 방문할 정확한 URL을 확인한 뒤, 서버에 HTTP 요청을 전송
  • 요청 헤더 예시는 다음과 같음 
    Host: example.com
Accept: text/html
  • Host 헤더는 요청이 전송될 서버 식별자 역할 수행

서버 주소 해석 (DNS)

  • 브라우저는 example.com 같은 도메인 이름을 직접 사용할 수 없음
    • DNS 시스템을 통해 IP 주소로 변환해야 서버와 통신 가능
  • 입력창에 도메인을 입력하면 DNS 해석 결과(IP 주소) 를 확인할 수 있음

TCP 연결 설정

  • DNS로 IP를 얻은 후, 브라우저는 TCP 프로토콜을 이용해 서버와 신뢰성 있는 연결을 수립
  • 3단계 핸드셰이크 과정으로 연결이 확립됨
    1. SYN: 클라이언트가 연결 요청
    2. SYN-ACK: 서버가 응답 및 확인
    3. ACK: 클라이언트가 최종 확인
  • TCP는 데이터 순서 보장과 재전송 기능을 통해 안정적 통신을 유지
  • 네트워크를 끊거나 패킷을 조작하며 전송 안정성 실험 가능

HTTP 요청과 응답

  • TCP 연결 후 브라우저는 HTTP 요청을 전송, 서버는 HTTP 응답을 반환
  • 요청과 응답의 이동 과정을 시각적으로 표시, 패킷 흐름을 관찰 가능
  • 응답이 도착하면 브라우저는 헤더와 본문을 분리하고 HTML을 렌더링 시작

HTML 파싱과 DOM 트리 생성

  • 브라우저는 HTML 바이트를 파서(parser) 에 전달해 DOM 트리를 구성
  • 예시 HTML을 입력하면 <h1>, <p> 등의 태그가 DOM 노드로 변환되는 과정을 시각적으로 확인 가능
  • 파싱은 스트리밍 방식으로 진행되며, 문서 전체가 도착하기 전에도 노드 생성 가능
  • <script> 태그가 등장하면 파싱이 일시 중단되어 스크립트 실행
  • 완성된 DOM은 CSS와 결합해 렌더 트리(render tree) 를 형성

DOM의 중요성

  • DOM(Document Object Model) 은 브라우저 메모리 내의 문서 모델로,
    HTML 파서, CSS 선택자 엔진, JavaScript 런타임이 공유하는 핵심 구조
  • DOM 변경은 즉시 레이아웃, 스타일, 사용자 인터랙션에 반영
  • JavaScript 코드를 수정하면 DOM 변화가 실시간으로 반영되는 미리보기 기능 제공

Layout, Paint, Composite

  • DOM과 CSS가 준비되면 브라우저는 렌더링 파이프라인을 실행
    • Layout(Reflow) : 요소의 크기와 위치 계산
    • Paint: 픽셀 채우기
    • Composite: GPU에서 레이어 결합
  • 색상 변경은 Paint만 다시 실행되지만, 크기 변경은 Layout과 Paint 모두 재실행
  • 각 단계의 재실행 여부를 클릭으로 확인 가능
  • Layout 연산이 많은 페이지는 느리게 렌더링됨을 시각적으로 보여줌

요약

  • 주소 입력부터 렌더링까지의 전체 과정을 직접 체험하며 학습할 수 있는 가이드
  • 모든 단계를 완료하면 브라우저의 작동 원리에 대한 명확한 정신적 모델을 형성 가능
  • 프로젝트는 오픈소스로, GitHub에서 이슈나 Pull Request를 통해 개선 제안 가능
▲
GN⁺ 3일전  [-]
Hacker News 의견들

  • 모든 브라우저가 처음부터 DOM을 가진 것은 아님
    초기에는 WorldWideWeb(Nexus, 1990), Erwise(1992), ViolaWWW(1992), Lynx(1992), NCSA Mosaic(1993), Netscape 1.0(1994), IE 1.0(1995) 등이 있었음
    Lynx는 지금도 의도적으로 비-DOM 브라우저로 남아 있음
    AOL 1.0–2.0은 프로그래밍 가능한 객체가 없는 정적 엔진(AOLPress)을 사용했음
    DOM과 상호작용할 수 있게 된 것은 Netscape 2.0(1995), IE 3.0(1996), AOL 3.0(1996), Opera 3.0(1997)부터였음
    이후 Netscape 4.0(document.layers)과 IE 4.0(document.all)이 각자 다른 모델을 사용했음
    첫 표준 DOM은 W3C DOM Level 1(1998)로, IE 5.0(1999)이 부분 지원, Konqueror 2.0(2000)과 Netscape 6.0(2000)이 완전 지원을 시작했음
    Safari 1.0(2003), Firefox 1.0(2004), Chrome 1.0(2008)은 처음부터 표준 DOM을 지원했으며, 현재는 WHATWG DOM Living Standard를 따름

    • Dillo 브라우저도 여전히 DOM이 없는 구조임
      HTML 텍스트를 직접 해석해 렌더링하기 때문에 RAM 사용량이 매우 적음
    • “modern browsers에서의 DOM”이라고 표현하는 게 더 정확한지 묻고 싶음

  • 멋진 프로젝트임
    HN 독자라면 High-Performance Browser Networking과 Every Layout을 함께 보면 좋음
    둘 다 웹 성능과 CSS 구조를 깊이 있게 다루는 훌륭한 자료임

    • HPBN은 정말 잘 쓰인 책임
      4장에서 TLS 프레임 구조를 이해하게 되어, 이전 직장에서 지연 문제를 디버깅할 수 있었음
      TLS 프레임 크기를 조정하는 트레이드오프 부분도 흥미로웠음
      실제로 쓸 일은 많지 않겠지만, 네트워크 레벨의 세부 조정이 가능하다는 걸 알게 됨
    • HPBN 링크 고마움, 정말 흥미로운 자료임

  • 설치 없이 browser.engineering을 체험하는 듯한 흥미로운 접근임
    브라우저와 서버 예시를 보여줄 때 시각적 아이콘(예: 데스크톱/서버)을 추가하면 더 이해하기 쉬울 것 같음

    • 더 많은 섹션과 세부 내용을 추가할 계획임
      우선 피드백을 모으는 중이며, 아이콘 제안은 좋은 아이디어라 검토해볼 예정임

  • 매우 마음에 들어서 북마크해둠
    다만 HTML/DOM을 기반으로 이미지, 스타일시트, 스크립트 같은 리소스 로딩 과정이 빠져 있는 점이 아쉬움
    이 부분이 페이지 스타일이 깨지거나 이미지가 누락되는 이유를 이해하는 데 중요함

    • 단순함을 유지하려고 일부러 생략했음
      복잡하지 않게 이 블록들을 추가할 방법을 고민 중임

  • 브라우저 창이 좁을 때(1170px 미만) 목차 섹션이 본문 위로 겹쳐 보이는 문제가 있음

    • 수정 중임

  • URL 파싱 로직을 조금 더 다듬으면 좋겠음
    대부분의 사용자는 문제를 겪지 않겠지만, https://나 http:// 외의 프로토콜 스킴을 입력했을 때도 브라우저가 특별히 처리함
    이런 케이스를 잡아주는 게 좋을 듯함
    참고: List of URI schemes

  • 훌륭한 프로젝트임
    다음 단계로 reflow 과정의 세부 내용을 추가할 계획이 있는지 궁금함

  • 페이지의 절반 이상이 네트워크 요청에 할애되어 아쉬움
    실제로 브라우저의 복잡한 부분은 파싱과 렌더링 파이프라인에 있음

    • 렌더링 엔진 부분을 더 자세히 다룰 예정임
      어느 섹션에서 깊게 들어가야 할지 몰라 일단 공개 후 피드백을 받는 중임
    • DOM도 렌더링 파이프라인의 일부로 볼 수 있음

  • 엉뚱한 질문일 수도 있지만, DNS 조회를 완전히 없애고 사람이 읽을 수 있는 도메인 이름으로만 작동하게 하면 어떨까 궁금함

    • 더 엉뚱한 생각인데, IP 주소 대신 이더넷 주소로 라우팅하면 어떨까 함
      인터넷 전체를 하나의 거대한 스위치처럼 만드는 개념임
      Tailscale 창업자가 비슷한 아이디어를 쓴 글을 본 적 있음

  • 멋진 작업임

답변달기