컴퓨터 네트워크

서론

브라우저는 하나의 운영체제입니다. 매일 브라우저를 사용하며 — 영상을 보고, 뉴스를 읽고, 온라인으로 업무를 봅니다. 하지만 주소창에 웹사이트 주소를 입력하고 엔터를 누르면 배경에서 무슨 일이 일어나는지 생각해 본 적이 있나요?

이 글은 "온라인 쇼핑"이라는 일상적인 비유와 실제 기술 과정을 통해, 브라우저가 한 줄의 주소를 풍부한 페이지로 바꾸는 과정을 단계별로 이해하도록 도와줍니다.

이 글에서 무엇을 배우게 되나요?

이 장을 마치면 URL 입력부터 페이지 표시까지의 완전한 기술 흐름을 파악하고, 브라우저와 서버가 어떻게 협력하는지 이해하게 됩니다. 이 지식은 이후 API, 인터페이스, 네트워크 보안 등을 학습하는 기초가 되며, "웹페이지가 열리지 않아요", "로딩이 느려요" 등의 일상적인 문제를 해결하는 핵심입니다.

장	내용	핵심 개념
제1장	URL 해석	웹 주소의 구조와 역할
제2장	DNS 조회	도메인 이름을 IP 주소로 변환
제3장	TCP 핸드셰이크	신뢰할 수 있는 연결 설정
제4장	HTTP 통신	브라우저와 서버의 대화
제5장	브라우저 렌더링	코드가 화면이 되는 과정
제6장	정적 vs 동적	웹페이지 콘텐츠의 생성 방식

0. 서론: 엔터 키를 누르는 그 순간

🤔 핵심 질문

브라우저에 웹사이트 주소를 입력하고 엔터를 누르면 배경에서 무슨 일이 일어날까요? 왜 어떤 웹페이지는 빨리 열리고, 어떤 것은 느릴까요? 왜 "서버를 찾을 수 없습니다"라는 오류가 가끔 나타날까요?

일상 비유: 온라인 쇼핑 여정

온라인 쇼핑을 한다고 상상해 보세요. 전체 과정은 5단계로 나눌 수 있습니다:

🛒 1단계: 주문서 작성 상품 선택, 배송지 확인

🗺️ 2단계: 창고 검색 시스템이 구체적인 출고 창고를 찾음

📞 3단계: 통로 확립 창고가 영업 중이고 발송 가능한지 확인

🚚 4단계: 창고 발송 배달원이 택배를 배달

🎁 5단계: 개봉 체험 포장을 열고 원하는 상품 확인

웹페이지에 접속하는 과정은 온라인 쇼핑과 놀랍도록 유사합니다!

브라우저에 google.com을 입력하고 엔터를 누르면, 여러분은 "구매자"가 되고, 브라우저는 일련의 작업을 통해 원격 서버에 있는 "상품"(웹페이지 콘텐츠)을 화면으로 가져옵니다.

https://

试一试:

🛒

出发

🗺️

查仓库

📞

建立通道

🚚

发货

🎁

收货

👈 在左上角输入网址，开启网络快递之旅

💡 핵심 통찰

브라우저 작동 원리를 이해하는 핵심은 복잡한 기술 과정을 익숙한 일상 시나리오에 매핑하는 것입니다. 온라인 쇼핑의 5단계는 브라우저가 웹페이지에 접속하는 5개 기술 단계와 완벽하게 대응합니다.

1. 첫 번째 단계: "주문서" 작성 — URL 해석

🤔 핵심 질문

왜 웹 주소가 저렇게 생겼을까요? https://www.example.com:8080/path/page.html?id=123#section — 이 문자열은 대체 무슨 의미일까요?

일상 비유: 구매 목록 작성

주문서에 "신발 사기"라고만 쓰면, 창고에서는 어떤 신발을 보내야 할지 모릅니다. 다음을 명확히 적어야 합니다:

매장 유형(공식 플래그십스토어/일반 매장)
매장명(나이키 공식 매장)
상품 위치(남성화 코너/러닝화 시리즈)
구체적인 모델(에어맥스 90)
추가 정보(빨간색으로 주세요)

실제 과정: 브라우저의 URL 해석

URL(Uniform Resource Locator, 통일 자원 위치 지정자)은 브라우저 세계의 "상품 위치 코드"입니다. 주소창에 https://www.example.com:8080/path/page.html?id=123#section을 입력하면 브라우저는 즉시 이를 분해합니다:

