[HTTP의 기초를 찾아서 - 2편] HTTP 메서드와 상태코드에 대한 정리

이 글은 혼자 공부하는 네트워크 책과 널널한 개발자님의 외워서 끝내는 네트워크 핵심이론 - 기초 강의를 참고해서 작성한 글입니다.

HTTP가 정확히 무엇인지 모르시는 분들은 이전 편인 1편을 읽어 보고 오시면 좋습니다.

1편에서 HTTP 메시지의 첫 줄인 시작 라인을 살펴보았습니다. 요청 메시지의 첫 줄에는 메서드가, 응답 메시지의 첫 줄에는 상태코드가 들어 있었습니다.

요청 라인에는 메서드가, 상태 라인에는 상태코드가 들어 있다

메서드는 클라이언트가 자원에 무엇을 하고 싶은지를, 상태코드는 서버가 그 요청을 어떻게 처리했는지를 알려 줍니다. 이번 편에서는 이 두 가지를 차례로 정리해 보겠습니다.

HTTP 메서드

메서드란?

HTTP 메서드(Method)는 클라이언트가 자원에 어떤 작업을 하려는지 서버에 알려 주는 값입니다.

1편에서 보았듯이 요청 대상이 같아도 메서드가 다르면 서로 다른 요청입니다. GET /users/1은 1번 사용자를 조회하라는 요청이고 DELETE /users/1은 1번 사용자를 삭제하라는 요청입니다. URI가 “무엇을”을 가리킨다면 메서드는 “어떻게”를 말하는 셈입니다.

HTTP 표준 문서인 RFC 9110은 8개의 메서드를 정의하고, 여기에 RFC 5789에서 정의한 PATCH까지 더하면 모두 9개입니다. 그중 자주 쓰는 메서드는 다음과 같습니다.

메서드	하는 일
GET	자원을 조회한다
HEAD	GET과 같지만 본문 없이 헤더만 받는다
POST	서버에 데이터를 보내 처리를 요청한다
PUT	자원을 통째로 바꾼다 (없으면 만든다)
PATCH	자원의 일부만 바꾼다
DELETE	자원을 삭제한다
OPTIONS	자원이 지원하는 통신 옵션을 확인한다

나머지 CONNECT와 TRACE는 일반적인 웹 개발에서 직접 쓸 일이 거의 없습니다. CONNECT는 프록시를 거쳐 HTTPS 통신을 할 때 터널을 여는 데 쓰고 TRACE는 요청이 서버까지 어떻게 전달되는지 확인하는 진단용 메서드입니다. TRACE는 받은 요청을 쿠키까지 그대로 돌려주기 때문에 공격에 악용될 수 있어서 꺼 두는 경우가 많습니다.

GET: 자원을 조회한다

GET은 자원을 조회할 때 쓰는, 가장 많이 쓰이는 메서드입니다. 브라우저 주소창에 주소를 입력하거나 링크를 클릭하면 브라우저는 GET 요청을 보냅니다.

서버에 추가로 전달할 값이 있으면 URI의 쿼리에 담습니다.

GET /search?q=http&page=2 HTTP/1.1
Host: www.example.com

GET 요청에도 본문을 담을 수는 있지만 표준은 그 본문에 정해진 의미가 없다고 말합니다. 서버나 중간 서버에 따라서는 본문을 무시하거나 요청을 거부할 수도 있으니 GET으로 값을 보낼 때는 보통 쿼리를 사용합니다.

HEAD: 헤더만 받는다

HEAD는 GET과 똑같이 동작하지만 응답에 본문을 담지 않습니다. 본문은 필요 없고 헤더만 확인하고 싶을 때 씁니다.

예를 들어 큰 파일을 내려받기 전에 Content-Length 헤더로 파일 크기를 확인하거나 Last-Modified 헤더로 자원이 언제 마지막으로 바뀌었는지 확인할 수 있습니다. 본문을 받지 않으니 전송량을 아낍니다.

POST: 데이터를 보내 처리를 요청한다

POST는 요청 본문에 담긴 데이터를 서버에 보내 처리해 달라고 요청할 때 보내는 메서드입니다. 회원가입 폼 제출이나 게시글 작성이 대표적입니다.

POST /users HTTP/1.1
Host: www.example.com
Content-Type: application/json

