400 Bad Request

400 Bad Request는 요청에 문제가 있다고 판단한 서버가 처리를 거부할 때 보내는 HTTP 상태 코드입니다. 잘못된 문법이나 메시지 형식 등이 원인이며, 정확한 이유는 응답 본문과 서버의 규칙을 함께 읽어 판단합니다. 같은 요청을 그대로 반복하기보다 URL, 헤더, 본문의 형식과 값을 확인하는 데 쓰이는 오류 신호입니다.

요청을 처리하지 않는 이유

HTTP 의미를 정의한 RFC 9110은 400을 서버가 클라이언트 오류로 인식한 문제 때문에 요청을 처리할 수 없거나 처리하지 않는 경우로 설명합니다. 예시에는 잘못된 요청 문법, 유효하지 않은 메시지 구분, 속임수로 판단한 요청 라우팅이 포함됩니다. 여기서 클라이언트 오류라는 분류는 문제를 발견한 위치의 표현입니다. 실제 결함이 사용자 입력, 호출 코드, 중간 프록시 중 어디에서 생겼는지는 상태 코드 하나로 확정되지 않습니다.

MDN의 400 설명은 형식이 잘못된 JSON 본문을 보내는 예를 듭니다. 서버가 본문을 읽지 못하면 정상적인 데이터 저장 단계까지 진행하지 못합니다. 문자열 따옴표나 줄바꿈 처리에 문제가 있는지, 전송한 내용과 Content-Type이 맞는지처럼 요청을 구성하는 부분부터 좁혀 볼 수 있습니다. 이 예는 400의 한 원인이며, 모든 400 응답이 JSON 문법 오류를 뜻하지는 않습니다.

요청 본문이 문법상 유효해도 서비스가 요구하는 입력 규칙을 어기면 API 구현에 따라 400을 받을 수 있습니다. 필수 값이 빠졌는지, 허용된 값인지, 사용한 API 버전에서 그 필드를 받는지는 서비스 문서가 정합니다. HTTP 공통 규격과 개별 API의 오류 체계를 나눠 읽으면 상태 코드의 넓은 분류와 응답 본문에 적힌 구체적인 원인을 함께 해석할 수 있습니다.

다른 오류 코드와의 경계

RFC 9110은 인증 정보가 필요한 경우의 401, 요청을 이해했으나 수행을 거부하는 403, 대상 자원을 찾지 못한 경우의 404도 구분합니다. 본문 형식이 맞지 않는 요청과 접근 권한이 부족한 요청은 고칠 대상이 다릅니다. API가 응답에 자체 오류 코드를 덧붙인다면 HTTP 상태와 그 코드를 함께 확인합니다. 모든 실패를 400으로 뭉뚱그리는 클라이언트 화면에서는 이 차이가 사용자에게 보이지 않을 수 있습니다.

서버가 예상하지 못한 상태에 부딪혔다는 500과도 구분합니다. 서버가 400을 반환했다는 사실만으로 서버 프로그램 전체가 정상이라고 인증할 수는 없지만, 오류를 추적할 출발점은 받은 요청의 조건입니다. 입력을 바꾸어 성공한 경우에도 어떤 값이나 형식이 달라졌는지 기록해야 재현할 수 있습니다. 단지 재시도 횟수가 늘어난 뒤 성공했다면 그 사이의 요청과 서버 상태 변화를 따로 확인할 필요가 있습니다.

요청을 수정하고 결과를 확인하는 과정

MDN은 수정 없이 같은 요청을 반복하면 같은 오류가 날 것으로 예상하라고 설명합니다. 재시도 프로그램이 오류를 일시적인 네트워크 장애로만 처리하면 잘못된 요청을 계속 보낼 수 있습니다. 대기 시간을 늘리는 방식은 입력 문법을 고치지 않습니다. 실제로 보낸 URL과 메서드, 관련 헤더, 본문의 구조를 응답의 오류 설명과 대조한 뒤 해당 부분을 수정하면 원인과 조치가 연결됩니다.

오류를 조사할 때는 API 키나 토큰을 기록에서 지우고도 요청 구조를 확인할 수 있게 남깁니다. 같은 이름의 필드라도 문자열과 숫자는 서로 다른 값으로 해석될 수 있고, 필드가 없는 경우와 null을 보낸 경우도 서비스에 따라 다릅니다. 클라이언트에서 만들었다고 생각한 객체와 네트워크로 실제 전송된 내용을 나눠 확인하면 직렬화 과정에서 바뀐 부분을 찾는 데 도움이 됩니다.

수정 후에는 상태 코드가 바뀌었는지와 요청한 작업이 실제로 이루어졌는지를 함께 봅니다. 오류 화면이 사라진 것과 데이터가 원하는 값으로 저장된 것은 서로 다른 확인입니다. 응답 식별자와 수정한 입력 조건을 연결하면 서버 로그에서 같은 요청을 찾기 쉽습니다. 실패한 요청의 원인, 적용한 수정, 이후 응답을 한 기록으로 남겨야 다른 호출 경로에서 같은 문제가 생겼을 때 비교할 수 있습니다.