Network · 완벽 가이드 Ch.4 §3

HTTP 상태 코드에 대해서 설명해주세요

HTTP 상태 코드 5가지 클래스(1xx~5xx)를 인터랙티브 시각화로 완전 정복. 200·201·204·301·302·401·403·404·500의 정확한 의미와 REST API 설계에서 올바른 코드 선택법을 배웁니다.

2026년 3월 31일 · 약 12분 읽기

Q. "HTTP 상태 코드의 5가지 클래스를 설명하고, 401과 403의 차이를 말씀해주세요."

예상 꼬리질문

답변 가이드

HTTP 상태 코드는 클라이언트의 요청에 대해 서버가 반환하는 3자리 숫자 코드로, RFC 9110에 정의되어 있습니다. 첫 번째 자리에 따라 1xx(정보), 2xx(성공), 3xx(리다이렉션), 4xx(클라이언트 오류), 5xx(서버 오류)로 분류됩니다.

401 Unauthorized는 이름과 달리 "인증(Authentication)이 되지 않은 상태"를 의미합니다. 비로그인 상태에서 보호된 API를 호출할 때 반환됩니다. 반면 403 Forbidden은 인증은 되었으나 해당 리소스에 대한 인가(Authorization) 권한이 없는 상태입니다. 로그인한 일반 사용자가 관리자 전용 API를 호출하는 경우가 이에 해당합니다.

실무에서는 200 OK만 남용하는 패턴이 자주 문제가 됩니다. 에러 상황에서도 200을 반환하고 body에 에러 메시지를 담으면, 모니터링 시스템이 정상 응답과 오류를 구분하지 못하고, API 게이트웨이의 오류 감지 기능이 무력화됩니다. 의미에 맞는 상태 코드 사용이 시스템 가시성(observability)의 첫걸음입니다.

면접관이 정말 듣고 싶은 건 코드 번호 암기가 아닙니다. "이 상황에서 왜 이 코드를 써야 하는가"를 판단할 수 있는 설계 감각입니다. 인터랙티브 시각화로 5가지 클래스의 의미를 체득하고, 실무에서 혼동하기 쉬운 코드들을 비교해봅시다.

1. 5가지 클래스 한눈에 보기

첫 자리 숫자로 응답의 성격이 결정됩니다

HTTP 상태 코드는 첫 자리 숫자로 응답의 성격을 즉시 파악할 수 있도록 설계되었습니다. 1xx는 처리 중, 2xx는 성공, 3xx는 리다이렉션, 4xx는 클라이언트 오류, 5xx는 서버 오류입니다. 이 구조 덕분에 API를 호출하는 클라이언트는 상세 코드를 몰라도 첫 자리만으로 재시도 여부를 결정할 수 있습니다.

4xx와 5xx 구분은 특히 중요합니다. 4xx는 "클라이언트가 요청을 수정해야 해결된다"는 신호이므로 즉시 재시도가 의미 없습니다. 5xx는 "서버 문제"이므로 클라이언트는 나중에 재시도하면 됩니다.

클래스 버튼을 클릭하면 해당 클래스의 대표 코드들을 볼 수 있습니다. 각 코드 카드를 클릭하면 상세 설명이 펼쳐집니다.

2xx성공

요청 정상 처리 완료

카드를 클릭하면 상세 설명을 볼 수 있습니다

1xx는 일반 웹 개발에서 자주 마주치지 않지만, WebSocket 연결 수립 시 101 Switching Protocols를 볼 수 있습니다.

2. 2xx 성공 코드 — 상황에 맞는 선택

꼬리질문: "201 Created와 200 OK는 언제 구분해서 사용하나요?"

성공 응답이라고 모두 200 OK로 통일하면 안 됩니다. 리소스를 새로 만들었을 때는 201 Created, 반환할 내용이 없을 때는 204 No Content를 써야 API가 의미를 명확히 전달합니다. 특히 201은 Location 헤더에 생성된 리소스의 URI를 포함해야 클라이언트가 바로 활용할 수 있습니다.

HTTP 메서드 탭을 클릭하여 각 메서드에서의 올바른 성공 응답 코드를 확인해 보세요.

요청 (Request)

GET/api/users/1— 사용자 정보 조회
올바른 응답
200OK
{
  "id": 1,
  "name": "김철수",
  "email": "kim@example.com"
}
자주 쓰는 잘못된 응답
201Created

201 Created로 응답 시

실무 포인트

GET으로 기존 리소스를 조회하면 200 OK. 새 리소스 생성이 아니므로 201이 아닙니다.

3. 3xx 리다이렉션 — PRG 패턴까지

꼬리질문: "302와 307의 차이점은 무엇인가요?"

리다이렉션 코드는 단순히 "다른 URL로 이동"이 아닙니다. 영구(301·308) vs 일시(302·307), 메서드 변경 허용(301·302) vs 메서드 유지(307·308)라는 두 축으로 구분됩니다. 실무에서 302를 무심코 사용하면 POST 요청이 GET으로 바뀌어 데이터가 누락되는 버그가 생길 수 있습니다.

매트릭스 셀을 클릭하면 각 코드의 사용 예시를 볼 수 있습니다. "시뮬레이션" 버튼으로 PRG 패턴의 흐름을 확인해 보세요.

메서드 변경 가능
메서드 유지
영구
임시
303
See Other— PRG 패턴 전용

