(번역) 브라우저가 자바스크립트 타이머를 스로틀링(throttle) 하는 이유는 무엇일까요?

 

 

원문: https://nolanlawson.com/2025/08/31/why-do-browsers-throttle-javascript-timers

 

 

자바스크립트를 꽤 오래 사용해 왔다고 하더라도 setTimeout(0)이 실제로는 setTimeout(0)이 아니라는 사실에 놀랄 수 있습니다. 실제로 이것은 4ms 이후에 실행될 수 있습니다.

 

const start = performance.now()
setTimeout(() => {
  // 아마도 4ms
  console.log(performance.now() - start)
}, 0)

 

거의 10년 전 Microsoft Edge 팀에 있었을 때, 브라우저가 이런 방식을 채택한 이유는 "남용"을 방지하기 위함이라고 들었습니다. 즉, setTimeout을 과도하게 사용하는 웹사이트가 많기 때문에, 사용자의 배터리 소모를 막고 상호작용을 차단하지 않기 위해 브라우저가 4ms라는 특별한 "제한된" 최소 시간값을 설정한다는 것이었습니다.

 

이는 일부 브라우저가 배터리 전원을 사용하는 기기에 대한 스로틀링을 높이거나(구버전 Edge의 경우 16ms) 백그라운드 탭에 대한 스로틀링을 훨씬 더 공격적으로 높이는 이유(Chrome의 경우 1초!)를 설명합니다.

 

그런데 한 가지 의문이 항상 저를 괴롭혔습니다. setTimeout이 그렇게 남용된다면, 왜 브라우저는 setImmediate(RIP), Promises, 심지어 scheduler.postTask() 같은 새로운 타이머를 계속 도입했을까요? 만약 setTimeout의 성능을 의도적으로 제한해야 했다면, 결국 이런 타이머들도 같은 운명을 맞이하게 되는 것 아닐까요?

 

2018년에 자바스크립트 타이머에 대한 긴 글을 쓴 적이 있지만, 최근까지 이 질문을 다시 꺼내볼 만한 뚜렷한 이유는 없었습니다. 그러다 IndexedDB API를 순수 자바스크립트로 구현한 fake-indexeddb 작업을 하던 중 이 질문이 떠올랐습니다. 알고 보니, IndexedDB는 이벤트 루프에 남아 있는 작업이 없을 때 트랜잭션을 자동 커밋하려고 합니다. 다시 말해 모든 마이크로태스크가 끝난 후, 그리고 어떠한 작업(슬쩍 '매크로태스크'라고 불러도 될까요?)도 시작되기 전 그 시점을 노리는 것이죠.

 

이 작업을 수행하기 위해 fake-indexeddb는 Node.js에서는 setImmediate를 사용하고(이는 구형 브라우저 버전과 유사함), 브라우저에서는 setTimeout을 사용했습니다. Node에서 setImmediate는 꽤 이상적인데, 마이크로태스크 이후에 다른 태스크들보다 바로 앞서 실행되고, 제한(clamping)도 없기 때문입니다. 하지만 브라우저에서는 setTimeout이 꽤 비효율적입니다. 한 벤치마크에 따르면, Node에서는 300ms 걸리던 작업이 Chrome에선 무려 4.8s나 걸렸습니다(16배 느린 속도!).

 

하지만 2025년의 타이머 기술을 살펴보면, 어떤 것을 선택해야 할지 명확하지 않았습니다. 몇 가지 선택지는 다음과 같습니다.

 

• setImmediate – 구형 Edge와 IE에서만 지원되므로, 사용할 수 없습니다.
• MessageChannel.postMessage – afterframe에서 사용하는 기법입니다.
• window.postMessage – 좋은 아이디어지만, 페이지의 다른 스크립트가 동일한 API를 사용할 경우 충돌을 일으킬 수 있어 다소 불안정합니다. 그래도 setImmediate 폴리필에서는 이 방식을 사용합니다.
• scheduler.postTask – 결론부터 말하자면, 이것이 최종 선택이었습니다. 왜 그런지 설명해 드리겠습니다!

 

이 선택지들을 비교하기 위해 저는 간단한 벤치마크를 작성했습니다. 이 벤치마크에 대한 몇 가지 중요한 사항은 다음과 같습니다.

 

