위키피디아(Wikipedia)를 둠스크롤(Doomscroll) 형태로? 아이디어는 좋았지만...
위키피디아(Wikipedia)의 단순 영어 버전을 기반으로 한 둠스크롤(Doomscroll) 형태의 소셜 미디어 피드가 제안됨
40MB 데이터 로딩(Data Loading)으로 인한 긴 로딩 시간과 사용자 경험 저하(Poor User Experience)가 주요 문제로 지적됨
DuckDB와 WebAssembly를 활용한 개선 방안과 Lazy Loading 방식 제안 등 기술적 개선 논의가 이루어짐
위키피디아(Wikipedia) 콘텐츠 자체의 단조로움(Monotony)과 둠스크롤(Doomscroll)과의 부적합성에 대한 비판도 제기됨
대용량 데이터 로딩 문제
커뮤니티에서는 초기 페이지 로딩 시 40MB에 달하는 데이터를 한 번에 로드하는 방식에 대한 비판이 제기되었다. 특히, 모바일 환경에서의 긴 로딩 시간은 사용자 이탈(User Churn)을 유발하는 주요 원인으로 지적되었다. Lazy Loading 방식을 통해 초기 로딩 시간을 단축하고, 필요한 데이터만 점진적으로 로드(Progressive Loading)하는 방안이 대안으로 제시되었다.
DuckDB와 WebAssembly를 활용한 개선
한 사용자는 DuckDB를 브라우저 내에서 WebAssembly를 통해 로드하고, Parquet 파일을 S3에서 가져오는 방식을 제안했다. 이는 클라이언트 측에서 데이터 처리의 효율성을 높여 로딩 속도를 개선할 수 있는 방법이다. 기술적으로 보면, 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 성능을 향상시킬 수 있다.
둠스크롤(Doomscroll)과 위키피디아(Wikipedia) 콘텐츠의 부적합성
일부 사용자들은 위키피디아(Wikipedia)의 콘텐츠가 둠스크롤(Doomscroll)에 적합하지 않다는 의견을 제시했다. 둠스크롤(Doomscroll)의 본질은 자극적인 콘텐츠를 끊임없이 소비하는 데 있는 반면, 위키피디아(Wikipedia)는 교육적인 정보를 제공하기 때문이다. 콘텐츠 소비 패턴(Content Consumption Pattern)의 차이로 인해, 둠스크롤(Doomscroll)의 목적을 달성하기 어렵다는 비판이 제기되었다.
소셜 기능 부재에 대한 아쉬움
몇몇 댓글에서는 둠스크롤(Doomscroll) 피드에 소셜 기능(Social Features)을 추가하는 방안을 제안했다. 예를 들어, 큐레이터(Curator)를 통해 게시물을 공유하고, 인기/트렌딩 게시물을 정렬하며, 댓글 시스템을 도입하는 것이다. 이러한 기능들은 사용자 참여(User Engagement)를 높이고, 플랫폼의 매력을 증대시킬 수 있다.