URL 부분	예시 값	온라인 쇼핑 비유	기술적 역할
프로토콜 `https://`	보안 하이퍼텍스트 전송 프로토콜	배송 방식: 비밀 배송(HTTPS) vs 일반 배송(HTTP)	어떤 규칙으로 통신할지 결정. `http`는 일반 전송, `https`는 암호화 전송
도메인 `www.example.com`	서버의 사람이 읽을 수 있는 이름	매장명: 이마트	브라우저에게 어느 서버를 찾을지 알려줌. 도메인은 기억하기 위한 것, 최종적으로 IP 주소로 변환됨
포트 `:8080`	서버의 구체적인 "호수"	카운터 번호: 3번 카운터(기본값은 생략)	서버에 여러 서비스가 있을 수 있으며, 포트는 어느 것에 접속할지 지정. HTTP 기본 80, HTTPS 기본 443
경로 `/path/page.html`	서버 상의 파일 위치	진열대 위치: 생활용품 코너/3번째 줄	서버 상의 구체적인 자원 위치 지정
쿼리 매개변수 `?id=123`	추가 정보	주문 메모: 빨간색, XL 사이즈	서버에 전달할 추가 데이터, 예: 검색 키워드, 페이지 번호 등
앵커 `#section`	페이지 내의 위치	설명서 페이지: 5페이지로 넘기기	페이지 로드 후 지정된 위치로 자동 스크롤, 서버에 전송되지 않음

URL Parsing -- Translating human text into structured information

https://www.google.com/search

🚛 Transport mode (Protocol)

This says you want the safest vehicle, HTTPS encrypted communication. With HTTP, it is like an open-top car that anyone along the way can inspect.

🏢 Store name (Host)

This is the destination server domain. The browser later translates it into the numeric IP address used by the network.

📍 Exact shelf (Path)

After entering the store, this tells the server which room, resource, or action you want.

Hover over each part to see its responsibility

💡 핵심 이해

URL은 사람이 기억하고 입력할 수 있도록 존재합니다. 컴퓨터가 궁극적으로 필요로 하는 것은 IP 주소입니다(배달원이 궁극적으로 필요로 하는 것은 "나이키 공식 매장"이라는 이름이 아니라 구체적인 창고 주소인 것과 같습니다).

2. 두 번째 단계: "주소록" 찾기 — DNS 조회

🤔 핵심 질문

브라우저는 웹사이트를 어떻게 찾을까요? 여러분이 입력하는 것은 사람이 읽을 수 있는 도메인 이름(예: baidu.com)이지만, 컴퓨터가 실제로 필요로 하는 것은 숫자 주소(IP)입니다. 그 사이에 무슨 일이 일어날까요?

일상 비유: 창고 주소 찾기

주문서에 "나이키 공식 매장"이라고 썼지만, 물류 시스템은 창고가 어디에 있는지 모릅니다. 주소록을 조회해야 합니다:

먼저 자주 쓰는 주소 확인(최근 이 매장에서 구매한 적이 있나요?) → 브라우저 캐시
없으면 동네 택배점에 문의(큰 지역의 배정을 알고 있음) → 로컬 DNS 서버
본부 배송 센터에 문의(.com류 매장을 누가 관리하는지 알고 있음) → 루트 네임 서버
브랜드 관리 부서에 문의(나이키 매장의 실제 출고 창고를 최종적으로 찾음) → 권한 네임 서버

실제 과정: DNS 계층적 조회

DNS(Domain Name System, 도메인 이름 시스템)은 인터넷의 "분산 주소록 조회 시스템"입니다. 전 세계에 수십억 개의 도메인이 있기 때문에 계층형 아키텍처로 조회 부하를 분산합니다:

나(브라우저)
    ↓ 질문: google.com의 IP는 무엇인가요?
로컬 DNS 서버(통신사, 예: KT/SK)
    ↓ 질문: .com은 누가 관리하나요?
루트 네임 서버(전 세계 13개 그룹, 모든 최상위 도메인 관리)
    ↓ 안내: .com의 관리자에게 문의하세요
최상위 도메인 서버(Verisign이 .com 관리)
    ↓ 안내: google.com의 관리자에게 문의하세요
권한 네임 서버(Google 자체 DNS 서버)
    ↓ 안내: google.com의 IP는 142.250.80.46입니다
브라우저에 IP 주소 반환

조회 유형 설명:

재귀적 조회(Recursive Query): 브라우저가 한 번만 요청을 보내고, 로컬 DNS가 계층적 조회 후 결과를 반환
반복적 조회(Iterative Query): 각 계층이 다음 계층에게 어디서 조회할지만 알려주고, 브라우저가 여러 번 조회해야 함
캐시 메커니즘: 조회 결과가 캐시되어 다음에는 직접 반환되어 접속 속도 크게 향상

DNS Lookup -- Finding coordinates in the address book

📱

Browser

Wants to visit www.google.com

Ask for coordinates

Return IP

📞

Directory service (DNS)

Standing by

Click the button to tell the browser that you do not know where the Google server is

💡 왜 이렇게 많은 계층이 필요한가요?