{"name": "kim", "email": "kim@example.com"}

POST로 보낸 데이터를 어떻게 처리할지는 서버가 정합니다. 새 자원을 만들 수도 있고 결제나 메일 발송처럼 자원을 만드는 것과는 거리가 먼 작업을 처리할 수도 있습니다. 이렇다 보니 다른 메서드로 표현하기 애매한 작업은 POST로 처리하는 경우가 많습니다.

POST로 새 자원을 만들었다면 서버는 보통 201 Created 상태코드와 함께 새 자원의 위치를 알려 줍니다. 이 내용은 아래 상태코드 부분에서 다시 살펴보겠습니다.

PUT: 자원을 통째로 바꾼다

PUT은 요청 본문의 내용으로 대상 자원을 통째로 바꿉니다. 대상 자원이 없으면 새로 만듭니다.

PUT /users/1 HTTP/1.1
Host: www.example.com
Content-Type: application/json

{"name": "lee", "email": "lee@example.com"}

POST와 달리 자원의 위치(URI)를 클라이언트가 정한다는 점이 다릅니다. POST /users는 “사용자를 하나 만들어 달라”는 요청이라 새 사용자가 몇 번이 될지 서버가 정합니다. 반면 PUT /users/1은 “1번 사용자를 이 내용으로 바꿔 달라”고 클라이언트가 위치를 직접 지정합니다.

통째로 바꾼다는 것에 주의해야 합니다. 기존 자원에 name, email, age가 있었는데 PUT으로 name과 email만 보내면 서버는 age가 빠진 내용으로 자원을 덮어씁니다.

PATCH: 자원의 일부만 바꾼다

자원의 일부만 바꿀 때는 PATCH를 씁니다.

PATCH /users/1 HTTP/1.1
Host: www.example.com
Content-Type: application/json

{"email": "new@example.com"}

위 요청은 1번 사용자의 이메일만 바꾸고 나머지 값은 그대로 둡니다. 일부만 바꾸고 싶은데 PUT을 쓰면 바꾸지 않을 값까지 모두 보내야 합니다. 이럴 때는 PATCH가 알맞습니다.

DELETE: 자원을 삭제한다

DELETE는 대상 자원을 삭제해 달라고 요청할 때 보냅니다.

DELETE /users/1 HTTP/1.1
Host: www.example.com

삭제에 성공하면 서버는 보통 돌려줄 본문이 없으므로 204 No Content로 응답합니다. 삭제 작업이 오래 걸려 아직 끝나지 않았다면 202 Accepted로 응답할 수도 있습니다.

OPTIONS: 통신 옵션을 확인한다

OPTIONS는 대상 자원이 어떤 메서드와 옵션을 지원하는지 물어볼 때 보내는 요청입니다. 서버는 지원하는 메서드 목록을 Allow 헤더에 담아 돌려줄 수 있습니다.

HTTP/1.1 204 No Content
Allow: GET, POST, OPTIONS

개발자가 직접 OPTIONS 요청을 보낼 일은 많지 않지만 브라우저는 자주 보냅니다. CORS 사전 요청(Preflight Request)에 OPTIONS를 쓰기 때문입니다. 사전 요청은 다른 출처(도메인)의 서버에 특정 요청을 보내기 전에 보내도 되는지를 미리 확인하는 요청입니다.

메서드의 세 가지 속성: 안전, 멱등, 캐시 가능

메서드는 단순히 하는 일로만 구분하지 않고 “안전한지?”, “이 요청을 다시 보내도 괜찮을지?”, “결과를 저장해 놓고 다시 사용해도 될지?”로도 구분합니다.

메서드	안전	멱등	캐시 가능
GET	O	O	O
HEAD	O	O	O
OPTIONS	O	O	X
POST	X	X	△
PUT	X	O	X
PATCH	X	X	△
DELETE	X	O	X
CONNECT	X	X	X
TRACE	O	O	X

안전(Safe)

요청해도 서버의 자원을 바꾸지 않는 메서드를 안전한 메서드라고 합니다. GET, HEAD, OPTIONS, TRACE가 여기에 해당합니다.

여기서 “바꾸지 않는다”는 것은 클라이언트가 자원의 변경을 요청하지 않는다는 뜻입니다. 서버가 요청을 받으면서 접속 로그를 남기거나 조회수를 올리는 것까지 막지는 않습니다.

