웹훅
쉽게 풀면
택배가 도착하면 문자로 알려주는 서비스를 떠올려 보세요. 내가 계속 배송 조회 페이지를 새로고침하며 확인할 필요 없이, 택배가 도착하는 "사건"이 발생하는 순간 배송 회사가 알아서 내 번호로 문자를 보내줍니다. 웹훅도 같은 원리입니다. 어떤 시스템(A)이 "이런 일이 생기면 이 주소로 알려줘"라고 다른 시스템(B)에 자신의 콜백 주소를 미리 등록해두면, B는 해당 사건이 실제로 발생했을 때 그 주소로 데이터를 담아 자동으로 요청을 보냅니다. 그래서 A는 "혹시 무슨 일 생겼나?" 하고 계속 물어보는(폴링) 대신, 일이 생겼을 때만 알림을 받아 즉시 반응할 수 있습니다.
왜 중요한가
웹훅은 서버가 지속적으로 상태를 확인(폴링)하지 않고도 실시간에 가깝게 이벤트를 전달할 수 있게 해주기 때문에, 마이크로서비스 간 통신, 서드파티 서비스 연동, IoT 기기의 상태 알림 등 다양한 분야의 시스템 설계 논문에서 이벤트 기반 아키텍처의 핵심 구성 요소로 다루어집니다. 서버 자원을 절약하면서도 반응 속도를 높일 수 있다는 장점 때문에, 확장성과 효율성을 다루는 분산시스템 연구에서도 자주 등장합니다.
논문에서는 이렇게 쓰입니다
이 문장은 결제가 끝나는 순간 그 사실을 다른 시스템에 즉시 전달하도록 설계했다는 뜻으로, 이벤트 기반 아키텍처나 시스템 통합 방식을 설명하는 논문에서 자주 쓰입니다.
소프트웨어 공학 분야에서는 코드 변경이라는 이벤트를 웹훅으로 감지하여 자동화된 빌드·배포 과정을 시작시키는 지속적 통합 환경을 구성하는 사례가 흔히 보고됩니다.
사물인터넷 분야에서는 센서의 이상 상황을 지속적으로 확인하는 대신, 이벤트가 발생했을 때만 웹훅으로 알림을 보내 자원 소모를 줄이고 반응 속도를 높이는 방식이 활용됩니다.
조금 더 깊게 보면
웹훅을 실제로 안전하게 운용하려면 수신 측이 요청의 출처를 검증하는 절차(예: 서명 검증, 비밀 토큰 확인)가 필요한데, 이는 누구나 알림 주소만 알면 위조된 요청을 보낼 수 있기 때문입니다. 또한 네트워크 문제로 알림이 유실되거나 중복 전송될 수 있어, 송신 측은 재시도(retry) 로직을, 수신 측은 동일한 이벤트를 여러 번 받아도 결과가 달라지지 않도록 하는 멱등성(idempotency) 처리를 갖추는 것이 일반적입니다. 최근에는 웹훅과 유사한 목적을 메시지 큐나 발행-구독 패턴으로 대체해 안정성과 순서 보장을 강화하는 아키텍처도 함께 논의됩니다.
주의할 점
웹훅은 클라이언트가 서버에 요청을 보내야만 응답을 받는 일반적인 REST API (자원 중심 API 설계) 호출과 방향이 반대입니다. 즉 요청을 보내는 주체가 우리 쪽이 아니라 사건이 발생한 시스템이라는 점에서, 수신 측은 예상치 못한 시점에 오는 요청을 안전하게 검증하고 처리할 준비가 되어 있어야 합니다. 알림이 순서대로 오거나 반드시 한 번만 온다는 보장이 없는 경우도 많아, 중복 처리나 순서 뒤바뀜에 대비한 설계가 필요합니다.