요청-응답 모델 이해하기

Source: Dev.to

Overview

Request–Response는 인터넷과 오늘날 우리가 사용하는 대부분의 기술이 실제로 작동하는 방식을 근간으로 하는 흥미로운 주제입니다.

이름이 말해주듯, Request–Response 모델은 클라이언트(요청자)와 서버(응답자)가 통신하는 방식입니다. 이 통신은 동기적으로(응답을 기다림) 혹은 비동기적으로(대기 중에도 차단되지 않음) 일어날 수 있습니다.

핵심 아이디어는 간단합니다:

• 요청은 클라이언트(요청자)에 의해 전송됩니다. 이 요청에는 클라이언트가 원하는 데이터, 명령, 파라미터, 헤더 등 다양한 정보가 포함됩니다.
• 서버가 이 요청을 받으면 이를 이해하고 처리한 뒤, 적절한 응답을 되돌려 보냅니다. 우리는 이를 response라고 부릅니다.

How the Request–Response Model Works

1. Client sends a request – 클라이언트가 서버에 요청을 보내면서 통신을 시작합니다.
2. Server parses the request – 서버는 요청을 헤더, 본문, 파라미터 등으로 나누어 무엇을 요구하는지 파악합니다.
3. Server processes the request – 서버는 역직렬화, 비즈니스 로직 수행, 데이터베이스 쿼리, 검증 등을 수행합니다.
4. Server sends a response – 처리 후 서버는 상태 코드, 헤더, 데이터를 포함한 응답을 준비해 전송합니다.
5. Client parses and consumes the response – 클라이언트는 응답을 해석하고 UI 렌더링, 상태 업데이트, 액션 트리거 등 필요한 작업에 사용합니다.

Where Is the Request–Response Model Used?

• 웹 기술: HTTP, DNS, SSH
• RPC (Remote Procedure Calls)
• SQL 및 데이터베이스 프로토콜
• API: REST, SOAP, GraphQL

웹 페이지를 로드하거나, 앱에 로그인하거나, API에서 데이터를 가져본 적이 있다면 이 모델을 사용한 것입니다.

Structure of a Request–Response Model

• 요청은 명확한 경계를 가집니다.
• 프로토콜(예: HTTP)은 통신 방식이 어떻게 이루어지는지를 정의합니다.
• 메시지 포맷(JSON, XML 등)은 데이터가 어떻게 표현되는지를 정의합니다.
• 양측은 이러한 규칙에 동의해야 통신이 정상적으로 이루어집니다.

Limitations of the Request–Response Model

• Notifications (real‑time updates) – 지속적인 폴링은 비효율적이며, WebSocket 같은 푸시 기반 프로토콜이 더 적합합니다.
• Very long‑running requests – 클라이언트가 응답을 기다리는 동안 차단될 수 있어 이 모델에 부적합합니다.
• Concurrency and load‑balancing challenges – 동시에 많은 요청을 처리하려면 서버가 적절히 설계되지 않을 경우 과부하가 발생합니다.
• Data streaming – 연속적인 스트림(비디오, 실시간 피드)은 단일 요청‑응답 사이클에 잘 맞지 않습니다.
• Offline or unreliable networks – 연결이 끊기면 흐름이 중단됩니다.
• Highly decoupled systems – 이벤트 기반 또는 메시지 기반 아키텍처가 더 선호됩니다.

Conclusion

Request–Response 모델은 컴퓨팅에서 가장 중요한 통신 패턴 중 하나이며, 웹, API, 데이터베이스 및 우리가 매일 의존하는 많은 시스템을 구동합니다.

단순하고 강력하지만, 그 한계를 이해하는 것 역시 작동 방식을 이해하는 만큼 중요합니다. 언제 Request–Response를 사용하고 언제 사용하지 말아야 하는지를 아는 것은 확장 가능하고 효율적인 시스템을 구축하는 핵심 역량입니다.

이 모델을 잘 이해하고 있다면, 현대 소프트웨어가 어떻게 소통하는지에 대한 큰 부분을 이미 파악한 것입니다.