홈 / 학습 코스 / 웹은 어떻게 작동하는가

3부 · 대화의 규칙: HTTP

← 2부 | 목차 | 다음: 4부 · HTML 기초 →

지금 다루는 단계: ② 연결 + ③ 요청 + ⑤ 응답 — 클라이언트와 서버가 실제로 말을 주고받는 부분입니다.
flowchart LR
    U["주소 입력"]:::dim
    DNS["① DNS"]:::dim
    TCP["② 연결"]:::focus
    REQ["③ 요청"]:::focus
    SRV["④ 서버"]:::dim
    RES["⑤ 응답"]:::focus
    REN["⑥ 렌더링"]:::dim
    U --> DNS --> TCP --> REQ --> SRV --> RES --> REN

    classDef focus fill:#cfe8ff,stroke:#2b6cb0,color:#000,stroke-width:3px
    classDef dim fill:#f0f0f0,stroke:#bbb,color:#999

HTTP는 클라이언트와 서버의 공용어

2부에서 서버의 주소(IP)를 알아냈습니다. 이제 그 서버에게 "이 페이지 주세요"라고 말을 걸어야 합니다. 이때 쓰는 약속된 언어가 HTTP입니다.

HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 규약): 웹에서 클라이언트와 서버가 자료를 주고받기 위해 정한 대화 규칙. 'Protocol(프로토콜)'은 "이런 형식으로 말하자"는 약속이라는 뜻입니다.

핵심 성질 하나를 기억하세요. HTTP는 기본적으로 한 번 묻고 한 번 답하면 끝입니다. 서버는 여러분이 누구였는지 다음 요청 때 자동으로 기억하지 않습니다(이를 "상태가 없다 = stateless"라고 합니다). 로그인 상태 유지 같은 건 그래서 별도 장치(쿠키 등)로 처리합니다.

요청과 응답은 무엇으로 이루어지나

HTTP 대화는 요청(request) 한 통과 응답(response) 한 통으로 이뤄집니다. 각각은 사실 잘 짜인 편지입니다.

sequenceDiagram
    participant C as 클라이언트(브라우저)
    participant S as 서버
    C->>S: 요청 편지<br/>"GET /index.html 주세요"
    Note over S: 요청을 읽고<br/>해당 자료 준비
    S-->>C: 응답 편지<br/>"200 OK, 여기 HTML 있습니다"

요청 편지의 구성

HTTP
GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
  • 첫 줄: 무엇을(/index.html) 어떤 방식으로(GET) 원하는지.
  • 그 아래 줄들: 헤더(header) — 부가 정보입니다. "나는 어느 사이트를 원하고(Host)", "어떤 브라우저이며(User-Agent)", "HTML을 받고 싶다(Accept)" 같은 메모죠.

응답 편지의 구성

HTTP
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256

<!DOCTYPE html>
<html> ... </html>
  • 첫 줄: 상태 코드(200 OK) — 요청이 잘 됐는지 알려주는 숫자입니다.
  • 헤더들: 본문이 어떤 종류인지(Content-Type), 길이가 얼마인지(Content-Length) 등.
  • 빈 줄 다음의 본문(body): 진짜 알맹이. 여기 HTML이 담겨 옵니다.
비유: 요청은 "주문서", 응답은 "포장된 택배"입니다. 헤더는 택배 송장(보내는 이·내용물 종류·무게)이고, 본문은 상자 안 물건입니다.

메서드: "무엇을 하려는가"

요청 첫 줄의 GET 자리에 오는 단어를 메서드(method)라고 합니다. "서버에게 무엇을 시키려는지" 동사라고 보면 됩니다. 초보가 가장 자주 보는 둘만 확실히 알면 됩니다.

메서드뜻일상 비유
GET자료를 가져오기 (읽기)게시판 글을 읽기
POST자료를 보내기 (제출/생성)게시판에 글 올리기
PUT / PATCH기존 자료 수정글 고치기
DELETE자료 삭제글 지우기

웹페이지를 그냥 열 때는 거의 다 GET입니다. 로그인 폼을 채워 "제출"을 누르면 보통 POST가 나갑니다.

