1. 요청의 일생

이 그림 한 장이 이 덱 전체의 지도다

이 장에서 처음 나오는 말4개

DNSDomain Name System

도메인 이름(myapp.com)을 IP 주소로 바꿔 주는 전화번호부. 요청의 첫 단계는 항상 이것이다.

TLSTransport Layer Security

통신 암호화 프로토콜. 주소창의 자물쇠(https)가 이것이고, 옛 이름이 SSL이라 아직 그렇게도 부른다.

CDNContent Delivery Network

전 세계에 흩어진 캐시 서버망. 사용자와 가장 가까운 지점(엣지)이 대신 응답해서 빠르다.

오리진Origin Server

CDN 뒤에 있는 원본 서버. 캐시에 없는 것만 여기까지 온다 — 그래서 "얼마나 오리진까지 안 가게 하느냐"가 성능 설계의 핵심이 된다.

전체 경로 — 한 번에 보기

https://myapp.com/memos를 입력했을 때 일어나는 일:

여기 나오는 등장인물 — 브라우저 · CDN · 오리진 · DB — 이 웹의 전부다. 이후 모든 장은 이 그림의 어딘가를 확대한 것이다.

핵심

성능 질문은 전부 “이 요청은 어디까지 갔다 오는가”로 환원된다. 앞단 캐시에서 끝날수록 네트워크 구간과 서버 작업이 줄어드는 경우가 많다. 설계란 캐시 가능한 요청은 앞쪽에서 끝내고, 최신성·개인화가 필요한 요청은 뒤쪽 비용을 관리하는 일이다.

단계별로 — 무엇이 일어나는가

① DNS — 이름을 주소로

브라우저는 myapp.com이라는 이름만 안다. DNS가 이걸 IP 주소로 바꿔 준다. 요즘 서비스의 도메인을 조회하면 대부분 서비스 자체 서버가 아니라 CDN 업체(Cloudflare, Vercel 등)의 IP가 나온다 — 요청이 서비스의 서버가 아니라 CDN 엣지에 먼저 도착한다는 뜻이다.

② 연결 — TCP와 TLS

IP를 알았으니 연결을 연다. HTTP/1.1·2는 TCP 위에서 TLS를 협상하고, HTTP/3는 QUIC가 전송과 암호화 협상을 함께 다룬다. 왕복이 몇 번 필요해서 연결 자체에도 시간이 든다 — HTTP/2·HTTP/3가 줄이려는 게 바로 이 비용이지만, 이 덱에서는 “연결은 공짜가 아니다”만 기억하면 된다.

③~④ CDN — 가장 빠른 경로

CDN 엣지는 캐시를 먼저 본다. 이미지·JS·CSS 같은 정적 파일이나 미리 만들어 둔 HTML이면 오리진까지 가지 않고 즉시 응답한다. 이게 웹에서 가장 빠른 경로다.

응답 헤더에 이 판정이 기록된다 — x-vercel-cache: HIT(캐시에서 응답) / MISS(오리진까지 갔다 옴) 같은 헤더를 DevTools에서 직접 볼 수 있다.

⑤~⑦ 오리진과 DB — 가장 비싼 경로

캐시로 못 끝내는 요청 — 로그인한 사용자의 데이터, 방금 쓴 글 — 은 오리진 서버가 코드를 실행해서 만든다. 대개 DB까지 한 번 더 내려간다. 요청당 비용(시간·서버 자원·돈)이 가장 큰 경로라서, 백엔드 설계의 대부분은 이 구간을 줄이거나 빠르게 하는 이야기다.

⑧~⑨ 브라우저 — 받은 것을 화면으로

HTML을 받았다고 끝이 아니다. 브라우저는 HTML을 파싱하며 CSS·JS·이미지를 추가로 요청하고 (DNS 캐시와 기존 연결을 재사용하면서 필요한 구간을 다시 탄다), JS가 로드된 뒤에야 JS가 맡은 클릭·입력 같은 상호작용이 살아난다. “어디서 HTML을 만들고 언제 JS를 붙이는가”가 다음 장의 주제인 렌더링 전략이다.

응답에는 세 종류가 있다

한 페이지 안에서도 이 셋이 섞인다.

구분	무엇을 받나	누가 언제 만드나	예
정적 파일	미리 만들어진 HTML/JS/CSS/이미지	빌드 시점에 생성, CDN이 서빙	블로그 글, 랜딩 페이지
서버 렌더링	요청 순간에 만든 HTML	오리진이 요청마다 생성	로그인한 사용자의 대시보드
API 호출	JSON 데이터	서버가 생성, 브라우저 JS가 화면에 반영	무한 스크롤, 폼 제출

첫 화면은 서버 렌더링으로 받고 이후 상호작용은 API 호출로 처리하는 식의 조합이 일반적이다.

함정

“우리 서비스 느려요”라는 말은 진단이 아니다. 어느 구간이 느린지부터 갈라야 한다 — 첫 HTML이 늦나(서버·DB), 리소스가 늦나(번들 크기·CDN), 상호작용이 늦나(브라우저 JS). 구간이 다르면 처방이 완전히 다르다.

직접 확인하기

표로 외우지 말고 DevTools에서 눈으로 식별할 수 있어야 한다.

1. 아무 사이트나 열고 DevTools → Network 탭을 켠 채 새로고침한다

2. 첫 번째 HTML 응답을 클릭해 내용을 본다 — 내용이 차 있으면 서버 렌더링/정적, 거의 비어 있으면 브라우저 JS가 그리는 방식(다음 장의 CSR)이다

3. 이어지는 요청들을 구분해 본다 — CSS/JS/이미지(정적 파일)와 fetch/XHR(API 호출)

4. 응답 헤더에서 cache-control과 x-vercel-cache 같은 캐시 헤더를 찾는다 — 새로고침을 반복하며 MISS가 HIT으로 바뀌는 것을 본다

5. dig myapp.com(또는 dnschecker.org)으로 유명 서비스의 DNS를 조회한다 — CDN 업체의 IP가 나오는 것을 확인한다

1장 요약

• 웹의 등장인물은 넷 — 브라우저 · CDN 엣지 · 오리진 서버 · DB
• 성능 질문은 전부 “이 요청은 어디까지 갔다 오는가”로 환원된다
• 캐시에서 끝나는 요청이 가장 빠르고, DB까지 내려가는 요청이 가장 비싸다
• 응답은 세 종류 — 정적 파일 / 서버 렌더링 / API 호출 — 가 한 페이지에 섞인다
• Network 탭에서 이 구분을 눈으로 식별할 수 있어야 한다

2. 화면은 어디서 그려지는가CSR · SSR · SSG — 같은 화면을 만드는 세 갈래 길과 각각의 대가.