📡 백엔드 통신 패턴 총정리 — Short Polling, Long Polling, SSE, Pub/Sub

1. 들어가며

백엔드 개발에서는 클라이언트 ↔ 서버 간 데이터를 주고받는 방식이 다양합니다.
이번 글에서는 가장 대표적인 네 가지 패턴:

1. Short Polling (짧은 폴링)
2. Long Polling (롱 폴링)
3. SSE (Server-Sent Events)
4. Pub/Sub (게시-구독)

을 구조부터 장단점, 실전 예제까지 정리합니다.

---

2. Short Polling (짧은 폴링)

개념

• "폴링"이란 일정 간격으로 서버에 요청을 보내 작업 완료 여부를 확인하는 방식
• 짧은 폴링은 주기가 매우 짧아, 클라이언트가 빠르게 상태를 재확인함
• 주로 비동기 처리 작업 상태 확인에 사용

---

동작 흐름

1. 클라이언트가 작업 요청 → 서버는 즉시 Job ID 반환
2. 클라이언트는 Job ID로 상태 확인 요청 반복
3. 작업 완료 시 서버가 결과 반환

[Client] POST /submit → { jobId }
[Client] GET /status?jobId=123 → { progress: 50% }
[Client] GET /status?jobId=123 → { progress: 100%, result: ... }

---

실전 예시

• YouTube 영상 업로드
  업로드 요청 후, 브라우저가 주기적으로 업로드 진행률 확인
• 이미지 처리, 대규모 데이터 변환 등 장기 작업 모니터링

---

장점

• 구현이 매우 간단 (백엔드·프론트엔드 모두)
• 장기 작업 상태를 안전하게 조회 가능
• 클라이언트가 연결을 끊었다가 재접속해도 이어서 상태 확인 가능

---

단점

• 네트워크 낭비: 대부분 요청이 "아직 준비 안 됨" 응답
• 클라이언트 수가 많으면 서버 부하 급증
• 응답이 즉시 필요 없는 경우에도 요청 전송 → 비용 증가

---

Node.js 예제 (Short Polling)

const express = require('express');
const app = express();
app.use(express.json());

let jobs = {};

app.post('/submit', (req, res) => {
  const jobId = Date.now().toString();
  jobs[jobId] = 0;
  updateJob(jobId);
  res.json({ jobId });
});

app.get('/status', (req, res) => {
  const jobId = req.query.jobId;
  res.json({ progress: jobs[jobId] });
});

function updateJob(jobId) {
  if (jobs[jobId] < 100) {
    setTimeout(() => {
      jobs[jobId] += 10;
      updateJob(jobId);
    }, 5000);
  }
}

app.listen(3000);

---

3. Long Polling (롱 폴링)

개념

• 폴링의 변형
• 클라이언트가 요청을 보내고 결과가 준비될 때까지 서버가 응답을 지연
• Kafka, 채팅 서버 등에서 사용

---

동작 흐름

1. 클라이언트 → "작업 상태 알려줘" 요청
2. 서버 → 작업 완료 전까지 응답 보류
3. 완료 시 즉시 응답 반환

[Client] GET /status?jobId=123 → (대기 중)
[Server] 작업 완료 시 응답 전송 → { progress: 100%, result: ... }

---

장점

• 네트워크 낭비 감소 (잡담 줄어듦)
• 서버 친화적 — 불필요한 "아직 안 됨" 트래픽 없음

---

단점

• 실시간성이 100% 보장되진 않음 (응답 직후 새 데이터 발생 가능)
• 연결 유지 시간 길어짐 → 서버 소켓 점유

---

Kafka 예시

• 소비자(Consumer)가 롱 폴링으로 토픽 구독
• 토픽에 메시지가 없으면 응답 대기 → 새 메시지 도착 시 응답

---

4. SSE (Server-Sent Events)

개념

• HTTP 기반 단방향 스트리밍
• 클라이언트가 1회 요청 → 서버가 연결 유지하며 이벤트 스트림 전송
• Content-Type: text/event-stream

---

동작 흐름

[Client] GET /stream
[Server] data: "msg1"\n\n
[Server] data: "msg2"\n\n

• 각 이벤트는 data:로 시작, 두 줄 바꿈으로 구분
• 브라우저 EventSource 객체로 자동 파싱 가능

---

장점

• 실시간성 ↑ (푸시 모델과 유사)
• HTTP 기반이라 방화벽·프록시 통과 용이
• WebSocket보다 구현 단순

---

단점

• 브라우저 동시 연결 제한(HTTP/1.1 → 도메인당 6개)
• 클라이언트가 오프라인이면 이벤트 수신 불가
• 클라이언트 처리 능력 초과 시 메시지 손실 가능

---

Node.js SSE 예제

app.get('/stream', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  let counter = 0;
  setInterval(() => {
    res.write(`data: ${counter++}\n\n`);
  }, 1000);
});

---

5. Pub/Sub (게시-구독)

개념

• 발행자(Publisher)가 메시지를 토픽에 게시
• 구독자(Subscriber)는 관심 있는 토픽만 소비
• 메시지 브로커(Kafka, RabbitMQ, Redis Pub/Sub) 사용

---

동작 흐름

[Publisher] → [Broker: topic A] → [Subscriber1]
                                 → [Subscriber2]

---

장점

• 느슨한 결합 (서비스 간 직접 호출 불필요)
• 여러 소비자 동시 처리 가능
• 비동기·확장성 우수

---

단점

• 메시지 전달 보장 문제(중복·유실)
• 브로커 운영·확장 복잡
• 소비 속도 제어 필요 (푸시 vs 폴링)

---

RabbitMQ 예제

// publisher.js
channel.assertQueue('jobs');
channel.sendToQueue('jobs', Buffer.from(JSON.stringify({ num: 107 })));

// consumer.js
channel.assertQueue('jobs');
channel.consume('jobs', (msg) => {
  console.log('Received:', msg.content.toString());
});

---

6. 비교 표

패턴	실시간성	네트워크 효율	구현 난이도	대표 사례
Short Polling	중간	낮음	매우 쉬움	진행률 조회
Long Polling	중간↑	높음	보통	Kafka 소비자
SSE	높음	높음	쉬움	실시간 알림
Pub/Sub	높음↑	높음↑	높음	마이크로서비스 이벤트

---

7. 마치며

• 짧은 폴링: 간단하지만 네트워크 낭비 심함
• 롱 폴링: 효율적이지만 완전 실시간은 아님
• SSE: HTTP 기반 실시간 스트리밍, 브라우저 친화적
• Pub/Sub: 대규모 확장·마이크로서비스에 필수

📌 상황·요구사항에 맞춰 혼합 사용이 일반적
예: 업로드 처리 → Pub/Sub로 마이크로서비스 연결,
클라이언트 업데이트는 SSE로 실시간 전달