📌 백엔드 통신 디자인 패턴 — 요청·응답과 푸시 모델 완전 정리

1. 들어가며

백엔드 개발에서 가장 고전적이고 널리 쓰이는 통신 패턴은 요청(Request)-응답(Response) 모델입니다.
HTTP, DNS, RPC, SQL, API 등 거의 모든 프로토콜의 기본 구조가 이 패턴을 기반으로 합니다.

이번 글에서는 요청·응답 패턴의 구조·동작 과정·비용 요소를 살펴보고, 실시간성 요구가 높은 경우 활용되는 푸시 모델까지 비교해 정리합니다.

---

2. 요청-응답 패턴이란?

기본 개념

• 클라이언트(Client): 요청(Request)을 전송
• 서버(Server): 요청을 파싱하고 처리 후, 응답(Response) 반환
• 핵심 특징: 클라이언트가 요청해야 서버가 응답 → Pull 기반 모델

[Client] -- 요청 --> [Server]
[Client] <-- 응답 -- [Server]

---

3. 요청·응답 동작 과정

3.1 요청(Request)

1. 작성
   • 데이터 직렬화(JSON, XML, ProtoBuf 등)
   • 네트워크 전송 준비
2. 전송
   • TCP/UDP 패킷 단위로 분할
   • 네트워크 레이턴시(Latency) 발생
3. 파싱
   • 서버가 요청의 시작·끝 경계를 파악
   • 직렬화된 데이터를 역직렬화해 사용 가능한 객체로 변환

---

3.2 응답(Response)

1. 처리
   • 서버가 요청 로직 실행 (DB 조회, 연산 등)
2. 응답 작성
   • 직렬화 후 전송
3. 수신
   • 클라이언트가 응답의 경계 파악
   • 역직렬화 후 화면 표시 또는 후속 로직 실행

---

4. 요청·응답의 성능 비용 요소

• 네트워크 전송 시간 (요청·응답 모두)
• 직렬화/역직렬화 비용
  • JSON > ProtoBuf (속도·메모리 효율 차이)
• 파싱 오버헤드
• 네트워크 패킷 재조합 비용
• 응답 처리 시간

💡 예시: curl --trace로 HTTP 요청을 분석하면, DNS 조회 → TCP 연결 → 요청 전송 → 응답 헤더 수신 → 바디 수신 순서가 명확히 보임.

---

5. 요청·응답의 한계

1. 실시간성 부족
   • 서버에서 이벤트가 발생해도, 클라이언트가 요청해야만 알 수 있음
2. 폴링(Polling) 부하
   • "새 알림 있나요?"를 반복적으로 요청하면 네트워크·서버 리소스 낭비
3. 긴 처리 시간 문제
   • 요청-응답이 오래 걸리면 클라이언트가 연결을 유지해야 함
   • 연결 끊기면 상태 동기화 어려움

---

6. 푸시(Push) 모델

개념

• 서버가 이벤트 발생 시 즉시 클라이언트에 데이터 전송
• 클라이언트가 지속적으로 요청할 필요 없음
• 실시간성이 필요한 서비스에 적합

[Server] -- 이벤트 발생 --> 즉시 [Client]에 전달

---

6.1 작동 방식

1. 연결 설정
   • 클라이언트가 서버와 지속 연결(WebSocket, TCP 등) 생성
2. 이벤트 발생
   • 서버가 해당 연결을 통해 즉시 데이터 전송
3. 수신 처리
   • 클라이언트는 수신 이벤트 핸들러로 데이터 처리

---

6.2 장점

• 실시간 알림 가능
• 불필요한 요청 감소 (폴링 대비 효율적)

---

6.3 단점

• 항상 연결 필요
  • 오프라인 클라이언트에는 푸시 불가 (재연결 후 동기화 필요)
• 부하 조절 어려움
  • 서버가 무조건 전송 → 클라이언트 처리 속도 초과 가능
• 규모 확장 복잡
  • 수많은 클라이언트 동시 연결 시 부하 증가

---

7. 푸시 모델 실전 예시 — Node.js WebSocket 채팅

서버 예시 코드

const http = require('http');
const WebSocket = require('ws');

const server = http.createServer();
const wss = new WebSocket.Server({ server });

let clients = [];

wss.on('connection', (ws) => {
  clients.push(ws);

  ws.on('message', (msg) => {
    // 모든 클라이언트에게 메시지 푸시
    clients.forEach(client => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(msg);
      }
    });
  });

  ws.on('close', () => {
    clients = clients.filter(c => c !== ws);
  });
});

server.listen(8080, () => console.log('Server started on 8080'));

---

동작 흐름

1. 사용자 연결 → connection 이벤트 발생
2. 메시지 전송 → 서버가 연결된 모든 클라이언트에 푸시
3. 클라이언트 연결 종료 → 배열에서 제거

---

사용 예시 (브라우저 콘솔)

// 연결
const ws = new WebSocket('ws://localhost:8080');
ws.onmessage = (e) => console.log('받음:', e.data);

// 메시지 전송
ws.send('안녕하세요!');

---

8. 요청-응답 vs 푸시 비교

구분	요청-응답	푸시
방향성	클라이언트 요청 후 서버 응답	서버 → 클라이언트 이벤트 전송
실시간성	낮음	높음
연결 유지	요청 시만 연결	지속 연결 필요
부하 관리	요청 빈도로 제어	서버에서 제어 어려움
활용 예시	API 호출, DB 쿼리	채팅, 실시간 알림, 스트리밍

---

9. 마치며

• 요청-응답은 범용적이고 단순하지만, 실시간성이 필요한 서비스엔 한계가 있음
• 푸시 모델은 실시간성에 강하지만, 연결 유지·부하 조절·확장성에 주의해야 함
• 실제 서비스는 두 모델을 혼합하는 경우가 많음
  • 예: 일반 데이터는 요청-응답, 실시간 이벤트는 푸시(WebSocket, SSE)

📚 다음 글에서는 푸시 모델의 변형 형태인 롱 폴링(Long Polling)과 Pub/Sub 구조를 다루겠습니다.