안전한 메서드는 서버의 자원을 바꾸지 않는다고 기대할 수 있기 때문에 검색 엔진의 크롤러는 링크를 따라가며 마음 놓고 GET 요청을 보냅니다. 만약 GET /posts/1/delete 같은 주소로 게시글을 삭제하도록 만들어 두었다면 크롤러가 링크를 따라오는 것만으로 게시글이 지워질 수 있습니다. 자원을 바꾸는 작업에 GET을 쓰면 안 되는 이유입니다.

멱등(Idempotent)

같은 요청을 한 번 보내든 여러 번 보내든 서버에 남는 결과가 같은 메서드를 멱등한 메서드라고 합니다. 안전한 메서드는 애초에 자원을 바꾸지 않으므로 모두 멱등합니다. 안전하지 않은 메서드 중에서는 PUT과 DELETE가 멱등합니다.

• PUT /users/1을 여러 번 보내도 1번 사용자는 같은 내용으로 덮어쓰일 뿐이므로 결과가 같습니다.
• DELETE /users/1을 여러 번 보내도 1번 사용자는 삭제된 상태로 남으므로 결과가 같습니다.
• POST /users를 여러 번 보내면 그때마다 새 사용자가 생기므로 멱등하지 않습니다.

멱등성은 서버에 남는 결과를 기준으로 판단합니다. 응답까지 같아야 하는 것은 아닙니다. DELETE /users/1을 두 번 보내면 첫 번째는 204 No Content, 두 번째는 이미 없으니 404 Not Found를 받을 수 있지만 1번 사용자가 없다는 결과는 같습니다.

PATCH는 멱등하다고 보장되지 않습니다. 위 예시처럼 이메일 값을 바꾸는 요청은 여러 번 보내도 결과가 같지만 “포인트를 100 늘려라”처럼 현재 값을 기준으로 바꾸는 요청은 보낼 때마다 결과가 달라지기 때문입니다.

그렇다면 멱등성은 왜 중요할까요? 요청을 보냈는데 응답을 받기 전에 네트워크가 끊겼다고 해 보겠습니다. 클라이언트는 서버가 요청을 처리했는지 알 수 없습니다. 멱등한 요청이라면 결과가 같으니 다시 보내도 안전합니다. 반면 결제 같은 POST 요청을 무작정 다시 보내면 결제가 두 번 될 수도 있습니다. 그래서 자동 재시도는 보통 멱등한 요청에만 적용합니다.

캐시 가능(Cacheable)

응답을 저장해 두었다가 다음 요청에 재사용할 수 있는 메서드를 캐시 가능한 메서드라고 부릅니다. GET과 HEAD가 여기에 해당합니다.

표준은 POST와 PATCH의 응답도 특정 조건을 만족하면 캐시할 수 있다고 정해 두었습니다. 하지만 실제로는 대부분의 캐시가 GET과 HEAD의 응답만 저장하므로 위 표에서는 △로 표시했습니다.

HTTP 상태코드

이제 응답 쪽을 살펴보겠습니다. 서버는 응답 메시지의 첫 줄인 상태 라인에 요청을 어떻게 처리했는지 적어서 돌려줍니다.

HTTP/1.1 404 Not Found

여기서 404가 상태코드(Status Code)이고 뒤의 Not Found는 상태코드를 사람이 읽기 쉽게 풀어 쓴 이유 구문(Reason Phrase)입니다.

범위에 따른 상태코드 의미

상태코드는 세 자리 정수이고 첫 번째 자리가 응답의 종류를 나타냅니다.

범위	분류	의미
1xx	정보	요청을 받았고, 처리를 계속하고 있다
2xx	성공	요청을 성공적으로 처리했다
3xx	리다이렉션	요청을 마치려면 클라이언트의 추가 동작이 필요하다
4xx	클라이언트 에러	클라이언트의 요청에 문제가 있다
5xx	서버 에러	요청은 올바르지만 서버가 처리하지 못했다

에러가 났을 때 첫 자리만 봐도 누구 쪽 문제인지 감이 옵니다. 4로 시작하면 요청을 보낸 쪽(클라이언트)을, 5로 시작하면 서버 쪽을 먼저 살펴보면 됩니다.

