웹의 작동 원리와 역사
브라우저 요청과 서버 응답으로 웹 페이지가 전달되는 흐름을 이해하고 웹 표준이 발전해 온 배경을 연결합니다.
웹 개발을 처음 시작하면 화면을 만드는 기술부터 배우고 싶어집니다. 하지만 브라우저가 요청을 보내고 서버가 응답하는 흐름을 모르면, 이후에 배울 HTML, CSS, 자바스크립트가 서로 떨어진 지식처럼 느껴지기 쉽습니다. 예를 들어 페이지가 느릴 때 원인이 코드인지, 네트워크인지, 서버의 응답인지 구분하지 못하면 문제를 찾는 데 오래 걸립니다.
이 글에서는 주소를 입력한 순간부터 화면이 그려지기까지 웹이 어떻게 동작하는지 따라가고, 웹이 지금의 모습으로 발전해 온 과정을 간단히 살펴봅니다. 이 흐름을 알아 두면 앞으로 기술을 고르거나 문제를 찾을 때 어느 단계부터 확인할지 판단할 수 있습니다.
URL 입력에서 렌더링까지의 웹 요청 생명주기 — 상태 추적
URL·연결·HTTP 응답·DOM 해석·표시의 실행 경계가 차례로 달라진다. 한 요청을 따라 현재 보유 정보와 화면 준비 상태를 보여 주면 초보자가 요청과 렌더를 구분한다.
REQUEST & RENDER
HTTP 응답을 해석해 브라우저가 화면을 구성합니다
주소와 연결을 준비하고 자원을 받은 뒤 문서·스타일 해석과 화면 구성이 이어집니다. 캐시와 병행 요청이 이 흐름에 영향을 줍니다.
병행과 재사용
새 HTTPS 문서를 받는 단순화한 예입니다. DNS 캐시·기존 연결·HTTP 캐시를 재사용할 수 있으며, 문서 해석 중 CSS·JS·이미지 요청이 병행됩니다.
느린 곳을 구분하는 관찰
Network에서는 연결·응답 대기·전송을, Performance에서는 스크립트·레이아웃·그리기 시간을 확인합니다. HTML을 받았다고 화면 구성까지 끝난 것은 아닙니다.
그림의 상자 사이 간격은 소요 시간이 아닙니다. 스타일 계산·레이아웃·페인트·합성은 내용과 변화에 따라 반복되며, 모든 갱신이 모든 단계를 수행하는 것은 아닙니다.
이 예의 조건
- 원도표의 전체 구조와 설명은 위 관계도와 표에서 유지합니다. 아래 인쇄 표에도 원도표의 관계·조건·라벨·설명·주석을 보존합니다.
- 두 관찰 칸의 위치는 고정입니다. 관찰 상태는 해당 순간의 값이며, 동작·이유는 그 조건에서의 판정과 변화 원인입니다. 독립 비교와 실패 분기는 별도 조건으로 읽고 모든 분기를 한 요청의 필수 실행 순서로 이어 읽지 않습니다.
관계도의 보충 설명
| 구분 | 내용 |
|---|---|
| 전체 관계·조건 설명 | 주소 해석과 이름 및 연결 준비를 거쳐 서버에 요청한다. HTML 응답은 브라우저의 문서 및 스타일 해석으로 이어지고 화면을 구성한다. |
| 원도표 설명 | Network에서는 연결·응답 대기·전송을, Performance에서는 스크립트·레이아웃·그리기 시간을 확인합니다. HTML을 받았다고 화면 구성까지 끝난 것은 아닙니다. |
| 장면 | 현재 관찰값 | 설명 | 변화 이유 |
|---|---|---|---|
| 문서를 요청한다 | 브라우저: 문서 없음 / 요청: URL의 document GET | URL 탐색을 시작하고 연결 및 HTTP 응답을 기다린다 | 탐색이 시작되어 호스트의 응답이 필요하다 |
| 문서로 화면을 계산한다 | 문서: 응답 HTML / 화면: DOM·style·layout 계산 | HTML을 DOM으로 읽고 스타일과 레이아웃을 계산한다 | 응답을 읽어 화면 표현을 준비한다 |
| 픽셀을 표시한다 | 화면: paint 결과 / 자원: 문서와 별도 요청될 수 있음 | 계산된 배치를 paint하고 필요한 자원을 이어 처리한다 | 계산 결과가 표시되며 후속 자원에 따라 화면이 갱신될 수 있다 |
URL 입력에서 렌더링까지의 웹 요청 생명주기 — 상태 추적
URL·연결·HTTP 응답·DOM 해석·표시의 실행 경계가 차례로 달라진다. 한 요청을 따라 현재 보유 정보와 화면 준비 상태를 보여 주면 초보자가 요청과 렌더를 구분한다.
REQUEST & RENDER
HTTP 응답을 해석해 브라우저가 화면을 구성합니다
주소와 연결을 준비하고 자원을 받은 뒤 문서·스타일 해석과 화면 구성이 이어집니다. 캐시와 병행 요청이 이 흐름에 영향을 줍니다.
병행과 재사용
새 HTTPS 문서를 받는 단순화한 예입니다. DNS 캐시·기존 연결·HTTP 캐시를 재사용할 수 있으며, 문서 해석 중 CSS·JS·이미지 요청이 병행됩니다.
느린 곳을 구분하는 관찰
Network에서는 연결·응답 대기·전송을, Performance에서는 스크립트·레이아웃·그리기 시간을 확인합니다. HTML을 받았다고 화면 구성까지 끝난 것은 아닙니다.
그림의 상자 사이 간격은 소요 시간이 아닙니다. 스타일 계산·레이아웃·페인트·합성은 내용과 변화에 따라 반복되며, 모든 갱신이 모든 단계를 수행하는 것은 아닙니다.
이 예의 조건
- 원도표의 전체 구조와 설명은 위 관계도와 표에서 유지합니다. 아래 인쇄 표에도 원도표의 관계·조건·라벨·설명·주석을 보존합니다.
- 두 관찰 칸의 위치는 고정입니다. 관찰 상태는 해당 순간의 값이며, 동작·이유는 그 조건에서의 판정과 변화 원인입니다. 독립 비교와 실패 분기는 별도 조건으로 읽고 모든 분기를 한 요청의 필수 실행 순서로 이어 읽지 않습니다.
관계도의 보충 설명
| 구분 | 내용 |
|---|---|
| 전체 관계·조건 설명 | 주소 해석과 이름 및 연결 준비를 거쳐 서버에 요청한다. HTML 응답은 브라우저의 문서 및 스타일 해석으로 이어지고 화면을 구성한다. |
| 원도표 설명 | Network에서는 연결·응답 대기·전송을, Performance에서는 스크립트·레이아웃·그리기 시간을 확인합니다. HTML을 받았다고 화면 구성까지 끝난 것은 아닙니다. |
| 장면 | 현재 관찰값 | 설명 | 변화 이유 |
|---|---|---|---|
| 문서를 요청한다 | 브라우저: 문서 없음 / 요청: URL의 document GET | URL 탐색을 시작하고 연결 및 HTTP 응답을 기다린다 | 탐색이 시작되어 호스트의 응답이 필요하다 |
| 문서로 화면을 계산한다 | 문서: 응답 HTML / 화면: DOM·style·layout 계산 | HTML을 DOM으로 읽고 스타일과 레이아웃을 계산한다 | 응답을 읽어 화면 표현을 준비한다 |
| 픽셀을 표시한다 | 화면: paint 결과 / 자원: 문서와 별도 요청될 수 있음 | 계산된 배치를 paint하고 필요한 자원을 이어 처리한다 | 계산 결과가 표시되며 후속 자원에 따라 화면이 갱신될 수 있다 |
위 그림은 새 HTTPS 문서를 처음 받을 때의 흐름을 다섯 단계로 보여 줍니다. 브라우저는 주소창의 URL에서 scheme, host, path를 읽고, 필요하면 DNS로 서버의 IP 주소를 찾아 HTTPS 연결을 준비합니다. 서버가 HTTP 요청에 HTML로 응답하면, 브라우저는 그 문서를 해석해 DOM과 스타일 모델을 만들고, 스타일 계산, 레이아웃, 페인트, 합성을 거쳐 화면을 구성합니다.
그림 아래의 설명처럼 실제로는 이 흐름이 항상 처음부터 끝까지 반복되지는 않습니다. DNS 캐시나 이미 열린 연결, HTTP 캐시를 다시 쓰면 앞 단계의 일부를 건너뛰고, 문서를 해석하는 동안 CSS, 자바스크립트, 이미지 요청이 함께 진행됩니다. 상자 사이의 간격은 걸리는 시간이 아니며, 느린 곳을 찾을 때는 브라우저 개발자 도구의 Network 패널에서 연결, 응답 대기, 전송 시간을, Performance 패널에서 스크립트, 레이아웃, 그리기 시간을 확인합니다. HTML을 받았다고 해서 화면 구성까지 끝난 것은 아닙니다.
웹이란 무엇이며, 어떻게 작동할까요?
우리가 흔히 웹(Web)이라고 부르는 것은 월드 와이드 웹(World Wide Web)을 줄인 말입니다. 인터넷은 컴퓨터 사이에 데이터를 보내는 기반이고, 웹은 그 기반 위에서 URL로 자원을 찾고 링크로 문서를 연결하는 서비스입니다. 인터넷 위에는 웹 말고도 이메일 같은 서비스가 있으므로, 브라우저로 웹을 쓴다는 말과 인터넷을 쓴다는 말은 가리키는 범위가 다릅니다. 문서들이 거미줄처럼 서로 연결되어 있다고 해서 웹이라는 이름이 붙었습니다.
웹은 다음 요소들이 맞물려 동작합니다.
- 클라이언트(client)와 서버(server): 웹 브라우저(Chrome, Edge, Firefox, Safari 등)는 클라이언트로서 정보를 요청하고, 서버는 데이터를 저장하고 있다가 요청에 맞는 정보로 응답합니다. 지금 보고 있는 이 페이지도 서버에 있는 내용을 브라우저가 요청해 받아 온 결과입니다.
- HTTP(HyperText Transfer Protocol): 클라이언트와 서버가 요청과 응답을 주고받을 때 따르는 통신 규약입니다. 주소창에
https://www.example.com을 입력하면 브라우저는www.example.com서버에 자원을 요청하며,https는 HTTP 요청과 응답을 암호화된 연결로 주고받는다는 뜻입니다. - URL(Uniform Resource Locator): 웹 페이지, 이미지, 동영상 같은 자원의 위치를 나타내는 주소입니다. 도서관에서 책꽂이 번호와 제목으로 책을 찾듯이, 클라이언트는 URL로 서버에 원하는 자원이 어디 있는지 알려 줍니다.
- HTML, CSS, 자바스크립트: 웹 페이지를 이루는 세 언어입니다. HTML(HyperText Markup Language)은 제목, 문단, 이미지, 링크 같은 내용의 구조를, CSS(Cascading Style Sheets)는 색상, 글꼴, 배치 같은 모양을, 자바스크립트(JavaScript)는 버튼을 눌렀을 때의 동작처럼 사용자와 주고받는 기능을 맡습니다.
웹사이트의 첫 문서를 요청하면 서버는 보통 HTML로 응답합니다. 브라우저는 그 HTML을 읽다가 CSS, 자바스크립트, 이미지의 주소를 발견하면 필요한 자원을 따로 요청합니다. 그래서 한 페이지가 하나의 응답에 모두 담겨 오는 것은 아니며, 브라우저는 받은 자원을 해석해 화면을 그립니다.
브라우저가 알아서 다 처리해 주니 네트워크는 신경 쓰지 않아도 된다고 생각하기 쉽지만, 같은 코드라도 지연 시간(latency), 캐시 정책, 응답 크기에 따라 체감 속도가 크게 달라집니다. 앞의 그림에서 DNS는 www.example.com 같은 호스트 이름으로 연결할 IP 주소를 찾는 과정이고, DOM은 브라우저가 HTML을 읽어 만든 요소의 트리 구조입니다. 이름과 주소를 찾는 일, 문서를 받는 일, 받은 문서로 화면을 만드는 일은 서로 다른 단계이므로, 문제가 생기면 어느 단계에서 생겼는지부터 나눠 봅니다.
예를 들어 소개 페이지의 글은 보이는데 사진만 보이지 않는다고 해 보겠습니다. 브라우저가 사진 주소를 따로 요청했지만 파일이 없어 404 응답을 받았다면, 이미지의 src 값과 실제 파일 위치를 비교합니다. 반대로 사진 요청은 성공했는데 CSS가 사진을 숨기고 있다면, 개발자 도구의 Elements 패널에서 그 요소에 적용된 스타일을 확인합니다. 같은 증상이라도 요청이 실패했는지, 받은 자원을 화면에 그리지 않았는지에 따라 확인할 곳이 달라집니다.
요청과 응답의 기본 흐름은 MDN의 웹 동작 설명에서도 함께 확인할 수 있습니다.
웹은 어떻게 시작되었고 발전해 왔을까요?
오늘날의 웹은 많은 사람의 아이디어와 표준 작업이 쌓여 만들어졌습니다. 웹이 어떤 문제를 풀려고 시작되었고 어떻게 넓어졌는지 알면, 브라우저와 서버, 표준이 각각 어떤 역할을 맡게 되었는지 이해하기 쉽습니다.
- 웹의 탄생(1989–1990년): 스위스 제네바의 유럽 입자 물리 연구소(CERN)에서 일하던 팀 버너스리(Tim Berners-Lee)가 1989년, 연구자들이 정보를 쉽게 공유할 수 있도록 하이퍼텍스트(hypertext)로 문서를 연결하는 시스템을 제안했습니다. 이듬해 말에는 첫 웹 서버와 브라우저가 실제로 동작했습니다.
- 개방과 확산(1993–1994년): 1993년 CERN이 웹 소프트웨어를 누구나 자유롭게 쓸 수 있도록 공개했고, 같은 해 그래픽 브라우저 모자이크(Mosaic)가 나오면서 글뿐 아니라 이미지가 섞인 페이지를 쉽게 볼 수 있게 되었습니다. 1994년에는 웹 표준을 함께 만들기 위해 W3C(World Wide Web Consortium)가 세워졌고, 이후 넷스케이프(Netscape) 같은 브라우저가 널리 쓰였습니다.
- 참여와 공유(2000년대): 블로그, 위키, 소셜 서비스가 늘면서 사용자가 정보를 읽기만 하지 않고 직접 만들고 공유하는 흐름이 커졌습니다. 이 변화를 웹 2.0이라고 부르지만, 웹의 버전이 올라간 것은 아니며 쓰임새가 달라진 것을 가리키는 말입니다.
- 모바일과 반응형 웹(2000년대 후반부터): 스마트폰과 태블릿으로 같은 콘텐츠를 보게 되면서, 화면 크기에 맞춰 배치를 바꾸는 반응형 웹 디자인이 중요해졌습니다.
- 애플리케이션 플랫폼(현재): 오늘날 브라우저는 문서를 보여 주는 데 그치지 않고 통신, 저장, 미디어, 그래픽 같은 기능을 갖춘 애플리케이션 실행 환경입니다. 메일, 문서 편집, 지도처럼 예전에는 따로 설치하던 프로그램도 브라우저에서 실행합니다.
WEB EVOLUTION
개방적인 문서 공유에서 다양한 웹 앱으로 확장됐습니다
초기 구현과 자유 이용 공개가 확산의 바탕이 되었고, 표준·참여·모바일 기능이 함께 발전했습니다.
초기 사건의 연도 간격을 1년·3년·1년으로 표시했습니다. 각 해 안의 날짜 차이는 생략했습니다. 1993년 4월 30일의 CERN 자유 이용 공개와 같은 해 그래픽 브라우저 확산은 서로 다른 사건입니다.
2000년대 · 참여와 공유
블로그·위키·소셜 서비스에서 사용자가 직접 콘텐츠를 만들고 공유하는 흐름이 커졌습니다. 웹 2.0은 단일 버전 업그레이드가 아닙니다.
2000년대 후반부터 · 모바일
스마트폰·태블릿에서도 같은 콘텐츠를 이용하게 되면서 다양한 화면에 맞추는 반응형 설계가 중요해졌습니다.
오늘 · 애플리케이션 플랫폼
문서 읽기에 더해 통신·저장·미디어·상호작용을 제공하는 앱을 브라우저에서 실행합니다. 개방 표준과 기능 확장은 계속됩니다.
위 그림은 웹 초기의 네 사건을 연도 간격에 맞춰 놓고, 그 뒤의 흐름을 세 단계로 이어 보여 줍니다. 1989년의 제안에서 1990년의 첫 서버와 브라우저까지는 1년, 1993년 CERN의 공개와 모자이크까지는 3년, 1994년 W3C 설립까지는 다시 1년입니다. 그림 아래의 설명처럼 1993년 4월 30일의 CERN 공개와 같은 해 그래픽 브라우저의 확산은 서로 다른 사건입니다. 자유롭게 쓸 수 있는 구현과 공개된 표준이 바탕이 되었고, 그 위에서 사용자 참여, 모바일, 애플리케이션 기능이 차례로 넓어졌습니다.
이처럼 웹은 문서를 전달하는 시스템에서 애플리케이션을 실행하는 환경으로 계속 넓어졌지만, 브라우저가 요청하고 서버가 응답하는 기본 구조는 그대로입니다.
더 깊이: 지금의 HTML 표준은 누가 만들까
W3C가 세워진 뒤에도 HTML 표준을 만드는 곳은 한 군데가 아니었습니다. 2004년에 Apple, Mozilla 재단, Opera의 개발자들이 W3C가 HTML보다 XHTML에 힘을 싣는 방향을 우려해 WHATWG(Web Hypertext Application Technology Working Group)를 세웠고, 한동안 W3C와 WHATWG가 각자 HTML 명세를 펴냈습니다. 같은 기술에 문서가 둘이라 어느 쪽을 따라야 하는지 헷갈리는 일이 생겼습니다.
이 상황은 2019년 5월 두 단체가 맺은 양해 각서(memorandum of understanding)로 정리되었습니다. 이때부터 HTML과 DOM은 WHATWG가 관리하는 단일 문서인 리빙 스탠더드(Living Standard)로 만들고, W3C는 별도 판을 펴내지 않는 대신 WHATWG가 주기적으로 떼어 내는 스냅샷(Review Draft)을 W3C 권고안으로 승인합니다. 리빙 스탠더드는 버전 번호 없이 계속 고쳐지므로, 지금 참고할 HTML 명세는 html.spec.whatwg.org입니다.
다른 언어는 만드는 곳이 다릅니다. CSS는 여전히 W3C의 CSS 작업 그룹(CSS Working Group)이 만들지만, 하나의 큰 명세 대신 선택자, 색, Flexbox처럼 기능별 모듈로 나눠 모듈마다 따로 레벨을 올립니다. 이 그룹이 펴내는 CSS 스냅샷 문서도 CSS는 전통적인 의미의 버전 대신 레벨을 가지며 언어 전체의 레벨 4는 없다고 밝히므로, 흔히 말하는 CSS3는 여러 모듈을 묶어 부르는 이름에 가깝습니다. 자바스크립트의 표준인 ECMAScript는 Ecma International의 TC39 위원회가 만듭니다.
정리
- 인터넷은 데이터를 주고받는 기반이고, 웹은 그 위에서 URL과 링크로 자원을 연결하는 서비스입니다.
- 브라우저는 URL을 해석하고 이름과 연결을 준비한 뒤 HTTP로 문서를 요청하며, 받은 HTML을 DOM과 스타일 모델로 바꿔 화면을 구성합니다.
- 한 페이지는 여러 응답으로 이루어지며, HTML 안의 CSS, 자바스크립트, 이미지는 따로 요청됩니다.
- 캐시와 기존 연결을 다시 쓰면 일부 단계를 건너뛰며, 느린 곳은 Network와 Performance 패널로 나눠 확인합니다.
- 웹은 1989년의 제안과 1993년의 공개, 1994년의 W3C 설립을 거쳐 참여, 모바일, 애플리케이션 플랫폼으로 넓어졌습니다.
연습 문제
1. HTML 요청은 성공했는데
친구가 “HTML 요청이 성공했으니 화면의 이미지도 모두 정상으로 받아 왔을 것이다”라고 말합니다. 이 주장이 맞지 않는 이유를 설명하고, 이미지가 보이지 않을 때 확인할 곳을 두 가지 들어 보세요.
해설 보기
HTML 안의 이미지 주소는 별도의 요청으로 이어지므로, 문서 요청이 성공했다고 이미지 요청까지 성공했다고 볼 수 없습니다. 이미지 파일이 없거나 주소가 틀리면 그 요청만 실패합니다.
먼저 Network 패널에서 그 이미지 URL의 요청과 상태 코드를 확인합니다. 요청이 성공했다면 Elements 패널에서 src 값과 그 요소를 숨기는 스타일이 있는지 확인합니다.
2. 인터넷과 웹
메일 프로그램으로 이메일을 보내는 것과 브라우저로 뉴스 사이트를 여는 것은 둘 다 인터넷을 쓰는 일입니다. 둘 중 웹을 쓰는 것은 어느 쪽이며, 그 이유는 무엇일까요?
해설 보기
브라우저로 뉴스 사이트를 여는 쪽이 웹을 쓰는 일입니다. 브라우저가 URL로 자원을 찾고 HTTP로 HTML 문서를 요청해 받아 오기 때문입니다.
메일 프로그램의 이메일 전송은 인터넷 위의 다른 서비스로, 메일 전송용 규약을 씁니다. 다만 웹 메일처럼 브라우저에서 메일을 읽고 쓴다면, 그 화면을 주고받는 부분은 웹입니다.
3. 두 번째 방문이 빠른 이유
같은 사이트를 두 번째로 열었더니 처음보다 훨씬 빨리 열렸습니다. 그림의 다섯 단계 중 어떤 단계를 줄일 수 있었을까요? 그래도 꼭 다시 해야 하는 일은 무엇일까요?
해설 보기
DNS 결과가 캐시에 남아 있으면 이름 찾기를 건너뛰고, 열려 있는 연결을 다시 쓰면 연결 준비를 줄입니다. HTTP 캐시에 저장된 CSS, 이미지 같은 자원은 서버에서 다시 받지 않아도 됩니다.
그래도 브라우저는 받은 문서로 DOM과 스타일 모델을 다시 만들고, 레이아웃과 페인트를 거쳐 화면을 구성해야 합니다. 캐시는 자원을 받는 시간을 줄일 뿐, 화면을 그리는 일까지 대신하지는 않습니다.
다음 글 HTML, CSS, 자바스크립트 소개에서는 웹 페이지를 이루는 세 언어가 각각 무엇을 맡는지 살펴봅니다.