HTTP/2와 HTTP/3 중 무엇을 우선 지원해야 하나요?

2026년 기준 주요 브라우저·CDN은 둘 다 널리 지원합니다. TLS 종단에서 HTTP/2(h2)와 HTTP/3(h3)를 함께 켜고, QUIC이 막히는 네트워크는 HTTP/2로 폴백되게 구성하는 것이 일반적입니다.

REST와 HTTP는 같은 말인가요?

아닙니다. REST는 아키텍처 스타일이고 HTTP는 그 위에서 자주 쓰이는 **전송 수단**입니다. REST는 리소스·표현·상태 코드·HATEOAS 등의 원칙으로, HTTP 메서드와 자연스럽게 맞물립니다.

캐시는 어디서 결정되나요?

브라우저·공유 캐시(프록시)·CDN·원본 서버가 **Cache-Control, ETag, Vary** 등 헤더와 검증 요청(조건부 GET)으로 협력합니다. API는 `Cache-Control: no-store` 등으로 민감 데이터를 보호합니다.

HTTP 프로토콜 완전 가이드 | HTTP/1.1·HTTP/2·HTTP/3·REST·HTTPS·캐시 실전

2026년 3월 30일 · 22분 읽기 · 수정 2026년 3월 30일 중급 가이드

이 글의 핵심

HTTP는 무상태 요청·응답 모델 위에서 웹·API를 표준화하며, 버전별로 파이프라인·멀티플렉싱·QUIC까지 진화했고 HTTPS·캐시·REST가 실무 품질을 결정합니다.

들어가며

HTTP(HyperText Transfer Protocol)는 월드 와이드 웹과 대부분의 공개 API가 공유하는 애플리케이션 계층 프로토콜입니다. 브라우저 탭 하나, 모바일 앱의 백엔드 호출, 마이크로서비스 간 동기 호출까지 “요청을 보내고 응답을 받는다”는 경험의 대부분이 HTTP(보통 HTTPS) 위에 있습니다.

버전은 HTTP/1.1의 단순함과 호환성, HTTP/2의 멀티플렉싱, HTTP/3의 QUIC 기반으로 진화했고, TLS 1.3, HSTS, 콘텐츠 보안 정책(CSP)은 보안 기본선이 되었습니다. 이 글은 프로토콜 스펙과 실무( curl, REST, 캐시, CDN)를 한 흐름으로 잇습니다.

왜 HTTP가 기본이 되었나요?

브라우저·모바일 SDK·API 게이트웨이·CDN이 같은 의미론(메서드·상태 코드·헤더)을 공유하기 때문입니다. 캐시·압축·TLS 종단까지 생태계가 HTTP에 최적화되어 있어, 새로운 전송을 매번 도입하기보다 HTTP 위에서 리소스 모델·보안 헤더를 다듬는 편이 비용 대비 효과가 큽니다.

프로덕션에서 주의할 점

캐시 헤더는 “빠름”과 “최신성”의 계약입니다. Cache-Control 실수는 옛 데이터 노출이나 과도한 원본 부하로 이어집니다.
CORS는 브라우저 정책일 뿐, 서버 간 호출 보안을 대신하지 않습니다. 인증·네트워크 경계를 함께 설계합니다.
HTTP/3는 UDP 443이 막히면 자동으로 HTTP/2로 폴백되는 경우가 많지만, 의도한 경로인지 로그와 ALB/CDN 설정으로 확인하는 것이 좋습니다.

이 글을 읽으면

요청 라인·메서드·상태 코드·헤더로 HTTP 메시지를 읽고 설계할 수 있습니다
HTTP/1.1 파이프라인 한계, HTTP/2 스트림, HTTP/3 QUIC의 차이를 설명할 수 있습니다
curl로 헤더·캐시·리다이렉트를 검증하고, RESTful API와 캐싱 전략을 적용할 수 있습니다
HTTPS·TLS 1.3·HSTS·CSP를 포함한 보안 체크리스트를 갖출 수 있습니다

