웹페이지는 서버에서 날아오는 걸까?

인터넷 주소를 입력하면 브라우저가 서버를 찾아간다. 지금까지의 글에서 DNS와 라우터, TCP/IP와 HTTP, URL과 웹서버를 차례로 살펴본 이유도 결국 이 과정을 이해하기 위해서였다.

브라우저는 필요한 자료가 있는 곳을 찾아 요청을 보내고, 서버는 그 요청에 맞는 내용을 다시 돌려준다. 사용자는 그 결과를 화면으로 보게 된다.

겉으로 보면 과정은 단순하다. 주소를 입력하고 잠시 기다리면 웹페이지가 나타난다. 하지만 서버에서 사용자 화면까지 오는 과정을 조금만 안쪽에서 살펴보면 생각보다 여러 일이 이어진다.

우리가 보는 웹페이지도 서버 안에 완성된 그림 한 장으로 들어 있는 것은 아니다. 웹서버가 자료를 보내면 브라우저가 그것을 읽고 화면에 맞게 구성한다.

한줄 요약
웹페이지는 서버에 저장된 완성된 화면을 그대로 받아보는 것이 아니다. 서버가 보내준 여러 자료를 브라우저가 해석하고 조합하면서 우리가 보는 화면이 만들어진다.

서버에는 완성된 화면이 들어 있는 것이 아니다

사진 파일을 다른 사람에게 보내는 경우라면 이해하기 쉽다. 내가 가지고 있던 사진 한 장을 전송하면 상대방도 같은 파일을 받아 화면에 띄운다.

웹페이지도 처음에는 이와 비슷하게 생각하기 쉽다. 서버 안에 홈페이지 화면이 그대로 저장되어 있고, 사용자가 접속하면 그 화면을 통째로 보내주는 것처럼 느껴진다.

하지만 웹페이지는 하나의 이미지 파일처럼 움직이지 않는다.

기본적인 구조를 만드는 데에는 HTML이 사용된다. 제목과 문단의 위치, 이미지와 링크가 들어갈 자리처럼 웹문서의 뼈대가 HTML 안에 담긴다.

화면의 모양은 또 다른 자료가 맡는다. 글자의 크기나 간격, 배치와 여백은 CSS를 이용해 정할 수 있고, 버튼을 눌렀을 때 메뉴가 나타나거나 화면 일부가 바뀌는 기능에는 JavaScript가 사용되기도 한다.

사진과 아이콘 역시 별도의 파일로 불러오는 경우가 많다.

서버가 보내주는 것은 완성된 한 장의 화면이라기보다 화면을 만들기 위해 필요한 여러 재료에 가깝다.

그 재료를 받아 실제 화면으로 만드는 쪽이 브라우저다.

크롬이나 엣지는 인터넷에 접속하는 프로그램이면서 동시에 웹문서를 읽고 해석하는 프로그램이기도 하다. 서버에서 받은 HTML과 CSS, 이미지 같은 자료를 읽은 뒤 사용자가 볼 수 있도록 화면에 배치한다.

웹서버와 웹브라우저의 역할을 나눠 생각하면 이해하기 쉽다. 서버는 필요한 자료를 보내고, 브라우저는 받은 자료를 이용해 화면을 만든다.

웹페이지 하나에도 여러 요청이 이어진다

웹페이지 하나를 불러오는 과정은 생각보다 여러 번의 통신을 필요로 한다.

처음 서버에서 HTML을 받아왔다고 해서 필요한 자료가 모두 도착한 것은 아니다. HTML 안에는 화면에 사용할 이미지의 위치나 디자인에 필요한 CSS, 특정 기능을 실행하는 JavaScript와 같은 다른 파일에 대한 정보가 들어 있을 수 있다.

브라우저는 HTML을 읽으면서 추가로 필요한 자료가 있는지 확인한다. 필요한 파일이 있다면 다시 서버에 요청을 보내고 해당 자료를 받아온다.

사용자는 주소를 한 번 입력했을 뿐이지만, 그 뒤에서는 여러 요청과 응답이 이어질 수 있는 셈이다.

사진이 많은 페이지를 열었을 때 글은 먼저 나타나고 사진이 조금 늦게 표시되는 경우가 있다. 인터넷을 사용하다 보면 어렵지 않게 볼 수 있는 장면이다.

