HTTP 상태 코드(Status Code) 정리

HTTP 상태 코드 완전 정리. 200, 404, 500은 알겠는데 401과 403의 차이는? 204는 언제 쓰지? 백엔드 개발자가 API를 설계할 때 꼭 알아야 할 HTTP 상태 코드를, 자주 쓰는 것 위주로 실무 기준과 함께 정리한다.

---

들어가며

API를 만들다 보면 "이 상황엔 무슨 상태 코드를 줘야 하지?" 하고 멈칫하는 순간이 온다. 성공이면 200, 못 찾으면 404 정도는 외우지만, 막상 "잘못된 요청인데 401이야 400이야?", "삭제 성공은 200이야 204야?" 같은 데서 헷갈린다.

HTTP 상태 코드는 단순한 숫자가 아니라, 서버가 클라이언트에게 결과를 알려주는 약속된 언어다. 제대로 쓰면 API를 쓰는 사람이 응답만 보고도 무슨 일이 일어났는지 안다. 반대로 아무 코드나 던지면(다 200으로 주거나) API의 신뢰도가 떨어진다.

좋은 API는 상태 코드만 봐도 무슨 일이 일어났는지 알 수 있다. 상태 코드는 응답의 요약이다.

이 글에서는 HTTP 상태 코드를 분류별로, 그리고 실무에서 자주 쓰는 것 위주로 정리한다.

---

5개의 큰 분류

상태 코드는 세 자리 숫자이고, 맨 앞자리가 그 성격을 나타낸다. 이것만 알아도 절반은 안다.

분류	의미	한 줄 요약
1xx	정보	요청을 받았고 처리 중 (거의 직접 안 씀)
2xx	성공	요청이 정상 처리됨
3xx	리다이렉션	다른 곳으로 이동해야 함
4xx	클라이언트 오류	요청한 쪽의 잘못
5xx	서버 오류	서버 쪽의 잘못

핵심은 4xx와 5xx의 구분이다. 4xx는 "네가 잘못 보냈어"(클라이언트 책임), 5xx는 "내가 처리하다 터졌어"(서버 책임)다. 이 구분만 명확해도 API가 훨씬 읽기 쉬워진다.

---

2xx — 성공

요청이 성공했을 때다. 그냥 다 200으로 주는 경우가 많은데, 상황에 맞게 나눠 쓰면 더 명확하다.

코드	이름	언제 쓰나
200	OK	일반적인 성공 (조회, 수정 등)
201	Created	리소스 생성 성공 (POST로 새 데이터 생성)
202	Accepted	요청은 받았으나 처리는 아직 (비동기 작업)
204	No Content	성공했지만 응답 본문이 없음 (삭제 등)

실무 포인트를 짚으면:

• POST로 생성하면 201이 정석이다. 새 사용자를 만들었으면 200보다 201이 의미가 분명하다. 보통 Location 헤더에 생성된 리소스의 URL을 함께 준다.
• DELETE 성공은 204가 깔끔하다. 지웠으니 돌려줄 본문이 없다. 물론 삭제 결과 메시지를 주고 싶으면 200도 괜찮다.
• 202는 비동기용이다. "엑셀 10만 건 처리해줘" 같은 오래 걸리는 작업을 큐에 넣고 "접수했어"라고 답할 때 쓴다.

# 사용자 생성 성공
POST /users
→ HTTP/1.1 201 Created
   Location: /users/42

# 사용자 삭제 성공
DELETE /users/42
→ HTTP/1.1 204 No Content

---

4xx — 클라이언트 오류

가장 자주, 그리고 가장 많이 헷갈리는 영역이다. 요청한 쪽에 문제가 있을 때다.

코드	이름	언제 쓰나
400	Bad Request	요청 형식·값이 잘못됨 (검증 실패)
401	Unauthorized	인증 안 됨 (로그인 필요)
403	Forbidden	인증은 됐으나 권한 없음
404	Not Found	리소스가 존재하지 않음
405	Method Not Allowed	허용되지 않은 HTTP 메서드
409	Conflict	현재 상태와 충돌 (중복 등)
422	Unprocessable Entity	형식은 맞으나 의미상 처리 불가
429	Too Many Requests	요청 횟수 초과 (속도 제한)

401 vs 403 — 가장 헷갈리는 한 쌍

이 둘의 차이가 면접 단골이자 실무 혼란의 주범이다.

• 401 Unauthorized: "너 누구인지 모르겠어." 인증 자체가 안 됐다. 로그인을 안 했거나 토큰이 없거나 만료됐을 때. 사실 이름이 "Unauthorized(인가)"인데 의미는 "Unauthenticated(인증)"라서 더 헷갈린다.
• 403 Forbidden: "너가 누구인지는 알아. 근데 이건 권한이 없어." 로그인은 했지만 그 리소스에 접근할 자격이 없을 때. 일반 사용자가 관리자 API를 호출한 경우.

