TL;DR

• Stingray라는 심플한 셀프 호스트형 (Self-hosted) RSS 리더를 AI에게 만들게 했어
• 어느 정도의 노력과 기간으로 실용 가능한 수준의 결과물이 나올 수 있는지에 대한 실험이기도 했어
• 앞으로의 시대에는 자신이 사용하는 도구를 각 개인이 AI와 협업하여 만들어가게 될지도 몰라 (하지만 쉽지는 않아)

서론

Stingray는 RSS / Atom 피드를 하나의 타임라인으로 집약하는 셀프 호스트형 (Self-hosted) Web 리더입니다. 내 PC에서 구동하며, 구독 데이터와 읽음 상태도 모두 자신의 관리하에 둔다 ── 그러한 사상으로 만들었습니다. 외국어 피드에는 로컬 LLM (Ollama)이 제목 번역과 일본어 요약을 자동으로 붙여줍니다.

スクリーンショット

그리고, 이 프로젝트의 코드는 모두 AI가 작성했습니다. 다만, "AI에게 전부 맡겼더니 알아서 완성되었다"는 이야기는 아닙니다. 사양을 결정하고, 방침을 제시하고, 기술 스택을 선택하고, 코드를 작성하게 하고, 리뷰를 돌려주고, 테스트를 작성하게 하고, 납득할 때까지 수정하게 하는 데 상당한 시간을 소비했습니다. PM 겸 아키텍트(Architect) 겸 리뷰어(Reviewer)에 가까운 역할이라고 할 수 있겠네요.

이 기사에서는 무엇을 만들었는지, 왜 만들었는지, 그리고 어떻게 만들었는지를 대략적으로 소개합니다.

계기

직접적인 트리거는 이 기사였습니다.

저도 오랫동안 사용해 온 Inoreader에 여러 불만이 있었습니다. 쓸데없이 기능이 너무 많아 사용하지 않는 아이콘 등이 열람에 노이즈가 되고, 곳곳의 폰트 사이즈 밸런스가 나빠 보기 불편하며, 번역 기능이 약하다는 점 등입니다. 항상 이전을 시도했다가 다시 돌아오기를 반복해 왔습니다.

그렇다고 해서 기사에 나온 것처럼 "그날 안에 자신이 만족할 만한 프로토타입을 만들 수 있다"고까지는 생각하지 않았습니다. AI의 능력(과 자신의 지시 능력)이 그 정도로 높다고는 생각하지 않았지만, 선구자들이 있다면 어느 정도 가능할지도 모른다는 생각에 어느 정도의 기간이면 사용할 수 있는 수준에 도달할지 실험해 보기로 했습니다. 그리고 머지않아 "도구는 각자가 AI와 협업하여 만드는 시대가 될 것이다"라는 가설을 제 손으로 직접 확인해 보고 싶었습니다. 그렇다면 시작해 보자, 는 것이죠.

왜 만들었는가

동기는 크게 세 가지가 있습니다.

1. 심플하고 쾌적한, 나만의 전용 리더가 필요했다

제가 피드 리더에 요구하는 가장 중요한 기능은 관심 있는 기사와 읽지 않는 기사를 어떻게든 고속으로 분류하는 것입니다. Inoreader는 상용 제품인 만큼 고기능이지만, 저는 기사 필터링 기능 외에는 사용하지 않습니다. 사용하지 않는 기능의 UI는 항상 사고를 방해하고 시간 효율을 떨어뜨립니다. 제가 원했던 것은 자신의 읽기 방식에만 최적화된, 불필요한 것이 없는 리더였습니다.

j / k로 기사를 넘기고, Space로 다음 미독 피드로 점프한다. 그것만 할 수 있으면 충분하며, 화면은 피드와 기사에만 집중되어 있다 ── 그러한 "내 손에 익은 도구"를 원했던 것입니다.

그렇기 때문에 제가 사용하지 않는 기능 ── 기사 검색 · 즐겨찾기 · 나중에 읽기 · 태그 지정 · 기사 전문 가져오기 · 세세한 UI 표시 옵션 · 모바일 대응 · SNS 공유 버튼 · 인증 · 다중 사용자 대응 ── 등은 구현하지 않습니다.

2. Inoreader의 세세한 불만 사항을 하나씩 해결하고 싶었다

기성품인 이상 "이 부분이 이랬으면 좋겠다"를 스스로 고칠 수는 없습니다. 요청을 보내고 본사가 반영해 주기를 기다릴 수밖에 없습니다.

