# RSS를 더 재미있게 만들기 > Clean Markdown view of GeekNews topic #24911. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24911](https://news.hada.io/topic?id=24911) - GeekNews Markdown: [https://news.hada.io/topic/24911.md](https://news.hada.io/topic/24911.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-08T10:52:02+09:00 - Updated: 2025-12-08T10:52:02+09:00 - Original source: [matduggan.com](https://matduggan.com/making-rss-more-fun/) - Points: 15 - Comments: 1 ## Summary **RSS 피드 기반 웹 탐색 확장 프로그램**이 기존 리더의 피로감을 줄이고, 무작위로 작은 웹사이트를 탐색하는 새로운 방식을 제안합니다. 사용자는 버튼 한 번으로 새 콘텐츠를 받고 **좋아요·싫어요·신고 기능**으로 커뮤니티 추천 구조를 형성합니다. **FastAPI와 SQLite**로 구성된 백엔드는 Kagi의 *small web* RSS 목록을 활용해 약 60만 개 페이지를 인덱싱하며, 광고나 데이터 수집 없이 순수한 웹 탐색 경험을 제공합니다. ## Topic Body - **RSS 피드 기반 웹 탐색 확장 프로그램**을 제작해, 사용자가 무작위로 독립 웹사이트 콘텐츠를 탐색하고 평가할 수 있도록 구현 - 버튼 클릭으로 새 사이트를 표시하고, **좋아요·싫어요·신고 기능**을 통해 커뮤니티 기반 추천 구조 형성 - **FastAPI와 SQLite**를 사용해 백엔드 구성, Kagi의 *small web* RSS 목록을 활용해 약 60만 개 페이지를 인덱싱 - **광고나 사용자 데이터 수집 없이**, 단순히 짧은 시간 동안 흥미로운 웹 콘텐츠를 탐색하는 경험 제공 - 기존 RSS 리더의 피로감을 줄이고, **작은 웹 생태계의 재발견**을 목표로 한 개인 실험적 프로젝트 --- ### 프로젝트 개요 - RSS 리더 사용 경험이 부담스럽다는 문제의식에서 출발 - 읽지 않은 글이 쌓이는 압박감, 시간순 콘텐츠 구조의 비효율성 지적 - 사용자는 **무작위로 흥미로운 글을 탐색**하고 싶다는 욕구 표현 - TikTok의 추천 방식에서 착안해, **작은 웹사이트 콘텐츠를 무작위로 제공**하는 구조 설계 - 사용자가 콘텐츠를 평가하면, **좋아요 수에 따라 노출 빈도 증가** - 광고나 개인 데이터 수집 없이 단순한 추천 알고리듬 적용 ### 기능 및 사용자 흐름 - Firefox 확장 프로그램 형태로 제공, [timewasterpro.xyz](https://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만 개 페이지 인덱싱 완료**, 소스 코드는 안정화 후 공개 예정 ## Comments ### Comment 47379 - Author: neo - Created: 2025-12-08T10:53:02+09:00 - Points: 2 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46160698) - 모든 콘텐츠를 다 읽어야 한다는 생각은 **리더 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] 같은 **접두어를 붙이는 방식**으로 구분함