주소창에 URL을 입력하면 무슨 일이 일어날까?

주소를 입력하고 화면이 뜰 때까지 몇 초가 걸린다. 이 시간을 통째로 “서버가 느리다”고 말하기 쉽지만, 서버에 요청을 보내기 전에도 할 일이 있다. 주소를 찾고 연결해야 한다. 서버에서 문서를 받은 뒤에는 그 문서가 필요로 하는 파일을 더 가져오고 화면을 그린다.

브라우저(browser)는 웹 주소로 문서를 요청하고 받은 내용을 화면에 보여 주는 프로그램이다. 한 페이지가 늦게 뜨는 이유를 알려면 이 과정에서 어디까지 끝났고 어디서 기다리는지 봐야 한다. 아래에서는 처음 방문한 상품 페이지 한 곳을 따라가 본다. 숫자와 주소는 흐름을 설명하기 위한 예다.

주소를 나눠 읽는다

웹 주소(Uniform Resource Locator, URL)는 가져올 자원의 위치와 접근 방법을 담는다. 다음 주소를 보자.

https://shop.example.com/items/7?color=blue#reviews

https는 통신 방식, shop.example.com은 접속할 곳의 이름이다. /items/7은 상품 문서의 경로, color=blue는 요청에 덧붙인 조건이다. reviews는 문서 안에서 이동할 위치를 가리킨다. 브라우저는 서버 주소를 알아낼 때 호스트 이름을 조회한다. 서버에 문서를 요청할 때는 경로와 조건을 보낸다. #reviews 부분은 이 예에서 서버로 보내는 요청 경로에 넣지 않는다.

같은 URL을 다시 열더라도 매번 아래 단계를 처음부터 밟는 것은 아니다. 여기서는 브라우저에 저장된 응답과 다시 쓸 연결이 없다고 가정한다.

네트워크에 나가기 전에 저장된 응답을 확인한다

브라우저는 이미 받아둔 응답을 사용할 수 있는지 확인한다. 캐시(cache)는 이전에 받은 응답이나 조회 결과를 잠시 보관해 다시 쓰는 공간이다. 응답을 그대로 다시 쓸 수 있다면 서버까지 가지 않고 문서를 보여줄 수 있다. 유효 기간이 지났더라도 서버에 변경 여부만 물어보고, 내용이 같으면 본문을 다시 내려받지 않을 수도 있다.

웹페이지가 서비스 워커(service worker)라는 백그라운드 스크립트를 등록했다면 그 스크립트가 요청을 받아 저장된 내용을 돌려줄 수도 있다. 그래서 브라우저 개발자 도구에서 문서 요청이 보이지 않거나 저장된 응답으로 표시된다면, 원본 서버가 그때 새 문서를 만들어 보냈다고 가정하면 안 된다.

첫 접속과 재방문을 비교할 때도 이 차이를 기억해야 한다. 재방문이 빨라진 이유가 서버 처리의 변화인지 저장된 응답 때문인지 구분하지 않으면 엉뚱한 곳을 고치게 된다.

이름을 주소로 바꾸고 연결한다

도메인 이름 시스템(Domain Name System, DNS)은 shop.example.com 같은 이름에 대응하는 인터넷 주소를 찾는다. 조회 결과가 브라우저나 운영체제에 남아 있으면 이전 값을 쓸 수도 있다. DNS가 알려주는 것은 연결을 시도할 주소다. 주소를 받았다고 그 서버가 응답한다는 뜻은 아니다.

이번 예에서는 전송 제어 프로토콜(Transmission Control Protocol, TCP)로 연결한다고 하자. TCP는 양쪽이 데이터를 순서대로 주고받을 연결을 만든다. https 주소에서는 전송 계층 보안(Transport Layer Security, TLS)으로 서버 인증서를 확인하고 암호화에 쓸 키를 정한다. 인증서가 요청한 호스트 이름과 맞지 않으면 TCP 연결이 됐더라도 안전한 웹 요청을 계속할 수 없다.

브라우저가 이전 연결을 다시 쓰면 새 연결 과정이 보이지 않을 수 있다. HTTP/3처럼 TCP가 아닌 전송 방식을 쓰는 경우도 있다. 따라서 모든 웹 요청이 DNS 조회, TCP 연결, TLS 확인을 매번 같은 순서와 시간으로 거친다고 보면 안 된다.

여기까지도 상품 문서 자체는 아직 요청하지 않았다. 이름을 못 찾는 오류와 인증서 오류가 모두 “페이지가 안 열린다”로 느껴져도, 실제로는 서로 다른 단계에서 멈춘 것이다.

문서 요청은 서버 안에서도 기다릴 수 있다

하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol, HTTP)은 브라우저가 무엇을 요청하고 서버가 무엇을 돌려주는지 정한다. 앞의 주소에서는 상품 7번을 가져오라는 GET /items/7?color=blue 요청을 보낼 수 있다. GET은 지정한 자원을 가져오는 요청 방법이다.

