앞자리로 읽는 법
상태 코드는 세 자리이고 첫 자리가 성격을 정합니다. 1xx는 중간 정보, 2xx는 성공, 3xx는 다른 곳으로 가라는 안내, 4xx는 요청한 쪽의 잘못, 5xx는 서버의 잘못입니다. 모르는 코드를 만나도 앞자리만으로 누가 고쳐야 하는지 알 수 있습니다. 4xx면 요청 내용·주소·인증을, 5xx면 서버 로그를 먼저 봅니다. 이 표는 브라우저에 내장되어 있어 검색 내용이 외부로 나가지 않습니다.
자주 혼동하는 쌍
401 vs 403: 401은 "누군지 모르겠다"(로그인하면 해결), 403은 "누군지 알지만 안 된다"(로그인해도 안 됨)입니다. 301 vs 302 vs 307/308: 301·308은 영구, 302·307은 임시입니다. 301·302는 브라우저가 POST를 GET으로 바꿔 따라가는 오래된 관행이 있어, 메서드를 유지해야 하는 API에서는 307·308을 씁니다. 502 vs 503 vs 504: 셋 다 프록시 뒤 문제이지만 502는 뒤 서버가 이상한 응답을 줬거나 죽었고, 503은 서버가 스스로 "지금 못 한다"고 했고, 504는 뒤 서버가 제때 응답하지 않은 것입니다. 400 vs 422: 400은 JSON이 깨진 것처럼 형식 자체가 틀릴 때, 422는 형식은 맞지만 값이 규칙에 어긋날 때(이메일 형식 오류 등) 쓰는 것이 최근 관행입니다.
API 설계에서의 선택
생성은 201, 본문 없는 성공은 204, 비동기 접수는 202를 쓰면 클라이언트가 응답을 더 정확히 다룰 수 있습니다. 중복 생성은 409, 권한 없는 리소스 존재를 숨기려면 403 대신 404, 레이트 리밋은 429에 Retry-After를 붙입니다. 반대로 모든 오류를 200에 {"success": false}로 감싸는 방식은 HTTP 캐시·모니터링·브라우저 동작과 어긋나므로 피하는 것이 좋습니다.
표준이 아닌 코드
Nginx의 499(클라이언트가 응답 전에 연결 끊음), Cloudflare의 520~530(원본 서버 문제 세분화), 일부 프레임워크의 419·440 등은 표준 목록에 없습니다. 브라우저 개발자 도구에 그런 코드가 보이면 해당 제품 문서를 찾아야 합니다. 2022년 RFC 9110에서 413은 "Payload Too Large"에서 "Content Too Large"로, 422는 "Unprocessable Entity"에서 "Unprocessable Content"로 이름이 바뀌었고, 이 표는 새 이름을 따릅니다.
자주 묻는 질문
404와 410의 차이는요?
404는 "없다"만 말하고 410은 "있었는데 영구히 지웠다"를 명시합니다. 검색엔진은 410을 받으면 색인을 더 빨리 제거합니다.
304는 오류인가요?
아닙니다. 브라우저가 "이 파일 바뀌었나?"라고 물었을 때 "안 바뀌었으니 캐시 써라"라는 정상 응답입니다. 개발자 도구에 많이 보여도 문제가 아닙니다.
CORS 오류는 무슨 코드인가요?
CORS 차단은 상태 코드가 아니라 브라우저가 응답을 JS에 넘기지 않는 것입니다. 서버는 200을 줬을 수 있으며, 콘솔의 CORS 메시지와 Access-Control-Allow-Origin 헤더를 확인해야 합니다.