1xx: 정보

요청을 받았고 처리가 진행 중이라는 중간 안내입니다. 실무에서 직접 볼 일은 드문 편입니다. AI에게 물어보니 그나마 자주 보는 것이 WebSocket 연결을 맺을 때 쓰이는 101 Switching Protocols라고 하네요..! (처음 알았습니다..)

WebSocket 연결은 항상 HTTP 요청으로 시작합니다. HTTP/1.1에서는 클라이언트가 Upgrade: websocket 헤더를 담아 “프로토콜을 바꾸자”고 요청하면 서버가 101로 동의합니다. 그 직후부터 같은 연결에서 HTTP 대신 WebSocket으로 데이터를 주고받습니다.

2xx: 성공

요청을 성공적으로 처리한 경우입니다. 자주 쓰는 코드는 다음 네 가지입니다.

코드	이름	의미
200	OK	요청을 성공적으로 처리했다
201	Created	요청을 처리해서 새로운 자원을 만들었다
202	Accepted	요청은 받았지만, 처리는 아직 끝나지 않았다
204	No Content	요청은 성공했지만, 돌려줄 본문이 없다

201 Created

POST나 PUT으로 새 자원을 만들었을 때는 Location 헤더에 생성된 자원의 위치를 담아 보낼 수 있습니다. 여기서 위치는 DB 테이블이나 파일 경로 같은 저장 위치가 아니라 클라이언트가 그 자원을 찾아갈 수 있는 URI를 말합니다.

HTTP/1.1 201 Created
Location: /users/42

클라이언트는 이 주소로 다시 요청해서 방금 만든 자원을 조회할 수 있습니다.

202 Accepted

요청은 잘 받았지만 요청한 작업은 아직 끝나지 않았다는 응답입니다. 끝날 때까지 응답을 붙잡고 있기에는 오래 걸리는 작업에 씁니다. 대용량 파일 업로드 후 처리 작업이나 배치 작업이 그렇습니다.

202는 “받았다”는 뜻일 뿐, 작업이 성공한다는 보장은 아닙니다. 처리 도중 실패할 수도 있으므로 결과는 나중에 따로 확인해야 합니다.

204 No Content

요청은 성공했지만 응답 본문에 담을 내용이 없을 때 돌려주는 코드입니다. 앞에서 본 것처럼 DELETE로 자원을 삭제하는 데 성공했다면 굳이 돌려줄 데이터가 없으니 204로 응답할 수 있습니다.

3xx: 리다이렉션

리다이렉션(Redirection)은 클라이언트가 요청한 자원이 다른 곳에 있을 때, 클라이언트의 요청을 그곳으로 이동시키는 것입니다.

이때 서버는 응답 메시지의 Location 헤더에 자원이 실제로 있는 URL을 담아 보냅니다. 클라이언트(브라우저)는 이 헤더를 보고 새 URL로 자동으로 다시 요청합니다.

서버가 Location 헤더로 새 URL을 알려 주면 브라우저가 그 URL로 다시 요청한다

영구적인 리다이렉션과 일시적인 리다이렉션

리다이렉션은 크게 두 가지로 나뉩니다.

• 영구적 리다이렉션(301, 308): 자원이 완전히 새로운 곳으로 옮겨 가서 경로가 영구적으로 바뀐 경우입니다. 도메인을 이전하는 것처럼 웹 사이트를 크게 개편할 때 씁니다. 클라이언트는 다음부터 새 URL로 요청해도 됩니다.
• 일시적 리다이렉션(302, 303, 307): 자원의 위치가 잠시 바뀌었거나 임시로 다른 URL을 써야 하는 경우입니다. 원래 URL은 여전히 유효하므로 클라이언트는 원래 URL을 기억해 두고 다음 요청도 원래 URL로 보내야 합니다.

차이는 다음 방문 때 드러난다. 영구적이면 새 URL로, 일시적이면 원래 URL로 요청한다

재요청할 때 메서드가 바뀔까?

같은 종류의 리다이렉션인데도 코드가 여러 개인 이유는 새 URL로 다시 요청할 때 메서드를 유지하는지가 다르기 때문입니다.

