안동민 개발노트

본문 시작

상태 코드와 헤더

HTTP 상태 코드 범주와 주요 요청·응답 헤더를 해석하고 REST API의 성공·오류 응답을 일관되게 설계합니다.

HTTP 응답을 받았을 때 가장 먼저 확인하는 것이 상태 코드(Status Code)입니다.

200이면 성공, 404이면 없음, 500이면 서버 오류.

하지만 이 세 개만 아는 것과 전체 체계를 이해하는 것에는 큰 차이가 있습니다.


상태 코드 체계

HTTP 상태 코드는 세 자리 숫자로, 첫 자리가 응답의 범주를 나타냅니다.

  • 1xx 정보 응답 — 처리 중의 임시 응답입니다.
  • 2xx 성공 — 요청을 수신하고 이해하여 수락했습니다. 202는 최종 처리 완료와 구분합니다.
  • 3xx 추가 동작 — 리다이렉션이나 조건부 요청의 캐시 재사용 등 코드별 처리가 필요합니다.
  • 4xx 클라이언트 오류 — 요청·인증·권한·대상 리소스 등의 문제를 나타냅니다.
  • 5xx 서버 오류 — 서버가 요청을 처리하지 못한 경우입니다.

클라이언트는 모든 상태 코드를 세부적으로 알지 못하더라도 첫 자리의 범주는 이해해야 합니다.

예를 들어 처음 보는 499라면 구체적 의미는 몰라도 4xx 클라이언트 오류 계열로 다뤄야 합니다.

상태 코드는 확장 가능하며, 공식 등록값은 IANA HTTP Status Code Registry에서 관리됩니다. 499는 표준 등록 코드로 소개한 것이 아니라 모르는 코드의 범주를 읽는 예입니다.


주요 상태 코드 상세

실무에서 자주 만나는 상태 코드를 하나씩 살펴보겠습니다.

코드이름·의미·쓰임
200이름: OK; 의미: 성공; 사용 사례: GET/PUT/PATCH 성공 응답
201이름: Created; 의미: 리소스 생성; 사용 사례: POST 성공, Location 헤더 포함
204이름: No Content; 의미: 성공, 본문 없음; 사용 사례: DELETE 성공, 반환 데이터 없을 때
301이름: Moved Permanently; 의미: 영구 이동; 사용 사례: URL이 영구적으로 바뀜, 캐시와 검색엔진 신호에 영향
302이름: Found; 의미: 임시 이동; 사용 사례: 오래된 관례상 POST가 GET으로 바뀔 수 있음
304이름: Not Modified; 의미: 변경 없음; 사용 사례: 캐시 유효, 본문 생략
400이름: Bad Request; 의미: 잘못된 요청; 사용 사례: 파라미터 누락, 형식 오류
401이름: Unauthorized; 의미: 인증 필요; 사용 사례: 유효한 인증 정보 없음, WWW-Authenticate 필요
403이름: Forbidden; 의미: 요청 처리 거부; 사용 사례: 서버가 요청을 이해했지만 허용하지 않음
404이름: Not Found; 의미: 리소스 없음; 사용 사례: 잘못된 URL, 삭제된 리소스
405이름: Method Not Allowed; 의미: 메서드 불가; 사용 사례: GET만 허용인데 POST 요청
409이름: Conflict; 의미: 충돌; 사용 사례: 이미 존재하는 리소스 생성 시도
429이름: Too Many Requests; 의미: 요청 과다; 사용 사례: Rate Limiting 초과
500이름: Internal Server Error; 의미: 서버 오류; 사용 사례: 코드 버그, 예외 미처리
502이름: Bad Gateway; 의미: 게이트웨이 오류; 사용 사례: 업스트림에서 유효하지 않은 응답을 받음
503이름: Service Unavailable; 의미: 서비스 불가; 사용 사례: 과부하, 유지보수
504이름: Gateway Timeout; 의미: 게이트웨이 타임아웃; 사용 사례: 업스트림 응답 지연

