블로그가 매일 아침 뉴스를 큐레이션하게 만들었다 — /feed 섹션과 cron 발행 파이프라인
목차
좋은 뉴스를 매일 손으로 모으던 걸, 블로그가 대신하게 만들었다. 그런데 자동화의 어려움은 수집이 아니라, 발행을 누가 책임지느냐에 있었다.
이 글은 블로그 제작기 시리즈의 다섯 번째 편이다. 1편에서 정적 사이트에 동적 기능을 붙였고, 4편(Cloudflare 통합 아키텍처)에서 블로그 전체를 서버리스 위에 올렸다. 여기까지가 “블로그라는 그릇을 만드는” 이야기였다면, 이번 편은 그 그릇을 매일 스스로 채우게 만드는 이야기다.
그동안 주간 뉴스는 손으로 모았다. GeekNews, Hacker News, 국내 기술 블로그를 훑고, 읽을 만한 걸 골라 요약하고, 코멘트를 달아 발행했다. 매주 반복하다 보니 이건 사람이 판단할 부분(뭘 고르고 뭐라 코멘트할지)과 기계가 할 부분(모으고 요약하고 포맷팅)이 명확히 갈렸다. 기계 몫을 떼어내기로 했다.
무엇을 만들었나
블로그에 /feed 섹션을 새로 냈다. 기존 /blog가 내가 직접 쓴 글이라면, /feed는 매일 아침 자동으로 채워지는 큐레이션 레이어다. 하루에 두 종류가 올라온다.
- IT 커뮤니티 (06:00) — GeekNews, Hacker News, 카카오·우아한형제들·네이버 D2 같은 기술 블로그
- 아침 뉴스 (06:10) — 연합뉴스, Reuters, ZDNet, ETNews 등 일반 기술·경제 뉴스
두 개의 Hermes cron 잡이 각각 웹에서 실데이터를 수집해 하루치 md 파일을 만들고, 발행 스크립트가 그걸 커밋·푸시하면 Cloudflare Pages가 배포하고, 마지막에 Telegram과 Slack으로 링크 프리뷰 카드가 날아온다. 카드를 누르면 원문으로 직행한다.
flowchart LR
C1[cron: IT 06:00] --> MD[md 생성<br/>src/data/feed]
C2[cron: 아침 06:10] --> MD
MD --> SH[publish-feed.sh<br/>pull·commit·push]
SH --> CF[CF Pages 배포]
CF --> MSG[Telegram · Slack<br/>OG 프리뷰 카드]만드는 과정에서 판단이 갈린 지점이 네 군데 있었다. 결과보다 그 결정들이 이 글의 본론이다.
발행을 cron이 아니라 스크립트에 맡겼다
처음엔 cron 잡이 수집부터 git push까지 전부 하게 하려 했다. 에이전트가 md를 쓰고, 그대로 add·commit·push까지 하면 깔끔하니까.
그런데 에이전트 루프 안에서 git을 다루는 건 생각보다 취약하다. 다른 PC에서 먼저 커밋이 올라와 있으면 rebase가 필요하고, 충돌이 나면 에이전트가 엉뚱하게 풀려다 히스토리를 흔든다. 무엇보다 매일 도는 작업이 매번 git 상태를 추론하게 두는 건 비용 낭비다. 같은 일을 LLM에게 반복해서 시킬 이유가 없다.
그래서 역할을 갈랐다. cron 잡은 md 파일 하나만 정확히 쓰고 끝낸다. 그 뒤 publish-feed.sh가 git pull --rebase --autostash → add → commit → push → 배포 폴링을 결정론적으로 처리한다. 에이전트가 판단할 필요가 없는 부분은 스크립트로 굳혔다.
이건 이 블로그를 만들며 계속 지켜온 원칙과 같다. 판단이 필요한 곳에만 LLM을 두고, 반복되는 절차는 코드로 굳힌다. 큐레이션의 “뭘 고르고 뭐라 코멘트할지”는 모델이, “어떻게 발행할지”는 스크립트가 맡는다.
뉴스 잡에 opus를 버리고 sonnet을 골랐다
처음 잡을 돌릴 때 프론티어 모델(opus급)을 물려놨다. 좋은 모델이 요약도 잘하겠거니 했다.
한 번 돌려보고 생각을 바꿨다. 이 작업은 정형화된 파이프라인이다. 웹을 검색하고, 본문을 긁고, 정해진 스키마(출처·요약·코멘트·링크)로 채워 넣는다. 여기서 프론티어 모델의 추론력은 거의 쓰이지 않는다. 요약과 한 줄 코멘트의 품질은 한 급 아래 모델(sonnet급)로도 충분히 나온다. 반대로 매일 두 번, 수십 건을 처리하는 작업에서 모델 단가와 속도는 매일 누적된다.
그래서 두 잡 모두 claude-sonnet-5로 고정했다. 밸런스가 맞았다. 이건 “좋은 모델을 쓰자”가 아니라 “작업의 성격에 모델을 맞추자”의 문제였다. 수집·요약·포맷팅은 밸런스 모델의 자리다.
여기서 한 가지 함정을 만났다. Hermes cron은 모델을 명시적으로 pin하지 않은 잡은 글로벌 모델 설정이 바뀌었을 때 과금 방지를 위해 실행을 스킵한다. 처음 잡이 조용히 스킵돼서 한참 헤맸는데, 원인은 잡이 unpinned 상태였던 것. 두 잡의 모델을 명시적으로 박아두니 해결됐다. 자동화에서 “조용한 실패”만큼 위험한 건 없다 — 안전장치가 작동한 거였지만, 그걸 몰랐으면 매일 아침 아무 일도 안 일어나는 줄도 모를 뻔했다.
유형 구분을 색이 아니라 라벨로 했다
IT 커뮤니티와 아침 뉴스, 두 유형을 시각적으로 구분해야 했다. 처음엔 이모지(💻/☀️)와 색을 다르게 줬다. 직관적이니까.
그런데 이 블로그는 단일 accent(파랑 하나) 규칙을 지켜왔다. 유형마다 색을 다르게 주는 순간 그 규칙이 깨진다. 색은 강조를 위해 아껴야 하는 자원인데, 분류에 색을 써버리면 정작 강조가 묻힌다.
그래서 색 대신 블로그 본문 H2가 쓰던 시각 언어를 재사용했다. 본문 소제목은 원래 파랑 세로막대(border-left)로 표시된다. 피드 유형 라벨도 같은 파랑 세로막대에 텍스트만 “IT 커뮤니티” / “아침 뉴스”로 다르게 뒀다. 색은 그대로 파랑 하나, 구분은 글자로. FeedTypeLabel 컴포넌트 하나로 카드 목록과 상세 페이지 양쪽에서 같은 언어를 쓴다.
이모지를 뺀 자리가 오히려 깔끔했다. 분류를 색이 아니라 텍스트로 하니 디자인의 예산이 아니라 정보의 문제로 돌아왔다.
OG 프리뷰를 대표 카드로 걸었다
큐레이션 글은 결국 읽으라고 링크를 던지는 글이다. Telegram·Slack에 발행 알림이 갈 때 링크 프리뷰가 밋밋하면 아무도 안 누른다.
각 피드 페이지(/feed/{날짜}-{유형})의 og:image를 그날 첫 번째 뉴스의 대표 OG 이미지로 걸었다. 하루치를 대표하는 한 장이 카드에 뜨고, 출처 브랜드 컬러(GeekNews 남색, HN 주황 등)를 배지로 함께 보여준다. 메신저에서 카드만 봐도 “오늘 뭐가 올라왔는지” 감이 온다.
지금과 앞으로
오늘 아침 실제로 두 잡을 돌려 end-to-end를 검증했다. IT 8건, 아침 뉴스 한 묶음이 실데이터로 수집돼 발행됐고(2026-07-11 IT 피드), 스크립트가 커밋·배포까지 끌고 갔으며 메신저 카드도 정상적으로 도착했다. 손으로 하던 주간 뉴스가 이제 매일 아침 자동으로 쌓인다.
여기까지가 1차다. /feed는 외부 뉴스를 중개하는 레이어다. 원문을 전재하지 않고 제목·요약·코멘트·원문 링크만 둔다. 다음 단계는 이 중에서 정말 좋은 주제를 골라 정식 blog 글로 승격하는 흐름이다. 큐레이션이 발행의 원료가 되고, 원료 중 일부가 완성된 글이 된다.
블로그를 만드는 일이 어느 순간 블로그가 스스로 채우게 만드는 일로 넘어왔다. 그릇을 만드는 시리즈가, 그릇이 스스로 채워지는 이야기에 도착했다.