HTTP 상태 코드: 완전한 참조 가이드

2026년 3월 31일 · 12분 읽기

HTTP 상태 코드란 무엇인가?

HTTP 상태 코드는 클라이언트의 요청에 대한 응답으로 서버가 반환하는 세 자리 숫자입니다. 요청이 성공했는지, 리디렉션되었는지, 오류가 발생했는지를 나타냅니다. 브라우저가 페이지를 로드하거나, API를 호출하거나, 양식을 제출할 때마다 서버는 상태 코드로 응답합니다.

상태 코드는 서버가 요청에 대해 무슨 일이 일어났는지 전달하는 방식이라고 생각하면 됩니다. 신호등이 멈추거나 가라고 알려주는 것처럼, 상태 코드는 애플리케이션에 계속 진행할지, 재시도할지, 오류를 처리할지 알려줍니다.

상태 코드는 첫 번째 숫자를 기준으로 다섯 가지 범주로 그룹화됩니다:

• 1xx (정보): 요청을 받았으며 처리가 계속됩니다
• 2xx (성공): 요청을 받았고, 이해했으며, 수락되었습니다
• 3xx (리디렉션): 요청을 완료하기 위해 추가 작업이 필요합니다
• 4xx (클라이언트 오류): 요청에 클라이언트 측 오류가 포함되어 있습니다
• 5xx (서버 오류): 서버가 유효한 요청을 처리하지 못했습니다

상태 코드 작동 방식

클라이언트(브라우저나 API 클라이언트 등)가 HTTP 요청을 하면 서버가 이를 처리하고 응답을 반환합니다. 이 응답에는 항상 첫 번째 줄에 상태 코드가 포함되며, 그 뒤에 헤더와 선택적 본문이 따라옵니다.

일반적인 HTTP 응답은 다음과 같습니다:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1234

{"status": "success", "data": {...}}

상태 코드는 HTTP 버전 바로 뒤에 나타납니다. 이 예제에서 200 OK는 클라이언트에게 요청이 성공했음을 알려줍니다.

상태 코드는 여러 목적으로 사용됩니다:

• 통신: 서버가 결과를 전달하는 표준화된 방법을 제공합니다
• 오류 처리: 애플리케이션이 코드에 따라 다양한 시나리오를 프로그래밍 방식으로 처리할 수 있습니다
• 디버깅: 개발자가 요청-응답 주기에서 문제가 발생한 위치를 빠르게 식별할 수 있습니다
• SEO: 검색 엔진이 상태 코드를 사용하여 콘텐츠 색인 방법을 이해합니다
• 캐싱: 브라우저와 CDN이 코드를 사용하여 캐싱 동작을 결정합니다

1xx 정보

정보 상태 코드는 서버가 요청을 받았으며 계속 처리 중임을 나타냅니다. 이는 임시 응답이며 일상적인 웹 브라우징에서는 거의 볼 수 없지만, 특정 프로토콜과 최적화에 중요합니다.

100 Continue

서버가 요청 헤더를 받았으며 클라이언트가 본문을 전송해야 합니다. 이는 클라이언트가 전체 페이로드를 보내기 전에 서버가 요청을 수락할지 확인하기 위해 Expect: 100-continue 헤더를 보내는 대용량 업로드에 사용됩니다.

이 최적화는 거부될 요청에 대한 대역폭 낭비를 방지합니다. 예를 들어, 500MB 비디오 파일을 업로드하는 경우 인증 실패로 인해 서버가 거부할 것이라는 사실을 알게 된 후에야 모든 데이터를 보내고 싶지 않을 것입니다.

POST /upload HTTP/1.1
Host: api.example.com
Content-Length: 524288000
Expect: 100-continue

// 서버가 100 Continue로 응답
// 그런 다음 클라이언트가 요청 본문을 전송

101 Switching Protocols

서버가 클라이언트가 요청한 대로 프로토콜 전환에 동의합니다. Upgrade: websocket 헤더를 사용하여 HTTP에서 WebSocket으로 업그레이드할 때 가장 일반적으로 볼 수 있습니다.