토큰 없이 요청        → 401 (누군지 모름)
일반 유저가 /admin   → 403 (누군지 알지만 권한 없음)

OWASP 접근 제어 관점에서도 이 구분은 중요하다. 다만 보안상 "리소스 존재 자체를 숨기고 싶을 때"는 403 대신 404를 주기도 한다.

400 vs 422 — 형식이냐 의미냐

• 400: 요청 자체가 망가짐. JSON 문법 오류, 필수 필드 누락 등.
• 422: 형식은 맞는데 비즈니스 규칙 위반. 예를 들어 "나이"에 음수를 보냈거나, 이미 가입된 이메일로 가입 시도. (프레임워크에 따라 400으로 통일해 쓰기도 한다.)

409 Conflict와 429

• 409: "이미 존재하는 이메일입니다" 같은 충돌 상황. 동시 수정으로 인한 버전 충돌에도 쓴다.
• 429: API 호출이 너무 잦을 때. OWASP의 무제한 리소스 소비 방어와 직결된다. 보통 Retry-After 헤더로 "언제 다시 시도하라"를 알려준다.

---

5xx — 서버 오류

서버가 요청을 처리하다 실패했을 때다. 이건 클라이언트 잘못이 아니다.

코드	이름	언제 쓰나
500	Internal Server Error	서버 내부에서 처리되지 않은 예외
502	Bad Gateway	게이트웨이/프록시가 잘못된 응답 받음
503	Service Unavailable	서버 과부하·점검으로 일시 불가
504	Gateway Timeout	게이트웨이가 응답을 기다리다 타임아웃

실무 포인트:

• 500은 "잡지 못한 예외"의 신호다. NullPointerException 같은 게 그대로 터지면 500이 나간다. 500이 자주 보인다면 코드에 버그가 있다는 뜻이다.
• 502/504는 보통 인프라 문제다. 로드밸런서 뒤의 서버가 죽었거나(502), 응답이 너무 느릴 때(504). API 서버 코드보다 게이트웨이·네트워크를 봐야 한다.
• 503은 점검·과부하용이다. 의도적으로 "지금은 서비스 못 해"라고 알릴 때 쓴다.

중요한 건, 클라이언트 잘못을 500으로 주면 안 된다는 점이다. 잘못된 입력은 400번대로 줘야 한다. 다 500으로 주면, API를 쓰는 쪽이 "내 잘못인지 서버 잘못인지" 구분을 못 한다.

---

자주 하는 실수

실무에서 흔히 보는 안티패턴들이다.

1. 전부 200으로 주기
가장 흔한 실수. 에러가 나도 200을 주고 본문에 {"success": false}를 담는 식이다. 이러면 HTTP 표준의 이점을 통째로 버리는 것이다. 클라이언트가 매번 본문을 까봐야 성공/실패를 안다.

2. 클라이언트 오류를 500으로 주기
검증 실패(400이어야 할 것)를 처리 안 해서 예외가 터지고 500이 나가는 경우. 입력 검증을 제대로 하면 4xx로 정확히 응답할 수 있다.

3. 401과 403을 섞어 쓰기
인증 안 된 걸 403으로, 권한 없는 걸 401로 주는 혼란. 위의 구분을 기억하자.

4. 에러 응답에 정보가 없음
상태 코드만 주고 끝내지 말고, 본문에 "무엇이 왜 잘못됐는지"를 담아주는 게 좋다.

// 좋은 에러 응답 예시
{
  "status": 400,
  "code": "INVALID_EMAIL",
  "message": "이메일 형식이 올바르지 않습니다",
  "field": "email"
}

---

마치며

HTTP 상태 코드는 외우는 게 목적이 아니라, API를 쓰는 사람과의 약속이다. 핵심만 다시 짚으면 이렇다. 앞자리로 성격을 가르고(2xx 성공, 4xx 클라이언트 잘못, 5xx 서버 잘못), 자주 쓰는 것(200·201·204·400·401·403·404·409·429·500)만 정확히 쓰면 대부분의 상황을 깔끔하게 표현할 수 있다.

특히 401과 403의 구분, 그리고 "클라이언트 오류는 4xx, 서버 오류는 5xx"라는 원칙만 지켜도 API의 품질이 눈에 띄게 올라간다. 상태 코드를 제대로 쓰는 API는, 문서를 덜 봐도 동작을 예측할 수 있다. 그게 좋은 API의 조건이다.

---

참고 출처

• MDN: HTTP response status codes — https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
• RFC 9110: HTTP Semantics — https://www.rfc-editor.org/rfc/rfc9110.html
• httpstatuses.com — https://httpstatuses.com/