Network · 완벽 가이드 Ch.4 §1

HTTP 기본에 대해서 설명해주세요 (Stateless, 비연결성)

HTTP의 핵심 설계 원칙인 무상태성(Stateless)과 비연결성(Connectionless)을 인터랙티브 시각화로 완벽하게 이해하고 면접을 준비하세요.

2026년 3월 31일 · 약 12분 읽기

Q. "HTTP의 무상태성(Stateless)과 비연결성(Connectionless)에 대해 설명하고, 이를 극복하기 위한 방법을 말씀해주세요."

예상 꼬리질문

답변 가이드

HTTP는 무상태성(Stateless)과 비연결성(Connectionless)이라는 두 가지 핵심 설계 원칙을 갖습니다. 무상태성은 서버가 클라이언트의 이전 요청 상태를 저장하지 않는다는 의미로, 각 요청은 독립적으로 처리됩니다. 비연결성은 요청-응답이 완료되면 TCP 연결을 종료하여 서버 자원을 효율적으로 사용한다는 의미입니다.

이러한 설계 덕분에 서버 수평 확장(Scale-out)이 용이하고, 더 많은 클라이언트를 동시에 처리할 수 있습니다. 하지만 단점도 있는데, 무상태성으로 인해 로그인 상태 유지가 불가능하고, 비연결성으로 인해 매 요청마다 TCP 3-way Handshake 비용이 발생합니다.

이를 극복하기 위해 실무에서는 여러 방법을 사용합니다. 무상태성 문제는 쿠키-세션 또는 JWT 토큰으로 해결하고, 비연결성 문제는 HTTP/1.1의 Keep-Alive 헤더나 HTTP/2의 멀티플렉싱으로 해결합니다.

면접관이 정말 듣고 싶은 건 "HTTP가 무엇인지"가 아닙니다. 무상태성과 비연결성이 왜 이런 방식으로 설계되었는지, 그리고 이 설계가 실무에서 어떤 문제를 만들고 어떻게 해결하는지를 이해하고 있는가입니다.

이 아티클에서는 HTTP 동작을 인터랙티브 시각화로 체득하고, 면접에서 바로 활용할 수 있는 수준까지 준비합니다.

1. HTTP 요청/응답 구조

꼬리질문: "HTTP 요청/응답 메시지 구조를 설명해주세요"

HTTP는 클라이언트-서버 모델 기반의 요청(Request)/응답(Response) 프로토콜입니다. 브라우저가 URL을 입력하는 순간부터 화면이 나타나기까지, 정형화된 메시지 구조를 통해 데이터가 교환됩니다.

요청 메시지는 시작 라인(메서드, URL, 버전), 헤더(메타데이터), 바디(데이터) 세 부분으로 구성됩니다. 응답 메시지 역시 같은 구조이며, 상태 코드로 처리 결과를 전달합니다.

메서드 탭을 전환하고 각 구성 요소를 클릭하여 HTTP 메시지 구조를 살펴보세요.

클릭하면 설명을 볼 수 있습니다

클라이언트 요청

GET /users/1 HTTP/1.1

Host: api.example.com

Authorization: Bearer token123

Accept: application/json

(바디 없음)

서버 응답 200

HTTP/1.1 200 OK

Content-Type: application/json

Content-Length: 42

{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com"
}

2xx 성공3xx 리다이렉트4xx 클라이언트 오류5xx 서버 오류

HTTP 메서드는 서버에 "무엇을 하고 싶다"는 의도를 전달합니다. GET은 안전(Safe)하고 멱등(Idempotent)하므로 캐싱이 가능하지만, POST는 그렇지 않습니다.

2. 비연결성 (Connectionless)과 HTTP 버전 진화

꼬리질문: "HTTP/1.1의 Keep-Alive와 HTTP/2의 멀티플렉싱은 어떻게 다른가요?"

