웹훅 vs 폴링, 어떤 방식이 맞을까
안녕하세요, 채원이에요.
두 시스템이 데이터를 주고받는 방법은 크게 두 가지예요. 웹훅(webhook)과 폴링(polling). 이름은 어려워 보이지만, 개념은 정말 간단해요.
이전 글에서 웹훅에 대해 이야기했었는데, 오늘은 폴링과 비교해서 어떤 상황에 어떤 방식이 맞는지 정리해 볼게요.
다시 한번, 택배 비유
폴링은 택배 아저씨에게 "혹시 내 택배 왔어요?" 하고 매시간 전화하는 거예요. 안 왔어도 전화하고, 또 안 왔어도 전화하고. 드디어 왔다는 대답을 듣고 나서야 가져와요.
웹훅은 택배가 오면 초인종을 눌러주는 거예요. 내가 물어볼 필요 없이, 도착하면 알아서 알려줘요.
기술적으로 말하면:
- 폴링: 일정 간격으로 "새 데이터 있어?" 하고 물어보는 방식 (Pull)
- 웹훅: 새 데이터가 생기면 알아서 보내주는 방식 (Push)
비교표
| 폴링 (Polling) | 웹훅 (Webhook) | |
|---|---|---|
| 방식 | 주기적으로 물어봄 | 이벤트 발생 시 알려줌 |
| 실시간성 | 낮음 (간격에 따라) | 높음 (거의 즉시) |
| 효율 | 낮음 (빈 응답이 많음) | 높음 (필요할 때만 동작) |
| 구현 난이도 | 상대적으로 쉬움 | 수신 서버가 필요 |
| 데이터 누락 | 간격 사이에 놓칠 수 있음 | 실패 시 재시도 가능 |
| 서버 부하 | 높음 (계속 요청) | 낮음 (이벤트 때만) |
| 비용 | API 호출 횟수에 비례 | 이벤트 횟수에 비례 |
| 주의사항 | API 호출 한도 초과 주의 | 중복 수신·순서 비보장 가능 |
웹훅을 쓸 때 알아둘 것
웹훅이 효율적이긴 하지만, 몇 가지 알아두면 좋은 특성이 있어요:
- 수신 측 요청 제한 (rate limit) — 우리 서버가 초당 받을 수 있는 요청 수에 제한이 있을 수 있어요. 데이터가 갑자기 몰리면 일부가 거부될 수 있으니, 연동 전에 양쪽의 처리 한도를 확인하세요
- 중복 수신 가능 — 네트워크 문제로 보내는 쪽이 "전달 실패"로 판단하고 재시도하면, 같은 데이터가 두 번 올 수 있어요. 중요한 데이터라면
order_id같은 고유값으로 중복을 걸러내는 게 좋아요 - 순서 비보장 — 웹훅은 이벤트 순서대로 도착한다는 보장이 없어요. 예를 들어 "주문 생성" 알림보다 "주문 변경" 알림이 먼저 올 수도 있어요. 타임스탬프를 기준으로 판단하세요
- 응답 시간 — 웹훅을 보내는 쪽은 보통 5~10초 안에 응답을 기대해요. 무거운 처리가 필요하면 일단 빠르게 "받았다" 응답을 하고, 처리는 비동기로 하는 게 안전해요
이런 특성 때문에 아래 "실전 조합" 섹션에서 이야기하는 것처럼, 웹훅과 폴링을 함께 쓰는 경우가 많아요.
폴링이 적합한 경우
폴링이 나쁜 방식은 아니에요. 이런 상황에서는 폴링이 더 맞아요:
- 상대방이 웹훅을 지원하지 않을 때 — 아직도 웹훅을 제공하지 않는 시스템이 있어요. 이 경우 폴링이 유일한 방법이에요
- 대량의 과거 데이터를 가져올 때 — "지난 한 달치 주문을 한꺼번에 가져오기" 같은 경우에는 폴링(정확히는 API 조회)이 적합해요
- 실시간이 중요하지 않을 때 — 하루에 한 번 데이터를 동기화하면 충분한 경우
웹훅이 적합한 경우
대부분의 비즈니스 상황에서는 웹훅이 더 나아요:
- 실시간 알림이 필요할 때 — 주문, 결제, 예약 같은 즉시 대응이 필요한 이벤트
- 비용을 줄이고 싶을 때 — 쓸데없이 "새 거 있어?" 물어보는 비용이 없어요
- 자동화를 구축할 때 — "주문이 오면 → 슬랙 알림 → 자동 기록" 같은 워크플로우
- 여러 소스의 데이터를 통합할 때 — 각 소스가 데이터를 보내주면, 한곳에서 모아 관리
웹훅의 한 가지 허들: 수신 서버
웹훅의 가장 큰 걸림돌은 "데이터를 받을 서버가 필요하다"는 거예요.
폴링은 내가 물어보러 가는 거니까, 간단한 스크립트만 있으면 돼요. 하지만 웹훅은 상대방이 보내주는 거니까, 보낼 곳(URL)이 있어야 해요. 보통은 서버를 직접 운영하거나 만들어야 한다는 뜻이에요.
3Min API가 해결하는 게 바로 이 부분이에요. 서버 없이도 웹훅을 받을 수 있는 URL을 만들어주니까요. 클릭 몇 번이면 웹훅 수신 엔드포인트가 준비돼요.
실전 조합: 웹훅 + 폴링
사실 현실에서는 두 방식을 함께 쓰는 경우가 많아요:
- 실시간 데이터는 웹훅으로 받기
- 과거 데이터 동기화나 누락분 확인은 폴링(API 조회)으로 보완
예를 들어, 쇼핑몰 주문 데이터를 웹훅으로 실시간 수신하면서, 하루에 한 번 API 조회로 "혹시 놓친 주문이 없는지" 확인하는 식이에요.
3Min API에서도 이 조합이 가능해요. 웹훅으로 데이터를 받으면서, 필요할 때 대시보드나 API로 저장된 데이터를 조회할 수 있어요.
정리
- 빠르고 자동화된 데이터 수신이 필요하면 → 웹훅
- 과거 데이터 조회나 상대가 웹훅을 지원하지 않으면 → 폴링
- 가장 안정적인 방법은 → 웹훅 + 폴링 조합
어떤 방식이 우리에게 맞을지 고민이라면, 일단 웹훅부터 시작하는 걸 추천해요. 대부분의 비즈니스 상황에서 웹훅이 더 효율적이고, 자동화의 기반이 되니까요.