프로토콜 개요

역사 및 개발 배경

HTTP는 1990년대 초 CERN에서 문서 링크를 전 세계에 퍼뜨리기 위해 시작되었고, RFC 1945(HTTP/1.0), RFC 2616(HTTP/1.1)으로 대중화되었습니다. 이후 헤더·캐시·청크 전송 등이 정교해졌고, HTTP/2(RFC 9113 계열)는 한 TCP 연결에서 다중 요청을 다루기 위해 등장했습니다. HTTP/3(RFC 9114)는 QUIC(UDP 기반) 위에서 TLS 1.3과 혼잡 제어·연결 마이그레이션을 일체화해, 무선·패킷 손실 환경에서 체감 성능을 개선하는 방향으로 정착했습니다(2026년 기준 주요 CDN·브라우저가 기본 지원).

OSI 7계층에서의 위치

HTTP는 OSI 7계층(응용 계층)에 해당합니다. 전송 계층에서는 전통적으로 TCP(HTTP/1.1, HTTP/2) 또는 QUIC(HTTP/3)이 사용되며, TLS는 기록 계층으로 HTTP 바이트를 암호화합니다. DNS로 호스트를 해석한 뒤, 443/tcp 또는 443/udp(QUIC)로 리소스 표현(representation)을 주고받는 모델입니다.

핵심 특징

특징	설명
무상태(Stateless)	서버는 기본적으로 이전 요청을 기억하지 않음(세션은 쿠키·토큰·서버 저장소로 보완).
요청·응답	클라이언트가 요청을 시작하고, 서버가 상태 코드·헤더·본문으로 응답합니다.
리소스 지향	URL로 대상을 식별하고, 메서드로 의도(GET 조회, POST 생성 등)를 표현합니다.
협상	`Accept`, `Accept-Encoding`, `Accept-Language` 등으로 표현 형식을 맞춥니다.
캐시 친화	검증 헤더(ETag)와 Cache-Control으로 대역폭·지연을 줄입니다.

동작 원리

Request / Response

HTTP 메시지는 시작 줄, 헤더 필드, 빈 줄, (선택) 본문으로 구성됩니다.

요청 시작 줄(HTTP/1.1 예)

GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json

응답 시작 줄

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: private, max-age=60

메서드(안전·멱등)

메서드	일반적 용도	안전	멱등(이상적)
GET	조회	예	예
HEAD	메타만	예	예
POST	생성·처리	아니오	보장 안 함
PUT	전체 치환	아니오	예
PATCH	부분 수정	아니오	스펙에 따라 다름
DELETE	삭제	아니오	예

멱등: 같은 요청을 여러 번 해도 서버 상태가 동일하게 유지되는 성질(네트워크 재시도 설계에 중요).

상태 코드 개요

2xx: 성공(200 OK, 201 Created, 204 No Content)
3xx: 리다이렉트(301, 302, 307, 308—메서드 보존 여부 주의)
4xx: 클라이언트 오류(400, 401, 403, 404, 429)
5xx: 서버 오류(500, 502, 503, 504)

헤더 하이라이트

헤더	역할
Host	가상 호스팅·SNI와 함께 동일 IP의 여러 사이트 구분(HTTP/1.1 필수급).
Authorization	`Bearer`, `Basic` 등 인증 자격 증명.
Content-Type	본문 MIME(`application/json` 등).
Cache-Control	캐시 가능 여부·수명(`max-age`, `no-store` 등).
ETag / Last-Modified	조건부 요청·검증.

HTTP/2: 멀티플렉싱

HTTP/2는 하나의 TCP 연결에서 여러 스트림을 동시에 다룹니다. HTTP/1.1의 헤더 중복은 HPACK 압축으로 줄이고, 서버 푸시(push)는 일부 환경에서 우선순위·리소스 힌트로 대체되는 추세였습니다. 핵심은 HOL(Head-of-Line) 블로킹을 애플리케이션 레벨에서 완화한다는 점입니다( TCP 레벨 HOL은 여전히 존재).