코드	이름	종류	재요청 메서드
301	Moved Permanently	영구적	바뀔 수 있다 (POST → GET)
308	Permanent Redirect	영구적	바뀌지 않는다
302	Found	일시적	바뀔 수 있다 (POST → GET)
303	See Other	일시적	GET으로 바뀐다
307	Temporary Redirect	일시적	바뀌지 않는다

원래 HTTP 명세는 302로 리다이렉트할 때 메서드를 바꾸지 말라고 정했습니다. 하지만 대부분의 브라우저가 POST 요청을 302로 리다이렉트받으면 GET으로 바꿔서 다시 요청했고 이 동작이 사실상 표준처럼 굳어졌습니다. 그래서 HTTP/1.1에서 의도를 분명히 밝히는 코드를 따로 만들었습니다. 반드시 GET으로 바꾸라는 303과 절대 바꾸지 말라는 307입니다. 이후 301에 대응하는 308도 추가되었습니다.

303이 자주 쓰이는 곳은 글 작성처럼 POST 요청을 처리한 뒤 결과 페이지를 GET으로 보여 주는 경우입니다. 이렇게 해 두면 사용자가 새로고침을 눌러도 POST 요청이 다시 전송되지 않습니다. 앞에서 본 것처럼 POST는 멱등하지 않으니 같은 글이 두 번 작성되는 일을 막을 수 있습니다.

303으로 결과 페이지를 GET으로 보여 주면 새로고침해도 POST가 다시 전송되지 않는다

304 Not Modified

304는 3xx에 속하지만 다른 URL로 보내는 코드가 아니라 캐시와 관련된 코드입니다. 자원이 변경되지 않았음을 의미합니다.

클라이언트가 “내가 캐시해 둔 자원이 아직 최신인가?”라고 물으면(조건부 요청) 서버는 바뀐 게 없을 때 본문 없이 304만 돌려줍니다. 클라이언트는 이 응답을 받고 캐시해 둔 자원을 그대로 씁니다. 같은 자원을 다시 내려받지 않으니 전송량이 줄어듭니다.

자원이 바뀌지 않았으면 서버는 본문 없이 304만 돌려주고, 브라우저는 캐시를 그대로 쓴다

4xx: 클라이언트 에러

클라이언트의 요청에 문제가 있어서 처리하지 못한 경우입니다.

코드	이름	의미
400	Bad Request	요청의 형식이나 값이 잘못되었다
401	Unauthorized	인증되지 않았다
403	Forbidden	자원에 접근할 권한이 없다
404	Not Found	요청한 자원을 찾을 수 없다
405	Method Not Allowed	요청한 자원이 해당 메서드를 지원하지 않는다

401 Unauthorized와 403 Forbidden

두 코드는 자주 헷갈리는데 구분하려면 먼저 인증과 인가의 차이를 알아야 합니다.

• 인증(Authentication): 자신이 누구인지 증명하는 것입니다. 로그인이 대표적입니다.
• 인가(Authorization): 인증된 주체에게 특정 작업을 허용하는 것입니다. 권한 부여라고도 합니다.

회사 건물에 비유하면 사원증을 찍고 건물에 들어가는 것이 인증이고 사원증으로 특정 사무실에 들어갈 수 있는지가 인가입니다.

구분	401 Unauthorized	403 Forbidden
실패한 단계	인증	인가
서버의 판단	“누구인지 모르겠다”	“누구인지는 알지만, 권한이 없다”
회사 건물 비유	사원증이 없어서 건물에 못 들어감	사원증은 있지만 다른 부서 사무실이라 못 들어감
다시 로그인하면	해결될 수 있다	같은 계정으로는 해결되지 않는다

401의 이름은 Unauthorized(인가되지 않음)이지만 실제 의미는 인증되지 않음에 가깝습니다. 이 점을 기억해 두면 덜 헷갈립니다.

401로 응답할 때 서버는 WWW-Authenticate 헤더로 어떤 방식으로 인증해야 하는지를 함께 밝혀야 합니다.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

405 Method Not Allowed

요청한 자원이 해당 메서드를 지원하지 않을 때의 응답입니다. 예를 들어 조회만 가능한 자원에 DELETE 요청을 보내면 405를 받을 수 있습니다. 이때 서버는 OPTIONS의 응답처럼 Allow 헤더에 사용할 수 있는 메서드 목록을 담아 보내야 합니다.

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

