RSS 리더를 추천하는 기사가 37MB라니, 웹은 어디로 가고 있는가

아이러니의 극치

PC Gamer가 RSS 리더를 추천하는 기사를 발행했습니다. RSS는 웹의 초기 정신을 대표하는 기술입니다. 가볍고, 빠르고, 사용자가 원하는 콘텐츠만 깔끔하게 받아볼 수 있는 구독 포맷이죠. 그런데 이 RSS 리더 추천 기사의 용량이 무려 37MB입니다. 페이지를 열면 끝없이 다운로드가 계속된다고 합니다. 가벼운 웹을 위한 도구를 소개하면서 정작 그 기사 자체가 비대한 웹의 전형을 보여주고 있는 셈입니다.

37MB가 의미하는 것

이 수치가 얼마나 비정상적인지 감을 잡아봅시다. 일반적인 텍스트 위주 웹페이지는 1~3MB 정도면 충분합니다. 이미지가 많은 페이지라도 최적화가 잘 되어 있으면 5~10MB 선에서 해결됩니다. 37MB는 고화질 이미지 갤러리나 임베디드 비디오가 여러 개 포함된 수준이고, 텍스트 기사로서는 상식을 벗어난 크기입니다.

이런 비대함의 원인은 대개 복합적입니다. 최적화되지 않은 고해상도 이미지, 수십 개의 광고 스크립트와 트래커, 서드파티 분석 도구, 소셜 미디어 임베드, 그리고 현대 웹 미디어 사이트들이 사용하는 무거운 JavaScript 프레임워크가 겹겹이 쌓이면 이런 결과가 나옵니다.

HTTP Archive의 통계에 따르면 웹페이지의 평균 크기는 지속적으로 증가해왔습니다. 2010년에 약 700KB였던 평균 페이지 크기가 2025년에는 2.5MB를 넘었습니다. 하지만 37MB는 이 평균의 15배에 달하는 수치로, 극단적 사례라 할 수 있습니다.

RSS가 다시 주목받는 이유

흥미로운 것은 RSS 리더에 대한 관심이 다시 살아나고 있다는 점입니다. Google Reader가 2013년에 종료된 이후 RSS는 사실상 '마니아의 영역'으로 밀려났었습니다. 대부분의 사용자는 소셜 미디어 피드나 뉴스 앱의 알고리즘 추천에 콘텐츠 소비를 맡겼죠.

하지만 최근 들어 알고리즘 피드에 대한 피로감, SNS 플랫폼의 불안정성(트위터/X의 변화, 레딧의 API 정책 변경 등), 그리고 정보의 자율적 큐레이션에 대한 수요가 맞물리면서 RSS가 재조명되고 있습니다. Feedly, Miniflux, Newsblur 같은 서비스들이 꾸준히 사용자를 확보하고 있고, 셀프호스팅 RSS 리더를 운영하는 개발자들도 늘고 있습니다.

웹 성능과 개발자의 책임

이 사건은 프론트엔드 개발자와 웹 퍼블리셔 모두에게 중요한 질문을 던집니다. 우리가 만드는 웹페이지는 사용자를 위해 존재하는가, 아니면 광고주와 분석 도구를 위해 존재하는가?

Core Web Vitals가 SEO 순위에 영향을 미치게 되면서 성능 최적화에 대한 인식은 높아졌지만, 실제로는 마케팅 부서의 트래커 추가 요청이나 비즈니스 요구사항 앞에서 성능이 뒷전으로 밀리는 경우가 여전히 많습니다. 한 개의 트래커를 추가할 때마다 그것이 페이지 로딩 시간에 미치는 영향을 측정하고 관리하는 조직은 많지 않습니다.

한국 개발자에게 주는 시사점

한국은 인터넷 속도가 세계 최상위권이기 때문에 페이지 크기 문제가 잘 체감되지 않을 수 있습니다. 하지만 모바일 환경에서의 데이터 사용량, LCP(Largest Contentful Paint) 같은 성능 지표, 그리고 저사양 디바이스에서의 사용자 경험을 고려하면 여전히 중요한 이슈입니다.

실무적으로는 이미지에 WebP/AVIF 포맷을 적용하고, lazy loading을 활용하고, 서드파티 스크립트를 정기적으로 감사하는 것만으로도 상당한 개선 효과를 볼 수 있습니다. Lighthouse나 WebPageTest 같은 도구를 CI 파이프라인에 통합해서 페이지 크기가 임계치를 넘으면 경고를 받는 체계를 갖추는 것도 좋은 방법입니다.