브라우저에 google.com을 입력하면 어떤 일이 일어날까? - 2

아래 내용 중 1~3번에 대해 간략하게 요약해 작성하고 4, 5번에 대해 자세히 작성하겠다.

1~3번의 자세한 내용은 이전글에 작성했다.

 

0. 사용자가 google.com을 입력

1. 캐시 검사 : 해당 도메인에 대한 IP가 캐시에 있는지 검사한다.

2. DNS 조회 : 만약 캐시가 되어있지 않다면 DNS를 조회해 IP값을 조회한다.

3. TCP (및 TLS) 연결 설정 :  DNS를 통해 얻은 IP 주소로 TCP(+TLS) 연결을 시도한다.

4. HTTP 요청 및 응답

5. 브라우저의 페이지 렌더링

 

3번에서 TCP 연결이 완료되면, 이제 해당 IP를 통해 실제 요청을 보낼 차례이다.

실행 흐름대로 작성해야 해서 4번과 5번에 대해 함께 작성하고 이후 추가 설명을 덧붙이도록 하겠다.

---

4. HTTP 요청 및 응답

- 대부분의 서버는 요청을 직접 처리하지 않고, 먼저 NGINX나 Load Balancer(LB)와 같은 Reverse Proxy가 요청을 수신한 뒤, 내부 서버로 라우팅한다.
- 요청 경로에 따라 정적 파일, SSR 앱, API 요청 등으로 분기된다.
- 이 과정에서 브라우저는 HTML, CSS, JS 등 화면을 구성하는 데 필요한 리소스를 수신한다.

 

5. 브라우저의 페이지 렌더링

- 브라우저는 수신한 리소스를 바탕으로 HTML을 파싱하고, CSS를 적용하며 DOM을 구성한다.

- 이후 자바스크립트를 로딩 및 실행하고, 앱 초기화 작업을 수행한다.  
- 프론트엔드 앱은 초기 렌더링 이후 필요에 따라 비동기적으로 WAS에 API 요청을 보낸다. (fetch, axios 등 사용)
- WAS는 비즈니스 로직을 처리하며, DB나 외부 시스템과 연동하여 데이터를 조회한다.  
- 백엔드는 JSON 등으로 응답을 반환하고, 프론트는 이를 기반으로 화면을 동적으로 갱신한다.  

 

---

이제 위에서 사용한 용어들에 대해 하나씩 알아보자.

 

Reverse Proxy

클라이언트의 요청을 대신 처리하고, 내부 서버에 요청을 전달한 뒤 그 응답을 다시 클라이언트에게 반환하는 중간 서버

 

주요 기능

- 로드 밸런싱 : 트래픽 분산

- 캐싱

- SSL 연결: HTTPS 통신을 Reverse Proxy에서 종단 처리할 수 있으며, 이후 내부 서버와는 HTTP 또는 HTTPS로 통신

- 경로 기반 라우팅: 요청 URI 또는 Hostname에 따라 서로 다른 서버에 전달

  (ex. example.com의 경우 프론트 서버에게 example.com/api의 /api를 보고 api 서버에게 전달하는 방식으로 설정)

 

Reverse Proxy에 대해 찾다 보니 CDN이라는 용어가 나와서 이에 대해서도 작성해보겠다.

---

CDN(Content Delivery Network)

전 세계 여러 지역에 분산된 캐시 서버 네트워크를 통해 사용자에게 더 빠르고 안정적으로 정적 콘텐츠를 전달하는 시스템

 

필요성

 

- 사용자와 서버 간의 물리적 거리가 멀어질수록 응답 속도가 느려짐

- CDN은 콘텐츠를 사용자와 가까운 위치에 미리 복제(캐싱)해두고, 빠르게 응답함으로써 성능과 안정성을 높힘

 

 

 

캐싱 대상(대부분 정적 파일)

- HTML, CSS, JS

- 이미지 (PNG, JPG, SVG 등)

- 영상 스트리밍(MP4, HLS 등)

- 파일 다운로드(PDF, ZIP 등)

- 일부 CDN은 동적 컨텐츠 전달 가능

 

CloudFront를 활용한 프론트엔드 배포

업무를 하며 프론트엔드 개발자분이 CloudFront를 사용해 배포하는 것을 봤는데 CloudFront 역시 CDN을 사용하는것이라고 한다.

프론트엔드 배포 흐름에 대해 간략하게만 알아보자.

 

CloudFront를 활용한 프론트엔드 배포 흐름

프론트엔드 애플리케이션 빌드 시 아래와 같은 정적 리소스 생성

- index.html, main.js, styles.css ..

 

이러한 정적 리소스를 S3, EC2, 또는 기타 오리진 서버에 올려두고, CloudFront가 그 오리진을 콘텐츠 소스로 사용하게 구성한다고 한다.

 

자주 사용하는 구성은 아래와 같다고 한다.

- S3 + CloudFront

• S3에 빌드된 리소스 업로드
• CloudFront가 S3를 오리진으로 설정

- EC2 + CloudFront

• SSR 또는 인증 처리가 필요한 경우
• 프론트엔드 정적 파일을 EC2의 NGINX에서 서빙
• CloudFront가 EC2를 오리진으로 사용

 

CDN vs Reverse Proxy

- CDN은 정적 콘텐츠를 전 세계 엣지에 캐싱하여 빠르게 제공하는 데 중점
- Reverse Proxy는 내부 서비스와 통신을 중계하며, 라우팅, 인증, 부하 분산 등 애플리케이션 계층의 관문 역할 수행
- Cloudflare, CloudFront와 같은 CDN 서비스는 실제로 Reverse Proxy 역할도 함께 수행

---

WEB Server

정적 리소스(HTML, CSS, JS, 이미지 등)를 클라이언트에게 제공하는 서버

 

- 클라이언트 요청에 대해 파일을 찾아서 그대로 응답하는게 주 역할

- HTTP 프로토콜을 기반으로 작동하며, 일반적으로 빠르고 가볍게 동작

- 동적인 처리는 수행하지 않고, 필요한 경우 WAS나 CGI 등 외부 프로그램에 요청을 전달

 

 

WAS(Web Application Server)

비즈니스 로직을 실행하는 서버로, 주로 동적 요청을 처리하는 데 사용

 

 

- DB 질의, 로그인 처리, 게시판 글 작성 등과 같은 동적인 요청 처리

- 요청을 받아서 내부 로직을 실행하고, DB에서 값을 조회하거나 조작한 후 결과 반환

- 주로 Java(Spring Boot, Tomcat), Node.js, Python(FastAPI, Django), Ruby on Rails 환경에서 사용

 

 

이렇게 알아보다 보니 문득 궁금한 점이 생겼다.

Web Server는 브라우저 렌더링 전에만 사용되고, WAS는 렌더링 이후에만 사용될까?

둘 다 "렌더링 이전에도", "렌더링 이후에도" 사용될 수 있다.

 

 

- Web Server는 보통 HTML, CSS, JS 등 정적 리소스를 렌더링 이전에 제공

- WAS는 SSR일 경우 초기 HTML을 생성하므로 렌더링 이전에도 관여하고, 렌더링 이후 JS 실행 시 API 호출 대상이 되므로 이후에도 계속 사용

 

 

---

브라우저에 "google.com"을 입력하면 일어나는 일에 대해 작성해보았다.

이렇게 작성해도 아직 부족한 내용이 꽤 있겠지만, 그래도 한번 정리하니 어느정도 흐름이 머리속에 그려졌다고 생각한다.