Debounce vs Throttling 이해하기

안녕하세요 기존의 영상들과 더불어 이제 면접에서 나오는 질문들이나 주제들을 모아서 면접지식 시리즈를 시작해보려고 합니다. 오늘은 프론트엔드 쪽으로 취준을 하시면 자주 나오는 질문인 쓰로틀링과 디바운스에 대해서 알아보려고 합니다.

 

쓰로틀링과 디바운스 모두 프론트엔드에서 성능 최적화를 위해서 사용됩니다. 특정 이벤트에 로직을 붙일 때 로직이 실행되는 횟수를 제한하는 것이 목적이지만 동작방식이 조금씩 차이가 있는데요,

 

—-

먼저 쓰로틀링입니다.

쓰로틀링은 한번 로직이 실행되고 나면이후 정해진 시간동안은 해당 로직의 실행을 막는 방식입니다. 

화면에서 보이다시피 처음 0초에 이벤트가 발생되었기때문에 로직이 실행됩니다. 현재 화면의 예시는 쓰로틀링을 3초로 걸었기때문에 1초와 2초에 발생한 이벤트에 대해서는 로직이 실행되지 않습니다. 그 후 3초가 지났기때문에 3초에 발생한 이벤트에 대해서는 다시 로직이 실행됩니다.

 

이런 방식으로 한번 로직이 실행되고 나면 일정 시간동안 로직의 재실행을 막는 것을 쓰로틀링이라고 합니다. 이벤트 발생 시에 수행되는 이벤트 핸들러는 로직 실행가능여부를 판단하여 로직을 실행하는데요.

 

 

첫번째 방식으로는 로직을 실행한 후 로직 실행가능여부를 false로 바꾸고 타이머를 세팅하여 정해진 시간이 지난후 true로 변경해주는 방식으로 작성이 가능하고 두번째로는 로직이 마지막으로 수행된 시간을 저장해두고 이벤트 핸들러에서 이벤트가 발생했을때의 시간을 저장된 마지막 로직 수행시간과 비교하여 실행여부를 판단할 수 있습니다.

 

—

다음은 디바운스입니다.

디바운스는 이벤트발생이 종료되고 정해진 시간이 지날동안 이벤트가 다시 발생하지 않으면 로직을 실행하는 방식입니다. 정해진 시간이 지나기 전에 다시 이벤트가 발생한다면 다시 처음부터 그 시간을 기다립니다. 

 

화면을 보시면 0초에 최초로 이벤트가 발생하여 3초까지 대기하다가 로직을 실행하려고 합니다. 하지만 1초에 다시 이벤트가 발생했기때문에 4초까지 기다리도록 타이머가 초기화되었고, 2초에도 동일하게 초기화되어 5초까지 기다리게됩니다. 그 후 3초와 4초에는 이벤트가 발생하지않았기때문에 5초에 예약되었던 로직이 실행됩니다.

 

 

디바운스는 이벤트 핸들러에서 로직 수행을 위한 타이머가 세팅되어 있는 지를 확인합니다. 세팅되어있지 않다면 정해진 시간 후에 로직이 수행하도록 타이머를 세팅합니다. 만약 이미 타이머가 세팅되어있다면 세팅된 타이머를 초기화하거나 제거한 후 새로 세팅합니다.

 

—

그럼 언제 어떤 방식을 사용해야할까요?

이건 전적으로 어떠한 문제를 어떠한 방식으로 해결할지에 달렸습니다. 본인의 서비스의 사용자들의 사용방법에 따라 다르기도하구요. 둘다 적용될 수 있는 문제를 예시를 들어 장단점을 설명드리겠습니다.

 

가장 대중적인 예시로 스마트폰에서 사용하는 지도 어플리케이션을 생각해보겠습니다. 이름이 프레임워크나 언어별로 다를 수 있지만 일반적으로 저희가 지도를 살펴보기 위해 터치로 쭉 끌어서 이동하는 경우 발생하는 이벤트를 drag라고 생각해보겠습니다.

 

이런 drag이벤트는 사용자가 드래그를 하는 동안 수십수백번 실행되는데요, 현재 화면의 지도에 보이는 영역에 있는 카페를 검색하기 위한 API가 호출된다고 생각하면 1초에 수십번 호출되는 것입니다. 

 

1분동안 사용된다고 하면 수천번 호출되는 것이고 천명의 사용자가 동시에 사용한다면 몇백만번 이상의 API호출이 일어나 서버에 과부하가 일어나게됩니다. 이렇게 서버 호출 뿐만이 아니라 복잡한 계산이 들어가는 경우에도 불필요하게 많이 반복됨으로 인해 부하가 일어나고 사용자의 화면에서 버벅임이 일어나기도 합니다.

 

그럼 쓰로틀링을 적용하면 어떻게 될까요? 이 경우 쓰로틀링을 적용하면 사용자가 드래그를 시작하고 3초마다 한번씩만 카페 검색 API를 호출합니다. 장점은 사용자가 드래그를 하는 동안 계속해서 현재 위치의 카페들을 볼 수 있습니다.

 

반대로 디바운스를 적용하면 사용자가 드래그를 멈출때까지 API가 호출되지 않고 드래그를 멈추면 최종 화면의 위치에 있는 카페들을 검색합니다. 쓰로틀링에 비해서 API호출 횟수가 적은점은 장점이지만 드래그를 하는 도중에는 화면에 카페가 보여지지 않습니다.

 

위의 예시에서 만약 본인의 팀이 사용자의 사용성을 더 우선시한다면 쓰로틀링을 적용할 것이고, 서버의 비용을 줄이고 싶다하면 디바운스를 적용할 수 있을 것 같은데요, 앞서 말씀드렸다시피 정답이 있다기보다는 현재의 상황에 따라 다를 것 같네요.

 

끝!