▲

헬렌 폭풍 중, 단순한 텍스트 웹사이트만 원했다

 (sparkbox.com/foundry)
2P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 헬렌 허리케인으로 인한 정전과 통신 불안정 상황에서 가벼운 웹 접근성의 필요성이 드러남
  • 복잡한 이미지·스크립트 중심 웹사이트가 모바일 환경에서 거의 작동하지 않음
  • 단순한 텍스트 기반 페이지가 정보 전달과 접근성 면에서 가장 효율적임
  • 웹 성능 저하가 재난 상황의 정보 격차로 이어질 수 있음
  • 위기 시에도 접근 가능한 경량 웹 설계의 중요성이 강조됨

헬렌 폭풍과 모바일 웹 접근성

  • 헬렌 폭풍으로 전력과 네트워크가 불안정한 상황에서 웹사이트 로딩이 거의 불가능한 문제 발생
    • 이미지, 광고, 자바스크립트 등 복잡한 요소가 많은 사이트는 로딩 실패
    • 단순한 HTML 텍스트만 제공하는 페이지는 상대적으로 접근 가능
  • 이러한 경험을 통해 웹의 기본 목적이 정보 전달임을 재확인
    • 시각적 디자인보다 콘텐츠 접근성이 우선되어야 함

단순한 웹의 가치

  • 텍스트 중심 웹사이트는 저속 네트워크 환경에서도 빠르게 작동
    • 불필요한 리소스를 제거하면 데이터 사용량과 로딩 시간을 크게 줄일 수 있음
  • 위기 상황뿐 아니라 모바일 사용자 경험 개선에도 유용
    • 단순 구조는 유지보수와 접근성 향상에도 기여

웹 성능과 사회적 책임

  • 복잡한 웹 구조는 정보 불평등을 심화시킬 수 있음
    • 네트워크 인프라가 약한 지역에서 정보 접근이 제한됨
  • 개발자는 최소한의 리소스로도 작동하는 웹을 고려해야 함
    • 위기 대응, 접근성, 지속 가능성 측면에서 필수적 과제

결론

  • 헬렌 폭풍 경험은 경량 웹 설계의 필요성을 보여주는 사례
  • 단순한 텍스트 웹은 위기 대응성과 보편적 접근성을 동시에 확보하는 해법임
