> "웹훅은 가장 단순한 비동기 통합 방식이지만, 가장 자주 깨지는 통합 방식이기도 하다. 2026년에는 더 이상 raw POST를 직접 구현할 이유가 없다." — Standard Webhooks Working Group, 2024

웹훅(Webhook)은 2007년 Jeff Lindsay가 처음 정의한 이래 거의 20년간 거의 변하지 않은 패턴이지만, 그 운영(Operational) 표면적은 폭발적으로 커졌습니다. Stripe, Twilio, Shopify, GitHub, Slack 같은 SaaS 한 곳만 연동해도 하루 수십만~수백만 건의 POST 요청이 우리 인프라에 쏟아지고, 거꾸로 우리 서비스에서 외부로 내보내는 이벤트도 같은 규모로 늘어났습니다.

2026년 5월 현재, 웹훅 인프라는 단순한 "HTTP POST 받기"가 아니라 **게이트웨이(Gateway), 신뢰성(Reliability), 터널(Tunnel), 디버깅(Debugger), 클라우드 네이티브 이벤트 버스(Cloud-native Event Bus)** 다섯 카테고리로 분화된 거대한 생태계입니다. 이 글에서는 Svix, Hookdeck, ngrok, smee.io, Sequin, Convoy, Webhook.site, RequestBin, Beeceptor, AWS EventBridge, GCP Eventarc, Azure Event Grid, Inngest, 그리고 Standard Webhooks 표준까지 한 번에 정리합니다.

1. 2026년 웹훅 인프라 지도 — Gateway / Reliability / Tunnel / Cloud-Native

웹훅 인프라는 역할에 따라 다섯 개의 큰 박스로 나눌 수 있습니다.

| 카테고리 | 대표 제품 | 역할 |

|---|---|---|

| Gateway (보내는 쪽) | Svix, Hookdeck Connect, Convoy, AWS EventBridge Pipes | 우리 서비스에서 고객에게 이벤트를 보낼 때, 큐·재시도·서명·대시보드를 제공 |

| Reliability (받는 쪽) | Hookdeck, Inngest, Convoy, Tinybird Events | 외부에서 들어오는 웹훅을 큐잉·필터링·재시도·변환 |

| Tunnel (개발) | ngrok, Cloudflare Tunnel, Tailscale Funnel, smee.io | 로컬 머신을 인터넷에 노출해 개발/테스트 |

| Debugger | Webhook.site, RequestBin, Beeceptor, Diagnostic | URL만 받아 들어오는 페이로드를 가시화 |

| Cloud-native Event Bus | AWS EventBridge, GCP Eventarc, Azure Event Grid | 클라우드 내부/외부 이벤트 라우팅과 SaaS 통합 |

**보내는 쪽(Producer)** 과 **받는 쪽(Consumer)** 은 요구사항이 완전히 다릅니다. Producer는 "내가 보낸 이벤트가 고객에게 도달했는가, 도달하지 못했다면 몇 번 재시도했는가"가 중요하고, Consumer는 "외부에서 무작위로 쏟아지는 트래픽을 우리 코어 시스템과 분리(Buffer)할 수 있는가"가 중요합니다. Hookdeck처럼 양쪽을 모두 다루는 제품도 있고, Svix처럼 Producer에 집중하는 제품도 있습니다.

웹훅 인프라 선택의 첫 번째 분기점은 항상 "내가 보내는 쪽인가 받는 쪽인가, 둘 다인가"입니다. 이 글 전체를 관통하는 핵심 질문이기도 합니다.

2. 웹훅 표준 — Standard Webhooks (2023.4)와 그 영향

웹훅이 20년 동안 표준화되지 않은 채로 자라난 결과, 각 SaaS는 서로 다른 서명 헤더 이름, 다른 페이로드 포맷, 다른 재시도 정책을 가집니다. Stripe는 `Stripe-Signature`, GitHub는 `X-Hub-Signature-256`, Shopify는 `X-Shopify-Hmac-Sha256`, Slack은 `X-Slack-Signature` — 통합 한 건당 새로운 SDK를 학습해야 했습니다.

2023년 4월 Svix가 주도하고 Zapier, Twilio, Lob, Ngrok, Vercel, Supabase 등이 합류한 **Standard Webhooks** 이니셔티브가 이 혼란을 표준화하기 위해 출범했습니다. 핵심 규약은 다음과 같습니다.

- **공통 헤더 3종**: `webhook-id`, `webhook-timestamp`, `webhook-signature`

- **서명 방식**: HMAC-SHA256, base64 인코딩, `v1,` 접두사

- **타임스탬프 검증**: 기본 허용 윈도 5분 (재전송 공격 방지)

- **페이로드 포맷**: JSON, `type` + `data` 구조 권장

