LINE Corporation이 2023년 10월 1일부로 LY Corporation이 되었습니다. LY Corporation의 새로운 기술 블로그를 소개합니다. LY Corporation Tech Blog

Blog


2022년 웹 개발에서 고려해야 할 환경

 TL;DR: 2022년 웹 개발에서 고려해야 할 환경은, 성능 측면에서는 저사양의 Android 기기, 웹 표준 측면에서는 2년 전의 Safari, 네트워크 측면에서는 4G입니다. 웹은 대체적으로 이와 같은 니즈에 적절히 대응하지 못하고 있습니다. 특히 성능 관점에서 JavaScript에 과도하게 의존하는 것과 같은 요소들이 웹 사이트의 성능을 끌어내리고 있습니다. 

안녕하세요! LINE에서 프런트엔드 엔지니어로 일하고 있는 Alan Dávalos입니다. 이 글의 제목이 그저 클릭을 유도하려는 미끼라고 생각하실 수 있겠지만, 조금만 더 읽어주시길 바랍니다. 분명 읽을 만했다고 생각하실 겁니다. 2021년과 2022년 사이에 웹에는 몇 가지 큰 변화가 있었는데요. 이 변화가 전반적인 웹 개발 방식에 영향을 미치고 있습니다. 그래서 저는 이번 글에서 다양한 데이터를 분석하며 어떤 변화가 있었는지 알아보고, 웹 개발자로서 이런 변화에 어떻게 적응해야 하는지 말씀드리려고 합니다. 

2021년의 가장 큰 변화 - Internet Explorer의 은퇴

2021년에 많은 변화가 있었지만 Internet Explorer(이후 IE)의 공식 은퇴만큼 중대한 변화는 없었습니다. Microsoft는 2021년 5월에 관련 소식을 발표했고, 8월부터는 Microsoft 365를 포함한 많은 Microsoft 제품에서 IE 지원을 공식적으로 중단했습니다. IE의 공식 은퇴 날짜는 2022년 6월로 예정되어 있지만, 이미 IE가 은퇴한 것이라고 간주해도 될 만한 몇 가지 이유가 있습니다.

웹에서 가장 큰 몇몇 사이트에서 IE 지원 중단

Microsoft의 발표 후 많은 프로젝트에서 IE 지원을 중단하기 시작했습니다. 그중에는 대부분의 인터넷 사용자가 이용하는 사이트도 있었는데요. 예를 들어 Google Search는 2021년 10월에 IE 지원을 중단했습니다(참고).

A tweet from October 2nd, 2021 by Principal Software Engineer and Engineering Director Malte Ubl mentioning Google search dropped support for IE.
Twitter @cramforce

일본에서는 2021년 9월에 Yahoo! JAPAN이 IE는 더 이상 권장하지 않는 브라우저라고 발표했습니다. 

An excerpt from Yahoo! JAPAN's page regarding their recommended browsers. The next quote has a full translation.

Yahoo! JAPAN은 Internet Explorer 11을 권장하는 브라우저로 설정하고 있습니다. 하지만 Internet Explorer 지원을 종료한다는 Microsoft의 발표에 따라 Yahoo! JAPAN에서도 2021년 9월 7일부터 Internet Explorer 11을 권장하지 않는 브라우저로 설정하기로 결정했습니다.
Internet Explorer 11을 사용해 일부 서비스를 이용할 수는 있지만 페이지가 제대로 동작하지 않거나 렌더링되지 않는 문제가 발생할 수 있습니다. Internet Explorer 11의 공식 지원 종료일이 다가오고 있으므로 Internet Explorer 11을 사용하는 모든 사용자에게 당사가 권장하는 브라우저를 사용할 것을 권장합니다. 

또한 약 33%의 웹에서 사용하고 있는 WordPress도(참고) 2021년 7월에 릴리스한 WordPress 5.8 버전부터 IE 지원을 중단한다고 발표했습니다.

When WordPress 5.8 is released in July of this year, Internet Explorer 11 will no longer be supported.

현재 IE의 시장 점유율

위와 같은 발표들이 IE의 공식 은퇴 날짜 이전에 나온 데에는 그만한 이유가 있습니다. IE의 시장 점유율은 2021년 내내 급격히 줄어들었습니다. 

A pie chart for the global browser market share in November 2021. A more detailed explanation is below.
Statcounter의 Browser Market Share Worldwide의 파생 그래프로 CC BY-SA 3.0에 따라 사용했습니다. 위 그래프는 Alan Dávalos에 의해 CC BY-SA 3.0 라이선스를 따릅니다.
A pie chart for the Japanese browser market share in November 2021. A more detailed explanation is below.
Statcounter의 Browser Market Share Japan의 파생 그래프로 CC BY-SA 3.0에 따라 사용했습니다. 위 그래프는 Alan Dávalos에 의해 CC BY-SA 3.0 라이선스를 따릅니다.

