요청과 응답

The Request-Response model is a message exchange pattern in which a requester sends a request message to a replier system.

— W3C 분산 컴퓨터 아키텍처 권고 규격에서 공식 명시하는, 단방향 메시지 교환 및 결합 모델의 정의

먼저 말을 걸지 않으면 절대 응답을 먼저 내려주지 않는 매정하고 시크한 서버를 향해, 끊임없이 구애 패킷을 쏘아 올리는 클라이언트의 가혹한 짝사랑 핑퐁 게임. 백엔드에서 혼신을 다해 가공한 우아한 응답 데이터를 준비해 놨더라도, 클라이언트가 먼저 '요청'이라는 초인종 단추를 눌러주지 않으면 서버실 하드 속에서 평생 썩어 문드러질 운명(...)

1. 개요

네트워크 아키텍처 구조 속에서 데이터를 공유하고 협업할 때 통용되는 절대 룰. 서비스를 요구하는 쪽(클라이언트)이 먼저 질문하는 패킷을 전송하는 요청(Request) 단계와, 서비스를 대기 중이던 쪽(서버)이 이 패킷을 해석하고 가공하여 알맞은 데이터를 다시 회신해 주는 응답(Response) 단계가 철저하게 맞물리는 턴제 핑퐁(Ping-Pong)식 네트워크 통신 대전제를 일컫는다.

2. 손님의 주문(Request)과 주방의 요리 서빙(Response)

이 소통 흐름은 식당의 동작 원리와 소름 돋게 일치한다. 손님(클라이언트)이 테이블에 앉아 메뉴판(API 명세서)을 보고 웨이터에게 '돈까스 하나 가져다주세요'라고 정중히 요구하는 행위가 Request이다. 이 신호가 주방(서버)에 도착하면, 요리사는 고기를 다듬고 튀겨(데이터베이스 쿼리 및 연산) 완성된 바삭한 돈까스 요리를 접시에 담아 손님 테이블로 안전 서빙해 돌려주는데, 이 행위가 바로 Response이다. 요리가 손님에게 서빙 완료(응답 성공)되는 순간, 웨이터는 주문지를 찢어버리고 손님과의 실시간 교신 끈을 가볍게 끊어 독립적인 상태로 돌아간다.

3. 요청의 구성 요소와 응답 상태 코드(Status Code)

이들의 대화록인 HTTP 메시지 장부에는 정교한 통신 메타데이터 규격 정보들이 박혀있다. 요청(Request) 패킷 안에는 어떤 동작을 원하는지 밝히는 행동 메서드(GET, POST, PUT, DELETE)와 목적지 주소(URL), 그리고 실질적인 데이터 알맹이인 바디(Body)가 동봉된다. 응답(Response) 패킷 안에는 데이터와 함께, 이 주문이 성공했는지 실패했는지 기계가 단 0.1초 만에 인지할 수 있도록 우아한 응답 상태 코드(Status Code) 번호표를 머리에 붙여 내려보낸다.

2xx (성공): 200 OK, 201 Created 등 주문하신 요리가 정상 완성되어 배달되었다는 축복의 신호.
3xx (리다이렉션): 301 Moved Permanently 등 요리 만드는 가게 주소가 이사 갔으니 새 주소로 다시 찾아가 주문하라는 안내.
4xx (클라이언트 에러): 404 Not Found, 401 Unauthorized 등 손님이 메뉴판에도 없는 변태 같은 해괴한 요리를 주문했거나 외상 계약 인증서 없이 무지성 주문했다가 거부당하는 손님 잘못 에러.
5xx (서버 에러): 500 Internal Server [Error](./error.md) 등 주방장이 요리하다가 주방 프라이팬에 불을 내서 주방이 터져버렸으니 나중에 다시 주문해달라는 서버 자폭 참사 에러.(...)

4. 관련 밈 및 드립

4.1. 외롭고 슬픈 404 Not Found의 비명

클라이언트가 서버의 특정 URL 엔드포인트 경로를 타고 들어와 자료를 요구했으나, 서버의 하드디스크 속이나 가상 라우터 맵에 해당 리소스가 흔적도 없이 사라졌을 때 내뿜는 공포의 상태 코드이다. 전 세계 수많은 웹 서퍼들과 개발자들은 이 '404 Not Found' 화면을 마주하는 것을 세상에서 버림받은 듯한 외롭고 참담한 기분과 자조적으로 동치 시키며 위트 있는 길 잃은 유량자 밈으로 활발하게 박제해 소비하곤 한다.

5. 여담

HTTP의 비정한 특성, 무상태성 (Stateless): 요청과 응답 모델의 최대 전제는 '서버는 손님의 이전 대화 상태를 1도 기억하지 못하는 무상태성'에 있다. 1초 전에 로그인 요청을 성공해서 '아주 훌륭해요!' 하고 응답을 받았더라도, 1초 뒤에 마이페이지 클릭 요청을 보내면 서버는 '너 처음 보는데 누구세요?'라며 자비 없이 쫓아낸다. 이 때문에 우리는 로그인 명찰 자물쇠 역할을 해주는 세션(session)이나 토큰(token)을 매 요청마다 눈물겹게 손에 쥐여서 보내야만 한다.
핑퐁의 한계를 부순 실시간 양방향 통신: 손님이 주문하기 전에는 주방장이 먼저 음식을 절대 내줄 수 없는 이 단방향 요청/응답 핑퐁의 한계를 부수고, 실시간 주식 차트나 채팅처럼 서버가 클라이언트에게 신호를 먼저 능동적으로 마구 쏘아 보낼 수 있도록 고안한 혁신적인 통신 파이프 라인이 바로 웹소켓(websocket)과 SSE(server-sent-events) 기술이다.
보이지 않는 3-way handshake: 요청 패킷을 쏘기 전, 컴퓨터는 물밑에서 서버와 서로 가볍게 세 번 고개를 숙여 인사하는 TCP 3-way handshake를 전사 실행한다. '내 신호 들리니?', '어 잘 들려! 내 신호도 들리니?', '어 잘 들려! 자 대화 시작하자!' 하는 정교한 하드웨어 물리 통신 확인 도장 완료가 끝난 뒤에야 비로소 우아한 HTTP 요청 패킷이 선로 위를 질주하게 된다.