- **재시도 정책 권고**: 지수 백오프 (5초, 5분, 30분, 2시간, 5시간, 10시간, 16시간) — 약 24시간 후 포기

- **이벤트 ID**: 멱등성 키로 사용 가능한 고유 ID

2024년부터 Vercel, Supabase, Resend, Linear, Cal.com 같은 모던 SaaS는 처음부터 Standard Webhooks 호환으로 출시했고, 2025년에는 Stripe도 새로운 `v2` Event API에서 부분적으로 채택했습니다. 2026년 현재 표준 헤더(`webhook-id`, `webhook-timestamp`, `webhook-signature`)를 지원하는 SaaS는 100개를 넘었습니다.

표준화가 가져온 가장 큰 가치는 **검증 SDK의 공통화**입니다. `standardwebhooks` 패키지 하나로 모든 호환 SaaS의 서명을 검증할 수 있고, 새로운 통합을 추가할 때마다 새 SDK를 익힐 필요가 없습니다.

3. 서명 검증 — HMAC-SHA256, timing-safe compare

웹훅 보안의 핵심은 "이 요청이 진짜 그 SaaS에서 왔는가"를 검증하는 것입니다. 거의 모든 SaaS는 **HMAC-SHA256** 기반 서명을 사용합니다. 표준 흐름은 다음과 같습니다.

1. SaaS와 우리 서비스가 공유 비밀(`signing secret`)을 가짐

2. SaaS는 요청 페이로드와 타임스탬프를 결합해 HMAC-SHA256으로 서명

3. 헤더에 서명을 담아 전송

4. 우리 서비스는 같은 키로 같은 입력을 서명해 비교

5. **반드시 timing-safe compare** 로 비교 (타이밍 공격 방지)

Node.js에서 Standard Webhooks 호환 검증을 직접 구현하면 다음과 같습니다.

export function verifyStandardWebhook(opts: {

payload: string // raw body, JSON.stringify가 아닌 byte-exact 원본

headers: Record<string, string>

secret: string // 'whsec_xxx' 형태의 base64 인코딩된 키

toleranceSeconds?: number

}): boolean {

const { payload, headers, secret, toleranceSeconds = 300 } = opts

const id = headers['webhook-id']

const timestamp = headers['webhook-timestamp']

const signature = headers['webhook-signature']

if (!id || !timestamp || !signature) return false

// 1) 타임스탬프 윈도 검증 (재전송 공격 방지)

const ts = parseInt(timestamp, 10)

const now = Math.floor(Date.now() / 1000)

if (Math.abs(now - ts) > toleranceSeconds) return false

// 2) signed content 조립 — "id.timestamp.payload"

const signedContent = `${id}.${timestamp}.${payload}`

// 3) base64 secret을 raw bytes로 디코딩

const secretBytes = Buffer.from(secret.replace(/^whsec_/, ''), 'base64')

// 4) HMAC-SHA256 계산

const expected = createHmac('sha256', secretBytes)

.update(signedContent)

.digest('base64')

// 5) 헤더에는 "v1,sig1 v1,sig2" 형태로 여러 서명이 올 수 있음 (롤링 키 대응)

const sigs = signature.split(' ').map((s) => s.split(',')[1]).filter(Boolean)

// 6) timing-safe compare — 절대 === 쓰지 말 것

return sigs.some((sig) => {

const sigBytes = Buffer.from(sig, 'base64')

const expBytes = Buffer.from(expected, 'base64')

if (sigBytes.length !== expBytes.length) return false

return timingSafeEqual(sigBytes, expBytes)

})

}

세 가지 함정이 있습니다.

**페이로드는 raw bytes로 받아야 합니다.** Express의 `body-parser`나 Next.js Route Handler가 자동으로 JSON.parse한 객체를 다시 `JSON.stringify`하면 공백·키 순서가 달라져 서명이 깨집니다. Next.js App Router에서는 `await req.text()`로, Express에서는 `bodyParser.raw({ type: '*/*' })`로 원본을 받아야 합니다.

**타임스탬프 윈도 검증을 빼먹지 마세요.** 서명만 검증하면 공격자가 한 번 가로챈 유효 요청을 영원히 재전송할 수 있습니다. Standard Webhooks는 5분, Stripe는 5분, Slack은 5분이 기본값입니다.

**timing-safe compare를 반드시 사용하세요.** `===`나 `Buffer.compare`는 첫 다른 바이트에서 즉시 false를 반환하므로 타이밍 차이로 한 바이트씩 서명을 알아낼 수 있습니다. Node.js는 `crypto.timingSafeEqual`, Python은 `hmac.compare_digest`, Go는 `subtle.ConstantTimeCompare`를 제공합니다.

4. 멱등성 + 재시도 + 지수 백오프 패턴