현재 IE의 글로벌 시장 점유율은 0.5% 이하이며, IE의 점유율이 다른 나라에 비해 높은 일본에서도 2% 정도로 하락세를 보이고 있습니다. 

웹 개발의 새로운 베이스라인

지금까지는 시장 점유율 때문에 IE를 계속 지원해 왔지만 이제 그래야 할 이유가 사라졌습니다. 하지만 그동안 많은 툴에서 IE가 지원 베이스라인이었기 때문에 새로운 문제가 발생했습니다. IE 개발은 대부분 오래전에 중단됐는데요. 따라서 지원하는 웹 표준이 최신 브라우저에서 지원하는 웹 표준과 많이 다릅니다. 이런 IE가 떠나면서 베이스라인이 흐릿해졌습니다. 이에 제가 사용자 기기의 현재 상태를 분석해서 새로운 베이스라인을 정의해 보려고 합니다. 

사용자 기기와 브라우저

브라우저와 OS의 시장 점유율

브라우저의 시장 점유율을 앞서 보여드린 것과 다른 형식의 차트로 살펴보겠습니다. 

A bar chart for the global browser market share in November 2021. A more detailed explanation is below.
Statcounter의 Browser Market Share Worldwide의 파생 그래프로 CC BY-SA 3.0에 따라 사용했습니다. 위 그래프는 Alan Dávalos에 의해 CC BY-SA 3.0 라이선스를 따릅니다.
A bar chart for the Japanese browser market share in November 2021. A more detailed explanation is below.
Statcounter의 Browser Market Share Japan의 파생 그래프로 CC BY-SA 3.0에 따라 사용했습니다. 위 그래프는 Alan Dávalos에 의해 CC BY-SA 3.0 라이선스를 따릅니다.

위 차트에서 발견할 수 있는 두 가지 경향을 강조하고 싶습니다. 

  • 우리가 지원해야 할 브라우저 엔진은 세 가지다.
    1. Chromium: Chrome, Edge, Samsung Internet Browser, Opera의 기반 엔진
    2. Gecko: Firefox의 기반 엔진
    3. Webkit: Safari의 기반 엔진
  • 일본은 Safari 사용자 비율이 글로벌 평균보다 높다. 

위 항목 중 두 번째 사항은 아래 차트를 보면 쉽게 알 수 있습니다. 

A pie chart for the global mobile OS market share in November 2021. A more detailed explanation is below.
Statcounter의 Mobile Operating System Market Share Worldwide의 파생 그래프입니다. CC BY-SA 3.0에 따라 사용했으며, 위 그래프는 Alan Dávalos에 의해 CC BY-SA 3.0 라이선스를 따릅니다.
A pie chart for the Japanese mobile OS market share in November 2021. A more detailed explanation is below.
Statcounter의 Mobile Operating System Market Share Japan의 파생 그래프입니다. CC BY-SA 3.0에 따라 사용했으며, 위 그래프는 Alan Dávalos에 의해 CC BY-SA 3.0 라이선스를 따릅니다.

글로벌 모바일 OS 시장에서는 Android가 약 70%를 차지하고, iOS가 약 28%를 차지합니다. 반면 일본에서는 iOS가 약 66%를 차지하고, Android는 33% 정도에 그칩니다. 

CPU 성능의 차이

OS의 차이는 소프트웨어 측면에서뿐 아니라 하드웨어 측면도 포함합니다. 하드웨어 측면에서 가장 많이 고려해야 할 부분은 CPU의 성능입니다. 

위 차트에서 볼 수 있듯이 iOS 기기는 지난 10년 동안 매년 가장 좋은 CPU 성능 점수를 기록했습니다. 그에 비해 Android 기기는, 상급 기종에서는 어느 정도 비슷한 점수를 받았지만 중급이나 하급 기종에서는 그에 훨씬 못 미치는 점수를 기록했습니다. 위 두 차트 기사의 작성자인 Alex Russel의 말을 인용하면 다음과 같습니다. 

2020년의 하이엔드 Android 기기는 2017년 3분기에 출시된 iPhone 8의 싱글 코어 성능을 자랑하고,
중가 Android 기기는 2014년에 출시된 iPhone 6보다 약간 더 빠르며,
저가형 Android 기기는 2012년에 출시된 iPhone 5를 마침내 따라잡았습니다.

웹 표준을 기준으로 브라우저 정렬

서로 다른 브라우저가 웹 개발에 가장 큰 영향을 미치는 부분은 서로 다른 웹 표준을 구현하는 것입니다. 앞서 언급한 것처럼 우리가 신경 써야 할 세 가지 브라우저 엔진이 있는데요. 각 브라우저가 어떻게 웹 표준을 구현했는지 살펴보려고 합니다. 가장 쉬운 방법은 Web Platform Tests(이하 WPT) 데이터를 확인해 보는 것입니다.

