🚀 웹앱이 느려지는 진짜 이유, Microsoft가 밝힌다

 

웹 성능, 왜 이렇게 중요할까요?

요즘 우리가 쓰는 웹앱들, 정말 복잡해졌죠? 은행 앱, 협업 툴, 클라우드 서비스까지. 그런데 가끔 버튼 하나 누르는데도 한참 기다려야 할 때 있잖아요. 그럴 때마다 "내 인터넷이 느린 건가?" 싶으시죠?

사실 문제는 인터넷 속도가 아닐 수 있어요. Microsoft가 최근 발표한 자료에 따르면, 복잡한 웹앱일수록 내부적으로 여러 창이나 작업 스레드가 서로 메시지를 주고받는데, 바로 이 과정에서 병목현상이 생긴다고 하더라구요.

실제로 Google의 Web Vitals 통계를 보면, 사용자들이 체감하는 페이지 반응 속도(INP)가 200밀리초를 넘어가면 이탈률이 급격히 증가한다고 해요. Microsoft는 바로 이 문제를 해결하기 위해 새로운 API를 제안했습니다.

Microsoft가 웹 성능에 진심인 이유

Microsoft는 Edge 브라우저를 통해 웹 생태계를 개선하는 데 꾸준히 투자해왔어요. 그들의 접근 방식은 세 가지로 나뉘는데요.

첫째, Edge 브라우저 자체를 더 빠르고 반응성 좋게 만들기. 둘째, 브라우저 엔진이 복잡한 웹앱을 더 효율적으로 실행하도록 개선하기. 셋째, 개발자들이 더 빠른 웹앱을 만들 수 있도록 도구를 제공하기.

특히 세 번째가 중요한데요. 아무리 브라우저가 빨라도 웹앱 자체가 비효율적으로 설계되면 결국 사용자 경험은 나빠질 수밖에 없거든요. 그래서 이번에 제안된 게 바로 Delayed Message Timing API예요. 2024년 말 기준으로 Edge 브라우저는 전 세계 브라우저 시장에서 약 11%의 점유율을 차지하고 있는데, Microsoft는 이 플랫폼을 통해 웹 표준 개선에 적극적으로 참여하고 있어요.

복잡한 웹앱의 숨은 구조

요즘 웹앱들은 겉보기엔 하나의 화면처럼 보여도, 속을 들여다보면 여러 개의 컨텍스트가 동시에 돌아가고 있어요. 메인 창, 여러 개의 iframe, 백그라운드에서 돌아가는 워커 스레드까지.

예를 들어볼게요. 구글 독스 같은 협업 도구를 생각해보세요. 당신이 문서를 편집하는 동안, 백그라운드에서는 자동 저장 워커가 돌고, 다른 사람의 수정사항을 실시간으로 받아오는 워커도 있고, 맞춤법 검사하는 워커도 따로 있을 수 있어요.

이런 구조에서 각 컨텍스트들은 postMessage API를 통해 서로 정보를 주고받는데, 바로 여기서 문제가 생길 수 있다는 거죠. 메시지가 많아지면 대기 시간이 길어지고, 결국 앱이 버벅거리게 돼요. 최근 웹 아키텍처 리포트에 따르면, 현대적인 SPA(Single Page Application)는 평균적으로 3~5개의 워커 스레드를 동시에 활용한다고 하더라구요.

지연의 첫 번째 원인: 받는 쪽이 바쁠 때

상황을 이렇게 상상해보세요. 당신이 친구한테 카톡을 보냈는데, 친구가 마침 중요한 회의 중이라 한참 뒤에야 답장이 온다면? 웹앱에서도 똑같은 일이 벌어져요.

메인 창에서 워커 스레드로 메시지를 보냈는데, 그 워커가 마침 복잡한 계산 작업을 하느라 스레드가 막혀있으면 메시지는 대기열에 쌓일 수밖에 없어요. 동기적으로 실행되는 긴 작업이 끝날 때까지 말이죠.

문제는 이게 얼마나 지연되는지 개발자가 정확히 알 방법이 없었다는 거예요. 그래서 Microsoft는 blockedDuration이라는 속성을 추가했어요. 이걸 보면 메시지가 대기열에서 얼마나 기다렸는지 정확히 알 수 있죠.

Stack Overflow의 2024년 개발자 설문조사에 따르면, 웹 개발자의 73%가 성능 디버깅에 가장 많은 시간을 쓴다고 답했어요. 이런 도구가 얼마나 절실했을지 상상이 가시죠?

지연의 두 번째 원인: 작업 대기열 정체

이번엔 조금 다른 상황이에요. 각각의 작업은 짧은데, 너무 많이 몰려서 문제가 되는 경우죠.

웹페이지의 메인 스레드는 정말 바빠요. 사용자가 버튼을 클릭하면 그 이벤트를 처리해야 하고, 네트워크에서 데이터가 오면 받아야 하고, 페이지 렌더링도 해야 하고. 이런 우선순위 높은 작업들이 계속 들어오면 메시지 처리는 자꾸 밀려나게 돼요.