직접 가지고 있다면 불만을 발견한 그 자리에서 해결할 수 있습니다. 실제로 Stingray에서 수행한 작업의 일부:

• 가져오기 시 utm_*나 fbclid 등의 트래킹 파라미터(Tracking parameter)를 자동으로 제거하여 링크를 깔끔하게 저장 - RSS를 제공하지 않는 웹 페이지도 CSS 셀렉터(Selector) 추출 규칙을 부여하면 구독 대상으로 지정 가능 - 제목 / 본문에 대한 패턴 매칭으로 읽고 싶지 않은 기사를 자동으로 걸러냄 (정규 표현식도 가능) - 피드 가져오기 간격을 자동으로 조정 (신착 기사가 계속 올라오는 피드는 짧게, 업데이트가 적은 피드는 점차 길게)

"있었으면 좋겠다" 하는 것을 기다리지 않고 자신의 손으로 구현할 수 있다. 이것이 셀프 호스트의 최대 장점입니다.

3. "도구는 각자가 AI와 협업하여 만드는 시대가 될 것이다"를 확인하고 싶었다

이것이 가장 큰 동기일지도 모릅니다.

원하는 기능을 원작(Original) 측에서 구현해 주기를 기다리는 것이 아니라, 자신의 AI에게 부탁하여 자신의 손안에서 원하는 대로 만들어 바꾼다. 그런 세상이 정말로 오는가 ── 오고 있는가 ── 를 자신의 작은 프로젝트를 통해 검증해 보고 싶었습니다.

결론부터 말하자면, (제 경우에는) 오고 있었습니다. 기술 스택(Tech Stack)은 제가 선택했고, 구현은 모두 AI에게 맡겼습니다. 이 점이 AI 주도 개발 (AI-driven development)의 가장 재미있는 부분일 것입니다. 자신이 평소에 사용하는 언어나 프레임워크에 얽매이지 않고, 해당 프로젝트에 최적인 조합을 주저 없이 선택할 수 있습니다. 거의 만져본 적 없는 스택이라도 구현을 AI가 맡아준다면 채용 후보로 올릴 수 있습니다. 저의 역할은 무엇을 채택하고 무엇을 채택하지 않을지를 결정하고, 설계에 제약을 가하며, 올라온 코드를 리뷰하는 것 ── PM 겸 아키텍트(Architect)에 가까운 것이었습니다.

따라서 Stingray는 완성품으로서 배포하기보다는, **각자가 AI로 자유롭게 확장하기 위한 베이스(Base)**로서 두려 합니다. 원하는 기능이 있다면 원작에 대한 PR(Pull Request)을 기다리는 대신, 자신의 AI에게 부탁하여 포크(Fork)를 키워나가길 바랍니다. 그런 출발점인 셈입니다.

무엇을 만들었는가

여기에 나열한 기능들은 제가 원했던 것들에 불과합니다. 바꿔 말하면, 제품의 기능 리스트가 아니라 저의 요구사항 리스트입니다. 원한다면 이루어진다는 뜻입니다 (지시·검증·조정 비용은 별개로 하더라도).

📚 피드를 모아서 읽기

RSS / Atom (RDF나 JSON Feed 포함)을 구독할 수 있습니다. 등록은 피드 URL을 직접 지정하는 것 외에도, 사이트의 메인 페이지 URL을 붙여넣으면 페이지 내의 피드 링크를 자동으로 탐지하여 가져옵니다. 피드 이름과 언어도 취득한 정보로부터 자동 판별합니다. 구독 중인 피드는 폴더로 정리할 수 있으며, 드래그 앤 드롭으로 순서를 바꿀 수 있습니다.

🔎 피드가 없는 페이지도 피드로 만들기

RSS를 제공하지 않는 웹 페이지라도, CSS 셀렉터(Selector) 추출 규칙을 부여하면 구독할 수 있습니다. 페이지 내의 어느 부분을 기사의 단위로 간주할지, 어디에서 제목·링크·날짜·썸네일을 가져올지를 지정하면 ── 일반적인 피드와 마찬가지로 목록에 흘려보낼 수 있습니다.

🧹 노이즈를 줄이는 필터

제목 또는 본문에 대한 패턴 매칭으로 읽고 싶지 않은 기사를 자동으로 제외합니다. 단순한 키워드 (부분 일치·대소문자 무시) 외에도, /.../로 감싸면 정규 표현식(Regular Expression)을 사용할 수 있습니다. 규칙은 JSON으로 import / export 할 수 있습니다.

🤖 LLM을 이용한 제목 번역과 요약

