개인 리더로 웹을 되찾기

 (olano.dev)
4P by GN⁺ | ★ favorite | 댓글 1개
  • 소프트웨어 업계와 기존 소셜 미디어에 지친 뒤 Mastodon도 써봤지만, 실제로 필요했던 것은 사람 중심 타임라인보다 웹의 글과 알림을 모아 보는 개인용 피드 리더였음
  • 목표는 RSS 리더의 이메일함식 밀린 목록이 아니라, Twitter·Mastodon 홈 피드처럼 열 때마다 흥미로운 콘텐츠가 흐르는 스트림형 인터페이스였음
  • 설계 기준은 사용자 경험 > 운영 편의 > 개발 편의였고, htmx·hyperscript, 모놀리식 Web 앱, SQLite, Python, gevent와 Huey 확장처럼 단순하게 운영할 수 있는 선택을 우선함
  • 실제 사용 과정에서 앱 안에서 글 읽기, 나중에 읽기 pin, bookmark, 소스 발행 빈도별 정렬, 스크롤 시 자동 “이미 봄” 처리 같은 기능이 추가됨
  • 약 3개월의 느슨한 작업 끝에 feedi를 만들었고, 몇 달 동안 “인터넷의 첫 화면”으로 쓰면서 소비하는 정보에 대한 통제감을 되찾음

번아웃 이후 다시 찾은 웹 사용 방식

  • 연속된 나쁜 프로젝트와 소프트웨어 업계에 대한 환멸로 커리어 번아웃을 겪음
  • 일을 줄이고 퇴사하고 치료를 시작했으며, 식사·운동·명상 같은 습관을 고침
  • 프로그래밍과 소프트웨어 관련 읽기를 한동안 멀리했고, 마지막으로 쓰던 소셜 미디어인 Twitter도 떠남
  • How to Do Nothing을 읽는 과정에서 대안 온라인 커뮤니티로 Mastodon을 다시 살펴보게 됨

Mastodon에서 확인한 한계

  • Mastodon은 알고리듬 중개자 없이 시간순 피드를 제공해, 피드를 다시 통제하는 느낌을 줌
  • 소프트웨어 업계와 웹에 비슷한 불편함을 느끼는 사람들은 RSS, BBS, digital gardens, webrings 같은 과거 웹 요소를 다시 살피거나 더 개방적이고 독립적인 웹을 상상하고 있었음
  • 실제 사용 목적은 마이크로블로깅보다 정보 허브에 가까웠음
    • 사람을 팔로우한 이유는 그들이 웹사이트에 글을 올릴 때 알림을 받기 위해서였음
    • 봇을 팔로우한 이유는 링크 애그리게이터 콘텐츠를 받기 위해서였음
  • IndieWeb의 social readers 개념을 접한 뒤, 필요한 도구가 Mastodon이 아니라 직접 조정 가능한 피드 리더라는 판단에 도달함

개인용 리더의 사용자 목표

  • 일반적인 RSS 리더의 이메일함식 밀린 목록이 아니라, 앱을 열 때마다 흥미로운 콘텐츠가 흐르는 스트림을 원함
  • 피드에는 여러 출처가 함께 섞여야 했음
    • 블로그, 잡지, 뉴스 사이트, 링크 애그리게이터의 글
    • Mastodon, Goodreads, GitHub 같은 개인 계정 알림
  • 출처마다 데이터 형태가 달라도 일관된 모양과 느낌을 만들 수 있도록 파싱 커스터마이즈가 필요했음
  • 완전한 IndieWeb 리더의 소셜 기능은 구현 대상이 아니었음
    • 댓글을 달기 위해 다른 탭을 여는 것은 문제가 아니었음
    • 콘텐츠가 제3자 사이트에 흩어져 있어도 괜찮았음
  • 단기 목표는 이 도구가 주된, 나아가 유일한 웹 정보원이 될 수 있는지 빠르게 확인하는 것이었고, 아니라면 프로젝트를 바로 접을 계획이었음