웹훅의 두 번째 어려움은 "받는 쪽이 같은 이벤트를 두 번 받았을 때 무슨 일이 일어나는가"입니다. SaaS는 200을 받기 전까지 재시도하기 때문에, 우리 핸들러가 타임아웃되거나 잠시 죽으면 같은 이벤트가 여러 번 도착합니다.

**멱등성(Idempotency)** 의 핵심 패턴은 이벤트 ID를 키로 한 중복 처리 방지 테이블입니다.

// 멱등성 처리 예시 — Postgres + Redis 조합

export async function handleWebhookIdempotent(event: {

id: string // SaaS가 보낸 고유 ID (webhook-id 헤더 또는 페이로드 내 id)

type: string

data: unknown

}) {

// 1) Redis로 빠른 lock (TTL 60초) — 동시 도착 방지

const lockKey = `webhook:lock:${event.id}`

const acquired = await redis.set(lockKey, '1', 'NX', 'EX', 60)

if (!acquired) {

// 다른 워커가 처리 중 — 200 반환해서 SaaS의 재시도 큐 비우기

return { status: 'in-flight' }

}

try {

// 2) Postgres에 영구 처리 기록 (UNIQUE constraint로 중복 방지)

const inserted = await db.query(

`INSERT INTO processed_webhooks (event_id, event_type, received_at)

VALUES ($1, $2, NOW())

ON CONFLICT (event_id) DO NOTHING

RETURNING event_id`,

[event.id, event.type]

)

if (inserted.rowCount === 0) {

// 이미 처리된 이벤트 — 200 반환

return { status: 'duplicate' }

}

// 3) 실제 비즈니스 로직 실행

await processBusinessLogic(event)

return { status: 'processed' }

} finally {

await redis.del(lockKey)

}

}

보내는 쪽의 재시도 정책은 **지수 백오프 + 지터(Jitter)** 가 표준입니다. Standard Webhooks 권고는 다음과 같습니다.

| 시도 | 대기 시간 | 누적 |

|---|---|---|

| 1 | 즉시 | 0초 |

| 2 | 5초 | 5초 |

| 3 | 5분 | 5분 5초 |

| 4 | 30분 | 35분 |

| 5 | 2시간 | 2시간 35분 |

| 6 | 5시간 | 7시간 35분 |

| 7 | 10시간 | 17시간 35분 |

| 8 | 16시간 | 33시간 35분 → 포기 |

지터를 더하면 ±10~25% 정도 랜덤 변동을 줘서 thundering herd를 방지합니다.

수신 측이 "지금은 받을 수 없다"고 알리는 방법은 두 가지입니다. **429 Too Many Requests** 와 함께 `Retry-After` 헤더를 보내면 좋은 SaaS는 그 시간만큼 기다립니다. **5xx** 를 반환하면 자동 백오프 큐에 들어갑니다. **4xx (400, 401, 422)** 를 반환하면 영구 실패로 분류되어 재시도하지 않으므로, 일시적 문제일 때는 절대 4xx를 쓰지 마세요.

5. Svix — 오픈소스 웹훅 게이트웨이

Svix(`svix.com`)는 2021년 창업, 2023년 시리즈 A를 받은 웹훅 인프라 회사로, 가장 잘 알려진 오픈소스 웹훅 게이트웨이를 운영합니다. Lob, Brex, Clerk, Lightspeed, Benchling, Resend 등이 Svix 위에서 자사 웹훅을 운영합니다.

핵심 가치 제안은 "Stripe 수준의 웹훅 시스템을 1주가 아니라 1일 만에 만들 수 있다"입니다. 자체 구축 시 필요한 것들 — 큐, 재시도, 지수 백오프, 서명, 멱등성, 회로 차단기, 대시보드, 로그 보관, replay UI, OpenAPI 스키마 등 — 을 SDK 한 줄로 대체합니다.

// Svix로 고객에게 이벤트 보내기

const svix = new Svix(process.env.SVIX_AUTH_TOKEN!)

// 1) 고객 애플리케이션 생성 (한 번만)

const app = await svix.application.create({

name: 'Acme Corp',

uid: 'cust_acme_001',

})

// 2) 고객이 자신의 엔드포인트 등록 (대시보드 또는 API)

await svix.endpoint.create(app.id, {

url: 'https://acme.com/webhooks',

description: 'Production endpoint',

})

// 3) 이벤트 발송 — Svix가 큐, 재시도, 서명을 처리

await svix.message.create(app.id, {

eventType: 'invoice.paid',

eventId: `evt_${invoice.id}`, // 멱등성 키

payload: {

invoice_id: invoice.id,

amount: invoice.amount,

customer: invoice.customer_id,

},

})