HTTP의 비연결성은 요청-응답 후 TCP 연결을 종료하는 특성입니다. 이 설계로 서버는 동시에 더 많은 클라이언트를 처리할 수 있지만, 매 요청마다 TCP 3-way Handshake 비용이 발생하는 단점도 있습니다.

HTTP 버전이 발전하면서 비연결성의 단점을 점진적으로 해결해왔습니다. HTTP/1.1은 Keep-Alive로 연결을 재사용하고, HTTP/2는 멀티플렉싱으로 하나의 연결에서 여러 요청을 동시에 처리합니다.

버전 탭을 전환하며 HTTP/1.0, HTTP/1.1, HTTP/2의 연결 방식 차이를 애니메이션으로 확인하세요.

매 요청마다 새 연결

RTT 3회 이상

요청마다 TCP 연결을 새로 수립하고 종료합니다. 이미지 10개를 받으면 10번의 TCP 핸드셰이크가 필요합니다.

연결 방식 시각화

클라이언트서버

HTML

TCP 연결 → 요청 → 응답 → TCP 종료

CSS

TCP 연결 → 요청 → 응답 → TCP 종료

3개 요청 = 3번의 TCP 핸드셰이크 비용 발생

HTTP/1.0

RTT 3회 이상

HTTP/1.1

RTT 1회 + 순차 처리

HTTP/2

RTT 1회 + 병렬 처리

HTTP/2의 헤드 오브 라인 블로킹(Head-of-Line Blocking) 문제는 TCP 레벨에서 발생합니다. HTTP/3(QUIC)은 UDP를 기반으로 이 문제를 근본적으로 해결합니다.

3. 무상태성 (Stateless)과 상태 유지 메커니즘

꼬리질문: "세션과 JWT는 어떤 차이가 있고, 각각 언제 사용하나요?"

무상태성은 서버가 클라이언트의 이전 요청 상태를 기억하지 않는 설계입니다. 덕분에 어떤 서버도 클라이언트 요청을 처리할 수 있어 수평 확장이 쉽지만, 로그인 상태 같은 컨텍스트를 유지하려면 추가 메커니즘이 필요합니다.

실무에서는 쿠키-세션 방식과 JWT 토큰 방식으로 상태를 관리합니다. 두 방식은 상태를 저장하는 위치가 다르며, 수평 확장 시 동작 방식에 차이가 있습니다.

단계 버튼을 클릭하고 세션/JWT 방식을 전환하며 수평 확장 시 차이를 직접 확인해 보세요.

인증 방식:

사용자가 로그인합니다

브라우저→POST /login (ID/PW)→서버 A

서버 A→세션 ID 저장 (메모리)→메모리

서버 A→Set-Cookie: sessionId=abc→브라우저

세션 방식

• 상태 저장 위치: 서버 메모리
• 수평 확장: Redis 등 외부 저장소 필요
• 로그아웃: 서버에서 즉시 세션 삭제 가능
• 토큰 크기: 작음 (세션 ID만)

JWT 방식

• 상태 저장 위치: 클라이언트 (토큰 자체)
• 수평 확장: 추가 인프라 불필요
• 로그아웃: 블랙리스트 별도 관리 필요
• 토큰 크기: 큼 (정보 포함)

JWT는 서버 메모리가 필요 없어 수평 확장에 유리하지만, 로그아웃 구현이 까다롭습니다. 토큰 블랙리스트를 Redis에 저장하거나, 짧은 만료 시간 + Refresh Token 방식을 사용합니다.

4. HTTP 버전 비교

꼬리질문: "HTTP 버전이 발전하면서 어떤 문제들이 해결되었나요?"

HTTP는 웹의 발전과 함께 성능 문제를 해결하며 진화해왔습니다. 각 버전은 이전 버전의 한계를 극복하기 위한 핵심 기능을 도입했으며, 오늘날 대부분의 서비스는 HTTP/2를 사용하고 HTTP/3 전환이 가속화되고 있습니다.

버전 카드를 클릭하면 상세 특성을 확인할 수 있습니다.