A bar chart comparing the number of tests failed in only one browser. A more detailed explanation is below.
출처: Browser Specific Failures, 2021년 12월 4일 기준

이 차트는 세 브라우저 중 어떤 한 브라우저에서만 실패한 WPT 실패 수를 보여줍니다. 즉, 특정 브라우저는 구현하지 못했지만 다른 두 브라우저는 이미 구현한 기능의 수를 알 수 있는데요. 한 가지 분명한 사실은 Safari만 구현하지 않은 웹 표준의 수가 Firefox나 Chrome만 구현하지 않은 웹 표준의 수보다 몇 배나 많다는 것입니다. Safari가 구현하지 않은 웹 표준의 수는 Firefox의 약 2.4배, Chrome의 약 4.7배입니다. 

또한 Safari는 iOS와의 긴밀한 관계도 고려해야 합니다. 구체적으로 다음 두 가지 사항을 들 수 있습니다.

  • 다른 모바일 브라우저는 OS와 독립적으로 업데이트되지만 Safari는 iOS가 업데이트될 때만 업데이트됩니다. 최신 버전의 iOS에서 더 이상 지원하지 않는 기기는 최신 버전의 Safari로 업데이트할 수 없습니다. 
  • iOS의 모든 브라우저는 Webkit 기반입니다. Chrome과 Firefox에는 iOS 용 버전이 있지만, 이들 또한 iOS의 Safari와 같은 엔진을 사용하고 있습니다. 이는 모든 iOS 브라우저에서는 Webkit을 사용해야 한다는 Apple의 지침 때문입니다. 

iOS와 Safari의 이러한 관계는 주요 iOS 버전이 새로 출시될 때마다 iOS 버전의 시장 점유율이 어떻게 변하는지 확인해야 한다는 것을 의미합니다. 

A line chart showing the quarterly variation in market share for iOS major versions from 2019 to 2021. A more detailed explanation is below.
Statcounter의 Mobile & Tablet iOS Version Market Share Worldwide의 파생 그래프로 CC BY-SA 3.0에 따라 사용했으며, 위 그래프는 Alan Dávalos에 의해 CC BY-SA 3.0라이선스를 따릅니다.

iOS 버전에 따라 시장 점유율이 어떻게 변하는지 더 깊이 이해하기 위해 지난 2년 동안 iOS 12의 시장 점유율이 어떻게 변해왔는지 살펴봤습니다. 

  • 2019년 1분기부터 3분기까지 iOS 12의 점유율은 점차 증가했지만, 3분기에 iPhone 11과 iOS 13이 출시되면서 점유율이 급감했습니다. 
  • 그 다음 해에 iOS 12의 점유율은 20% 아래로 떨어졌습니다.
  • 2020년 3분기에 iPhone 12와 iOS 14가 출시되자마자 iOS 12의 점유율은 급격히 하락해 2021년 2분기에는 미미한 수준이 되었습니다.
  • iOS 12의 이와 같은 점유율 패턴은 iOS 13과 14에서도 관찰할 수 있었습니다. 

결론적으로, 앞으로 iOS 시장 점유율의 90% 이상은 지난 2년간 출시된 주요 버전으로 구성될 것이라고 안심하고 가정할 수 있습니다. 즉, 최근 2년 이내에 출시된 Safari 버전만 지원하면 되는 것입니다. 

모바일 네트워크

지금까지 주로 기기와 브라우저에 대해 이야기했습니다. 이제 웹 개발자의 영향이 미치지 않으면서 UX에 큰 영향을 주는 요소 중 하나인 네트워크 연결에 대해 이야기해 보겠습니다. Wi-Fi 네트워크에 연결한다면 대부분의 연결이 안정적일 테지만, 모바일 네트워크도 그렇다고 말할 수는 없습니다. 먼저 모바일 네트워크의 현재 상황을 살펴보겠습니다. 

3G와 4G

Lighthouse와 같은 툴을 사용하면 네트워크를 3G로 시뮬레이션하도록 테더링되긴 하지만, 최근 모바일 네트워크는 전 세계적으로 바뀌고 있습니다. Opensignal에서 2020년 5월에 발간한 리포트에 따르면 글로벌 4G 가용성은 약 86.8%입니다. 따라서 대부분의 사용자가 4G 네트워크에 접속할 수 있다고 안심하고 가정할 수 있습니다. 일본은 4G 가용성이 약 98.5%로 테스트한 국가 중에서 가장 높았습니다.

5G

반면 5G 네트워크는 아직 많이 현실화되지 않았습니다. Opensignal이 2021년 11월에 발간한 리포트에 따르면 전 세계에서 5G 가용성이 가장 높은 한국에서도 약 29.1%에 그쳤습니다. 

