브라우저에 주소를 입력하면 어떻게 웹사이트 화면이 그려질까?

"브라우저 주소창에 뭔가 입력하면 웹사이트가 나오는데, 어떻게 동작할까요? 그 과정을 아는대로 전부 설명해주세요"

입사 면접에서 이런 질문을 받았던 적이 있습니다. 정말 대답하기 막막한 질문이라는 생각이 스치는 찰나에, 그래도 잘 대답해야겠다는 생각에 어떻게든 아는 것을 설명했습니다. 나름 막힘 없이 설명했지만 중간에 끊고 면접관이 재차 물어본 질문에 당황하여 대답을 정확하게 하지 못했습니다. 그 질문의 정답은 3-Way Handshake였는데, 왜 이게 생각이 안났지 싶으면서도 면접에서 떨어진 이후로 계속해서 기억에 남는 질문입니다.

그리고 이걸 다시 블로그에 정리해야겠다는 생각이 들었습니다. 정리하는 하는 이유는 숙제처럼 생각했던 문제 복기를 지금이라도 해보고, 이후에도 면접자 혹은 면접관으로서 이와 비슷한 상황에 잘 대답하기 위해서입니다. 특히 이번에는 쉽게 설명하는 것에 초점을 맞춰보려고 합니다. 어떻게 동작하는지 아무것도 모르는 사람에게 이해시킨다는 마음으로 설명해보겠습니다.

웹사이트 검색 과정

먼저 웹사이트 검색 과정을 봅시다. 과정은 아래와 크게 다르지 않을겁니다.

1. 컴퓨터(핸드폰)를 킨다
2. 브라우저를 실행한다
3. 브라우저 주소창에 google.com 입력한다
4. 엔터를 누른다
5. 조금 기다리면 구글 웹사이트가 출력된다
6. 웹사이트 내의 기능을 이용한다 (메일 확인, 구글 검색 등)

도메인에서 아이피로 치환

출처: https://whois.icann.org/en/dns-and-whois-how-it-works

먼저 컴퓨터 혹은 핸드폰을 키고 브라우저를 실행한 상태라고 하겠습니다. 브라우저 주소창에 google.com 값을 입력하는데, 이를 도메인 네임(웹 주소)이라고 부릅니다.

나의 요청이 인터넷 통신을 거쳐 서버까지 도달하기 위해서는 도메인이 아이피라는 형태로 변환되어야 하는데요, 변환을 수행해주는 것이 DNS(Domain Name Server) 서버입니다. 즉, 우리는 항상 구글이나 네이버같은 서버와 통신하기 이전에 DNS 서버를 먼저 거치고 아이피를 알아낸다는 뜻입니다.

정상적인 상황이라면 DNS를 통해 구글 서버의 아이피 값을 알아내는데 성공했을 것입니다.

목적지 찾아가기 (라우팅)

출처: https://www.cloudflare.com/ko-kr/learning/network-layer/what-is-routing/

이제 내 컴퓨터가 인터넷 너머에 존재하는 구글 서버와 통신하려면 실제 서버의 위치까지 내 통신 신호가 도달해야합니다. 내 컴퓨터의 통신 신호가 서버까지 찾아가는 과정을 라우팅이라고 부릅니다.

내가 서울에 있고 서버가 로스엔젤레스에 있다고 치면 그 사이에 통신 신호를 전파해줄 수 있는 수많은 장비들이 배치되어 있습니다. 이를라우터라고 부릅니다. 내 컴퓨터에서 발생한 통신 신호는 서울에 위치한 라우터를 거치고 중간 과정을 거쳐서 미국 로스엔젤레스에 있는 라우터까지 전달됩니다. 그리고 최종적으로 서버의 엣지에 해당하는 라우터에서 서버로 통신 신호를 전달하게 됩니다.

한 가지 중요한 사실은 하나의 라우터가 고장나더라도 다른 라우터를 통해 길을 우회할 수 있도록 복잡한 메쉬 형태로 구성되어 있다는 것입니다. 이런 특성 때문에 인터넷 통신에서는 같은 목적지라 해도 매번 도달하는 경로가 달라질 수 있습니다.

따라서 라우터가 다음 라우터로 신호를 전달할 때 어떤 경로를 선택 하느냐가 인터넷 통신 속도에 영향을 미치며, 최적의 방법으로 목적지까지 도달할 수 있는 길이 무엇인지 알아내는 방법이 중요해집니다. 이와 관련해 문제를 해결하기 위한 다양한 라우팅 알고리즘이 이미 구현되어 있습니다.

서버와 상호작용 하기 (HTTP 프로토콜)

라우팅을 통해 구글 서버와 성공적으로 통신했습니다. 이제 어떻게 서버와 내 브라우저(클라이언트)가 상호작용 하는지에 대해 알아야 합니다. 여기서 우리는 두 가지를 알아야 합니다. 바로 클라이언트-서버 모델과 HTTP 프로토콜입니다.

출처: https://developer.mozilla.org/ko/docs/Learn/Server-side/First_steps/Client-Server_overview

클라이언트-서버 모델은 거창한 것이 아닙니다. 이미 우리가 이해하고있는 서버와 이를 접속해서 서비스를 이용하는 우리들, 그리고 접속에 필요한 네트워크망의 관계를 생각하면 됩니다. 오히려 중요한 것은 HTTP 프로토콜을 통해 클라이언트-서버 모델을 구현한 것이 브라우저와 서버가 상호작용하는 방식이라는 것입니다.

웹페이지 화면을 그리기 위해서는 HTML, CSS, Javascript 같은 정보들을 서버로부터 받아야 합니다. (이게 무슨 역할을 하는지 여기서는 알 필요 없습니다) 브라우저는 이러한 리소스를 서버로부터 받고자 구글에 요청하게 되는데, 그 때 사용하는 것이 HTTP 요청입니다.

HTTP 요청은 위에서 알아본 라우팅 과정을 거쳐 구글 서버에 도달하고, 구글 서버는 HTTP 요청를 받아서 그에 대응하는 HTTP 응답을 보내고, 이 것이 라우팅을 통해 다시 클라이언트에 도달하게 되면 응답으로부터 HTML 정보를 읽어서 브라우저가 화면에 그려주는 것입니다.

그런데 우리가 HTTP 요청을 언제 했을까요? 사실 도메인 주소를 입력하는 행위 자체가 HTTP 요청을 생성한것과 똑같습니다.

요청 결과 그리기 (브라우저 렌더링)

서버로부터 HTTP 응답을 받았으면 이제 브라우저의 할 일만 남았습니다.

HTTP 응답에는 다양한 리소스가 포함되는데요, 그 중 화면을 그리는데 필요한 정보인 HTML, CSS, Javascript같은 리소스를 받았다면 이를 해석해서 적절하게 화면에 그려주는 역할을 합니다. 이런 과정을 렌더링이라고 부릅니다.

렌더링은 렌더링 엔진이라는 컴포넌트가 담당하는데요, 브라우저 종류에 따라 내장된 엔진이 각각 다르고 성능 또한 천차만별입니다. 심지어 같은 코드인데도 렌더링 엔진이 달라지면 해석이 달라져서 브라우저에 따라서 개발자의 의도와 다르게 동작할 수 있습니다. 이런 문제를 크로스 브라우저 이슈라고 이야기 하며, 이를 해결하기 위한 다양한 방법들을 적용하기도 합니다.