C-3: 웹이 동작하는 원리

안녕하세요, 홍순구 튜터입니다. CS 기초 아홉 번째 시간, 네트워크 파트의 마지막 시간이에요.

지난 세 시간 동안 우리는 네트워크의 조각들을 하나씩 손에 쥐었습니다. C-1에서는 네트워크를 계층으로 펼치고, TCP로 연결을 맺는 3-way handshake와 IP·포트 주소 체계를 배웠어요. C-2에서는 그 위에서 도는 HTTP의 요청·응답, 메서드, 상태 코드, 그리고 통신을 암호로 지키는 TLS 핸드셰이크까지 봤죠. 조각은 충분히 모였습니다. 그런데 한 가지, 아직 안 한 게 있어요. 이 조각들이 실제로 어떤 순서로 맞물려 돌아가는지는 따로따로 봤지 한 줄기로 꿰어본 적이 없습니다.

그래서 오늘은 흩어진 조각을 하나의 여정으로 잇습니다. 여러분이 브라우저 주소창에 www.instagram.com을 치고 엔터를 누른 그 한순간 — 화면에 사진이 뜨기까지 컴퓨터 안에서, 그리고 인터넷 너머에서 실제로 무슨 일들이 순서대로 일어나는가. 이게 오늘의 주제입니다.

이 질문은 우연히 고른 게 아니에요. "URL을 치면 무슨 일이 일어나나요?" 는 신입 개발자 기술 면접에서 가장 자주, 가장 깊게 묻는 단골 질문입니다. 면접관이 이 하나로 컴퓨터 구조·운영체제·네트워크를 한꺼번에 떠보거든요. DNS만 답하면 거기서 "그다음은요?"가 꼬리를 물고, 끝까지 막힘없이 풀어내는 사람과 중간에 멈추는 사람이 확연히 갈립니다. 오늘 그 전체 여정을 한 호흡에 정리해둡시다.

오늘 우리가 걸을 길은 이렇습니다.

   오늘의 여정 — 웹이 동작하는 원리

   ① 전체 여정 한눈에 — "URL 을 치면 일어나는 일" (최고 빈출)
   ② DNS — 주소를 IP 로 바꾸는 인터넷 전화번호부 (면접 빈출)
   ③ 연결을 맺는다 — TCP 3-way + TLS 핸드셰이크 (지난 시간 회수)
   ④ 요청과 응답 — 서버는 그동안 무엇을 하나
   ⑤ 렌더링 — 받은 HTML 이 화면이 되기까지
   ⑥ 서버는 한 대가 아니다 — 로드밸런싱·CDN·캐싱 (면접 빈출)
   ⑦ REST API — 웹 API 를 설계하는 약속 (면접 빈출)
   ⑧ 웹소켓 한 입 — HTTP 가 못 하는 양방향

①에서 전체 여정의 큰 그림을 통째로 잡고, ②~⑤에서 그 여정을 단계별로 깊이 파고듭니다(주소 찾기 → 연결 → 요청·응답 → 화면 그리기). 그다음 ⑥에서 "사실 서버는 한 대가 아니다"로 시야를 넓히고, ⑦~⑧에서 그 위에서 앱이 대화하는 두 방식(REST와 웹소켓)을 봅니다.

💡 오늘 수업의 핵심 — "URL을 치면, DNS로 IP를 찾고 → TCP·TLS로 연결을 맺고 → HTTP로 요청·응답을 주고받고 → 받은 HTML을 브라우저가 렌더링한다. 실제 서비스는 로드밸런서·CDN·캐시로 수많은 서버에 흩어져 있고, 그 위에서 앱은 REST(요청-응답)나 웹소켓(양방향)으로 대화한다" 🎯

🎯 학습 목표

• "URL을 치면 일어나는 일" 전체 여정(DNS → TCP → TLS → HTTP → 서버 처리 → 응답 → 렌더링)을 한 호흡에 설명하고, 각 단계가 지난 시간 배운 어느 조각인지 짚어냅니다.
• DNS가 도메인을 IP로 바꾸는 계층 구조(루트·TLD·권한 서버)와 재귀 질의를 이해하고, 로드밸런싱·CDN·캐싱이 왜 필요한지 개념으로 설명합니다(깊은 운영은 인프라 과목의 몫).
• REST API(자원·메서드·무상태)가 웹 API를 설계하는 약속임을 알고, HTTP의 한계를 넘는 웹소켓의 양방향 통신이 언제 필요한지 구분합니다.

Step 1: "전체 여정 한눈에 — 'URL을 치면 일어나는 일'"

면접에서 "URL을 치면 무슨 일이 일어나나요?"를 받으면, 잘하는 사람은 먼저 전체 골격을 한 호흡에 던지고 그다음 면접관이 파고드는 단계를 깊이 설명합니다. 그래서 우리도 똑같이 갑니다. 오늘 배울 모든 것을 일단 한 장의 지도로 통째로 보고, Step 2부터 한 칸씩 확대할게요.

