200 OK

200 OK 는 서버가 요청을 받아 끝까지 처리했다고 알립니다. 서버가 돌려주는 응답의 첫 줄에 이 값이 실립니다. 클라이언트(요청을 보내고 응답을 받는 쪽)는 이 값을 보고 함께 온 본문을 결과로 받아 씁니다.

상세

200 OK 는 HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 프로토콜)의 상태 코드 가운데 하나입니다. HTTP 는 브라우저나 프로그램이 서버에 요청을 보내고 응답을 받는 규약입니다. 상태 코드는 그 응답이 어떻게 끝났는지를 세 자릿수로 알리는 값입니다.

200 은 요청이 성공했다는 뜻입니다. 서버가 요청을 알아듣고 처리까지 마쳤다는 말입니다. 처리 결과는 응답 본문에 담겨 옵니다.

응답 첫 줄의 세 자릿수

이 소절은 200 이 응답의 어디에 적히는지를 응답 한 벌로 봅니다. 아래는 서버가 짧은 글 한 줄을 돌려준 응답입니다.

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 5

hello

첫 줄을 상태 줄이라고 부릅니다. 규약의 판 이름, 상태 코드, 짧은 설명 문구가 차례로 놓입니다. 그 아래 두 줄은 헤더입니다. 본문의 형식과 길이를 알립니다. 빈 줄 다음이 본문입니다.

숫자 뒤에 붙은 OK 는 사유 구절입니다. 사람이 읽으라고 붙인 문구입니다. 프로그램은 이 글자를 안 보고 숫자만 봅니다. 그래서 「200」과 「200 OK」는 같은 값을 가리킵니다. HTTP 의 뒤 판인 HTTP/2 부터는 사유 구절을 아예 싣지 않고 숫자만 보냅니다.

맨 앞 숫자 2 가 가르는 갈래

상태 코드의 맨 앞 숫자는 결과가 어느 갈래에 드는지를 정합니다. 200 이 무엇과 이웃하는지 보려면 이 갈래부터 알아야 합니다.

2 로 시작하는 코드는 전부 성공을 뜻합니다. 200 은 그 가운데 가장 기본이 되는 값입니다. 클라이언트는 처음 보는 코드를 받아도 맨 앞 숫자만 보고 갈래는 압니다.

약속된 숫자로 성공을 알리는 까닭

응답을 읽는 쪽은 요청을 보낸 클라이언트만이 아닙니다. 받은 응답을 저장해 두었다가 다음 요청에 다시 내주는 캐시도 같은 응답을 봅니다. 캐시가 있으면 같은 내용을 가지러 서버까지 다시 가지 않아도 됩니다.

서버가 실패를 몇 번 냈는지 세는 모니터링 도구도 응답을 봅니다. 이 도구가 있어야 장애를 일찍 알아챕니다.

이들은 본문을 열어 보지 않습니다. 본문의 형식은 웹 페이지, 이미지, 데이터 한 덩이처럼 제각각입니다. 성공인지를 본문으로 알려야 한다면 형식마다 읽는 법을 다 알아야 합니다.

200 은 이 수고를 숫자 하나로 덜어 줍니다. 캐시는 200 을 보고 저장할지 따집니다. 모니터링은 4 나 5 로 시작하는 응답을 실패로 셉니다.

메서드마다 달라지는 본문

요청에는 무엇을 해 달라는지 알리는 메서드가 붙습니다. 메서드는 GET 이나 POST 처럼 요청 첫 줄 맨 앞에 적는 낱말입니다. 200 이라는 값은 같아도 본문에 무엇이 담기는지는 이 메서드가 정합니다.

메서드가 다루는 대상을 리소스라고 부릅니다. 리소스는 게시글 한 편이나 사용자 한 명처럼 서버가 주소를 붙여 가리키는 대상입니다.

표에서 눈여겨볼 줄은 HEAD 입니다. HEAD 에 대한 200 은 본문이 비어 있는 것이 정상입니다. HEAD 는 내려받기 전에 크기나 고친 시각만 먼저 보려고 쓰는 메서드이기 때문입니다.

캐시와 조건부 요청에서의 200

200 응답은 따로 막지 않으면 캐시가 저장해도 되는 응답으로 칩니다. 저장을 막거나 얼마 동안 써도 되는지 정하려면 Cache-Control 헤더에 적습니다.

조건부 요청은 「내가 가진 버전과 같으면 보내지 마라」는 단서를 붙인 요청입니다. 브라우저가 어제 받아 둔 이미지를 오늘 다시 쓰기 전에 이 요청을 보냅니다.

이 요청을 받은 서버는 두 값 중 하나를 고릅니다. 버전이 같으면 본문 없이 304 Not Modified를 돌려줍니다. 버전이 달라졌으면 200 과 함께 새 내용 전부를 보냅니다. 여기서 200 은 「내용이 바뀌었으니 새로 받아라」는 뜻을 겸합니다.