5xx: 서버 에러

요청 자체는 올바르지만 서버 쪽 문제로 처리하지 못했다는 뜻입니다.

500 Internal Server Error

서버 내부에서 발생한 에러를 통칭하는 포괄적인 코드입니다. 서버 코드에서 처리하지 못한 예외가 발생했을 때 가장 흔히 보게 됩니다.

502 Bad Gateway

실제 서비스에서는 클라이언트와 서버가 일대일로 바로 연결되는 경우가 드뭅니다. 그 사이에 게이트웨이, 프록시 같은 중간 서버가 있는 경우가 많습니다. 대표적인 예가 리버스 프록시(Reverse Proxy)입니다. Nginx처럼 서버 앞에 두는 중간 서버로, 요청을 대신 받아 뒤쪽 서버로 넘겨 줍니다. (클라이언트 쪽에서 요청을 대신 보내 주는 포워드 프록시(Forward Proxy)도 있는데 두 프록시의 차이는 다른 글에서 따로 정리해 보겠습니다.)

502는 중간 서버가 뒤쪽 서버에게서 올바른 응답을 받지 못했을 때 클라이언트에게 돌려주는 코드입니다.

502는 Nginx가 돌려주지만, 실패한 곳은 그 뒤의 애플리케이션 서버다

502를 보내는 건 중간 서버이지만, 문제는 보통 그 뒤에 있습니다. Nginx 자체는 정상적으로 동작하면서 “뒤쪽 서버가 제대로 답하지 않는다”고 알려 주는 것입니다. 그래서 502가 나면 Nginx보다 애플리케이션 서버가 살아 있는지, 에러로 죽지는 않았는지부터 확인하는 것이 좋습니다.

503 Service Unavailable

서버가 일시적으로 요청을 처리할 수 없는 상태임을 알리는 코드입니다. 요청이 몰려 과부하가 걸렸거나 점검 중이라 잠시 서비스를 멈춘 경우에 돌려줍니다. Retry-After 헤더에 언제 다시 시도하면 되는지 담아 보낼 수도 있습니다.

마무리를 하면서

지금까지 HTTP 메서드와 상태코드에 대해 정리해 봤습니다. 메서드는 더 깊게 파고들 수도 있고 상태코드도 이번에 소개한 것보다 훨씬 많습니다. 그래도 이번 글에서는 꼭 알아야 할 부분만 골라서 정리해 보았습니다. 나머지는 필요할 때 그때그때 찾아보면 되니까요. (요즘은 AI가 다 알려 주긴 하지만요!)

이번 포스팅의 핵심을 정리해 보면 다음과 같습니다.

• 메서드는 자원에 어떤 작업을 할지 알려 줍니다. 조회는 GET, 처리 요청은 POST, 전체 교체는 PUT, 일부 수정은 PATCH, 삭제는 DELETE를 씁니다.
• POST는 자원의 위치를 서버가 정하고 PUT은 클라이언트가 정합니다.
• 안전한 메서드는 서버의 자원을 바꾸지 않고 멱등한 메서드는 여러 번 보내도 서버에 남는 결과가 같습니다. 멱등한 요청은 실패했을 때 다시 보내도 안전합니다.
• 상태코드는 세 자리 정수이고 첫 자리로 정보(1xx), 성공(2xx), 리다이렉션(3xx), 클라이언트 에러(4xx), 서버 에러(5xx)를 구분합니다.
• 201은 Location 헤더로 생성된 자원의 위치를, 202는 작업이 아직 끝나지 않았음을 알려 줍니다.
• 리다이렉션은 영구적(301, 308)과 일시적(302, 303, 307)으로 나뉘고 재요청할 때 메서드를 유지하는지에 따라 코드가 다릅니다.
• 304는 리다이렉트가 아니라 “캐시해 둔 걸 그대로 쓰라”는 뜻입니다.
• 401은 인증 실패, 403은 인가 실패입니다.
• 502는 중간 서버가 뒤쪽 서버에게서 올바른 응답을 받지 못했을 때 돌려주는 코드입니다.

긴 글 읽느라 고생 많으셨습니다. 다음 포스팅에서는 HTTP 헤더에 대해 자세하게 정리해 보겠습니다. 감사합니다.