junn.dev

[ Web ] 호스팅과 DNS로 이해하는 웹사이트 동작 원리

호스팅과 DNS

호스팅(Hosting)

호스팅은 웹사이트를 구성하는 파일들을 인터넷에서 24시간 접근 가능한 서버에 저장하고 제공하는 서비스다.

우리가 만든 HTML, CSS, JS 파일은 결국 어딘가에 저장되어 있어야 하고, 누군가 URL로 접근했을 때 그 파일을 응답으로 내려줄 수 있어야 한다. 그 역할을 하는 것이 호스팅 서버다.

호스팅의 종류

공유 호스팅

여러 웹사이트가 하나의 서버 자원(CPU, 메모리 등)을 함께 사용하는 방식

  • 장점 : 비용이 매우 저렴하고 초보자도 쉽게 사용할 수 있다.

  • 단점 : 다른 사이트의 트래픽 급증 시 내 사이트도 느려질 수 있다.

  • 대표 서비스 : 카페24, 닷홈

  • 적합한 경우 : 개인 블로그, 간단한 웹사이트

VPS (Virtual Private Server: 가상 사설 서버) 호스팅

하나의 물리 서버를 가상으로 분리해 독립적인 서버처럼 사용하는 방식

  • 장점 : 다른 사용자와 자원을 분리하여 비교적 안정적이며, 서버 관리자 권한을 통해 자유롭게 설정할 수 있다.

  • 단점 : 서버 운영체제 설치, 보안 설정 등을 직접 관리해야 하므로 기술적 지식이 필요하다.

  • 대표 서비스 : AWS(EC2), DigitalOcean Droplet, Linode

  • 적합한 경우 : 백엔드 서버 운영, 중간 규모 서비스

전용 서버 호스팅

하나의 물리 서버를 특정 사용자 또는 기업이 단독으로 사용하는 방식이다.

  • 장점 : 서버 자원을 독점적으로 사용하여 성능과 안정성이 매우 뛰어나며, 모든 설정을 자유롭게 구성할 수 있다.

  • 단점 : 비용이 높고, 서버 운영 및 관리 부담이 크다.

  • 대표 서비스 : AWS(Dedicated Host), GCP, Azure

  • 적합한 경우 : 대규모 서비스, 트래픽 많은 플랫폼

클라우드 호스팅

여러 서버를 하나의 인프라처럼 사용하여 유연하게 확장 가능한 방식이다.

  • 장점 : 트래픽에 따라 자원을 유연하게 확장/축소 가능하다.

  • 단점 : 사용량에 따라 비용 예측이 어려울 수 있다.

  • 대표 서비스 : AWS, GCP, Azure

  • 적합한 경우 : 트래픽 변동이 큰 서비스, 스타트업

서버리스 호스팅

서버를 직접 관리하지 않고, 요청이 있을 때만 코드를 실행하는 방식이다.

  • 장점 : 서버 관리가 필요 없고, 사용자가 많아지면 서버가 자동으로 확장되어 늘어난다.

  • 단점 : 처음 실행 시 지연(콜드 스타트)이 발생할 수 있고, 실행 환경에 대한 제어가 제한적이다.

  • 대표 서비스 : Vercel, Netlify, AWS(Lambda)

  • 적합한 경우 : Next.js 프로젝트, 간단한 API 서버, 프론트엔드 중심 서비스

정적 호스팅

HTML, CSS, JS 같은 정적 파일을 서버에 올려서 그대로 제공하는 방식이다.

  • 장점 : 속도가 빠르고 비용이 저렴하며, 설정이 간단하다.

  • 단점 : 서버 로직이 없기 때문에 동적인 기능 구현이 제한된다.

  • 대표 서비스 : Vercel, Netlify, AWS(S3), GitHub Pages

  • 적합한 경우 : 포트폴리오 사이트, 블로그

프론트엔드 개발자 관점에서는 정적 호스팅이 가장 자주 접하게 되는 유형이다.

React, Next.js(SSG)의 경우 빌드 시 HTML, CSS, JS 같은 정적 파일이 생성되며, 이를 CDN 기반 정적 호스팅에 배포하는 것이 일반적이다.

Vercel이나 Netlify는 이러한 정적 파일을 CDN에 배포하여 제공하는 정적 호스팅 플랫폼이며, 단순한 파일 서버가 아닌 CDN 기반으로 동작한다.

CDN (Content Delivery Network)

콘텐츠를 여러 지역 서버에 분산, 캐싱하여 사용자에게 가장 가까운 위치에서 빠르게 제공하는 서버 네트워크다.

DNS(Domain Name System)

DNS는 사람이 읽을 수 있는 도메인 이름(example.com)을 컴퓨터가 이해할 수 있는 IP 주소(93.184.216.34)로 변환해주는 시스템이다.

인터넷의 모든 통신은 IP 주소를 기반으로 이루어지지만, 사람이 이를 직접 기억하기 어렵기 때문에 DNS가 사용된다.

DNS 계층 구조

DNS는 하나의 서버가 아니라 계층 구조로 이루어진 분산 시스템이다.

Root DNS (루트 네임서버)

DNS 계층 구조의 최상위에 위치한 서버이다.
요청받은 도메인의 확장자(TLD)를 보고 어떤 TLD 서버로 가야 할지 알려준다.

TLD DNS (최상위 네임서버)

