How Browsers Work

2026-01-05

https://howbrowserswork.com/

How Browsers Work

브라우저는 어떻게 동작하는가

브라우저가 어떻게 동작하는지를 설명하는 인터랙티브 가이드

→ 이 글은 단순 설명이 아니라, 직접 조작하며 이해하도록 만든 튜토리얼이다.

 

브라우저는 URL을 기준으로 동작한다

주소창에는 사실 아무 글자나 입력할 수 있다.

하지만 내부적으로 브라우저는 URL을 기준으로 동작한다.

● pizza 같은 임의의 텍스트는 https://google.com/search?q=pizza

   (또는 설정에 따라 DuckDuckGo) 같은 검색 URL로 변환된다.

● example.com 같은 도메인은 https://example.com 같은 완전한 URL로 정규화된다.

→ 주소창은 "검색창 + URL 입력창"을 겸하고 있다.

실제로 어떻게 변환되는지 보려면 주소창에 입력하고 Enter(또는 Go 버튼)를 눌러 보라.

 

URL을 HTTP 요청으로 변환하기

방문할 정확한 URL이 결정되면 브라우저는 서버로 요청을 보내 리소스를 가져와 화면에 표시한다.

브라우저와 서버는 HTTP 프로토콜로 통신한다.

→ 프론트엔드에서 fetch를 쓰는 순간, 이 단계가 발생한다.

전체 URL을 입력하면 URL이 HTTP 요청 형식으로 변환되는 과정을 볼 수 있다.

HTTP 요청에는 다음과 같은 헤더가 포함된다.

Host: example.com
Accept: text/html

이 중 Host 헤더는 요청이 어떤 서버로 가야 하는지를 식별한다.

→ 하나의 IP에서 여러 도메인을 운영할 수 있는 이유가 이 헤더 때문이다.

 

서버 주소 해석 (DNS)

브라우저는 example.com 같은 이름으로는 통신할 수 없다.

컴퓨터는 IP 주소로 통신하기 때문에, 브라우저는 DNS 시스템에 도메인 이름을 IP 주소로 바꿔 달라고 요청한다.

→ 이 단계가 느리면 "첫 접속이 느린 사이트"가 된다.

도메인을 입력하면 DNS를 통해 IP 주소로 변환되는 과정을 확인할 수 있다.

 

TCP 연결 설정

DNS로 IP를 얻어도 브라우저는 여전히 신뢰 가능한 연결이 필요하다.

이 연결을 설정하는 것이 TCP 프로토콜이다.

TCP는 3-way handshake를 통해 양쪽이 데이터를 주고받을 준비가 되었는지 확인한다.

1. SYN

    클라이언트가 연결 요청 (seq=1000)

2. SYN-ACK

    서버가 응답 + 자신의 번호 전달 (seq=5000, ack=1001)

3. ACK

    클라이언트가 확인 응답 (ack=5001)

→ 이 숫자들은 "어디까지 받았는지"를 관리하기 위한 번호다.

이 번호 덕분에

● 데이터가 빠지면 재전송이 가능하다.

● 순서가 보장된다.

● 신뢰성이 유지된다.

→ TCP가 "느리지만 안전한" 이유.

 

HTTP 요청과 응답

TCP 연결이 완료되면 브라우저는 HTTP 요청을 서버로 보낼 수 있다.

요청이 서버로 가고, 응답이 다시 브라우저로 돌아오는 과정을 확인할 수 있다.

HTTP 응답이 도착하면 브라우저는 원시 응답 데이터를 읽고 HTML 렌더링을 시작한다.

→ 여기서부터 "화면 그리기"가 시작된다.

 

HTML 파싱과 DOM 트리 생성

HTTP 응답이 도착하면 브라우저는 헤더와 바디를 분리하고 HTML 바이트를 파서(parser)에 전달한다.

파서는 <h1> 같은 태그를 토큰으로 바꾸고 DOM 트리를 생성한다.

파싱의 특징

● 전체 문서를 다 받기 전부터 시작된다 (스트리밍)

● 오류에 관대하다 (태그가 빠져도 보정)

● <script>를 만나면 파싱이 멈출 수 있다