Svix의 오픈소스 버전(`github.com/svix/svix-webhooks`)은 Rust로 작성된 서버, PostgreSQL, Redis, RabbitMQ를 자체 호스팅할 수 있습니다. 클라우드 버전은 월 5,000건까지 무료, 그 이상은 메시지당 과금입니다.

2025년 11월에는 React, Vue용 임베디드 대시보드 위젯(`@svix/react`)이 정식 출시되어, 고객이 우리 앱 안에서 자신의 엔드포인트를 등록·테스트·로그 확인을 할 수 있게 되었습니다. 이는 자체 빌드 시 가장 시간이 많이 드는 부분이라 큰 차별점입니다.

6. Hookdeck — 웹훅 신뢰성 플랫폼

Hookdeck(`hookdeck.com`)은 캐나다 몬트리올 기반으로 2021년 창업, 2024년 시리즈 A를 받았습니다. Svix가 "보내는 쪽" 중심이라면 Hookdeck은 "받는 쪽 + 양방향" 중심입니다.

핵심 시나리오는 **인바운드 웹훅의 신뢰성 보장**입니다. Stripe, Shopify, GitHub 같은 외부 SaaS의 웹훅 URL을 `https://hkdk.events/xxx`로 등록해놓으면, Hookdeck이 그것을 받아 우리 백엔드로 전달합니다. 우리 백엔드가 죽어 있어도 Hookdeck이 버퍼링·재시도하고, 우리는 Hookdeck 대시보드에서 실패한 이벤트를 한 번에 replay할 수 있습니다.

Hookdeck CLI로 로컬 개발 환경에 웹훅 포워딩

hookdeck listen 3000 stripe --path /api/webhooks/stripe

출력 예시:

Inbound URL: https://hkdk.events/abcd1234

Forwarding to: http://localhost:3000/api/webhooks/stripe

Connection: stripe-local

이 한 줄로 ngrok 없이도 로컬 환경에 외부 웹훅을 받을 수 있고, 동시에 모든 요청이 Hookdeck 대시보드에 로그로 남습니다. 같은 명령으로 production URL로도 포워딩할 수 있어, 로컬-스테이징-프로덕션 동일한 게이트웨이를 사용할 수 있습니다.

2025년에 출시된 Hookdeck Connect는 Svix와 정면 경쟁하는 outbound 웹훅 플랫폼으로, 같은 대시보드에서 양방향을 통합 관리할 수 있습니다.

Hookdeck의 차별점은 **Filtering & Transformation**입니다. 들어오는 페이로드를 JavaScript 함수로 변환하거나, 특정 이벤트 타입만 필터링해 백엔드로 전달할 수 있습니다.

// Hookdeck Transformation 예시

addHandler('transform', (request, context) => {

// Stripe charge.succeeded 이벤트만 통과

if (request.body.type !== 'charge.succeeded') {

return null // drop

}

// 페이로드 단순화

return {

...request,

body: {

charge_id: request.body.data.object.id,

amount: request.body.data.object.amount,

customer: request.body.data.object.customer,

},

}

})

7. ngrok / Cloudflare Tunnel — 로컬 터널링

웹훅 개발의 영원한 숙제는 "로컬 머신에 어떻게 외부 트래픽을 받을까"입니다. ngrok(`ngrok.com`)은 2013년 출시 이후 사실상 표준이 되었습니다.

2024년 ngrok은 브랜드를 **Ngrok Edge**로 리네이밍하면서, 단순 터널을 넘어 API Gateway·OAuth·Mutual TLS·Rate Limiting을 제공하는 풀스택 ingress 플랫폼으로 진화했습니다.

기본 사용 — 로컬 3000 포트를 인터넷에 노출

ngrok http 3000

고정 도메인 (유료 플랜)

ngrok http 3000 --domain=acme-dev.ngrok.app

인증·헤더 추가 게이트웨이로 사용

ngrok http 3000 \

--domain=api-dev.acme.dev \

--oauth=google \

--oauth-allow-domain=acme.com

YAML 설정 파일

~/.ngrok2/ngrok.yml

tunnels:

webhook-dev:

proto: http

addr: 3000

domain: webhooks-dev.acme.dev

request_header_add:

- "X-Forwarded-Source: ngrok-dev"

ngrok의 대안으로 부상한 것이 **Cloudflare Tunnel**(구 Argo Tunnel)입니다. Cloudflare 계정만 있으면 무료로 영구 도메인을 받을 수 있고, Cloudflare의 글로벌 네트워크를 통과해 DDoS·WAF가 자동 적용됩니다.

Cloudflare Tunnel 설치 후 한 번 인증

cloudflared tunnel login

터널 생성

cloudflared tunnel create my-dev-tunnel

라우팅 (acme.com이 Cloudflare DNS여야 함)

cloudflared tunnel route dns my-dev-tunnel webhook-dev.acme.com

로컬 서비스로 포워딩