▲
GN⁺ 3일전  [-]
Hacker News 의견들

  • 여러 뉴스 사이트들이 텍스트 전용 버전을 제공하고 있음
    예를 들어 lite.cnn.com, text.npr.org, wttr.in 등이 있음
    더 많은 목록은 Greycoder의 리스트에서 볼 수 있음
    이런 사이트들을 쉽게 찾고 지역 뉴스 사이트에서도 지원할 수 있도록 표준화된 방식이 있으면 좋겠음

    • CNN의 라이트 버전이 좋긴 하지만, 여전히 거대한 쿠키 배너가 있음
      실제로 설정되는 쿠키는 배너 클릭 여부뿐인데, 페이지 용량 대부분이 그 배너 때문인 듯함
    • CNN 라이트 기사 하나를 열어보니, 실제 기사 본문은 11KB인데 CSS 선언만 560KB나 포함되어 있었음
    • 이런 텍스트 전용 사이트를 표준화하려면, 브라우저의 리더 모드(reader mode) 가 사이트에 최소한의 포맷만 요청하도록 하는 방식이 좋을 것 같음
    • 네덜란드에서는 공영방송이 아직도 Teletekst를 통해 뉴스를 제공함
      관련 기사: Hoe werkt het vernieuwde Teletekst
    • ‘lite’ 서브도메인을 이용하면 구독자 전용 기사도 읽을 수 있음
      CNN이 몇 달 전 공격적인 A/B 테스트를 할 때 이 사이트를 다시 떠올렸음

  • 기사 헤더 이미지가 2400x1600 PNG로 500KB나 되었는데, 미세한 디더링 때문에 압축이 잘 안 된다고 함
    같은 이미지를 .avif(품질 90, 12비트)로 변환하니 15KB로 줄어듦

    • 그런데 그 이미지는 내용과 무관한 히어로 이미지였음
      이런 이미지는 페이지 로딩을 늦추고 스크롤을 강요하며, 금세 잊히는 존재임
    • 실제로 사이트는 6.7KB의 텍스트를 전달하기 위해 1.18MB(압축 기준) 를 전송함. 아이러니함
    • SVG로 만들면 더 작아질 수도 있겠지만, 그라데이션 효과는 단순화해야 할 듯함

  • 허리케인 Helene 당시, 내가 속한 Newspack 팀이 Blue Ridge Public Radio 등과 협력해
    저대역폭 사용자를 위한 텍스트 버전 뉴스 사이트를 구축했음
    text.bpr.org을 통해 수만 명에게 정보를 전달했고,
    그 성과로 OpenNews의 지원을 받아
    긴급 뉴스용 평문 웹 솔루션을 전국 언론사에 배포하는 프로젝트를 진행 중임

    • 나도 뉴스를 자주 보는데, CNN에 라이트 버전이 있는 줄은 몰랐음

  • 순수 HTML과 폼 기반 인터랙션만으로도 충분히 효과적임
    예전 웹 포럼은 대부분 JS 없이도 완전하게 작동했음
    GitHub도 한때 JS 없이 이슈 열람과 댓글 작성이 가능했지만,
    지금은 거의 아무것도 표시되지 않음. 아마 추적 스크립트 유도 때문일 것 같음

  • 허리케인 Helene 당시의 경험을 정리해봄

    • AT&T는 완전히 다운됐지만 Verizon과 MVNO는 작동했음
    • 집 인터넷 요금제에 포함된 보조 eSIM이 큰 도움이 되었음
    • 하지만 Verizon의 재난 대응 트럭이 도착하자마자 내 MVNO 인터넷이 끊겼음
    • 교훈: 폭풍 전에는 연료나 배터리를 가득 채워두는 것이 중요함
      정전으로 주유소를 찾기 어려워 이웃들과 연료를 나눠 써야 했음
    • 몇 년 전 Pineapple Express 폭풍 때도 비슷한 경험이 있었음
      태양광만 믿지 말고 보조 전원(차량, 프로판 발전기 등) 을 준비해야 함
      또, 긴급 서비스 웹사이트는 Web 1.0 수준의 단순 폼과 이미지로도 작동해야 함
      JS 로딩에 5분 걸리는 사이트는 재난 상황에서 무용지물임
    • 지역에 따라 상황이 달랐음. 내 지역은 모든 통신망이 끊겼고,
      NPR의 라디오 업데이트가 유일한 정보원이었음
      결국 이웃들과 협력해 도로를 복구하고, 연료 확보 후 탈출했음
    • 정전 시에는 현금을 반드시 지참해야 함
      카드 결제망이 마비되면 POS 단말이 작동하지 않기 때문임
    • 숲이 많은 지역에 살면서 ISP 문제를 자주 겪는데,
      Xfinity 앱은 연결이 불안정할 때마다 오류를 내며 너무 무거움
      이런 상황에서야말로 가벼운 고객지원 포털이 필요한데, 현실은 정반대임
    • 듀얼 SIM(AT&T + T-Mobile)을 쓰고 있는데,
      트리플 SIM 폰이 있으면 Verizon도 추가하고 싶음
      eSIM은 여러 개 등록 가능하지만 동시에 하나만 활성화할 수 있음

  • 비슷한 경험으로, 네팔 산사태 때 며칠 동안 고립된 적이 있었음
    정보가 전혀 없어 전화로만 소식이 전달되었고,
    도로가 열리자마자 차량이 몰려 혼잡과 위험이 발생했음
    코로나 시기에는 지역 규제를 단순히 정리한 텍스트 페이지를 운영했는데,
    복잡한 브리핑보다 훨씬 유용했음
    우크라이나 침공 당시에는 난민들이 Telegram, Notion, Google Docs로
    24시간 만에 자발적 정보 네트워크를 구축했음
    결국 정보 전달의 단순화가 위기 대응의 핵심임

    • 내 우크라이나 동료는 피난 중에 “다리 X가 아직 통행 가능한가? ” 같은 질문을
      친구들에게 실시간으로 물으며 탈출 경로를 확인했음
      다행히 대부분 정확한 답을 받아 안전한 지역으로 이동할 수 있었음
    • 그런데 왜 우크라이나는 Telegram을 그렇게 신뢰하는지 궁금함
      민감한 정보도 그곳에서 공유되는 듯함

  • 웹 업계에서 오래된 사람이라면, 9/11 당시의 대규모 웹 장애를 기억할 것임
    거의 모든 뉴스 사이트가 다운됐고, Slashdot만이 간신히 살아남아 정보를 제공했음
    지금은 인프라가 많이 달라졌지만, 여전히 “만약 또 그런 일이 생긴다면?” 하는 생각이 듦

    • 당시 Yahoo 뉴스가 응답하지 않아 traceroute를 돌려봤는데,
      마지막 홉이 뉴욕의 타워 내부 서버로 향하고 있었음
      이후 서부로 리디렉션되기까지 시간이 꽤 걸렸음

  • 최근 읽은 기사에서, 이제는 1GB RAM으로 브라우저를 돌리기 어렵다는 이야기가 있었음
    JS는 빨라졌지만, 그만큼 웹사이트 코드 크기가 불필요하게 커졌음
    빠른 네트워크가 오히려 비효율을 부추긴 셈임
    관련 글 참고

  • 거의 1994년 수준의 순수 HTML로 시작해보는 게 좋음
    <html>, <body>만으로도 충분하고, 필요하면 약간의 CSS만 추가하면 됨
    Pico.css 같은 외부 CSS를 쓴다면 CDN 대신 직접 호스팅하는 게 바람직함

    • 이런 HTML이야말로 모든 웹 개발자의 첫 페이지가 되어야 함
      npx create-react-app 같은 복잡한 도구는 나중 문제임
    • 참고용으로 HTML5 Boilerplate 기본 템플릿을 볼 수 있음
    • 나도 텍스트 중심 사이트를 운영하는데, CSS 없이도 작동하는지 항상 확인함
      CSS는 gzip 기준 20KB 정도로 유지 중임
    • <meta charset="utf-8">은 여전히 포함하는 게 좋음

  • 영국 정부의 GDS 웹 표준은 단순 HTML로 구성되어
    심지어 PSP에서도 작동했다는 일화가 있음
    Terence Eden의 블로그 글 참고

답변달기