| 1xx | 요청 처리 중 | 요청이 진행 중 |
| 2xx | 요청 성공 | 정상 처리 완료 |
| 3xx | 리다이렉션 | 다른 위치로 이동 필요 |
| 4xx | 클라이언트 오류 | 사용자 요청 문제 |
| 5xx | 서버 오류 | 서버 내부 문제 |
1xx (Informational)
| 100 | Continue | 계속 요청 진행 |
| 101 | Switching Protocols | 프로토콜 전환 |
- 100 Continue
클라이언트가 보낸 요청 중 헤더를 서버가 정상적으로 확인했고, 이후 본문 데이터를 계속 보내도 된다는 의미입니다. 대용량 업로드나 API 요청에서 사용됩니다.
해결 방법: 일반적인 웹 사용에서는 문제가 아닙니다. 업로드 실패가 발생한다면 네트워크 불안정, 프록시 서버 제한, 요청 크기 제한(client_max_body_size 등)을 점검해야 합니다.
- 101 Switching Protocols
HTTP에서 WebSocket 등 다른 프로토콜로 전환할 때 발생합니다. 실시간 통신 기능에서 주로 사용됩니다.
해결 방법: 연결 실패 시 서버의 Upgrade 헤더 설정, WebSocket 엔드포인트 설정, 프록시(Nginx/Cloudflare) 통과 여부를 확인해야 합니다.
2xx (Success)
| 200 | OK | 정상 응답 |
| 201 | Created | 생성 완료 |
| 202 | Accepted | 요청 접수됨 |
| 204 | No Content | 응답 없음 |
- 200 OK
요청이 정상적으로 처리되고 데이터가 정상 반환된 상태입니다. 가장 일반적인 성공 응답입니다.
해결 방법: 문제 자체는 없지만, 반환 데이터가 예상과 다르다면 API 로직, DB 조회 조건, 필터링 로직을 점검해야 합니다. 프론트에서는 응답 파싱 구조가 변경되지 않았는지도 확인합니다.
- 201 Created
새로운 데이터가 성공적으로 생성된 상태입니다. 회원가입, 게시글 작성, 파일 업로드에서 자주 발생합니다.
해결 방법: 실제 DB에 데이터가 정상 저장되었는지 확인하고, 중복 생성 방지를 위한 unique key 또는 validation 로직이 있는지 점검해야 합니다. 응답 body에 생성된 resource 위치(Location header)가 포함되는지도 확인합니다.
- 202 Accepted
요청은 정상적으로 접수되었지만 처리는 아직 완료되지 않은 상태입니다. 비동기 작업(큐, 배치 처리)에서 사용됩니다.
해결 방법: 작업이 실제로 완료되는지 백그라운드 worker, queue 상태를 확인해야 합니다. 완료 상태를 확인할 수 있는 polling API 또는 callback(Webhook)이 있는지도 점검해야 합니다.
- 204 No Content
요청은 성공했지만 응답 데이터가 없는 상태입니다. 삭제 요청(DELETE) 후 자주 사용됩니다.
해결 방법: 프론트에서는 응답 body가 없을 수 있다는 점을 고려해야 합니다. null 처리 또는 상태 코드 기반 UI 처리 로직이 필요하며, 삭제 이후 UI 갱신(fetch, re-render)도 확인해야 합니다.
3xx (Redirection)
| 301 | Moved Permanently | 영구 이동 |
| 302 | Found | 임시 이동 |
| 303 | See Other | 다른 위치 참조 |
| 304 | Not Modified | 변경 없음 (캐시 사용) |
- 301 Moved Permanently
URL이 영구적으로 변경된 상태로, 검색 엔진도 새로운 URL을 기준으로 인덱싱합니다.
해결 방법: 서버 리다이렉트 설정(301 redirect)을 정확히 구성하고, 내부 링크, sitemap, canonical URL을 모두 새 주소로 변경해야 합니다. 기존 URL이 남아 있으면 SEO 중복 문제가 발생할 수 있습니다.
- 302 Found
임시로 다른 URL로 이동된 상태입니다. 이벤트 페이지, A/B 테스트에서 사용됩니다.
해결 방법: 장기간 사용할 경우 SEO 영향 때문에 301로 변경하는 것이 좋습니다. 캐시 또는 브라우저에 따라 예상과 다르게 동작할 수 있으므로 테스트가 필요합니다.
- 303 See Other
POST 요청 이후 결과 페이지를 GET으로 다시 요청할 때 사용됩니다.
해결 방법: 중복 요청 방지를 위해 redirect 흐름을 명확히 하고, form submit 이후 재전송 문제가 발생하지 않도록 처리해야 합니다.
- 304 Not Modified
캐시된 리소스가 최신이므로 서버가 다시 전송하지 않는 상태입니다.
해결 방법: 캐시 정책(Cache-Control, ETag, Last-Modified)을 점검하고, 의도치 않게 변경이 반영되지 않는 경우 캐시 무효화 설정을 조정해야 합니다.
4xx (Client Error)
| 400 | Bad Request | 잘못된 요청 |
| 401 | Unauthorized | 인증 필요 |
| 403 | Forbidden | 접근 금지 |
| 404 | Not Found | 페이지 없음 |
| 405 | Method Not Allowed | 메서드 오류 |
| 408 | Request Timeout | 요청 시간 초과 |
| 429 | Too Many Requests | 요청 과다 |
- 400 Bad Request
요청 데이터 형식이 잘못된 상태입니다. JSON 구조 오류, 필수 파라미터 누락 등이 원인입니다.
해결 방법: API 스펙과 비교하여 요청 body, query string, header 값을 검증해야 합니다. 서버에서는 validation 로직을 강화하고, 프론트에서는 입력값 검증을 추가해야 합니다.
- 401 Unauthorized
인증이 필요하거나 인증 토큰이 만료된 상태입니다.
해결 방법: 로그인 상태를 확인하고 JWT 또는 세션 토큰이 유효한지 점검해야 합니다. 토큰 만료 시 refresh token 로직이 정상 작동하는지도 확인합니다.
- 403 Forbidden
인증은 되었지만 해당 리소스 접근 권한이 없는 상태입니다.
해결 방법: 사용자 role, permission 설정을 점검하고, 서버의 access control 정책(ACL, RBAC)을 확인해야 합니다.
- 404 Not Found
요청한 페이지나 리소스가 존재하지 않는 상태입니다.
해결 방법: URL 오타, 라우팅 설정, 삭제된 리소스 여부를 확인합니다. SEO 관점에서는 301 리다이렉트 또는 410 처리도 고려해야 합니다.
- 405 Method Not Allowed
지원되지 않는 HTTP 메서드를 사용한 경우입니다.
해결 방법: API 문서 기준으로 GET, POST, PUT, DELETE 메서드가 올바르게 사용되는지 확인하고, 서버 라우팅 설정도 점검해야 합니다.
- 408 Request Timeout
요청이 서버에서 지정한 시간 안에 완료되지 않은 상태입니다.
해결 방법: 네트워크 상태, 서버 처리 시간, DB 쿼리 성능을 점검하고 timeout 값을 조정해야 합니다.
- 429 Too Many Requests
짧은 시간에 과도한 요청이 발생한 상태입니다. API rate limit에 걸린 경우입니다.
해결 방법: 요청 빈도를 줄이고, retry 로직에 delay/backoff 전략을 적용해야 합니다. 서버에서는 rate limit 정책을 조정하거나 IP/사용자별 제한을 설정해야 합니다.
5xx (Server Error)
| 500 | Internal Server Error | 서버 오류 |
| 502 | Bad Gateway | 게이트웨이 오류 |
| 503 | Service Unavailable | 서비스 불가 |
| 504 | Gateway Timeout | 응답 지연 |
- 500 Internal Server Error
서버 내부 코드 오류, 예외 처리 누락, DB 오류 등 다양한 원인으로 발생합니다.
해결 방법: 서버 로그를 최우선으로 확인하고 stack trace를 분석해야 합니다. 최근 배포된 코드 변경 사항을 롤백하거나, 예외 처리와 null handling을 강화해야 합니다.
- 502 Bad Gateway
프록시 서버(Nginx 등)가 upstream 서버로부터 정상 응답을 받지 못한 상태입니다.
해결 방법: 백엔드 서버 상태, 포트 연결, 방화벽 설정, API 서버 다운 여부를 점검해야 합니다.
- 503 Service Unavailable
서버가 과부하 상태이거나 유지보수 중입니다.
해결 방법: 트래픽 분산(load balancer), 서버 증설, 캐시 적용, 점검 모드 설정을 통해 안정성을 확보해야 합니다.
- 504 Gateway Timeout
서버가 다른 서버(API, DB)의 응답을 기다리다 시간 초과된 상태입니다.
해결 방법: 외부 API 속도 개선, DB 쿼리 최적화, timeout 설정 증가, 비동기 처리 구조로 변경하는 것이 필요합니다.
반응형