cloudflared tunnel run --url http://localhost:3000 my-dev-tunnel

**Tailscale Funnel**은 2023년 GA된 또 다른 대안으로, 기존 Tailnet에 속한 노드를 인터넷에 노출할 수 있습니다. 팀 내부에서 이미 Tailscale을 쓰고 있다면 별도 계정 없이 바로 활용할 수 있는 장점이 있습니다.

선택 기준은 다음과 같습니다. **빠른 일회성 테스트** 는 ngrok 무료 플랜, **팀 공용 영구 개발 URL** 은 Cloudflare Tunnel(무료), **엔터프라이즈 OAuth/Mutual TLS** 는 ngrok Edge 유료 플랜, **이미 Tailscale을 쓰는 팀**은 Funnel.

8. smee.io (GitHub) — 무료 개발 forwarding

GitHub이 운영하는 무료 서비스인 smee.io(`smee.io`)는 ngrok과 비슷하지만 더 단순합니다. 페이지에서 "Start a new channel" 한 번 누르면 영구 URL이 생기고, 그 URL로 들어오는 요청을 SSE(Server-Sent Events)로 받아 로컬 서버로 포워딩합니다.

smee CLI 설치

npm install -g smee-client

포워딩 시작

smee --url https://smee.io/abcd1234 --path /webhooks/github --port 3000

또는 코드에서

import SmeeClient from 'smee-client'

const smee = new SmeeClient({

source: 'https://smee.io/abcd1234',

target: 'http://localhost:3000/webhooks/github',

logger: console,

})

smee.start()

smee의 강점은 **무료, 무한정, 가입 불필요**입니다. 약점은 SLA가 없고, 트래픽이 폭주하면 GitHub이 막을 수 있으며, 인증·필터링 기능이 없다는 것. GitHub Apps 개발용 공식 가이드에 등장하는 도구이기 때문에, GitHub Webhook 학습용으로는 가장 마찰이 적은 선택입니다.

2025년에는 smee.io에 Web UI 페이로드 미리보기가 추가되어, 브라우저에서 채널 URL을 열어두면 들어오는 요청을 실시간 JSON으로 볼 수 있게 되었습니다.

9. Sequin — Postgres → 웹훅/Kafka

Sequin(`sequin.io`)은 2022년 창업, 2024년 Andreessen Horowitz로부터 시리즈 A를 받은 회사입니다. Sequin의 차별점은 **Postgres의 변경(Change)을 웹훅·Kafka·SQS로 스트리밍**한다는 것입니다. CDC(Change Data Capture) 카테고리지만, 출구로 웹훅을 1급으로 지원합니다.

전형적인 시나리오는 이렇습니다. 우리 백엔드에 외부 통합용 코드를 작성할 시간이 없을 때, Sequin이 Postgres 트랜잭션 로그(WAL)를 읽고 INSERT/UPDATE/DELETE를 자동으로 외부 HTTP 엔드포인트로 보내줍니다.

sequin.yaml — Postgres 테이블 -> 웹훅

sources:

- name: orders-pg

type: postgres

url: postgresql://user:pass@db.acme.com:5432/app

publication: sequin_pub

slot: sequin_slot

destinations:

- name: warehouse-webhook

type: webhook

url: https://warehouse.acme.com/api/orders

headers:

authorization: Bearer ${WAREHOUSE_TOKEN}

retry:

max_attempts: 8

backoff: exponential

streams:

- name: orders-to-warehouse

source: orders-pg

destination: warehouse-webhook

tables:

- name: orders

actions: [insert, update]

filter: "status IN ('paid', 'shipped')"

Sequin의 장점은 **애플리케이션 코드 변경 없이** DB 변경을 외부에 전파한다는 것입니다. 단점은 Postgres WAL을 정확히 이해해야 하고, 스키마 변경 시 슬롯 관리에 주의해야 한다는 것. 2025년 기준 Sequin은 Stripe, Linear, Notion 같은 SaaS 통합도 기본 제공해서, "Stripe 신규 customer가 생기면 우리 DB에 INSERT" 같은 양방향 동기화도 가능합니다.

비슷한 카테고리에는 **Debezium**(오픈소스, JVM 기반), **Fivetran HVR**, **Airbyte**가 있지만, 웹훅 출력을 1급으로 지원하는 것은 Sequin이 가장 깔끔합니다.

10. Convoy — 오픈소스 delivery

Convoy(`getconvoy.io`, `github.com/frain-dev/convoy`)는 나이지리아 라고스 기반의 오픈소스 웹훅 게이트웨이입니다. Go로 작성되었고 MIT 라이선스이며, Svix 클라우드와 정면 경쟁하는 self-hosted 옵션입니다.

Docker Compose로 Convoy 띄우기

git clone https://github.com/frain-dev/convoy

