학습 공간 개념 · 판단 · 실험

Frontend Performance Lab

네트워크

HTTP 요청·응답의 의미

HTTP는 아래쪽 전송 계층의 연결 방식과 분리된 일관된 요청·응답 의미(메서드, URI, 헤더, 상태 코드)를 정의합니다.

이럴 때 필요해요

HTTP 버전이나 서버 구현이 바뀌어도 브라우저, 프록시, CDN 캐시가 똑같은 약속으로 안전하게 통신할 수 있는 이유를 이해하기 위해 필요합니다.

어떻게 동작하나요?

웹 브라우저에서 게시글 하나를 불러올 때 클라이언트는 '무엇을(URI), 어떤 의도로(메서드), 어떤 부가 조건으로(헤더) 원하는지'를 담아 HTTP 요청을 보내고, 서버는 '결과가 어떠한지(상태 코드)'와 실제 데이터(표현 본문)를 담아 응답합니다. 아래에서 데이터를 나르는 방식이 HTTP/1.1의 텍스트 프레이밍이든, HTTP/2의 바이너리 스트림이든, HTTP/3의 QUIC(UDP 기반)이든 이 상위 요청·응답의 의미 자체는 동일하게 유지됩니다.

흔히 면접에서 묻는 HTTP의 무상태성(Stateless)은 '서버가 이전 요청의 대화 맥락을 프로토콜 차원에서 자동으로 기억해 두지 않아도, 지금 들어온 요청 메시지 하나만으로 의미를 완전히 해석할 수 있다'는 뜻입니다. 이것이 곧 웹 서비스에서 로그인 세션이나 데이터베이스 상태를 저장할 수 없다는 뜻은 아니며, 쿠키나 토큰, 서버 세션을 통해 애플리케이션 상태를 관리하는 것과 아래에서 TCP 연결을 끊지 않고 재사용(Keep-Alive)하는 것은 모두 HTTP 무상태성과 양립합니다.

응답으로 돌아오는 상태 코드는 성공(2xx), 이동·캐시 재사용(3xx), 요청 측 오류(4xx), 서버 측 오류(5xx)를 명확히 구분해 줍니다. 예를 들어 304 Not Modified는 에러가 아니라 '클라이언트가 이미 가지고 있는 캐시 데이터가 최신이니 본문을 다시 받지 말고 그대로 쓰라'는 효율적인 응답이고, 204 No Content는 삭제나 저장이 성공했지만 돌려줄 본문은 없다는 뜻입니다. 따라서 프론트엔드에서도 단순히 '200이면 성공'으로만 처리하지 않고 상태 코드별 의미에 맞게 화면과 캐시를 다루어야 합니다.

코드 예제

동작을 설명하는 읽기 전용 예제입니다.

example.txt
GET /articles/7 HTTP/1.1
Host: example.test
If-None-Match: "v3"

HTTP/1.1 304 Not Modified
ETag: "v3"
http · 읽기 전용6줄

클라이언트가 가진 게시글 버전("v3")이 서버의 최신 버전과 같을 때의 요청·응답 예시입니다. 서버는 304 상태 코드만 돌려주고 본문 전송을 생략해 네트워크 비용을 아낍니다.

자주 헷갈리는 포인트

  • HTTP가 무상태(Stateless) 프로토콜이라는 말을 '서버에 로그인 세션을 저장할 수 없다'거나 '매번 TCP 연결을 새로 맺는다'는 뜻으로 섞어 쓰면 안 됩니다.
  • 오직 상태 코드 200만 성공으로 처리하거나, 반대로 HTTP 200 안에 에러 메시지를 담아 보내면 캐시와 공통 에러 처리가 꼬이게 됩니다.

내 말로 설명해 보기

웹 서비스가 쿠키와 서버 세션으로 로그인 상태를 유지하고 있는데도 여전히 HTTP 자체를 무상태(Stateless) 프로토콜이라고 부르는 이유는 무엇인가요?

실전 시나리오에 적용해 보기

설계 상황티켓팅 페이지, 공연 정보와 좌석 목록을 어떻게 불러올까요?독립적인 API 병렬 호출부터 부분 실패 처리, 요청 경쟁(Race Condition) 방지와 응답 스키마 검증까지 차례대로 설계합니다.설계 상황결제 요청 중 타임아웃이 났다면, 그냥 다시 요청해도 괜찮을까요?API 권한 검증, 개인화 데이터 캐시 격리, 멱등성 키(Idempotency Key)를 이용한 안전한 재시도와 결제 확정을 설계합니다.

함께 읽으면 좋은 개념

HTTP 메서드와 안전한 재시도 →TCP 바이트 스트림과 UDP 데이터그램 →쿠키·웹 저장소·인증과 브라우저 보안 →

관련 면접 질문 3개

웹 통신에서 프로토콜(Protocol)은 어떤 규칙을 정하며 각 계층은 어떻게 역할을 나누나요?

프로토콜은 통신 상대끼리 메시지 형식과 의미, 교환 순서, 오류 처리 방식을 일치시키는 규칙입니다. 웹에서는 DNS가 도메인 이름 해석을, HTTP가 요청·응답 의미를, TLS가 암호화와 인증을, TCP나 QUIC이 전송을 각각 분담합니다. 이처럼 계층마다 보장하는 범위가 다르므로 하위 전송 성공을 곧바로 상위 비즈니스 처리 완료로 간주하지 않고 애플리케이션 계약을 별도로 설계해야 합니다.

꼬리질문과 참고자료 →

HTTP의 요청·응답 구조와 무상태성(Stateless)은 정확히 무엇을 뜻하나요?

HTTP는 메서드·URI·헤더·본문으로 요청 의도를 보내고 상태 코드와 표현으로 응답을 받는 애플리케이션 계층 프로토콜입니다. 여기서 무상태성(Stateless)이란 서버가 이전 요청의 문맥을 프로토콜 수준에서 자동 보존하지 않아도 각 요청의 의미를 독립적으로 해석할 수 있다는 뜻입니다. 이는 프로토콜 설계 특성일 뿐, 애플리케이션이 쿠키·토큰·세션 저장소나 DB로 로그인 상태를 관리하는 것까지 금지한다는 뜻은 아닙니다.

꼬리질문과 참고자료 →

HTTP 상태 코드의 다섯 가지 계열(1xx~5xx)은 클라이언트가 어떤 판단을 내리도록 돕나요?

HTTP 상태 코드는 1xx(중간 정보), 2xx(성공), 3xx(리다이렉션 및 캐시 재사용 안내), 4xx(클라이언트 측 요청 문제), 5xx(서버 측 오류)로 응답 성격을 분류합니다. 예를 들어 201은 자원 생성, 204는 본문 없는 성공, 304는 캐시 재사용, 401은 인증 요구, 403은 권한 거부를 뜻합니다. 클라이언트는 상태 코드 숫자만 보지 않고 요청 메서드의 멱등성과 Retry-After 헤더, 업무 정책을 함께 고려해 재시도나 안내 방식을 결정합니다.

꼬리질문과 참고자료 →

공식 참고 자료

← 네트워크