요청이 곧바로 상품 데이터를 읽는 프로그램에 닿는다는 보장은 없다. 사용자와 가까운 곳에서 콘텐츠를 전달하는 콘텐츠 전송 네트워크(Content Delivery Network, CDN)의 서버가 먼저 받을 수 있고, 앞단 프록시나 로드 밸런서를 더 지날 수도 있다. CDN에 저장된 상품 문서가 있으면 원본 서버까지 가지 않을 수 있다. 이번에는 저장된 문서가 없어 원본 서버로 넘어간다고 하자. 상품 조회 프로그램은 데이터를 보관하고 찾는 데이터베이스(database)를 읽어 응답을 만든다.

이때 브라우저에는 “서버 응답 기다림” 한 구간으로 보이는 시간 안에 앞단 대기, 프로그램 실행, 데이터베이스 조회, 응답이 돌아오는 네트워크 시간이 함께 들어갈 수 있다. 브라우저 화면만으로 데이터베이스가 느렸다고 단정할 수 없다. 서버 쪽 기록과 같은 요청을 가리키는 식별자를 맞춰 봐야 한다.

응답을 받아도 화면은 계속 만들어진다

서버가 성공 상태와 문서를 보냈다고 화면이 완성되는 것은 아니다. 하이퍼텍스트 마크업 언어(HyperText Markup Language, HTML)는 글과 이미지의 위치 같은 문서 구조를 표현한다. 브라우저는 HTML을 읽으면서 스타일 파일, 이미지, 글꼴, 스크립트가 더 필요하다는 사실을 발견하고 추가 요청을 보낸다.

캐스케이딩 스타일 시트(Cascading Style Sheets, CSS)는 화면의 모양과 배치를 정한다. 자바스크립트(JavaScript)는 브라우저에서 문서의 동작을 실행하는 언어다. 필요한 스타일 시트를 기다리거나 긴 자바스크립트 작업을 처리하는 동안 화면 표시가 늦어질 수 있다. 큰 이미지 하나만 늦게 도착해도 글은 보이는데 상품 사진은 비어 있을 수 있다.

HTTP 성공 응답을 받은 시각, 문서의 구문 분석이 끝난 시각, 이미지까지 다 들어온 시각, 사용자가 주요 내용을 본 시각은 같지 않다. 무엇이 늦다는 말인지 알려면 실제로 기다리는 화면 요소를 함께 봐야 한다.

1초가 걸렸다면 어느 구간이었을까?

다음은 단계를 읽기 쉽게 벌려놓은 가상의 시간표다. 실제 요청은 일부 작업이 겹쳐 진행되므로 이 숫자를 성능 기준으로 쓰면 안 된다.

0ms     주소 입력, 저장된 문서 없음
30ms    DNS 조회 완료
80ms    연결과 서버 확인 완료
400ms   상품 문서의 첫 응답 도착
500ms   상품 문서 받기 완료
900ms   필요한 스타일과 이미지가 준비되고 주요 내용 표시

주소 조회와 연결에 80ms가 들었고, 문서 요청 뒤 첫 응답을 받을 때까지 320ms가 더 걸렸다. 문서를 다 받은 뒤에도 주요 내용이 보이기까지 400ms가 걸렸다. 이 마지막 400ms가 전부 이미지 다운로드 시간이라는 뜻은 아니다. 다른 파일 요청과 브라우저 작업이 겹칠 수 있다.

브라우저 개발자 도구의 네트워크 화면에서 문서 요청을 고르고 시간 분석 항목을 보면 주소 조회, 연결, 응답 대기, 다운로드를 나눠 볼 수 있다. 이어서 이미지와 스크립트 요청의 시작·종료 시각을 확인한다. 문서가 빨리 도착했는데 화면이 늦게 반응한다면 성능 분석 화면에서 스크립트 실행과 화면 그리기도 봐야 한다.

같은 사이트를 다시 열면 시간표가 바뀐다. DNS 결과가 남아 있거나 기존 연결을 쓰고, 문서나 이미지를 저장된 응답으로 보여줄 수 있다. 두 결과를 비교할 때는 첫 접속인지 재방문인지, 개발자 도구에서 캐시 사용을 막아둔 것은 아닌지 함께 적어두면 원인을 찾기 쉽다.

멈춘 지점에 따라 확인할 곳도 다르다

주소 조회가 실패했다면 상품 조회 프로그램까지 요청이 가지 않았다. 연결은 됐는데 인증서가 맞지 않으면 TLS 설정과 접속한 호스트 이름을 본다. HTTP 오류 응답을 받았다면 그 응답을 만든 앞단이나 원본 서버의 기록을 확인한다. 문서는 정상적으로 받았는데 사진이 비어 있다면 사진 요청부터 따로 본다.

사용자 눈에는 모두 “페이지가 안 뜬다”로 보일 수 있다. 개발자 도구와 서버 기록에서 마지막으로 성공한 단계를 찾아야 다음에 확인할 곳이 정해진다.

참고 자료

• HTTP 요청과 응답의 의미: RFC 9110
• 브라우저의 문서 처리 규칙: HTML 표준
• Chrome 개발자 도구의 네트워크 시간 분석