그럼 새로운 베이스라인은 무엇일까요

위에서 말씀드린 데이터를 모두 고려한 웹 개발의 새로운 베이스라인은 다음과 같습니다. 

  • Safari는 웹 표준 관점에서의 베이스라인입니다. 우리가 개발하는 사이트는 적어도 2년 이상 지난 Safari에서 동작해야 합니다. 
  • Android 하위 기종은 성능 관점에서의 베이스라인입니다. Android 하위 기종은 지난 몇 년간 그다지 발전하지 않았기 때문에 그에 맞추려면 우리가 만드는 사이트의 성능이 매우 좋은지 확인해야 합니다. 
  • 4G는 네트워크 관점에서의 베이스라인입니다. 최근 몇 년 동안 모바일 네트워크는 전 세계적으로 훨씬 더 빠르고 안정적으로 발전했습니다.   

우리는 사용자의 요구에 얼마나 잘 대응하고 있을까요?

베이스라인을 구성하는 세 부분을 성공적으로 정의했지만 그것만으로는 충분하지 않습니다. 우리가 사용자의 요구에 얼마나 잘 대응하고 있는지 살펴봐야 합니다. 심층적으로 분석하면 각 프로젝트마다 결과가 다를 것이기 때문에 LINE에서 진행하는 특정 프로젝트에 대해 이야기하는 것은 대부분의 사람들에게 별로 도움이 되지 않을 것 같습니다. 이 점을 고려해 웹 전체를 분석해 보려고 하는데요. 운 좋게도 Web Almanac 2021이라는 훌륭한 데이터 소스가 있습니다. HTTP Archive에서 만드는 연간 리포트로, 약 820만 개의 사이트를 24개의 챕터로 나누어 분석해 놓은 리포트입니다. 앞서 정의한 기준에 현재 웹이 얼마나 잘 부합하고 있는지 알아보기 위해 이 리포트의 여러 챕터에서 몇몇 데이터를 발췌해 살펴보겠습니다.  

2021년 웹 사이트 크기의 중앙값

2021년에 웹 사이트 크기의 중앙값은 1,923KB였습니다. 크기를 아래와 같이 파일 유형별로 분류하면 이미지와 JavaScript(이하 JS)가 대부분을 차지하고 있다는 것을 알 수 있습니다. 

이 데이터를 보면 이미지가 가장 큰 것으로 나오기 때문에 이미지에 집중하기 쉽지만, 사실 JS에 주의를 기울여야 합니다. 그 이유는 이미지 처리는 JS 처리만큼 복잡하지 않기 때문입니다. 이미지는 기본적으로 다운로드하는 즉시 렌더링할 수 있지만 JS는 구문을 분석한 뒤 실행해야 하기 때문에 일반적으로 JS 처리가 더 많은 리소스를 소비합니다.  

또한 위에서 언급했던 Alex Russell의 기사를 보면 4G 네트워크에서 Android 하위 기종을 테스트할 때 웹 사이트가 좋은 성능을 유지하기 위한 적정 크기는 HTML과 CSS는 최대 100KB, 그리고 JS는 최대 350KB입니다. 현재 중간값을 살펴볼 때 HTML과 CSS는 기준을 충족하지만 JS는 넘어서고 있습니다. 

HTML과 CSS 사용

Web Almanac 리포트의 markup과 CSS 챕터에는 많은 정보가 담겨 있는데요. 그중에서 현재 HTML과 CSS를 어떻게 사용하고 있는지 예시를 살펴보는 데 도움이 될 만한 몇 가지 주요 데이터를 확인해 보겠습니다. 

HTML

먼저 HTML에 대해서 이야기해 보겠습니다. 현재 'deprecated'되지 않은 HTML 엘리먼트는 112개인데요(참고). 웹 페이지에서 사용하는 HTML 엘리먼트 개수의 중앙값은 31개입니다. 물론 모든 페이지에서 각 엘리먼트를 전부 사용할 필요는 없습니다. 하지만 앞서 말씀드린 31개 엘리먼트에는 <html>과 <body><script>와 같은 엘리먼트도 포함돼 있기 때문에 실제로 표시하는 데 사용하는 엘리먼트의 수는 더 적을 것입니다. 

가장 많이 사용하는 HTML 엘리먼트 순위에서 <div>가 1위를 차지하고 있고, <span>이 3위, <p>가 7위를 차지하고 있습니다. 페이지에 <div> 엘리먼트가 있을 확률은 약 98.9%입니다. 콘텐츠를 표시하기 위해 가장 많이 사용하는 엘리먼트라고 할 수 있습니다. 