전 세계에 주소록이 하나뿐이라면, 수십억 명이 동시에 조회할 때 시스템이 다운될 것입니다. 계층형 설계는 각 계층이 자신의 "관할 구역"만 관리하게 하여, 효율적이고 신뢰성이 높습니다.

이것이 인터넷 설계의 핵심 사상인 분산 시스템입니다.

3. 세 번째 단계: 전화 확인 — TCP 3방향 핸드셰이크

🤔 핵심 질문

왜 "3방향 핸드셰이크"가 필요한가요? 서버 주소를 찾은 후 왜 바로 데이터를 보낼 수 없을까요? 왜 먼저 세 번의 통신을 해야 할까요?

일상 비유: 물류 통로 확립

물류 차량이 창고에 바로 도착하면 다음과 같은 상황이 발생할 수 있습니다:

창고 문이 닫혀 있음 → 헛걸음
창고가 꽉 차서 주문을 받지 않음 → 발송 불가
하차장을 찾을 수 없음 → 연결 불가

그래서 실제 발송 전에 신뢰할 수 있는 운송 통로를 확립해야 합니다.

실제 과정: TCP 3방향 핸드셰이크

TCP(Transmission Control Protocol, 전송 제어 프로토콜)은 데이터의 신뢰할 수 있는 전송을 보장하는 규칙입니다. 상품(데이터)을 전송하기 전에 "3방향 핸드셰이크"를 통해 연결을 확립해야 합니다:

클라이언트(내 컴퓨터)              서버(판매자 창고)
   |                                |
   |--- SYN=1 --------------------->|  1번째: 안녕하세요, 저는 집에 있고, 수령 준비 완료!(SYN)
   |                                |
   |<-- SYN=1, ACK=1 ---------------|  2번째: 확인! 저도 발송 준비 완료, 집에 계신가요?(SYN-ACK)
   |                                |
   |--- ACK=1 --------------------->|  3번째: 네! 발송해 주세요.(ACK)
   |                                |
   ===== 통로 확립, 발송 시작 =====

왜 3번인가, 2번이 아닌가?

첫 번째(SYN): 클라이언트가 보낼 수 있음을 증명
두 번째(SYN-ACK): 서버가 받을 수 있고 보낼 수 있음을 증명
세 번째(ACK): 클라이언트가 받을 수 있음을 증명

3방향 핸드셰이크는 양쪽 모두 보내고 받을 수 있음을 보장합니다 — 네 가지 조건이 모두 충족되어야 신뢰할 수 있는 전송이 가능합니다.

TCP의 추가 역할:

데이터 분할: 큰 데이터를 작은 패킷으로 나누어 전송
순서 재조립: 패킷이 올바른 순서로 조립되도록 보장
오류 재전송: 패킷 손실 시 자동 재전송
흐름 제어: 네트워크 상태에 따라 전송 속도 조정

TCP Three-Way Handshake -- Establishing a reliable channel

💻

Browser (you)

Waiting

🖥️

Google server

Waiting

Click "Start connection" to simulate the TCP three-way handshake

HTTPS의 추가 단계: HTTPS(보안 웹사이트)의 경우, TCP 핸드셰이크 후 TLS 핸드셰이크(1-RTT 또는 2-RTT)가 추가로 수행됩니다. 양측이 암호화 키를 교환하여 이후 대화 내용을 양측만 볼 수 있게 합니다. 비밀 암호로 통화하는 것과 같습니다.

4. 네 번째 단계: "구매자"와 "판매자"의 대화 — HTTP 요청과 응답

🤔 핵심 질문

브라우저와 서버는 무슨 말을 하나요? 연결이 확립된 후, 브라우저는 서버에게 무엇을 원하는지 어떻게 "알리며", 서버는 어떻게 "응답"할까요?

일상 비유: 창고 발송

물류 차량이 창고에 도착합니다: "이것은 주문서(HTTP 요청)입니다. 상품(웹페이지 HTML 소스 코드)을 가져가겠습니다!" 창고 관리자가 확인합니다: "주문이 유효합니다. 원하시는 소포(HTML 파일)입니다. 잘 받으세요."

실제 과정: HTTP 프로토콜 통신

HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 프로토콜)은 브라우저와 서버 간의 "대화 규칙"입니다. 통로가 확립된 후, 브라우저는 수령 요청을 보내며, 핵심 목표는 웹페이지의 소스 코드(HTML 파일)를 가져오는 것입니다:

HTTP 요청 예시:

http

GET /index.html HTTP/1.1          ← 요청 메서드 + 경로 + 프로토콜 버전
Host: www.example.com             ← 대상 호스트(가상 호스트 지원, 한 서버에서 여러 웹사이트 호스팅 가능)
User-Agent: Chrome/120.0          ← 클라이언트 식별(서버가 이에 맞춰 콘텐츠 반환 가능)
Accept: text/html,application/xhtml+xml  ← 수락 가능한 응답 형식
Accept-Language: ko-KR,ko;q=0.9   ← 선호하는 언어
Accept-Encoding: gzip, deflate    ← 지원하는 압축 형식
Connection: keep-alive            ← 연결 유지(TCP 연결 재사용)
Cookie: session_id=abc123         ← 인증 정보

