느린 기기를 사용하는 사용자들에게 미치는 웹 블로트의 영향

 (danluu.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 2017년 이후 대역폭 증가는 일반 사이트의 전송 크기 증가를 어느 정도 앞질렀지만, 웹 앱의 CPU 요구량은 저가형 기기 성능보다 빠르게 커져 빠른 인터넷에서도 웹 접근성이 나빠짐
  • 1Gbps 연결에서도 Tecno Spark 8C는 Discourse 포럼에서 브라우저 크래시가 발생하고, Itel P32에서는 Discourse, Reddit, Shopify, Substack, Wix, Mastodon, Bluesky 같은 사이트가 FAIL 또는 사실상 사용 불가 상태가 됨
  • 측정은 M3 Max, M1 Pro, Chrome 10x CPU 스로틀링, Tecno Spark 8C, Itel P32에서 LCP*와 메인 스레드 CPU 시간을 비교했으며, PageSpeed Insights 점수는 실제 체감 속도와 상관이 약했음
  • MyBB, phpBB, 구형 WordPress, HN, danluu.com처럼 단순하거나 오래된 사이트는 저가형 모바일에서도 비교적 잘 동작한 반면, Discourse, Medium, Reddit, Substack처럼 동적 로딩이 많은 사이트는 스크롤·검색·탭 지연이 두드러짐
  • Nigeria, India, Latin America 같은 지역의 저가형 기기 사용자는 실제 웹 사용자이며, iOS와 빠른 인터넷만 기준으로 웹을 만들면 부유하지 않은 사용자와 낮은 사양의 데스크톱 사용자까지 배제됨

대역폭보다 CPU가 병목이 된 웹

  • 2017년에는 느린 연결에서 웹 블로트가 사용성을 크게 해쳤고, 이후 고급 연결의 대역폭은 Nielsen 기준 연 50% 수준으로 빠르게 늘어남
  • 느린 인터넷을 쓰는 사용자는 여전히 많고 현대 웹 상당수는 느린 연결에서 쓰기 어렵지만, 일반 사이트에서는 대역폭 증가가 전송 크기 증가를 어느 정도 앞섬
  • 반대로 웹 앱의 CPU 성능 요구는 대역폭만큼 빠르게 개선되지 않아, 좋은 인터넷 연결을 갖고도 저사양 기기에서는 웹 사용이 어려워짐
  • Discourse 기반 “현대적” 포럼은 Tecno Spark 8C에서 브라우저 크래시를 일으키기도 하며, 크래시 사이의 반응성도 8 MHz 286과 1200 baud 모뎀으로 BBS를 쓰는 것보다 나쁘게 측정됨
  • Discourse에서 메시지 제목을 불러오는 압축 페이로드는 2.6 MB로, 과거 대비 전송량이 1000x 늘어난 수준이지만 1Gbps 연결에서는 상대적으로 가벼움
  • CPU 측면에서는 8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55)를 가진 Tecno Spark 8C도 Discourse를 감당하지 못하며, 해당 CPU는 286보다 대략 100000x 빠른 수준임

측정 대상과 지표

  • 테스트 기기는 M3 Max Macbook (14-core), M1 Pro Macbook (8-core), Chrome DevTools에서 10x 스로틀링한 M3 Max, Tecno Spark 8C, Itel P32
  • 네트워크는 기기에 유리하도록 1Gbps 인터넷과 부하 시 지연시간이 낮게 벤치마크된 WiFi 라우터를 사용함
  • 비교 대상은 블로그·마이크로블로그, 포럼, 소규모 비즈니스용 플랫폼을 포함함
    • 블로그·마이크로블로그: danluu.com, Substack, Medium, Ghost, Hugo, Tumblr, Mastodon, Twitter, Threads, Bluesky, Patreon
    • 포럼: Discourse, Reddit, Quora, vBulletin, XenForo, phpBB, MyBB
    • 소규모 비즈니스 플랫폼: Wix, Squarespace, Shopify, WordPress
  • 주요 지표는 전송 압축 크기(wire), 압축 해제 크기(raw), LCP*, 메인 스레드 CPU 시간
  • LCP*는 Chrome이 측정한 Largest Contentful Paint가 아니라, 큰 화면 갱신이 사용자에게 쓸모없는 경우 실제 유용한 콘텐츠가 보이는 시점을 기준으로 삼음
  • CPU 시간은 Core Web Vital은 아니지만, 느린 기기에서 사용자가 체감하는 사용성과 강하게 맞물리는 단순 지표로 사용됨

표에서 드러난 사용성 격차

  • danluu.com과 HN은 모든 테스트 기기에서 빠르게 동작함
    • danluu.com은 6kB wire / 18kB raw, Tecno Spark 8C에서 0.4s LCP* / 0.3s CPU
    • HN은 11kB wire / 50kB raw, Tecno Spark 8C에서 0.5s LCP* / 0.5s CPU
  • 오래된 PHP 기반 포럼은 현대적 포럼보다 느린 기기에서 훨씬 나았음
    • MyBB는 Tecno Spark 8C에서 0.8s LCP* / 0.8s CPU
    • phpBB는 1.7s LCP* / 1.5s CPU
    • vBulletin은 4.4s LCP* / 4.8s CPU
    • Discourse는 15s LCP* / 26s CPU이고 Itel P32에서는 FAIL
  • 블로그 플랫폼에서도 오래된 WordPress 테마는 Medium과 Substack보다 저사양 기기에서 훨씬 빠름
    • WordPress(old)는 Tecno Spark 8C에서 0.7s LCP* / 1.7s CPU
    • Medium은 2.8s LCP* / 33s CPU
    • Substack은 14s LCP* / 14s CPU
  • 여러 현대 사이트는 Itel P32에서 실패하거나 사실상 사용할 수 없었음
    • XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse, Reddit은 FAIL
    • Threads는 28s LCP* / 66s CPU, Twitter는 24s LCP* / 43s CPU, Medium은 3.2s LCP* / 63s CPU
  • 10s+ CPU를 쓰는 페이지는 로드 후에도 나쁜 경험을 만듦
    • 스크롤이 몇 FPS까지 떨어지고, 탭 지연이 길어 사용자가 탭이 등록됐는지 알기 어려움
    • 다시 탭하면 첫 번째 탭이 뒤늦게 등록된 뒤 두 번째 탭이 엉뚱한 동작을 일으킬 수 있음