개발 원칙과 범위

  • 개발 원칙은 user > ops > dev였음
    • 작업 우선순위와 설계 절충에서 개발 편의보다 운영 편의를 선택함
    • 그보다 더 위에 사용자 경험을 둠
  • 개인용 앱이므로 “사용자 우선”은 직접 사용(dogfooding)하면서 자신의 필요를 먼저 만족시키는 방식이었음
  • 이상적인 사용자를 상정하기보다 자기 자신에게 인체공학적으로 맞는 도구를 만드는 편이 더 유용할 가능성이 높다고 봄
  • 이 프로젝트는 학습 프로젝트나 포트폴리오 프로젝트가 아니어야 했음
    • 목표는 생산성이 아니라 소프트웨어 개발의 즐거움과 다시 연결되는 것이었음
    • 즐거움은 “무언가를 만드는 것”보다 “직접 만든 것을 쓰는 것”에서 와야 했음
  • 단일 타깃 사용자를 가정하면서 여러 결정을 미룰 수 있었음
    • 당장 필요 없는 사용자 인증은 나중으로 미룸
    • Kindle로 보내기 같은 매우 구체적인 기능은 초기에 다룰 수 있었음
    • 피드 파서 커스터마이즈나 Mastodon 로그인처럼 프로그래밍 지식을 전제로 할 수 있었음

UI와 아키텍처 선택

  • 노트북뿐 아니라 휴대폰에서도 접근하려면 Web 애플리케이션이어야 했음
    • 하나의 인터페이스로 두 기기를 지원하는 비용 효율적인 방법이었음
    • 익숙한 HTML과 CSS를 사용할 수 있었음
    • 상태를 서버에 저장해 기기 간 동기화를 해결할 수 있었음
  • Web UI는 어느 정도 동적이어야 했지만, 별도 프런트엔드 애플리케이션이나 새 프레임워크 학습은 원하지 않았음
  • boring tech와 radical simplicity 조언에 따라 서버 사이드 렌더링 라이브러리를 찾았고, htmx와 hyperscript를 함께 사용함
  • 운영 친화성을 위해 배포와 로컬 설정이 쉬워야 했고, Docker나 Nix 같은 인프라를 전제로 하지 않으려 함
  • Aaron Parecki가 설명한 정식 IndieWeb reader는 Micropub, Microsub, Webmentions 등 여러 프로토콜별 컴포넌트로 나뉘지만, 개인 사용에는 개발과 운영을 복잡하게 만들 뿐 이점이 크지 않았음
  • 결과적으로 모놀리식 Web 애플리케이션을 선택했고, 데이터베이스는 설치·설정할 컴포넌트를 줄이기 위해 SQLite를 사용함

언어와 백그라운드 작업

  • Go는 단순하고 범용적이며, 가비지 컬렉션이 있고 충분히 빠르며, 동시성 모델과 배포하기 쉬운 바이너리가 장점이라 이 프로젝트에 잘 맞아 보였음
  • 하지만 Go를 한 줄도 써본 적이 없었고, 프로젝트가 학습 프로젝트로 바뀌는 것을 원하지 않았음
  • 이미 익숙한 언어 중 가장 빠르게 프로토타입을 만들 수 있는 Python을 선택함
  • Python은 환경과 의존성, 특히 호스트 OS 라이브러리 의존성이 단점으로 남음
  • 주기적인 feed polling을 위해 별도 컴포넌트를 늘리고 싶지 않았고, 조사 끝에 gevent와 Huey의 mini-huey 확장을 사용해 애플리케이션 프로세스 안에서 백그라운드 작업을 실행함
  • 대신 Python에는 HTTP, feed parsing, scraping에 쓸 수 있는 좋은 라이브러리들이 있었음

테스트를 미룬 이유

  • 초기에는 테스트를 쓰지 않기로 함
  • 기능을 추가·삭제·재배치하며 실험할 계획이었기 때문에, 유닛 테스트 유지 비용이 가치보다 크다고 봄
  • 작은 로직 버그는 감수할 수 있었고, 직접 매일 쓰는 앱이므로 중요한 버그는 시간이 지나며 드러날 것으로 기대함
  • 신뢰도를 주는 데는 통합 테스트가 더 가치 있다고 봤지만, 이 프로젝트의 많은 버그는 외부 소스 연동과 UI에서 나왔음
  • 통합 테스트가 일부 버그와 회귀를 더 일찍 잡을 수는 있었겠지만, 초기 비용을 들일 만큼의 가치는 없다고 판단함