cd convoy

docker compose -f deploy/docker-compose.yml up -d

기본 포트 5005에 대시보드, 5004에 API

open http://localhost:5005

Convoy의 데이터 플로우는 Svix와 거의 같습니다. Project, Endpoint, Event, Subscription의 4개 핵심 객체가 있고, REST API로 이벤트를 푸시하면 Convoy가 큐(Redis)로 받아 워커가 외부 endpoint로 전달합니다.

Convoy CLI로 이벤트 발송

curl -X POST http://localhost:5004/api/v1/projects/{project_id}/events \

-H "Authorization: Bearer CONVOY_API_KEY" \

-H "Content-Type: application/json" \

-d '{

"endpoint_id": "endpoint_abc",

"event_type": "user.created",

"data": {

"user_id": "u_123",

"email": "alice@example.com"

}

}'

Convoy는 **Filter Expressions** 라는 SQL 유사 문법으로 라우팅 규칙을 쓸 수 있는 것이 특징입니다. `data.amount > 1000 AND data.currency == 'USD'` 같은 조건으로 endpoint별로 다른 이벤트만 받게 할 수 있습니다.

자체 호스팅 비용 부담 없이 시작하고 싶다면 Convoy Cloud도 있으나, Svix·Hookdeck에 비하면 시장 점유율은 작습니다. 자체 호스팅이 필수인 환경(금융권, 헬스케어, GovCloud 등)에서 검토할 만한 선택지입니다.

11. Webhook.site / RequestBin / Beeceptor — 디버깅 도구

웹훅을 처음 통합할 때 가장 먼저 필요한 것은 "내가 진짜로 무엇을 받고 있는가"입니다. 페이로드 구조, 헤더 이름, 인코딩을 눈으로 봐야 합니다.

**Webhook.site**(`webhook.site`)는 가장 인기 있는 무료 도구입니다. 페이지를 열면 즉시 고유 URL이 생기고, 그 URL로 들어오는 모든 요청이 실시간으로 표시됩니다. 페이로드, 헤더, 쿼리, 메서드, 응답 시간 모두 한 화면에서 확인 가능. 무료 플랜은 100건/일, Premium은 무제한 + 영구 보존 + 커스텀 응답 + JavaScript로 응답 조작이 가능합니다.

테스트

curl -X POST https://webhook.site/abcd1234 \

-H "Content-Type: application/json" \

-d '{"hello": "world"}'

브라우저에서 https://webhook.site/#!/abcd1234 열면 실시간으로 확인

**RequestBin**(`requestbin.com`)은 Pipedream이 인수한 후 유료화되었으나, 오픈소스 버전(`github.com/Runscope/requestbin`)을 자체 호스팅할 수 있습니다.

**Beeceptor**(`beeceptor.com`)는 단순 디버깅을 넘어 **Mock API 서버**를 만드는 데 특화된 도구입니다. 들어오는 요청에 조건부 응답을 정의할 수 있어, 외부 API를 흉내내는 가짜 서버를 5분 안에 만들 수 있습니다. 통합 테스트 환경에서 외부 SaaS가 다운된 상황을 시뮬레이션할 때 유용합니다.

// Beeceptor의 응답 규칙 예시 (JS expression)

// 조건: request.body.action === "create"

// 응답: 201 + JSON

{

"id": "{{$randomUUID}}",

"created_at": "{{$timestamp}}",

"echo": "{{request.body}}"

}

**Diagnostic**(`diagnostic.dev`)은 2024년 출시된 신규 도구로, 단순 인박스가 아니라 **사용한 SaaS별 페이로드 스키마를 자동 추론**해서 OpenAPI 스펙을 생성해줍니다. Webhook.site에서 며칠 동안 받은 페이로드를 분석해 "이 SaaS의 `invoice.paid` 이벤트는 평균 12개 필드를 보내고, 그 중 3개가 옵셔널"이라는 식의 통계를 보여줍니다.

세 도구의 사용 분기점은 명확합니다. **빠른 일회성 디버깅**은 Webhook.site, **Mock API**는 Beeceptor, **장기 페이로드 분석**은 Diagnostic.

12. AWS EventBridge / Google Eventarc / Azure Event Grid — 클라우드 네이티브

클라우드 사업자들도 자사 생태계용 이벤트 라우터를 제공합니다. 이들은 단순 웹훅을 넘어 **서비스 간 이벤트 버스**의 역할을 합니다.

**AWS EventBridge**는 2019년 GA된 서비스로, AWS 내부 이벤트(S3 PUT, EC2 상태 변경 등)와 외부 SaaS(Stripe, Datadog, Shopify, GitHub 등 100+ 파트너) 이벤트를 한 곳에서 라우팅합니다.

EventBridge 규칙 — Stripe 결제 성공 이벤트가 오면 Lambda 호출