워커 스레드에서도 비슷한 일이 생겨요. 짧은 시간에 메시지가 쏟아지면 처리 속도보다 들어오는 속도가 빨라서 적체가 생기는 거죠. 마치 좁은 고속도로에 차가 몰리는 것처럼요.

이런 상황을 진단하기 위해 API는 taskCount와 scriptTaskCount 속성을 제공해요. 메시지가 처리되기 전에 몇 개의 작업이 앞에 있었는지 알 수 있죠. Chrome의 성능 모니터링 데이터를 보면, 작업 대기열에 10개 이상의 작업이 쌓이면 사용자가 체감하는 지연이 기하급수적으로 증가한다고 하더라구요.

지연의 세 번째 원인: 직렬화의 무게

이건 좀 기술적인 얘기인데요. 컨텍스트 간 경계를 넘어갈 때, 메시지는 반드시 직렬화(serialization)와 역직렬화(deserialization) 과정을 거쳐야 해요.

쉽게 말하면, 메시지를 보낼 때 데이터를 포장하고, 받을 때 다시 풀어야 한다는 거예요. 이 과정이 동기적으로 일어나기 때문에, 보내는 쪽과 받는 쪽 스레드가 잠깐씩 멈출 수밖에 없어요.

특히 무거운 데이터를 postMessage로 보낼 때 이 오버헤드가 눈에 띄게 느껴져요. 예를 들어 대용량 JSON 객체나 이미지 데이터를 보낸다면 말이죠.

이건 브라우저 내부 동작이라 개발자가 직접 바꿀 순 없어요. 하지만 Delayed Message Timing API는 serialization과 deserialization 속성을 통해 정확한 소요 시간을 측정할 수 있게 해줘요. 최소한 문제의 원인이 여기 있는지는 알 수 있는 거죠. 웹 성능 벤치마크 연구에 따르면, 대용량 객체의 직렬화 과정이 전체 메시지 전송 시간의 30~40%를 차지할 수 있다고 해요.

실제로 어떻게 쓰나요?

이 API는 정말 다양한 상황에서 쓸 수 있어요. 창(window), 탭(tab), iframe, 워커(worker) 모두 지원하구요. 문서 간 메시징, 워커-문서 메시징, 채널 메시징, 브로드캐스트 채널까지 커버해요.

완전한 왕복 시간 분석을 하려면, 보내는 쪽과 받는 쪽 양쪽에서 Performance 엔트리를 수집해서 연결해야 해요. Microsoft는 이를 위한 자세한 설명서(explainer)도 함께 공개했어요.

실무에서는 이런 식으로 쓰게 될 거예요. Performance API를 통해 메시지 타이밍 정보를 가져오고, blockedDuration이 임계값을 넘으면 경고를 띄우거나 로그를 남기는 식이죠. 그리고 taskCount를 보면서 작업 대기열 관리를 개선하고, serialization 시간이 길면 데이터 구조를 최적화하는 거예요.

웹 개발 커뮤니티의 반응도 뜨겁더라구요. Reddit의 webdev 커뮤니티에서는 이미 이 API를 실제 프로젝트에 적용해보려는 개발자들의 토론이 활발하게 이뤄지고 있어요. GitHub에서도 관련 오픈소스 프로젝트들이 생겨나고 있구요.

성능 최적화, 이제 추측이 아닌 측정으로

지금까지 웹 개발자들은 성능 문제를 해결할 때 많이 답답했을 거예요. "분명히 어딘가에서 병목이 생기는데, 정확히 어디서, 왜 그런지 모르겠다"는 상황이 많았거든요.

Delayed Message Timing API는 바로 이 안개를 걷어내는 도구예요. 추측이 아니라 정확한 측정을 통해, 성능 문제의 근본 원인을 찾아낼 수 있게 해주죠.

2024년 웹 성능 리포트에 따르면, 성능 모니터링 도구를 적극적으로 활용하는 기업들은 그렇지 않은 곳보다 평균 로딩 시간을 40% 이상 단축했다고 해요. 도구의 힘이 이렇게 큰 거죠. 특히 e-커머스 업계에서는 페이지 로딩 속도가 1초 개선될 때마다 전환율이 평균 7% 증가한다는 연구 결과도 있어요.

복잡한 웹앱일수록 내부적으로 많은 일들이 동시에 벌어지고 있어요. 메시지들이 오가고, 작업들이 대기하고, 데이터가 변환되죠. Microsoft의 Delayed Message Timing API는 이 모든 과정을 투명하게 보여줌으로써, 개발자들이 더 빠르고 반응성 좋은 웹앱을 만들 수 있도록 돕고 있어요. 웹이 더 빨라진다는 건, 결국 우리 모두에게 더 나은 경험이 돌아온다는 뜻이니까요.