여러분이 주소창에 www.instagram.com/p/abc를 치고 엔터를 누르면, 대략 이런 순서로 일이 벌어집니다.

   URL 을 치면 일어나는 일 — 한 페이지가 뜨기까지

   ① 주소창에 URL 입력
        │  www.instagram.com/p/abc → 무슨 프로토콜·도메인·경로인지 분해
        ▼
   ② DNS 조회               도메인 이름 → IP 주소 (Step 2)
        │
        ▼
   ③ TCP 3-way handshake    그 IP 의 서버와 연결 통로 열기 (Step 3)
        │
        ▼
   ④ TLS 핸드셰이크          https 면 암호 통로까지 얹기 (Step 3)
        │
        ▼
   ⑤ HTTP 요청 전송          "이 페이지(자원) 줘" (Step 4)
        │
        ▼
   ⑥ 서버 처리              라우팅 → 앱 로직 → DB 조회 → 응답 생성 (Step 4·6)
        │
        ▼
   ⑦ HTTP 응답 수신          HTML·CSS·JS·이미지가 돌아옴 (Step 4)
        │
        ▼
   ⑧ 브라우저 렌더링         글자 덩어리(HTML) → 눈에 보이는 화면 (Step 5)

이 여덟 단계가 오늘의 전부예요. 하나씩 한 줄로만 풀어볼게요. ① 브라우저는 먼저 입력한 주소를 분해합니다 — https라는 프로토콜, www.instagram.com이라는 도메인, /p/abc라는 경로로요. ② 도메인은 사람이 읽는 이름일 뿐이고 실제 통신은 숫자 IP로 하니까, DNS에게 "이 도메인의 IP가 뭐야?"를 물어 IP를 받아옵니다. ③ IP를 알았으니 그 서버와 TCP 3-way handshake로 연결 통로를 엽니다(지난 C-1에서 배운 그 세 번 인사예요). ④ https라면 그 위에 TLS 핸드셰이크로 암호 통로까지 얹어요(C-2에서 배운 그 과정이죠). ⑤ 이제 안전한 통로로 HTTP 요청을 보냅니다("이 페이지 줘"). ⑥ 서버는 요청을 받아 내부에서 처리하고(필요하면 데이터베이스도 뒤져), ⑦ 결과를 HTTP 응답으로 돌려줍니다. ⑧ 브라우저는 받은 HTML을 해석해 화면으로 그려냅니다.

지금은 각 단계를 "아, 이런 게 순서대로 있구나" 정도로만 머리에 담으면 충분해요. 중요한 건 이 여덟 칸의 순서입니다. 순서만 외워둬도 면접에서 절반은 먹고 들어가요. Step 2부터 이 칸들을 하나씩 열어 안을 들여다보겠습니다.

🎯 면접에서는 이렇게 답하세요

"주소창에 URL을 치면, 먼저 브라우저가 주소를 프로토콜·도메인·경로로 분해합니다. 그다음 DNS로 도메인을 IP 주소로 바꾸고, 그 IP의 서버와 TCP 3-way handshake로 연결을 맺어요. HTTPS라면 그 위에 TLS 핸드셰이크로 암호화 통로를 추가하고요. 이제 HTTP 요청을 보내면 서버가 라우팅·로직·DB 조회를 거쳐 HTTP 응답을 돌려주고, 브라우저가 받은 HTML을 파싱해 화면으로 렌더링합니다. 한마디로 DNS → TCP → TLS → HTTP 요청·응답 → 렌더링의 순서예요."

Step 2: "DNS — 주소를 IP로 바꾸는 인터넷 전화번호부"

여정의 첫 실제 통신은 DNS(Domain Name System, 도메인 이름 체계)입니다. 왜 이게 필요한지부터 잡을게요. 우리는 www.instagram.com 같은 이름을 기억하지만, 정작 컴퓨터끼리의 통신은 C-1에서 배운 IP 주소(예: 142.250.x.x 같은 숫자)로 이뤄집니다. 사람은 숫자 수십 개를 외우기 어렵고, 컴퓨터는 이름으로 길을 못 찾아요. 그 사이를 번역해주는 게 DNS입니다.

비유하면 전화번호부예요. 우리는 "재훈이에게 전화해야지"라고 이름으로 생각하지만, 실제로 전화기가 거는 건 번호죠. 전화번호부가 이름을 번호로 바꿔주듯, DNS는 도메인 이름을 IP 주소로 바꿔줍니다. 그래서 DNS를 흔히 "인터넷의 전화번호부"라고 불러요.

그런데 전 세계 도메인이 수십억 개입니다. 이걸 전화번호부 한 권에 다 담아 한 곳에서 관리하면, 그 한 곳이 멈추는 순간 인터넷 전체가 멈추고, 너무 느려서 감당도 안 돼요. 그래서 DNS는 계층 구조로, 책임을 위에서 아래로 나눠 갖습니다. 도메인을 점(.)으로 끊어 오른쪽부터 좁혀 가며 찾아요.

   DNS 계층 구조 — 위에서 아래로 좁혀 가며 IP 를 찾는다

   브라우저: "www.instagram.com 의 IP 가 뭐죠?"
        │
        ▼
   [ 재귀 리졸버 ]   나 대신 끝까지 물어봐 주는 대리인 (보통 통신사·공용 DNS)
        │
        ├─▶ [ 루트 서버 (.) ]        "com 은 저쪽 TLD 서버한테 물어봐"
        │
        ├─▶ [ TLD 서버 (.com) ]      "instagram.com 은 저쪽 권한 서버한테"
        │
        └─▶ [ 권한 서버 ]            "instagram.com 의 IP 는 142.250.x.x 야"
        │
        ▼
   IP 주소를 받아 브라우저에 전달 (그리고 한동안 기억 = 캐시)