200 대신 다른 성공 코드를 고를 때

백엔드에서 응답을 만들 때는 성공이면 무엇이든 200 으로 돌려주기 쉽습니다. 2 로 시작하는 코드는 여럿입니다. 각각이 200 보다 좁은 뜻을 전합니다. 아래 그림은 어느 코드를 고를지 묻는 순서입니다.

flowchart TD
    A{"받아 두기만 하고<br/>처리는 나중인가"} -- 예 --> B["202 Accepted"]
    A -- 아니오 --> C{"새 리소스를<br/>만들었나"}
    C -- 예 --> D["201 Created"]
    C -- 아니오 --> E{"돌려줄 본문이<br/>있나"}
    E -- 예 --> F["200 OK"]
    E -- 아니오 --> G["204 No Content"]

202 Accepted는 요청을 받아 두었지만 처리는 아직이라는 뜻입니다. 오래 걸리는 작업을 뒤에서 돌릴 때 씁니다. 클라이언트는 이 코드를 보고 결과를 나중에 따로 확인해야 한다는 것을 압니다.

201 Created는 요청으로 새 리소스가 생겼다는 뜻입니다. 새 리소스의 주소는 대개 응답 헤더에 함께 알립니다. 회원 가입처럼 무언가를 새로 만드는 요청에 씁니다.

204 No Content는 해냈지만 돌려줄 본문이 없다는 뜻입니다. HEAD 를 빼면 200 은 본문이 따라온다는 전제를 깔고 있습니다. 보낼 내용이 없으면 204 를 써야 클라이언트가 본문을 기다리지 않습니다.

그림의 앞 두 질문에 모두 아니오이고 돌려줄 본문이 있으면 200 입니다. 요청이 실패했다면 이 그림을 타지 않습니다. 그때는 4 나 5 로 시작하는 코드를 씁니다.

200 인데 실패인 응답

200 을 받았는데도 일이 잘못된 경우가 둘 있습니다. 하나는 서버가 실패를 본문에만 적은 경우입니다. 다른 하나는 본문을 보내는 도중에 서버가 멈춘 경우입니다.

어떤 API(Application Programming Interface, 프로그램끼리 기능을 불러 쓰는 약속)는 오류가 나도 상태 코드를 200 으로 둡니다. 대신 본문에 {"error": "not_found"} 처럼 오류를 알리는 필드를 넣습니다. 이렇게 하면 캐시와 모니터링이 실패를 성공으로 봅니다. 캐시는 오류 응답을 저장해 다음 요청에 다시 내줄 수 있습니다.

웹 페이지에서도 같은 일이 있습니다. 「찾는 페이지가 없습니다」라는 화면을 200 으로 내보내는 것을 소프트 404라고 부릅니다. 검색 엔진은 이 화면을 멀쩡한 문서로 알고 목록에 올릴 수 있습니다.

또 하나는 보내는 도중의 실패입니다. 상태 줄은 본문보다 먼저 나갑니다. 서버가 큰 본문을 조금씩 흘려보내다 중간에 멈추면 클라이언트는 200 을 받은 뒤에 잘린 본문을 받습니다.

이때 서버는 상태 코드를 바꿔 알릴 방법이 없습니다. 그래서 클라이언트가 본문의 끝을 보고 잘렸는지 가립니다. Content-Length 헤더가 있으면 그 길이만큼 왔는지 봅니다.

길이를 미리 알리지 못하는 응답은 본문을 조각으로 나눠 보내고 맨 끝에 빈 조각을 붙입니다. 이 빈 조각이 끝 표시입니다. 이런 방식을 청크 전송 인코딩이라고 부릅니다. 끝 표시가 오기 전에 연결이 끊기면 본문이 잘린 것입니다.

관련 항목

200 이 속하는 상위 분류

상태 코드 · 상태 코드 등급 · 성공 응답 · HTTP · HTTP 응답

200 과 함께 응답을 이루는 구성 요소

상태 줄 · 사유 구절 · 헤더 · 응답 본문 · Content-Type · Content-Length

200 대신 고르는 다른 성공 코드

201 Created · 202 Accepted · 204 No Content · 206 Partial Content

200 과 맞세워지는 안내·오류 코드

301 Moved Permanently · 304 Not Modified · 404 Not Found · HTTP 403 · HTTP 429 · 500 Internal Server Error

200 응답의 본문을 정하는 메서드

요청 메서드 · GET · HEAD · POST · PUT · DELETE · OPTIONS

200 응답을 저장하고 다시 묻는 캐시 장치

HTTP 캐시 · Cache-Control · 조건부 요청 · 재검증 · 검증자 · ETag · 신선도

200 을 성공 신호로 읽는 도구

모니터링 · 헬스 체크 · 로드 밸런서 · 프록시 · 검색 엔진

200 을 두고 내리는 설계 판단

API 설계 · REST · 소프트 404 · 오류 응답 본문 · 청크 전송 인코딩