웹훅이 API를 뒤집다: 묻는 대신, 일이 생기면 앱이 호출받는다

2007년 웹사이트에는 API가 있었지만, 통합은 여전히 폴링을 뜻했다. 한 애플리케이션이 다른 애플리케이션의 문을 몇 번이고 두드리며 새로운 일이 있었는지 물었다. 제프 린지의 블로그 글 '웹을 혁신할 웹 훅(Web hooks to revolutionize the web)'은 웹에 유닉스 파이프 사상을 적용하자고 주장했다. 즉, 입력과 출력으로 서로 연결되는 단순한 프로그램들을, 사이트가 콜백을 등록하고 이벤트가 발생하면 다른 사이트가 그 콜백을 호출하게 함으로써 구현하자는 것이었다.

이 설계는 그 작음 자체가 급진적이다. 웹훅은 사용자 정의 HTTP 콜백이다. 발신 앱에 URL을 주면, 이벤트가 발생할 때 그 앱이 데이터를 당신에게 POST한다. 메시지 브로커도, 새로운 전송 형식도, 새로운 포트나 인증서도 필요 없다. 그저 모두가 이미 운영 중인 웹 위로 요청 하나를 보낼 뿐이다. 각 통합은 일대일이므로, 중앙 조정자 없이도 네트워크가 복리로 확장된다.

이 패턴은 플랫폼마다 퍼져 나갔다. GitHub, Stripe, Shopify, Slack이 웹훅 지원을 내놓았고, 2010년대에는 Zapier 같은 통합 플랫폼이 이를 앱들이 서로 '말하는' 기본 방식이라고 설명할 수 있게 되었다. 애플리케이션에게는 푸시 이메일의 순간, 즉 소프트웨어가 확인을 멈추고 수신을 시작한 때였다.

우리에게 전화하지 마세요. 우리가 전화할 테니, 평범한 HTTP로

웹훅은 URL 하나이므로, 어떤 앱이든 새로운 인프라 없이 제공할 수 있다

푸시가 폴링을 이긴다: 낭비되는 요청이 없고 기본적으로 거의 실시간 전달이 이루어진다

평범한 HTTP를 타므로 방화벽, 프록시, TLS가 이미 작동한다

일대일 연결이 중앙 브로커 없이 네트워크로 복리 확장된다

가장 값싼 표준은 새로운 기계 장치가 필요 없는 표준이다. 새로운 패턴을 모두가 이미 운영 중인 것, 즉 URL과 HTTP POST로 표현할 수 있다면 도입은 저절로 이루어진다.

웹훅은 외부인의 아이디어에서 기본 요건이 되었고, 그 단순함은 업계가 이후 표준화로 대응한 나름의 문제들을 낳았다. 이제 페이로드는 서명되며(Stripe가 HMAC 서명을 대중화했다), 소비자는 재시도와 멱등성을 필요로 하고, 공격자가 제공한 URL을 가져오는 수신자는 OWASP가 상세히 문서화한 고전적인 서버 측 요청 위조 벡터가 되었다. 블로그 글로 시작한 것이 이제는 결제 확인, 코드 배포, 채팅 앱 알림이 이루어지는 방식이다.