▲

RSS를 더 재미있게 만들기

 (matduggan.com)
14P by neo 2일전 | ★ favorite | 댓글 1개
  • RSS 피드 기반 웹 탐색 확장 프로그램을 제작해, 사용자가 무작위로 독립 웹사이트 콘텐츠를 탐색하고 평가할 수 있도록 구현
  • 버튼 클릭으로 새 사이트를 표시하고, 좋아요·싫어요·신고 기능을 통해 커뮤니티 기반 추천 구조 형성
  • FastAPI와 SQLite를 사용해 백엔드 구성, Kagi의 small web RSS 목록을 활용해 약 60만 개 페이지를 인덱싱
  • 광고나 사용자 데이터 수집 없이, 단순히 짧은 시간 동안 흥미로운 웹 콘텐츠를 탐색하는 경험 제공
  • 기존 RSS 리더의 피로감을 줄이고, 작은 웹 생태계의 재발견을 목표로 한 개인 실험적 프로젝트

프로젝트 개요

  • RSS 리더 사용 경험이 부담스럽다는 문제의식에서 출발
    • 읽지 않은 글이 쌓이는 압박감, 시간순 콘텐츠 구조의 비효율성 지적
    • 사용자는 무작위로 흥미로운 글을 탐색하고 싶다는 욕구 표현
  • TikTok의 추천 방식에서 착안해, 작은 웹사이트 콘텐츠를 무작위로 제공하는 구조 설계
    • 사용자가 콘텐츠를 평가하면, 좋아요 수에 따라 노출 빈도 증가
    • 광고나 개인 데이터 수집 없이 단순한 추천 알고리듬 적용

기능 및 사용자 흐름

  • Firefox 확장 프로그램 형태로 제공, timewasterpro.xyz에서 다운로드 가능
  • 사용자는 버튼 클릭으로 새 웹사이트를 받고, Upvote/Downvote/Report로 평가
  • 계정 생성 필요, 제출한 링크가 다른 사용자에게 인기를 얻으면 Leaderboard에서 순위 상승
  • 백엔드에서 RSS 피드를 주기적으로 크롤링해 데이터베이스에 저장
    • 600초마다 5개 피드를 확인, 하루에 한 번 이하 빈도로 업데이트
    • 신고된 URL은 검토 대기열로 이동, 좋아요·싫어요 횟수 기록

기술 구성

  • FastAPI로 API 작성, SQLAlchemy로 데이터베이스 관리
  • 데이터 저장은 SQLite 사용
    • 빠른 시작과 간단한 백업이 가능해 취미 프로젝트에 적합
  • 인증은 이메일 기반 계정 생성 후 링크 검증 방식
    • Passkey 로그인도 시도했으나 OSS 구현의 불안정성으로 제한적
    • JWT 인증 사용, 그러나 사용자 경험 측면에서 비효율적이라 평가
  • Kagi small web GitHub 저장소의 RSS 목록을 데이터 소스로 활용

디자인 및 사용자 경험

  • System.css 라이브러리를 사용해 80~90년대 Apple System OS 스타일 구현
    • “전문 서비스가 아닌 개인 실험”임을 시각적으로 전달
  • 키보드 단축키를 OS별로 구분하지 못해 Alt 키로 고정
  • 확장 프로그램의 manifest.json 설정에서 브라우저별 ID 지정 문제를 겪음
  • 분석 도구를 포함하지 않아, 사용자 피드백은 직접 보고된 문제 중심으로 수집