로컬의 Ollama를 사용하여 외국어 기사의 제목을 일본어로 번역하고, 본문은 짧은 요약으로 대체합니다. 짧은 기사에서는 요약 대신 본문 번역을 저장하기도 합니다. 등록 시 피드의 언어를 판정하여, 모국어(일본어)와 다른 (또는 판정할 수 없는) 피드는 번역·요약을 세트로 자동 On 합니다. 모국어로 판정된 피드는 둘 다 Off 상태이므로, 요약이 필요할 때만 수동으로 On 합니다. 번역·요약은 모두 나중에 피드 단위로 전환할 수 있습니다.

이것들은 페치(Fetch) 단계에서 한꺼번에 생성하여 기사에 저장하므로, 열었을 때는 이미 완성되어 있습니다. 클라우드 LLM은 사용하지 않으므로 API 키도 과금도 필요 없습니다.

참고로, LLM을 앱 본체에 내장하지 않고 별도 프로세스인 Ollama에 처리를 맡기는 이유는 코드베이스를 가볍게 유지하기 위해서입니다.

📖 읽기 · 따라잡기

• 읽음 / 안 읽음 관리 ── 토글로 전환. "○시간보다 오래된 것만"과 같은 조건부 일괄 읽음 처리도 가능
• 키보드 조작 ── j / k로 기사 이동, Space로 다음 안 읽은 피드로. ?로 목록 표시
• OPML import / export ── 다른 리더기로의 이행이나 백업용. 폴더 구성·번역/요약 설정·추출 규칙까지 포함하여 입출력
• 리치한 표시 ── 썸네일이나 이미지를 가져오며, Twitter / X의 임베딩은 읽기 쉬운 카드로 정형화

⏱️ 자동으로 수집하기

피드 취득은 백그라운드에서 자동으로 실행됩니다. 취득 간격은 피드마다 자동 조정됩니다 (대략 10분~6시간). 스케줄러(cron)는 15분마다 실행되며, 취득 기한이 된 피드만 가져옵니다. 수동 업데이트도 가능합니다.

만들어 보니

실제로 Inoreader에서 직접 만든 리더로 갈아타는 데 거의 일주일이 걸렸습니다. 그 후에도 매일 사용하면서 기능을 추가하고, 버그를 수정하며, 대략 2개월에 걸쳐 일단 동작에 거의 불만이 없는 상태로 만들어 둘 수 있었습니다. 그렇긴 해도, 상당한 시간을 투자하고 있습니다. 전체적으로 보면, 실현은 가능하지만 상당한 열정이 없으면 본전을 뽑기 어렵겠다는 것이 솔직한 심정입니다.

어쨌든 AI에게 끈기 있게 저의 의도를 설명하고, 불필요한 우회 경로를 수정하게 하고, 제대로 계획을 세우게 하고, 다른 AI에게도 리뷰를 시키는…… 식의 사이클을 끊임없이 돌렸습니다. 아마 제가 익숙한 기술 스택(Tech Stack)을 사용하여 처음부터 만들었더라도, 우회하는 일이 적은 만큼 소요된 시간 면에서는 큰 차이가 없을 것 같다는 느낌이 듭니다. 그래도 AI에게 작업을 시키는 동안 다른 업무를 진행할 수 있다는 점은 명확한 이점입니다.

제품으로서는 크롤링(Crawl)한 결과가 로컬에 저장되어 있어, 기사나 피드의 표시 전환이 매우 빨라 무척 쾌적합니다. 읽기가 귀찮아서 방치하곤 했던 영어 피드도, 대략적인 요약을 보고 흥미가 생기면 AI에게 다시 질문하는 방식으로 바뀌었습니다. 전반적으로 쾌적한 피드 생활을 보내고 있습니다.

AI가 작성한 코드라도, 내가 매일 사용하는 도구로서 다듬어 나간다면 나름대로 손에 익는다는 점은 확인할 수 있었습니다. 다만, 이것은 AI 주도 개발(AI-driven development)의 성과라기보다, 단순히 도그푸딩(Dogfooding)의 효과가 컸던 것일지도 모릅니다. 그럼에도 AI가 수정 사이클을 돌리기 쉽게 만들어 주었다는 점은 확실합니다.

아직은 다듬어지지 않았고 제 취향에 치우친 구조이지만, Stingray는 MIT 라이선스로 공개하고 있습니다. 혹시 관심이 있으시다면, 당신의 AI에게 전달하여 당신만의 전용 리더로 개조하는 베이스로 삼아주셨으면 합니다.

Discussion