반면 <main> 엘리먼트가 사용될 확률은 약 27.9%입니다. 이 사실이 중요한 이유는 <aside>나 <header>처럼 <main> 엘리먼트는 특별한 스타일이 적용되지는 않지만 시맨틱 관점의 의미가 있는 엘리먼트 중 하나이기 때문입니다. 다시 말하자면, <main>의 사용률은 얼마나 많은 웹 페이지가 시맨틱 엘리먼트를 적극적으로 사용하고 있는지 가늠할 수 있는 지표입니다. 

CSS

CSS 사용에 관해서는 이에 대해 아주 잘 요약한 데이터가 하나 있습니다. 최신 레이아웃 기능인 Flex와 Grid의 채택률입니다. 

보시다시피 웹 페이지의 71%에서 Flex를 사용하고 있는 반면에 Grid는 8%에 불과합니다. 이런 결과가 나온 가장 큰 이유는 IE 지원입니다. IE에서 Grid의 오래전 사양 밖에 지원하지 않기 때문에(참고) IE를 지원하려는 웹 페이지는 이를 고려할 수밖에 없습니다. CSS 기능은 JS 기능만큼 쉽게 폴리필(polyfill)할 수 없기 때문에 아마도 이 점이 많은 개발자들이 Grid를 포기하게 만드는 가장 큰 이유가 될 것입니다. 하지만 이제 IE 지원을 중단할 수 있으므로 Grid를 포함해 많은 최신 CSS 기능을 사용할 수 있습니다. 

성능

최근 가장 널리 사용되는 성능 측정 방법은 Core Web Vitals(CWV)입니다. 여러 이유가 있겠지만 Google Search에서 검색 순위 요소로 사용하고 있다는 점이 가장 큰 이유일 것입니다(참고). 현재 웹이 CWV에서 어느 정도의 성적을 받고 있는지 확인해 보겠습니다. 

전반적으로 성능이 좋지 않았습니다. 웹 페이지의 절반 이상이 좋지 않은 CWV 점수를 받았습니다. 기기 간의 CPU 성능 차이를 고려하면, 위 차트에서 모바일이 데스크톱보다 12% 낮은 것은 납득할 수 있습니다. 이 결과는 대부분의 웹 사이트에서 JS의 크기가 적정 수준보다 더 크다는 사실과도 일치합니다.  

다음 차트를 보면 성능이 사용자 수에 직접적인 영향을 미친다는 것을 알 수 있습니다. 

이 차트를 통해 CWV 점수와 조회 수 사이에 상관관계가 있다는 것을 알 수 있습니다. 아마도 CWV가 Google Search의 검색 순위 요소라는 사실에 부분적으로 영향을 받았을 것입니다. 조회 수 기준 상위 1,000개 웹 사이트의 CWV 점수는 37%인 반면 전체 CWV 점수는 32%입니다. 상위 10,000개 또는 100,000개를 보면 조회 수 순위가 더 높은 웹 사이트들이 더 성능이 좋은 경향이 있다는 것을 알 수 있습니다. 성능 향상이 프로젝트의 수익을 직접 증가시킬 수 있는 방법 중 하나라고 해도 과언이 아닙니다. 

JS 라이브러리와 프레임워크

지금까지 JS의 크기가 사이트의 성능에 얼마나 나쁜 영향을 미치는지 확인해 보았습니다. 대용량의 JS를 사용하는 대부분의 프로젝트는 어느 방식으로든 라이브러리나 프레임워크를 사용할 텐데요. 이런 선택이 어떤 결과를 가져오는지 확인해 보겠습니다. 

JS 라이브러리와 프레임워크 사용률

Web Almanac 리포트의 JS 챕터를 보면 가장 많이 사용되는 라이브러리는 84%의 사용률을 기록한 jQuery입니다. 앞서 언급했던, 웹 사이트의 33%가 WordPress를 사용한다는 사실이 이런 결과가 나온 주요 이유 중 하나일 것입니다. 

프레임워크 중에서는 React가 8%로 가장 인기가 많았지만, 다른 프레임워크의 사용률이 4%도 되지 않는 것을 고려하면 프레임워크 사용은 소수라고 해도 될 것 같습니다.

프레임워크 성능 비교

프레임워크 사용이 많지는 않지만, 널리 사용되는 프레임워크들은 관련 데이터가 충분하기 때문에 이들 간의 성능을 비교해 볼 수 있습니다. 이 섹션의 데이터는 Tim Kadlec의 2020년 기사에서 발췌했습니다.  

React와 Angular, Vue, jQuery를 사용한 웹 사이트의 JS 크기를 일반 데이터와 비교해 보겠습니다. 

  • 전체 데이터의 중앙값은 414KB이고 jQuery의 중앙값은 430KB입니다. 이 숫자는 2021년 웹 사이트 크기의 중앙값과 비슷합니다. 
  • Vue와 React의 중앙값은 모두 690KB 근처입니다. 전체의 중앙값보다 250KB만큼 더 큽니다. 
  • Angular의 중앙값은 1,066KB로 훨씬 큽니다. 1MB가 넘는 첫 번째 숫자입니다. 
  • 10번째 백분위수를 봐도 유사한 결과가 나옵니다. 전체 데이터의 10번째 백분위수는 93KB이고, jQuery는 110KB, Vue는 245KB, React는 348KB, Angular는 445KB입니다.
  • 다시 말해 가장 작은 JS를 포함한 프레임워크를 사용하는 웹 사이트도 앞서 말씀드린 적정 크기를 만족시키는 것은 어렵습니다.  