리디렉션은 특히 주의해야 합니다.

301과 302는 역사적 호환성 때문에 클라이언트가 POST를 GET으로 바꾸는 경우가 있고, 메서드를 보존해야 한다면 307 Temporary Redirect 또는 308 Permanent Redirect가 더 명확합니다.

429 Too Many Requests나 503 Service Unavailable에는 상황에 따라 Retry-After 헤더를 함께 보낼 수 있습니다.


REST API 상태 코드 설계 패턴

  • 생성 완료는 201로 표현하며 새 리소스 URI를 Location으로 알릴 수 있습니다.
  • 처리를 접수했지만 끝나지 않았다면 202와 상태 확인 방법을 제공합니다.
  • 처리에 성공했고 응답 본문이 없다면 204를 사용합니다.
  • 현재 상태 충돌은 409, 요청 전제 조건 실패는 412처럼 API 계약에 맞춰 구분합니다.

REST API에서 상태 코드는 “서버 내부 구현 결과”가 아니라 클라이언트가 다음 행동을 판단할 수 있게 해주는 계약입니다.


주요 요청/응답 헤더

HTTP 헤더는 요청과 응답에 대한 메타데이터를 전달합니다.

  • Content-Type — 방향: 양방향; 용도: MIME 타입 지정; 주의사항: 본문 형식을 명시; 누락이 항상 파싱 실패라는 뜻은 아님

  • Authorization — 방향: 요청; 용도: 인증 토큰; 주의사항: Bearer, Basic 등 스킴 구분

  • Host — 방향: 요청; 용도: 대상 서버; 주의사항: HTTP/1.1 필수, 가상호스트 구분

  • Cache-Control — 방향: 양방향; 용도: 캐시 정책; 주의사항: no-cache ≠ 캐시 금지

  • Set-Cookie — 방향: 응답; 용도: 쿠키 설정; 주의사항: HTTPS 서비스는 Secure, 민감 쿠키는 HttpOnly 권장

  • User-Agent — 방향: 요청; 용도: 클라이언트 정보; 주의사항: 위조 가능하므로 보안 판단 근거로 부적합

Content-Type은 본문이 어떤 표현 형식인지 알려주고, Accept는 클라이언트가 선호하는 응답 형식을 알려줍니다.

Cache-Control: no-cache는 “저장 금지”가 아니라 재사용 전에 재검증하라는 의미이고, 저장 자체를 막고 싶다면 no-store를 사용합니다.

http_headers.py
from http.client import HTTPSConnection
import json

def inspect_headers(host, path="/"):
    """HTTP 응답 헤더 분석"""
    conn = HTTPSConnection(host)
    conn.request("GET", path, headers={
        "Accept": "text/html",
        "Accept-Encoding": "gzip, deflate",
        "Accept-Language": "ko-KR,ko;q=0.9",
    })

    response = conn.getresponse()

    print(f"=== {host}{path} ===")
    print(f"Status: {response.status} {response.reason}")
    print("\nResponse Headers:")

    security_headers = [
        "strict-transport-security",
        "content-security-policy",
        "x-frame-options",
        "x-content-type-options",
    ]

    for name, value in response.getheaders():
        marker = " [보안]" if name.lower() in security_headers else ""
        print(f"  {name}: {value[:80]}{marker}")

    response.read()
    conn.close()

# inspect_headers("www.google.com")
# inspect_headers("github.com")

면접 포인트

질문핵심 답변
401과 403의 차이?401은 유효한 인증 정보 필요, 403은 요청 처리 거부(인증 성공을 뜻하지 않음)
302와 307의 차이?302는 관례상 메서드가 바뀔 수 있고, 307은 메서드 보존
Content-Type 역할?본문 MIME 타입을 알려 올바른 해석을 돕는 헤더
502와 504 차이?502는 업스트림 비정상 응답, 504는 업스트림 응답 지연

다음 절에서는 HTTP의 상태 관리 메커니즘인 쿠키와 세션을 살펴보겠습니다.