WebSocket은 클라이언트와 서버 간의 실시간 양방향 통신을 가능하게 하며, 이는 채팅 애플리케이션, 실시간 업데이트 및 협업 도구에 필수적입니다.

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

// 서버가 101 Switching Protocols로 응답

103 Early Hints

이 비교적 새로운 상태 코드를 사용하면 서버가 최종 응답 전에 예비 헤더를 보낼 수 있습니다. 서버가 여전히 주 응답을 준비하는 동안 CSS, 글꼴 및 JavaScript 파일과 같은 리소스를 미리 로드하는 데 자주 사용됩니다.

Early Hints는 브라우저가 페이지 로드 프로세스 초기에 중요한 리소스 다운로드를 시작할 수 있도록 하여 페이지 로드 시간을 크게 개선할 수 있습니다.

2xx 성공

성공 코드는 보고 싶은 것입니다. 요청이 성공적으로 수신, 이해 및 수락되었음을 나타냅니다. 다양한 2xx 코드는 요청이 정확히 어떻게 처리되었는지에 대한 세밀한 정보를 제공합니다.

200 OK

표준 성공 응답입니다. 요청이 성공했으며 응답 본문에 요청된 데이터가 포함되어 있습니다. 이것은 웹에서 가장 일반적인 상태 코드입니다.

데이터를 반환하는 성공적인 GET 요청, 생성된 리소스 데이터를 반환하는 성공적인 POST 요청, 업데이트된 리소스 데이터를 반환하는 성공적인 PUT/PATCH 요청에 200 OK를 사용하세요.

GET /api/users/123 HTTP/1.1

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 123, "name": "John Doe", "email": "[email protected]"}

201 Created

새 리소스가 성공적으로 생성되었습니다. 이것은 새 리소스를 생성하는 POST 요청에 대한 적절한 응답입니다. 응답에는 새로 생성된 리소스를 가리키는 Location 헤더가 포함되어야 합니다.

POST /api/users HTTP/1.1
Content-Type: application/json

{"name": "Jane Smith", "email": "[email protected]"}

HTTP/1.1 201 Created
Location: /api/users/124
Content-Type: application/json

{"id": 124, "name": "Jane Smith", "email": "[email protected]"}

202 Accepted

요청이 처리를 위해 수락되었지만 처리가 완료되지 않았습니다. 이는 서버가 나중에 처리하기 위해 요청을 대기열에 넣는 비동기 작업에 유용합니다.

일반적인 사용 사례에는 배치 처리, 이메일 전송, 비디오 인코딩 및 HTTP 응답을 차단해서는 안 되는 기타 장기 실행 작업이 포함됩니다.

204 No Content

요청이 성공했지만 반환할 콘텐츠가 없습니다. 이는 일반적으로 DELETE 요청이나 클라이언트가 업데이트된 리소스를 반환할 필요가 없는 PUT/PATCH 요청에 사용됩니다.

빈 본문이 있는 200 OK 대신 204 No Content를 사용하면 대역폭이 절약되고 의도가 명확하게 전달됩니다.

DELETE /api/users/123 HTTP/1.1

HTTP/1.1 204 No Content

206 Partial Content

서버가 클라이언트가 보낸 범위 헤더로 인해 리소스의 일부만 전달하고 있습니다. 이를 통해 클라이언트가 특정 바이트 범위를 요청하는 재개 가능한 다운로드 및 비디오 스트리밍이 가능합니다.

비디오 플레이어는 전체 파일을 먼저 다운로드하지 않고도 비디오의 다른 부분으로 탐색할 수 있도록 이를 광범위하게 사용합니다.

3xx 리디렉션

리디렉션 코드는 클라이언트가 요청을 완료하기 위해 추가 작업을 수행해야 함을 나타냅니다. 이는 URL 관리, SEO 및 리소스가 이동할 때 이전 버전과의 호환성을 유지하는 데 중요합니다.

