`와 ``이 잔뜩 늘어나 오류가 희석돼 보일 뿐이에요. WebAIM도 보고서에서 같은 경고를 합니다. 밀도는 사이트 조회 기능에 제공하지만 그것만으로는 접근성을 판단할 수 없고, `

`·``이 많으면 밀도가 낮아져 나아진 것처럼 보이지만 실제로는 새 오류가 늘었을 수 있다고요. 그래서 보고서는 밀도가 아니라 페이지당 오류 수를 기준으로 삼습니다. 밀도를 성적표로 쓰면 곤란한 이유가 여기 있습니다. 요소만 늘려도 좋아지는 숫자라면, 무엇이 나아졌는지 알려 줄 수가 없으니까요. ## 평균의 함정, HTTP Archive 중앙값은 오히려 줄었다 여기서 다른 데이터를 하나 겹쳐 보겠습니다. HTTP Archive의 Web Almanac은 훨씬 큰 표본으로 웹을 크롤링해 매년 통계를 냅니다. 2024년 Markup 장을 보면 모바일 페이지의 요소 수 **중앙값**(모든 페이지를 요소 수대로 줄 세웠을 때 한가운데 오는 값)은 2022년 653개에서 2024년 594개로 오히려 줄었습니다. 가벼운 쪽부터 세어 75% 지점은 1,010개, 90% 지점은 1,716개였고요. WebAIM은 늘었다는데 HTTP Archive는 줄었다고 하니 헷갈리실 수 있습니다. 둘 중 하나가 틀린 건 아닙니다. 재는 대상과 방식이 다를 뿐이에요. | 구분 | WebAIM Million | HTTP Archive Web Almanac | |---|---|---| | 통계량 | 평균 | 중앙값·백분위 | | 표본 | Tranco 순위 상위 100만 사이트의 홈페이지 | Chrome 사용자 데이터(CrUX)에 잡힌 사이트 전체, 내부 페이지 포함 | | 시점 | 매년 2월 | 연 1회(2024년판은 6월, 2025년판은 7월) | 평균은 무거운 소수에 끌려갑니다. 요소 5,000개짜리 홈페이지 하나가 평균을 밀어 올리는 동안 중앙값은 꿈쩍하지 않을 수 있어요. {{< img src="images/contents/mean-vs-median.png" alt="가상의 홈페이지 11개를 점으로 찍은 예시 그림 - 가장 무거운 한 페이지만 5,200개에서 7,000개로 늘자 평균은 1,250에서 1,414로 13% 오르지만 중앙값은 650 그대로다" >}} 그래서 "평균 요소 수 +14.3%"는 "보통의 홈페이지가 14.3% 무거워졌다"가 아니라, "무거운 쪽 꼬리가 더 길어졌을 가능성이 크다"로 읽는 게 안전합니다. 두 조사의 표본과 시점이 달라 직접 비교는 안 되지만, 방향이 다르다는 사실 자체가 평균 하나로 결론 내리지 말라는 신호입니다. ## 상위 10만과 하위 10만, 표본이 바뀌면 숫자도 바뀐다 WebAIM 보고서에는 인기도별 비교도 있습니다. 2026년 상위 10만 사이트의 홈페이지는 평균 1,584개, 하위 10만(표본에서 90만~100만 위)은 1,318개였습니다. 2025년에는 각각 1,465개와 1,014개였고요. 계산해 보면 상위 10만은 1년 새 8.1% 늘었고, 하위 10만은 30.0% 늘었습니다. 상위와 하위의 격차도 45%에서 20%로 확 좁혀졌습니다. "작은 사이트들이 1년 새 급격히 무거워졌다"는 문장이 바로 튀어나오죠. 그런데 이 숫자를 바로 그렇게 읽기는 어렵습니다. WebAIM의 100만 개 목록은 Tranco라는 인기 순위에서 해마다 새로 뽑습니다. 이런 순위 목록은 아래쪽으로 갈수록 흔들립니다. Tranco를 만든 연구진의 논문에는, 한때 대표적인 순위 제공처였던 Alexa가 "10만 위 아래 순위는 통계적으로 큰 의미가 없고, 측정된 트래픽이 조금만 바뀌어도 순위가 크게 움직인다"고 밝힌 내용이 인용돼 있습니다. 표본은 실제로 크게 바뀌어 있었습니다. WebAIM의 Jared Smith가 알려 준 수치로는 2026년 표본 중 2025년에도 검사된 사이트가 60.1%뿐이었습니다. 구간별로 보면 차이가 더 큽니다. 하위 10만은 **72.6%가 작년과 다른 사이트**였고, 상위 10만은 10.1%만 바뀌었습니다(WebAIM Jared Smith, 2026년 9월 서신). 다만 Jared는 이걸 조심스럽게 말했습니다. 하위 구간이 더 빨리 늘어난 원인은 알기 어렵지만, 표본 변화가 한 요인일 수 있다고요. 그러니 하위 10만의 +30%에는 같은 사이트가 무거워진 몫과, 애초에 다른 사이트를 잰 몫이 섞여 있습니다. 반대로 상위 10만은 열에 아홉이 작년과 같은 사이트라, 그쪽의 +8.1%가 "같은 사이트가 실제로 얼마나 무거워졌나"에 가까운 값입니다. 오류 수에서도 두 구간은 차이가 납니다. 상위 10만의 평균 오류는 52.2개, 하위 10만은 56.4개였습니다. Jared는 인기 있는 사이트일수록 접근성에 신경 쓰는 것처럼 페이지 크기와 복잡도에도 더 신경 쓴다고 보는 게 합리적이라고 덧붙였습니다. > 여기서 "하위 10만"은 인터넷에서 가장 인기 없는 사이트들이 아닙니다. WebAIM 표본 안에서 90만~100만 위에 있는 사이트들이에요. 수치를 인용해도 되는지 물었을 때 Jared가 짚어 두면 좋겠다고 한 부분입니다. ## Lighthouse DOM 크기 기준 1,400개와 평균 홈페이지 1,437개 같은 숫자를 성능 도구 쪽에서 보면 이야기가 하나 더 붙습니다. Lighthouse(구글이 만든 웹 페이지 품질 검사 도구)의 DOM 크기 감사는 `` 안 노드가 약 800개를 넘으면 경고를, 약 1,400개를 넘으면 오류를 표시합니다. 이유는 셋입니다. 처음 화면에 보이지도 않는 노드까지 내려받느라 데이터가 늘고, 사용자가 상호작용할 때마다 브라우저가 노드 위치와 스타일을 다시 계산해야 하며, `querySelectorAll` 같은 코드가 수천 개 노드를 붙들고 있으면 메모리가 부족해집니다. (Lighthouse 13부터는 이 감사가 「Optimize DOM size」 인사이트로 옮겨 갔습니다. 새 인사이트는 요소 수를 보여 주되, 스타일 재계산이나 레이아웃이 한 번에 40ms를 넘을 때만 실패로 표시합니다. 요소가 많다는 것 자체보다 그 때문에 실제로 느려졌는지를 보는 쪽으로 바뀐 거죠.) WebAIM이 잰 평균 홈페이지는 1,437개입니다. 두 도구가 세는 방식이 완전히 같지는 않지만, 상위 100만 사이트의 "평균적인 홈페이지"가 예전 Lighthouse라면 오류로 표시했을 선 위에 있다는 그림은 분명합니다. 그러면 이 요소들은 어디서 올까요. Web Almanac 2025의 Page Weight 장을 보면 홈페이지 HTML 문서의 중앙값 크기는 22KB에 불과합니다. 반면 JavaScript는 데스크톱 697KB, 모바일 632KB고, 페이지 전체는 2.86MB(데스크톱)·2.56MB(모바일)입니다. 중앙값과 평균이라 바로 나눌 수는 없지만, HTML 22KB에 요소 1,437개가 다 들어 있다고 보긴 어렵습니다. WAVE는 스크립트와 스타일이 적용된 뒤의 렌더된 DOM을 검사하니, 요소의 상당수는 **JavaScript가 실행된 뒤에 만들어졌다**고 보는 게 자연스럽습니다. 프레임워크, 서드파티 위젯, 광고·분석 스크립트가 심어 놓는 마크업이 여기에 다 들어갑니다. {{< img src="images/contents/rendered-dom.png" alt="서버가 보낸 HTML 22KB, JavaScript 632~697KB 실행, 렌더된 DOM 요소 1,437개를 화살표로 이은 흐름도 - WAVE와 Lighthouse는 마지막 단계인 렌더된 DOM을 잰다" >}} 비교 삼아 이 블로그 홈페이지도 재 봤습니다. Hugo로 만든 정적 사이트라 서버가 보낸 HTML(약 50KB)에 시작 태그가 365개쯤 들어 있고, 렌더가 끝난 뒤 DOM의 요소는 392개였습니다. 거의 그대로죠. 스크립트가 나중에 심는 요소가 적은 사이트는 HTML과 DOM의 차이가 이 정도입니다. 접근성 오류와 성능 저하는 이 지점에서 만납니다. 개발자가 직접 쓰지 않은 마크업이 늘수록, 그 안에 무엇이 들어 있는지 아는 사람이 줄어드니까요. ## 프레임워크별 오류 수, 복잡하다고 다 나쁜 건 아니다 그렇다고 "요즘 프레임워크는 다 무거우니 어쩔 수 없다"로 끝내면 곤란합니다. WebAIM 보고서는 사이트가 쓰는 기술별로 평균 오류 수를 함께 냅니다. 전체 평균 56.1개를 기준으로 몇 개만 추리면 이렇습니다. | 기술 | 사이트 수 | 평균 오류 | 전체 평균 대비 | |---|---|---|---| | Astro | 5,472 | 9.0 | −84.0% | | Squarespace | 2,669 | 33.0 | −41.2% | | Wix | 3,183 | 33.3 | −40.6% | | Next.js | 23,863 | 40.9 | −27.1% | | React | 45,673 | 43.5 | −22.5% | | WordPress | 252,302 | 52.8 | −5.8% | | Bootstrap | 240,869 | 63.3 | +12.8% | | Vue.js | 55,049 | 64.6 | +15.1% | | jQuery | 560,294 | 64.9 | +15.7% | | Shopify | 42,516 | 75.1 | +33.9% | | AngularJS | 6,054 | 76.6 | +36.4% | | jQuery UI | 53,076 | 79.9 | +42.3% | React나 Next.js로 만든 페이지의 DOM이 가볍다고 보긴 어렵습니다. 그런데도 평균보다 오류가 적습니다. Astro는 9개로 압도적이고요. 물론 이건 상관관계입니다. Astro를 고르는 팀과 jQuery UI를 10년째 쓰는 팀은 사이트의 성격부터 다를 테니까요. 다만 "복잡한 스택이면 오류가 많다"는 단순한 등식은 이 표가 깨 줍니다. 기본기를 시스템 안에 넣어 둔 도구(시맨틱 요소를 기본으로 내는 컴포넌트, 접근 가능한 이름을 강제하는 린트)를 쓰면 페이지가 커져도 오류가 따라 커지지 않을 수 있다는 뜻입니다. WebAIM이 결론에서 쓴 문장도 같은 방향입니다. 접근성을 규모 있게 개선하려면 더 나은 관행과 더 단순한 시스템이 필요하고, 복잡한 시스템이라면 접근성 기본기에 더 집중해야 한다고요. ## 내 페이지의 요소 수는 몇 개일까 내가 맡은 페이지는 몇 개일까요? 브라우저 개발자 도구 콘솔에서 바로 셀 수 있습니다. ```javascript // 렌더된 DOM의 전체 요소 수 (html 포함) document.getElementsByTagName('*').length // Lighthouse가 보는 범위에 가깝게: body 안쪽만 document.body.getElementsByTagName('*').length // ARIA 속성이 하나라도 붙은 요소 수 document.querySelectorAll('[role], [aria-hidden], [aria-label], [aria-labelledby], [aria-describedby]').length // 흔한 남용 후보: aria-hidden="true"와 tabindex document.querySelectorAll('[aria-hidden="true"]').length document.querySelectorAll('[tabindex="0"], [tabindex="-1"]').length ``` 첫 줄의 결과를 1,437과 비교해 보세요. 그리고 페이지를 새로고침하자마자 한 번, 5초 뒤에 한 번 더 세어 보면 스크립트가 얼마나 많은 요소를 나중에 심는지도 보입니다. 참고로 WebAIM 평균 홈페이지는 `aria-hidden="true"`가 23.3개, `tabindex` 0 또는 -1이 30.4개였습니다. Lighthouse로 재고 싶다면 Chrome 개발자 도구의 Lighthouse 탭에서 Performance만 켜고 돌린 뒤, 진단 항목에서 DOM 크기 항목을 찾으면 전체 노드 수, 자식이 가장 많은 요소, 가장 깊은 요소를 알려 줍니다. ## 한 장 요약 - WebAIM Million 2026의 "요소 수 1년 새 +22.5%"는 2년치 증가율이었고, 문의 후 +14.3%로 정정됐습니다. 원문에 정정 표시는 없으니 22.5%를 인용한 글은 계속 남습니다. - 7년 동안 홈페이지 요소는 782개에서 1,437개로 84% 늘었지만 오류는 56개 안팎 그대로입니다. 오류 밀도가 반으로 준 건 오류가 요소 사이에 희석된 결과입니다. - 평균은 무거운 꼬리에 끌립니다. HTTP Archive 중앙값은 오히려 줄었으니, "보통 페이지가 무거워졌다"로 읽으면 안 됩니다. - 하위 10만(표본의 90만~100만 위)은 1년 새 72.6%가 다른 사이트로 바뀌어, +30%를 그대로 증가율로 읽기 어렵습니다. 같은 사이트가 무거워진 값에 가까운 건 열에 아홉이 그대로인 상위 10만의 +8.1%입니다. - 평균 홈페이지 1,437개는 예전 Lighthouse DOM 오류선(약 1,400개) 위에 있습니다. 접근성과 성능은 같은 마크업에서 같이 나빠집니다. ## 마무리 이번 일로 배운 건 복잡도 통계보다 습관 쪽입니다. 보고서의 숫자를 옮길 때 한 줄이라도 검산하기. 특히 증가율처럼 두 숫자로 만들어지는 값은, 원래 두 숫자를 찾아 직접 나눠 보기. 이번엔 나눗셈 한 번이었습니다. 그리고 틀린 것 같으면 만든 사람에게 물어보기. WebAIM은 사흘 만에 답을 줬고 바로 고쳤습니다. 100만 페이지를 매년 검사하는 팀이 문의 폼 하나에 그렇게 반응한다는 것도, 이 보고서를 계속 믿고 인용해도 되겠다는 근거가 됐습니다. 숫자는 고쳐졌지만 웹은 여전히 해마다 무거워지고 있습니다. 여러분 페이지의 요소 수를 오늘 한 번 세어 보세요. 그 숫자가 어디서 오는지 알면, 접근성 오류가 어디서 오는지도 절반은 보입니다. --- ## 참고 자료 - The WebAIM Million 2026 (WebAIM). 2019~2025년 보고서는 같은 주소 뒤에 연도를 붙이면 열립니다 - Web Almanac 2024: Markup (HTTP Archive) - Web Almanac 2025: Page Weight (HTTP Archive) - Avoid an excessive DOM size (Lighthouse, Chrome for Developers) - Optimize DOM size insight (Chrome for Developers) - Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation (Le Pochat 외, NDSS 2019) - How large DOM sizes affect interactivity (web.dev)