.com, .net, .org, .dev, .kr 등도메인의 가장 뒷부분(확장자)을 관리하는 서버이다.
루터 서버로부터 요청을 이어받아, 해당 도메인이 등록된 권한 네임서버의 위치를 알려준다. 예를 들어 .com TLD 서버는 example.com가 어느 업체(Google, Cloudflare 등)의 네임서버를 쓰는지 알고 있다.

Authoritative DNS (권한 네임서버)

특정 도메인에 대한 최종 IP 주소 정보를 직접 가지고 있는 서버이다.
도메인 소유자가 실제로 IP 주소(A 레코드)나 별칭(CNAME)을 설정하는 곳이다. DNS 탐색의 최종 목적지이며, 여기서 브라우저에게 도메인의 실제 IP 주소(93.184.216.34)를 돌려받는다.

주요 DNS 레코드 타입

사용자의 요청 목적에 따라 도메인을 IP 주소, 별칭, 혹은 메일 서버 등과 연결해주는 데이터베이스 설정값이다.

A 레코드

도메인을 IPv4 주소에 연결

  • 예시 : example.com → 93.184.216.34

AAAA 레코드

도메인을 IPv6 주소에 연결

  • 예시 : example.com → 2606:2800:220:1:248:1893:25c8:1946

CNAME 레코드

도메인을 IP 주소가 아닌 또 다른 도메인 이름(별칭)으로 연결

  • 예시 : www.junn.dev → junn.dev

MX 레코드

해당 도메인으로 오는 이메일을 수신할 메일 서버를 지정

  • 예시 : junn.dev → aspmx.l.google.com

TXT 레코드

도메인 소유권 인증 및 이메일 보안 설정(SPF/DKIM) 등 외부 서비스와의 신뢰 구축을 위한 메타데이터를 기록

  • 예시 : google-site-verification=AbCdEfG12345...

DNS Cache와 TTL (Time To Live)

DNS 정보를 매번 루트 네임서버부터 권한 네임서버까지 찾아가서 물어보는 것은 비효율적이다. 이를 해결하기 위해, 한 번 조회한 IP 주소를 일정 기간 저장(Cache)해두고 이후 요청 시 빠르게 응답할 수 있도록 한다. 이때 캐시가 유지되는 시간을 TTL이라고 하며, TTL이 만료되면 다시 DNS 조회가 수행된다.

TTL이 길면 DNS 질의 횟수가 줄어들어 사이트 접속 속도는 빨라지지만, IP가 변경되었을 때 반영되는 시간은 오래 걸린다.

TTL이 짧으면 서버 이전이나 IP 변경 시 빠르게 반영되지만, DNS 요청이 증가하여 서버 부하가 늘어나고 접속 속도가 미세하게 느려질 수 있다.

웹사이트 동작 흐름

1단계 : URL 입력

사용자가 브라우저 주소창에 URL을 입력한다.

https://junn.dev

2단계 : DNS 조회

브라우저는 해당 도메인의 IP 주소를 찾기 위해 DNS 조회를 수행한다.

  1. 먼저 브라우저 및 OS에 캐시가 남아있는지 확인한다.

  2. 없으면 DNS 서버에 요청하여, Root → TLD → Authoritative DNS를 거쳐 IP 주소를 찾는다.

이 과정을 통해 실제 서버의 IP 주소를 알게 된다.

3단계 : 서버 연결

IP 주소를 알게되면, 브라우저는 서버와 연결을 시작한다.

  1. TCP 연결을 통해 서버와 통신 가능한 상태를 만든다.

  2. HTTPS인 경우 TLS 핸드셰이크를 통해 암호화된 연결을 수립한다.

즉, 데이터를 안전하게 주고받기 위한 준비 단계이다.

TCP (Transmission Control Protocol)

TCP는 신뢰성 있는 데이터 전송을 위해 연결을 기반으로 통신하는 프로토콜이다. 데이터를 주고받기 전에 3-way handshake를 통해 서로 연결 가능한 상태인지 확인한다.

TLS 핸드셰이크 (Transport Layer Security Handshake)

TLS 핸드셰이크는 클라이언트와 서버가 암호화 통신을 하기 위해 키를 교환하고 인증하는 과정이다. TCP 연결 이후 HTTPS 환경에서 추가로 수행되며, 안전한 데이터 전송을 가능하게 한다.

4단계 : HTTP 요청 전송

연결이 완료되면 브라우저는 서버에 HTTP 요청을 보낸다.

GET /index.html HTTP/1.1
Host: junn.dev
...

웹페이지 데이터를 요청하는 단계

5단계 : 서버 응답

서버는 요청을 처리한 후 HTML, CSS, JavaScript 등의 웹페이지를 구성하는 리소스를 응답으로 반환한다.

HTTP/1.1 200 OK
...
<!DOCTYPE html>
<html>...

정적 사이트는 미리 생성된 HTML을 반환하고 동적 사이트는 요청에 따라 데이터 생성 후 반환한다.

6단계 : 브라우저 렌더링

브라우저는 서버로부터 받은 데이터를 기반으로 화면을 그린다.

  1. HTML 파싱 → DOM 트리 생성

  2. CSS 파싱 → CSSOM 트리 생성

  3. DOM + CSSOM → 렌더 트리 생성

  4. 레이아웃 → 위치/크기 계산

  5. 페인트 → 픽셀 그리기

  6. 컴포지팅 → 레이어 합성

위의 과정을 거쳐 최종적으로 사용자가 보는 웹페이지가 완성된다.

← 목록으로 돌아가기