흐름을 따라가 볼게요. 브라우저는 직접 전 세계를 헤매지 않고, 재귀 리졸버(recursive resolver)라는 대리인에게 질문을 통째로 맡깁니다. 보통 통신사가 운영하거나 8.8.8.8 같은 공용 DNS 서버죠. 이 대리인이 나 대신 계층을 타고 다니며 답을 찾아옵니다. 먼저 맨 위 루트 서버에게 묻습니다. 루트는 IP를 직접 모르지만 ".com을 담당하는 TLD 서버(Top-Level Domain, 최상위 도메인)는 저기야"라고 알려줘요. 그 TLD 서버에게 다시 물으면 "instagram.com을 책임지는 권한 서버(authoritative server)는 저기"라고 안내합니다. 마지막으로 그 권한 서버가 비로소 실제 IP 주소를 내놓아요. 대리인은 이 IP를 브라우저에게 돌려줍니다.

핵심은 두 가지예요. 첫째, 아무도 전부를 알지 않고 각자 자기 단계만 책임진다 — 루트는 TLD가 어디인지만, TLD는 권한 서버가 어디인지만 압니다. 이렇게 나눠 가져야 수십억 도메인을 감당할 수 있어요. 둘째, 한 번 찾은 답은 캐시됩니다. 각 단계가 결과를 일정 시간(TTL, Time To Live) 동안 기억해뒀다가 재사용해요. 그래서 자주 가는 사이트는 DNS 조회를 거의 건너뜁니다(Step 1의 질문 답이 여기서 완성되죠).

🎯 면접에서는 이렇게 답하세요

"DNS는 사람이 읽는 도메인 이름을 컴퓨터가 통신에 쓰는 IP 주소로 바꿔주는, '인터넷의 전화번호부'입니다. 전 세계 도메인이 너무 많아 한 곳에서 관리할 수 없어서 계층 구조로 나뉘어 있어요. 브라우저의 질문을 받은 재귀 리졸버가 루트 → TLD(.com) → 권한 서버 순으로 도메인을 오른쪽부터 좁혀 가며 물어 최종 IP를 찾아옵니다. 각 단계는 자기 책임 범위만 알고, 한 번 찾은 결과는 TTL 동안 캐시해 다음 조회를 빠르게 합니다."

Step 3: "연결을 맺는다 — TCP 3-way + TLS 핸드셰이크"

DNS로 IP를 알아냈으니, 이제 그 서버와 연결을 맺을 차례예요. 여기서 지난 두 시간에 배운 조각 둘이 한 여정으로 합류합니다. C-1의 TCP 3-way handshake(통로 열기)와 C-2의 TLS 핸드셰이크(암호 통로 얹기)예요. 둘은 따로 배웠지만, 실제 HTTPS 통신에서는 위아래로 포개져 차례로 일어납니다.

먼저 TCP 3-way handshake입니다. HTTP는 한 글자도 틀리면 안 되는 통신이라 신뢰성을 보장하는 TCP 위에서 돈다고 했죠(C-2). 그 TCP는 데이터를 보내기 전에 "우리 연결할 준비됐지?"를 세 번 인사로 확인합니다. 그게 끝나면 데이터가 안전하게 오갈 통로가 열려요. 여기에 더해 https라면, 그 통로 위에 TLS 핸드셰이크로 암호 통로를 한 겹 더 얹습니다. 인증서로 상대가 진짜인지 확인하고, 비대칭키로 대칭키를 합의한 뒤, 그 빠른 대칭키로 본 통신을 암호화하는 과정이었죠(C-2). 순서가 중요해요 — TCP가 먼저(통로), TLS가 그 위에(암호) 입니다.

   TCP 로 통로를 열고(3-way), 그 위에 TLS 로 암호 통로를 얹는다

     Client                                          Server
     │                                            │
     │─────────────────── SYN ───────────────────▶│   연결할까요?
     │◀──────────────── SYN + ACK ────────────────│   좋아요, 그쪽도 준비됐죠?
     │─────────────────── ACK ───────────────────▶│   준비 끝 — 여기서 TCP 통로 완성
     │                                            │
     │─────────────── ClientHello ───────────────▶│   암호화 시작, 인증서 주세요
     │◀──────── Certificate + KeyExchange ────────│   인증서 확인 + 대칭키 합의
     │──────────────── Finished ─────────────────▶│   대칭키 확정 — 암호 통로 완성
     │                                            │

위쪽 세 줄(SYN → SYN+ACK → ACK)이 TCP 3-way handshake고, 아래 세 줄이 TLS 핸드셰이크예요. 둘 다 끝나야 비로소 안전하게 암호화된 통로가 완성됩니다. 그제야 그 위로 진짜 데이터, 즉 HTTP 요청이 오갈 수 있어요(Step 4).

눈치챘겠지만, 연결 한 번 맺는 데 인사가 꽤 많죠. TCP에 세 번, TLS에 또 몇 번. 그래서 연결 수립에는 시간(왕복)이 든다는 게 중요한 포인트예요. 이 비용을 줄이려고 HTTP는 keep-alive로 연결을 재활용하고, HTTP/2는 한 연결로 여러 요청을 멀티플렉싱하고, HTTP/3는 아예 더 가벼운 QUIC로 갈아탔다는 게 — 바로 지난 시간 C-2 마지막에 본 진화의 이유입니다.

🎯 면접에서는 이렇게 답하세요

"IP를 알아내면 그 서버와 먼저 연결을 맺습니다. HTTP는 신뢰성이 필요해 TCP 위에서 돌기 때문에, TCP 3-way handshake(SYN → SYN+ACK → ACK)로 데이터를 보낼 통로를 먼저 열어요. HTTPS라면 그 위에 TLS 핸드셰이크를 추가해서, 인증서로 상대를 확인하고 대칭키를 합의한 암호화 통로를 얹습니다. 즉 TCP 통로 → TLS 암호 통로 순서로 포개져요. 이 과정에 왕복이 여러 번 들어서 연결 수립 비용이 있고, 그래서 keep-alive나 HTTP/2·3 같은 최적화가 나온 겁니다."

