400 오류와 422 오류 차이 — 요청 형식과 내용 구분

사용자 화면에서는 어떻게 보나요?

폼 입력값과 필수 항목을 확인하고 오류 문장을 그대로 읽습니다. 같은 제출을 여러 번 누르지 않습니다. 첨부 파일 형식과 크기는 서비스가 표시한 제한을 따릅니다.

API의 400은 무엇을 보나요?

JSON 문법, Content-Type, 필수 헤더, URL 인코딩을 확인합니다. 프록시가 요청을 잘랐는지도 봅니다. 서버 로그의 요청 ID와 클라이언트 시각을 맞춥니다.

422는 어디가 다른가요?

서버가 콘텐츠 형식과 문법을 이해했지만 포함된 지시를 처리하지 못한 상태입니다. 필드 유효성, 서로 충돌하는 값, 현재 자원 상태를 확인합니다. 같은 본문을 재전송해도 결과가 달라지지 않을 수 있습니다.

재시도 정책을 나눕니다

네트워크 오류처럼 자동 재시도하지 않습니다. 요청 값을 고치거나 서버 상태가 바뀐 뒤 다시 보냅니다. 결제와 생성 API는 중복 실행을 막는 키가 있는지 확인합니다.

오류 본문을 어떻게 설계하나요?

운영자는 사람이 읽을 메시지와 안정적인 오류 식별자, 잘못된 필드 위치를 제공합니다. 내부 스택과 비밀 값을 노출하지 않습니다. 문서에는 허용 형식과 예시를 함께 둡니다.

브라우저에서는 개발자 도구의 요청 본문에 개인정보가 있을 수 있습니다. 공개 캡처 전에 토큰, 쿠키, 이메일을 가립니다. 지원팀에는 재현 가능한 최소 입력만 전달합니다.

오류를 재현할 때 무엇을 남기나요?

요청 시각은 시간대와 함께 기록하고 전체 URL에서는 토큰과 개인정보를 제거합니다. 응답 상태, Retry-After, 요청 ID처럼 서버가 제공한 식별자를 남깁니다. 브라우저 화면과 API 클라이언트 결과가 다르면 요청 방식과 헤더 차이를 확인합니다.

GET 조회와 결제·생성 POST는 재시도 위험이 다릅니다. 상태를 확인하지 않고 POST를 반복하면 중복 처리가 생길 수 있습니다. 서비스가 멱등 키를 제공하면 공식 문서의 범위에서 사용하고, 처리 내역을 먼저 조회합니다.

운영자는 프록시, 응용 프로그램, 데이터베이스 로그의 시계를 맞춥니다. 한 상태 코드만 보고 원인을 확정하지 않고 실패 경로와 정상 경로를 비교합니다. 오류 페이지에는 내부 스택이나 비밀 값을 노출하지 않습니다.

판단 기준: 한 사용자만 실패하면 계정·클라이언트 조건을 보고, 여러 지역에서 같은 시각에 실패하면 서비스 계층을 봅니다. 상태가 회복된 뒤에는 같은 요청의 응답 코드와 처리 결과를 확인합니다. 오류 횟수만으로 원인을 확정하지 않습니다.

자주 묻는 질문

400과 422는 모두 입력 오류인가요?

둘 다 요청 문제일 수 있지만 422는 서버가 형식을 이해한 뒤 내용 처리를 거부한 점을 더 구체적으로 나타냅니다.

422를 자동 재시도하면 되나요?

값이나 자원 상태가 바뀌지 않으면 같은 실패가 반복될 수 있습니다.

오류 본문을 공개해도 되나요?

토큰, 쿠키, 개인정보를 가린 뒤 필요한 부분만 공유합니다.

관련 가이드: HTTP 상태 코드 · 400 코드 · 422 코드

근거: MDN 422 Unprocessable Content. 2026-09-14 확인. 공식 원문