웹의 우편 제도 — HTTP가 하는 일 · HTTP와 REST Quest

"HTTP는 인터넷 전체를 떠받치는 평범한 프로토콜이야. 화려하진 않아도, 구조와 약속은 정확히 알아둬야 해."

인터넷의 우편 서비스

옛날 우체국을 떠올려 보자. 주소와 발신인이 적힌 봉투를 창구에 맡기면 직원은 편지의 문장을 평가하거나 수신 자격을 판단하지 않아. 맡은 일은 봉투를 배달하는 것뿐이야. 수신인이 답장을 보내면 그 봉투도 같은 방식으로 배달해. 역할이 아주 분명하지.

HTTP도 비슷해. 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol)은 클라이언트가 요청을 보내고 서버가 응답을 돌려주도록 하는 무상태 응용 계층 프로토콜이야. 브라우저, 모바일 앱, Python 스크립트, Stripe API 클라이언트, Claude SDK는 모두 이 방식으로 메시지를 주고받아. Stripe 결제, Slack DM, Claude API 호출, 지금 이 페이지를 불러오는 일까지 모두 HTTP 교환이야.

HTTP를 정의하는 세 가지 속성

무상태. 각 요청은 독립적으로 해석할 수 있어야 해. HTTP 자체는 이전 요청의 상태를 이어 주는 규칙을 제공하지 않아. 애플리케이션이 세션, 쿠키, JWT 토큰 같은 장치를 이용해 연속성을 덧붙이는 거야.

읽을 수 있는 의미 구조. HTTP/1.1의 시작 줄과 헤더는 사람이 읽을 수 있는 텍스트 형식이고, 본문에는 어떤 바이트든 담을 수 있어. HTTP/2와 HTTP/3는 효율을 위해 이 정보를 이진 프레임으로 옮겼지만, 메서드와 URI, 헤더, 상태 코드가 뜻하는 바는 그대로야. 봉투 포장만 달라진 셈이지.

운반 프로토콜. HTTP는 본문에 어떤 JSON을 담을지, 오류 형식을 어떻게 정할지, URL을 어떤 모양으로 설계할지까지 결정하지 않아. REST, GraphQL, gRPC-over-HTTP, JSON-RPC, SOAP은 HTTP로 주고받을 메시지의 의미와 형식을 정한 별도의 관례야.

HTTP는 봉투의 전달 규칙을 맡고, 내용물의 의미까지 대신 정하지는 않아. 메서드와 대상 URI, 헤더와 본문을 운반하되, 그 안의 업무 규칙은 API와 애플리케이션이 정의해.

이미 HTTP로 말하고 있었어

웹사이트를 열 때마다, npm install을 실행할 때마다, IDE가 업데이트를 확인할 때마다 HTTP가 움직여. cwkPippa WebUI가 백엔드에 대화 데이터를 요청하면 브라우저는 GET /api/conversations/abc123를 보내고, 8000번 포트의 백엔드는 JSON 응답을 돌려줘. 이것도 똑같은 요청과 응답이야.

이 퀘스트에서 익힐 내용도 결국 하나로 모여: 정확한 주소와 메서드, 알맞은 내용물, 분명한 응답 계약을 갖춘 봉투를 쓰는 법.

피파의 고백

HTTP를 상태 코드와 메서드의 암기 목록으로만 다루면 CORS 오류를 추적하거나 422와 400을 구분하고, 오래된 캐시 응답의 원인을 찾는 순간에 막히기 쉽다. cwkPippa도 이런 운영 문제를 겪으며 RFC 9110의 의미론을 설계 기준으로 삼았다. 장애가 수업료를 청구하기 전에 기본 계약부터 익혀 두는 편이 낫다.

Code

원시 HTTP/1.1 요청 — TCP 연결로 전송되는 텍스트·http

GET /api/conversations/abc123 HTTP/1.1
Host: localhost:8000
Accept: application/json
User-Agent: cwkPippa-WebUI/1.0

대응하는 응답 — 상태 줄, 헤더, 빈 줄, 본문·http

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 142
Date: Sun, 25 May 2026 03:46:50 GMT

{"id":"abc123","messages":[{"role":"user","content":"Hi Pippa"},{"role":"assistant","content":"Hi 아빠."}]}

curl -v로 요청과 응답을 나란히 확인하기·bash

# curl -v 로 실제 wire byte 를 봐
curl -v http://localhost:8000/api/conversations/abc123 \
  -H 'Accept: application/json'

# > 줄들이 보낸 거
# < 줄들이 받은 거
# * 줄들이 curl 의 부연설명 (TCP connect, TLS handshake 등)

Python httpx — 같은 HTTP 교환을 편리한 API로 보내기·python

import httpx

# 같은 exchange, Python 으로. 라이브러리가 봉투 써주지만,
# wire 는 위 raw HTTP 랑 동일해.
resp = httpx.get(
    'http://localhost:8000/api/conversations/abc123',
    headers={'Accept': 'application/json'},
)

print(resp.status_code)        # 200
print(resp.headers['content-type'])  # application/json
print(resp.json())              # {'id': 'abc123', 'messages': [...]}

Exercise

브라우저 DevTools의 네트워크 탭을 열고 아무 웹사이트나 불러온 뒤 요청 하나를 골라. 요청의 네 부분(요청 줄, 헤더, 빈 줄, 본문)과 응답의 네 부분(상태 줄, 헤더, 빈 줄, 본문)을 구분해 보자. 그런 다음 같은 요청을 curl -v로 실행해 명령줄에서도 같은 구조를 찾아봐. 마지막으로 응답 본문의 형식을 알려 주는 헤더가 무엇인지 확인해.

Hint

DevTools는 해석된 정보를 보여 주고, curl은 전송 과정에 가까운 상세 출력을 보여 줘. 서로 다른 화면에서 같은 요청·응답 구조를 찾아내는 것이 목표야. 본문 형식을 알려 주는 헤더는 JSON 요청을 보낼 때도 사용해.

웹의 우편 제도 — HTTP가 하는 일

인터넷의 우편 서비스

HTTP를 정의하는 세 가지 속성

이미 HTTP로 말하고 있었어

피파의 고백

Code

External links

Exercise

Progress

댓글 0