Webhooks vs. Polling

웹 애플리케이션에서 외부 시스템과 통신하거나 상태 변화를 감지하는 방식에는 대표적으로 웹훅(Webhooks)과 폴링(Polling)이 있다. 이 두 방식은 서로 다른 접근 방식을 가지고 있으며, 각각 고유한 장단점이 있다.

웹훅(Webhooks)

정의와 작동 방식

웹훅은 “역방향 API” 또는 “사용자 정의 콜백"이라고도 불리며, 이벤트 기반 통신 방식이다.
웹훅은 특정 이벤트가 발생했을 때 한 애플리케이션이 다른 애플리케이션에 HTTP POST 요청을 통해 실시간으로 데이터를 전송하는 방식이다.

작동 과정:

  1. 클라이언트(데이터를 수신하는 측)가 서버(데이터를 제공하는 측)에 콜백 URL을 등록한다.
  2. 서버에서 특정 이벤트가 발생하면 해당 URL로 HTTP POST 요청을 보낸다.
  3. 클라이언트는 이 요청을 수신하고 처리한다.

주요 사용 사례

장점

  1. 효율성: 변경이 있을 때만 통신이 발생하므로 리소스 사용이 효율적이다.
  2. 실시간성: 이벤트 발생 즉시 알림이 전송되어 실시간에 가까운 통신이 가능하다.
  3. 확장성: 폴링보다 서버 부하가 적어 대규모 시스템에서 더 확장성이 좋다.
  4. 푸시 기반: 데이터 제공자가 능동적으로 데이터를 푸시하므로 수신자는 수동적으로 대기만 하면 된다.

단점

  1. 구현 복잡성: 수신 엔드포인트 설정, 인증, 재시도 메커니즘 등 구현이 복잡할 수 있다.
  2. 보안 위험: 공개적으로 접근 가능한 엔드포인트를 노출해야 하므로 보안 위험이 있다.
  3. 신뢰성 문제: 네트워크 오류나 서버 다운으로 인해 웹훅 전송이 실패할 수 있다.
  4. 디버깅 어려움: 비동기적 특성으로 인해 디버깅이 어려울 수 있다.

구현 예시

GitHub 웹훅을 사용하여 저장소 이벤트를 수신하는 Node.js 서버:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

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

app.post('/webhook', (req, res) => {
  const event = req.headers['x-github-event'];
  const payload = req.body;
  
  console.log(`Received ${event} event`);
  console.log(payload);
  
  // 이벤트 처리 로직
  
  res.status(200).send('Webhook received successfully');
});

app.listen(3000, () => {
  console.log('Webhook server running on port 3000');
});

폴링(Polling)

정의와 작동 방식

폴링은 클라이언트가 주기적으로 서버에 요청을 보내 변경사항이나 업데이트를 확인하는 방식이다. 클라이언트는 일정한 간격으로 서버에 데이터를 요청하고, 서버는 그 시점의 최신 정보를 응답한다.

작동 과정:

  1. 클라이언트가 주기적으로(예: 5초마다) 서버에 HTTP 요청을 보낸다.
  2. 서버는 현재 상태나 새로운 데이터가 있는지 확인하고 응답한다.
  3. 클라이언트는 응답을 받아 처리한 후, 다시 일정 시간을 기다렸다가 과정을 반복한다.

주요 사용 사례

장점

  1. 구현 용이성: 간단한 HTTP 요청만으로 구현 가능하여 기술적 복잡성이 낮다.
  2. 신뢰성: 클라이언트가 제어하므로 데이터 수신 여부를 확인하기 쉽다.
  3. 방화벽 친화적: 일반적인 HTTP 요청이므로 방화벽 문제가 적다.
  4. 디버깅 용이성: 요청-응답 패턴이 명확해 디버깅이 상대적으로 쉽다.

단점

  1. 리소스 낭비: 변경 여부와 관계없이 계속해서 요청을 보내므로 서버 및 네트워크 리소스를 낭비한다.
  2. 지연 발생: 폴링 간격에 따라 실시간성이 떨어진다.
  3. 확장성 제한: 클라이언트 수가 증가할수록 서버 부하가 크게 증가한다.
  4. 불필요한 요청: 대부분의 요청은 변경사항이 없을 때도 발생하여 효율성이 떨어진다.

구현 예시

5초마다 서버에 새로운 데이터가 있는지 확인하는 JavaScript 폴링 함수:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

function pollServer() {
  fetch('https://api.example.com/data')
    .then(response => response.json())
    .then(data => {
      // 데이터 처리 로직
      console.log('Received data:', data);
    })
    .catch(error => {
      console.error('Error polling server:', error);
    })
    .finally(() => {
      // 5초 후 다시 폴링
      setTimeout(pollServer, 5000);
    });
}

// 폴링 시작
pollServer();

롱 폴링(Long Polling)

웹훅과 폴링 사이의 중간 지점으로, 롱 폴링이라는 방식도 있다.
롱 폴링은 클라이언트가 서버에 요청을 보내면 서버가 이벤트가 발생할 때까지 응답을 지연시키는 방식이다. 이벤트가 발생하면 서버는 응답을 보내고, 클라이언트는 즉시 새 요청을 시작한다.

장점:

단점:

웹훅 vs. 폴링 비교

특성웹훅(Webhooks)폴링(Polling)
통신 방식푸시 기반 (서버 → 클라이언트)풀 기반 (클라이언트 → 서버)
데이터 전송 시점이벤트 발생 시 즉시정해진 간격으로 주기적
실시간성높음 (즉시 전송)낮음 (폴링 간격에 의존)
리소스 효율성높음 (필요 시에만 통신)낮음 (변경 여부와 무관하게 통신)
서버 부하낮음 (이벤트 발생 시에만)높음 (지속적인 요청 처리)
구현 복잡성높음 (콜백 URL, 인증, 오류 처리 등)낮음 (간단한 HTTP 요청)
보안 고려사항공개 엔드포인트, 인증, 검증 필요표준 API 보안과 동일
신뢰성중간 (네트워크 오류로 알림 누락 가능)높음 (클라이언트 제어로 재시도 용이)
확장성높음 (많은 클라이언트에 효율적)낮음 (클라이언트 증가에 따른 서버 부하 증가)
방화벽 친화성낮음 (인바운드 연결 허용 필요)높음 (일반적인 아웃바운드 연결)
디버깅 용이성낮음 (비동기적 특성으로 추적 어려움)높음 (동기적 요청-응답 패턴)
적합한 사용 사례중요한 이벤트 알림, 결제 처리, 비동기 워크플로우자주 바뀌는 데이터 모니터링, 채팅 앱, 실시간성이 덜 중요한 경우
인프라 요구사항공개적으로 접근 가능한 서버 필요특별한 인프라 요구사항 없음
대표적 사용 서비스GitHub, Stripe, Twilio, Slack이메일 클라이언트, 레거시 시스템, 간단한 모니터링 도구

선택 가이드라인

다음 상황에서는 웹훅을 고려한다:

다음 상황에서는 폴링을 고려한다:

하이브리드 접근 방식

많은 현대 시스템은 웹훅과 폴링을 조합한 하이브리드 접근 방식을 채택한다:

두 방식 모두 각자의 장단점이 있으므로, 시스템 요구사항과 제약 조건에 따라 적절한 방식을 선택하거나 조합하는 것이 중요하다.

참고 및 출처