URL 입력 후 화면까지
브라우저에 URL을 입력하면 화면이 나타나기까지의 전체 과정 (면접 단골 질문!)
전체 흐름
1. URL 파싱
↓
2. DNS 조회 → IP 주소 획득
↓
3. TCP 연결 (3-way handshake)
↓
4. TLS 핸드셰이크 (HTTPS)
↓
5. HTTP 요청 전송
↓
6. 서버 처리 + HTTP 응답
↓
7. HTML 파싱 → DOM 트리
↓
8. CSS 파싱 → CSSOM 트리
↓
9. 렌더 트리 생성
↓
10. 레이아웃 → 페인트 → 화면 표시
상세 과정
1~2. URL 파싱 & DNS 조회
https://www.google.com/search?q=hello
└┬──┘ └──────┬───────┘└──┬──┘└──┬──┘
프로토콜 호스트 경로 쿼리
DNS 조회 순서:
브라우저 캐시 → OS 캐시
→ Local DNS → Root → TLD → Auth
→ IP: 142.250.196.110
3~4. TCP + TLS 연결
Client Server
|--- SYN ----→| TCP
|←- SYN+ACK --|
|--- ACK ----→|
|--- ClientHello →| TLS
|←- ServerHello --|
|--- KeyExchange →|
| 암호화 시작 |
5~6. HTTP 요청/응답
→ GET /search?q=hello HTTP/1.1
Host: www.google.com
Accept: text/html
← HTTP/1.1 200 OK
Content-Type: text/html
<html>...</html>
7~10. 브라우저 렌더링
HTML → DOM Tree
↘
Render Tree → Layout → Paint
↗
CSS → CSSOM Tree
JS → DOM/CSSOM 수정 가능
| 단계 | 설명 |
|---|
| DOM 생성 | HTML 파싱 → 노드 트리 |
| CSSOM 생성 | CSS 파싱 → 스타일 트리 |
| 렌더 트리 | DOM + CSSOM 결합 |
| 레이아웃 | 요소 위치/크기 계산 |
| 페인트 | 픽셀로 화면에 그림 |
성능 최적화 포인트
| 단계 | 최적화 |
|---|
| DNS | DNS 프리페치, 캐싱 |
| TCP | Keep-Alive, HTTP/2 |
| TLS | TLS 1.3, 세션 재사용 |
| 다운로드 | CDN, 압축(gzip) |
| 렌더링 | CSS를 head에, JS를 body 끝에 |
| 리소스 | lazy loading, 코드 스플리팅 |
Q.브라우저에 URL을 입력하면 어떤 과정이 일어나나요?
| 단계 | 하는 일 |
|---|
| 1 | URL 을 해석한다. 프로토콜, 호스트, 경로 |
| 2 | DNS 로 호스트의 IP 를 찾는다 |
| 3 | TCP 연결을 맺는다. HTTPS 면 TLS 협상까지 |
| 4 | HTTP 요청을 보낸다 |
| 5 | 서버가 처리해 응답한다 |
| 6 | 브라우저가 HTML 을 파싱해 DOM 을 만든다 |
| 7 | CSS 로 CSSOM 을 만들고 둘을 합쳐 렌더 트리를 만든다 |
| 8 | 배치를 계산하고(레이아웃) 화면에 그린다(페인트) |
| 9 | 이미지, 스크립트 등 하위 자원을 받아 반영한다 |
중간에 캐시가 여러 번 끼어듭니다. DNS 캐시, HTTP 캐시, 브라우저 자원 캐시가 각각 단계를 건너뛰게 합니다.
흔한 실수: 6번 이후를 빼고 답하는 것. 이 질문은 네트워크만이 아니라 렌더링까지 아는지 보려는 것이고, 성능 최적화 이야기가 그 위에서 나옵니다.
Q.렌더링 과정에서 DOM과 CSSOM의 역할은?
| 구조 | 무엇으로 만드나 | 담는 것 |
|---|
| DOM | HTML | 문서의 구조와 내용 |
| CSSOM | CSS | 각 요소에 적용될 스타일 |
| 렌더 트리 | DOM 과 CSSOM 을 합쳐 | 화면에 그려질 것만 |
렌더 트리에는 display: none 인 요소가 빠집니다. 반면 visibility: hidden 은 자리를 차지하므로 포함됩니다.
두 구조가 모두 있어야 그릴 수 있으므로 CSS 는 렌더링을 막습니다. 그래서 CSS 는 문서 앞쪽에 두고, 당장 필요 없는 스타일은 나중에 불러옵니다.
스크립트는 반대 성격입니다. 파싱 중에 만나면 DOM 생성이 멈추므로 defer 나 async 로 이 멈춤을 피합니다.
흔한 실수: 렌더 트리를 DOM 과 같은 것으로 설명하는 것. DOM 은 문서 구조이고 렌더 트리는 그릴 대상만 남긴 별도 구조입니다.
Q.리플로우(reflow)와 리페인트(repaint)의 차이는?
크기와 위치를 다시 계산하는지, 색만 다시 칠하는지가 다릅니다.
| 항목 | 리플로우 | 리페인트 |
|---|
| 다시 하는 일 | 배치 계산 | 픽셀 칠하기 |
| 비용 | 크다. 주변 요소까지 영향 | 상대적으로 작다 |
| 유발하는 변경 | width, height, margin, font-size, 요소 추가와 삭제 | color, background, visibility |
리플로우가 나면 리페인트도 따라옵니다. 반대는 아닙니다.
줄이는 방법입니다.
스타일을 여러 번 바꾸지 말고 클래스 하나로 한 번에 바꾼다
DOM 을 반복해 조작할 때는 문서 조각에 모아 한 번에 붙인다
애니메이션은 transform 과 opacity 를 쓴다. 배치와 칠하기를 건너뛴다
읽기와 쓰기를 번갈아 하지 않는다. 강제 동기 배치가 발생한다
흔한 실수: 마지막 항목을 모르는 것. offsetHeight 같은 값을 읽으면 브라우저가 밀린 변경을 즉시 반영해야 해서, 반복문 안에서 읽고 쓰면 매번 리플로우가 납니다.
Q.각 단계별 성능 최적화 방법을 설명해주세요.
| 단계 | 최적화 |
|---|
| DNS | 미리 조회, 연결 사전 수립 |
| 연결 | 연결 재사용, HTTP/2 로 연결 수 줄이기, TLS 세션 재사용 |
| 요청과 응답 | 압축, 캐시 헤더, CDN 으로 거리 단축 |
| 서버 처리 | 느린 쿼리 개선, 캐시, 응답 크기 축소 |
| 파싱과 렌더 | CSS 는 앞에, 스크립트는 defer, 중요한 스타일만 먼저 |
| 이미지 | 적절한 포맷과 크기, 지연 로딩 |
무엇부터 할지는 측정으로 정합니다. 편도 지연이 큰 사용자에게는 왕복 수를 줄이는 것이 가장 크고, 서버가 느리면 그쪽이 전부입니다.
| 환경 | 연결 수립 | 서버 처리 | 먼저 고칠 것 |
|---|
| 편도 40ms | 240ms | 12ms | 왕복을 줄인다 |
| 편도 5ms | 30ms | 200ms | 서버를 고친다 |
흔한 실수: 이미지 압축부터 시작하는 것. 눈에 띄는 작업이지만 병목이 아닌 경우가 많습니다. 구간별 시간을 먼저 재는 것이 순서입니다.
먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.
읽었으면 문제로 확인해보세요
네트워크 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.