throttle과 debounce를 위해서 lodash가 필요했을까?

간혹, 버튼이나 스크롤 이벤트에서 디바운스나 쓰로틀을 이용하여 함수의 호출 횟수를 핸들링하고 싶을 때가 있다.

그럴 때 나는 lodash 라이브러리를 이용해서 이 라이브러리에서 제공하는 함수를 호출하여 사용했었다.

그런데, 쓰로틀과 디바운스만 사용하는데 lodash 라이브러리를 사용해야하는 걸까? 하는 생각이 들었다.

 

그리고 내가 쓰로틀과 디바운스를 적용했던 것이 과연 적절한 동작이었을까? 한 번 회고하며 알아보면 좋을 것 같다는 생각이 들어서 글을 작성하게 되었다.

 

아마 많은 분들이 쓰로틀과 디바운스가 뭐야? 라고 물었을 때 거의 반자동으로 답변을 하실 수 있으리라고 생각한다.

하지만 ! 모르시는 분들이 있을 수 있기 때문에 한 번 더 정의를 짚고 넘어가려고 한다.

그리고 나도 한 번 더 확실하게 정리하고 넘어가야, 이후에 내가 적용했던 부분에서 제대로 적용한 것이었는지 판단할 수 있지 않겠는가?!

그럼 바로 알아보자

 

디바운스와 쓰로틀 (debounce & throttle)

Debounce (디바운스)

짧은 시간 동안 이벤트가 여러 번 발생하더라도 마지막 이벤트가 발생한 후 일정 시간 동안 대기한 뒤에만 실행되도록 하는 것이다.

 

"마지막 이벤트 후 일정 시간 동안 대기한 뒤에만 실행"

 

라고 생각하면 된다 ! 그러면 이런 경우 보통 언제 적용하게 되는 것일까?

한 번 잠깐 생각해보면 좋을 것 같다.

떠올려보자, 이벤트가 지속적으로 발생하는 상황에서 마지막 이벤트 후 일정 시간 뒤에 실행되어야하는 것이 뭐가 있을까?

-> 사용자 동작이 끝났을 때 그 동작의 결과를 가지고 이벤트를 실행시키는 상황

 

첫 번째로 떠오르는 상황은 검색 input이었다.

최근에 수행했었던 과제의 요구사항도 검색 input에 적절한 이벤트 핸들링 처리를 해줘야하는 것이었다.

완성 예시에서 검색 input에 debounce가 걸려있어서 나도 동일하게 처리를 해줘야 했다.

 

디바운스와 쓰로틀에 대한 정의가 제대로 되어 있지 않았으면 쓰로틀을 적용하지 않았을까? 하는 끔찍한 생각이 들기도 하는 군 흠흠

 

말고도 창의 크기를 마구 바꿔주다가 멈췄을 때 레이아웃이 적용되는 식의 인도우 리사이즈 이벤트 역시 디바운스를 통해 적용해줘야할 것 같다.

디바운스를 어떤 상황에서 적용해줘야하는지 느낌이 오는가? 그렇다면 쓰로틀에 대해서도 알아보자

 

Throttle (쓰로틀)

연속적으로 발생하는 이벤트 중에서도 최대 한 번만 실행하도록 만드는 것이다.

 

"지정된 시간 간격으로 실행"

여기서 중요한 키워드는 바로 '시간'이다.

사용자가 아무리 이벤트를 잔뜩 발생시켜도, 지정된 시간이 지나지 않았다면 함수는 실행되지 않는다.

-> 함수가 자주 호출되지 않도록 막아야한다 ! (api 요청과 관련된 경우는 특히 서버 자원이 낭비되지 않게 해야 함)

 

이번에도 어떤 상황에서 쓰로틀을 적용하면 좋을 지 예시를 한 번 생각해보자.

나는 첫 번째로 떠오른 상황은 버튼 이벤트였다. 특히 api 요청을 보내는 버튼에는 쓰로틀이 적절해보인다.

 

한 가지 더 생각해보자면, 스크롤 이벤트가 떠오른다.

스크롤은 이벤트는 마우스 휠이 움직일 때마다 발생하기 때문에 상당히 짧은 간격으로 많이 호출되는데, 이럴 때 디바운스를 걸면 어떻게 될까? 사용자는 스크롤을 하는데 그에 대해서 무반응이었다가 스크롤 이벤트가 다 끝났을 때 갑자기 렉걸렸다 풀리듯 쉬쉬쉭 이벤트가 발생할 것이다. 끔찍한 사용자 경험이 되고 말 것이다.

고로, 스크롤 이벤트는 쓰로틀을 적용하는 것이 적절해보인다.

 

내가 그동안 사용해왔던 디바운스와 쓰로틀

내가 개발을 시작하고 나서 사용했던 디바운스와 쓰로틀 사용 사례를 최대한 전부 가져와보려고 했다.

놓친.....사례가 있을 수도 있지만 ! 우선 적절했는지 한 번 생각해보자

 

디바운스

- 검색 input : input의 value 값이 바뀔 때마다 그에 따른 api 요청을 보내고 있었고, 사용자의 의도보다 많은 이벤트가 호출되고 있어서 이를 개선하기 위해서 사용해준 상황

 

쓰로틀

- 랜덤 데이터 조회를 위한 Button : 버튼을 누를 때마다 랜덤 데이터를 받아오는 api 요청 버튼에 쓰로틀을 걸어준 상황

- 토글 버튼 : 사용자의 설정을 변경하는 토글 버튼, 이를 연타하여 설정을 불필요하게 자주 바꾸지 못하도록 쓰로틀링을 걸어준 상황

