# 49MB 웹페이지 > Clean Markdown view of GeekNews topic #27544. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27544](https://news.hada.io/topic?id=27544) - GeekNews Markdown: [https://news.hada.io/topic/27544.md](https://news.hada.io/topic/27544.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-16T09:58:54+09:00 - Updated: 2026-03-16T09:58:54+09:00 - Original source: [thatshubham.com](https://thatshubham.com/blog/news-audit) - Points: 2 - Comments: 1 ## Topic Body - 뉴욕타임스 웹사이트의 한 기사 페이지가 **422개의 네트워크 요청과 49MB 데이터 전송**을 발생시키며, 단순한 기사 열람조차 과도한 리소스를 요구함 - 페이지 로딩 과정에서 **수십 개의 광고 입찰 요청과 추적 스크립트**가 동시에 실행되어, 브라우저 CPU와 배터리를 소모시키는 구조임 - 이러한 **적대적 UX 설계**는 쿠키 배너, 구독 팝업, 자동 재생 영상, 화면 점유형 광고 등으로 이어져 사용자의 읽기 경험을 방해함 - 광고 수익 극대화를 위한 **‘체류 시간’과 ‘노출률’ 중심의 비즈니스 모델**이 독자 경험을 희생시키며, 엔지니어조차 이 구조에 얽매여 있음 - 글은 **텍스트 중심의 경량 뉴스 페이지(text.npr.org 등)** 를 예시로 들며, 독자와 비즈니스가 공존할 수 있는 단순하고 존중받는 웹 경험의 복원을 강조함 --- ### 49MB 웹페이지의 현실 - 뉴욕타임스 웹사이트 접속 시 **422개의 요청과 49MB 데이터**가 발생, 페이지 안정화까지 2분 소요 - 이는 **Windows 95 전체 용량(28장의 플로피 디스크)** 보다 크며, **MP3 음악 10~12곡 분량**에 해당 - 단 몇 문단의 텍스트를 읽기 위해 앨범 한 장을 다운로드하는 셈임 - 과거보다 하드웨어 성능이 비약적으로 향상되었음에도, **광고·트래킹 중심의 웹 프레임워크**가 그 진보를 상쇄함 ### CPU 부하와 추적 구조 - 뉴스 사이트는 **프로그램형 광고 입찰 시스템**을 브라우저 내에서 실행함 - Rubicon Project, Amazon Ad Systems 등으로의 **비동기 입찰 요청**이 동시에 발생 - 브라우저는 수 MB의 자바스크립트를 다운로드·파싱·컴파일해야 하며, 이는 **메인 스레드 부하**로 이어짐 - 사용자는 텍스트를 요청했지만, 브라우저는 **5MB의 추적 스크립트**를 먼저 처리하고, 이후 광고 삽입이 이루어짐 - 동시에 **행동 추적 비콘(POST 요청)** 과 **보이지 않는 픽셀 리디렉션(doubleclick.net, casalemedia)** 이 작동하여 교차 사이트 식별을 수행 - 이러한 과정은 **모바일 발열·배터리 소모**를 유발하며, 사용자는 자신도 모르게 **고빈도 데이터 거래 시장**에 참여하게 됨 ### 적대적 UX와 상호작용 비용 - 페이지 진입 시 **GDPR 쿠키 배너, 뉴스레터 구독 모달, 알림 허용 팝업**이 연속적으로 등장 - 사용자는 콘텐츠 접근 전 여러 번의 클릭과 스크롤을 수행해야 함 - 이는 **NNgroup의 ‘상호작용 비용(Interaction Cost)’** 과 **‘미니멀리즘 디자인’ 원칙**을 위반 - **Economic Times** 사례에서 사용자는 세 개의 모달을 닫고, 상단 배너를 넘겨야만 본문 접근 가능 - 구글의 **Core Web Vitals** 기준에서도 이러한 **침입형 인터스티셜**은 SEO 감점 요인으로 명시됨 ### 레이아웃 불안정과 광고 삽입 - 독자가 문단을 읽는 도중, 광고 입찰이 완료되면 **iframe 광고가 삽입되어 텍스트가 250픽셀 이동** - 이는 **누적 레이아웃 이동(CLS)** 으로 측정되며, 이탈률 상승과 직결 - 구글은 이 문제를 공식적으로 감점하지만, **자사 광고 제품이 동일한 문제를 유발**하는 모순 존재 - **자동 재생 영상**은 스크롤 후에도 화면 하단에 고정되어 계속 재생되며, 닫기 버튼은 작고 클릭 영역이 좁음 - 이는 **Fitts의 법칙 위반** 사례로 지적됨 ### 모바일 환경의 공간 낭비 - 평균 모바일 뷰포트 800px 중, **로고·공유바·브라우저 UI**가 상당 부분을 차지 - 실제 콘텐츠는 **Guardian 페이지 기준 11%** 만 표시 - **광고·모달 89% vs 콘텐츠 11%** 의 비율은 사용자의 시각적 피로와 스크롤 빈도를 증가시킴 - **‘X’ 버튼을 광고 클릭 영역 근처에 배치**해 오클릭을 유도하는 ‘fat-finger tax’ 전략도 존재 - **Jagran** 등 일부 인도 뉴스 사이트는 앱 설치 유도 모달과 구독 팝업으로 본문 접근을 방해 ### 개선 방안 제시 - 콘텐츠 표시 전 **3~4개의 닫기 동작을 강요하는 구조**는 사용자의 인지 자원을 낭비 - 팝업은 **60초 체류 또는 50% 스크롤 이후**에만 노출하도록 조정 필요 - 쿠키 동의와 뉴스레터 구독을 **하단 비차단형 섹션**으로 통합 가능 - 광고 슬롯은 **고정 높이 컨테이너**로 예약해 **레이아웃 이동 방지** - 예: `min-height: 250px; background: var(--skeleton-loader);` - 광고 실패 시 `ResizeObserver`로 비가시 영역에서만 축소 처리 ### 경량 뉴스 사이트의 존재 - **text.npr.org**, **lite.cnn.com**, **cbc.ca/lite** 등은 **추적·모달 없는 경량 버전** 제공 - RSS 피드 기반 뉴스 소비도 여전히 활발 - 이러한 사례는 **단순하고 콘텐츠 중심적인 웹 경험**에 대한 수요가 여전함을 보여줌 ### 결론: 독자의 주의력은 자원 - 현재 뉴스 UI는 **독자를 포획 대상으로 간주**하며, 광고 노출을 극대화하는 구조로 설계됨 - 그러나 **수익성과 접근성은 양립 가능**하며, 엔지니어들도 이 구조에 불만을 품고 있음 - 문제의 근원은 **단기 CPM 중심의 비즈니스 인센티브** - 독자의 주의력을 **추출 가능한 자원으로 취급하는 시스템**이 형성되었으며, **RSS 사용·탭 닫기·이탈률 증가**가 이에 대한 가장 강력한 저항 행위로 제시됨 ## Comments ### Comment 53082 - Author: neo - Created: 2026-03-16T09:58:55+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47390945) - 우리 개발자들이 한 웹사이트를 열 때마다 약 **750MB**를 사용했음 서버가 느리다는 티켓이 들어와 확인해보니, 페이지의 모든 동영상이 미리 일부씩 **preload**되고 있었음 사무실이 데이터센터와 광케이블로 직접 연결돼 있어서 그나마 버텼던 것임 웹 개발자들에게는 128kbit 이상의 네트워크 속도를 주면 안 된다고 생각함. 그 이상이면 전부 엉망이 됨 - Chromium이나 Firefox 기반 브라우저의 **Network 탭**에서 3G나 4G 속도를 시뮬레이션할 수 있음 CPU 제한 기능과 함께 쓰면 저사양 환경에서 사이트 성능을 점검하기에 좋음 - 128kbit 제한은 **마케팅 부서**에도 적용해야 함. 추적 스크립트의 주범이 그들이기 때문임 - 빠른 컴퓨터로 개발하더라도, 테스트는 **Chromebook** 같은 저사양 기기에서 해야 함 - **mcmaster.com**처럼 문맥 인식 프리패칭이 잘 구현된 사이트를 참고할 만함 느린 개발 서버를 쓰면 자연스럽게 불필요한 리소스를 줄이게 되는 훈련 효과가 있음 - 예전에 [text.npr.org](https://text.npr.org) 같은 **텍스트 웹**을 Lyx로 사용했음 Gopher, Gemini, IRC 기반 Bitlbee 등 초저속 환경에서도 잘 작동했음 Electron 앱 개발자들도 2GB RAM, 구형 Celeron급 PC에서 테스트해야 진짜 완성된 앱이라 할 수 있음 - 실험 삼아 **nytimes.com**을 열어봤는데, 추적 픽셀과 광고 스크립트가 정말 끔찍했음 그래도 전송량 기준으로 보면 44.47MB 중 36.3MB가 **저널리즘용 동영상**이었음 즉, 과도한 광고보다는 영상 중심의 콘텐츠 구조가 문제인 셈임 - 하지만 왜 모든 페이지에 **자동 재생 영상**이 있어야 하는지 의문임 사용자가 클릭하기도 전에 36MB를 강제로 내려받게 하는 건 납득하기 어려움 - 요즘 **NYT**는 완전히 바닥으로 치닫고 있음 광고와 자바스크립트 덩어리 때문에 아예 읽지 않음. 대신 제목만 복사해 다른 사이트에서 읽음 기본적으로 **JavaScript를 꺼둔 상태**로 브라우징하며, 광고는 거의 보지 않음 JS를 끄면 페이지가 훨씬 빠르고, 개인정보 유출 위험도 줄어듦 이런 방식이 비윤리적이라고 생각하지 않음. 사이트들이 먼저 불공정하게 행동했기 때문임 - [lite.cnn.com](https://lite.cnn.com), [text.npr.org](https://text.npr.org), [newsminimalist.com](https://newsminimalist.com) 같은 **경량 뉴스 사이트**들이 훨씬 쾌적함 - NYT는 이런 사용자가 **수익에 기여하지 않는 소수**라는 걸 알고 있음 차라리 방문하지 않는 게 그들에게도 이득일 정도임 - 대부분의 사람들은 **JS나 메가바이트 단위**에 관심이 없음 콘텐츠가 보이고 작동하면 그걸로 충분하다고 생각함 NYT는 이런 ‘기술에 무관심한 다수’를 대상으로 함 - YouTube가 앞으로도 **대체 클라이언트**를 허용할지, 아니면 DRM으로 막을지 궁금함 - 2005년 우리 가족의 첫 **브로드밴드 요금제**는 월 400MB 제한이었음 신문 산업의 근본 문제는 **광고 기반 경제 모델 붕괴**임 과거엔 인쇄비만 독자에게 받고, 나머지는 광고로 충당했음 하지만 지금은 Facebook Marketplace, Craigslist 등이 그 광고를 모두 가져감 결국 뉴스는 **틈새 상품**이 되었고, 독자 데이터 판매는 마지막 몸부림임 - 2010년에 120MB짜리 게임 업데이트를 받아서 부모님께 혼난 기억이 있음 월 250MB 제한이었으니 지금 생각하면 믿기 어려움 - 요즘 웹 개발은 정말 **광고와 추적 지옥**임 HN처럼 JS 한 줄 한 줄을 신중히 다루는 사이트가 오히려 신의 선물처럼 느껴짐 웹을 덜 비대하게 만들어야 함 - 웹사이트가 메모리를 다 쓸 수 있다고 해서, 꼭 그렇게 해야 하는 건 아님 - 페이지 위에 온갖 팝업과 오버레이가 덮여서 **콘텐츠를 볼 수조차 없는** 경우가 많음 이런 UX로 돈을 벌 수 있을 리 없는데도 계속 반복함 - **Windows 95 설치 용량(약 40MB)** 으로 비교하는 단위가 재밌음 예전엔 Win95도 ‘비대하다’고 불렸는데, 지금 웹페이지는 그보다 훨씬 큼 광고 자체보다 **리소스 낭비와 산만함**이 문제임 JS를 켜자마자 화면이 요란해지면 바로 나가버림 - 광고 산업의 **경제 구조**가 궁금함 사용자 짜증을 유발하면서 얻는 몇 센트가 과연 가치가 있는지 의문임 대부분의 사람들은 그냥 무관심하게 받아들이는 듯함 나는 30대 후반 개발자로, **‘자유로운 인터넷’ 세대**라 광고에 대한 인내심이 거의 없음 - 항공사 웹사이트는 특히 심각함. **Air Canada** 같은 곳은 단순한 예약 과정조차 수 MB의 JS로 뒤덮여 있음 예전 **Amadeus 터미널**처럼 명령줄 기반 인터페이스가 그립음 웹이 다시 사용자 중심으로 돌아가려면 어떻게 해야 할지 고민임 - **China Southern** 웹사이트는 최악이었음 필드 라벨 오류, 잘린 placeholder, 중국어로 뜨는 date picker, 좌석 선택 후 “선택 불가” 메시지 등 UX가 완전히 붕괴되어 있었음 - **Big Tech의 트렌드 추종**에 빠진 개발자들을 비판해야 함 단순한 HTML 폼으로도 충분히 쓸 만한 사이트를 만들 수 있음 JS를 남용하는 건 세뇌된 결과임 - 요즘 웹은 **개발자 이력서 채우기용**으로 만들어지는 느낌임 - 광고 클릭 외의 **새로운 수익 모델**이 필요하다고 생각하지만, 대안은 아직 모르겠음 - 기사에서 **DNS 차단 리스트**를 언급하지 않은 건 아쉬움 나는 **Hagezi ultimate list**로 거의 모든 광고를 차단하고, 데스크톱에서는 uBlock으로 미세 조정함 Google·Adobe 폰트 도메인도 직접 차단해 속도와 프라이버시를 개선했음 - 정밀 테스트는 안 했지만, 필터 덕분에 **트래픽이 1/10 이하**로 줄어든 느낌임 - 웹사이트에서 **스크립트 실행을 허용한 결정**은 90년대 최대의 실수였음 사용자가 검증하지 않은 프로그램이 내 컴퓨터에서 실행되는 건 근본적으로 잘못된 구조임 JS를 끄면 사이트가 망가지는 건 개발자들이 잘못 설계했기 때문임 HTML과 실행 코드가 분리됐더라면 세상이 훨씬 나았을 것임 - 단순히 읽기 전용 콘텐츠를 보기 위해 **실행 코드를 다운로드**해야 하는 건 말이 안 됨 서버에서 렌더링해 결과만 보내면 충분함 - 하지만 사용자들이 **인터랙티브 웹**을 원했기 때문에 스크립팅은 결국 도입됐을 것임 49MB짜리 페이지는 그저 **우선순위의 반영**일 뿐임 빠른 인터넷이 보편화된 지금, 대부분의 사용자는 문제를 느끼지 않음 - 아이러니하게도, 이런 비판 글조차 **Cloudflare Insights** 같은 3rd-party 리소스를 불필요하게 불러옴 나는 **uBlock Origin 하드 모드**로 이런 리소스를 완전히 차단함