1. 라이브러리
  2. HTTP와 웹
  3. HTTP 상태 코드

200 OK

업데이트됨 1개월 전

링크를 클릭했을 때 페이지가 나타나고, 양식을 제출했을 때 확인 메시지가 뜨고, API가 요청한 데이터를 돌려줄 때—거의 모든 성공적인 상호작용 뒤에는 200 OK 응답이 있습니다. 가장 흔한 HTTP 상태 코드이자, 인터넷이 "네, 여기 있습니다"라고 말하는 방식입니다.

200 OK가 실제로 의미하는 것

200 OK는 네 가지를 알려줍니다:

  1. 요청을 받아 이해했습니다
  2. 요청이 유효합니다
  3. 서버가 성공적으로 처리했습니다
  4. 응답에 요청한 내용이 담겨 있습니다
HTTP/1.1 200 OK
Content-Type: application/json

{"id": 123, "name": "Alice", "email": "alice@example.com"}

그게 전부입니다. 요청을 이해하고 처리했으며, 데이터를 보냅니다.

200이 올바른 선택인 경우

데이터를 반환하는 GET 요청:

GET /api/users/123

HTTP/1.1 200 OK
{"id": 123, "name": "Alice"}

리소스를 업데이트하는 PUT/PATCH 요청:

PUT /api/users/123
{"name": "Alice Smith"}

HTTP/1.1 200 OK
{"id": 123, "name": "Alice Smith"}

삭제된 내용을 확인하고 싶을 때의 DELETE 요청:

DELETE /api/users/123

HTTP/1.1 200 OK
{"message": "User deleted", "id": 123}

새로운 리소스를 생성하지 않고 데이터를 처리하는 POST 요청:

POST /api/calculate
{"expression": "2 + 2"}

HTTP/1.1 200 OK
{"result": 4}

200이 잘못된 선택인 경우

2xx 계열에는 더 구체적인 코드들이 있습니다. 더 적합한 코드가 있는데 200을 쓰는 것은 모든 질문에 "괜찮아"로만 답하는 것과 같습니다—기술적으로 틀린 건 아니지만, 의사소통의 기회를 놓치는 겁니다.

새로운 것을 만들었나요? 201을 쓰세요

POST /api/users
{"name": "Bob"}

HTTP/1.1 201 Created
Location: /api/users/124

{"id": 124, "name": "Bob"}

201은 "성공했을 뿐만 아니라, 새로운 리소스가 생겼습니다"라고 말합니다. Location 헤더는 그 리소스를 어디서 찾을 수 있는지 알려줍니다.

반환할 것이 없나요? 204를 쓰세요

DELETE /api/users/123

HTTP/1.1 204 No Content

본문도 없고, Content-Length도 없습니다. 성공을 뜻하는 침묵입니다. {"success": true}를 200으로 반환하는 것보다 훨씬 깔끔합니다.

나중에 처리하나요? 202를 쓰세요

POST /api/video/render
{"source": "video.raw"}

HTTP/1.1 202 Accepted

{"jobId": "abc123", "status": "queued"}

202는 "받았습니다, 처리 중입니다, 아직 완료되지 않았습니다"라고 말합니다. 클라이언트는 나중에 다시 확인해야 한다는 것을 알게 됩니다.

함정: HTTP 성공 vs. 비즈니스 성공

200 OK는 HTTP 메커니즘이 작동했다는 의미입니다. 비즈니스 로직이 성공했다는 보장은 아닙니다—이 차이가 개발자들을 혼란에 빠뜨리고 프로덕션 시스템을 망가뜨려 왔습니다.

일부 API는 이렇게 합니다:

POST /api/transfer
{"amount": 1000, "to": "account-456"}

HTTP/1.1 200 OK

{"success": false, "error": "Insufficient funds"}

HTTP 요청은 성공했습니다. 이체는 실패했습니다. 상태 코드는 한 가지를 말하고, 본문은 다른 것을 말합니다.

이것은 폭탄에 리본을 다는 것과 같습니다—포장이 내용물에 대해 거짓말을 하는 셈입니다. 모니터링 도구는 상태 코드를 신뢰합니다. 오류 추적 시스템도 상태 코드를 신뢰합니다. 모든 응답이 200을 반환하면, 실패가 눈에 보이지 않게 됩니다.

더 나은 방법:

HTTP/1.1 400 Bad Request

{"error": "Insufficient funds", "code": "INSUFFICIENT_FUNDS"}

이제 상태 코드와 본문이 일치합니다. 로그에 실패가 기록됩니다. 알림이 발생합니다. 시스템이 실제로 일어난 일에 대해 정직해집니다.

본문에 담을 내용