Step 4: "요청과 응답 — 서버는 그동안 무엇을 하나"

암호화된 통로가 열렸으니, 드디어 HTTP 요청을 보냅니다. C-2에서 배운 그 메시지예요 — GET /p/abc HTTP/1.1 같은 시작줄에 헤더가 붙은 글자 덩어리죠. 이 요청이 서버에 도착하면, 그동안 서버 안에서는 무슨 일이 벌어질까요? 우리가 클라이언트 쪽만 보다 보니 서버는 "요청 넣으면 답 나오는 까만 상자"처럼 느껴지는데, 그 상자 안을 한 겹 열어볼게요.

   요청 한 건이 서버 안에서 거치는 길

   [ HTTP 요청 도착 ]   GET /p/abc
        │
        ▼  라우팅 — 이 요청은 어느 코드가 처리? (/p/abc → 게시물 핸들러)
        │
        ▼  애플리케이션 로직 — 로그인 됐나? 권한 있나? 비즈니스 규칙 처리
        │
        ▼  데이터베이스 조회 — 게시물·작성자·좋아요 수를 꺼내 옴 (다음 카테고리 D 의 주인공)
        │
        ▼  응답 생성 — 꺼낸 데이터를 HTML 또는 JSON 으로 빚어
        │
   [ HTTP 응답 반환 ]   200 OK + 본문

순서대로 보면, 요청이 도착하면 서버는 먼저 라우팅을 합니다. "/p/abc라는 경로의 요청은 어느 코드가 맡지?"를 정하는 단계예요. 그다음 그 코드(애플리케이션 로직)가 실제 일을 처리합니다 — 로그인 여부와 권한을 확인하고, 필요한 규칙을 적용하죠. 거의 항상 여기서 데이터베이스를 조회합니다. 게시물 내용, 작성자, 좋아요 수 같은 진짜 데이터는 서버 코드가 아니라 데이터베이스에 저장돼 있으니까요. 꺼내온 데이터를 HTML이나 JSON 같은 형태로 빚어서, 마지막에 상태 코드(200·404 등, C-2)와 함께 HTTP 응답으로 돌려줍니다.

여기서 잠깐 멈춰볼게요. 방금 "데이터베이스를 조회한다"고 했죠. 그 데이터베이스가 정확히 뭐고, 어떻게 데이터를 안전하게(트랜잭션) 그리고 빠르게(인덱스) 다루는지는 바로 다음 카테고리 D의 주인공입니다. 오늘은 "서버 처리의 한복판에 DB 조회가 있다"는 것만 짚고 넘어갈게요. 면접에서 "이 API가 느려요, 어디부터 보겠어요?"를 물으면, 바로 이 그림 — 네트워크 왕복인지, DB 조회인지, 응답 생성인지 — 을 떠올려 가설을 세우는 게 시작입니다.

🎯 면접에서는 이렇게 답하세요

"요청이 서버에 도착하면, 먼저 라우팅으로 어느 코드가 이 요청을 처리할지 정합니다. 그 코드가 애플리케이션 로직(인증·권한·비즈니스 규칙)을 실행하고, 대부분 그 안에서 데이터베이스를 조회해 필요한 데이터를 꺼냅니다. 마지막으로 그 데이터를 HTML이나 JSON으로 응답을 생성해 상태 코드와 함께 돌려줘요. 그래서 'API가 느리다'는 문제를 만나면 네트워크 왕복·DB 조회·응답 생성 중 어디가 병목인지 단계별로 의심하는 게 출발점입니다."

Step 5: "렌더링 — 받은 HTML이 화면이 되기까지"

서버가 응답으로 HTML을 돌려줬어요. 그런데 HTML은 결국 <div>...</div> 같은 글자 덩어리입니다. 이게 어떻게 우리 눈에 보이는 사진과 버튼이 될까요? 그 마지막 변환을 렌더링(rendering, 화면에 그리기)이라고 하고, 브라우저가 담당합니다. 여정의 마지막 칸이에요.

브라우저는 받은 글자 덩어리를 다음 단계로 가공합니다.

   받은 HTML 이 화면이 되기까지 (브라우저 안에서)

   HTML 문서  ──파싱──▶  DOM 트리      문서의 구조 (요소들의 부모-자식 관계)
   CSS 문서   ──파싱──▶  CSSOM 트리     스타일 규칙 (무엇을 어떻게 꾸밀지)
                          │
                    둘을  │  합쳐서
                          ▼
                     Render Tree       실제로 화면에 그릴 것만 추린 트리
                          │
                          ▼
                       Layout           각 요소의 위치·크기를 계산 (어디에 얼마나)
                          │
                          ▼
                       Paint            계산된 대로 픽셀을 칠해 화면에 표시

순서를 따라가 볼게요. 브라우저는 HTML을 파싱(parsing, 해석)해서 DOM 트리를 만듭니다. 문서가 어떤 요소들로 어떻게 중첩돼 있는지의 구조예요. 동시에 CSS를 파싱해 CSSOM 트리를 만드는데, 이건 "어떤 요소를 무슨 색·크기로 꾸밀지"의 스타일 규칙이죠. 이 둘(구조 + 스타일)을 합쳐 렌더 트리를 만듭니다. 화면에 실제로 그려질 것만 추린 트리예요(예: display:none인 요소는 여기서 빠져요). 그다음 레이아웃 단계에서 각 요소가 화면 어디에, 얼마만 한 크기로 놓일지를 계산하고, 마지막 페인트 단계에서 그 계산대로 픽셀을 칠해 비로소 화면에 나타납니다.