1. setTimeout(및 유사한 API들)의 제한(clamping) 동작을 제대로 파악하려면, 여러 번 반복 실행해봐야 합니다.
   기술적으로는, HTML 명세에 따라 4ms 제한은 setTimeout이 5번 이상 중첩 실행될 때부터(즉, 한 setTimeout이 다른 setTimeout을 호출하는 경우) 적용됩니다.
2. 배터리 사용 혹은 전원 연결 여부, 모니터의 주사율, 탭의 백그라운드/포그라운드 여부 등이 제한 동작에 영향을 줄 수 있다는 건 알고 있지만, 그 모든 조합을 전부 테스트해 본 건 아닙니다. 저도 삶이 있고, 실험실 가운을 입고 몇 가지 실험을 하는 것도 재밌지만, 토요일 내내 그걸 하고 싶진 않습니다.

 

어쨌든, 측정된 수치들은 다음과 같습니다. (단위: ms, 2021년형 16인치 맥북 프로에서 101회 반복 측정의 중앙값)

 

브라우저	setTimeout	MessageChannel.postMessage	window.postMessage	scheduler.postTask
Chrome 139	4.2	0.05	0.03	0.00
Firefox 142	4.72	0.02	0.01	0.01
Safari 18.4	26.73	0.52	0.05	구현되지 않음

 

참고: 이 벤치마크는 작성하기가 꽤 까다로웠습니다! 처음에는 Promise.all을 사용해 모든 타이머를 동시에 실행했는데, 이 방식이 Safari의 중첩 휴리스틱을 무력화시키는 듯했고, Firefox에서는 타이머가 불규칙하게 동작했습니다. 그래서 지금은 각 타이머를 독립적으로 실행하도록 벤치마크를 수정했습니다.

 

정확한 숫자에 너무 집착할 필요는 없습니다. 중요한 점은 Chrome과 Firefox에서는 setTimeout이 4ms로 제한(clamp)된다는 것이고, 나머지 세 가지 옵션은 대체로 비슷한 성능을 보인다는 점입니다. 흥미롭게도 Safari에서는 setTimeout이 훨씬 더 강하게 제한되며, MessageChannel.postMessage는 window.postMessage보다 약간 느립니다 (물론 위에서 언급한 이유들 때문에 window.postMessage는 여전히 다소 불안정한 방식입니다).

 

이번 실험을 통해 제가 당면한 질문에 대한 답을 얻을 수 있었습니다. fake-indexeddb는 기본적으로 scheduler.postTask를 사용하고(사용성 측면에서 제가 선호하는 방식입니다), 그 외에는 MessageChannel.postMessage나 window.postMessage를 대체 옵션으로 사용하는 것이 적절해 보였습니다.
(postTask에 다양한 우선순위를 적용해 실험해 봤지만, 성능은 대부분 동일했습니다. fake-indexeddb의 사용 목적에는 기본 우선순위인 'user-visible'이 가장 적절해 보였고, 실제 벤치마크에서도 이 값을 사용했습니다.)

 

하지만 이 모든 실험도 제가 원래 궁금했던 질문에 대한 답이 되지 못했습니다. 웹 개발자들이 어차피 scheduler.postTask나 MessageChannel 같은 다른 방법을 쓸 수 있다면, 브라우저는 왜 굳이 setTimeout을 제한하려고 할까요? 저는 이러한 "개입"에 대한 논의가 활발히 진행되던 당시 웹 성능 워킹 그룹의 공동 의장이었던 제 친구 Todd Reifsteck에게 물었습니다.

 

그는 실질적으로 두 가지 진영이 존재했다고 말했습니다. 한쪽은 웹 개발자들이 스스로를 해치지 않도록 타이머를 제한해야 한다고 생각했고, 다른 쪽은 개발자들이 스스로의 어리석음을 자각하도록 두자며, 이런 미묘한 제한(휴리스틱)은 오히려 혼란만 야기한다고 주장했습니다.

 

요약하자면, 이것은 성능 관련 API를 설계할 때 늘 따라오는 고전적인 딜레마였습니다.
"어떤 API는 빠르지만, 지뢰(footgun)도 함께 따라온다." 즉, 잘못 사용하면 큰 문제를 일으킬 수 있다는 의미입니다.

 