aws events put-rule \

--name stripe-payment-success \

--event-pattern '{

"source": ["aws.partner/stripe.com"],

"detail-type": ["charge.succeeded"]

}'

aws events put-targets \

--rule stripe-payment-success \

--targets 'Id=1,Arn=arn:aws:lambda:us-east-1:123:function:processPayment'

EventBridge의 핵심은 **EventBridge Pipes**(2022년 GA)와 **Schema Registry**입니다. Pipes는 source → filter → enrich → target의 파이프라인을 GUI로 구성하고, Schema Registry는 들어오는 이벤트 스키마를 자동 등록·버전 관리합니다.

**Google Eventarc**는 GCP 버전입니다. Cloud Run, Cloud Functions, Workflows를 이벤트 트리거로 호출하며, Google Cloud의 70+ 서비스(GCS, BigQuery, Pub/Sub, Cloud Build 등)를 source로 지원합니다. AWS EventBridge보다 외부 SaaS 통합 폭은 좁지만, CloudEvents v1.0 표준을 1급으로 지원합니다.

Eventarc 트리거 — GCS 객체 생성 시 Cloud Run 호출

gcloud eventarc triggers create gcs-upload-trigger \

--location=us-central1 \

--destination-run-service=process-upload \

--destination-run-region=us-central1 \

--event-filters="type=google.cloud.storage.object.v1.finalized" \

--event-filters="bucket=acme-uploads" \

--service-account=eventarc@my-project.iam.gserviceaccount.com

**Azure Event Grid**는 Microsoft의 옵션입니다. Azure 서비스(Blob Storage, IoT Hub, Service Bus 등) 이벤트와 SaaS 이벤트를 라우팅하며, **MQTT v5** 브로커 기능까지 통합되어 IoT 시나리오에 강합니다. 2024년 GA된 Event Grid Namespaces는 pub/sub과 webhook delivery를 한 리소스에서 처리합니다.

클라우드 네이티브 이벤트 버스 선택의 핵심은 **이미 어느 클라우드를 쓰는가**입니다. AWS면 EventBridge, GCP면 Eventarc, Azure면 Event Grid. 멀티 클라우드면 Hookdeck·Svix처럼 클라우드 중립 SaaS가 합리적입니다.

13. Inngest의 웹훅 통합

Inngest(`inngest.com`)는 2022년 창업한 이벤트 기반 워크플로 플랫폼으로, 2024년 시리즈 B를 받았습니다. 핵심 가치는 "큐, 크론, 워크플로, 웹훅을 한 SDK에서"입니다.

Inngest는 본래 자체 이벤트 시스템이지만, 2024년부터 **Webhook Source**가 1급 시민이 되었습니다. Stripe·GitHub·Shopify URL을 Inngest 대시보드에 등록하면, Inngest가 인박스 역할을 하면서 들어온 이벤트를 자동으로 Inngest 이벤트로 변환합니다.

// Inngest 함수 — Stripe webhook을 받아 자동 처리

export const handleStripePayment = inngest.createFunction(

{

id: 'handle-stripe-payment',

retries: 5,

idempotency: 'event.data.id', // Stripe event ID로 멱등성 보장

},

{ event: 'stripe/charge.succeeded' }, // Inngest가 자동 라우팅

async ({ event, step }) => {

// step.run으로 감싸면 자동 재시도 + 결과 캐싱

const customer = await step.run('fetch-customer', async () =>

db.customer.findUnique({ where: { stripeId: event.data.customer } })

)

await step.run('send-receipt', async () =>

mailer.sendReceipt(customer.email, event.data)

)

// step.sleep으로 대기 — 함수 일시 중단, 비용 0

await step.sleep('wait-1h', '1h')

await step.run('send-followup', async () =>

mailer.sendFollowup(customer.email)

)

}

)

Inngest의 매력은 **웹훅 + 큐 + 워크플로 + 크론** 을 한 SDK로 통합한다는 것입니다. Hookdeck이 신뢰성 레이어에 집중한다면, Inngest는 그 위에 비즈니스 로직 오케스트레이션까지 얹습니다.

비슷한 카테고리에는 **Trigger.dev**, **Defer**, **Temporal Cloud**가 있고, AWS Step Functions + EventBridge 조합이 클라우드 네이티브 대안입니다.

14. 한국 / 일본 사례 — 토스, Mercari, SmartHR

**한국 — 토스(Toss)**: 토스페이먼츠는 가맹점에게 **결제 승인/취소/환불 웹훅** 을 제공하며, 자체 구축한 게이트웨이를 사용합니다. 2025년 토스페이먼츠 기술 블로그에서 공개한 내용에 따르면, 일 평균 수억 건의 웹훅을 처리하기 위해 Kafka 기반 자체 큐, 워커 풀, Redis 기반 멱등성 캐시, MongoDB 기반 영구 로그 구조를 사용합니다. 서명은 RSA-SHA256(공개키 검증) + HMAC 이중 구조이며, 가맹점이 대시보드에서 직접 실패 이벤트를 replay할 수 있습니다.