💡 개발자 통찰: 이거不就是 API인가요?

완전히 같습니다! 평소 작성하는 API 호출(fetch / axios)과 브라우저가 웹페이지에 접속하는 것은 HTTP 수준에서 완전히 동일한 것입니다.

둘 다 요청을 보내고 서버가 텍스트 데이터를 반환합니다.

서버가 HTML을 주면, 브라우저는 그것을 그려서(웹페이지로 만듭니다) 보여줍니다.
서버가 JSON을 주면, 코드는 그것을 저장하여(로직 처리에 사용합니다) 활용합니다.

"두 가지 종류"의 요청이 존재하는 것이 아니라, 동일한 HTTP 요청이 있을 뿐이며, 반환되는 데이터 형식(Content-Type)만 다릅니다. 이것이 HTTP를 이해하면 백엔드 API 원리의 90%를 이해하게 되는 이유입니다.

API 개발에 대해 자세히 알고 싶다면 API 챕터를 참조하세요.

일반적인 HTTP 메서드:

GET: 자원 획득(안전, 멱등성, 캐시 가능)
POST: 데이터 제출(자원 생성, 예: 회원가입, 로그인)
PUT: 자원 갱신(전체 교체)
PATCH: 자원 부분 갱신
DELETE: 자원 삭제
HEAD: 응답 헤더만 획득(본문 반환 안 함, 자원 존재 여부 확인용)

서버의 HTTP 응답:

http

HTTP/1.1 200 OK                   ← 프로토콜 버전 + 상태 코드 + 상태 설명
Date: Mon, 23 May 2025 12:00:00 GMT  ← 서버 시간
Content-Type: text/html; charset=UTF-8  ← 콘텐츠 유형과 인코딩
Content-Length: 1234              ← 콘텐츠 길이(바이트)
Cache-Control: max-age=3600       ← 캐시 정책
Set-Cookie: user_id=xyz789        ← 쿠키 설정

<!DOCTYPE html>...                ← 응답 본문(웹페이지 콘텐츠)

HTTP 상태 코드 분류:

상태 코드	분류	의미	일상 비유
200	성공	요청이 성공적으로 처리됨	"주문 확인, 바로 발송합니다"
301/302	리다이렉트	자원이 이동됨	"저희 매장이 이사했습니다, 새 매장에서 주문해 주세요"
304	수정 없음	캐시가 여전히 유효함	"지난번 구매하신 것 아직 쓸 수 있어요, 다시 발송 안 해도 됩니다"
400	클라이언트 오류	요청 형식 오류	"주문서 내용이 불명확해서 이해가 안 됩니다"
401	미인증	인증 필요	"먼저 회원카드를 보여주세요"
403	접근 금지	권한 부족	"내부 인원 외 출입 금지"
404	찾을 수 없음	자원이 존재하지 않음	"창고에 이 상품이 없습니다"
500	서버 오류	서버 내부 오류	"창고에 화재가 발생하여 일시적으로 발송 불가"
502	게이트웨이 오류	상위 서버 응답 없음	"본 창고에 재고가 없어 분창고에서도 조달 불가"
503	서비스 불가	서버 과부하 또는 유지보수	"주문 폭주로 임시 주문 중단"

HTTP Request and Response -- Sending a note to buy a package

📤 Buyer note: HTTP Request

GET /search HTTP/1.1
Host: www.google.com
User-Agent: Mac Chrome browser
Accept-Language: en-US (I want English content)

📥 Seller package: HTTP Response

The server response package will appear here...

The HTTP request is assembled with a path and supporting headers.

5. 다섯 번째 단계: "소포" 개봉 — 브라우저 렌더링

🤔 핵심 질문

코드가 어떻게 화면이 될까요? 서버가 보낸 것은 지루한 HTML/CSS/JavaScript 코드입니다. 브라우저는 이것들을 어떻게 풍부하고 화려한 웹페이지로 바꿀까요?

일상 비유: 개봉 및 조립

드디어 택배 소포(HTTP 응답)를 받았습니다. 하지만 열어보니 완성된 가구가 아니라 부품(HTML)과 조립 설명서(CSS)가 들어있습니다. "구매자"(브라우저)로서 직접 조립해야 합니다:

