HTTP Request와 Response
🌿 자라는 중
HTTP 통신은 Request ↔ Response 한 쌍의 왕복이 전부다. 한 줄 비유: HTTP는 손님이 주문해야 음식이 나오는 식당이다.
- Request (요청): 클라이언트가 서버에게 보내는 메시지. “이거 해줘”에 해당하며, 뭘 해달라는 건지가 메서드(GET, POST…)로 적혀 있다. HTTP에서 통신을 시작할 수 있는 건 언제나 Request 쪽이다
- Response (응답): 서버가 Request를 받고 돌려주는 답. 됐는지 안 됐는지가 상태 코드(200, 404…)로 적혀 있다. Request 하나당 Response 하나가 짝이고, 짝이 안 돌아오면 타임아웃
- Reply (응답): 뜻은 Response와 같지만 공식 용어인지는 프로토콜마다 다르다. HTTP 표준어는 Response고, ARP·ICMP(ping)에서는 Reply가 공식 명칭. “리플라이 리퀘스트”라는 말이 어색하게 들리는 이유 - HTTP 얘기라면 Request ↔ Response라고 불러야 맞다
HTTP는 식당이다
- Request = 손님이 주문하는 것. “김치찌개 하나요”
- Response = 주방이 음식을 내주는 것
규칙은 세 개뿐이다.
- 손님이 먼저 말해야 한다. 주방이 먼저 음식을 갖다주는 일은 없다. HTTP는 무조건 클라이언트의 Request가 먼저고, 서버는 Response로만 답할 수 있다. (그래서 서버가 먼저 알려야 하는 실시간 알림에는 WebSocket이나 웹훅 같은 다른 방법을 쓴다)
- 주문 1개 = 음식 1개. 음식이 안 나오면 기다리다 포기하는데, 이게 타임아웃이다.
- 주문서와 음식엔 각자 다른 게 적혀 있다. 주문서에는 “뭘 해달라”(메서드), 음식에는 “됐다/안 됐다”(상태 코드). 서로 상대쪽엔 없는 필드다.
동네마다 다른 표준어
| 프로토콜 | 공식 쌍 |
|---|---|
| HTTP | Request ↔ Response |
| ARP, ICMP(ping) | Request ↔ Reply |
| DNS | Query ↔ Response |
“Reply는 HTTP 스펙에 없다”는 말은 Reply가 틀린 단어라는 게 아니라, HTTP 동네에서는 Response가 표준어라는 뜻이다. 반대로 Request ↔ Reply가 공식 명칭인 동네도 있다 → ARP개념 및 ARP Request와 ARP Reply 동작 차이
실무 메모 - Slack 봇의 3초 룰
Slack이 우리 서버로 이벤트를 보낼 때는 역할이 뒤집힌다. Slack이 손님(클라이언트), 내 서버가 식당(서버)이 된다.
이때 3초 안에 200 응답을 안 주면 Slack이 같은 이벤트를 재시도로 또 보낸다. 그래서 무거운 작업(RAG 검색 등)은 일단 200부터 반환하고 백그라운드로 처리한 뒤 결과를 따로 보내는 구조가 정석이다. ②의 200은 진짜 답이 아니라 “주문 접수됐습니다” 영수증인 셈이다.
두 가지 포인트:
- ③은 Response가 아니라 완전히 새로운 Request다. ①-②의 왕복은 이미 끝났으니, 이번엔 내 서버가 클라이언트가 되어 Slack API에 새로 요청하는 것. 클라이언트/서버는 기계에 붙는 이름이 아니라 그 순간의 역할이다
- 결과를 보낼 때 쓰는 “답장 전용 주소”(
response_url)는 슬래시 커맨드나 버튼 클릭일 때만 딸려 온다. 봇이 그냥 멘션된 경우엔 없으니chat.postMessageAPI로 채널에 직접 보내야 한다
연결되는 것들
- HTTP는 TCP 위에서 달린다. Request/Response가 정확히 전달돼야 하니까, 밑에서는 TCP가 연결을 맺고 유실을 재전송해주고 있다 → TCP와 UDP 차이
- 처음 이 개념을 주운 날의 기록: 오늘 배운 단어 - Request·Response·Reply
한 줄 요약: HTTP는 손님이 주문해야 음식이 나오는 식당이고, Reply냐 Response냐는 프로토콜마다 다른 표준어일 뿐이다.