- 스크롤 이벤트 : 사용자가 스크롤 이벤트를 발생시킬 때 페이지의 특정 위치로 슬라이딩 되어 이동해야하는 상황

 

사용 사례를 찾아보면서, 혹시라도 잘 못 사용하고 있으면 어쩌나 라는 생각을 했는데, 사용을 안해서 문제인 경우는 있었지만 잘 못 사용한 적은 없어서 불행(?) 중 다행이라는 생각이 들었다.

 

사실 디바운스와 쓰로틀의 적용 자체는 프론트엔드의 기본적인 처리 중 하나라서, 앞으로는 필요한 곳에 반드시 사용해줘야할 것이다.

그렇다면 적용하는 과정에서 사용했던 'lodash' 라이브러리의 사용은 과연 적절했을까?

 

 

lodash가 뭔데?

이 글을 작성하면서 lodash에서 조금 더 알아보았다. 그리고 크게.... 크게 반성했다. 쓰로틀과 디바운스를 적용했을 때는 거의 모든 경우에 lodash에서 제공하는 쓰로틀과 디바운스를 사용했는데, 한 번도 '굳이' lodash를 써야하는 이유에 대해서 고민해본 적이 없는 것 같았다. 성능 최적화 한다고 폰트랑 이미지 확장자는 그렇게 신경쓰면서 이런 대용량 라이브러리 선택은 아무 생각 없이 한다니...! 반성했다.

 

그래서 lodash에서 제공하는 기능들이 어떤 것들이 있는지, 패키지의 크기가 어떻게 되는지 한 번 알아보았다.

 

제공 기능

배열 및 객체 처리, 문자열 조작, 함수 유틸리티, 객체 깊은 복사, 데이터 정렬 및 그룹화 등 throttle과 debounce를 포함한 정말 많은 함수를 제공하는 라이브러리이다.

많은 기능을 제공하기 때문에 패키지 크기도 약 24.5kB로 큰 것을 볼 수 있다.

 

그렇다면 나는 lodash에서 debounce와 throttle을 제외한 다른 함수들을 사용하고 있는가...?

안타깝게도 아니다.

그렇다면 어떻게 개선할 수 있을까

 

 

모기잡으려고 대포를 쏘면 안되지

지금 내 꼴이 딱 이 꼴이다. 그래서 방법을 몇 가지 생각해보았다. 우선 라이브러리를 꼭 써야할까? 디바운스와 쓰로틀 정도는 직접 구현해서 사용해도 되지 않을까?

 

이것도 맞다 ! 하지만, 실사용자를 맞이해야하는 입장이었기 때문에 두려웠던 것도 사실이었다. (프로젝트 와글와글2)

가뜩이나 애플의 아이폰, 아이패드에서 생각치 못한 오류로 곤혹을 겪고 있었기 때문에 운영체제에 따라 발생할 수 있는 이슈들을 잡을 수 있을까 하는 걱정도 있었고, 빠른 시간 안에 구현을 마쳐야했기 때문에 라이브러리 사용을 선택했다.

 

그러면 그때로 돌아가 지금보다 나은 선택을 하기 위해서 할 수 있는 선택은 무엇일까?

 

lodash 라이브러리에서 throttle과 debounce만 가져오기

이번에 어떻게 개선할 수 있었을까를 고민하던 중 알게된 방법이었다. 라이브러리 중에서 특정 기능들만 따로 다운받아서 사용할 수 있다. 어처피 두 가지 함수만 사용하고 있다면,  두 개만 다운받으면 된다.

 

npm install lodash.debounce lodash.throttle

기존에 설치했었던 lodash를 삭제하고, 두 개의 함수만 다운받았을 때의 패키지의 크기를 비교해보았다.

 

168.1MB -> 143.2MB 로 약 25MB 가량 줄어든 것을 볼 수 있다.

 

그럼 여기서 한 가지 더, 패키지 크기가 작아지면 뭐가 좋은걸까?

그건 이전 게시글을 한 번 읽어보시죠 ! (저도 더 많이 공부해서 보완해보도록 하겠습니다)

 

2024.12.02 - [🗂️ 개발 이모저모] - node_modules, 패키지 크기가 작아지면 좋은 점이 뭘까?

node_modules, 패키지 크기가 작아지면 좋은 점이 뭘까?

 

throttle-debounce 라이브러리 사용

`throttle-debounce` 라이브러리는 쓰로틀과 디바운스만 제공하는 1KB의 작은 라이브러리이다.

앞서 얘기했던 것처럼 특별히 내가 쓰로틀과 디바운스 이외에 사용할 일이 없다면, 애초에 lodash 대신 throttle-debounce 라이브러리를 사용하는 것도 하나의 방법이 된다.

 

 

 

느낀 점

하나의 라이브러리를 사용하더라도, 이 라이브러리에서 어떤 기능들을 제공하는지 패키지의 크기가 불필요하게 크지는 않은지 등을 고려하면서 라이브러리를 선택해야겠다.

이렇게 라이브러리에 대해서도 확실하게 알고 사용하면, 라이브러리 선택의 타당성도 높아지고 불필요하게 패키지 크기를 커지게 만들 일도 없을 것이다.

초반부터 이런 습관을 들여놓아야하는데, 이제서야 이렇게 생각해보게 되서 아쉽고 그래도 앞으로는 이전과 같은 실수를 하지 않을테니 다행이라는 생각도 든다.

 

그럼 오늘은 이만~!

안뇽 !