본문으로 건너뛰기
피드

Google의 'Android가 모바일 웹 최고 성능' 주장, 기기명도 없는 벤치마크를 언론이 그대로 받아쓴 꼴

frontend 약 3분
vote
0
댓글
북마크

Google이 Android가 모바일 웹 성능 최고 기록을 세웠다고 주장했지만, 테스트 기기명과 소프트웨어 버전을 공개하지 않음. Daring Fireball John Gruber가 검증 불가능한 벤치마크를 여과 없이 보도한 언론을 신랄하게 비판.

  • 1

    Speedometer 3.1 + Google 자체 LoadLine 벤치마크 사용

  • 2

    3개 Android 기기명과 비교 대상(아마 iPhone 17 Pro) 미공개

  • 3

    LoadLine은 iOS에서 실행이 극도로 복잡 — Google/OEM이 만든 벤치마크

  • 4

    다수 언론이 검증 없이 보도

  • Google이 "Android가 모바일 웹 성능에서 새 기록을 세웠다"고 발표 — Daring Fireball의 John Gruber가 이걸 통렬하게 까는 글

    • Chrome 엔지니어가 Chromium 블로그에 "하드웨어, Android OS, Chrome 엔진의 깊은 수직 통합"으로 모든 모바일 경쟁자를 압도한다고 주장
    • Speedometer 3.1과 LoadLine 두 벤치마크에서 "이름 없는 3개 Android 플래그십"이 "이름 없는 경쟁 모바일 플랫폼"(아마 iPhone 17 Pro)을 이겼다는 내용
  • 문제점: 테스트 기기명을 공개하지 않음

    • Speedometer는 누구나 웹에서 돌릴 수 있는 오픈소스 벤치마크 (WebKit, Blink, Gecko 공동 관리)
    • LoadLine은 Google과 Android OEM이 만든 벤치마크 — iOS에서 실행하려면 USB-C 이더넷 어댑터 2개, Safari 원격 자동화 활성화, 커스텀 인증서 설치, Mac 전용 소프트웨어 설치가 필요
    • 당연히 LoadLine에서 격차가 훨씬 크게 나옴
  • Gruber의 핵심 비판: "기기명도 없고 소프트웨어 버전도 없는 걸 어떻게 검증하라는 거냐"

    • MacRumors, 9to5Google, Android Authority, PhoneArena 등이 검증 없이 그대로 보도
    • Notebookcheck는 아예 "Google이 영수증을 보여줬다"라고 헤드라인을 달음 — "뭘 샀는지 안 적힌 영수증이 무슨 영수증이냐"
    • Gruber 제안: "실사용자 100명씩 Speedometer 돌려서 비교하자. 돈도 걸겠다."

벤치마크에서 테스트 기기를 공개하지 않는 건 벤치마크가 아님. '기기명을 말하든지 입을 다물든지'라는 Gruber의 지적이 정확함.

댓글

댓글

댓글을 불러오는 중...

frontend

요즘 픽셀 폰트가 그냥 복고 감성이 아닌 이유

1990년대 기기 화면 느낌을 현대 폰트 시스템으로 재해석한 픽셀 폰트 몇 가지를 소개한 글이다. 핵심은 예쁜 복고풍 글자 모양만이 아니라, 실제 제품에서 쓸 수 있게 기준선, 자간, 메타데이터, 세로 메트릭까지 챙기는지가 중요하다는 점이다.

frontend

HTML의 `<dl>`이 생각보다 쓸모 많은 이유

이 글은 HTML의 description list, 즉 `<dl>`, `<dt>`, `<dd>`가 단순 용어 사전용 태그가 아니라 이름-값 쌍 UI를 표현하는 꽤 강력한 시맨틱 도구라고 설명한다. 숙소 편의시설, 요금 내역, 기술 용어 설명, 게임 능력치표처럼 흔한 패턴을 중첩 `<div>` 대신 의미 있는 HTML로 만들 수 있다는 얘기다.

frontend

HTML을 캔버스 안에 넣는 데모 모음이 등장함

구글 크롬 랩스 저장소에 HTML-in-Canvas 관련 데모와 프레임워크 지원 목록이 정리됐다. Duck Hunt 스타일 폼, 흔들리는 버튼, 셰이더 기반 페이지 전환, 천처럼 매달린 폼 같은 실험적 예제가 포함돼 있고 Three.js와 PlayCanvas 쪽 샘플도 연결돼 있다.

frontend

싱글 페이지 앱이 웹을 너무 비싸게 만들었다는 불평

이 글은 싱글 페이지 앱(SPA)이 사용자 경험을 좋게 만든다는 명분 아래 웹의 초기 로딩 비용, 도구 복잡도, 개발 진입 장벽을 키웠다고 비판한다. 페이스북 로그인 페이지의 CSS 3.8MB, 레딧 몇 개 클릭 후 33MB 다운로드 같은 숫자를 들며, 지금의 프론트엔드 생태계가 사람보다 대기업의 요구에 맞춰져 있다고 주장한다.

frontend

네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백

20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.