당연한 얘기지만, JS 크기가 성능을 나타내는 중요한 지표이긴 하지만 그것만 가지고 성능을 얘기할 수는 없습니다. 따라서 이 웹 사이트들이 실제 기기에서는 어떨지 몇 가지 데이터와 함께 살펴보겠습니다. 

  • 최대한 공정하게 비교하기 위해 여러 라이브러리나 프레임워크를 사용한 웹 사이트는 포함시키지 않았습니다.
  • 위 차트에서 jQuery와 Vue의 중간값을 보면 각각 2.3초와 3.2초입니다. 간단한 계산으로 크기 비율이 시간 비율과 비슷하다는 것을 알 수 있습니다. 
  • 하지만 React와 Angular는 위와 같은 경향이 나타나지 않습니다. Angular의 중간값은 3.7초이고 React는 10.1초로 몇 초 더 느립니다.
  • JS 라이브러리를 비교할 때 크기만이 유일하게 중요한 척도가 아니라는 것이 분명합니다. 

정적 웹 사이트에서의 프레임워크 성능 비교

프레임워크는 주로 SPA(Single Page Applications)를 만드는 데 사용하지만 정적 사이트를 만들 때도 사용합니다. 프레임워크를 사용하는 SSG(Static Site Generators)와 프레임워크를 사용하지 않는 SSG의 성능을 비교해 보겠습니다. 실제로 사용량을 알아볼 수 있는 상위 5개 SSG(참고)를 비교하려고 합니다. 

  • React 기반인 Gatsby와 Next.js의 중앙값, 그리고 Vue.js 기반인 Nuxt.js의 중앙값은 모두 약 700KB입니다. 이 수치는 일반적인 React와 Vue의 중앙값과 비슷합니다.
  • 이에 비해 Go 기반 Hugo와 Ruby 기반 Jekyll의 중앙값은 각각 177KB와 129KB입니다. 
  • JS 프레임워크 기반 SSG는 JS를 기반으로 하지 않는 SSG보다 중앙값 기준으로 500KB가 넘는 JS를 더 서빙하고 있습니다.

앞서 성능 관점에서 JS의 크기가 전부가 아니라고 말씀드렸으므로 모바일 웹 사이트의 CWV 점수 차이를 살펴보겠습니다. 

  • Next.js와 Nuxt.js는 CWV 점수가 15% 미만입니다.
  • Gatsby는 21.9%로 다른 React 기반 Next.js보다 높습니다. 
  • 프레임워크 기반이 아닌 Hugo와 Jekyll은 각각 31.8%와 34.3%를 기록했습니다. 
  • JS 프레임워크를 사용하지 않은 SSG는 전체 평균보다 CWV 점수가 높았습니다. 

랩 테스트에서의 프레임워크 성능 비교

지금까지 가장 널리 쓰이는 세 가지 프레임워크의 데이터를 살펴보며 성능을 비교해 봤습니다. 하지만 이 세 가지 프레임워크 외에도 많은 프레임워크가 있습니다. 이를 고려해 Web Almanac에 올라올 만큼 많이 사용되지는 않았지만 그래도 널리 쓰인다고 할 수 있는 프레임워크들을 앞서 말씀드린 세 가지 프레임워크와 비교해 보겠습니다. 

비교에 사용한 데이터는 랩 테스트 데이터입니다. 실제 프로젝트에서의 성능은 다를 수 있습니다. 또한 비교에 추가한 프레임워크는 제가 생각하기에 가장 모멘텀이 좋다고 판단한 프레임워크들이며, 데이터 출처로 이동하면 다른 프레임워크와 비교한 것을 볼 수 있습니다.

위 표는 주요 세 가지 카테고리인 DOM 조작과 시작, 메모리 할당에서 수동으로 최적화한 바닐라 JS와 비교한 결과입니다.

  • React와 Angular는 바닐라 JS보다 2배 더 나쁜 성능을 보였습니다. 
  • 이와 비교해 Vue는 1.5배 더 나쁜 성능으로 Preact와 Stencil과 비슷했습니다. Web Almanac 리포트 내용과 다른 결과가 나온 주 요인은 Vue 버전 3.0이 릴리스되면서 성능이 향상됐기 때문입니다.
  • 마지막으로 Solid와 Lit, Svelte는 모두 1.2배로 바닐라 JS에 가까운 성능을 보였습니다. 