301 Moved Permanently

리소스가 Location 헤더에 지정된 새 URL로 영구적으로 이동했습니다. 브라우저와 검색 엔진은 새 URL을 사용하도록 기록을 업데이트해야 합니다.

이것은 영구 리디렉션을 위한 기본 상태 코드입니다. 검색 엔진은 이전 URL에서 새 URL로 SEO 가치를 전송하고 브라우저는 리디렉션을 캐시합니다.

GET /old-page HTTP/1.1

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

302 Found (Temporary Redirect)

리소스가 일시적으로 다른 URL에 있습니다. 클라이언트는 향후 요청에 대해 원래 URL을 계속 사용해야 합니다. 검색 엔진은 이 리디렉션으로 SEO 가치를 전송하지 않습니다.

일반적인 사용 사례에는 A/B 테스트, 유지 관리 페이지 및 임시 프로모션 페이지가 포함됩니다.

303 See Other

요청에 대한 응답은 GET을 사용하여 다른 URL에서 찾을 수 있습니다. 이는 일반적으로 POST 요청 후 결과 페이지로 리디렉션하는 데 사용되며, 사용자가 새로고침할 경우 중복 양식 제출을 방지합니다.

이것은 웹 양식의 모범 사례인 Post/Redirect/Get 패턴을 구현합니다.

304 Not Modified

요청 헤더(If-Modified-Since 또는 If-None-Match)에 지정된 버전 이후 리소스가 수정되지 않았습니다. 클라이언트는 캐시된 버전을 사용할 수 있습니다.

이는 콘텐츠가 변경되지 않았을 때 불필요한 데이터 전송을 피함으로써 대역폭 사용을 크게 줄이고 성능을 향상시킵니다.

307 Temporary Redirect

302와 유사하지만 리디렉션될 때 요청 메서드가 변경되지 않음을 보장합니다. 원래 요청이 POST였다면 리디렉션된 요청도 POST가 됩니다.

308 Permanent Redirect

301과 유사하지만 요청 메서드가 변경되지 않음을 보장합니다. 이것은 엄격한 메서드 보존이 필요한 API 및 애플리케이션을 위한 301의 현대적이고 더 정확한 버전입니다.

4xx 클라이언트 오류

클라이언트 오류 코드는 요청에 잘못된 구문이 포함되어 있거나 클라이언트 측 문제로 인해 처리할 수 없음을 나타냅니다. 이러한 오류는 클라이언트가 재시도하기 전에 요청을 수정해야 함을 의미합니다.

400 Bad Request

서버가 잘못된 구문, 잘못된 요청 메시지 프레이밍 또는 기만적인 요청 라우팅으로 인해 요청을 처리할 수 없습니다. 이것은 다른 4xx 범주에 맞지 않는 요청에 대한 일반적인 오류입니다.

일반적인 원인으로는 잘못된 JSON, 필수 필드 누락, 잘못된 데이터 유형 또는 API 제약 조건을 위반하는 요청이 있습니다.

POST /api/users HTTP/1.1
Content-Type: application/json

{"name": "John", "email": "not-an-email"}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error": "Invalid email format"}

401 Unauthorized

인증이 필요하며 실패했거나 제공되지 않았습니다. 이름과 달리 실제로는 "인증되지 않음"을 의미합니다. 클라이언트가 유효한 자격 증명을 제공해야 합니다.

응답에는 필요한 인증 방법을 나타내는 WWW-Authenticate 헤더가 포함되어야 합니다.

GET /api/protected-resource HTTP/1.1

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

{"error": "Authentication required"}

403 Forbidden

서버가 요청을 이해했지만 승인을 거부합니다. 401과 달리 인증이 도움이 되지 않습니다. 클라이언트가 이 리소스에 액세스할 권한이 없습니다.

사용자가 인증되었지만 필요한 권한이 없거나 IP 주소, 속도 제한 또는 기타 정책에 의해 액세스가 제한된 경우 이를 사용하세요.