웹의 작동 원리와 역사
브라우저 요청과 서버 응답으로 웹 페이지가 전달되는 흐름을 이해하고 웹 표준이 발전해 온 배경을 연결합니다.
웹 개발을 처음 시작하면 화면을 만드는 기술부터 배우고 싶어집니다.
하지만 실제로는 브라우저가 요청을 보내고 서버가 어떻게 응답하는지를 모르면, 이후에 배우는 HTML/CSS/JavaScript도 서로 분리된 지식처럼 느껴지기 쉽습니다.
예를 들어 페이지가 느릴 때 원인이 코드인지, 네트워크인지, 서버 응답인지 구분하지 못하면 문제를 잡는 데 시간이 오래 걸립니다.
이 장은 바로 그 막힘을 줄이기 위한 출발점입니다.
웹이 어떤 구조로 동작하고, 왜 지금의 형태로 발전했는지를 먼저 이해하면 기술 선택과 디버깅 판단이 훨씬 빨라집니다.
지금부터 웹의 기본 원리와 역사적 흐름을 연결해 보면서, 앞으로의 학습을 단단하게 받쳐줄 기준을 함께 세우겠습니다.
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하고 필요한 자원을 이어 처리한다 | 계산 결과가 표시되며 후속 자원에 따라 화면이 갱신될 수 있다 |
웹이란 무엇이며, 어떻게 작동할까요?
우리는 매일 인터넷을 통해 다양한 정보를 접하고 소통합니다.
지금 이 순간에도 여러분은 이 글을 웹 브라우저로 읽고 있습니다.
그렇다면 우리가 흔히 웹(Web)이라고 부르는 것은 정확히 무엇일까요?
또, 어떻게 우리가 원하는 정보를 눈앞에 보여줄 수 있을까요?
웹은 흔히 월드 와이드 웹(World Wide Web)이라고 불립니다.
인터넷은 컴퓨터 사이에 데이터를 보내는 기반이고, 웹은 그 기반 위에서 URL로 자원을 찾아 링크로 연결하는 서비스입니다. 인터넷에는 웹 외에도 이메일 같은 서비스가 있습니다. 브라우저로 웹을 이용한다는 말과 인터넷 자체를 이용한다는 말은 범위가 다릅니다.
마치 거미줄처럼 복잡하게 얽혀 있다고 해서 웹이라는 이름이 붙었죠.
이러한 웹은 다음과 같은 핵심 요소가 맞물리며 동작합니다.
-
클라이언트(Client)와 서버(Server): 웹의 작동 원리를 이해하는 핵심은 클라이언트와 서버입니다. 웹 브라우저(Chrome, Edge, Safari 등)는 클라이언트 역할을 하며 정보를 요청합니다. 서버는 데이터를 저장하고 있다가 요청에 맞는 정보를 응답합니다. 지금 보고 있는 페이지도 서버에 저장된 내용을 브라우저가 요청해 받아온 결과입니다.
-
HTTP(HyperText Transfer Protocol): 클라이언트와 서버가 대화할 때 사용하는 통신 규약입니다. 브라우저가 페이지를 요청하고 서버가 응답할 때 이 약속을 따릅니다. 예를 들어 주소창에
https://www.example.com을 입력하면, 브라우저는www.example.com의 자원을 요청합니다.https는 HTTP 요청·응답을 보안 연결로 주고받는 방식입니다. -
URL(Uniform Resource Locator): 웹상의 특정 자원(웹 페이지, 이미지, 동영상 등)의 위치를 나타내는 주소를 URL이라고 합니다. 여러분이 웹 브라우저 주소창에 입력하는 모든 주소가 바로 URL입니다. URL은 마치 우리가 원하는 책을 찾기 위해 도서관의 책꽂이 번호와 제목을 아는 것과 유사합니다. URL을 통해 클라이언트는 서버에게 내가 원하는 정보가 어디에 있는지를 정확하게 알려줄 수 있습니다.
-
HTML, CSS, JavaScript: 웹 페이지를 구성하는 세 가지 핵심 언어입니다.
- HTML(HyperText Markup Language): 웹 페이지의 뼈대를 만듭니다. 텍스트, 이미지, 링크 등 웹 페이지에 들어가는 내용들의 구조를 정의합니다. 마치 건물의 골조를 세우는 것과 같습니다.
- CSS(Cascading Style Sheets): 웹 페이지의 디자인을 담당합니다. 색상, 글꼴, 레이아웃 등 웹 페이지를 시각적으로 아름답게 꾸미는 역할을 합니다. 잘 지어진 건물에 아름다운 페인트와 장식을 더하는 것에 비유할 수 있습니다.
- JavaScript: 웹 페이지에 동적인 기능을 부여합니다. 버튼을 클릭했을 때 특정 동작을 수행하거나, 애니메이션 효과를 주는 등 사용자와 상호작용할 수 있는 기능을 만듭니다. 건물에 움직이는 엘리베이터나 자동문 같은 기능을 추가하는 것이라고 생각할 수 있습니다.
이러한 요소들이 복합적으로 작용하여 우리가 웹을 원활하게 이용할 수 있도록 돕습니다.
웹사이트의 첫 문서를 요청하면 서버는 보통 HTML을 응답합니다. 브라우저가 그 HTML을 읽다가 별도 CSS·JavaScript·이미지의 주소를 발견하면 필요한 자원을 추가로 요청할 수 있습니다. 한 페이지가 항상 하나의 응답에 모두 담겨 오는 것은 아닙니다.
그리고 여러분의 브라우저는 이 정보들을 해석하여 아름다운 웹 페이지를 화면에 그려내는 것입니다.
여기서 초보 개발자가 자주 하는 오해가 하나 있습니다.
브라우저가 알아서 다 해주니까 네트워크는 크게 중요하지 않다라고 생각하는 경우입니다.
하지만 같은 코드라도 지연 시간(latency), 캐시 정책, 응답 크기에 따라 체감 성능이 크게 달라집니다.
즉 웹 개발에서는 화면을 만드는 코드와 요청·응답 흐름을 함께 살펴봅니다. 앞의 그림에서 DNS는 www.example.com 같은 호스트 이름으로 연결할 IP 주소를 찾는 과정입니다. DOM은 브라우저가 HTML을 읽어 만든 요소 구조입니다. 이름과 주소를 찾는 일, 문서를 받는 일, 받은 문서로 화면을 만드는 일은 서로 다른 단계입니다. 캐시나 기존 연결을 재사용하면 일부 준비를 반복하지 않을 수도 있습니다.
예시
소개 페이지의 HTML은 열리는데 사진만 보이지 않는다고 가정해 봅시다. 브라우저가 사진 주소를 별도로 요청했지만 파일이 없어 404 응답을 받았다면, 먼저 이미지의 src와 파일 위치를 대조합니다. 반대로 사진 요청은 성공했는데 CSS가 사진을 숨겼다면 Elements에서 적용된 스타일을 확인합니다. 같은 “사진이 안 보임”도 근거에 따라 확인할 위치가 달라집니다.
스스로 설명해 보기
친구가 “HTML 요청이 성공했으니 화면의 모든 이미지도 반드시 정상이다”라고 말합니다. 앞의 요청 흐름을 이용해 이 주장이 성립하지 않는 이유를 두 문장으로 적고, 이미지 문제에서 추가로 확인할 증거 한 가지를 골라 보세요.
설명 확인
HTML 안의 이미지 주소는 별도의 요청으로 이어질 수 있으므로 문서 요청 성공만으로 이미지 요청 성공까지 알 수 없습니다. Network에서 해당 이미지의 URL·상태를 확인하거나, Elements에서 src와 숨김 스타일을 대조할 수 있습니다. 먼저 실제로 실패한 단계의 증거를 찾습니다.
기본 용어와 요청 흐름은 MDN의 웹 동작 설명에서 함께 확인할 수 있습니다.
웹은 어떻게 시작되었고 발전해 왔을까요?
오늘날 우리가 누리는 편리한 웹 환경은 결코 하루아침에 이루어진 것이 아닙니다.
수많은 사람들의 노력과 아이디어가 더해져 현재의 모습으로 발전해 왔습니다.
웹의 역사를 간략하게 살펴보는 것은 웹 개발의 흐름을 이해하고, 미래를 예측하는 데 중요한 통찰력을 제공할 것입니다.
-
웹의 탄생 (1989년, 팀 버너스리): 웹의 기원은 스위스 제네바에 위치한 유럽 입자 물리 연구소(CERN)의 팀 버너스리(Tim Berners-Lee) 박사에게서 찾을 수 있습니다. 그는 연구원들 간의 정보 공유의 어려움을 해결하고자, 하이퍼텍스트(Hypertext) 개념을 기반으로 하는 정보 공유 시스템을 제안했습니다. 이것이 바로 월드 와이드 웹의 시초입니다. 그는 최초의 웹 브라우저와 웹 서버를 개발하며 웹의 기반을 다졌습니다.
-
웹의 대중화 (1990년대 중반): 1993년 모자이크(Mosaic)가 등장하고, 1990년대 중반 넷스케이프(Netscape) 등 그래픽 기반의 웹 브라우저가 확산되면서 웹은 폭발적인 성장을 시작했습니다. 이전에는 텍스트 기반의 정보 공유가 주를 이루었다면, 이제는 이미지와 다양한 미디어를 웹에서 쉽게 접할 수 있게 되면서 일반 대중에게도 웹이 급속도로 확산되기 시작했습니다.
-
웹 2.0 시대의 도래 (2000년대 초반): 2000년대 초반에는 웹 2.0이라는 개념이 등장했습니다. 이는 단순히 정보를 읽는 것을 넘어, 사용자들이 직접 정보를 생성하고 공유하며 참여하는 웹의 시대를 의미합니다. 블로그, 위키, 소셜 미디어 플랫폼(페이스북, 유튜브 등)의 등장이 대표적인 예시입니다. 이 시기부터 웹은 단순히 정보를 소비하는 공간이 아니라, 사용자들이 서로 소통하고 협력하는 상호작용적인 공간으로 진화했습니다.
-
모바일 웹과 반응형 웹 (2000년대 후반 ~ 현재): 스마트폰의 등장과 함께 웹은 또 한 번의 큰 변화를 맞이합니다. 이제 사람들은 데스크톱 컴퓨터뿐만 아니라 스마트폰과 태블릿을 통해서도 웹에 접속하기 시작했습니다. 이에 따라 다양한 크기의 화면에서 웹 페이지가 최적으로 보일 수 있도록 반응형 웹 디자인과 같은 기술들이 중요해졌습니다. 또한, 웹 애플리케이션의 발전으로 인해 웹 브라우저만으로도 복잡한 기능을 수행하는 서비스들을 이용할 수 있게 되었습니다.
-
현재와 미래의 웹: 오늘날의 웹은 인공지능, 빅데이터, 블록체인, 가상현실(VR) 및 증강현실(AR) 등 첨단 기술들과 융합하며 끊임없이 발전하고 있습니다. 웹은 이제 단순히 정보 검색의 도구를 넘어, 우리의 일상생활과 비즈니스, 문화 등 모든 영역에 깊숙이 관여하는 거대한 플랫폼으로 자리매김했습니다.
WEB EVOLUTION
개방적인 문서 공유에서 다양한 웹 앱으로 확장됐습니다
초기 구현과 자유 이용 공개가 확산의 바탕이 되었고, 표준·참여·모바일 기능이 함께 발전했습니다.
초기 사건의 연도 간격을 1년·3년·1년으로 표시했습니다. 각 해 안의 날짜 차이는 생략했습니다. 1993년 4월 30일의 CERN 자유 이용 공개와 같은 해 그래픽 브라우저 확산은 서로 다른 사건입니다.
2000년대 · 참여와 공유
블로그·위키·소셜 서비스에서 사용자가 직접 콘텐츠를 만들고 공유하는 흐름이 커졌습니다. 웹 2.0은 단일 버전 업그레이드가 아닙니다.
2000년대 후반부터 · 모바일
스마트폰·태블릿에서도 같은 콘텐츠를 이용하게 되면서 다양한 화면에 맞추는 반응형 설계가 중요해졌습니다.
오늘 · 애플리케이션 플랫폼
문서 읽기에 더해 통신·저장·미디어·상호작용을 제공하는 앱을 브라우저에서 실행합니다. 개방 표준과 기능 확장은 계속됩니다.
이처럼 웹은 문서 전송에서 애플리케이션 실행 환경으로 계속 확장되어 왔습니다.
이러한 변화의 흐름을 이해하면 브라우저, 서버, 네트워크, 표준의 역할을 더 정확히 구분할 수 있습니다.
다음 HTML, CSS, JavaScript 소개 절에서는 세 언어의 역할을 살펴봅니다. 그다음 개발 환경 설정 절에서 도구와 실습 폴더를 준비합니다.
다음 절 진입 전 실수 방지 포인트
웹 언어의 역할을 살펴보고 개발 환경을 준비할 때는 아래 항목을 함께 확인합니다.
- 운영체제별 명령어 차이를 문서에서 바로 확인할 수 있도록 사용 환경을 먼저 명시합니다.
- 브라우저 문제, 네트워크 문제, 서버 문제를 구분해 확인하는 기본 진단 순서를 메모합니다.
- 이후 장에서 나오는 도구 설치는 "기능 구현"보다 "요청-응답 재현 가능성"을 우선 기준으로 점검합니다.
앞의 요청 생명주기 다이어그램은 웹 페이지가 느리거나 열리지 않을 때 요청-응답 경계를 따라 원인을 좁히는 기준으로 활용할 수 있습니다.
웹 기초 학습 루틴 점검
입문 절에서는 범위를 넓히기보다 반복 가능한 루틴을 만드는 것이 효과적입니다.
- HTML/CSS/JS 학습 시간을 주 단위로 고정합니다.
- 개념 학습 후 바로 작은 페이지를 만들어 적용합니다.
- 모르는 용어는 정의와 예시를 함께 기록해 재학습 시간을 줄입니다.
웹의 작동 원리는 주소를 입력한 순간부터 DNS, HTTP, HTML 파싱, 렌더링까지 이어지는 한 번의 생명주기로 보면 선명합니다.