200 응답에는 유용한 내용이 있어야 합니다. {"success": true}만으로는 부족합니다—기회를 낭비하는 것입니다.

GET의 경우 리소스를 반환하세요:

{
    "id": 123,
    "name": "Alice",
    "email": "alice@example.com",
    "createdAt": "2024-01-15T10:30:00Z"
}

수정·변경 요청의 경우 결과를 반환하세요:

{
    "id": 124,
    "name": "Bob",
    "createdAt": "2024-10-21T14:22:00Z"
}

클라이언트는 무언가가 일어나기를 요청했습니다. 무슨 일이 일어났는지 보여주세요.

Content-Type이 내용을 알려줍니다

200 OK는 무엇이든 담을 수 있습니다:

Content-Type: application/json    → API 응답
Content-Type: text/html           → 웹페이지
Content-Type: image/png           → 이미지
Content-Type: application/pdf     → 문서

Content-Type 헤더는 클라이언트가 받은 내용이 무엇인지 알 수 있는 수단입니다. 이것이 없으면 클라이언트는 추측에 의존해야 하고—추측은 버그로 이어집니다.

캐싱 동작

200 응답은 기본적으로 캐시할 수 있습니다. 브라우저, CDN, 프록시가 저장할 수 있습니다:

HTTP/1.1 200 OK
Cache-Control: public, max-age=3600

{"data": "cacheable for one hour"}

민감한 데이터라면 캐싱을 막아야 합니다:

HTTP/1.1 200 OK
Cache-Control: no-store

{"data": "never cache this"}

흔한 실수들

실패에 200을 반환하기. 문제가 생겼다면 4xx 또는 5xx로 명확히 알리세요.

204가 맞을 때 200 쓰기. 200으로 빈 본문을 반환하면 혼란을 줍니다. 204를 쓰세요.

201이 맞을 때 200 쓰기. 리소스를 생성했나요? 201과 Location 헤더로 클라이언트에게 알리세요.

Content-Type 누락. 클라이언트는 받은 내용이 무엇인지 알아야 합니다.

의미 없는 본문. {"success": true}는 클라이언트에게 아무런 유용한 정보를 주지 않습니다. 실제 데이터를 반환하세요.

간단한 판단 기준

200과 다른 2xx 코드 사이에서 고민할 때 이렇게 물어보세요:

  • 새로운 것을 만들었나요? → 201
  • 반환할 것이 없나요? → 204
  • 아직 처리 중인가요? → 202
  • 반환할 내용이 있나요? → 200
  • 무언가 실패했나요? → 4xx 또는 5xx

200 OK는 기본 성공 응답입니다. 어디서나 작동합니다. 하지만 어떤 기본값이든 그렇듯, 신중하게 사용하고 언제 다른 코드가 더 적합한지 아는 것—그것이 그저 그런 API와 탁월한 API의 차이를 만듭니다.

200 OK에 대해 자주 묻는 질문

200 응답에 빈 본문이 있을 수 있나요?

기술적으로는 가능하지만 오해를 불러일으킵니다. 200은 "요청한 내용이 여기 있습니다"를 의미합니다. 빈 본문은 그 약속에 어긋납니다. 대신 204 No Content를 쓰세요—아무것도 반환하지 않는 성공적인 작업을 위해 설계된 코드입니다.

리소스를 생성할 때 200과 201 중 무엇을 반환해야 하나요?

201 Created가 더 정확하고 의도를 더 잘 전달합니다. 또한 관례적으로 새 리소스를 가리키는 Location 헤더를 포함합니다. 생성에는 201을, 내용을 반환하는 그 외의 모든 경우에는 200을 사용하세요.

왜 일부 API는 오류에도 200을 반환하나요?

대개 역사적인 이유 때문입니다. 일부 프레임워크에서는 항상 200을 반환하고 성공/실패 여부를 본문에 담는 방식이 더 편했습니다. 작동하기는 하지만 HTTP 의미 체계를 깨뜨리고, 모니터링 도구를 혼란스럽게 하고, 디버깅을 어렵게 만듭니다. 새로운 API는 올바른 상태 코드를 사용해야 합니다.

200과 202의 차이점은 무엇인가요?

200은 "완료되었습니다"를 의미합니다. 202는 "받았으며 나중에 처리하겠습니다"를 의미합니다. API가 백그라운드 작업을 시작하거나, 작업을 대기열에 넣거나, 비동기 작업을 시작하는 경우라면 202로 클라이언트에게 즉각적인 결과를 기대하지 말라고 알릴 수 있습니다.

이전

503 Service Unavailable

다음

1xx 정보 상태 코드

이 페이지가 도움이 되었나요?

😔
🤨
😃