한 가지 더. 페이지 안에 이미지·CSS·JS 파일 링크가 있으면, 브라우저는 그걸 받으려고 여정을 또 돕니다(Step 1~4를 그 파일에 대해 다시!). 그래서 한 페이지를 여는 데 실제로는 수십 번의 요청이 오가요. 또 자바스크립트가 나중에 DOM을 바꾸면 레이아웃·페인트를 다시 하는데(리플로우·리페인트), 이게 잦으면 화면이 버벅입니다. 다만 렌더링을 빠르게 하는 최적화의 깊은 부분은 웹 과목(html-css-js 등)에서 본격적으로 다뤄요. 여기선 "받은 HTML이 DOM → 렌더 트리 → 레이아웃 → 페인트를 거쳐 화면이 된다"는 큰 흐름이면 충분합니다.

🎯 면접에서는 이렇게 답하세요

"브라우저는 받은 HTML을 파싱해 DOM 트리(문서 구조)를, CSS를 파싱해 CSSOM 트리(스타일)를 만들고, 둘을 합쳐 화면에 그릴 것만 추린 렌더 트리를 구성합니다. 그다음 각 요소의 위치·크기를 계산하는 레이아웃, 픽셀을 칠하는 페인트를 거쳐 화면에 나타나요. 이 과정을 흔히 Critical Rendering Path라고 부릅니다. 페이지 안의 이미지·CSS·JS는 각각 또 요청해서 받아오고, 자바스크립트가 DOM을 바꾸면 레이아웃·페인트가 다시 일어나(리플로우·리페인트) 성능에 영향을 줍니다."

Step 6: "서버는 한 대가 아니다 — 로드밸런싱·CDN·캐싱"

지금까지 우리는 "브라우저 하나가 서버 한 대와 대화한다"는 그림으로 여정을 그렸어요. 깔끔하지만, 현실은 다릅니다. 인스타그램에 동시 접속하는 사람이 수억 명인데, 서버 한 대가 그걸 다 받아낼 수 있을까요? 절대 못 합니다. 그래서 실제 서비스는 수많은 서버에 일을 흩뿌려 놓아요. 이 Step에서는 그 흩뿌림을 가능하게 하는 세 장치 — 로드밸런싱·CDN·캐싱 — 을 개념만 잡습니다. (깊은 운영은 인프라 과목의 영역이에요.)

먼저 로드밸런서(load balancer, 부하 분산기)입니다. 똑같은 코드를 돌리는 서버 여러 대 앞에 분배기를 하나 세우고, 들어오는 요청을 그 뒤의 서버들에 골고루 나눠줘요.

   한 대로 못 받으니, 분배기 뒤에 똑같은 서버를 여러 대

   Client ──▶ Load Balancer ──┬──▶ [ Server 1 ]
                              ├──▶ [ Server 2 ]
                              └──▶ [ Server 3 ]

   · 분배 방식: 라운드로빈(번갈아) · 최소 연결 수 등
   · 헬스체크: 죽은 서버는 분배에서 빼고 살아있는 서버로만
   · 무상태(C-2)라 어느 서버가 받아도 결과가 같다 ← 그래서 확장이 쉽다

분배 방식은 라운드로빈(번갈아 한 대씩)이나 "지금 가장 한가한 서버에게" 같은 규칙을 써요. 그리고 헬스체크로 죽은 서버는 분배 대상에서 빼버립니다. 여기서 지난 시간 배운 무상태(stateless, C-2)가 빛을 발해요 — HTTP가 무상태라 서버가 손님을 기억하지 않으니, 1번 요청은 Server 1이, 2번 요청은 Server 3이 받아도 아무 문제가 없습니다. "기억하지 않음"이 "아무 서버나 받아도 됨"을 만들고, 그게 곧 수평 확장(서버를 늘려 감당하기)의 힘이에요. 참고로 로드밸런서가 IP·포트만 보고 빠르게 분배하면 L4, URL·헤더 같은 내용까지 보고 똑똑하게 분배하면 L7이라고 부릅니다(L4/L7 운영의 깊은 부분은 인프라 과목에서 다뤄요).

두 번째는 CDN(Content Delivery Network, 콘텐츠 전송망)입니다. 서울 사용자가 미국에 있는 서버까지 매번 갔다 오면 거리가 멀어 느려요. 그래서 로고·이미지·CSS 같은 정적 콘텐츠(Step 4에서 본 그것)의 복사본을 전 세계 곳곳의 엣지 서버에 미리 뿌려둡니다. 사용자는 자기와 가장 가까운 엣지에서 받아 빠르고, 원본 서버(오리진)는 부담을 던 거죠. 세 번째 캐싱은 이 모든 단계에 깔린 "한 번 가져온 건 기억해두고 재사용"이라는 아이디어예요. 브라우저 캐시 → CDN 캐시 → 서버 앞단 캐시(예: 메모리 캐시) → 데이터베이스 순으로 여러 겹으로 쌓여, 뒤로 갈수록 느리고 비싼 곳까지 안 가도 되게 막아줍니다. A-2에서 본 "자주 쓰는 데이터를 가까운 빠른 곳에 둔다"는 캐시의 정신이, 컴퓨터 한 대를 넘어 인터넷 규모로 똑같이 반복되는 거예요.

🎯 면접에서는 이렇게 답하세요