이 결과에는 IE가 영향을 끼쳤습니다. '여기서 왜 IE가 나오나요?'라고 물을 수 있습니다. 이를 설명하기 위해서 프레임워크와 JS 표준의 역사를 살펴보겠습니다. 

Edge가 출시된 2015년은 IE가 대부분의 파트에서 새로운 개발을 중단한 시점이라고 할 수 있습니다. 그 해는 ES 2015(또는 ES6) 표준이 나온 해이기도 합니다. 이는 틀림없이 JS 역사에서 가장 큰 혁명이었습니다. ES 2015에는 promise나 화살표(=>) 함수와 같은 기능이 포함됐습니다. 이후 버전에서는 더 적은 코드로 더 많은 것을 할 수 있는 기능들이 또다시 JS에 추가됐습니다. 즉, ES 2015 이전 세계를 위해 개발된 것은 ES 2015 이후에 개발된 것과 많이 다르다고 할 수 있습니다.

위 표에서 성능 측면에서 가장 좋지 않았던 것은 Angular와 React입니다. 이 둘은 Vue와 함께 2015년 이전에 첫 번째 릴리스가 있었던 유일한 프레임워크입니다. 즉, 성능의 차이는 개발된 시대에 기인할 수 있습니다. 여기서 Vue가 빠진 이유는 앞서 언급한 것처럼 Vue는 3.0 버전에서 성능 향상을 위해 내부 코드를 많이 변경했기 때문입니다. 

앞서 언급한 차이를 이해하기 위한 또 하나의 방법이 있습니다. Solid와 Preact, React를 비교하는 것입니다. Solid와 Preact는 React의 영향을 많이 받았습니다. Preact의 경우 React 코드를 Preact 코드로 사용할 수 있는 호환성 모듈도 있습니다. 그러나 표를 보면 Solid와 Preact는 모든 항목에서 React를 능가하는 것으로 나타납니다. 이는 React의 성능 문제가 그 철학이나 React 용 코드 작성 방식에 있지 않다는 것을 의미합니다. 문제는 React 내부에 있습니다. 정확히 말하자면 IE를 지원하기 위한 많은 고려 사항이 들어간 React의 Virtual DOM과 합성 이벤트(synthetic event) 시스템 구현에 있습니다. 반면 Preact와 Solid의 성능 저하는 최신 브라우저에서 가용한 API 사용보다 디폴트를 선호하는 것이 가장 큰 원인일 것입니다.

마지막으로 차트를 하나 더 살펴보겠습니다. 

위 차트는 앞서 언급한 각 프레임워크로 30개의 컴포넌트를 생성했을 때의 번들 크기를 비교한 차트입니다. 이 비교를 통해 전체 애플리케이션을 만들 때 각 프레임워크가 작동하는 방식을 에뮬레이션할 수 있습니다.

  • React는 45.45KB로 또다시 가장 컸지만, 실제 개발자 코드 측면에서 보면 9.25KB로 가장 작았습니다. 그저 라이브러리 자체가 나머지보다 몇 배 더 큰 것입니다.
  • Vue는 3.0 버전에서 많이 개선됐지만 여전히 32.65KB로 다른 라이브러리보다 두 배 정도 컸습니다.
  • 나머지 프레임워크는 개발자 코드와 라이브러리 코드가 얼마나 묶이는지에 따라 달랐는데요. 모두 14~18KB 범위 내에서 비슷한 크기였습니다.

접근성

지금까지 사용자의 기기에 대해서 많은 이야기를 했는데요. 이제 사용자에 대해 이야기해 보겠습니다. 세계 보건 기구(World Health Organization)에 따르면 10억 명이 넘는 사람들이 장애를 갖고 있습니다(참고). 장애에는 다양한 종류가 있으며 그중 많은 장애가 사용자가 기기와 상호 작용하는 방식에 영향을 미칩니다. 장애를 갖고 있는 사용자가 해당 웹 사이트와 완전히 상호 작용할 수 있게 하는 조치를 우리는 접근성(accessibility, a11y)이라고 합니다.

그런데 접근성은 장애를 가진 사람들만을 위한 것이 아닙니다. 접근성을 개선하기 위한 조치는 모든 사용자를 위한 UX에 긍정적인 영향을 끼칩니다. 그 이유는 상황적 장애 때문입니다. 상황적 장애의 몇 가지 예를 들면, 한 손으로 무언가를 먹거나 마시면서 휴대폰을 사용하거나, 수면의 질을 개선하기 위해 특정 시간 후에는 기기 화면에 흑백 필터를 설정하는 것 등이 있습니다. 이러한 상황적 장애 상황에 놓인 사용자는 접근성을 위한 설계 덕분에 마치 평소와 같이 웹 페이지를 이용할 수 있습니다. 