실제 사용이 기능을 이끈 과정

  • 매일 최종 사용자로 직접 쓰면서 아이디어, 실험, 우선순위가 정해짐
  • 여러 UI 레이아웃과 기능을 시도한 뒤 사용 패턴이 정착함
    • 앱 열기
    • 메인 피드 스크롤
    • 나중에 읽을 항목 pin
    • 지금 읽을 항목 열기
    • 나중에 참고할 항목 bookmark
  • 앱을 떠나지 않고 글을 읽는 기능을 원했고, 이유 중 하나는 paywall과 동의 팝업을 피하는 것이었음
  • HTML 콘텐츠 추출을 위해 여러 Python 라이브러리를 시도했지만 Firefox가 쓰는 readability만큼 잘 동작하지 않았음
  • readability가 JavaScript 패키지라서, 선택적 의존성으로 Node.js를 추가하게 됨

피드 정렬과 “이미 봄” 처리

  • 기본 기능을 갖춘 뒤에도 발행일순 정렬만으로는 흥미로운 콘텐츠를 찾기 어려웠음
    • 드문 블로그 글이 Mastodon toot 뒤에 묻힘
    • 잡지의 긴 글이 일간 뉴스 기사 뒤에 묻힘
  • 팔로우하는 소스는 모두 관심 있는 출처이므로, 발행 빈도가 낮은 소스의 콘텐츠를 먼저 보고 싶다고 가정함
  • 월간 뉴스레터가 최근 며칠 안에 나왔다면, 마이크로블로깅이나 일간 뉴스보다 위에 보여야 했음
  • 소스를 “frequency buckets”으로 분류하고, 빈도가 낮은 bucket이 먼저 보이도록 피드를 정렬함
  • 드문 콘텐츠가 앱을 열 때마다 계속 상단에 붙어 있는 문제를 피하기 위해, 스크롤을 내리면 항목을 자동으로 “already seen” 처리하는 기능을 추가함
  • 이 방식으로 항상 새로운 콘텐츠를 보면서도 드문 업데이트를 놓치지 않게 됨

로컬에서 VPS까지

  • 처음에는 노트북의 터미널 탭에서 앱을 실행하며 개발과 사용을 병행함
  • 피드에 표시되는 콘텐츠가 마음에 들기 시작하자, 로컬 네트워크의 Raspberry Pi 서버에 올려 항상 접근 가능하게 만듦
  • Raspberry Pi에서 상시 사용하게 되면서 휴대폰 접근을 위해 모바일 렌더링을 개선함
  • 외출 중에도 앱 사용이 그리워지는 시점에 VPS로 배포함
  • VPS 배포는 미뤄둔 인증과 다중 사용자 지원을 추가하게 만들었고, 몇몇 친구에게 베타 테스트 접근 권한을 줄 수 있게 함
  • VPS 설정은 도메인을 사고 이 웹사이트를 만드는 계기가 되었으며, 처음 영감을 준 IndieWeb 이상에 더 가까워지는 과정이 됨

