개인 도구에서 제품으로 — AI 뉴스봇 확장기
이 글은 AI 뉴스봇을 이틀 만에 만들었다의 후속편입니다. 요약하면: 코딩 에이전트 Harry와 함께 개인용 AI 뉴스 큐레이터를 만들고, 15번 넘게 반복하면서 슬롯 기반 v2 랭킹 엔진을 완성해서 매일 텔레그램으로 다이제스트를 받고 있었습니다.
v2 엔진은 안정적이었고 결과물도 괜찮았어요. 실제로 쓰고 있었습니다.
그러다 당연한 질문이 떠올랐어요: 이걸 왜 나만 쓰지?
라이브 피드는 여기서 확인할 수 있어요: llm-digest.com
파이프라인 강화
공개하기 전에 파이프라인을 더 단단하게 만들어야 했습니다. Harry한테 전체 시스템을 처음부터 끝까지 리뷰하고 뭘 고쳐야 하는지 알려달라고 했어요.
고친 것들:
- 설정 프리셋 — 모든 설정값을 이해하지 않아도 튜닝할 수 있도록 표준화된 설정
- 상세한 진단 정보 — 매 실행마다 슬롯 우선순위, LLM 사용량, 소스 상태, 타이밍 분석을 상세하게 기록
- Git 정리 — 추적되는 런타임 아티팩트 정리,
.gitignore정비 - 슬롯 쿼터 재조정 — 전체 아이템 수 증가, 슬롯별 할당량 조정
개별적으로는 작은 것들이에요. 하지만 “내 컴퓨터에서는 돌아감”과 “안정적으로 돌아감” 사이의 차이를 만드는 것들입니다.
Vercel 전환
Harry한테 물어봤어요: “이걸 Vercel에 배포해서 다른 사람들도 피드를 볼 수 있게 하면 어때?”
보통이라면: 데이터베이스 세팅, API 만들기, 서버 배포. Harry는 더 간단한 방법을 제안했습니다: GitHub을 콘텐츠 저장소로 쓰자.
생각해보면 — 피드 아티팩트(다이제스트, 처리된 JSON, 진단 정보)는 이미 레포에 있어요. 매 실행마다 업데이트됩니다. 그 파일들을 읽어서 렌더링하는 정적 사이트만 있으면 돼요.
그래서 만드는 중입니다: 이 블로그와 같은 Astro 엔진으로 피드를 웹 페이지로 제공하는 정적 사이트. GitHub이 데이터베이스. Vercel이 push할 때마다 자동 배포. 관리할 서버 없음.
브라우저로 소스 탐색하기
여기서 재미있어졌어요. RSS 피드 너머로 X, Medium, Substack에서 콘텐츠를 찾고 싶었습니다. 보통이라면 API 연동을 하겠죠. 근데 API는 토큰, 속도 제한, 지속적인 관리가 필요해요.
대신, Harry한테 제 계정에 브라우저 접근 권한을 주고 말했습니다: “직접 돌아다니면서 좋은 소스 찾아봐.”
찾은 것들
Medium — 제 팔로잉 피드에서 좋은 엔지니어링 퍼블리케이션이 나왔어요:
- Netflix TechBlog
- Airbnb Tech Blog
- Pinterest Engineering
인사이트: 원시 팔로잉 피드가 아니라 퍼블리케이션 단위 화이트리스트를 써야 합니다. 팔로우 중인 것에 노이즈가 너무 많아요.
Substack — 가장 강한 시그널. 홈 스트림에서:
- Alberto Romero (The Algorithmic Bridge)
- Steve Yegge
- Kent Beck
고품질, 저노이즈. 피드에 추가하면 확실히 좋아질 소스들.
X — 쓸 만하지만 시끄러워요. 핫테이크와 진짜 인사이트가 섞여 있어서 훨씬 빡빡한 필터링이 필요합니다.
결정: 소셜 플랫폼 수집기는 나중으로. RSS 기반 소스가 이미 충분히 강하고, 소셜 플랫폼을 추가하면 복잡도(인증, 속도 제한, 콘텐츠 추출)가 아직은 가치 대비 과해요. 하지만 준비됐을 때 어디를 봐야 할지는 정확히 알고 있습니다.
스케줄링: 클라우드 떠나기
파이프라인은 원래 GitHub Actions에서 돌았어요 — 크론 트리거, 간단. 근데 문제가 있었습니다: LLM 연동이 로컬 OAuth(pi-ai)를 쓰는데, GitHub Actions 러너에서는 안 돌아요.
그래서 스케줄링을 전부 로컬 크론으로 옮겼습니다. OpenClaw이 관리:
- 09:00 KST — 아침 다이제스트
- 12:00 KST — 점심 리프레시
- 19:00 KST — 저녁 다이제스트
하루 세 번. 이 분야가 움직이는 속도를 생각하면 충분히 정당합니다.
GitHub Actions는 수동 트리거용으로 남겨뒀지만, 일상적인 실행은 완전히 로컬입니다.
자동 배포 루프 완성하기
예상 못 한 문제: 로컬 크론 실행이 Vercel 배포를 트리거하지 않는다는 것.
파이프라인이 로컬에서 돌고, 다이제스트 파일을 업데이트하고, 텔레그램과 GitHub Issues에 발행합니다. 하지만 Vercel은 main에 push가 있을 때만 배포해요. 로컬 실행은 아무것도 push하지 않았습니다.
Harry의 수정은 깔끔했어요:
파이프라인 실행
↓
다이제스트 빌드
↓
git pull --rebase --autostash (동기화 유지)
↓
변경된 아티팩트 커밋
↓
main에 git push
↓
Vercel 자동 배포 트리거
↓
텔레그램 + GitHub Issue 발행
이제 매 크론 실행 → git push → Vercel 재배포 → 공개 웹 피드 업데이트. 루프 완성.
킬 스위치도 추가: AUTO_PUSH_RUNTIME=0으로 배포 없이 실행 가능.
패턴
하루 만에 이 프로젝트가 “나한테 메시지 보내주는 개인 도구”에서 “공개 웹 프레즌스, 하루 3회 자동 리프레시, 로컬 실행과 클라우드 배포가 연동되는 콘텐츠 파이프라인을 갖춘 배포 가능한 제품”이 됐습니다.
같은 패턴이 계속 반복됩니다:
- 먼저 자기를 위해 만들어라. “사용자”를 생각하지 말고, 자기 문제를 풀어라.
- 결과물이 좋을 때까지 반복해라. 코드가 아니라 — 결과물. 실제로 보고 쓰는 것.
- 작동할 때만 일반화해라. 개인용에서 공개용으로의 점프는 기반이 탄탄하면 작아야 한다.
- 아키텍처는 지루하게 유지해라. GitHub이 데이터베이스. Vercel에 정적 사이트. 크론 잡. 쿠버네티스 없음. 메시지 큐 없음. 마이크로서비스 없음.
지루한 스택이 배포되는 스택입니다.
다음은
- 웹 피드 — 일일 다이제스트를 제공하는 공개 Astro 사이트 (진행 중)
- RSS 출력 — 다른 사람들이 자기 리더로 구독할 수 있도록
- 다국어 요약 — 같은 콘텐츠, 한국어와 영어 버전
- 더 많은 소스 — ROI가 명확해지면 Substack, Medium 연동
- 오픈소싱 — 거친 부분을 다듬으면, 파이프라인 전체가 다른 사람들에게도 유용할 수 있을 것
도구는 계속 자라고 있어요. 하지만 시작은 중요한 뉴스를 놓치고 있던 한 명의 엔지니어였습니다. 나머지는 거기서 따라왔습니다.