"로드밸런서는 똑같은 서버 여러 대 앞에서 요청을 골고루 분배하는 장치예요. 라운드로빈 같은 규칙으로 나누고, 헬스체크로 죽은 서버를 빼며, IP·포트만 보면 L4, URL·헤더까지 보면 L7입니다. HTTP가 무상태라 어느 서버가 받아도 되니 이런 수평 확장이 가능해요. CDN은 정적 콘텐츠를 사용자 가까운 엣지 서버에 복사해 지연을 줄이고 원본 부하를 더는 장치고, 캐싱은 브라우저·CDN·서버·DB로 이어지는 여러 겹에서 '한 번 가져온 건 재사용'으로 느린 뒷단까지 안 가게 막는 공통 원리입니다."

Step 7: "REST API — 웹 API를 설계하는 약속"

이제 여정에서 한 걸음 물러나, 그 위에서 앱들이 데이터를 주고받는 방식을 봅니다. 브라우저와 서버, 혹은 서버와 서버가 HTTP로 대화할 때 — 무작정 아무렇게나 주소를 정하면 서로 혼란스럽겠죠. 그래서 "HTTP를 이렇게 쓰자"는 널리 합의된 약속이 생겼는데, 그게 REST(Representational State Transfer)입니다. 이 약속대로 만든 창구를 REST API라고 불러요.

REST의 핵심은 세 가지예요. 첫째, 세상의 모든 것을 자원(resource)으로 보고 주소(URI)로 표현합니다. 둘째, 그 자원에 무엇을 할지는 HTTP 메서드로 밝혀요(C-2에서 배운 그 메서드들이죠). 셋째, 통신은 무상태(C-2)입니다. 표로 보면 한눈에 들어와요.

보이는 패턴이 있죠. 주소는 "무엇"(자원)을, 메서드는 "어떻게"(행위)를 나타냅니다. /posts/42라는 주소는 "42번 게시물"이라는 대상만 가리키고, 그걸 조회할지 지울지는 GET·DELETE 같은 메서드가 정해요. 그래서 좋아요를 누르는 건 POST /posts/42/likes처럼 표현합니다("42번 게시물의 좋아요를 하나 생성"이죠). 이렇게 자원과 행위를 깔끔하게 나눈 설계를 RESTful 하다고 말해요. 그리고 각 요청은 무상태라 그 자체로 완결돼야 합니다 — 필요한 정보(인증 토큰 등)를 매 요청에 담아 보내고, 서버는 이전 요청을 기억하지 않아요. 바로 이 무상태 덕분에 Step 6의 로드밸런서가 아무 서버에나 요청을 던질 수 있는 거고요.

REST는 지금도 웹 API의 가장 흔한 스타일이지만, 유일한 정답은 아니에요. 자원 중심이 안 맞는 곳도 있고, 더 유연한 방식(GraphQL 등)이나 곧 볼 양방향 방식(웹소켓)을 쓰기도 합니다. 실무 API 설계의 깊은 디테일은 백엔드·웹 과목에서 다루고, 여기선 "자원을 주소로, 행위를 메서드로, 무상태로"라는 REST의 골격이면 면접에 충분해요.

🎯 면접에서는 이렇게 답하세요

"REST는 HTTP를 이용해 웹 API를 설계하는 약속이에요. 핵심은 셋입니다. 자원을 URI로 표현하고(/posts/42), 그 자원에 할 행위는 HTTP 메서드로 밝히며(GET 조회·POST 생성·PUT/PATCH 수정·DELETE 삭제), 통신은 무상태로 합니다. 즉 주소는 '무엇'을, 메서드는 '어떻게'를 나타내요. 이 원칙을 잘 지킨 설계를 RESTful 하다고 하고, 무상태이기 때문에 로드밸런서로 여러 서버에 자유롭게 분산할 수 있습니다. 다만 REST가 유일한 정답은 아니고, GraphQL이나 웹소켓 같은 다른 선택지도 있어요."

Step 8: "웹소켓 한 입 — HTTP가 못 하는 양방향"

마지막으로 HTTP의 근본적인 한계 하나와, 그걸 푸는 웹소켓을 가볍게 한 입 봅니다. C-2에서 배운 HTTP의 규칙을 떠올려보세요 — 항상 클라이언트가 먼저 묻고, 서버가 답한다였죠. 서버는 절대 먼저 말을 걸 수 없어요. 평소엔 이게 문제가 안 되는데, 딱 한 종류의 상황에서 곤란해집니다. 서버에서 일어난 일을 클라이언트에게 곧바로 알려야 할 때예요.

예를 들어 실시간 채팅을 생각해봐요. 상대가 메시지를 보내면 내 화면에 즉시 떠야 하는데, HTTP는 서버가 먼저 못 보내니 방법이 마땅찮아요. 그래서 옛날엔 클라이언트가 "새 메시지 있어요? …없어요? 지금은요?"를 1초마다 계속 물어봤어요(폴링, polling). 답이 대부분 "없음"인데도 계속 묻느라 낭비가 크죠. 이 문제를 제대로 푸는 게 웹소켓(WebSocket)입니다.

   HTTP 요청-응답  vs  웹소켓 양방향

   [HTTP]    Client ──질문──▶ Server      한 번 묻고
             Client ◀──답변── Server      한 번 답하면 끝. 서버가 먼저 못 보냄.

   [폴링]    Client ──있어?──▶ Server     "없음"인데도
             Client ──지금은?▶ Server     계속 물어봐야 함 (낭비)

   [웹소켓]  Client ◀══════▶ Server       한 번 연결하면 통로가 계속 열려,
                                          양쪽 다 아무 때나 먼저 보낼 수 있음