HTTP/3: QUIC 위의 HTTP

HTTP/3는 QUIC 위에서 동작합니다. TLS 1.3이 QUIC에 통합되고, 패킷 손실 시 영향 범위가 스트림 단위로 줄어드는 경우가 많아 Wi‑Fi 이동·손실 큰 링크에서 유리할 수 있습니다.

flowchart TB
  subgraph app [응용 계층]
    H3[HTTP/3]
  end
  subgraph quic [전송·암호화]
    Q[QUIC + TLS 1.3]
  end
  subgraph net [네트워크]
    U[UDP]
    IP[IP]
  end
  H3 --> Q --> U --> IP

sequenceDiagram
  participant C as Client
  participant S as Server
  C->>S: HTTP Request (method, path, headers)
  S->>C: HTTP Response (status, headers, body)

실전 사용

curl로 검증하기

# 응답 헤더만 보기
curl -sI https://example.com

# JSON POST
curl -sS -X POST 'https://api.example.com/items' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -d '{"name":"demo"}'

# 리다이렉트 추적(-L), 상세 로그(-v)
curl -L -v 'https://example.com/path'

# HTTP/2 강제(지원 시)
curl --http2 -sI https://example.com

# HTTP/3(빌드에 따라)
curl --http3-only -sI https://cloudflare-quic.com/

-s: 진행률·에러 이외의 통계 출력을 숨겨 스크립트에 넣기 쉽게 합니다. -S: 에러가 나면 침묵하지 않고 표시합니다(-sS는 함께 쓰는 경우가 많음).
-I: HEAD 요청에 해당하는 동작으로, 응답 헤더만 가져옵니다(본문 없음).
-X POST: 메서드를 POST로 지정합니다.
-H: 요청 헤더 한 줄을 추가합니다. Content-Type, Authorization 등에 사용합니다.
-d: 요청 본문을 지정합니다. JSON 문자열을 그대로 붙입니다.
-L: 3xx 리다이렉트를 따라갑니다(최종 URL까지).
-v: 상세 디버그(DNS, TLS, 헤더)를 출력합니다.
--http2: 클라이언트가 지원하면 HTTP/2로 협상해 봅니다.
--http3-only: HTTP/3만 시도합니다(빌드·서버 지원 필요).

아키텍처 관점: 클라이언트 → CDN/엣지 캐시 → 원본(또는 API)으로 요청이 흐를 때, 각 홉의 캐시 키·Vary·TLS 종단 위치가 응답 내용을 바꿉니다. 장애 시 어느 레이어의 502/504인지를 먼저 나눕니다.

REST API 설계 팁

리소스 중심 URL: /users/42/orders처럼 명사·계층으로 표현합니다.
상태 코드로 의미 고정: 생성은 201+Location, 잘못된 입력은 400/422, 인증은 401, 권한은 403.
버전 관리: /v1/ 접두사 또는 Accept 헤더로 호환성을 명시합니다.
페이지네이션: cursor 또는 offset/limit, 링크 헤더(Link)로 다음 페이지를 표준화합니다.
멱등 키: 결제·주문처럼 중복 제출이 치명적이면 Idempotency-Key 패턴을 고려합니다.

캐싱 전략

정적 자산: 파일명에 해시를 넣고 Cache-Control: public, max-age=31536000, immutable.
HTML 진입점: max-age는 짧게, 버전된 JS/CSS에 긴 캐시.
API: 개인 데이터는 private 또는 no-store; 공개 읽기 전용은 ETag+max-age로 조건부 요청 유도.
Vary: Accept-Encoding·Accept-Language에 따라 다른 표현이면 Vary를 정확히 명시합니다.

보안 고려사항

HTTPS와 TLS 1.3

평문 HTTP는 인증 정보·쿠키·페이로드가 노출됩니다. TLS 1.3은 핸드셰이크 단축·암호 스위트 현대화로 기본선이 되었고, 인증서 체인·만료·SAN 관리가 운영 핵심입니다.

