[데브코스] Spring Boot REST API 실습 (26강) - HTTP 상태 코드는 얼마나 정확해야 할까? (200 vs 201)

이번 강의에서는 REST API 응답 코드(HTTP Status Code) 에 대해 다룬다.
특히 “게시물 작성 성공 시 200으로 응답해도 되는가?” 라는 현실적인 질문을 중심으로,
실무에서의 기준과 타협점을 정리했다.

---

📌 강의 배경

게시글 작성 API를 구현하고 Postman으로 테스트했을 때,
응답은 아래와 같이 내려오고 있었다.

{
  "resultCode": "200-1",
  "msg": "9번 글이 생성되었습니다.",
  "data": {
    "totalCount": 9,
    "post": {
      "id": 9,
      "createDate": "2025-06-26T12:18:23.5386661",
      "modifyDate": "2025-06-26T12:18:23.5386661",
      "title": "제목",
      "content": "내용"
    }
  }
}

Postman 상단에는 HTTP 200 OK 가 찍혀 있다.

---

❓ 질문: 이거 200 말고 201 써야 하는 거 아님?

AI에게 물어보면 거의 항상 이런 답이 나온다.

“리소스 생성에 성공했다면 HTTP 201 Created가 더 적절합니다.”

그럼 자연스럽게 이런 의문이 생긴다.

• 201이 맞다면
• 200으로 응답하면 잘못된 건가?
• 프론트엔드 개발자가

  “왜 201 안 쓰셨어요?”
  라고 따질까?

---

✅ 결론부터 말하면

201이 더 적절하긴 하지만, 200으로 응답해도 전혀 문제 없다.

이게 이번 강의의 핵심 결론이다.

---

🔍 HTTP 상태 코드의 본질

HTTP 상태 코드는 “요청 결과를 대략적인 범주로 전달하는 신호”다.

• 성공인가?
• 실패인가?
• 클라이언트 문제인가?
• 서버 문제인가?

이 정도를 빠르게 판단하기 위한 용도이지,
비즈니스 로직의 모든 맥락을 담기 위한 수단은 아니다.

---

🟢 성공 계열 (2xx)의 의미

상태코드	의미	설명
200	OK	요청이 정상적으로 처리됨
201	Created	리소스 생성에 성공함 (POST 후 주로 사용)
204	No Content	성공했지만 응답 본문이 없음

게시글 작성의 경우

• 201 Created
  → 의미적으로 가장 정확함
• 200 OK
  → 성공을 표현하는 데는 충분함

👉 즉, 정답은 201이지만 오답은 아니다 = 200도 허용

---

🔴 실패 계열 (4xx / 5xx)

실패 쪽은 오히려 조금 더 신경 쓰는 게 좋다.

상태코드	의미	설명
400	Bad Request	잘못된 요청
401	Unauthorized	인증 필요
403	Forbidden	권한 없음
404	Not Found	리소스 없음
409	Conflict	중복 등 충돌
422	Unprocessable Entity	유효성 검사 실패
500	Internal Server Error	서버 오류

실패의 경우에는
프론트엔드에서 분기 처리를 해야 하는 경우가 많기 때문에
상태 코드가 조금 더 중요해진다.

---

🤝 실무 관점에서의 타협점

강사님의 메시지는 명확했다.

“상황에 맞게 정밀하게 하면 좋지만,
반드시 그렇게 해야 하는 건 아니다.”

정리하면

• 성공
  • 200으로 통일해도 문제 없음
  • 201을 쓰면 더 REST스럽긴 함
• 실패
  • 4xx / 5xx는 의미 있게 구분하는 게 좋음
• 진짜 중요한 정보
  • HTTP 코드보다도
    resultCode, msg, data 같은 응답 본문

---

📦 그래서 우리는 이렇게 한다

{
  "resultCode": "200-1",
  "msg": "글이 생성되었습니다.",
  "data": {
    ...
  }
}

• HTTP 상태 코드: 성공이면 200
• 비즈니스 성공/실패: resultCode
• 사용자 메시지: msg
• 실제 데이터: data

👉 프론트엔드는 이 구조만 보고도 충분히 판단 가능하다.

---

🧠 한 줄 요약

HTTP 201이 더 정확하긴 하지만,
200으로 응답해도 전혀 문제 되지 않는다.
중요한 건 “의미 있는 응답 구조”다.

---

✍️ 느낀 점

처음에는
“REST면 무조건 정석대로 해야 하는 거 아님?”
이라는 생각이 강했는데,

이번 강의를 통해
REST는 규칙이 아니라 ‘권장사항’에 가깝다는 걸 느꼈다.

정답을 맞히는 것보다,
팀과 클라이언트가 이해하기 쉬운 구조를 만드는 것이 더 중요하다.