웹소켓은 처음엔 평범한 HTTP 요청으로 시작해서 "이 연결을 웹소켓으로 바꾸자"고 업그레이드(upgrade)한 뒤, 그때부터는 양방향으로 계속 열린 통로를 유지합니다. 그래서 서버에 새 메시지가 도착하면 묻지 않아도 서버가 먼저 내 화면에 밀어줄 수 있어요. 실시간 채팅, 알림, 라이브 댓글, 온라인 게임처럼 서버가 능동적으로, 즉시 알려야 하는 곳에 딱 맞습니다. 반대로 그냥 페이지를 조회하거나 데이터를 한 번 가져오는 일은 굳이 통로를 계속 열어둘 필요가 없으니 REST(요청-응답)가 더 낫고요. "양방향 실시간이면 웹소켓, 단방향 조회면 REST"가 고르는 기준이에요. 깊은 구현은 백엔드·웹 과목에서 다루니, 오늘은 "HTTP가 못 하는 양방향을 웹소켓이 푼다"는 한 입이면 됩니다.

🎯 면접에서는 이렇게 답하세요

"HTTP는 항상 클라이언트가 먼저 요청하고 서버가 응답하는 단방향 구조라, 서버가 먼저 말을 걸 수 없어요. 그래서 실시간 채팅·알림처럼 서버가 즉시 알려야 하는 경우엔 예전엔 클라이언트가 계속 물어보는 폴링을 썼는데 낭비가 큽니다. 웹소켓은 HTTP로 시작해 연결을 업그레이드한 뒤 양방향으로 계속 열린 통로를 유지해서, 서버도 아무 때나 먼저 데이터를 보낼 수 있어요. 그래서 실시간 양방향이 필요하면 웹소켓, 단순 조회면 REST를 씁니다."

마무리

오늘 배운 핵심 세 가지

🎯 하나, "URL을 치면 일어나는 일"의 전체 여정을 한 줄기로 꿰었습니다. 주소를 분해하고 → DNS로 도메인을 IP로 바꾸고 → TCP 3-way handshake로 통로를 열고 → TLS 핸드셰이크로 암호 통로를 얹고 → HTTP 요청을 보내면 → 서버가 라우팅·로직·DB 조회로 처리해 → HTTP 응답을 돌려주고 → 브라우저가 렌더링해 화면을 그립니다. 지난 시간 따로 배운 3-way handshake·TLS·HTTP가 여기서 하나의 순서로 합류했어요.

🎯 둘, 그 여정을 단계별로 깊이 봤습니다. DNS는 도메인을 IP로 바꾸는 계층적 전화번호부(루트 → TLD → 권한 서버, 재귀 질의)고, 렌더링은 HTML·CSS를 DOM·CSSOM으로 파싱해 렌더 트리 → 레이아웃 → 페인트로 화면을 그리는 과정이에요. 그리고 현실의 서비스는 서버 한 대가 아니라 로드밸런서(부하 분산)·CDN(거리 단축)·캐싱(재사용)으로 수많은 서버에 흩어져 있고, 무상태이기에 그 분산이 가능했습니다.

🎯 셋, 그 위에서 앱이 대화하는 두 방식을 잡았어요. REST는 "자원은 주소(URI)로, 행위는 메서드로, 통신은 무상태로"라는 웹 API 설계 약속이고, 웹소켓은 HTTP가 못 하는 양방향 실시간을 위해 연결을 계속 열어두는 방식입니다. 단방향 조회면 REST, 양방향 실시간이면 웹소켓 — 이 기준으로 고릅니다.

다음 시간 예고

이걸로 네트워크 카테고리(C-1~C-3)가 마무리됐어요. 계층과 TCP/UDP(C-1), HTTP와 HTTPS(C-2), 그리고 오늘 그 전부를 꿴 웹의 동작 원리까지 — 이제 "내가 친 요청이 어떻게 서버에 닿고 화면에 뜨나"를 한 호흡에 설명할 수 있게 됐습니다.

그런데 오늘 Step 4에서 슬쩍 미뤄둔 게 하나 있었죠. 서버가 요청을 처리할 때 거의 항상 데이터베이스를 조회한다고 했어요. 그 데이터베이스가 정확히 무엇이고, 어떻게 데이터를 안전하게(트랜잭션·ACID) 그리고 빠르게(인덱스) 다루는지 — 다음 시간(D-1)에는 바로 이 면접에 나오는 데이터베이스로 넘어갑니다. "트랜잭션이 뭔가요", "인덱스는 왜 조회를 빠르게 하나요", "SQL과 NoSQL은 언제 무엇을 쓰나요" 같은, 네트워크만큼이나 단골인 질문들을 원리부터 잡을 거예요. "이 API가 왜 느려요?"라는 물음의 답을 한 칸 더 깊이 파고드는 시간이 됩니다. 다음 시간에 만나요.

과제

[기초] URL 여정을 직접 그려보기

연필과 종이만 있으면 됩니다. 오늘 배운 전체 순서를 손으로 한 번 정리해봐요.

1. https://www.example.com/photos/7을 주소창에 치고 엔터를 눌렀다고 합시다. 화면에 페이지가 뜨기까지 일어나는 일을 순서대로 여덟 단계로 적어보세요. 각 단계를 한 줄로만 설명하면 됩니다(DNS·TCP·TLS·HTTP 요청·서버 처리·응답·렌더링이 들어가야 해요).
2. 위 여덟 단계 중, 지난 두 시간(C-1·C-2)에 이미 배운 단계가 어느 것인지 짚고, 각각 C-1에서 배운 건지 C-2에서 배운 건지 표시해보세요.
3. (선택) 브라우저 개발자 도구의 Network 탭을 열고 아무 사이트나 새로고침해보세요. 한 페이지를 여는 데 요청이 몇 개나 오가는지 세어보고, 왜 하나가 아니라 여러 개인지 한 줄로 설명해보세요(힌트: Step 5).