HSTS

HTTP Strict Transport Security(Strict-Transport-Security)는 브라우저가 해당 도메인을 HTTPS로만 로드하도록 강제합니다. 프리로드 리스트 등록은 정책에 따라 신중히 결정합니다.

CSP(콘텐츠 보안 정책)

Content-Security-Policy는 XSS 완화에 유효합니다. default-src, script-src에 nonce/hash 기반으로 좁히고, frame-ancestors로 클릭재킹을 제한합니다.

API 보안

OAuth 2.0 / OIDC로 위임 인증, 짧은 수명 액세스 토큰+리프레시 패턴.
CORS는 브라우저를 위한 정책—서버 간 호출을 막지는 않으므로 인증·네트워크 경계와 함께 설계합니다.

실무 활용 사례

영역	설명
웹 서비스	HTML·JS·미디어 배포, CDN 엣지 캐시와 연동.
공개·내부 API	JSON/XML, OpenAPI 문서화, 게이트웨이에서 레이트 리밋·인증.
마이크로서비스	동기 호출은 HTTP/gRPC 혼용, 재시도·타임아웃·서킷 브레이커로 연쇄 장애 완화.
웹훅	이벤트 수신 엔드포인트에 서명 검증(HMAC)·멱등 저장소.

최적화 팁

Keep-Alive(HTTP/1.1): Connection: keep-alive로 TCP 재사용(오늘날 기본). 많은 작은 요청은 HTTP/2·HTTP/3가 유리.
압축: br(Brotli)·gzip은 텍스트에 효과적; 이미 압축된 미디어는 이득이 작습니다.
CDN: 지리적으로 가까운 엣지에서 캐시·TLS 종단, 원본은 캐시 키·무효화 API로 제어.
HTTP/3: QUIC이 막히면 HTTP/2 폴백—로드밸런서·방화벽 UDP 443 허용 여부를 확인합니다.

흔한 문제와 해결

증상	점검
CORS 에러	서버 `Access-Control-Allow-Origin`, 프리플라이트 메서드·헤드 허용, 자격 증명 시 `credentials` 일치.
타임아웃	클라이언트·LB·서버 idle/read 타임아웃, 다운스트림 지연, DNS.
리다이렉트 루프	`301/302` 체인, http↔https, www 정규화, 캐시된 301 확인.
캐시가 안 바뀜	`Cache-Control`, CDN 퍼지, URL 버전 bump.

흔한 실수와 해결

실수	결과	해결
민감 API에 `Cache-Control: public`	공유 캐시에 개인 데이터가 캐시될 위험	`private`·`no-store` 등으로 재정의
`ETag`만 믿고 `Vary`를 무시	압축·언어·쿠키에 따라 엉뚱한 표현이 캐시됨	`Vary`를 정확히 명시
리다이렉트 체인만 길게 늘림	지연·실패 지점 증가	캐노니컬 URL로 단순화
HTTP/3만 켜고 UDP 차단을 미확인	일부 사용자는 느리거나 폴백	방화벽·관측 로그로 검증

마무리

HTTP는 무상태 요청·응답과 풍부한 의미론(메서드·상태·헤더)으로 웹과 API를 표준화했습니다. HTTP/2는 멀티플렉싱, HTTP/3는 QUIC으로 지연·손실 환경을 개선했으며, HTTPS·HSTS·CSP는 기본 보안입니다.

추천 시나리오: 공개 웹·REST API·게이트웨이 설계, 성능은 캐시·CDN·프로토콜 버전, 안전은 TLS·헤더·최소 권한으로 동시에 잡는 경우 이 글의 체크리스트를 그대로 적용할 수 있습니다.

참고

IETF HTTPbis 문서군(RFC 9110~9114 계열)
Mozilla MDN: HTTP, CORS, CSP
OWASP: API Security, Transport Layer Protection