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] 같은 접두어를 붙이는 방식으로 구분함