특성	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3
연결 방식	요청마다 새 연결	Keep-Alive (재사용)	단일 연결 유지	단일 연결 유지
헤더 처리	평문 (압축 없음)	평문 (압축 없음)	HPACK 압축	QPACK 압축
멀티플렉싱	없음	없음 (순차 처리)	있음 (병렬 스트림)	있음 (독립 스트림)
서버 푸시	없음	없음	있음	있음
전송 프로토콜	TCP	TCP	TCP	QUIC (UDP)
HoL 블로킹	TCP 레벨	TCP + 앱 레벨	TCP 레벨만	없음

자주 발생하는 문제

실무와 면접에서 자주 혼동하는 포인트를 정리했습니다.

면접 체크리스트

이 항목들을 자신 있게 설명할 수 있다면 HTTP 기본 질문은 준비 완료입니다.

- HTTP 메시지 구조: 시작 라인 + 헤더 + 바디, 요청/응답 구분
- 무상태성(Stateless): 서버가 이전 요청을 기억하지 않음 → 수평 확장 용이, 세션/JWT로 극복
- 비연결성(Connectionless): 요청-응답 후 TCP 종료 → Keep-Alive/멀티플렉싱으로 극복
- 세션 vs JWT: 세션은 서버 메모리 저장 (Redis 필요), JWT는 클라이언트 저장 (수평 확장 유리)
- HTTP 버전 진화: HTTP/1.0 → HTTP/1.1 Keep-Alive → HTTP/2 멀티플렉싱 → HTTP/3 QUIC
- 더 알아볼 주제: TCP 3-way Handshake, HTTP/3와 QUIC, JWT 인증 흐름, REST API 설계 원칙

퀴즈로 확인하기

배운 개념을 실제 시나리오에 적용해 보세요.

Quiz 1

무상태성의 이해

사용자가 쇼핑몰에서 로그인 후 장바구니를 확인합니다.
서버 A에서 로그인이 처리되었고,
장바구니 요청은 로드 밸런서에 의해 서버 B로 라우팅되었습니다.
세션 기반 인증을 사용 중일 때, 어떤 현상이 발생하나요?

Quiz 2

HTTP/1.1 Keep-Alive vs HTTP/2 멀티플렉싱

웹 페이지에서 HTML, CSS, JS, 이미지 4개 파일을 요청합니다.
HTTP/1.1 Keep-Alive와 HTTP/2에서
이 요청들은 어떻게 처리될까요?

Quiz 3

JWT vs 세션의 수평 확장

다음 중 수평 확장(Scale-out) 환경에서
추가 인프라 없이 바로 동작하는 인증 방식은?

// 방식 A
session.setAttribute("userId", user.getId());

// 방식 B
String token = jwt.sign({userId: user.getId()}, secretKey);

Quiz 4

HTTP 상태 코드 해석

Spring Boot REST API에서 다음 응답을 받았습니다.
어떤 상황인가요?

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api"
Content-Type: application/json

{"error": "token_expired", "message": "Access token has expired"}

추가 학습 자료를 공유합니다.

MDN Web Docs - HTTP 개요 — HTTP의 기본 개념을 도식과 함께 설명한 Mozilla 공식 문서. 한국어로 번역되어 있어 이해하기 쉽습니다.
생활코딩 HTTP — 비전공자도 이해할 수 있는 HTTP 입문 무료 강의. 영상과 텍스트 모두 제공합니다.
우아한 형제들 기술 블로그 - HTTP/2 도입기 — 실무에서 HTTP/2를 도입하면서 겪은 경험과 고려사항을 정리한 글입니다.
kakao tech - HTTP/3, QUIC는 왜 UDP를 선택했는가? — HTTP/3의 탄생 배경과 QUIC 프로토콜의 원리를 알기 쉽게 설명합니다.

의견을 들려주세요

서비스 개선에 큰 도움이 됩니다. 익명으로 자유롭게 남겨주세요.