디바운스와 쓰로틀, 무엇이 어떻게 다르고 언제 선택해야 할까
빠른 답
- 입력이 멈춘 뒤 한 번만 실행하면 되는 작업은 디바운스가 맞습니다.
- 연속 이벤트 중에도 일정 주기로 반응해야 하면 쓰로틀이 더 자연스럽습니다.
- 무한 스크롤을 scroll 이벤트로 구현한다면 보통 쓰로틀이 유리하지만, 최신 브라우저 환경에서는 Intersection Observer도 함께 비교해야 합니다.
- 실무에서는 delay 값보다 leading 또는 trailing 여부, 그리고 중복 요청 방지가 더 큰 차이를 만듭니다.
목차
한눈에 비교
브라우저는 input, scroll, resize, mousemove 같은 이벤트를 매우 짧은 간격으로 연속 발생시킵니다. 이때 핸들러 안에서 DOM 측정, 네트워크 요청, 상태 변경을 그대로 수행하면 화면 반응이 흔들리거나 같은 요청이 과하게 반복될 수 있습니다. 디바운스와 쓰로틀은 이런 과호출을 줄이는 도구이지만, 두 기법이 답하는 질문은 조금 다릅니다.
왜 자주 헷갈릴까
둘 다 "이벤트를 덜 실행한다"는 점에서 출발하기 때문에 이름만 보면 비슷해 보입니다. 라이브러리 예제도 둘 다 delay나 wait 값을 받는 경우가 많아서, 숫자만 조정하면 같은 종류의 도구처럼 느껴지기도 합니다.
차이는 실행 철학에 있습니다.
디바운스는 마지막 이벤트를 남기고 앞선 호출을 계속 지웁니다. 사용자가 무엇을 하다 멈췄을 때 최종 상태를 처리하는 데 더 가깝습니다. 검색창, 자동 저장, 창 크기 조절 후 레이아웃 재계산 같은 작업이 여기에 해당합니다.
쓰로틀은 연속 이벤트가 이어져도 처리 빈도를 일정 수준 이하로 제한합니다. 중간 상태를 완전히 버리지는 않고, "너무 자주는 아니지만 계속 보고는 있어야 하는" 상황에 맞닿아 있습니다. 스크롤 위치 반영, 드래그 중 좌표 업데이트, 고빈도 센서 입력 처리 같은 경우가 대표적입니다.
같은 화면 안에서도 둘을 섞어 써야 하는 경우가 적지 않습니다. 검색 입력창을 예로 들면, 사용자가 타이핑한 글자는 즉시 보여야 하지만 서버 요청은 그렇게 자주 보낼 필요가 없습니다. 입력 UI와 네트워크 부수 효과를 분리해 생각하면 왜 디바운스가 검색 요청에 자주 붙는지 더 분명해집니다.
시간 흐름으로 이해하기
차이는 시간축으로 놓고 보면 더 쉽게 보입니다.
- 이벤트 발생:
0ms,100ms,200ms,300ms debounce(300): 마지막 이벤트 뒤300ms가 지난 시점에 한 번 실행throttle(300): 이벤트가 이어져도300ms간격으로 실행 가능- 결과 해석: 디바운스는 "마지막 한 번", 쓰로틀은 "중간중간 한 번"
여기서 많이 놓치는 부분이 하나 더 있습니다. 쓰로틀이 항상 "첫 번째만 실행한다"거나 "마지막만 실행한다"고 단정하기는 어렵습니다. 구현체마다 leading, trailing 기본값이 다를 수 있기 때문입니다. 어떤 쓰로틀은 첫 호출을 즉시 실행하고, 어떤 구현은 간격 끝에서 마지막 호출을 보장합니다. 문서나 옵션을 함께 봐야 이유를 이해하기 쉽습니다.
어떤 상황에 무엇을 고를까
검색 자동완성은 디바운스 쪽이 잘 맞는 편입니다. 사용자가 r, re, rea, react를 빠르게 입력할 때마다 API를 호출하면 서버 부하가 커질 뿐 아니라 응답 순서가 뒤집혀 오래된 결과가 뒤늦게 화면을 덮어쓸 수도 있습니다. 입력창 자체는 즉시 반응하게 두고, 검색 요청만 디바운스로 묶는 방식이 보통 더 깔끔합니다.
자동 저장도 비슷합니다. 사용자가 한 글자 입력할 때마다 저장하기보다, 입력이 잠시 멈춘 시점에 한 번 저장하는 쪽이 요청 수를 줄이고 중간 상태를 덜 남깁니다. 다만 "몇 초마다 반드시 저장해야 한다"는 요구가 있으면 디바운스 단독보다 주기 저장과 결합하는 편이 더 맞을 수 있습니다.
스크롤은 쓰로틀과 자주 엮입니다. 사용자가 페이지를 계속 움직이는 동안 현재 위치를 간헐적으로 읽어야 하므로, "멈춘 뒤 한 번"보다는 "움직이는 동안 간격을 두고 확인"하는 쪽이 더 어울립니다. 무한 스크롤, 스크롤 진행률 표시, 특정 지점 도달 감지는 여기에 속합니다.
버튼 연타는 조금 다르게 볼 필요가 있습니다. 예제 글에서 쓰로틀로 설명되는 경우가 많지만, 저장이나 결제처럼 부수 효과가 큰 작업은 쓰로틀만으로 부족한 경우가 많습니다. 첫 클릭만 받고 나머지를 무시할 수는 있어도, 요청이 아직 끝나지 않았는지 사용자에게 드러나지 않으면 혼란이 남습니다. 이런 경우에는 isSubmitting 같은 잠금 상태, 버튼 비활성화, 서버 쪽 멱등성 보장까지 같이 보는 편이 낫습니다.
코드로 보는 디바운스
디바운스의 핵심은 호출될 때마다 기존 타이머를 지우고 다시 잡는 것입니다. 그래서 마지막 호출만 남게 됩니다.
export function debounce(fn, wait, { leading = false, trailing = true } = {}) {
let timerId = null;
let lastArgs = null;
const invoke = () => {
timerId = null;
if (trailing && lastArgs) {
fn(...lastArgs);
lastArgs = null;
}
};
function debounced(...args) {
const callNow = leading && timerId === null;
lastArgs = args;
clearTimeout(timerId);
timerId = setTimeout(invoke, wait);
if (callNow) {
fn(...args);
lastArgs = null;
}
}
debounced.cancel = () => {
clearTimeout(timerId);
timerId = null;
lastArgs = null;
};
return debounced;
}
이 구현에서 눈에 띄는 부분은 세 가지입니다. 첫째, 호출이 들어올 때마다 setTimeout을 새로 잡기 때문에 조용한 구간이 생기기 전까지는 실행이 밀립니다. 둘째, leading: true이면 첫 호출을 즉시 실행할 수 있습니다. 셋째, cancel()을 제공하면 화면 전환이나 컴포넌트 정리 시점에 예약된 실행을 안전하게 지울 수 있습니다.
검색 요청에 붙이면 동작이 더 또렷해집니다. 이때는 요청 수만 줄이는 것으로 끝나지 않고, 이전 요청 취소도 같이 두는 편이 좋습니다. AbortController를 사용하면 늦게 도착한 이전 응답이 결과를 덮어쓰는 상황을 줄일 수 있습니다.
const input = document.querySelector('#search');
const result = document.querySelector('#result');
let controller = null;
const requestSearch = debounce(async (query) => {
controller?.abort();
if (!query.trim()) {
result.textContent = '';
return;
}
controller = new AbortController();
try {
const response = await fetch(`/api/search?q=${encodeURIComponent(query)}`, {
signal: controller.signal,
});
const items = await response.json();
result.textContent = items.map((item) => item.name).join(', ');
} catch (error) {
if (error.name !== 'AbortError') {
console.error(error);
}
}
}, 300);
input.addEventListener('input', (event) => {
requestSearch(event.target.value);
});
여기서 디바운스가 맡는 역할은 "입력이 멈춘 뒤 요청하기"이고, AbortController가 맡는 역할은 "오래된 요청 정리하기"입니다. 둘은 비슷해 보여도 해결하는 문제가 다릅니다.
코드로 보는 쓰로틀
쓰로틀은 마지막 실행 시점과 다음 실행 가능 시점을 기준으로 움직입니다. 이벤트가 계속 발생해도 설정한 간격보다 자주 실행되지는 않습니다.
export function throttle(fn, wait, { leading = true, trailing = true } = {}) {
let lastRun = 0;
let timerId = null;
let lastArgs = null;
const invoke = (time, args) => {
lastRun = time;
fn(...args);
};
function throttled(...args) {
const now = Date.now();
if (!leading && lastRun === 0) {
lastRun = now;
}
const remaining = wait - (now - lastRun);
if (remaining <= 0) {
clearTimeout(timerId);
timerId = null;
lastArgs = null;
invoke(now, args);
return;
}
if (trailing) {
lastArgs = args;
if (!timerId) {
timerId = setTimeout(() => {
timerId = null;
invoke(Date.now(), lastArgs);
lastArgs = null;
}, remaining);
}
}
}
throttled.cancel = () => {
clearTimeout(timerId);
timerId = null;
lastArgs = null;
lastRun = 0;
};
return throttled;
}
쓰로틀은 "호출을 완전히 없애는" 기법이라기보다, "호출 빈도에 상한을 둔다"는 쪽에 가깝습니다. 그래서 중간 반응이 필요한 이벤트와 잘 맞습니다. 스크롤 위치를 읽는 경우를 예로 들면 아래처럼 구성할 수 있습니다.
let page = 1;
let isLoading = false;
async function loadNextPage() {
if (isLoading) return;
isLoading = true;
try {
const response = await fetch(`/api/feed?page=${page}`);
const items = await response.json();
renderItems(items);
page += 1;
} finally {
isLoading = false;
}
}
const onScroll = throttle(() => {
const nearBottom =
window.innerHeight + window.scrollY >= document.body.offsetHeight - 300;
if (nearBottom) {
loadNextPage();
}
}, 200, { leading: true, trailing: true });
window.addEventListener('scroll', onScroll, { passive: true });
여기서는 두 층의 보호 장치가 함께 들어갑니다. 쓰로틀은 이벤트 빈도를 줄이고, isLoading은 이미 진행 중인 페이지 요청을 막습니다. 스크롤 핸들러를 줄였다고 해서 중복 요청 문제가 저절로 사라지는 것은 아니므로, 이 둘을 분리해서 보는 편이 좋습니다. passive: true도 함께 두면 브라우저가 스크롤 처리 최적화를 적용하기 쉬워집니다.
무한 스크롤에서는 왜 쓰로틀이 먼저 떠오를까
무한 스크롤을 scroll 이벤트로 직접 구현한다면, 관심사는 대개 "하단 근처에 왔는가"입니다. 사용자가 페이지를 계속 내리는 동안 이 조건을 간헐적으로 확인해야 하므로 쓰로틀이 자주 선택됩니다. 사용자가 멈춘 뒤에야 검사하는 디바운스보다, 움직이는 중간에도 상태를 읽을 수 있기 때문입니다.
디바운스를 쓰면 사용자가 거의 하단에 다다른 뒤에도 손을 멈출 때까지 로딩이 시작되지 않을 수 있습니다. 스크롤이 빠른 화면에서는 빈 공간이 먼저 보이거나 다음 페이지 요청이 늦게 붙는 느낌이 날 수 있습니다.
다만 무한 스크롤의 목적이 "스크롤 숫자 계산"이 아니라 "특정 요소가 화면에 들어왔는지 확인"이라면, 이벤트 자체를 덜 다루는 방식이 더 단순할 수 있습니다. 이때는 Intersection Observer API를 같이 검토할 만합니다.
const sentinel = document.querySelector('#sentinel');
const observer = new IntersectionObserver(
(entries) => {
if (entries.some((entry) => entry.isIntersecting)) {
loadNextPage();
}
},
{ rootMargin: '300px' }
);
observer.observe(sentinel);
이 방식은 목록 끝의 감시용 요소가 뷰포트에 들어왔는지를 직접 기준으로 삼습니다. 하단 감지가 목표일 때는 코드가 더 짧아지고, scroll 이벤트를 계속 계산하지 않아도 된다는 점이 장점으로 꼽힙니다. 반대로 스크롤 위치 숫자 자체가 계속 필요하다면 여전히 쓰로틀 쪽이 더 직관적일 수 있습니다.
구현할 때 놓치기 쉬운 점
delay 값만 정하고 끝내면 미묘한 문제가 남는 경우가 많습니다. 먼저 볼 항목은 leading과 trailing입니다. 검색처럼 마지막 값이 중요하면 보통 leading: false, trailing: true가 잘 맞습니다. 스크롤처럼 시작 반응도 필요하고 마지막 상태도 놓치고 싶지 않다면 leading: true, trailing: true 조합이 더 자주 보입니다. 반대로 trailing: false를 켜 두면 마지막 호출이 실행되지 않을 수 있으므로, 왜 마지막 상태를 버려도 되는지 먼저 생각해 두는 편이 좋습니다.
정리 함수도 자주 빠집니다. 예약된 디바운스 호출이나 쓰로틀 후행 호출이 남아 있으면, 페이지 이동 뒤에 이전 화면 기준으로 함수가 실행될 수 있습니다. 프레임워크를 쓰는 경우에는 언마운트 시점에 cancel()을 호출하고, 네트워크 요청은 abort()로 정리하는 습관이 도움이 됩니다.
지연 시간은 정답이 고정돼 있지는 않지만 출발점은 잡아둘 수 있습니다.
- 검색 입력:
250~400ms - 스크롤 처리:
100~200ms - 창 크기 변경 후 정리 작업:
100~250ms
이 숫자는 화면 성격과 요청 비용에 따라 달라집니다. 입력 즉시 결과가 보여야 하는 제품 검색과, 내부 관리 도구의 느슨한 필터 입력은 같은 값을 쓰지 않아도 됩니다.
마지막으로, 시각적 업데이트가 프레임 단위로 이어져야 하는 작업은 쓰로틀보다 requestAnimationFrame이 더 잘 맞는 경우가 있습니다. 예를 들어 스크롤 연동 애니메이션, 드래그 중 위치 이동, 패럴랙스 효과는 타이머 간격보다 브라우저 렌더 주기에 맞추는 편이 덜 흔들릴 수 있습니다. 디바운스와 쓰로틀은 이벤트 빈도 제어 도구이고, 모든 고빈도 UI 갱신의 유일한 답은 아닙니다.
원문 참고
https://www.maeil-mail.kr/question/41
댓글
댓글 쓰기