[응용] 시나리오마다 어떤 장치가 일하는지 판단하기

아래 상황에서 오늘 배운 장치(DNS·로드밸런서·CDN·캐시) 중 무엇이 관련되는지 고르고, 한 줄씩 이유를 설명해보세요.

1. 어떤 사이트를 두 번째로 방문했더니 첫 방문보다 훨씬 빨리 떴습니다. 이걸 빠르게 만든 장치들을 떠올려보고, 각각 무엇을 건너뛰거나 재사용한 건지 설명해보세요.
2. 서울과 뉴욕에 있는 두 사용자가 같은 로고 이미지를 받았는데, 둘 다 빨랐습니다. 어떻게 둘 다 가까운 곳에서 받았을지, 어떤 장치 덕분인지 설명해보세요.
3. 한 서버가 갑자기 죽었는데도 사용자들은 아무 문제 없이 서비스를 계속 썼습니다. 이게 가능하려면 어떤 장치가 있어야 하고, HTTP의 어떤 성질(C-2)이 이걸 가능하게 하는지 연결해 설명해보세요.

[심화] "URL을 치면 일어나는 일" 면접 답변 만들기

오늘 배운 전체를 엮어, 면접 최고 빈출 질문에 대한 자기만의 답변을 직접 써보는 과제입니다.

1. "URL을 치면 무슨 일이 일어나나요?"에 대한 답변을, DNS → TCP → TLS → HTTP 요청 → 서버 처리 → 응답 → 렌더링 순서로 한 호흡에 말하듯 정리해보세요(소리 내어 한 번 말해보면 더 좋아요).
2. 면접관이 파고들 꼬리 질문에 대비해보세요. "DNS는 구체적으로 어떻게 IP를 찾나요?"에 대한 답을 루트·TLD·권한 서버·재귀 리졸버를 써서 두세 문장으로 준비하고, "서버가 응답을 보낸 뒤 브라우저는 뭘 하나요?"에 대한 답을 렌더링 과정(DOM·CSSOM·렌더 트리·레이아웃·페인트)으로 준비하세요.
3. (선택) "실제 서비스는 서버 한 대로 이걸 다 하나요?"라는 질문이 들어오면, 로드밸런서·CDN·캐싱을 끌어와 "서버는 한 대가 아니다"를 설명하는 답을 한 단락으로 준비해보세요. 무상태(C-2)가 왜 이 확장을 가능하게 하는지도 함께 엮으면 좋습니다.

생각해볼 주제

1. 왜 DNS는 한곳에서 관리하지 않고 계층으로 쪼갰을까?

전 세계 도메인-IP 짝을 거대한 표 하나에 담아 한 기관이 관리하면, 구조가 훨씬 단순할 것 같습니다. 찾을 때 한 군데만 물어보면 되니까요. 그런데 DNS는 굳이 루트·TLD·권한 서버로 책임을 잘게 나눠 가졌어요. 만약 그 중앙 표 하나가 멈추면 어떤 일이 벌어질지, 그리고 전 세계에서 1초에 수백만 번 쏟아지는 조회를 한 곳이 감당할 수 있을지 떠올려보세요. "한곳에 모으는 단순함"과 "여러 곳에 나누는 견고함·확장성" 사이의 트레이드오프를, A·B 카테고리에서 본 다른 분산·계층 구조(메모리 계층, 캐시)와 같은 원리로 생각해보세요.

2. "기억하지 않는" 무상태가 어떻게 "무한히 늘리는" 확장의 힘이 될까?

언뜻 생각하면 서버가 손님을 기억하는 편이 더 똑똑하고 편리할 것 같습니다. 그런데 오늘 본 로드밸런서는 무상태이기 때문에 비로소 아무 서버에나 요청을 던질 수 있었어요. 만약 서버가 각자 손님을 기억한다면, 같은 손님의 다음 요청은 반드시 그 손님을 기억하는 서버로만 보내야 하고, 서버를 늘리거나 한 대가 죽었을 때 그 기억은 어떻게 될지 생각해보세요. "기억하지 않음"이라는 불편을 감수한 대가로 무엇을 얻었는지, 그리고 그럼에도 로그인 같은 상태를 유지해야 할 때 그 상태를 어디에 두면 좋을지(힌트: 서버 바깥의 공용 저장소)를 함께 저울에 올려보세요.

3. REST가 늘 정답일까 — 웹소켓·다른 방식은 언제 더 나을까?

REST는 웹 API의 가장 흔한 스타일이고, 깔끔한 자원 중심 설계라는 큰 장점이 있습니다. 하지만 오늘 본 실시간 채팅에서는 "클라이언트가 먼저 묻는다"는 REST의 전제가 오히려 걸림돌이 됐죠. 모든 통신을 REST 하나로 밀어붙이면 어떤 상황에서 불편해질지, 반대로 모든 걸 웹소켓으로 만들면 단순 조회에 무엇이 과한지 생각해보세요. "널리 쓰이는 표준"이 곧 "모든 상황의 정답"은 아니라는 점을, 통신의 성격(단방향 조회냐, 양방향 실시간이냐)에 따라 도구를 고르는 관점에서 풀어보세요.