"www.google.com을 주소창에 입력하고 엔터를 눌렀을 때 무슨 일이 일어날까요?"
프론트엔드 면접에서 정말 자주 나오는 질문 중 하나다. 단순해 보이지만 웹의 전체적인 동작 원리를 이해하고 있는지 확인할 수 있는 좋은 질문이기도 하다.
이번 글에서는 주소창에 URL을 입력했을 때부터 웹페이지가 화면에 표시되기까지의 전체 과정을 차근차근 알아보자!
🌏 웹의 흐름 미리보기
주소창에서 웹페이지가 렌더링되기까지는 크게 다음과 같은 단계를 거친다.
- URL 파싱 - 입력한 주소 해석하기
- DNS 조회 - 도메인을 IP 주소로 변환하기
- TCP 연결 - 서버와 통신 채널 열기
- HTTP 요청 - 웹페이지 요청 보내기
- 서버 응답 - HTML, CSS, JS 파일 받기
- 브라우저 렌더링 - 화면에 웹페이지 그리기
이 과정은 마치 편지를 보내는 것과 유사하다.
받는 사람의 주소를 확인하고, 우체국을 거쳐 편지를 전달하고, 답장을 받는 과정과 같다고 생각하면 이해하기 쉽다.
1️⃣ URL 파싱: 주소 해석하기
사용자가 https://www.google.com/search?q=frontend를 입력했다고 가정하자.
브라우저는 이 URL을 다음과 같이 분해한다.
- 프로토콜 :
https://(보안 HTTP 통신) - 도메인 :
www.google.com(서버 주소) - 경로 :
/search(요청할 페이지) - 쿼리 파라미터 :
?q=frontend(검색어)
만약 프로토콜이 생략되었다면 브라우저가 자동으로 https://를 붙여준다. 요즘은 보안을 위해 HTTPS가 기본이 되었기 때문!
2️⃣ DNS 조회: 도메인을 IP 주소로 변환하기
우리는 www.google.com이라는 친숙한 이름을 사용하지만, 실제 컴퓨터들은 172.217.175.4와 같은 IP 주소로 통신한다. 아무래도 당연하다. 알파벳은 인간끼리 대화하기 위해 만들어졌으니 컴퓨터는 인간의 언어를 자신들만의 언어로 번역하는 과정이 필요할 것이다 !
DNS(Domain Name System) 조회 과정은 다음과 같다.
📋 DNS 조회 순서
- 브라우저 캐시 확인 - 최근에 방문한 사이트라면 기억하고 있을 수 있음
- 운영체제 캐시 확인 - OS 레벨에서 저장된 DNS 정보 확인
- 라우터 캐시 확인 - 공유기에서 캐시된 정보 확인
- ISP DNS 서버 조회 - 인터넷 제공 업체(KT, SK, LG 등)의 DNS 서버에 물어보기
- 루트 DNS 서버부터 순차 조회 - 전 세계 DNS 시스템을 통해 최종 IP 주소 찾기
이 과정은 마치 전화번호부에서 이름으로 전화번호를 찾는 것과 같다.
3️⃣ TCP 연결: 서버와 통신 채널 열기
IP 주소를 알았으니 이제 서버와 연결해야 한다. 이때 TCP 3-Way Handshake라는 과정을 거친다.
🤝 TCP 3-Way Handshake
클라이언트 → 서버 : SYN (연결 요청)
서버 → 클라이언트 : SYN-ACK (연결 승인 + 역방향 연결 요청)
클라이언트 → 서버 : ACK (최종 연결 확인)이는 두 사람이 전화통화를 시작할 때 "여보세요?" → "네 여보세요?" → "네 안녕하세요"라고 확인하는 과정과 비슷하다.
HTTPS의 경우 여기에 TLS Handshake가 추가로 필요하다. 보안 통신을 위한 암호화 키를 교환하는 과정이다.
4️⃣ HTTP 요청: 웹페이지 요청 보내기
연결이 완료되면 브라우저는 서버에 HTTP 요청을 보낸다.
GET / search?q=frontend HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/118.0.0.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-LanguageL ko-KR,ko;q=0.8,en-US;q=0.5,en;q=0.3
Connection: keep-alive📋 주요 구성 요소
- 요청 방식 : GET (데이터 조회)
- 경로 :
/search?q=frontend - 헤더 : 브라우저 정보, 언어 설정 등
5️⃣ 서버 응답: HTML, CSS, JS 파일 받기
서버는 이 요청을 처리하고 응답을 보낸다.
HTTP/1.1 200 OK
Content-type: text/html; charset=UTF-8
Content-Length: 12345
Cache-Control: max-age=3600
<!DOCTYPE html>
<html>
<head>
<title>검색 결과</title>
<link rel="stylesheet" href="stye.css">
</head>
<body>
<!-- HTML 콘텐츠 -->
<script src="app.js"></script>
</body>
</html>이제 브라우저는 HTML을 파싱하면서 추가로 필요한 리소스들(CSS, JS, 이미지 등)을 발견하면 추가 요청을 보낸다.
6️⃣ 브라우저 렌더링 : 화면에 웹페이지 그리기
드디어 화면에 그릴 차례다. 이 과정은 이전 글에서 다뤘던 렌더링 파이프라인과 연결된다.
🎨 렌더링 과정
- HTML 파싱 → DOM 생성
- CSS 파싱 → CSSOM 생성
- DOM + CSSOM → Render Tree 구성
- Layout (Reflow) → 요소 위치/크기 계산
- Paint (Repaint) → 픽셀 채우기
- Composite → 레이어 합성
JavaScript가 있다면 파싱 중간에 실행되어 DOM을 조작할 수도 있다.
⚡ 성능 최적화 관점에서 보기
각 단계에서 성능을 개선할 수 있는 방법은 어떤 것들이 있을까?
1. DNS 조회 최적화
- DNS Prefetch : `
- CDN 사용으로 지리적으로 가까운 서버 이용하기
2. 연결 최적화
- HTTP/2 사용 : 다중 요청 처리
- Keep-Alive : 연결 재사용
3. 리소스 최적화
- 압축 : Gzip, Brotli
- 캐싱 : 브라우저/서버 캐시 활용
- 번들링 : 파일 개수 줄이기
🎯 정리
주소창에 URL을 입력하는 순간부터 웹페이지가 화면에 나타나기까지는 생각보다 많은 과정을 거친다.
DNS 조회부터 TCP 연결, HTTP 통신, 브라우저 렌더링까지... 이 모든 과정이 몇 초 만에 완료된다는 것이 신기하면서도 웹 기술의 발전을 실감하게 된다.
이런 기본 원리를 이해하면
- 웹 성능 최적화의 방향을 잡을 수 있으며
- 네트워크 문제 상황에서 원인을 파악할 수 있다
개발자로서 겉으로 보이는 결과물뿐만 아니라 그 이면의 동작 원리를 아는 것이 얼마나 중요한지 새삼 느끼게 되는 주제였다 🤔
