[Web] HTTP 정리: 웹 개발 관점에서 이해하는 요청과 응답

게시 2026/01/22

By JY

9 분읽는 시간

HTTP(HyperText Transfer Protocol)는 웹에서 클라이언트(브라우저, 앱)가 서버와 통신할 때 사용하는 대표적인 프로토콜이다.
웹 개발 관점에서 HTTP를 이해한다는 것은 “주소로 접속한다”를 넘어, 요청(Request)과 응답(Response)이 어떤 형식으로 오가고, 메서드·상태 코드·헤더·캐시·쿠키 같은 요소가 어떤 역할을 하는지를 파악하는 것을 의미한다.

HTTP는 무엇을 하는가

HTTP는 클라이언트가 서버에 “무엇을 원한다”라고 요청하면, 서버가 “요청한 결과”를 응답하는 요청-응답 모델로 동작한다.

클라이언트: 브라우저, 모바일 앱, 프론트엔드 코드(fetch/axios)
서버: API 서버, 웹 서버, 백엔드 애플리케이션

HTTP 자체는 “데이터를 어떤 형식으로 주고받을지”에 대한 규칙이며, 실제 데이터는 HTML일 수도 있고 JSON일 수도 있다.

요청과 응답의 기본 구조

요청(Request)

요청은 크게 다음으로 구성된다.

1) 요청 라인(Request Line)
2) 헤더(Headers)
3) 바디(Body, 선택)

예를 들어 다음과 같은 형태가 된다.

GET /posts/1 HTTP/1.1
Host: example.com
Accept: application/json

응답(Response)

응답은 다음으로 구성된다.

1) 상태 라인(Status Line)
2) 헤더(Headers)
3) 바디(Body, 선택)

예시는 다음과 같다.

HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 1, "title": "Hello" }

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

웹 개발에서 가장 자주 사용하는 메서드는 다음과 같다.

GET: 조회(읽기)
POST: 생성(추가)
PUT: 전체 수정(교체)
PATCH: 일부 수정
DELETE: 삭제

예시:

GET /products : 상품 목록 조회
GET /products/123 : 상품 상세 조회
POST /products : 상품 생성
PATCH /products/123 : 상품 일부 수정
DELETE /products/123 : 상품 삭제

메서드는 “요청이 어떤 의도인지”를 표현하는 중요한 수단이며, REST API 설계에서도 핵심으로 활용된다.

상태 코드(Status Code): 결과는 어떻게 되었는가

상태 코드는 요청 처리 결과를 숫자로 표현한다. 실무에서 자주 마주치는 범주는 다음과 같다.

2xx: 성공

200 OK: 요청 성공
201 Created: 생성 성공(주로 POST)
204 No Content: 성공했으나 응답 바디가 없음(주로 DELETE)

3xx: 리다이렉트

301 Moved Permanently: 영구 이동(SEO에서도 중요)
302 Found: 임시 이동

4xx: 클라이언트 오류

400 Bad Request: 요청 형식/값이 잘못됨
401 Unauthorized: 인증 필요(로그인 필요)
403 Forbidden: 권한 없음
404 Not Found: 자원 없음
409 Conflict: 충돌(중복 등)
422 Unprocessable Entity: 형식은 맞지만 의미상 처리 불가(검증 실패 등)

5xx: 서버 오류

500 Internal Server Error: 서버 내부 오류
502 Bad Gateway / 503 Service Unavailable: 게이트웨이/서비스 장애

헤더(Headers): 부가 정보의 핵심

헤더는 요청/응답의 동작 방식을 세밀하게 제어한다. 웹 개발에서 특히 자주 등장하는 헤더는 다음과 같다.

Content-Type

전송하는 데이터 형식을 의미한다.

Content-Type: application/json
Content-Type: text/html; charset=utf-8

Accept

클라이언트가 원하는 응답 형식이다.

Accept: application/json

Authorization

인증 토큰(예: Bearer 토큰)을 담는다.

Authorization: Bearer <token>

Cache-Control

캐시 정책을 제어한다.

Cache-Control: no-store
Cache-Control: max-age=3600

바디(Body): 실제 데이터

GET 요청은 보통 바디가 없고, POST/PATCH/PUT에서 바디를 주로 사용한다.

예:

로그인: 아이디/비밀번호 전달
글 작성: 제목/내용 전달
상품 수정: 가격/재고 변경 값 전달

웹 개발에서는 JSON 형태의 바디가 가장 흔하다.

쿠키(Cookie)와 세션(Session): 상태를 다루는 방법

HTTP는 기본적으로 요청과 요청이 서로 독립적인 무상태(Stateless) 특성을 가진다.
그러나 웹 서비스는 로그인 상태처럼 “상태”가 필요하므로 이를 보완하기 위해 쿠키와 세션, 또는 토큰 기반 인증을 활용한다.

쿠키: 브라우저에 저장되어 자동으로 요청에 포함될 수 있는 값
세션: 서버가 사용자 상태를 관리하고, 클라이언트는 세션 식별자만 들고 있는 방식
토큰(JWT 등): 서버가 발급한 토큰을 클라이언트가 들고 다니며 요청마다 제출하는 방식

실무에서는 보안과 환경에 따라 쿠키 기반(특히 httpOnly 쿠키) 또는 토큰 기반을 선택한다.

캐시(Cache): 더 빠르게, 더 효율적으로

캐시는 “같은 요청에 대해 매번 서버를 두드리지 않고” 이전 응답을 재사용하도록 돕는다.
정적 파일(이미지, CSS, JS)에서 특히 중요하며, 성능과 비용에 직접적인 영향을 준다.

대표 개념은 다음과 같다.

max-age: 일정 시간 동안 재요청 없이 재사용
ETag / If-None-Match: 변경 여부를 확인하여 변경이 없으면 304 응답
Last-Modified / If-Modified-Since: 마지막 수정 시각 기반 검증

캐시는 무조건 “켜는 것”이 아니라, 리소스 성격에 따라 정책을 구분하는 것이 중요하다.

CORS: 브라우저에서만 생기는 제약

프론트엔드에서 API를 호출할 때 자주 마주치는 문제가 CORS이다.
CORS(Cross-Origin Resource Sharing)는 브라우저 보안 모델에서 비롯된 정책으로, 다른 출처(origin)의 요청을 제한하거나 허용하는 규칙을 말한다.

서버가 허용 헤더(Access-Control-Allow-Origin 등)를 적절히 설정해야 한다.
같은 API라도 브라우저에서는 막히고, 서버 간 통신에서는 문제가 없을 수 있다.

마무리

웹 개발 관점에서 HTTP는 다음 세 가지를 이해하는 것으로 요약할 수 있다.

1) 요청과 응답이 어떤 구조로 오가는지
2) 메서드와 상태 코드로 의도를 어떻게 표현하는지
3) 헤더·쿠키·캐시·CORS 같은 주변 개념이 왜 중요한지

HTTP를 정확히 이해하면 API 설계가 명확해지고, 디버깅 속도가 빨라지며, 성능과 보안에 대한 판단도 쉬워진다.

Web