토스의 특이점은 **금융 규제 대응 로깅**입니다. 모든 웹훅 송신/수신 로그를 5년간 보관해야 하고, 외부 감사 대응 시 특정 거래 ID로 페이로드·서명·재시도 이력을 1초 안에 검색할 수 있어야 합니다. 이는 Svix·Hookdeck 같은 외부 SaaS로 풀기 어려운 요구사항이고, 토스가 자체 구축을 택한 이유이기도 합니다.

**일본 — Mercari**: Mercari는 마이크로서비스 간 비동기 통합에 **Cloud Pub/Sub + Cloud Run + Eventarc** 조합을 사용합니다. 2024년 Mercari 엔지니어링 블로그에서 공개한 내용에 따르면, 결제·재고·배송 도메인 간 이벤트 흐름을 모두 Pub/Sub topic으로 추상화하고, 외부 SaaS 연동(SendGrid, Stripe Connect 등)은 Eventarc trigger로 receive합니다. 내부 서비스가 외부 webhook을 직접 받지 않고 항상 Eventarc/Pub/Sub을 거치는 것이 핵심 원칙입니다.

**일본 — SmartHR**: HR SaaS인 SmartHR는 자사 고객(인사담당자)에게 **사원 정보 변경 웹훅** 을 제공합니다. 2025년 SmartHR Tech Blog에서 공개된 아키텍처는 Rails + Sidekiq 기반 자체 구축이며, 재시도는 Sidekiq의 지수 백오프(최대 25회, 약 21일), 서명은 HMAC-SHA256, 페이로드 포맷은 자체 정의했습니다. 특이점은 **고객이 등록한 endpoint URL의 신뢰성 점수(Health Score)** 를 계산해, 점수가 낮은 endpoint는 자동으로 회로 차단기를 가동하고 고객에게 이메일 알림을 보낸다는 점입니다.

세 사례의 공통점은 **자체 구축 + 운영 자동화**입니다. 일정 규모를 넘은 SaaS는 외부 게이트웨이를 쓰는 비용이 자체 구축 비용을 초과하기 시작합니다. 다만 자체 구축은 6~12개월의 엔지니어링 투자가 필요하므로, 시리즈 A 이전 단계 SaaS는 Svix·Hookdeck로 시작해 PMF 검증 후 자체 구축으로 옮기는 것이 일반적인 경로입니다.

15. 참고 / References

- Standard Webhooks specification — `https://www.standardwebhooks.com/`

- Standard Webhooks GitHub — `https://github.com/standard-webhooks/standard-webhooks`

- Svix documentation — `https://docs.svix.com/`

- Svix open source — `https://github.com/svix/svix-webhooks`

- Hookdeck documentation — `https://hookdeck.com/docs`

- Hookdeck CLI — `https://github.com/hookdeck/hookdeck-cli`

- Convoy open source — `https://github.com/frain-dev/convoy`

- Convoy documentation — `https://docs.getconvoy.io/`

- ngrok documentation — `https://ngrok.com/docs`

- Cloudflare Tunnel — `https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/`

- Tailscale Funnel — `https://tailscale.com/kb/1223/funnel`

- smee.io — `https://smee.io/`

- Sequin — `https://sequin.io/`

- Webhook.site — `https://webhook.site/`

- Beeceptor — `https://beeceptor.com/`

- RequestBin (Pipedream) — `https://pipedream.com/requestbin`

- AWS EventBridge — `https://docs.aws.amazon.com/eventbridge/`

- AWS EventBridge Pipes — `https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html`

- Google Eventarc — `https://cloud.google.com/eventarc/docs`

- Azure Event Grid — `https://learn.microsoft.com/en-us/azure/event-grid/`

- Inngest webhooks — `https://www.inngest.com/docs/platform/webhooks`

- Stripe webhook signatures — `https://docs.stripe.com/webhooks/signatures`

- GitHub webhook deliveries — `https://docs.github.com/en/webhooks`

- Slack request signing — `https://api.slack.com/authentication/verifying-requests-from-slack`

- 토스페이먼츠 개발자센터 — `https://docs.tosspayments.com/`

- Mercari Engineering Blog — `https://engineering.mercari.com/en/blog/`

- SmartHR Tech Blog — `https://tech.smarthr.jp/`

- CloudEvents specification — `https://cloudevents.io/`

- OWASP Webhook Security Cheat Sheet — `https://cheatsheetseries.owasp.org/cheatsheets/Webhook_Security_Cheat_Sheet.html`