안녕하세요! 오늘은 개발자라면 한 번쯤 들어봤을 웹훅(Webhook) 에 대해 이야기해보려고 합니다.
처음 접했을 때는 생소했지만, 알고 보면 여러 시스템이 실시간으로 협력할 수 있도록 도와주는 아주 유용한 개념이에요.
이번 글에서는 웹훅의 개념부터 실제로 어디서 어떻게 쓰이는지까지 정리해보겠습니다.
웹훅(Webhook)은 특정 이벤트가 발생했을 때, 미리 등록해둔 URL로 HTTP 요청을 자동 전송하는 방식이에요.
쉽게 말하면 "무슨 일이 생기면 알려줄게!" 라는 일종의 푸시 알림 시스템이라고 볼 수 있어요.
서버 간 데이터 연동을 생각해보면, 우리가 직접 계속 확인(polling)하지 않고도 이벤트 발생을 실시간으로 인지할 수 있으면 좋겠죠?
예를 들어...
이런 시나리오에서 웹훅은 중간다리 역할을 해주고, 이벤트 기반으로 깔끔한 시스템 흐름을 만들어줍니다.
웹훅의 기본적인 흐름은 아래와 같아요.
[이벤트 발생 시스템] ──▶ [Webhook POST 요청] ──▶ [내 서버에서 수신 및 처리]
| 구분 | 웹훅 (Webhook) | 폴링 (Polling) |
|---|---|---|
| 방식 | 푸시 (Push) | 주기적 요청 (Pull) |
| 실시간성 | 높음 | 낮음 |
| 리소스 사용 | 적음 | 많음 |
| 복잡도 | 약간 설정 필요 | 구현은 단순하지만 비효율 |
웹훅은 설정만 해두면 자동으로 알림을 받을 수 있기 때문에,
불필요한 요청을 줄이면서도 실시간성을 확보할 수 있습니다.
웹훅은 간단해 보이지만, 실제 서비스에 적용하려면 몇 가지 중요한 요소들을 신경 써야 해요.
외부에서 우리 서버로 요청이 들어오는 구조이기 때문에,
"이게 진짜 믿을 수 있는 요청인지"를 검증하는 로직이 필요합니다.
웹훅을 보낸 시스템은 빠른 응답(예: 200 OK)을 기대합니다.
처리 시간이 오래 걸리면 타임아웃 → 재시도로 이어질 수 있어요.
→ 그래서 대부분 웹훅 수신 후에는 빠르게 OK 응답을 보내고,
실제 처리는 큐나 쓰레드로 비동기 처리합니다.
네트워크 문제로 같은 웹훅이 여러 번 올 수도 있어요.
중복 처리를 방지하려면, 이벤트 ID로 중복 여부를 판단해야 합니다.
웹훅 요청은 나중에 되짚기 어렵기 때문에
성공/실패 로그와 재전송 이력을 남기는 게 중요합니다.
| 서비스 | 제공 기능 |
|---|---|
| GitHub | 푸시, PR, 이슈 등 이벤트 트리거 |
| Stripe | 결제 완료/실패 등 |
| Slack | 메시지 전송용 Incoming Webhook |
| Notion | 페이지 생성/수정 이벤트 알림 |
| Discord | 채널 알림 전송 |
| Google Form | 응답 알림 |
개발 중에는 로컬 서버를 외부에서 호출할 수 없기 때문에,
ngrok이나 localtunnel을 이용해 테스트하면 편리합니다.
ngrok http 8080
이 명령어 하나로 http://xxxx.ngrok.io 주소가 만들어지고,
이 주소를 웹훅 수신용 URL로 등록하면 외부 서비스가 로컬 서버로 직접 요청을 보낼 수 있어요!
웹훅은 시스템 간 실시간 연동을 위해 매우 유용한 도구입니다.
간단한 구조로 시작할 수 있지만, 운영 관점에서는 보안, 실패 대응, 멱등성 등 여러 요소들을 함께 고려해야 안정적으로 서비스에 녹일 수 있어요.
정리된 개념을 바탕으로, 다음 글에서는 직접 웹훅을 구현하거나 활용하는 실습도 다뤄보겠습니다.
읽어주셔서 감사합니다!