POST 처리 후 반드시 GET으로 다른 URI를 조회하도록 안내합니다. 중복 제출 방지(PRG 패턴)에 사용됩니다.

PRG 패턴 (Post/Redirect/Get)

새로고침 시 POST 중복 제출을 방지하는 패턴

POST /orders→303 See Other→GET /orders/123→200 OK

4. 4xx 클라이언트 오류 — 401 vs 403 완전 정복

꼬리질문: "401과 403의 차이를 인증/인가 관점에서 설명해주세요."

4xx 코드 중 가장 많이 혼동하는 것이 401과 403입니다. 401 Unauthorized는 이름이 misleading한데, 실제로는 "인증(Authentication)되지 않음"을 의미합니다. 403 Forbidden은 "인가(Authorization) 실패"입니다. 이 둘을 혼동하면 클라이언트가 로그인 화면으로 이동해야 할 때 권한 오류 메시지를 보여주는 UX 버그가 생깁니다.

좌측에서 코드를 선택하면 상세 정보와 혼동 주의 패널이 표시됩니다.

4xx 코드 목록

401Unauthorized

인증(Authentication) 없음

발생 상황

비로그인 상태, 만료된 액세스 토큰, 잘못된 API 키

클라이언트 대응

로그인 화면으로 이동 또는 토큰 갱신

혼동 주의

401

인증(Authentication) 없음

누구인지 모름 → 로그인 필요

403

인가(Authorization) 없음

누군지는 알지만 권한 없음 → 접근 거부

403과 혼동 주의 — 401은 인증 자체가 없는 상태

5. 5xx 서버 오류 — 502 vs 504 구분

꼬리질문: "502와 504의 차이를 실제 인프라 관점에서 설명해주세요."

5xx 코드는 서버 인프라 구조를 이해해야 구분할 수 있습니다. 500은 애플리케이션 서버(WAS) 내부 오류, 502는 게이트웨이가 WAS로부터 잘못된 응답을 받은 것, 504는 게이트웨이가 WAS로부터 응답을 못 받은 것(타임아웃)입니다.

상단 탭을 클릭하면 해당 에러가 발생하는 인프라 구간이 표시됩니다.

💻
클라이언트
HTTP
🔀Nginx
Reverse Proxy
✗
☕Spring Boot
WAS
JDBC
🗄️
Database
502Bad Gateway재시도 가능

Nginx가 WAS로부터 잘못된 응답을 받거나 연결 자체가 거부됨

주요 원인

WAS 프로세스 다운, 포트 불일치, 비정상 응답 형식

502 vs 504 핵심 차이

502

WAS가 잘못된 응답 또는 연결 거부

504

WAS가 응답 없음 (타임아웃)

자주 발생하는 문제

실무와 면접에서 자주 혼동하는 포인트를 정리했습니다.

면접 체크리스트

이 항목들을 자신 있게 설명할 수 있다면 HTTP 상태 코드 질문은 준비 완료입니다.

  • - 1xx: 처리 중 — 101 Switching Protocols로 WebSocket 연결 수립
  • - 2xx: 성공 — 생성은 201+Location, body 없으면 204, 나머지는 200
  • - 3xx: 리다이렉션 — 영구/임시 × 메서드 유지/변경으로 4가지 구분. PRG 패턴은 303
  • - 4xx: 클라이언트 오류 — 401(인증없음), 403(인가없음), 404(없음), 409(충돌), 422(의미오류), 429(Rate Limit)
  • - 5xx: 서버 오류 — 500(WAS 오류), 502(잘못된 응답), 503(불가), 504(타임아웃)
  • - 안티패턴: 200 OK에 에러 담기 금지 — 모니터링·게이트웨이가 오류를 감지하지 못함

퀴즈로 확인하기

배운 개념을 실제 시나리오에 적용해 보세요.

Quiz 1

사용자 생성 API의 응답 코드

@PostMapping("/api/users")
public ResponseEntity<?> createUser(@RequestBody UserRequest req) {
    User user = userService.save(req);
    return ???; // 어떤 응답을 반환해야 할까?
}
Quiz 2

인증이 필요한 API에 비로그인 접근

비로그인 사용자가 GET /api/orders/me (내 주문 목록)를 호출했습니다.
서버는 어떤 상태 코드를 반환해야 할까요?
Quiz 3

POST 요청 후 302 리다이렉션

Client → POST /login (username, password)
Server → 302 Found (Location: /dashboard)
Client → ??? /dashboard

대부분의 브라우저는 마지막 줄에 어떤 HTTP 메서드를 사용할까요?
Quiz 4

Nginx 게이트웨이 에러 분석

Nginx 뒤에 Spring Boot 서버가 있습니다.
사용자들이 갑자기 502 에러를 받고 있습니다.

어떤 상황이 발생했을 가능성이 가장 높을까요?
Quiz 5

이미 가입된 이메일 처리

POST /api/users
{ "email": "test@example.com", "name": "김철수" }

응답: 이미 해당 이메일로 가입된 계정이 존재합니다.

이 상황에서 가장 적합한 HTTP 상태 코드는?

추가 학습 자료를 공유합니다.

의견을 들려주세요

서비스 개선에 큰 도움이 됩니다. 익명으로 자유롭게 남겨주세요.

0 / 1000