향후 계획

  • 콘텐츠를 카테고리별로 분류해 사용자가 선호 장르를 더 자주 볼 수 있도록 개선 예정
  • Downvote가 일정 수준 이상인 콘텐츠를 별도 큐로 이동하는 기능 검토
  • 신규 사용자가 초기에 ‘좋은 콘텐츠’를 우선적으로 접할 수 있는 구조 마련 필요
  • 사진·과학·공예 분야의 독립 웹사이트 확충 희망
  • 현재 약 60만 개 페이지 인덱싱 완료, 소스 코드는 안정화 후 공개 예정
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 모든 콘텐츠를 다 읽어야 한다는 생각은 리더 UI 설계의 결함임

    • RSS 피드를 이메일처럼 ‘받은편지함’으로 보여주는 방식이 문제임

    • TikTok처럼 흘러가는 ‘뉴스의 강(river of news)’ 형태로 접근해야 함

    • 흥미로운 글만 잠깐 들여다보고, 나머지는 그냥 흘려보내는 게 핵심임

    • Twitter도 본질적으로는 RSS와 비슷한 구조였음 — 단지 ‘읽지 않음’ 표시 없이 스크롤만 하는 방식이었음

    • 그래서 ‘읽지 않은 항목 수’ 카운터는 꺼두는 게 좋음. RSS의 가치는 내가 무엇을 선택해 읽느냐에 있음

    • 정말 좋은 글이라면, 결국 다른 구독자들이 링크를 공유해줄 것임

    • 나는 ‘강’보다는 받은편지함 방식을 선호함

      • 피드를 카테고리별로 정리해두면 ‘모두 읽음’ 처리도 어렵지 않음
      • 대신 너무 자주 글을 올리는 피드는 바로 구독 해제함. 매일 글을 올리는 블로그는 소화가 안 됨

    • 나도 한때 웹 전반에서 내 취향에 맞는 콘텐츠를 자동으로 찾아주는 시스템을 만들려 했음

      • 결국 고품질 데이터 소스의 중요성을 깨닫고, 소수의 좋은 사람만 구독하면 된다는 결론에 도달함
      • 결국 처음부터 다시 생각해보니, 그게 바로 RSS였음 — 2005년에 이미 완성된 개념이었음

    • 나도 몇 년 전 비슷한 깨달음을 얻었음

      • 읽은 글을 추적하고 싶지 않아서 RSS 피드마다 봇을 만들어 Diaspora에 미러링했음
      • 지금은 Mastodon으로 옮겼지만 원리는 같음 — 단순히 스크롤하며 흥미로운 글만 보는 방식임

    • Twitter는 ‘그랬던’ 서비스였음, 지금은 아님

  • 어떤 사람은 RSS 리더를 잘못 쓰고 있는 것 같음

    • RSS는 유튜브 채널처럼 모든 콘텐츠를 다 소비하는 게 아니라, 헤드라인만 보고 흥미로운 글만 읽는 도구임

    • TikTok은 오히려 더 나쁨 — 끝없는 콘텐츠 스트림으로 사람을 계속 붙잡아두는 구조임

    • 이런 사람은 새로운 RSS 리더보다 ‘나중에 읽기’ 리스트를 쓰는 게 나을 것 같음

    • TikTok의 추천 엔진은 단일 콘텐츠 단위로 반응을 측정하기 때문에 매우 효율적임

      • 반면 YouTube는 여러 썸네일 중 하나를 고르게 해서, 클릭하지 않은 9개에 대한 정보를 잃음
      • 알고리즘 자체가 나쁜 게 아니라, 무엇을 최적화하느냐가 문제임
      • 내 리더도 TikTok처럼 한 번에 하나의 콘텐츠를 보여주지만, 내가 직접 제출한 과학 논문이나 LLM 관련 글 등으로 구성됨

    • 누군가 RSS를 ‘잘못 쓴다’고 단정할 필요는 없음

      • 콘텐츠 소비 방식이 ‘지금 올라온 걸 읽기’에서 ‘내가 쌓아둔 걸 따라잡기’로 바뀐 것뿐임
      • YouTube도 같은 원리로 사용할 수 있음

    • 예전에 NetNewsWire를 쓸 때 읽지 않은 글 배지 때문에 불안감을 느꼈음

      • 지금 다시 쓴다면 배지를 끄고, 2일 이상 지난 글은 자동으로 읽음 처리할 것임

    • 나는 2005년 버전의 tt-rss를 커스터마이징해서 사용 중임

      • 어떤 피드는 처음부터 끝까지 읽고, 어떤 피드는 가끔만 훑음
      • 나중에는 추천 시스템 기반의 알고리즘 피드를 추가하고 싶음
      • 특히 내가 즐겨 읽는 작가들의 ‘별표/태그된 글’을 기반으로 한 분산형 추천 피드를 실험해보고 싶음

    • Google Reader의 ‘읽지 않음’ 표시가 이메일처럼 보여서, 마치 ‘해야 할 일’처럼 느껴졌음

      • 단순히 헤드라인을 훑는 행위가 아니라 ‘작업’처럼 보이게 만드는 UI였음

  • 많은 사람들이 RSS를 웹 피드의 일반명사로 사용함

    • 실제 구현 시 RSS, Atom, JSON Feed 중 무엇을 써야 하는지가 문제임

    • 팟캐스트는 여전히 RSS를 기본으로 사용함

    • 나는 JSON Feed만 사용함

      • 단순한 구조 덕분에 대부분의 리더에서 잘 작동하고, 프로그래밍적으로 다루기 쉬움
      • 직접 생성할 때는 100% JSON Feed를 씀. Atom은 굳이 쓸 이유를 못 느꼈음

  • 대부분의 피드 리더는 실제로 RSS를 쓰지 않는 사람들이 만든 것 같음

    • 나는 211개의 피드를 20여 개 카테고리로 관리 중이며, 13,000개의 캐시 항목이 있음

    • 실제로 클릭해 본문을 여는 비율은 1~5% 정도임

    • 완전 공감함. 필터링 기능이나 대량의 글을 처리할 수 있는 구조가 없는 리더가 많음

  • RSS의 장점은 추천 알고리즘의 영향에서 자유롭다는 점임

    • 특정 도메인만 반복 노출되지 않고, 다양한 분야의 글을 균형 있게 볼 수 있음
    • 이는 전통적인 선형 정보 흐름 모델로의 회귀처럼 느껴짐

  • 이런 프로젝트가 너무 반가움

    • 예전에 StumbleUpon을 정말 좋아했는데, 비슷한 서비스가 생겨 기쁨임

    • 누군가 DIGG의 후속작을 만들어줬으면 좋겠음

    • 완전 동의함. StumbleUpon의 향수를 느끼게 하면서도, 콘텐츠 초점을 직접 선택할 수 있는 점이 좋음

    • 참고로 Digg는 최근 베타 버전으로 재출시되었음

  • 나는 RSS의 비알고리즘적 큐레이션을 좋아하지만, ‘재미’ 중심의 큐레이션은 원하지 않음

    • TikTok처럼 ‘참여’를 유도하는 구조는 피하고 싶음
    • RSS를 다시 쓰는 이유는 내가 좋아하는 저자에게 직접 연결되기 위함임
    • 나중에 콘텐츠가 많아지면, 알고리즘이 콘텐츠를 압축해주는 주간 뉴스레터형 큐레이션이 이상적일 것 같음

  • 콘텐츠의 시간 순서 유지 여부는 상황에 따라 다름

    • RSS 리더나 팟캐스트에서도 이 문제를 해결할 UX를 상상해봤지만, 아직 좋은 해법을 못 찾았음

  • Scour라는 서비스를 추천함

    • 사용자의 관심사와 관련성이 높은 글을 순위화해줌

    • RSS 피드를 가져오거나 15,000개 이상의 소스에서 검색 가능함

    • 수천 개의 ‘읽지 않음’ 항목을 피하고, 좋은 글만 골라주는 도구로 설계했음

    • 흥미롭다고 생각함. 특정 피드를 블랙리스트로 제외할 수 있는 기능이 있는지 궁금함

  • RSS의 카테고리 분류 문제를 해결하려고 시도 중임

    • 많은 피드가 category 필드를 사용하지 않아서, 설명란의 해시태그를 파싱하는 크롤러를 만들었음

    • 하루에 RSS ‘inbox zero’를 유지하려고, 너무 자주 글을 올리는 블로그는 구독 해제함

    • 게시 빈도와 콘텐츠 품질은 반비례하는 경향이 있음

    • 나는 Karakeep 앱으로 RSS를 구독함

      • 콘텐츠를 자동으로 저장하고, 생성형 AI로 태그를 생성함
      • 조건 기반 RSS 피드를 만들 수 있어 기존 리더와 함께 쓰기 좋음

    • 내 웹사이트도 여러 종류의 콘텐츠를 제공하지만, 대부분의 리더가 category 태그를 지원하지 않아

      • 결국 제목에 [Blog] 같은 접두어를 붙이는 방식으로 구분함
답변달기