HTTP 상태코드¶

HTTP 상태코드란?¶

서버가 클라이언트 요청을 어떻게 처리했는지 알려주는 3자리 숫자다.

상태코드 종류¶

2xx — 성공¶

200 OK: 조회/수정 성공
201 Created: 리소스 생성 성공. POST 응답으로 주로 사용. Location 헤더에 생성된 리소스 URI를 함께 내려주는 것이 REST 스펙에 맞는 방식.
```
  HTTP/1.1 201 Created
  Location: /members/1

  {
    "id": 1,
    "name": "김철수"
  }
```
204 No Content: 성공했지만 응답 body 없음. DELETE 응답으로 주로 사용

3xx — 리다이렉션¶

301 Moved Permanently: 영구 이동 (URL이 바뀐 경우)
302 Found: 임시 이동. PRG 패턴에서 사용
304 Not Modified: 캐시 사용 (서버 데이터 변경 없음)

4xx — 클라이언트 오류¶

400 Bad Request: 요청 형식/값 자체가 잘못됨
401 Unauthorized: 인증 안 됨 (로그인 필요)
403 Forbidden: 인증은 됐지만 권한 없음
404 Not Found: 리소스 없음
405 Method Not Allowed: 해당 메서드 지원 안 함
409 Conflict: 리소스 충돌 (중복 이메일 가입 등)
422 Unprocessable Entity: 형식은 맞지만 비즈니스 규칙 위반

5xx — 서버 오류¶

500 Internal Server Error: 서버 내부 오류
502 Bad Gateway: 게이트웨이/프록시 오류
503 Service Unavailable: 서버 과부하 또는 점검 중

학습 우선순위¶

⭐ 반드시 알아야 하는 8개 (면접 + 실무 필수)¶

200 201 204 400 401 403 404 500

📌 알면 좋은 4개 (실무에서 종종 쓰임)¶

302 409 422 503

나머지¶

존재한다는 것만 알면 됨. 인프라/프레임워크가 알아서 내려주는 경우가 많음.

400 vs 422 vs 409 구분¶

상황	상태코드
이메일 형식이 아닌 값 입력 (`abc123`)	`400`
나이에 음수 입력 (`-1`)	`400`
잔액이 부족한데 결제 시도	`422`
미성년자인데 성인 서비스 가입 시도	`422`
이미 존재하는 이메일로 가입 시도	`409`
이미 좋아요 누른 게시글에 또 좋아요	`409`

실무에서는 422 없이 400으로 통일하는 팀도 많음. 면접에서는 세 가지를 구분할 줄 안다는 것만 보여주면 충분.

500 에러 처리 원칙¶

클라이언트에게 서버 내부 오류를 그대로 노출하면 안 된다.

이유 - 보안: 스택 트레이스, 클래스명, DB 쿼리 등 내부 정보가 노출되면 공격자에게 취약점을 알려주는 꼴 - UX: 기술적인 에러 메시지는 일반 사용자가 이해하지 못함

실무 처리 방식

{
  "status": 500,
  "message": "서버 오류가 발생했습니다. 잠시 후 다시 시도해주세요."
}

실제 에러 상세 내용은 서버 로그에만 남기고, 클라이언트에는 일반화된 메시지만 내려준다. Spring에서는 @ControllerAdvice + @ExceptionHandler로 전역 처리한다. (로드맵 9번에서 구현)

면접 답변 예시¶

Q. 401과 403의 차이를 설명해보세요.

401은 인증이 안 된 상태로, 로그인이 필요한 경우입니다. 403은 인증은 됐지만 해당 리소스에 대한 권한이 없는 경우입니다. 예를 들어 로그인하지 않고 마이페이지에 접근하면 401, 일반 유저가 관리자 페이지에 접근하면 403입니다.

Q. 로그인 API에서 비밀번호가 틀렸을 때 어떤 상태코드를 반환해야 할까요?

401 Unauthorized를 반환합니다. 비밀번호 오류는 요청 형식의 문제가 아니라 인증 실패이기 때문입니다. 또한 보안상 응답 메시지는 "이메일 또는 비밀번호가 올바르지 않습니다"로 통일합니다. "비밀번호가 틀렸습니다"처럼 구체적으로 알려주면 공격자가 이메일 존재 여부를 파악할 수 있기 때문입니다.