실제 기기와 CPU 스로틀링의 차이

  • Chrome DevTools의 CPU 스로틀링은 편리하지만, 실제 느린 기기의 결과를 일관되게 근사하지 못함
  • M3/10과 Tecno Spark 8C 비교에서는 사이트별 차이가 크게 달랐음
    • danluu.com과 Ghost는 어느 정도 근사했음
    • Medium, Substack, Twitter는 Tecno Spark 8C의 CPU 시간이 약 3x 느렸음
    • Reddit과 Discourse는 약 4x 느렸음
    • Shopify는 Tecno Spark 8C가 M3/10보다 한 자릿수 이상 빠른 결과를 보임
  • 느린 페이지는 기기가 느려질수록 초선형적으로 더 느려지는 경우가 있고, 한 페이지의 느림이 다른 페이지의 느림을 잘 예측하지 못함
  • Discourse, Medium, Reddit은 M3와 M1에서는 CPU를 많이 쓰지 않는 것처럼 보이지만, Tecno Spark 8C에서는 가장 느린 축에 들어감
  • Reddit은 아무 상호작용 없이 기다려도 ~90% CPU를 사용해 CPU가 ∞로 표시됨

오래된 사이트와 단순한 페이지의 강점

  • 오래된 사이트는 대체로 최신 사이트보다 빨랐고, 10~20년간 시각적으로 크게 바뀌지 않은 사이트가 가장 빠른 축에 속함
  • MyBB는 Discourse보다 M3에서 3.6x / 5x, Tecno Spark 8C에서 19x / 33x 빠름
  • WordPress(old)는 Medium보다 M3 Max에서 17.5x / 10x, Tecno Spark 8C에서 4x / 19x 빠르게 측정됨
  • Ghost는 Medium보다 1년 뒤 출시된 현대적 플랫폼이지만, 오래된 플랫폼과 경쟁 가능한 성능을 보이는 예외임
  • NodeBB도 부록 테스트에서 현대적 포럼 중 예외에 가까움
    • M1에서 0.3s / 0.4s
    • Tecno Spark 8C에서 3.4s / 7.2s
    • Discourse보다 훨씬 빠르고, 로드 후 스크롤과 탭도 기본적으로 동작함

동적 로딩과 지표 최적화의 함정

  • Discourse, Reddit, Substack처럼 페이지 일부를 먼저 로드하고 나머지를 동적으로 불러오는 사이트는 표의 점수보다 실제 사용성이 더 나쁨
  • 느린 기기에서는 스크롤 거리를 예측하기 어렵고, 너무 멀리 스크롤하면 추가 로딩이 트리거되어 페이지가 멈출 수 있음
  • 스크롤한 과거 내용을 제거하는 페이지는 느린 기기에서 사실상 사용할 수 없음
  • 동적 로딩 페이지는 브라우저의 빠른 Ctrl/Command+F 검색을 그대로 쓰기 어렵고 자체 검색을 구현해야 함
    • Google Docs 검색은 최근 몇 달 또는 1년가량 문서 로드 직후 바로 쓰기 어려울 만큼 늦게 로드됨
    • Discourse 검색은 느린 기기나 아주 빠르지 않은 기기에서 잘 동작한 적이 없음
  • 이론적으로는 초기 CPU 작업이 이후 상호작용을 빠르게 만들 수 있지만, 테스트한 페이지들은 초기 로드, 후속 로드, 로드 후 상호작용 모두 느렸음

LCP 게임화

  • LCP는 원래 사용자가 페이지의 주요 콘텐츠가 보이는 시점을 가늠하는 지표지만, Chrome 측정은 화면의 큰 페인트가 언제 발생했는지에 가까움
  • 일부 사이트는 사용자에게 도움이 되지 않는 큰 로딩 화면을 빨리 표시해 LCP를 낮추고, 이후 실제 콘텐츠가 LCP로 잡히지 않게 작은 갱신으로 나눔
  • Discourse는 Discourse Splash를 공개적으로 도입했고, 느린 로드에서 큰 스플래시 화면으로 LCP를 크게 줄였다고 안내함
  • Discourse의 공식 답변은 실제 콘텐츠 배너가 스플래시보다 크면 LCP에 불리해진다는 취지였음
  • 유용한 콘텐츠 기준 LCP*와 Chrome 측정 LCP의 차이가 큰 사례는 Wix와 Discourse였음
    • Wix는 M3에서 6x, M1에서 12x, Tecno Spark 8C에서 3x
    • Discourse는 M3에서 10x, M1에서 12x, Tecno Spark 8C에서 4x

성능 최적화가 사업에 미치는 영향

  • 대규모 회사에서 사이트와 앱 성능 개선은 A/B 테스트로 측정될 만큼 큰 금전적 가치가 있었음
  • 장기 홀드백에서도 성능 개선은 성장과 유지율에 비교적 큰 영향을 주는 개입으로 나타남
  • Twitter에서 사용자 관측 p99 지연시간은 India와 여러 African countries뿐 아니라 United States에서도 약 60s였음
  • 각 국가에는 느린 기기나 연결을 가진 사용자가 충분히 많아, 한계 요인은 인구 전체의 평균 기기·연결 분포보다 사용자 인내심에 가까웠음
  • 느린 기기에서 60s를 50s로 줄이는 개선은 고급 기기 사용자에게도 5s를 4.5s로 줄이는 식의 영향을 줄 수 있고, 매출·성장·유지율에도 영향을 줌