이 내용은 제가 이 주제에 대해 갖고 있던 직관과도 잘 들어맞습니다. 브라우저 개입은 일반적으로 웹 개발자가 좋은 기능(예: setTimeout)을 너무 많이 사용하거나 더 나은 옵션을 전혀 알지 못하는 경우에 발생합니다(터치 리스너 논란이 좋은 예입니다). 결국 브라우저는 사용자를 대신하여 행동하는 "사용자 에이전트"이며, W3C의 이해관계 우선순위 원칙(Priority of Constituencies)에 따르면 최종 사용자의 요구 사항이 항상 웹 개발자의 요구 사항보다 우선한다는 점을 분명히 보여줍니다.

 

그렇긴 해도, 웹 개발자들은 종종 올바른 방식으로 작업하고 싶어 합니다. (이 블로그 글도 그런 시도의 일환이라고 저는 생각해요.)
다만, 항상 제대로 된 도구가 있는 건 아니라서 결국 눈앞에 있는 아무 도구나 집어 들고 억지로 문제를 해결하려다 더 큰 혼란을 초래하곤 합니다.
작업 처리와 스케줄링에 대해 더 많은 제어권이 주어진다면 setTimeout을 오용할 필요도 없어지고, 그 결과 일이 엉망이 돼서 개입이 필요한 상황을 피할 수 있을 겁니다.

 

제 예상으로는 당분간 postTask나 postMessage는 제한 없이(throttled 되지 않고) 유지될 것입니다. Todd가 말했던 두 "진영" 중에서, 세밀한 태스크 스케줄링 도구들을 제공하는 Scheduler API의 존재 자체가 현재는 "개발자에게 더 많은 제어권을 주자(pro-control)"는 진영이 주도권을 쥐고 있음을 시사하는 듯합니다. Todd는 이 API를 두 진영의 절충안으로 보고 있습니다. 물론 많은 제어권을 제공하지만, 무작위적인 타임아웃이 아니라 브라우저의 실제 렌더링 파이프라인과 정렬된 방식으로 동작한다는 점에서 어느 정도 균형을 이루고 있다는 것이죠.

 

비관적인 제 마음 한편에서는, 이 API조차도 결국 오용될 수 있지 않을까 하는 생각이 듭니다. 예를 들어, user-blocking 우선순위를 아무 생각 없이 모든 곳에 사용하는 식으로요.
어쩌면 미래에는 어떤 진취적인 브라우저 벤더가 스로틀링 제어를 더 강화하게 될지도 모릅니다. 그리고 그로 인해 웹사이트들이 더 빠릿빠릿하고 반응성도 좋으며 배터리 소모도 줄어들었다는 사실을 발견하게 된다면, 또다시 "브라우저 개입(intervention)"의 물결이 찾아올 수도 있겠죠. (그때가 되면, 아마 우리 모두를 그 혼란에서 구해줄 scheduler2 API 같은 게 필요해질지도 모르겠습니다!)

 

저는 더 이상 웹 표준 작업에 깊이 관여하지는 않아서 그저 추측만 할 수 있을 뿐입니다. 당분간은 대부분의 웹 개발자들이 그러하듯, 현재 제 목표를 달성하는 데 도움이 되는 API를 선택하고, 앞으로 브라우저가 너무 많이 바뀌지 않기를 바랄 뿐이죠. 우리가 조금만 신중하게 접근하고 너무 과한 무리수만 두지 않는다면, 그 정도 바람쯤은 과한 요구는 아니라고 생각합니다.

 

이 글의 초안에 피드백을 주신 Todd Reifsteck에게 감사드립니다.

 

참고: 제가 setTimeout에 대해 말한 모든 내용은 setInterval에도 그대로 적용됩니다. 브라우저 관점에서 보면, 이 둘은 거의 동일한 API입니다.

참고: 의미가 있을지는 모르겠지만, fake-indexeddb는 Safari에서 MessageChannel이나 window.postMessage 대신 setTimeout을 대체 수단으로 사용하고 있습니다. 위에서 설명한 벤치마크 결과에도 불구하고 제가 실제로 window.postMessage가 다른 두 방법보다 더 나은 성능을 보인 건 fake-indexeddb 자체의 벤치마크에서 뿐이었습니다. Safari에서는 MessageChannel에 대해 별도의 추가적인 스로틀링(throttling)이 적용되는 것 같고, 이는 제가 만든 독립 벤치마크에서는 포착되지 않았습니다. 그리고 window.postMessage는 여전히 에러 발생 가능성이 높아 보이기 때문에 개인적으로는 사용을 꺼리고 있습니다. 궁금한 분들을 위해서 제 벤치마크를 공유합니다.

 

🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article을 구독해주세요!