또한 웹 페이지를 만들면서 접근성을 고려하지 않는다면 법적으로 문제가 발생할 수 있습니다. 법률에 따라서 사용자는 접근성을 고려하지 않은 웹 사이트를 고소할 수도 있습니다. 유명한 사례로 Beyonce와 Domino's Pizza가 시각 장애 사용자가 접근할 수 없다는 이유로 소송을 당한 사례가 있습니다(참고). 따라서 적절하게 접근성을 확보하지 않으면 많은 비용을 치러야 할 수도 있습니다. 

웹 페이지의 접근성은 어떠한가요?

이제 전반적인 웹 페이지의 접근성이 어느 정도인지 살펴보겠습니다. Web Almanac의 a11y 챕터에서 몇 가지 데이터를 살펴볼 텐데요. Web Almanac의 a11y 챕터에는 더욱 많은 데이터가 실려 있으니 더 자세하게 확인하고 싶다면 한 번 살펴보시기 바랍니다. 

  • 77.8%의 웹 사이트에서 배경과 글꼴의 색상 대비가 좋지 않았습니다. 즉, 일부 시각 장애가 있는 사용자와 위에서 언급한 것과 같은 필터를 사용하는 사용자는 거의 80%에 달하는 웹 사이트를 제대로 사용하지 못할 수 있습니다. 
  • 29.4%의 웹 사이트에서 확대 혹은 축소를 차단했습니다. 요즘 몇몇 브라우저에서는 이 설정을 무시하기도 하지만 그래도 여전히 높은 수치입니다.
  • 42%의 웹 사이트에서 제목을 부적절하게 정렬하고 있습니다. 예를 들어 h1 엘리먼트를 사용하기 전에 h2 엘리먼트를 사용하는 식입니다. 이와 같은 순서 문제는 특히 보조 기술을 이용하는 사용자에게 문제를 일으킬 수 있습니다. 
  • 29%의 웹 사이트에서 role="button"을 사용하고 있습니다. role과 클릭 리스너만 있으면 충분하다고 생각할 수 있지만, 버튼은 키보드 이벤트에도 응답해야 하며, 포커스도 적절하게 처리해야 합니다. JS로 처리할 수도 있지만 button 엘리먼트를 사용하면 JS 없이도 잘 처리할 수 있습니다.
  • 32.7%의 웹 사이트에 접근 레이블이 없는 input 엘리먼트가 있습니다. 즉 해당 input 엘리먼트와 관련된 label 엘리먼트나 aria-label 엘리먼트 등 있어야 할 무언가가 없습니다. 이는 수익 감소로 이어질 수 있기 때문에 우려되는 부분입니다. 예를 들어 신용 카드 입력란에 레이블을 붙이지 않으면 사용자가 무엇을 구매하고 싶어도 필요한 정보를 어디에 기입해야 하는지 모를 수 있습니다.

결론

자, 이제 성적표를 확인해 봅시다. 

  • 우리는 사용자의 요구에 적절히 대응하지 않았습니다. 특히 성능과 접근성 측면에서 그랬습니다.
  • 우리는 JS를 과도하게 사용했습니다. 의존성과 우리가 작성한 코드 모두에서 그랬습니다. 
  • 우리는 HTML과 CSS를 너무 적게 사용했습니다. 이런 결과는 부분적으로 IE를 지원하기 위해서였지만, 이제 IE를 지원할 필요가 없기 때문에 많은 기능을 사용할 수 있습니다.  

다음은 어떻게 개선해야 하는지 시작점을 잡고 싶은 사람을 위한 전반적인 팁입니다.  

  • 무언가를 CSS로 할 수 있다면 CSS를 사용하세요. 예전에는 JS로만 할 수 있었던 많은 일들을 요즘에는 CSS로도 할 수 있습니다. 이를 통해 JS 코드를 부분적으로 줄일 수 있습니다. 
  • 사용하고 있는 툴셋을 평가해 보세요. 최신의 많은 툴들은 예전 툴보다 성능 베이스라인을 높였으며, 또한 모든 프로젝트가 SPA일 필요는 없습니다. Hugo와 Jekyll, 11ty와 같은 프레임워크 기반이 아닌 SSG들이 이런 경우에 아주 적합합니다.
  • 최신 브라우저를 대상으로 빌드하세요. IE 지원을 중단하고 빌드 대상을 ES 2017 혹은 ES 2018로 설정합니다. 이렇게 하면 번들 크기를 최대 20%까지 줄일 수 있습니다. 
  • 접근성을 처음부터 고려하세요. 계획 및 설계 단계에서부터 염두에 두는 것이 가장 이상적인 시나리오입니다. 명암비와 폰트 크기, 시멘틱 HTML 사용, 키보드 내비게이션과 같은 항목을 개선하는 것부터 시작하면 큰 차이를 만들어 낼 수 있습니다.