상태 코드: "결과가 어땠는가"

응답 첫 줄의 숫자(200, 404 등)가 상태 코드(status code)입니다. 백의 자리 숫자로 큰 분류를 외우면 편합니다.

범위의미대표 예
2xx성공200 OK (잘 됐음)
3xx다른 곳으로 보냄(리다이렉트)301(주소 영구 이전)
4xx요청한 쪽의 잘못404 Not Found(그런 페이지 없음), 403(권한 없음)
5xx서버 쪽의 잘못500(서버 내부 오류)
그 유명한 404가 바로 이것입니다. 페이지가 없을 때 서버가 "그런 건 없어요(4xx, 당신이 요청한 게 잘못됨)"라고 답하는 숫자죠. 503·500을 보면 "내 잘못이 아니라 서버가 아픈 것"이라고 이해하면 됩니다.

상태가 없는데 어떻게 로그인이 유지될까: 쿠키와 세션

앞에서 HTTP는 "한 번 묻고 답하면 끝, 다음 요청 때 누구였는지 모른다(stateless)"고 했습니다. 그런데 우리는 로그인하면 페이지를 옮겨 다녀도 로그인 상태가 유지되죠. 모순 같지 않나요?

해법은 쿠키(cookie)입니다. 서버가 응답할 때 "이 표를 가지고 다녀라"라며 작은 쪽지를 함께 줍니다. 브라우저는 그 쪽지를 저장해 뒀다가, 다음 요청마다 자동으로 도로 내밉니다. 서버는 그 표를 보고 "아, 아까 그 사람이구나" 하고 알아봅니다.

sequenceDiagram
    participant B as 브라우저
    participant S as 서버
    B->>S: 로그인 요청 (POST, 아이디/비번)
    S-->>B: 200 OK + Set-Cookie: 표=abc123
    Note over B: 쿠키(표) 저장
    B->>S: 다음 페이지 요청 + Cookie: 표=abc123
    Note over S: 표 확인 → "로그인된 그 사람"
    S-->>B: 그 사람 전용 화면
  • 서버는 응답 헤더 Set-Cookie로 쪽지를 발급합니다.
  • 브라우저는 이후 요청 헤더 Cookie로 그 쪽지를 자동 첨부합니다.
  • 이렇게 여러 요청을 하나의 "방문(세션, session)"으로 묶는 것을 세션 관리라고 합니다.
비유: 놀이공원에서 손목에 차는 입장 밴드와 같습니다. 한 번 받으면, 놀이기구를 탈 때마다 보여주지 않아도 직원이 밴드를 보고 통과시켜 주죠. 쿠키가 그 밴드입니다.

쿠키는 로그인뿐 아니라 장바구니 유지, 설정 기억, (때로는) 광고 추적에도 쓰입니다. 민감한 표가 담기므로 보안이 중요한데, 그래서 HTTPS(앞서 본 밀봉 봉투)와 함께 쓰는 것이 기본입니다.

같은 걸 또 받지 않기: 캐싱

페이지를 다시 방문하면 로고 이미지나 CSS가 거의 즉시 뜨는 걸 본 적 있을 겁니다. 매번 다시 받지 않고 브라우저가 저장(캐시)해 둔 것을 재사용하기 때문입니다.

서버는 응답 헤더로 "이 파일은 얼마나 오래 재사용해도 된다"를 알려줍니다(예: Cache-Control 헤더). 그 기간 안에는 브라우저가 서버에 묻지 않고 저장본을 바로 씁니다.

  • 장점: 속도가 빨라지고, 데이터·서버 부담이 준다.
  • 함정: 파일을 새로 바꿔도 사용자에게 옛 버전이 한동안 보일 수 있다. (2부의 DNS 캐시와 똑같은 트레이드오프죠.) 그래서 개발자는 파일 이름에 버전을 붙이는 등의 방법으로 이를 관리합니다.
캐시는 웹 전반의 핵심 주제입니다 — DNS에도, 브라우저에도, 서버 앞단에도 있습니다. 공통 아이디어는 하나: "한 번 구한 답을 가까이 두고 다시 쓴다."