→ 그래서 스크립트 위치가 성능에 영향을 준다.

DOM 트리는 CSS와 결합되어 렌더 트리를 만들고 레이아웃·페인트 단계로 넘어간다.

 

DOM이 중요한 이유

DOM은 문서의 브라우저 내부 메모리 표현이다.

HTML 파서, CSS 선택자 엔진, JavaScript 런타임이 모두 공유하는 공통 계약이다.

→ DOM을 바꾸면 즉시 스타일·레이아웃·상호작용이 바뀐다.

DOM은 다음을 모두 담당한다.

● querySelector

● 스타일 변경

● 이벤트 처리

스크립트를 수정하면 DOM과 화면이 즉시 바뀌는 것을 볼 수 있다.

 

레이아웃 · 페인트 · 컴포지트

DOM과 CSS가 준비되면 브라우저는 렌더링 파이프라인을 실행한다.

1. Layout (Reflow)

    크기와 위치 계산

2. Paint

    픽셀 색상 채우기

3. Composite

    GPU에서 레이어 합성

모든 변경이 모든 단계를 다시 실행하지는 않는다.

● 색상 변경 → Paint

● 크기 변경 → Layout + Paint

→ 레이아웃 변경이 많은 페이지가 느린 이유다.

 

 

 

반복과 정리

이 글을 읽으면서 자연스럽게 동아리 활동과 수업 시간이 떠올랐다. 사실 내용 자체는 낯설지 않았다. 수업 시간에 이미 다뤘던 개념들이고, 나아가 내가 이해한 내용을 바탕으로 동아리에서 신입 기수들을 위해 비슷한 교육 자료를 직접 만들고 설명했었다.

그래서 처음에는 이미 알고 있는 내용이라고 느꼈다. 하지만 다시 차분히 읽어 내려가다 보니, 이미 안다고 생각했던 지식이라도 여러 번 마주하는 것이 얼마나 중요한지를 다시 한 번 깨닫게 되었다. 어떤 개념은 흐릿해져 있었고, 어떤 부분은 다시 읽으며 머릿속으로 더 또렷하게 정리되었다.

이런 과정이 반복될수록 지식은 단순히 아는 것에서 끝나지 않고, 점점 내 언어로 설명할 수 있는 이해로 바뀌는 것 같다. 그래서 나는 이 블로그에 글을 쓴다. 이미 알고 있다고 생각했던 지식이라도 한 번 더 되짚고, 내 말로 정리하는 과정이 나에게 분명히 도움이 된다고 느끼기 때문이다. 다른 글들도 마찬가지이다.

 

 

 

---

 

 

 

나는 브라우저의 전체 흐름을 말로 끊김 없이 설명할 수 있는가?

URL 입력 → DNS → TCP → HTTP → 파싱 → DOM → 렌더링

이 흐름을 정말 내 말로 설명할 수 있는지 생각해 보았다.

지금은 주소창에 입력한 값이 URL로 정리되고, 도메인이 DNS를 통해 IP 주소로 변환된 뒤 TCP 연결이 맺어지고, 그 위에서 HTTP 요청과 응답이 오가며, 받은 HTML이 파싱되어 DOM을 만들고, 레이아웃과 페인트 과정을 거쳐 화면에 그려진다는 전체 흐름을 한 번에 이어서 설명할 수 있는 상태가 된 것 같다.

 

나는 지금까지 결과만 보고 원인을 추측하지는 않았는가?

화면이 늦게 뜰 때, 나는 그 원인을 어느 단계부터 의심해 왔는지 돌아보게 되었다. 서버 문제인지, 네트워크 문제인지, 아니면 브라우저 렌더링 파이프라인의 문제인지. 솔직히 말하면, 그동안은 대부분 막연히 네트워크 문제라고 생각했던 경우가 많았던 것 같다. 하지만 브라우저의 전체 흐름을 다시 정리하고 나니, 이제는 단순히 결과만 보는 것이 아니라 "어느 단계에서 문제가 생겼을까?"를 단계별로 떠올려 볼 수 있을 것 같다. 개발자로서 문제를 바라보는 시선을 바꿔준 것 같다고 느꼈다.