포장 개봉: 모든 부품을 꺼내 목록 확인(HTML 파싱 → DOM 트리)
설명서 읽기: 설명서를 이해하여 각 부품이 어디에 붙는지, 색상은 무엇인지 파악(CSS 파싱 → CSSOM 트리)
분류 정리: 조립할 부품만 골라내고 포장 비닐(display: none)은 버림(렌더 트리 구성)
위치 측정: 자로 방 크기를 재고 각 가구의 구체적인 배치 위치 결정(레이아웃/리플로우)
색칠 및 장식: 가구에 페인트 칠하고 스티커 붙이기(페인팅)
최종 전시: 청소하고 불 켜서 전시(컴포지팅)

실제 과정: 브라우저 렌더링 엔진

브라우저가 받는 것은 HTML/CSS/JavaScript 코드(지루한 텍스트)이지만, 이것을 픽셀 화면(아름다운 웹페이지)으로 변환해야 합니다. 이 과정을 렌더링(Rendering)이라고 하며, 브라우저의 렌더링 엔진(예: Chrome의 Blink, Safari의 WebKit)이 실행합니다.

단계 1: HTML 파싱 → DOM 트리 구축 (부품 목록)

브라우저는 HTML 바이트 스트림을 읽어 DOM(Document Object Model, 문서 객체 모델) 트리로 파싱합니다. 흩어진 부품을 계층 구조가 있는 목록으로 정리하는 것과 같습니다:

html

<!-- 원본 HTML -->
<div class="header">제목</div>
<div class="content">내용</div>

text

DOM 트리 구조:
Document
 └─ html
     └─ body
         ├─ div.header ("제목")
         └─ div.content ("내용")

단계 2: CSS 파싱 → CSSOM 트리 구축 (설명서)

브라우저는 모든 CSS(인라인, 외부 파일)를 파싱하여 CSSOM(CSS Object Model) 트리를 구축합니다. 설명서의 스타일 규칙을 이해하는 것과 같습니다:

css

.header {
  color: blue;
  font-size: 24px;
} /* 제목은 파란색이어야 함 */
.content {
  display: none;
} /* 내용은 일시적으로 숨김 */

단계 3: 병합 → 렌더 트리 (조립 준비)

DOM 트리 + CSSOM 트리 = 렌더 트리(Render Tree). 핵심 포인트: "보이는" 요소만 렌더 트리에 포함됩니다.

.header: 렌더 트리에 포함(보임).
.content: 렌더 트리에 미포함(display: none이므로, 버려진 포장지처럼 조립 불필요).

단계 4: 레이아웃(Layout / Reflow) — 크기 측정

브라우저는 렌더 트리의 각 노드가 화면에서 차지할 정확한 좌표와 크기를 계산합니다.

"이 제목 상자는 너비 100px, 높이 50px, 화면 왼쪽 상단 (0,0) 위치에 배치."
이 과정을 리플로우(Reflow)라고 합니다. 창 크기가 변하면(예: 휴대폰 가로 모드) 모든 요소의 위치를 다시 계산해야 하므로 성능 소모가 큽니다.

단계 5: 페인팅(Paint) — 색칠

위치를 파악한 후 브라우저는 픽셀을 채우기 시작합니다: 배경색, 텍스트 색상, 테두리, 그림자 등을 그립니다.

단계 6: 컴포지팅(Composite) — 최종 전시

현대 브라우저는 페이지를 여러 레이어(Layers)로 나누어 각각 그린 후(예: 3D 변환, 스크롤바 독립 레이어), 최종적으로 GPU가 Photoshop 레이어처럼 겹쳐서 화면에 표시합니다.

Browser Rendering -- Turning plain text into a polished page

Receive plain text source code

The response is just plain HTML and CSS text. It is an instruction manual for the page, not the visual page yet.