안전한 통신: HTTPS

요즘 주소창을 보면 거의 https://로 시작하고 자물쇠 아이콘이 있습니다. HTTPS는 HTTP에 암호화를 더한 것입니다(S = Secure, 안전).

  • 일반 HTTP는 편지를 엽서처럼 보냅니다 — 중간에 누가 보면 내용이 그대로 읽힙니다.
  • HTTPS는 편지를 밀봉 봉투에 넣어 보냅니다 — 중간에서 가로채도 내용을 읽지 못합니다. 이 봉투를 만드는 기술을 TLS라고 합니다.

연결을 처음 맺을 때 서버와 브라우저가 잠깐 인사(핸드셰이크, handshake)를 나누며 "이제부터 우리끼리만 아는 방식으로 암호화하자"라고 약속합니다. 이게 앞 그림의 ② 연결 단계에서 일어나는 일입니다. 로그인·결제 등 민감한 정보가 오가는 사이트라면 HTTPS는 필수입니다.

HTTP에도 버전이 있다 (가볍게)

HTTP는 시간이 지나며 더 빨라지도록 개선돼 왔습니다. 초보가 깊이 알 필요는 없지만, 이름은 종종 보게 됩니다.

버전한 줄 특징
HTTP/1.1오래되고 단순. 여전히 널리 쓰임
HTTP/2한 연결로 여러 요청을 동시에 — 더 빠름
HTTP/3더 빠른 연결을 목표로 한 최신 버전

현재(2026년 기준) 웹 트래픽은 HTTP/2가 약 51%로 가장 많고, HTTP/3는 약 21% 수준입니다. 크롬·파이어폭스·사파리·엣지 등 주요 브라우저는 모두 HTTP/3를 지원하며, 지원하지 않는 환경에서는 자동으로 HTTP/2로 내려가므로(fallback) 사용자는 차이를 거의 느끼지 못합니다. 중요한 건, 버전이 달라도 "요청-응답, 메서드, 상태 코드" 같은 기본 개념은 똑같다는 점입니다. 빨라지는 건 주로 그 아래 운반 방식이에요.

직접 들여다보기 (강력 추천 실습)

브라우저에는 이 편지들을 눈으로 볼 수 있는 도구가 내장돼 있습니다.

  1. 아무 웹사이트나 엽니다.
  2. 마우스 우클릭 → 검사(Inspect) 클릭. (또는 F12)
  3. 위쪽 탭에서 Network(네트워크)를 선택합니다.
  4. 페이지를 새로고침(F5)합니다.
  5. 목록에 뜨는 항목 하나를 클릭하면, 방금 배운 요청 헤더·응답 헤더·상태 코드가 그대로 보입니다.

직접 보면 "아, 페이지 하나 여는 데 이렇게 많은 요청이 오가는구나"를 실감하게 됩니다. HTML 한 통을 받은 뒤, 그 안에 적힌 이미지·CSS·JS를 받으러 추가 요청이 줄줄이 나가거든요(앞 그림의 점선 화살표).

이 부에서 기억할 것

  • HTTP는 클라이언트와 서버의 대화 규칙이고, 대화는 요청-응답 한 쌍이다.
  • 요청은 메서드(무엇을 할지: GET=읽기, POST=보내기)와 헤더로,

응답은 상태 코드(2xx 성공, 4xx 내 잘못, 5xx 서버 잘못)와 본문으로 이루어진다.

  • HTTPS는 통신을 봉투에 밀봉해 안전하게 만든다.
  • HTTP는 상태가 없지만, 쿠키(서버가 준 표를 매 요청 자동 첨부)로 로그인·세션을 유지한다.
  • 캐싱은 받은 파일을 저장해 재사용하므로 빠르지만, 옛 버전이 보일 수 있는 트레이드오프가 있다.
  • 버전(1.1/2/3)은 속도를 개선하지만 기본 개념은 동일하다.

다음 부에서는 응답 본문에 실려 온 HTML — 페이지의 뼈대를 직접 만들어 봅니다. 여기서부터 우리의 실습 프로젝트가 시작됩니다.

→ 4부 · 페이지의 뼈대: HTML