이런 현상도 웹페이지가 완성된 하나의 파일로 전달되는 것이 아니라는 점을 알고 나면 이해하기 쉬워진다.

브라우저는 먼저 도착한 자료부터 읽고 화면을 구성한다. 아직 도착하지 않은 이미지나 다른 파일이 있으면 기다렸다가 화면에 추가한다.

웹사이트의 속도도 이런 과정과 관련이 있다.

크기가 큰 이미지를 많이 사용하면 그만큼 받아야 할 데이터가 늘어난다. 외부에서 여러 파일을 불러오거나 서버의 응답 자체가 늦으면 페이지가 완전히 나타나는 데 시간이 더 필요할 수 있다.

사용자 입장에서는 화면이 늦게 뜨는 것만 보이기 때문에 흔히 서버가 느리다고 생각한다. 그러나 실제 원인은 서버뿐 아니라 네트워크, 이미지 크기, 프로그램 처리시간 등 여러 곳에 있을 수 있다.

앞에서 HTTP와 HTTPS를 살펴볼 때는 브라우저가 요청을 보내고 서버가 응답한다고 단순하게 설명하였다. 실제 웹페이지에서는 이런 요청과 응답이 한 번으로 끝나지 않는 경우가 많다.

사람마다 다른 화면은 어떻게 만들어질까

단순한 안내 페이지라면 서버에 있는 파일을 보내주는 방식으로도 충분할 수 있다.

은행이나 쇼핑몰처럼 사람마다 다른 내용을 보여주는 서비스에서는 상황이 조금 달라진다.

은행 홈페이지에 로그인하면 내 계좌와 거래내역이 나타난다. 다른 사람이 로그인하면 그 사람의 계좌가 보여야 한다.

쇼핑몰도 마찬가지다. 내가 장바구니에 담아둔 상품과 다른 사람이 담아둔 상품은 서로 다르다. 주문 내역과 배송상태도 사용자마다 다르게 나타난다.

이런 서비스를 회원 수만큼 서로 다른 웹페이지로 미리 만들어 놓는 방식은 현실적이지 않다.

회원이 백만 명이라면 백만 개의 화면을 별도로 만들어야 한다. 주문이 추가되거나 배송상태가 바뀔 때마다 해당 화면도 계속 수정해야 한다.

실제 웹서비스에서는 필요한 순간에 데이터를 찾아 그 결과를 화면에 보여주는 방식이 사용된다.

예를 들어 사용자가 주문 내역을 요청하면 먼저 누구의 요청인지 확인한다. 이후 해당 사용자의 주문 정보를 찾아 필요한 형태로 정리한 뒤 브라우저에 전달한다.

여기에서 중요한 것이 데이터를 저장하고 찾아내는 기능이다.

인터넷에서 다루는 정보가 적을 때는 파일 몇 개만으로도 관리할 수 있다. 하지만 회원과 상품, 주문, 결제, 배송정보처럼 데이터가 계속 쌓이기 시작하면 단순한 파일 저장만으로는 관리하기 어려워진다.

필요한 정보를 빠르게 찾고, 서로 관련된 자료를 연결하고, 여러 사용자가 동시에 접근하더라도 데이터가 뒤섞이지 않도록 관리할 수 있어야 한다.

이 역할을 담당하는 대표적인 수단이 데이터베이스이다.

지금까지는 정보가 목적지까지 어떻게 이동하는지를 주로 살펴보았다. 이제부터는 그 정보가 어디에 저장되고, 필요할 때 어떤 방식으로 다시 찾아지는지도 함께 보게 된다.

같은 사이트인데 기기마다 모습이 다른 이유

브라우저가 화면을 직접 구성한다는 사실을 알고 나면 같은 사이트가 기기마다 다르게 보이는 이유도 이해하기 쉬워진다.

컴퓨터에서 보던 사이트를 휴대전화로 열면 메뉴와 글, 사진의 위치가 달라지는 경우가 많다.

컴퓨터에서는 화면 위쪽에 길게 펼쳐져 있던 메뉴가 휴대전화에서는 작은 버튼 안으로 들어가기도 한다. 사진의 크기가 줄어들거나 한 줄에 나란히 있던 내용이 위아래로 배치되기도 한다.

내용은 같지만 화면을 사용하는 공간이 다르기 때문이다.

