웹훅 vs. 폴링
이 글에서는 웹훅과 폴링을 비교하고, 각각의 접근 방식의 장단점을 분석하며, 언제 어떤 것을 사용해야 하는지에 대해 논의할 것입니다.
웹 애플리케이션을 구축할 때, 우리는 종종 여러 서비스를 사용하게 됩니다. 대부분의 경우, 이들은 함께 작동하는 여러 다른 웹 서비스로 구성됩니다. 이러한 여러 서비스로 구성된 웹 애플리케이션에서 데이터를 전송하는 방법은 모든 개발자가 고려해야 할 중요한 사항입니다.
이 문제를 해결하기 위해 두 가지 접근 방식이 주류가 되었습니다: 웹훅과 폴링. 각 방법은 하나의 서비스에서 다른 서비스로 데이터를 가져오고 전달하는 독특한 방법을 제공합니다. 어느 한 방법을 선택하는 것은 애플리케이션의 효율성, 실시간 기능 및 전체적인 사용자 경험에 큰 영향을 미칠 수 있습니다. 이 글에서는 웹훅과 폴링을 비교하고, 각각의 접근 방식의 장단점을 분석하며, 언제 어떤 것을 사용해야 하는지에 대해 논의할 것입니다.
폴링이란?
폴링(흔히 API 폴링이라고 함)은 클라이언트가 특정 데이터를 정기적으로 요청하고(예를 들어, 매 x 초마다), 서버가 요청된 데이터를 응답하는 과정입니다.
이를 정기적으로 "새로운 데이터가 있습니까?"라고 묻는 것으로 생각할 수 있습니다. 폴링은 HTTP 요청을 통해 구현될 수 있으며, 클라이언트가 서버에 GET 요청을 보내고 서버가 요청된 데이터를 응답합니다.
존이 Doc.AI라는 AI 문서화 제품을 만들고 사용자 아이덴티티 관리를 위해 Logto를 사용하고 있다고 상상해 보세요.
프랭크는 존의 제품에 가입하여 자신의 개인 계정을 만든 사용자입니다. 어느 날, 프랭크는 그의 친구 데이비드가 만든 워크스페이스에 가입합니다. 이 순간, 존은 프랭크에게 이메일을 보내 추가적인 민감한 리소스에 접근하기 전에 계정 보안을 강화하기 위해 다중 인증(MFA)을 켜 달라고 요청하고자 합니다.
존의 제품 백엔드는 프랭크가 데이비드의 워크스페이스에 가입했는지 알기 위해 관련 API를 지속적으로 폴링해야 합니다.
웹훅이란?
웹훅(즉, "HTTP 콜백")은 이벤트가 발생했을 때 서버가 클라이언트에 데이터를 보내는 실시간 데이터 통신 메커니즘입니다. 클라이언트가 데이터를 요청하는 것이 아니라 웹훅이 업데이트가 있을 때마다 클라이언트에 데이터를 푸시합니다.
이를 애플리케이션의 받은 편지함으로 생각할 수 있습니다. 특정 이벤트, 예를 들어 신규 사용자가 가입하거나 결제가 이루어졌을 때, 웹훅은 애플리케이션에 메시지를 떨어뜨려 무슨 일이 일어나고 있는지 알려줍니다.
앞서 폴링을 설명할 때 사용한 Doc.AI 예시를 계속 이어가 봅시다. 웹훅을 사용하여 프랭크가 데이비드의 워크스페이스에 가입했는지 확인하는 경우 시퀀스 다이어그램이 다음과 같이 변경됩니다:
중요한 차이점
- 요청의 시작점 폴링은 클라이언트(우리의 예에서는 Doc.AI가 클라이언트이고 Logto가 서버)가 초기화하며, 웹훅은 이벤트에 의해 트리거되고 서버가 시작점입니다.
- 리소스 소비 폴링은 정기적으로 요청을 보내기 때문에 계산 자원을 낭비하며 비효율적인 자원 사용으로 이어집니다. 반면에 웹훅은 서버가 "필요에 따라" 시작합니다. 폴링에 비해 클라이언트와 서버 모두 훨씬 적은 자원을 소비합니다.
- 타이밍 폴링은 클라이언트가 시작하므로 클라이언트가 데이터 획득의 타이밍을 제어할 수 있지만, 웹훅은 서버가 시작하며 클라이언트는 데이터 수신과 처리를 할 수밖에 없습니다. 그러나 두 가지 메커니즘의 차이로 인해, 웹훅은 폴링으로 달성할 수 없는 실시간 데이터 동기화를 달성할 수 있습니다.
어떤 것을 선택해야 할까요?
폴링과 웹훅의 메커니즘에 기반하여, 일반적으로 데이터가 자주 업데이트되고 실시간 요구사항이 엄격하지 않은 경우에만 폴링을 선택합니다. 그 외의 경우에는 웹훅이 더 나은 선택입니다.
그러나 웹훅을 사용하기로 결정할 때, 개발자들은 다음과 같은 사항을 주의해야 합니다:
- 시스템이 획득된 데이터에 크게 의존하는 경우, 웹훅이 실패하여 데이터가 동기화되지 않는 상황을 염두에 두고 백업 계획을 고려해야 합니다. 예를 들어, 폴링을 사용하거나 웹훅에 재전송 메커니즘을 요구하는 것 등을 포함할 수 있습니다.
- 웹훅 을 수신하는 클라이언트 사이드 엔드포인트에서 API 비밀키와 콘텐츠 서명 검증 등을 적용하여 해커가 웹훅을 위조해 클라이언트를 공격하지 못하도록 해야 합니다.
- 웹훅이 중복된 요청을 보낼 수 있으므로, 이로 인해 데이터 중복과 비일관성이 발생하지 않도록 필수적인 처리가 필요합니다.
Logto는 매우 인기 있는 사용자 아이덴티티 솔루션으로, 풍부한 웹훅 장면과 뛰어난 보안을 제공합니다. Logto를 제품의 아이덴티티 시스템으로 사용하면 다양한 애플리케이션 장면에 쉽게 통합되고 적합할 수 있습니다.