저사양 기기를 고려한 설계

  • 느린 기기나 낮은 대역폭·불안정한 연결에서는 많은 콘텐츠를 한 번에 정적 페이지로 로드하는 경험이 대체로 가장 좋음
  • 이미지에 적절한 width, height, alt 속성이 있으면 도움이 되지만, progressive JPEG는 특별히 큰 도움이 되지 않았음
  • 빠른 연결이 있는 느린 기기에서는 가벼운 정적 페이지가 잘 동작하고, 성능을 고려한 가벼운 동적 페이지도 동작 가능함
  • 무거운 페이지에서 스크롤 시 추가 로딩과 검색 가로채기는 사용 가능한 상호작용 모델을 망가뜨림
  • Substack은 iPhone 8에서 글의 LCP가 빠를 수 있지만, 헤더 아래로 스크롤하려면 다음 페이지 로딩을 6s 기다리고 이후에도 1s~2s를 기다려야 하는 사례가 있음
  • 반대 사례로 큰 plain HTML 페이지는 저사양 기기에서도 비교적 잘 동작함
  • Zig standard library documentation은 소스 코드를 처음에 모두 가져오고 로컬에서 렌더링하지만, Tecno Spark 8C에서 4.7s CPU 사용 후 비교적 반응성을 유지함

저소득 사용자와 접근성

  • Tecno Spark 8C는 Nigeria에서 USD 50-60, India에서 USD 100-110 정도에 구할 수 있지만, 해당 지역 중위 가구소득 대비 비율은 미국의 현세대 iPhone보다 훨씬 큼
  • 세계 기준에서 Tecno Spark 8C는 최저가 기기에 가깝지 않고, Itel P32도 실제 사용되는 최저사양 기기보다는 높은 축에 있음
  • Alex Russell에 따르면 iOS 점유율은 India에서 7%, Latin America에서 6%임
  • Windows 텔레메트리 기준으로 대부분의 노트북·데스크톱 사용자는 최신 iPhone보다 느릴 가능성이 높은 저사양 기기를 쓰는 것으로 나타남
  • 교정 대상자에게 지급되는 “lifeline” phone에는 iPhone 6 또는 iPhone 8도 있지만, Itel P32보다 낮은 기기도 많고 데이터 한도가 작아 소진 후에는 구직·복지 양식 작성이나 Maps 사용이 어려워질 수 있음
  • 모바일 앱은 좋은 연결이 있을 때 미리 내려받을 수 있지만, 웹 앱은 접속할 때마다 수 MB의 압축 JavaScript를 받아야 하면 제한된 연결에서 사용할 수 없음

실험 조건과 한계

  • 각 사이트는 가능한 “가장 기본” 경험을 찾는 방식으로 측정됨
    • WordPress는 현재 기본 테마 twentytwentyfour 데모를 사용함
    • Shopify는 테마 목록에서 처음 보인 테마를 사용함
    • Discourse, vBulletin, XenForo, phpBB, MyBB는 공식 포럼으로 검색된 페이지를 사용함
  • 이 작업은 하루 안에 데이터 수집과 분석을 하는 짧은 프로젝트로 진행되어, 가장 흔한 테마나 실제 사용자 커스터마이징 분포까지 반영하지는 않음
  • 노트북은 약 60% 배터리, 전원 미연결, 20°C 방에서 열평형 상태에 가깝게 둔 뒤 테스트함
  • 모바일은 약 100% 충전 상태에서 전원 연결, 다른 앱과 탭 없이 테스트함
  • 실제 사용자는 같은 기기에서도 더 많은 앱과 백그라운드 작업 때문에 대부분 더 나쁜 성능을 볼 가능성이 높음
  • 크기는 모바일에서 측정되어 모바일과 데스크톱이 다른 자산을 받을 경우 모바일 자산 크기를 반영함
  • CPU는 메인 스레드 CPU 시간으로 측정했으며, 다른 스레드 시간은 기록했지만 지표에는 사용하지 않음