모든 웹사이트가 같은 방식으로 만들어지는 것은 아니지만, 화면 크기에 따라 배치를 조절하도록 설계된 사이트에서는 브라우저가 현재 기기의 조건에 맞게 내용을 표시한다.

서버가 컴퓨터용 화면과 휴대전화용 화면을 각각 한 장의 사진으로 만들어 보내는 것과는 다른 개념이다.

서버에서 받은 자료는 같더라도 브라우저가 화면의 폭과 크기를 고려해 배치를 달리할 수 있다.

이 때문에 웹페이지는 서버가 보내준 결과이면서 동시에 브라우저가 만들어낸 결과라고 볼 수 있다.

주소를 입력하고 몇 초를 기다리는 동안 브라우저는 서버에 요청을 보내고, 응답을 받고, 필요한 추가 자료를 가져온 뒤 화면을 구성한다.

평소에는 거의 느끼지 못하지만 웹페이지 하나를 보는 동안에도 여러 기술이 함께 움직이고 있다.

통신의 이야기는 이제 데이터의 이야기와 만난다

이번 블로그의 주제인 전쟁과 기술의 관점에서 보자면 지금까지의 이야기는 정보를 어떻게 더 멀리, 더 빠르게 전달할 것인가에서 시작하였다.

전령과 봉화의 시대에는 정보를 전달하려면 사람이 움직여야 했다. 전신은 사람의 이동과 정보의 이동을 처음으로 크게 분리하였고, 전화와 무선통신은 더 빠르고 자유로운 통신을 가능하게 하였다.

전쟁에서 다뤄야 할 정보가 늘어나면서 레이더와 컴퓨터가 등장하였고, 컴퓨터가 서로 연결되면서 ARPANET과 인터넷으로 이야기가 이어졌다.

이후 TCP/IP와 DNS, 라우터와 패킷을 살펴보았다. TCP와 UDP의 차이, 포트의 역할, HTTP와 HTTPS, URL과 웹서버까지 하나씩 따라왔다.

여기까지의 흐름은 대부분 정보가 이동하는 방법과 관련되어 있었다.

웹서버 안쪽을 조금 더 살펴보면 또 다른 문제가 나타난다.

보낼 정보가 있어야 하고, 그 정보가 어디에 있는지도 알아야 한다.

정보가 몇 개뿐이라면 찾는 일이 어렵지 않다. 하지만 수천만 명의 회원과 수많은 주문, 상품, 기록이 쌓이면 필요한 자료를 정확하게 찾아내는 일이 중요해진다.

은행은 많은 계좌 가운데 특정 사용자의 계좌를 찾아야 하고, 쇼핑몰은 수많은 주문 가운데 한 사람의 주문을 골라내야 한다.

군의 정보체계에서도 비슷한 문제가 생긴다. 통신망을 통해 많은 정보가 들어와도 필요한 자료를 제때 찾지 못하면 활용하기 어렵다.

반대로 데이터를 잘 저장해 두었더라도 필요한 부대나 사용자에게 적시에 전달하지 못하면 그 정보의 가치도 떨어진다.

결국 정보체계에서는 정보를 전달하는 기술과 정보를 저장하고 찾는 기술이 함께 움직여야 한다.

짧은 생각
인터넷을 따라가다 보면 처음에는 연결과 속도에 눈이 간다. 그런데 웹서버 안쪽으로 들어갈수록 중요한 것이 하나 더 보인다. 필요한 정보를 정확하게 찾아낼 수 있어야 빠른 통신도 의미가 있다. 통신과 데이터가 결국 한곳에서 만나는 이유도 여기에 있다고 생각한다.

지금까지는 정보가 지나가는 길을 따라왔다.

이제부터는 그 길을 따라 이동하던 정보가 어디에 쌓이고, 필요할 때 어떻게 다시 찾아지는지를 살펴볼 차례이다.

컴퓨터에는 파일을 저장할 수 있다. 그런데 은행이나 쇼핑몰 같은 서비스에서는 왜 굳이 데이터베이스를 사용하는 것일까?

정보가 몇 개일 때와 수백만 개로 늘어났을 때는 무엇이 달라질까?

다음 글에서는 파일 저장과 데이터베이스의 차이부터 살펴보려 한다. 지금까지 이어온 통신의 이야기가 데이터의 이야기로 넘어가는 첫 번째 지점이다.