아래 블로그는 chat GPT와 MDN을 참조해서 작성 했습니다.
HTTP 응답 상태 코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려줍니다. 응답은 5개의 그룹으로 나누어집니다: 정보를 제공하는 응답, 성공적인 응답, 리다이렉트, 클라이언트 에러, 그리고 서버 에러. 상태 코드는 section 10 of RFC 2616에 정의되어 있습니다.
100번대 HTTP 상태 코드: 정보 응답(Informational Responses)
100번대 HTTP 상태 코드는 클라이언트가 보낸 요청을 서버가 정상적으로 수신했으며, 추가 작업이 필요하다는 것을 의미합니다. 이 상태 코드는 최종 응답이 아니며, 요청을 계속 진행해도 된다는 신호를 클라이언트에게 제공합니다.
-
100 Continue
클라이언트가 Expect: 100-continue 헤더를 보냈을 때, 서버가 요청을 수락했음을 나타냅니다.
클라이언트는 요청 본문을 계속해서 전송할 수 있습니다. 예를 들어, 대용량 파일을 업로드할 때 본문을 전송하기 전에 서버의 승인을 받을 수 있습니다. 예) 파일 업로드 전, 서버에서 업로드 가능 여부 확인 -
101 Switching Protocols
클라이언트가 Upgrade 헤더를 사용해 다른 프로토콜(예: HTTP/1.1 → WebSocket)로 변경을 요청했을 때, 서버가 이를 승인했다는 의미입니다. 웹 브라우저와 서버 간의 실시간 통신을 위해 WebSocket으로 업그레이드할 때 사용됩니다.
예) HTTP를 WebSocket으로 변경할 때 -
102 Processing (WebDAV)
WebDAV 확장에서 사용되며, 서버가 요청을 처리 중임을 나타냅니다. 일반적으로 긴 시간이 걸리는 작업(예: 여러 개의 파일을 한 번에 처리하는 경우)에서 클라이언트가 요청이 멈춘 것이 아니라 진행 중임을 알리는 역할을 합니다. 예) 긴 시간이 걸리는 WebDAV 요청 처리 -
103 Early Hints
HTTP/2 및 HTTP/3에서 사용되며, 본 응답 이전에 클라이언트에게 Link 헤더를 제공하여 필요한 리소스를 미리 가져올 수 있도록 도와줍니다. 예를 들어, HTML 문서를 로딩하기 전에 CSS, JS 등의 리소스를 미리 다운로드할 수 있도록 유도하여 페이지 로딩 속도를 향상시킬 수 있습니다. 예) 웹 페이지의 리소스를 미리 로딩하여 성능 개선
200번대 HTTP 상태 코드: 성공 응답(Successful Responses)
200번대 HTTP 상태 코드는 클라이언트의 요청이 정상적으로 처리되었음을 의미합니다.
이 상태 코드는 주로 요청이 성공적으로 완료되었을 때 서버가 반환하는 응답입니다.
-
200 OK
클라이언트의 요청이 성공적으로 처리되었으며, 응답 본문에 요청한 리소스가 포함될 수 있습니다.
예) 웹 페이지 로드, API 요청 성공 -
201 Created
요청이 성공적으로 처리되었으며, 새로운 리소스가 생성되었음을 의미합니다.
예) 계정 생성, 블로그 글 작성 -
202 Accepted
요청이 수락되었지만, 아직 처리되지 않았음을 나타냅니다. 서버가 요청을 받았지만 처리가 비동기적으로 이루어질 때 사용됩니다.
예) 비동기 작업 요청(예: 대량 이메일 전송) -
203 Non-Authoritative Information
원본 서버가 아닌 프록시 서버가 제공한 응답일 때 사용됩니다. 원본 데이터가 변경되었을 가능성이 있어 신뢰도가 낮을 수 있습니다.
예) 캐시된 데이터를 반환할 때 -
204 No Content
요청이 성공적으로 처리되었지만, 응답 본문이 없음을 의미합니다.
예) 데이터 삭제 요청 후 응답 필요 없음 -
205 Reset Content
클라이언트가 입력 양식을 초기화해야 함을 의미합니다.
예) 폼 데이터를 제출한 후 입력 필드를 비우는 경우 -
206 Partial Content
클라이언트가Range헤더를 사용하여 일부만 요청했을 때 반환됩니다.
예) 동영상 스트리밍, 대용량 파일 다운로드 -
207 Multi-Status (WebDAV)
여러 개의 상태 코드가 포함될 수 있으며, WebDAV에서 주로 사용됩니다.
예) 다중 파일 작업 처리 시 개별 상태 코드 반환 -
208 Already Reported (WebDAV)
동일한 리소스가 중복 보고되는 것을 방지하는 용도로 사용됩니다.
예) 반복적인 WebDAV 응답에서 중복 제거 -
226 IM Used
서버가 클라이언트 요청을 받아 변형된 응답을 제공했음을 의미합니다.
예) 서버에서 데이터에 추가적인 변형을 적용한 경우
300번대 HTTP 상태 코드: 리다이렉트 응답(Redirection Responses)
300번대 HTTP 상태 코드는 요청한 리소스의 위치가 변경되었거나, 클라이언트가 추가적인 작업을 수행해야 함을 의미합니다.
-
300 Multiple Choices
하나 이상의 리소스가 요청에 대해 제공될 수 있으며, 클라이언트가 선택해야 함을 의미합니다.
예) 여러 개의 동영상 포맷(예: MP4, AVI) 중 선택 가능 -
301 Moved Permanently
요청한 리소스가 영구적으로 새로운 URL로 이동되었으며, 이후에는 변경된 URL을 사용해야 합니다.
예) 웹사이트 도메인을 변경했을 때 리디렉션 처리 -
302 Found
요청한 리소스가 일시적으로 다른 URL에 있으며, 원래 URL이 그대로 유지됨을 의미합니다.
예) 로그인 후 특정 페이지로 일시적으로 이동 -
303 See Other
클라이언트가 GET 요청을 사용하여 다른 URL에서 리소스를 가져오도록 안내하는 응답입니다.
예) 폼 제출 후 결과 페이지로 이동 -
304 Not Modified
클라이언트가 요청한 리소스가 변경되지 않았음을 의미하며, 캐시된 버전을 사용해야 합니다.
예) 브라우저 캐시를 활용하여 리소스를 재다운로드하지 않음 -
305 Use Proxy (Deprecated)
요청한 리소스를 가져오기 위해 프록시를 사용해야 함을 의미하지만, 보안상의 이유로 현재는 거의 사용되지 않습니다. -
306 (Unused)
현재는 사용되지 않는 상태 코드입니다. -
307 Temporary Redirect
302 Found와 유사하지만, 요청 메서드가 변경되지 않음을 보장합니다.
예) POST 요청이 리다이렉트될 때 여전히 POST로 유지됨 -
308 Permanent Redirect
301 Moved Permanently와 유사하지만, 요청 메서드가 변경되지 않음을 보장합니다.
예) PUT 요청이 영구적으로 새로운 URL로 이동되었을 때
400번대 HTTP 상태 코드: 클라이언트 오류 응답(Client Error Responses)
400번대 HTTP 상태 코드는 클라이언트의 요청에 오류가 있거나, 요청을 수행할 권한이 없음을 의미합니다.
-
400 Bad Request
요청이 잘못되어 서버가 이해할 수 없음을 의미합니다.
예) 잘못된 JSON 형식의 요청, 필수 파라미터 누락 -
401 Unauthorized
인증이 필요하지만 제공되지 않았거나, 인증에 실패했음을 의미합니다.
예) 로그인하지 않은 상태에서 보호된 페이지에 접근 -
402 Payment Required
현재는 거의 사용되지 않지만, 결제가 필요한 리소스에서 사용될 가능성이 있습니다.
예) 유료 API 서비스에서 결제 필요 -
403 Forbidden
서버가 요청을 이해했지만, 권한이 없어 요청을 거부함을 의미합니다.
예) 관리 권한이 없는 사용자가 관리자 페이지에 접근하려고 할 때 -
404 Not Found
요청한 리소스를 찾을 수 없음을 의미합니다.
예) 존재하지 않는 페이지에 접근 -
405 Method Not Allowed
요청한 HTTP 메서드(GET,POST,PUT등)가 허용되지 않음을 의미합니다.
예)GET만 지원하는 API에POST요청을 보냈을 때 -
406 Not Acceptable
클라이언트가 요청한 데이터 형식이 서버에서 지원되지 않을 때 사용됩니다.
예) API에서application/xml을 요청했지만, 서버가JSON만 지원할 때 -
407 Proxy Authentication Required
요청을 수행하기 전에 프록시 서버에서 인증이 필요함을 의미합니다. -
408 Request Timeout
클라이언트가 서버의 응답을 너무 오래 기다려서 요청이 종료됨을 의미합니다.
예) 인터넷 연결이 불안정한 상태에서 요청이 지연될 때 -
409 Conflict
요청이 서버의 현재 상태와 충돌하여 수행할 수 없음을 의미합니다.
예) 동일한 리소스를 여러 사용자가 동시에 수정하려고 할 때 -
410 Gone
요청한 리소스가 영구적으로 삭제되었음을 의미합니다.
예) 오래된 API 엔드포인트가 폐기된 경우 -
411 Length Required
요청에Content-Length헤더가 포함되지 않아 서버가 처리를 거부함을 의미합니다. -
412 Precondition Failed
요청이 사전 조건을 만족하지 않아 거부됨을 의미합니다.
예) 특정 버전의 리소스를 수정하려고 했으나, 서버의 최신 버전과 일치하지 않을 때 -
413 Payload Too Large
요청 본문의 크기가 서버가 허용하는 한도를 초과했음을 의미합니다.
예) 업로드 파일 크기가 서버의 제한을 초과할 때 -
414 URI Too Long
요청한 URL이 너무 길어 서버가 처리할 수 없음을 의미합니다.
예) GET 요청에서 너무 많은 쿼리 파라미터를 포함한 경우 -
415 Unsupported Media Type
요청 본문의 콘텐츠 타입이 서버에서 지원하지 않는 형식일 때 사용됩니다.
예) 서버가application/json만 허용하는데,application/xml을 전송한 경우 -
416 Range Not Satisfiable
클라이언트가 요청한Range헤더의 값이 리소스 범위를 벗어날 때 사용됩니다.
예) 동영상 스트리밍에서 잘못된 범위를 요청한 경우 -
417 Expectation Failed
클라이언트의Expect헤더 요구 사항을 서버가 충족할 수 없음을 의미합니다. -
418 I’m a teapot (Easter Egg)
RFC 2324에서 정의된 유머 상태 코드로, 실제로 사용되지는 않습니다. -
421 Misdirected Request
서버가 요청을 처리할 수 없는 잘못된 경로로 전달되었음을 의미합니다. -
422 Unprocessable Entity (WebDAV)
요청의 문법은 올바르지만, 의미적으로 처리할 수 없음을 의미합니다.
예) 필수 입력 값이 누락된 경우 -
423 Locked (WebDAV)
요청한 리소스가 잠겨 있어 수정할 수 없음을 의미합니다.
예) 다른 사용자가 파일을 편집하는 동안 락이 걸린 경우 -
424 Failed Dependency (WebDAV)
요청이 다른 요청에 종속되어 있으며, 해당 요청이 실패했기 때문에 수행할 수 없음을 의미합니다. -
425 Too Early
요청을 너무 일찍 보냈기 때문에 보안상 위험이 있어 서버가 거부했음을 의미합니다. -
426 Upgrade Required
클라이언트가 요청을 처리하기 위해 다른 프로토콜로 업그레이드해야 함을 의미합니다.
예) HTTP를 HTTPS로 업그레이드해야 하는 경우 -
428 Precondition Required
요청이 특정한 조건을 포함해야 하지만, 그렇지 않기 때문에 서버가 거부한 경우입니다.
예)If-Match헤더 없이 업데이트를 요청한 경우 -
429 Too Many Requests
클라이언트가 너무 많은 요청을 보내서 서버가 일시적으로 요청을 차단함을 의미합니다.
예) API 요청 속도 제한(레이트 리미트)에 걸린 경우 -
431 Request Header Fields Too Large
요청 헤더가 너무 커서 서버가 처리할 수 없음을 의미합니다. -
451 Unavailable For Legal Reasons
법적 이유로 인해 요청한 리소스에 접근할 수 없음을 의미합니다.
예) 정부 규제로 인해 특정 웹사이트가 차단된 경우
500번대 HTTP 상태 코드: 서버 오류 응답(Server Error Responses)
500번대 HTTP 상태 코드는 서버가 요청을 처리하는 중에 문제가 발생했음을 의미합니다.
클라이언트의 요청에는 문제가 없지만, 서버 측에서 오류가 발생했을 때 반환됩니다.
-
500 Internal Server Error
서버에서 예기치 않은 오류가 발생하여 요청을 처리할 수 없음을 의미합니다.
예) 서버 코드 오류, 데이터베이스 연결 실패 -
501 Not Implemented
서버가 요청한 기능을 지원하지 않음을 의미합니다.
예) 서버가 특정 HTTP 메서드(예:PATCH)를 지원하지 않는 경우 -
502 Bad Gateway
서버가 게이트웨이 또는 프록시 역할을 하고 있으며, 업스트림 서버로부터 잘못된 응답을 받았을 때 반환됩니다.
예) Nginx 또는 Apache가 백엔드 서버와의 통신에 실패한 경우 -
503 Service Unavailable
서버가 과부하 상태이거나 유지보수 중이라 요청을 처리할 수 없음을 의미합니다.
예) 트래픽 폭증으로 인해 웹사이트가 다운된 경우 -
504 Gateway Timeout
서버가 게이트웨이 또는 프록시 역할을 하고 있으며, 업스트림 서버의 응답 시간이 초과되었음을 의미합니다.
예) 백엔드 서버가 응답하지 않아 API 요청이 실패한 경우 -
505 HTTP Version Not Supported
서버가 요청에서 사용된 HTTP 프로토콜 버전을 지원하지 않음을 의미합니다.
예) HTTP/1.0 요청을 보냈지만, 서버가 HTTP/2.0만 지원하는 경우 -
506 Variant Also Negotiates
서버가 요청을 처리하는 중에 내부적인 구성 오류가 발생했음을 의미합니다.
예) 콘텐츠 협상 과정에서 무한 루프가 발생한 경우 -
507 Insufficient Storage (WebDAV)
서버가 요청을 완료하기에 충분한 저장 공간을 가지고 있지 않음을 의미합니다.
예) 클라우드 저장소 용량 초과 -
508 Loop Detected (WebDAV)
서버가 요청을 처리하는 중 무한 루프를 감지했음을 의미합니다.
예) WebDAV 요청 중 순환 참조가 발생한 경우 -
510 Not Extended
서버가 요청을 처리하기 위해 추가 확장이 필요하지만, 현재 지원하지 않는 경우에 반환됩니다.
예) 특정 확장 기능이 활성화되지 않은 API 요청 -
511 Network Authentication Required
네트워크 인증이 필요하며, 클라이언트가 먼저 로그인해야 함을 의미합니다.
예) 공공 Wi-Fi에서 로그인 페이지로 리디렉션되기 전 상태
🚀 웹 개발자가 특히 주목해야 할 HTTP 상태 코드
✅ 1. 성공(Success) 응답
200 OK
- 요청이 정상적으로 처리되었음을 의미합니다.
- 언제 사용될까?
- API에서 데이터를 성공적으로 조회했을 때
- 웹 페이지가 정상적으로 로딩되었을 때
201 Created
- 요청이 성공적으로 처리되었고, 새로운 리소스가 생성됨을 의미합니다.
- 언제 사용될까?
- 회원가입이 완료되었을 때
- 게시글이 작성되었을 때
204 No Content
- 요청이 성공적으로 처리되었지만, 응답 본문이 필요 없는 경우.
- 언제 사용될까?
- 데이터를 삭제한 후, 추가적인 응답이 필요 없을 때
- PUT/PATCH 요청 후 별도의 응답이 필요 없을 때
🔄 2. 리다이렉트(Redirection) 응답
301 Moved Permanently
- 요청한 리소스가 영구적으로 새로운 URL로 이동되었음을 의미합니다.
- 언제 사용될까?
- 도메인을 변경했을 때 (
example.com→new-example.com) - SEO 최적화를 위해 특정 URL을 영구적으로 이동시킬 때
- 도메인을 변경했을 때 (
302 Found (Temporary Redirect)
- 요청한 리소스가 임시적으로 다른 URL에 있으며, 나중에는 원래 URL을 사용해야 함.
- 언제 사용될까?
- 로그인 후 특정 페이지로 리디렉트할 때
- 유지보수 모드에서 임시 페이지로 리디렉트할 때
304 Not Modified
- 클라이언트가 요청한 리소스가 이전 버전과 동일하여, 기존 캐시된 데이터를 사용하도록 지시함.
- 언제 사용될까?
- 브라우저 캐시를 활용하여 불필요한 데이터 다운로드를 방지할 때
- CDN 및 프록시 서버에서 캐시된 콘텐츠를 유지할 때
⚠️ 3. 클라이언트 오류(Client Error) 응답
400 Bad Request
- 클라이언트의 요청이 잘못되었음을 의미함.
- 언제 사용될까?
- 필수 입력값이 누락되었을 때
- 잘못된 JSON 형식으로 API 요청을 보냈을 때
401 Unauthorized
- 인증(Authentication) 정보가 없거나 올바르지 않음.
- 언제 사용될까?
- 로그인되지 않은 사용자가 보호된 리소스에 접근할 때
- API 요청에서 올바른 토큰을 제공하지 않았을 때
403 Forbidden
- 서버가 요청을 이해했지만, 권한이 없어서 거부됨.
- 언제 사용될까?
- 관리자가 아닌 사용자가 관리자 페이지에 접근할 때
- 특정 사용자에게 제한된 API를 호출할 때
404 Not Found
- 요청한 리소스를 찾을 수 없음을 의미함.
- 언제 사용될까?
- 존재하지 않는 페이지에 접근했을 때
- 잘못된 URL을 입력했을 때
405 Method Not Allowed
- 요청한 HTTP 메서드(
GET,POST,PUT,DELETE등)가 허용되지 않음. - 언제 사용될까?
GET만 허용하는 API에POST요청을 보냈을 때DELETE요청을 지원하지 않는 엔드포인트를 호출했을 때
409 Conflict
- 요청이 서버의 현재 상태와 충돌하여 수행할 수 없음.
- 언제 사용될까?
- 중복된 사용자 이메일로 회원가입을 시도할 때
- 여러 사용자가 동시에 같은 데이터를 수정할 때
429 Too Many Requests
- 클라이언트가 너무 많은 요청을 보내서 서버가 일시적으로 차단함.
- 언제 사용될까?
- API 요청 속도 제한(레이트 리미트)에 걸렸을 때
- 로그인 시도를 너무 많이 해서 계정이 일시적으로 잠겼을 때
💥 4. 서버 오류(Server Error) 응답
500 Internal Server Error
- 서버에서 예기치 않은 오류가 발생하여 요청을 처리할 수 없음.
- 언제 사용될까?
- 서버 코드에 버그가 있을 때
- 데이터베이스 연결이 실패했을 때
502 Bad Gateway
- 서버가 다른 서버(예: 프록시, 게이트웨이)로부터 잘못된 응답을 받았을 때.
- 언제 사용될까?
- 프록시 서버(Nginx, Apache)가 백엔드 서버로부터 유효한 응답을 받지 못했을 때
- API 게이트웨이가 다운되었을 때
503 Service Unavailable
- 서버가 과부하 상태이거나 유지보수 중이라 요청을 처리할 수 없음.
- 언제 사용될까?
- 서버가 트래픽 과부하로 인해 다운되었을 때
- 유지보수를 위해 서비스가 일시적으로 중단되었을 때
504 Gateway Timeout
- 서버가 다른 서버로부터 응답을 기다리는 중 시간이 초과됨.
- 언제 사용될까?
- 백엔드 API 서버의 응답이 너무 느릴 때
- 데이터베이스가 과부하 상태일 때
여기서 생기는 궁금증
🤔 HTTP 상태 코드를 꼭 준수해야 하나?
HTTP 상태 코드는 클라이언트와 서버 간의 원활한 통신을 위해 정의된 표준 규칙입니다.
하지만 실제 개발에서는 항상 이 표준을 엄격하게 따라야 하는지 고민되는 경우가 있습니다.
HTTP 상태 코드를 꼭 준수해야 할까요? 아니면 상황에 따라 유연하게 사용해도 될까요?
✅ 상태 코드를 준수해야 하는 이유
- 클라이언트가 올바르게 동작하도록 하기 위해
- HTTP 상태 코드는 서버가 클라이언트에게 현재 요청의 결과를 알리는 신호입니다.
- 예를 들어:
- 성공하면 200 OK
- 리소스를 찾을 수 없으면 404 Not Found
- 요청이 잘못되었으면 400 Bad Request - 만약 표준을 따르지 않고 모든 요청에 200 OK를 반환한다면?
- 클라이언트는 “요청이 성공했다”고 오해할 수 있습니다.
- API를 사용하는 개발자는 “이게 에러인지 정상인지” 혼란스러워질 수 있습니다.
- 검색 엔진(SEO) 및 캐시 최적화를 위해
- 검색 엔진(Google, Bing 등)은 404 Not Found를 보고 “이 페이지는 존재하지 않는다”고 판단합니다.
- 301 Moved Permanently를 사용하면, 검색 엔진은 새로운 URL을 인덱싱합니다.
- CDN 및 프록시 서버는 304 Not Modified를 보고 캐시된 데이터를 유지하여 성능을 최적화합니다.
- 하지만 서버가 항상 200 OK를 반환하면?
- 검색 엔진이 삭제된 페이지를 여전히 인덱싱할 수도 있습니다.
- 캐시 서버가 데이터를 불필요하게 다시 다운로드할 수도 있습니다.
- API 설계에서의 일관성 유지
- RESTful API에서는 요청의 결과를 상태 코드로 전달하는 것이 일반적입니다.
- 예를 들어,
POST /users요청이 중복된 이메일일 경우:
409 Conflict를 반환하는 것이 RESTful한 방식입니다. - 만약200 OK + { "error": "User already exists" }형식으로 응답한다면?- API 소비자는 “이게 성공인지 실패인지” 헷갈릴 수 있습니다.
❌ 상태 코드를 엄격하게 준수하지 않아도 되는 경우
- 비표준적인 비즈니스 로직이 필요한 경우
- 일부 웹사이트는 404 Not Found 페이지를 보여주면서도 200 OK를 반환하기도 합니다.
- 예를 들어, 사용자 경험을 고려해 “이 페이지를 찾을 수 없습니다”라는 커스텀 페이지를 제공하면서도,
상태 코드를 404가 아닌 200으로 설정할 수 있습니다. - 하지만 SEO 문제를 유발할 수 있으므로 신중한 선택이 필요합니다.
- 특정 클라이언트와의 호환성을 위해
- 일부 레거시 시스템이나 특정 브라우저는 표준 HTTP 상태 코드에 대한 지원이 부족할 수 있습니다.
- 이 경우, 클라이언트가 정상적으로 작동하도록 하기 위해 비표준적인 상태 코드를 반환해야 할 수도 있습니다.
- SEO(검색 엔진 최적화)를 우회하기 위한 트릭
- 웹사이트에서 검색 엔진 크롤러를 속이기 위해 모든 페이지에 200 OK를 반환하는 경우도 있습니다.
- 하지만 검색 엔진이 이를 감지하면 오히려 패널티를 받을 수 있으므로, 추천되는 방법은 아닙니다.
🔥 결론: “상황에 따라 다르지만, 표준을 따르는 것이 일반적으로 더 좋다”
- 대부분의 경우, HTTP 상태 코드를 준수하는 것이 가장 좋습니다.
- 하지만 특수한 상황(SEO 전략, 레거시 시스템 대응, 사용자 경험 개선 등)에서는 약간의 유연성이 필요할 수도 있습니다.
- 중요한 것은 클라이언트(브라우저, API 소비자, 검색 엔진)가 올바르게 동작하는지 고려하는 것입니다.
📌 HTTP 상태 코드는 왜 “약속”일까?
HTTP 상태 코드는 결국 서버와 클라이언트 간의 약속입니다.
기술적으로 서버는 어떤 상태 코드든 반환할 수 있지만, 표준을 따르는 것이 중요합니다.
🔍 HTTP 상태 코드는 왜 중요할까?
- 클라이언트와 서버가 원활하게 소통하기 위해
- HTTP는 클라이언트(브라우저, API 요청)와 서버 간의 데이터 교환 규칙입니다.
- 예를 들어, 클라이언트가
GET /user/123요청을 보냈을 때:
- 존재하는 사용자라면 200 OK
- 사용자가 없으면 404 Not Found - 만약 서버가 404 상황에서도 200 OK를 반환하면?
- 클라이언트가 “이 사용자는 존재하지 않는구나”라고 올바르게 이해하지 못할 수 있습니다.
- 검색 엔진, 프록시, 캐시 서버가 올바르게 동작하려면 필요함
- 검색 엔진(Google, Bing 등)은 404를 보면 해당 페이지가 없다고 판단하고 검색 결과에서 제외할 수 있습니다.
- CDN이나 프록시 서버는 304 Not Modified 같은 상태 코드를 활용하여 네트워크 트래픽을 최적화합니다.
- 만약 서버가 항상 200 OK를 반환하면?
- 검색 엔진이 “이 페이지는 정상적으로 존재하는구나”라고 잘못 판단할 수 있습니다.
- 캐시 서버가 불필요한 데이터를 다시 다운로드하여 성능이 저하될 수 있습니다.
- API 개발에서 표준을 따르면 유지보수가 쉬워짐
- RESTful API에서는 상태 코드를 표준에 맞게 반환하는 것이 일반적입니다.
- 예를 들어,
POST /users요청을 보냈을 때:
- 성공하면
201 Created - 중복된 이메일이면
409 Conflict - 필수 필드가 누락되면
400 Bad Request- 이렇게 하면 백엔드와 프론트엔드(혹은 API 소비자) 간의 협업이 쉬워집니다.
🧐 그렇다면, 200 OK를 반환해도 될까?
기술적으로 가능하지만, 좋은 선택은 아님.
- 일부 웹사이트에서는 존재하지 않는 페이지에서도 200 OK를 반환하고 “이 페이지를 찾을 수 없습니다” 메시지를 표시하는 경우가 있습니다.
- 📌 하지만 이 방식은 SEO(검색 엔진 최적화)에 문제가 생길 수 있습니다.
- Google 같은 검색 엔진은
404 Not Found를 반환하는 페이지는 검색 결과에서 제외하지만,
200 OK를 반환하면 “이 페이지는 정상적인 페이지다”라고 인식할 수 있습니다. - 결과적으로 잘못된 페이지가 검색 결과에 남을 가능성이 생깁니다.
- API에서는 특히 더 위험합니다.
- 클라이언트가
GET /users/999요청을 보냈을 때:- 존재하지 않는 사용자라면 404 Not Found를 반환하는 것이 RESTful 방식입니다.
- 그런데 서버가 200 OK +
{ "error": "User not found" }같은 응답을 주면?- 클라이언트가 “응답이 성공했네!”라고 오해하고 잘못된 처리를 할 수도 있습니다.
- API를 사용하는 개발자도 “이게 성공인지 실패인지?” 헷갈릴 수 있습니다.
- 클라이언트가
✅ 결론: 상태 코드는 약속이지만, 지키는 것이 좋다
- 서버는 원하는 상태 코드를 반환할 수 있지만, 표준을 지키는 것이 일반적으로 더 좋은 선택입니다.
- 상태 코드를 잘 활용하면 클라이언트, 검색 엔진, 프록시, API 소비자 모두에게 더 명확한 의미를 전달할 수 있습니다.
- 하지만 특수한 경우(SEO를 고려한 커스텀 처리, 레거시 시스템과의 호환 등)에서는 200 OK를 반환하는 것도 가능합니다.