사이트별 주목 사례

  • Wix는 Tecno Spark 8C에서 스크롤이 제대로 안정되지 않고, Itel P32에서는 비결정적으로 실패함
  • Patreon은 초기 로드 숫자보다 스크롤 성능이 나빠, 오래된 글을 찾기 어려워 별도 Patreon 글 색인을 유지할 정도로 불편함
  • Discourse는 LCP가 강하게 게임화되어 있고, M3 Max의 1Gbps 연결에서도 Chrome 측정 LCP는 115ms였지만 실제 콘텐츠는 1.1s에 로드됨
  • Bluesky는 Itel P32에서 빈 화면을 표시함
  • Shopify의 첫 번째 실제 사용 사례 두 개는 테스트한 데모 페이지보다 둘 다 훨씬 느렸음
  • Tumblr은 Itel P32에서 JavaScript 오류가 나지만, 그 덕분에 페이지가 더 빨리 로드되고 스크롤·링크 클릭은 동작했음
  • MyBB는 모바일 버전을 제공하지 않아 Google에는 불리할 수 있지만, 느린 모바일에서는 스크롤과 탭이 실제로 잘 동작함
  • Woo Commerce는 초기 로드 성능만으로 Shopify와 비교하기 어렵고, 장바구니·체크아웃 같은 실제 흐름까지 포함한 별도 비교가 필요해 표에서 제외됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 최근에 비교적 느린 Android 휴대폰을 써보니, 텍스트와 이미지뿐인 것처럼 보이는 웹페이지도 로딩이 정말 고통스러울 수 있음
    실제 병목은 네트워크가 아니라 추적기와 광고, 자바스크립트 비대화 쪽에 가까움
    느린 구형 폰은 모바일 Firefox 같은 완전한 브라우저 자체가 너무 무거워서 Firefox Focus 같은 가벼운 브라우저를 쓰게 되는데, 확장을 못 쓰니 uBlock Origin도 못 쓰고 웹 경험은 더 나빠짐
    어떤 사이트는 “표준” 브라우저가 아니면 불평하며 unusable해지고, 회사들은 대신 앱 설치를 강요함
    예전에는 느린 기기와 연결을 위한 간소화 버전이 있었지만 점점 사라지고 있으며, 자바스크립트 비대화 없이는 광고와 추적망을 돌리기 어려워서 그런 듯함

    • 광고 차단 없이는 현대 웹이 쓸모없다는 점에서 완전한 진퇴양난임
      끝없이 스크롤되는 페이지에 무작위 광고가 박혀 있으면 특히 더 심함
    • 표준 브라우저를 써도 회사들이 웹사이트를 일부러 망가뜨려 앱을 쓰게 만드는 경우가 있음
      최근 예로 Nike 웹숍은 결제 중 쓸모없는 오류를 띄웠고, 지원팀은 “앱을 써보라”고만 했음
      유럽 항공사 예약 사이트들도 대기업 웹사이트가 자주 망가지는 대표 사례임
      2024년에 무제한에 가까운 자원을 갖고도 작동하는 웹사이트를 못 만드는 게 브랜드에 악영향이 없다고 보는 건 이상함
    • 그런 앱도 열에 아홉은 웹사이트의 일부 오프라인 복사본을 넣은 브라우저 껍데기일 가능성이 큼
    • 10년 전 nokia.com 메인 사이트 코드를 작성할 때, 리소스 로딩이 느린지 여러 방식으로 감지해서 추가 기능을 끄는 플래그를 설정했음
      모든 국가에서 동작해야 했고, 가장 느린 휴대폰 상당수가 그 회사 제품이었기 때문임
    • 2013년형 MacBook Pro를 아직 갖고 있는데, Apple이 만든 최고의 키보드라서 남겨둠
      빠르지는 않지만 웹사이트 이용에 어려움은 없고, 새 하드웨어만큼 즉각적이지 않을 뿐 충분히 쓸 만함
      다만 uBlock Origin은 사용 중임
      이런 Android 기기들이 11년 된 기본 사양 MacBook보다 실제로 더 약한 건지 궁금함

  • 전 세계의 불평등 수준을 의식해야 한다는 Dan의 요지에는 강하게 동의하지만, 라틴아메리카와 동남아시아 같은 중소득 국가도 포함해야 함
    예를 들어 월 데이터 한도가 한 자릿수 GB이고, RAM/CPU가 10년 전 미국 플래그십 수준인 사용자가 있음
    Discourse를 아예 못 쓰는 정도는 아니지만 경험은 불쾌하게 느릴 가능성이 큼
    Dan이 CPU/RAM/디스크의 점진적 개선이 참여도를 측정 가능하게 높인다고 본 것도 주로 이 사용자층 때문이라고 봄
    Itel P32 같은 최저가 기기 사용자는 점진적 최적화로는 별 이득이 없다는 게 Dan의 차트에서 드러남
    도움이 될 수 있는 건 기능과 세련됨을 희생하고 가능한 가장 얇은 코드를 제공하는 완전히 다른 클라이언트 구조, 즉 대체 라이트/기본 모드 정도임
    다만 이런 접근은 잘 성공하지 못했는데, 미국 개발자들이 성능을 위해 무엇을 남기고 버릴지 잘못 판단하는 식으로 공감 문제가 다시 나타나기 때문임

    • 왜 그게 “대체” 선택이어야 하는지 모르겠음
      현재 Discourse가 PhpBB나 DLang 포럼보다 제공하는 게 무엇인지 의문임
      모바일 친화적 디자인을 제외하면, 정상적인 세상에서는 반응형 CSS 몇 줄 수정으로 충분해야 함
    • 가난한 동남아시아 국가에 살고 있는데, 작은 데이터 요금제를 쓰는 사람들은 효율적인 웹사이트 때문에 데이터를 아끼는 게 아니라 어디에나 있는 Wi-Fi를 씀
      월 30GB 데이터가 $3.64이고, 최저임금 기준 4~6시간 정도임
      더 중요한 건 사람들이 서구처럼 데이터를 마구 쓰지 않는다는 점임
      카페, 식당, 슈퍼마켓, 쇼핑몰마다 무료 Wi-Fi가 있고, 대부분 메뉴보다 Wi-Fi 비밀번호를 먼저 물어봄
      웹사이트가 데이터를 너무 빨리 써버린다는 얘기는 본 적도 들은 적도 없음
      개발도상국에 실제로 살아보지 않은 사람들이 만들어낸 걱정처럼 들림
      여기서 데이터가 떨어지는 이유는 TikTok, Instagram, Facebook에서 영상을 봐서이지 웹사이트 비대화 때문이 아님
    • 모든 사이트가 더 효율적이면 비전문 사용자들이 “컴퓨터가 느려졌으니 새로 사야겠다”고 느끼는 시점이 늦어져 노트북과 PC의 수명도 늘어날 수 있음
      컴퓨터에 함께 설치되는 블로트웨어도 마찬가지임
      최근 새 노트북을 샀는데 $50짜리 “튜닝”을 제안받았음
      새 차 딜러가 그런 제안을 한다고 상상해보면 이상함
    • 한 세대 전 iPhone에서도 이런 사이트 중 일부는 정말 참기 어려울 정도임
      신호가 나쁜 곳이면 문제는 10배로 악화됨
      고정 헤더와 광고 때문에 화면의 3분의 1만 보이는 복잡한 UI 얘기가 아니라, 디자인 문서처럼 보일 때까지 아무렇게나 맞춰 만든 웹사이트 자체의 크기 문제임
      제대로 만들었어도 이미 비대했을 사이트가 느린 인터넷 연결에서는 사용할 수 없게 되며, 느린 하드웨어는 말할 것도 없음
      설명한 환경에서 인터넷을 쓰는 게 어떤 느낌일지 상상하기 어렵고, 그 사람들이 자기 대역폭과 기기에 맞춘 현지 사이트를 쓰며 우리가 겪는 비대한 쓰레기를 상대하지 않기를 바랄 뿐임
    • 캐나다에 살고 있고 데이터 요금제도 한 자릿수 GB였으며, 거의 10년 된 플래그십에서 막 업그레이드했음
      대부분의 웹사이트는 고문에 가까움

  • 대부분이 상사나 무서운 대기업 탓만 하는 게 흥미로움
    효율성을 잘 모르고, 알 생각도 없어 보이는 실력 부족 웹 프로그래머 집단도 크다는 사실을 개발자들이 인정하지 않음
    나쁜 소프트웨어를 만들게 강요한 상사나 기업 지배층만큼, 이들도 슬픈 웹 소프트웨어 세계에 책임이 있음

    • 그런 사람들과 일해본 적 있음
      “결과물”인 HTML, CSS, JS의 구체적인 부분을 물으면 다른 언어를 말하는 사람처럼 쳐다봤음
      자바스크립트 프레임워크 세계에서 와서 그 아래 결과물에 대해 별로 생각하지 않았던 것임
      내 철학은 거의 정반대로, 손으로 잘 작성한 HTML+CSS+JS 웹사이트와 동등한 결과를 내는 최소한의 유지보수 가능한 코드가 무엇인지 묻는 쪽임
      보통 결과물은 몇 자릿수 더 작아짐
      1000개 테이블 행을 실시간 필터링하면서도 모바일에서 빠르게 로드되고 잘 동작하게 만든 방법을 묻길래, 첫 요청에 전체 데이터를 보내고 필터에 맞지 않는 데이터를 동적으로 숨겼을 뿐이라고 했음
      웹서버는 같은 캐시 데이터를 모두에게 전달하기만 하면 되고, 사이트에서 실행되는 자바스크립트도 그것뿐이라 그들에게는 이상할 만큼 빠르게 보였음
      그들의 프레임워크 기반 해결책에서 비슷한 테이블 행 HTML을 보면 80%가 쓰지도 않는 보일러플레이트였음
      웹 개발은 너무 굳어졌고, 많은 사람이 웹 기술의 본질에서 너무 멀리 벗어났음
    • 약 5년 전, 아프리카 농촌 사람들이 생산한 물건을 더 쉽게 팔 수 있게 해주는 회사에 지원했음
      미국이나 EU 사용자를 주 대상으로 한다면 저사양 하드웨어와 불안정한 저대역폭·고지연 연결을 지나치게 최적화하지 않는 것도 일리가 있을 수 있음
      하지만 농촌 아프리카가 대상이면 공격적인 최적화는 당연해 보였음
      그런데 홈페이지는 CSS로 500×1000픽셀로 줄인 2MB짜리 거대한 이미지를 로드했고, 그 뒤는 더 나빴음
      정확한 JS 페이로드 크기는 기억나지 않지만 수 MB였고, 대부분 전통적인 템플릿 기반 백엔드 앱처럼 보였는데도 프런트엔드가 극도로 무거웠음
      콘셉트가 좋아서 지원은 했지만 기술은 끔찍했음
      첫 인터뷰 단계도 못 갔기 때문에 왜 그랬는지는 모르지만, 서유럽 개발자들이 이 측면에서 자신들이 뭘 하는지 제대로 깨닫지 못한 것 말고는 상상하기 어려움
    • “무서운 대기업”에서 일해본 입장에서는, 책임은 100% 그들에게 있음
      시작점은 개발자가 아니라 예산임
      윗선이 기술에 밝거나 엔지니어링 배경이 있지 않으면 보통 새 기능에는 예산을 잡지만 유지보수와 기술 부채 제거는 과소 편성하거나 아예 안 잡음
      유지보수 예산이 있어도 거의 전적으로 더 저렴한 해외 유지보수 팀이 맡음
      기능 팀이 6개월 동안 기능을 만들고, 해외 유지보수 팀과 1시간짜리 “KT 세션”을 한 뒤 코드를 넘김
      해외 팀은 기능에 대한 정보가 일부 있지만 기존 기술 부채를 관리할 만큼은 아니고, 그냥 불이 꺼지지 않게 유지하는 정도임
      조직 내에서 이 주기가 100~1000번 반복되면, 원래 최대 25만 줄이면 될 프런트엔드가 200만 줄이 되는 상황이 금방 옴
      새 기능 팀에 최고의 엔지니어가 들어와도 이미 만들어진 상자 안에서 일해야 함
      목업과 요소가 맞지 않으면 목업이 틀렸거나 UI 키트가 업그레이드됐거나 기존 UI 키트 리팩터링이 필요할 수 있지만, 그 예산은 없음
      그래서 팀은 컴포넌트를 복사해서 자기 기능에 맞게 수정하라는 지시를 받음
      유지보수 팀에 넘길 때도 새 팀은 기존 기능 작업을 건드리고 싶지 않아 그대로 둠
      비기술 경영진은 차이를 모르고, 수년간 팀들이 새 기능을 맞추려고 복사/붙여넣기를 반복한 결과 코드베이스에 “Button”이라는 컴포넌트가 50개 넘게 생김
    • 그건 공정하지 않음
      팀에 효율성을 중시하는 숙련 개발자가 있고, 더 효율적인 사이트를 밀어붙이거나 처음부터 더 효율적으로 만들면 페이지가 나아질 수는 있음
      하지만 대부분은 인센티브 문제임
      경영진이 신경 쓰지 않으면, 프로그래머가 시간을 들여 효율성을 높이는 것보다 절반의 시간으로 돌아가게만 만들고 백로그를 밀어내는 걸 선호할 가능성이 큼
    • 보통 나쁜 웹 소프트웨어는 나쁜 콘텐츠와 함께 감
      그래서 느린 기기는 쓰레기를 피하게 해주는 훌륭한 필터임

  • 최근에야 6년 된 LG 플래그십에서 새 Galaxy로 옮겼는데 성능 차이가 엄청났음
    그래서는 안 될 일임
    출시 당시 매우 고급 기기였고 그리 오래되지 않았으며 아직 새것처럼 작동함
    테스트용 Galaxy S9들도 같은 어려움을 겪는 걸 보면 내 폰만의 문제도 아님
    테스트에 Amazon이 들어갔으면 좋았겠음
    경험상 Amazon 웹사이트는 4년 이상 된 모바일 기기에서 최악 중 최악에 속함
    비교적 최근 고급 모바일 하드웨어에서도 내가 정기적으로 접속하던 사이트 중 유일하게 거의 사용할 수 없는 수준이었음

    • 7년 된 Snapdragon 835 기기 두 대를 써보니 RAM과 최신 Android 버전이 큰 차이를 만든다는 걸 느꼈음
      LineageOS로 Android 14를 올린 OnePlus 5를 일상용으로 쓰는데, 게임이 아닌 작업의 사용자 경험은 충분히 괜찮음
      이 폰은 RAM 6GB라 요즘 중급기와도 비슷함
      유일한 불만은 배터리를 교체해야 했고 폰 분해가 귀찮다는 점임
      반면 같은 SoC에 메모리 4GB, Samsung 수정이 들어간 순정 Android 9를 쓰는 Galaxy S8은 끝없이 버벅거림
      메모리 2GB 차이가 영향을 줄 수는 있겠지만 두 폰의 차이는 밤낮처럼 큼
      Android 14의 메모리 관리가 Android 9보다 훨씬 나은 건지, 아니면 Samsung의 느리고 비대한 소프트웨어가 기기를 발목 잡는 건지 모르겠음
      어쨌든 많은 회사가 구형·저가형 기기에서 테스트하지 않는 건 짜증남
      전 세계 사용자를 대상으로 한다면, 세계 대부분의 사람이 최신 플래그십을 쓰지 않는다는 점을 봐야 함
    • Amazon에서 JavaScript 비활성화를 해봤는지 궁금함
      실제로 그렇게 나쁘게 동작하지는 않음
      물론 그렇게 해야 할 필요는 없어야 한다는 데 동의함
    • 최근 브라질에 갔다가 새 폰을 손에서 낚아채였고, 지금은 예비용 4년 된 폰을 쓰는데 솔직히 차이를 못 느끼겠음
      다만 Firefox에 모든 광고 차단기를 쓰고 있어서 그게 도움이 되는 듯함
    • Palm Phone을 갖고 있는데, 지금 시점에서는 웹 브라우징이 거의 불가능하다고 봄
    • 최신 iOS 16을 쓰는 iPhone 8에서는 Amazon에 문제가 없음

  • 오늘날 기술은 기술에 익숙하지 않은 사람들에게도 너무 무관심함
    스마트폰이 대표 사례라고 봄
    자기 기기를 거의 쓰지 못하거나 아예 모르는 사람을 정말 많이 봤고, 그들에게는 전부 흑마법처럼 보임
    가장 큰 문제는 보이지 않아서 존재하지 않는 것과 같은 제스처 내비게이션에 과하게 의존한다는 점임
    iPhone의 제스처 바는 어찌어찌 알아낼 수 있어도, 알림 센터나 제어 센터에 대한 개념은 없음
    이 사람들이 멍청한 게 아니며, 다른 분야에서는 나보다 훨씬 뛰어날 수 있음
    기술에서는 노력 부족이 아니라 직관적인 인터페이스 부족이 문제임

    • 새 iPhone을 사도 문서가 함께 오지 않는 게 도움이 안 됨
      실제 문서를 보려면 Apple 사이트의 문서 페이지까지 찾아가야 하고, 조금 더 파고들어야 가능한 제스처 몇 개만 대략 보여주는 페이지가 나옴
      언제 어떤 제스처를 써야 하는지는 한 문장 예시 이상이 없음
      이것도 운영체제만의 얘기임
      앱들 중 자기 앱에서 제스처 기능이 어떻게 쓰이는지 설명하는 문서를 함께 제공하는 곳이 얼마나 되는지 의문임
      https://support.apple.com/guide/iphone/learn-basic-gestures-...
    • 카세트 데크도 못 다루고 타자기도 어려워했을 법한 중장년층을 본 적 있음
      그들은 분명 그런 기기들 주변에서 자랐음
      그래서 현대 기술만의 잘못은 아니라고 봄
    • 바깥에서 보기에는, 적어도 화려한 제품 쪽 인터페이스는 모두에게 하나로 맞추기 방식으로 설계되는 것 같음
      사용자가 자신에게 맞는 디자인과 상호작용을 고르게 하는 대신, 디자이너나 제품 책임자가 모든 사용자에게 무엇이 최선인지 안다고 행동함
    • 제스처 내비게이션에 과하게 의존하는 문제는 스마트폰 문제가 아니라 iPhone 특유의 문제임
      Android에서 넘어온 뒤 가장 큰 불만 중 하나였음
      뒤로 가기 버튼은 어디 있고, 홈 버튼은 어디 있으며, 버튼 자체는 어디 있는지 모르겠음
      Apple의 미니멀리즘 집착이 정말 싫고, 이 폰이 죽으면 Android로 돌아갈 것임

  • 이 글은 데스크톱에서 48세인 나에게 기본적으로 읽기 어려움
    개발자 도구에서 body에 아래를 추가하니 읽을 수 있게 됨
    font-size: 18px;
    line-height: 1.5em;
    max-width: 38rem;
    이렇게 하면 얼마나 읽기 쉽고 아름다운지 보임
    Dan Luu 글을 많이 읽지만 매번 이런 식으로 바꿔야 함
    진지하게 말해, 기술자들이여, 페이지를 더 읽기 쉽게 만드는 데는 64바이트만 더 들 뿐임

    • 53세이고 안경을 맞춰야 할 시기를 최소 5년은 넘긴 상태라, 지금도 안경이 코끝에 걸쳐 있고 때로 각도까지 맞춰야 함
      그 페이지는 거의 괜찮았고, 그냥 CTRL + 로 확대하면 됐음
      그 페이지는 순수 텍스트에 가깝고 조작도 거의 없음
      당신은 당신의 사용 사례에 맞는 해법이 있고, 나도 내 해법이 있음
      시각장애 독자도 자기 해법으로 접근할 수 있음
      소스가 단순하기 때문에 접근성 해법도 합리적으로 단순해짐
      Dan은 효과적으로 소통하는 방법을 안다고 봄
      단순하게 유지하고, 반드시 눈으로 읽을 것이라고 가정하지 않는 것임
      본인이 목적에 맞게 표시를 쉽게 바꿀 수 있음
      이런 표시 방식이 마음에 들지 않으면 읽기 전에 직접 재포맷하면 됨
      Dan은 손쉽게 조작 가능한 단순 텍스트 스트림으로 메시지를 제공한 셈임
    • 수정안은 합리적이라고 생각하지만, Dan Luu가 직접 그 CSS 규칙을 넣었다면 여기에는 낮은 밀도와 “과도한 여백”을 한탄하는 반응이 달렸을 것임
      Luu의 독자층은 전반적으로 비교적 스타일 없는 접근을 선호할 가능성이 큼
    • 동의하지 않음
      사용자는 자기 선호에 따라 창 크기, 글꼴 크기, 색상 등을 바꿀 수 있음
      매번 파일마다 바꿀 필요는 없어야 하며, 여러 파일에 적용할 수 있는 사용자 CSS 파일을 추가해 쓰는 게 허용돼야 함
    • 글꼴이 너무 작으면 브라우저의 기본 글꼴 크기를 바꿀 수 있음
      Firefox의 기본 설정 페이지에 있음
      웹사이트가 font-size: 18px;를 강제하면, 브라우저에서 더 큰 글꼴을 선택한 사용자에게는 오히려 글자가 작아질 수 있음
    • 최소한의 CSS를 추가해야 한다는 데는 동의함
      다만 브라우저의 읽기 모드를 써도 되고, 개발자 도구에서 여러 단계 거치는 대신 클릭 한 번이면 됨

  • 참고로 Raspberry Pi 3에서는 YouTube를 사용할 수 없음
    지난 1년 사이에 이렇게 됐고, 그 전에는 10~15FPS 정도로 영상을 “볼” 수 있었는데 작업장에서 수리 영상을 보기에는 충분했음
    Raspberry Pi Model B, 즉 처음 나온 모델이 출시됐을 때는 저장소의 1080p 영상을 재생하고 YouTube를 보고 게임도 할 수 있었음
    YouTube가 뭘 하는지, 다른 서비스들도 뭘 하는지 모르겠음
    기후 위기와 변화를 진지하게 생각한다면 Google과 Meta의 이런 수작을 매우 엄격하게 들여다봐야 함
    이익을 위해 CPU 사이클을 태우는 행위, 즉 즉흥적으로 추측하면 광고 기술 때문에 저전력 기기에서 YouTube가 망가지는 일은 언론에서 크게 비판받아야 하고, 전체 사용자 경험이 나쁘더라도 더 효율적인 서비스를 써야 함

    • 하드웨어 영상 디코딩 부재 때문일 수도 있지 않을까 함
      Pi3는 x264 하드웨어 가속이 있는데, YouTube가 한동안 전부터 다른 코덱을 쓰기 시작했음
    • YouTube는 확실히 무거워지고 있음
      2021년 초형 Intel MacBook Air에서도 중간 정도 부하에서 무작위로 영상이 멈추는데, 예전에는 없던 일임
    • 모든 자료를 보면 클라이언트 기기의 에너지 소비는 기후변화 기여도 측면에서 반올림 오차에 가깝다고 함
      기후변화를 해결하려고 그쪽을 공격하는 건 플라스틱 빨대나 비닐봉지 금지만큼이나 말이 안 됨
    • 사이트 탐색은 Invidious를 쓰고, 실제 영상은 난독화를 풀어 실제 스트림 URL을 얻은 뒤 VLC에 넘기는 스크립트로 봄
      또 다른 참고점으로, 10년 전 YouTube라면 그 하드웨어에서도 완전히 괜찮았을 것임
      범인은 전반적인 웹 비대화이고, 더 구체적으로는 JS에서 흔해진 추상화 괴물들임
      “기후 위기”를 전혀 믿지 않는 사람에게도 시간이 지나며 장인정신과 품질이 사라져 이런 혼란이 생겼다는 점은 말할 수 있음
      그래서 정치적 스펙트럼 전반에서 모두 동의할 수 있는 주제라고 봄
    • 사이트와 사용자별 페이지 무게를 감시하고 이름을 공개해 망신을 주는 감시 단체가 필요함
      Consumer Reports 방식으로 할 수도 있고, Nielsen 시청률처럼 동작하는 애드온일 수도 있음

  • 그 Discourse 쪽 사람은 실제 우리가 사는 세계가 아니라 자신이 존재했으면 하는 세계를 기준으로 제품을 설계하는 전형적인 사례임
    Qualcomm SoC가 들어간 기기는 수십억 대 존재하고, 앞으로도 계속 존재하며 제조·판매될 것임
    아무리 불평해도 바뀌지 않음
    받아들이고 그 기기에 맞게 최적화해야 함
    그 기기 사용자들은 개발자의 불평에 관심 없고, 소프트웨어가 충돌하면 그냥 무능한 소프트웨어 개발자라고 여길 것임

    • 아니면 “당신을 위한 것이 아님”이라고 말하는 경로를 택할 수도 있음

  • 보통 Dan Luu 글을 좋아하지만 이번 글은 빗나갔다고 느꼈음
    LCP/CPU 표는 좋았지만, 그 뒤로는 안락의자 심리학처럼 흘러감
    Discourse 창업자의 무작위 댓글 몇 개를 근거로 독자에게 소프트웨어 엔지니어들의 태도를 상상하라고 요구함
    Knuth까지 단일 코어 대 멀티 코어 성능 발언과 Itanium 관련 발언을 근거로 끌어내렸는데, 그건 오래된 학술적 논쟁 지점임
    글이 너무 무르고, 인터넷 싸움에 기대고 있어서 제대로 버티기 어렵다고 느꼈음

    • 하지만 실제로 그런 태도가 있지 않나 함
      Discourse 창업자의 말은 매우 설명적일 뿐임
      최근 웹을 써봤다면, 상상을 초월할 정도로 비대해져서 Google이 이제 Largest Contentful Paint 2.4초를 빠르다고 말하는 지경임: https://blog.chromium.org/2020/05/the-science-behind-web-vit...
      이건 4년 전 자료라 지금은 더 나빠졌을 가능성이 큼
      데스크톱에서 YouTube가 CSS 2.5MB를 로드하는 것부터, Vercel 창업자가 아주 빠른 사이트라고 자랑한 것이 조금만 제한을 걸면 로딩에 20초 걸리는 것까지 멀리 갈 필요도 없음: https://x.com/dmitriid/status/1735338533303259571
    • 회사가 성능을 진지하게 다루는 걸 본 적이 거의 없음
      프런트엔드용 단순 API 서비스 응답 시간이 500ms여도 아무도 비웃지 않음
      자기 클라우드 비용이 얼마나 나오는지 알고 신경 쓰는 엔지니어가 얼마나 되는지도 의문임
    • Knuth는 어느 정도 맞다고 봄
      지금의 병렬성은 전문적인 사용 사례나 같은 단일 스레드 프로그램을 여러 데이터 항목에 실행하는 경우를 제외하면 소프트웨어의 90%에서 쓰이지 않음
      프로그래밍 언어와 하드웨어 모두 세밀한 병렬성을 제대로 지원하지 못하고, 고전적인 소프트웨어를 병렬 접근으로 빠르게 만드는 건 매우 어려움
    • 무슨 논쟁인지 모르겠음
      Luu는 오히려 꽤 관대하게 쓴 편임
      Knuth는 수십 년간 지속된 공짜 점심이 끝난다고 불평한 것에 가까웠음
    • 요약은 꽤 잘했다고 봄
      Jeff Atwood는 예시로 고른 것뿐임
      팔로워가 많은 유명 웹 개발 사상가들이 비슷한 관점을 계속 쏟아내고, 많은 팔로워가 그 말을 그냥 받아들임

  • 모든 회사가 신경 쓰기를 멈췄고, 특히 Google과 Apple처럼 표준과 좋은 웹 디자인 관행의 최전선에 있던 회사들이 그랬음
    Google은 최근 HTML Gmail을 종료했는데, 2008년형 256MB RAM Android 폰과 오래된 Firefox에서도 빠르게 잘 돌아갔음
    당연히 새 자바스크립트 비대 버전은 브라우저를 죽여버림
    극단적 예이긴 하지만 저가형 폰은 RAM 2GB이고, 이제 이런 기기로 웹을 탐색하면서 합리적인 성능을 기대하기 어려움
    모바일 웹은 형편없고, 이는 사용자를 “네이티브” 앱으로 밀어 넣기 위해 의도된 일임
    Apple과 Google 같은 회사에 데이터 수집과 광고 표시가 더 쉬워지기 때문임

    • 부분적으로는 확실히 그렇지만, Amazon이나 유럽의 대형 스포츠·아웃도어 체인 Decathlon은 어떤지 모르겠음
      그들의 사이트는 모바일에서 끔찍하고, Decathlon은 고성능이 아닌 데스크톱에서도 끔찍함
      그런데 앱을 눈에 띄게 권하지도 않으니 그냥 무능하다고 봐야 할 것 같음
      개발자들이 백본에 연결된 고급 기기에서만 모든 걸 테스트하는 듯함
    • 목요일에 Google은 유일하게 쓸 만한 “제품”을 끝냈음
      RIP Google
      새 Reddit은 사용할 수 없고, old Reddit은 너무 낡았음
      Twitch는 채팅과 영상 스트림 문제 때문에 간신히 쓸 수 있는 수준임
      목록은 길어짐
      최종 공식을 이미 갖고 있으면 모든 변화는 일자리 보장을 위한 나쁜 변화가 됨
      언젠가 이 흙덩이 위의 원숭이들은 일자리와 돈이 존재하지 않는다는 걸 깨닫겠지만, 그때는 너무 늦을 것임
      아니, 그게 지금임
      RIP Humans
답변달기