<html>
  <style>
   .title { color: #f00; }
  </style>
  <body>
   <h1 class="title">
     Google Search
   </h1>
   <input />
  </body>
</html>

Click each step icon above to see the output of each rendering stage

💡 아시나요?

레이아웃과 페인팅은 브라우저가 가장 바쁜 시간입니다. 웹페이지의 요소가 많을수록 구조가 복잡할수록 브라우저는 위치를 계산하고 색을 칠하는 데 더 많은 시간이 필요합니다. 복잡한 웹페이지가 열릴 때 버벅거리는 이유가 바로 이것입니다.

5.5 웹페이지는 어떻게 "생성"되는가? 정적 웹사이트 vs 동적 웹사이트

🤔 핵심 질문

웹페이지 콘텐츠는 어디서 올까요? 브라우저가 페이지를 렌더링하는 방법을 설명했지만, 서버의 HTML 파일은 어떻게 만들어지는 걸까요? 미리 만들어진 것일까요, 즉석에서 만드는 것일까요?

브라우저가 "소포를 개봉"하는 방법을 다뤘습니다 — 서버가 보낸 HTML/CSS/JS를 페이지로 렌더링합니다. 하지만 한 가지 질문을 생각해 본 적 있나요: 서버에 있는 HTML 파일은 어떻게 만들어진 걸까요?

답은 두 가지 방식이 있습니다. 이것이 정적 웹사이트와 동적 웹사이트의 차이입니다.

정적 웹사이트: 미리 만들어서 바로 제공

마트에서 과자를 사는 것을 상상해 보세요. 진열대의 과자는 공장에서 이미 생산된 것이므로, 바로 가져가면 되고 기다릴 필요가 없습니다.

정적 웹사이트는 이런 "완제품"입니다 — 웹페이지가 서버에 이미 준비되어 있고, 접속 시 서버가 완성된 HTML 파일을 그대로 보내주며, 추가 처리를 하지 않습니다.

특징:

✅ 접속 속도 빠름(서버가 파일만 보내고 계산 안 함)
✅ 제작 간단(HTML만 작성하면 됨)
✅ 수용력 높음(CDN으로 배포 가능, 방문자 수 상관없음)
❌ 콘텐츠 업데이트 어려움(내용을 바꾸려면 파일을 다시 생성해야 함)

일반적인 예: 회사 소개 페이지, 제품 문서, 도움말 센터, 개인 블로그

동적 웹사이트: 즉석에서 주문 즉시 제작, 매번 다름

이번에는 식당에서 음식을 주문한다고 상상해 보세요. 요리사가 주문에 따라 즉석에서 요리합니다. 짜장면을 시켰는데 탕수육이 나오지 않습니다.

동적 웹사이트는 접속할 때마다 "즉석에서 제작"되는 페이지입니다 — 서버가 요청을 받은 후 데이터베이스에서 자료를 조회하고, 데이터를 계산한 다음 새로운 HTML을 생성하여 보냅니다.

특징:

✅ 콘텐츠 실시간(장바구니에 최신 재고 표시, 뉴스 실시간 업데이트)
✅ 개인화(로그인 후 개인 정보 표시)
✅ 강력한 기능(검색, 댓글, 추천, 결제 모두 구현 가능)
❌ 접속 속도 느림(서버가 계산에 시간 필요)
❌ 서버 부하 큼(동시에 많은 사람이 접속하면 대기 발생)

일반적인 예: 쇼핑몰, SNS, 인터넷 뱅킹, 온라인 문서 편집기

서버가 필요한가요? 동적 웹사이트는 확실히 어떤 형태의 "백엔드"가 필요하지만, 형태는 다양합니다:

전통적 서버: 서버를 직접 구매/임대(AWS EC2 등)
서버리스(Serverless): 서버를 관리할 필요 없이, 클라우드 공급자가 코드 실행(AWS Lambda, Cloudflare Workers 등)
제3자 API 호출: 결제는 Stripe, 날씨는 기상청 API, 백엔드 코드를 직접 작성하지 않음

💡 정적 + 동적 결합

오늘날 많은 웹사이트는 "혼합형"입니다: 웹페이지의 본체는 정적이지만, 특정 부분(예: 댓글 영역, 검색창)은 동적으로 로드됩니다. JavaScript가 페이지 로드 후 API를 호출하여 데이터를 가져와 "정적 페이지 + 동적 기능"을 구현할 수 있습니다.

📊 정적 vs 동적, 비교하면 한눈에

	정적 웹사이트	동적 웹사이트
어떻게 만들어지는가	미리 만들어 서버에 저장	접속 시 즉석에서 제작
비유	마트 진열대의 상품	식당에서 주문하는 요리
속도	빠름	느림(계산 필요)
콘텐츠 수정	어려움(다시 생성 필요)	쉬움(관리자에서 바로 수정)
적합한 용도	전시형 콘텐츠(소개 페이지, 문서)	상호작용형 애플리케이션(쇼핑, SNS)
대표적인 예	회사 공식 홈페이지, 도움말 문서	쇼핑몰, 메신저, 인터넷 뱅킹

🤔 자주 묻는 질문

Q: 정적 웹사이트는 JavaScript를 사용할 수 없나요?

아닙니다! 이미지 슬라이더, 접이식 메뉴, 폼 유효성 검사 같은 상호작용 기능은 정적 웹사이트에서도 JavaScript로 구현할 수 있습니다. "정적"과 "동적"은 페이지 콘텐츠가 미리 준비되어 있는지를 의미하며, 상호작용 기능의 유무와는 별개입니다.

Q: 동적 웹사이트는 반드시 서버를 직접 구매해야 하나요?

반드시 그런 것은 아닙니다. 전통적 서버 외에도 서버리스(클라우드 함수)를 사용하거나 제3자 API를 직접 호출할 수도 있습니다. 최근의 트렌드는 "서버를 건드리지 않는 것" — 정적 웹사이트 + JavaScript에서 API를 호출하는 방식으로, 빠르고 비용을 절약할 수 있습니다.

💡 중요 안내

정적 웹사이트든 동적 웹사이트든, 브라우저 렌더링의 원리는 동일합니다! 서버가 보낸 것을 브라우저가 렌더링합니다. 차이는 단지:

정적 웹사이트: 서버가 "완제품"을 보냄
동적 웹사이트: 서버가 "즉석에서 만든 것"을 보냄

프론트엔드 개발자로서 주로 관심을 가져야 할 것은 브라우저가 받은 콘텐츠를 어떻게 처리하는지이며, 서버가 어떻게 생성하는지는 아닙니다.

6. 요약: 완전한 "온라인 쇼핑" 여정

🎉 이 장을 마치면 다음을 할 수 있어야 합니다

URL 입력부터 페이지 표시까지의 완전한 흐름 설명
URL, DNS, TCP, HTTP의 역할과 관계 이해
브라우저가 페이지를 렌더링하는 방법 알기
정적 웹사이트와 동적 웹사이트 구분
일상 비유로 브라우저 작동 원리를 다른 사람에게 설명

전체 여정을 되돌아보겠습니다:

단계	기술 용어	온라인 쇼핑 비유	핵심 임무	핵심 기술
1. 해석	URL 해석	주문서 작성	구매자가 무엇을 원하는지 이해	프로토콜, 도메인, 포트, 경로, 매개변수
2. 조회	DNS 조회	창고 주소 확인	매장의 출고 창고 찾기	재귀/반복 조회, 캐시 메커니즘
3. 연결	TCP 핸드셰이크	통로 확립	물류 원활 보장	3방향 핸드셰이크, 시퀀스 번호, 흐름 제어
4. 대화	HTTP 교환	창고 발송	주문 제출 및 수령	요청 메서드, 상태 코드, 헤더 필드
5. 전시	브라우저 렌더링	개봉 및 조립	상품 전시	DOM, CSSOM, 렌더 트리, 레이아웃, 페인팅

전체 과정은 보통 수백 밀리초 내에 완료됩니다 — 얼마나 놀라운 일인지 생각해 보세요!

여러분의 브라우저는 1초도 안 되는 시간에:

복잡한 주소를 해석하고
전 세계에 분산된 DNS 서버를 조회하고
수천 km 떨어진 서버와 신뢰할 수 있는 연결을 확립하고
완전한 HTTP 대화를 수행하고
지루한 코드를 아름다운 화면으로 변환합니다

이것이 인터넷의 매력입니다: 복잡한 기술, 단순한 경험.

💡 심화 학습

특정 부분에 대해 더 깊이 알고 싶다면 다음을 참조하세요:

API 개발: API 소개 - API 설계 및 사용법 학습
프론트엔드 성능: 프론트엔드 성능 최적화 - 웹페이지 로딩 속도 최적화 학습
브라우저 렌더링: 브라우저 렌더링 파이프라인 - 렌더링 세부 사항 심층 학습

7. 용어 빠른 참조표 (Glossary)

용어	풀네임	간단한 설명
URL	Uniform Resource Locator	통일 자원 위치 지정자. 웹페이지의 "주소", 브라우저에게 어디서 자원을 찾을지 알려줌
DNS	Domain Name System	도메인 이름 시스템. 인터넷의 "전화번호부", 사람이 읽을 수 있는 도메인 이름을 기계가 읽을 수 있는 IP 주소로 변환
IP 주소	Internet Protocol Address	인터넷 프로토콜 주소. 네트워크에 연결된 각 기기의 고유한 "호수", 예: `192.168.1.1`
TCP	Transmission Control Protocol	전송 제어 프로토콜. 데이터의 신뢰할 수 있는 전송을 보장하는 "규칙", 3방향 핸드셰이크로 연결 확립
HTTP	HyperText Transfer Protocol	하이퍼텍스트 전송 프로토콜. 브라우저와 서버가 "대화"하는 규칙
HTTPS	HTTP Secure	보안 HTTP. HTTP에 암호화(TLS/SSL)를 추가하여 데이터 보안 보호
HTML	HyperText Markup Language	하이퍼텍스트 마크업 언어. 웹페이지의 "뼈대", 콘텐츠의 구조 정의
CSS	Cascading Style Sheets	종속형 스타일시트. 웹페이지의 "피부", 콘텐츠의 외형 정의
DOM	Document Object Model	문서 객체 모델. 브라우저가 HTML을 변환한 트리 구조, 조작에 편리
CSSOM	CSS Object Model	CSS 객체 모델. 브라우저가 CSS를 변환한 트리 구조
렌더링	Rendering	브라우저가 코드를 화면 픽셀로 변환하는 과정
RTT	Round Trip Time	왕복 시간. 데이터 패킷이 전송되어 수신 확인까지 걸리는 시간, 웹페이지 로딩 속도에 영향

🎓 축하합니다

이제 다시 주소창에 웹 주소를 입력하고 엔터를 누를 때, 화면 뒤에서 분주하게 돌아가는 흥미로운 디지털 세계를 볼 수 있을 것입니다.

여러분은 이제 이해합니다:

왜 가끔 웹페이지가 열리지 않는지(DNS 해석 실패, 서버 다운)
왜 어떤 웹페이지는 빠르고 어떤 것은 느린지(네트워크 지연, 서버 성능, 페이지 복잡도)
브라우저가 코드를 어떻게 화면으로 만드는지(렌더링 파이프라인)

이것이 기술 원리를 이해하는 가치 — 문제가 발생했을 때 원인을 어디서 찾아야 할지 알고, 어찌할 바를 모르지 않게 됩니다.

컴퓨터 네트워크 ​

0. 서론: 엔터 키를 누르는 그 순간 ​

일상 비유: 온라인 쇼핑 여정 ​

1. 첫 번째 단계: "주문서" 작성 — URL 해석 ​

일상 비유: 구매 목록 작성 ​

실제 과정: 브라우저의 URL 해석 ​

2. 두 번째 단계: "주소록" 찾기 — DNS 조회 ​

일상 비유: 창고 주소 찾기 ​

실제 과정: DNS 계층적 조회 ​

3. 세 번째 단계: 전화 확인 — TCP 3방향 핸드셰이크 ​

일상 비유: 물류 통로 확립 ​

실제 과정: TCP 3방향 핸드셰이크 ​

4. 네 번째 단계: "구매자"와 "판매자"의 대화 — HTTP 요청과 응답 ​

일상 비유: 창고 발송 ​

실제 과정: HTTP 프로토콜 통신 ​

5. 다섯 번째 단계: "소포" 개봉 — 브라우저 렌더링 ​

일상 비유: 개봉 및 조립 ​

실제 과정: 브라우저 렌더링 엔진 ​

단계 1: HTML 파싱 → DOM 트리 구축 (부품 목록) ​

단계 2: CSS 파싱 → CSSOM 트리 구축 (설명서) ​

단계 3: 병합 → 렌더 트리 (조립 준비) ​

단계 4: 레이아웃(Layout / Reflow) — 크기 측정 ​

단계 5: 페인팅(Paint) — 색칠 ​

단계 6: 컴포지팅(Composite) — 최종 전시 ​

5.5 웹페이지는 어떻게 "생성"되는가? 정적 웹사이트 vs 동적 웹사이트 ​

정적 웹사이트: 미리 만들어서 바로 제공 ​

동적 웹사이트: 즉석에서 주문 즉시 제작, 매번 다름 ​

📊 정적 vs 동적, 비교하면 한눈에 ​

🤔 자주 묻는 질문 ​

6. 요약: 완전한 "온라인 쇼핑" 여정 ​

7. 용어 빠른 참조표 (Glossary) ​

컴퓨터 네트워크

0. 서론: 엔터 키를 누르는 그 순간

일상 비유: 온라인 쇼핑 여정

1. 첫 번째 단계: "주문서" 작성 — URL 해석

일상 비유: 구매 목록 작성

실제 과정: 브라우저의 URL 해석

2. 두 번째 단계: "주소록" 찾기 — DNS 조회

일상 비유: 창고 주소 찾기

실제 과정: DNS 계층적 조회

3. 세 번째 단계: 전화 확인 — TCP 3방향 핸드셰이크

일상 비유: 물류 통로 확립

실제 과정: TCP 3방향 핸드셰이크

4. 네 번째 단계: "구매자"와 "판매자"의 대화 — HTTP 요청과 응답

일상 비유: 창고 발송

실제 과정: HTTP 프로토콜 통신

5. 다섯 번째 단계: "소포" 개봉 — 브라우저 렌더링

일상 비유: 개봉 및 조립

실제 과정: 브라우저 렌더링 엔진

단계 1: HTML 파싱 → DOM 트리 구축 (부품 목록)

단계 2: CSS 파싱 → CSSOM 트리 구축 (설명서)

단계 3: 병합 → 렌더 트리 (조립 준비)

단계 4: 레이아웃(Layout / Reflow) — 크기 측정

단계 5: 페인팅(Paint) — 색칠

단계 6: 컴포지팅(Composite) — 최종 전시

5.5 웹페이지는 어떻게 "생성"되는가? 정적 웹사이트 vs 동적 웹사이트

정적 웹사이트: 미리 만들어서 바로 제공

동적 웹사이트: 즉석에서 주문 즉시 제작, 매번 다름

📊 정적 vs 동적, 비교하면 한눈에

🤔 자주 묻는 질문

6. 요약: 완전한 "온라인 쇼핑" 여정

7. 용어 빠른 참조표 (Glossary)