feedi의 결과

  • 약 3개월의 느슨한 작업 끝에 개인 피드 리더 feedi를 만듦
  • feedi는 완성된 제품이라기보다 Emacs 설정처럼 계속 반쯤 고장 나 있지만 몸에 익는 도구에 가까움
  • 생산성 관점에서는 정당화하기 어렵지만, 자기 조건에 맞춰 만든 도구라 만족감을 줌
  • 몇 달 동안 feedi를 “front page of the internet”으로 사용함
  • 개인 리더를 쓰면서 소비하는 정보를 다시 통제하고, 흥미로운 블로그와 잡지를 적극적으로 찾으며, 발견과 놀라움에 더 잘 놓이게 됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • urlwatch(https://urlwatch.readthedocs.io/en/latest/)를 설정해두는 게 꽤 즐거웠음. 특히 Puppeteer 보일러플레이트를 넘기고 Chrome 인스턴스로 JavaScript 사이트를 긁어올 수 있게 되면, 웹을 당겨서 보는 게 아니라 밀려오게 만드는 식으로 통제하는 느낌이 듦
    웹사이트를 부담 없이 감시해두고 아침에 훑는 힘이 큼. 좋아하는 회사의 채용 공고, 현재 회사의 채용/마감, 세일·재입고·리퍼를 기다리는 제품, 코로나 하수 통계, 아파트 매물, 관심 있는 GitHub 릴리스, 중요한 웹사이트의 약관 변화까지 추적 가능함
    개인적으로는 RSS 리더와 Telegram 봇도 셀프호스팅하고 실험용 작은 HTTP 사이트도 자주 만들기 때문에 DigitalOcean $5 Droplet을 쓰지만, 매일 같은 시간에 돌 필요는 없어서 노트북에서도 가능함

    • “아파트 매물” 용도로 Feed me up, Scotty!(https://feed-me-up-scotty.vincenttunru.com/)를 만들었음. 이메일로 알리는 대신 GitHub Actions를 써서 CSS 선택자 몇 개로 RSS 피드를 생성함
    • 비슷하게 Playwright를 헤드리스 브라우저로 써서 하루 몇 번 Twitter에 로그인하고 저장된 검색에서 뉴스와 업데이트를 가져오고 있음
      개인용이라 관심 주제의 Twitter 업데이트 요약만 받아보고, 사이트 자체와 독한 논쟁, 성가신 광고는 피할 수 있음

  • 지금 IT 상태가 너무 화가 나서 제대로 정리하긴 어렵지만, 가끔 “내 IT 담당자”라는 개념을 상상함. 동네 이발사, 주치의, 재단사, 제빵사처럼 디지털 생활의 일부를 맡아주는 사람임
    작은 로컬 인프라를 갖고 개인화 피드를 만들고, 프라이버시와 디지털 건강을 챙기며, 단순한 인터페이스나 공개 프로토콜을 통해 피드 리더와 연결해주는 식임. 영화, 글, 밈, 재미있는 영상까지 다루되, 핵심은 수익 최적화 알고리즘이 아니라 대화할 수 있는 인간이 있다는 것임
    지역 커뮤니티가 운영하는 데이터센터를 도서관처럼 두거나, 집 인터넷으로 단순 콘텐츠 서비스를 제공하는 아이디어도 떠오름. 그래서 Veilid(https://gitlab.com/veilid/veilid) 같은 발상이 좋았음
    Feediverse로 옮긴 뒤 더 건강해졌다는 얘기를 처음 듣는 것도 아님. 직접 Puppeteer 위에 스크립트와 미니 앱을 얹고 로컬 llamacpp로 요약과 추천을 돌리고 있으며, 앞으로 더 다듬어 친구와 가족에게 권해보고 싶음
    이 스크립트들 이름은 “not a browser”로 붙였음. HTML/CSS/JS를 데이터와 함께 서빙하는 웹이 아니라, 데이터만 제공하고 어떻게 표시할지는 사용자가 정하는 웹을 원함

    • 그 감정에 크게 공감함. 최근 홈랩 서버를 세팅하고 여러 기능의 웹앱을 돌리고 있는데, 새로울 건 없어도 전부 사용자 중심이고 오픈소스/커뮤니티 기반이라는 점이 좋음
      사용자에게 적대적인 알고리즘도, 광고 기반 시스템도 없고, 대체로 사용자를 우선하고 공개 프로토콜을 말하는 소프트웨어들임. IT 업계에 있고 서버를 직접 운영할 수 있으면 가능하지만, 그렇지 않은 사람들은 어떻게 하느냐가 문제임
      개인 “IT 담당자”라는 아이디어가 흥미로움. 거대 기술 기업과 알고리즘에서 벗어나 더 개인적인 것을 쓰고 싶지만 기술적 수단이 없는 사람들에게 이런 서비스를 제공할 수 있을지 궁금함
      의료 데이터도 비슷함. 내 의료 기록이 MyChart와 여러 독점 시스템에 저장되어 있고 통제권이 없는 게 싫음. 주머니 속에는 슈퍼컴퓨터가 있는데, 왜 내 기록 사본을 직접 보관하고 진료 때 의사에게 선택적으로 공유할 수 없는지 모르겠음
      아직도 병원끼리 팩스를 주고받아야 하는 것도 이상함. 버튼 하나로 내 데이터를 공유할 수 있어야 함. Apple Health가 일부 기능에 가장 가깝지만 미국 내 채택은 거의 없어 보이고, 그마저 Apple 사용자에게만 유리함. 건강 데이터는 로컬에서 도는 Apple Health 같은 형태라도 독점 시스템에 갇히면 안 되고, 공개 프로토콜과 구현 생태계가 필요함
    • 100% 동의함. 현재 IT 상태는 화가 남
      마케팅과 탐욕이 인터넷을 장악하기 전에는 짧게나마 괜찮은 시기가 있었음. 최종 사용자에게 이로운 앱을 갖춘 Synology NAS 같은 제품과, 이를 도와주는 “내 IT 담당자”가 붙는 형태라면 잘 작동할 수도 있음
      개인 데이터와 돈을 뽑아내려는 구조가 아니라면 사용자 입장에서는 유토피아에 가깝겠지만, 경제성은 아마 낮은 마진과 큰 위험을 가진 사업일 것 같음. 예를 들어 파일 유실에 대한 책임 같은 문제가 큼
    • “내 IT 담당자”라는 개념은 정말 와닿고, 앞으로 5~10년 안에 현실화될 수도 있어 보임. 다만 누군가는 이미 시도했을 텐데, 지금까지 막고 있는 요인이 무엇인지 궁금함
    • 아이디어는 아름답고 매력적이지만, 이 기술 자체가 본질적으로 지렛대 효과와 규모에 관한 것이라 그렇게 흘러가지 않은 듯함
      코드를 한 번 쓰고 거의 추가 비용 없이 백만 번 실행하는 구조임. 모든 구조적 힘이 반대 방향으로 작동하는 것처럼 보임. AI가 우리 일자리를 다 대체하고 나면 오히려 더 가능해질지도 모르겠음

  • Jenny Odell의 How to Do Nothing은 정말 훌륭한 책임. Hacker News의 일반적인 독자층과는 조금 다를 수 있지만, 주의 경제가 강요하는 가짜 “생산성” 압박을 느끼기 시작한 사람에게 강력히 추천함
    Jenny Odell의 다른 프로젝트도 볼 만함. 예를 들어 The Bureau of Suspended Objects(https://www.jennyodell.com/bso-cjm.html)가 있음

    • 맞음. 다만 이 책은 생산성을 높이기 위한 “디지털 디톡스” 같은 게 아니라, 더 철학적 담론에 가까움
      같은 맥락에서 Jenny Odell의 Saving Time도 추천함. 조용하지만 매우 급진적인 책이고, 개인적으로는 두 책 중 더 나았음. 서사가 더 집중되어 있었음
    • 동의함. 종이책으로 사서 읽고 가족에게 줬고, 최근에는 Libro.fm에서 오디오북으로 다시 샀음

  • 단순한 개인 피드를 넘어, 시간 제한이 있고 산만함이 없는 피드를 원함
    내가 팔로우하는 모든 글 콘텐츠를 모아두고, 매일 약 30분 읽을 분량이 되도록 항목 조합을 골라주면 좋겠음. 블로그 글, 기사, 트윗 등 전부 포함해야 함
    ChatGPT든 다른 도구든 써서 가장 “영양가 있는” 콘텐츠를 걸러내고, 말싸움보다 가치 있는 콘텐츠를 우선해야 함. 이후 Kindle이나 reMarkable 태블릿으로 보내서 색과 번쩍임, 빠른 인터넷에서 벗어나 읽고 싶음
    다음 단계로는 친구의 피드를 구독해서 가끔 그 피드의 “게스트” 콘텐츠도 받아보고 싶음

    • 이런 류의 사이드 프로젝트를 조금 작업해왔음. 베타를 써볼 생각이 있는지 궁금함
      GPT 요약을 추가하는 아이디어가 마음에 들고, 다른 사람들도 관심이 있다면 정리해서 공유할 수도 있겠음. 지금은 로컬에서 쓰는 단순한 JavaScript 앱이지만, 이 아이디어가 원래 생각보다 더 멋져 보임
    • 이건 초기 인터넷과 에이전트에 대한 어떤 비전과 맞닿아 있음. 프로그램이 사용자를 대신해 인터넷을 돌아다니며 유용한 작업을 하는 개념임
      Douglas Engelbart였던 것 같지만 에이전트 관련 자료를 못 찾겠음. 다른 기술 전문가였을 수도 있음

  • 자동화 테스트를 처음에는 굳이 하지 않기로 한 의식적 결정이 눈에 띄었고 공감됐음. 테스트를 안 쓰면 찝찝한 느낌을 넘기는 데 시간이 꽤 걸렸지만, 개인용 장난감 프로젝트에서는 이제 비슷하게 접근함
    너무 많은 프로젝트가 첫 하루쯤에 죽었음. 원래는 추진력을 얻어야 할 시점인데 테스트 인프라와 CI 파이프라인을 만들다가 의욕을 잃었기 때문임
    지금은 테스트 부재가 실제 문제가 되면 그때 추가한다는 기준으로 작업함

    • 개발 모범 사례는 규모의 함수라는 점을 쉽게 잊게 됨
      개발자가 많고 코드베이스가 큰 성숙한 프로젝트에서 필수인 것이, 작은 1인 프로젝트에서는 거추장스러울 수 있음
    • 개인 프로젝트에서는 제대로 만들기 어려운 부분에 부딪힐 때 테스트를 쓰기 시작함. 그 전에는 안 씀
      이후 문제가 생길 때마다 임시로 테스트를 추가하는 데 집중함
    • 대체로 동의하지만 애플리케이션 성격에 따라 다름
      몇 년 전 개인 프로젝트로 호흡 가스 분석기를 만들고, Bluetooth로 연결해 데이터를 실시간 표시하는 소프트웨어를 작성했음. 과학 계산을 정확히 해야 하는 함수에는 단위 테스트가 매우 유용했지만, 인터페이스의 다른 부분 테스트는 되돌아보면 거의 시간 낭비였음
      함수가 더 이상 바뀌지 않을 거라는 확신이 생긴 뒤에는 테스트를 전부 제거했음. 혼자 개발할 때는 수동 테스트만으로도 충분할 수 있음

  • 미래 얘기를 솔직히 하려고 새 익명 계정을 만들었음
    이 글은 미래의 내가 쓴 것처럼 보여서 놀랐음. 저자와 공통점이 너무 많아 믿기 어려웠음
    번아웃을 깨닫고 내년 초에 일을 그만둘 계획을 세우고 있었음. 익명 계정을 만든 이유도 이것 때문임. 아마 비슷하게 느끼는 사람이 많을 것임
    더 놀라운 건 저자가 한 일이 내가 쉬는 동안 해보고 싶다고 공상하던 것과 거의 같다는 점임. 오픈 웹/IndieWeb에 어떻게 참여할지 생각했고, 이 영역에서 실험할 앱을 만들 계획이었음
    드문 게시물이 홍수 속에 묻히지 않게 하는 문제나, 어떤 언어와 기술을 쓸지 같은 기술적 고민까지 닮았음. 웹 개발은 10년쯤 뒤처져 있지만, 현대 웹 기술로 뭔가 만들어볼 생각도 했음
    한편으로는 최근 생각과 감정이 검증받는 느낌이라 기쁨. 올바른 길로 가고 있다는 느낌이 듦. 다른 한편으로는 저자가 먼저 해냈다는 점이 속상하고 질투도 남

    • 위로가 될지 더 속상할지는 모르겠지만, 20년 전에 거의 비슷한 걸 만들었고 아직도 매일 쓰고 있음
      그때 나만의 RSS 리더를 원했음. 기존 리더들은 싫었고, 받은편지함이 아니라 평범한 블로그처럼 보이며 원하는 대로 디자인할 수 있는 리더를 원했음. 그래서 RSS 피드 파서를 만들고 내 일반 블로그처럼 보이게 디자인했음
      이후 RSS 피드에 요약만 있으면 전체 글을 가져오도록 바꿨음. 리더 밖을 클릭해서 전체 글을 보고 싶지 않았고, 전부 피드 리더 안에 있길 원했음. 기본 페이지 스크레이퍼가 생기자 RSS가 없는 사이트에도 썼고, 소셜 미디어가 유행했을 때 특히 도움이 됐음
      실제 소셜 사이트에 갈 필요 없이 원하는 콘텐츠만 내 피드에서 볼 수 있었음. 20년 된 물건이라 PHP와 XSLT 같은 오래된 기술로 되어 있고, 아직도 그대로임
      어쨌든 직접 만들기를 강력히 추천함. 재미있는 프로젝트임. 낡고 거칠고 스크레이핑이 완벽하지 않아 원하는 콘텐츠가 안 나올 때도 있지만, 내 것이고 20년째 매일 쓰는 리더라 좋아함
    • 저자가 먼저 했다고 질투할 필요 없음. 핵심은 스스로를 위해 만들고, 그 과정을 통해 되돌아보는 것이었음
      비슷한 시도를 한다고 해서 효과가 없을 이유는 없음. 개인 리더를 구현한 첫 사람도 아니었음
      재미있는 점은, 내가 링크했던 IndieWeb 글을 다시 훑어보니 그 글의 아이디어를 거의 그대로 반복했다는 느낌이 들었음. “모두를 위한 소프트웨어를 만들려 하지 말고, 너 자신을 위해 만들라”는 식의 조언임
      범용으로 만들고 다른 사람이 쓰기 쉽게 만들려 하면, 자신의 사용성을 해치는 타협을 하거나 존재하지도 않는 상상 속 사용자를 위해 설계하게 될 수 있음. 이기적으로 만들어서 자신에게 더 유용하게 하라는 뜻임

  • 정말 신선했음. 지난 1년 동안 매우 비슷한 번아웃/회복 경로를 지나왔고, 유용한 개인용 소프트웨어를 만들면서 다시 일을 즐길 수 있게 됨
    또 다른 큰 장점은 원하는 “비정통적” 기술을 마음껏 써볼 수 있다는 것임. 최신식 단일 바이너리 PHP 실행 파일 만들기, 운영환경에서 SQLite 쓰기, Docker 없이 배포하기 같은 것들이 즐거움을 줌
    이런 작업은 본업에도 파급 효과가 있었음. 개인용 저장소에서 새 기법과 최적화를 발견하고 본업에 가져올 때가 많음

    • 나에 대해 말하는 것처럼 들린 부분이 있었음
      기술자들이 사이드로 이것저것 만져보고, 거기서 배운 것을 직업에 유용하고 때로는 가치 있는 형태로 가져오는 일이 많다는 점이 흥미로움. 그런데 고용주는 가끔 그런 노력을 깎아내리거나 열정을 막기도 함
      내가 잘못된 종류의 조직에서 일해온 걸 수도 있음. 그래도 그런 파급 효과의 이익을 얻었다니 다행임

  • 읽고/소비할 것의 체크리스트보다 피드 사고방식을 좋아함. 몇 년 동안 RSS 리더를 몇 개 써봤지만 오래 정착하지는 못했음
    또 하나의 받은편지함을 관리할 필요가 있을까 싶었음. 그래도 feedi(https://github.com/facundoolano/feedi)는 확인해볼 생각임

    • 나는 정반대임. RSS 리더가 있으면 “새로운” 것들을 빠르게 처리하고 한동안 해킹에 들어갈 수 있음
      설정 전에는 HN에 뭔가 새 글이 있을까, Reuters에는 있을까 하며 목적 없이 여기저기 클릭하곤 했음. 내 경험은 https://news.ycombinator.com/item?id=38642092와 맞아떨어짐
    • “또 하나의 받은편지함” 대신 rss2email로 모든 RSS 구독 항목을 이메일로 받음
      개인 메일, 메일링리스트, RSS 피드가 전부 한곳에 모임. 개별 스풀로 필터링하고 mutt 같은 강력한 이메일 클라이언트를 함께 쓰면 꽤 쾌적한 통합 경험이 됨

  • 저자는 어디서든 앱에 접근하려고 인증을 추가한 것처럼 보임
    대신 VPN에 올려두고, 그 VPN을 어디서든 접근 가능하게 만드는 게 가능하거나 더 쉬울지 궁금함
    개인 웹앱을 안전하게 접근하고 싶은데 가장 쉬운 접근법을 찾고 있음. 인증을 볼 때마다 개념, 프로토콜, 라이브러리의 미로처럼 느껴지고, 그걸 유지보수하고 싶지 않음

    • 이걸 쉽게 하는 표준에 가까운 방법은 Tailscale임
      집의 Raspberry Pi에 Home Assistant 같은 앱 몇 개를 호스팅하고, 그 Pi와 휴대폰에 Tailscale을 설치했는데 매우 잘 동작함. 해야 할 인증은 “각 기기에서 Tailscale에 로그인”뿐임
      자기 기기들로 안전한 네트워크를 구성하는 쉬움 면에서는 Tailscale을 정말 강력히 추천함
    • 대부분의 용도에는 Basic HTTP 인증으로 꽤 만족하고 있음. 다행히 아직 거의 보편적으로 지원됨
      다른 웹사이트에서 클립한 텍스트 조각만 호스팅하는 내 애플리케이션을 “보호”하는 데는 충분함
    • 가능은 분명하지만 이미 VPN을 쓰고 있지 않다면 더 쉽다고 보긴 어려움
      방법은 여러 가지가 있지만 요지는 VPN 종단점과 웹앱을 같은 위치, 예를 들어 같은 머신이나 같은 네트워크에 두고 그 외 위치에서의 웹앱 접근을 제한하는 것임
    • 서버에서 WireGuard와 Caddy를 Docker로 함께 설정해 쓰고 있음
      Caddy는 내부 네트워크나 VPN에서 온 요청만 리버스 프록시하고, 그렇지 않으면 404를 반환하게 구성함. 그래서 VPN이나 집 네트워크에 있지 않으면 아무것도 보이지 않음
      손님에게 네트워크를 열어두는지, 어떤 서비스를 돌리는지에 따라 VLAN이나 별도 게스트 네트워크가 필요할 수 있음. 집에서 돌리는 많은 서비스는 자체 비밀번호 인증도 있고, VPN 제한과 함께 사용함
      이 구성은 내가 처음 떠올린 방식이라 내 전문 영역 밖의 이유로 안전하지 않을 수도 있음. 장점은 같은 compose 파일에서 Pi-hole도 돌려서, 휴대폰이 VPN에 연결되면 원격 광고 차단도 “공짜로” 얻는다는 점임
      Tailscale은 설정이 더 쉽고 UI도 좋지만 iOS에서 배터리를 많이 먹어서 중단했음. “남의 서버를 신뢰”해야 하는 점도 문제지만, 배터리 문제가 아니었다면 편의성을 위해 추가 위험을 감수했을 가능성이 큼
      WireGuard 앱에는 편리한 기능도 있음. 집에 있을 때처럼 특정 네트워크에서는 실행하지 말라고 지정할 수 있어서, 밖으로 나가면 자동으로 켜지고 집에 오면 꺼지게 할 수 있음

  • 이건 크루징 요트에서 필요하다고 생각하던 것과 놀랄 만큼 가까움. 특히 먼바다에서는 연결이 간헐적이라, 두 가지가 더 있으면 정확히 맞을 듯함
    LTE가 잡히는 섬을 지나갈 때처럼 잠깐 연결되는 순간 지금 동기화를 누를 수 있어야 함. 또 기본적으로 Readability 처리와 로컬 캐시를 해서 이미지까지 포함한 모든 콘텐츠를 오프라인에서 읽을 수 있어야 함

답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.