"당신이 매일 아침 사용하는 IT 뉴스 프롬프트와, 그것을 자동으로 실행하는 방법을 알려줬으면 좋겠어"

얼마 전, 동료와 AI 이야기를 하던 중 그런 말을 들었습니다.

그래서 ChatGPT나 Claude의 스케줄링 기능을 사용하지 않고 약간의 기교를 부리고 있는, 제가 현재 사용 중인 수집원, Codex에 전달하는 프롬프트, macOS에서 매일 아침 실행하는 방법을 공개할 수 있는 형태로 정리해 보았습니다.

먼저 한 가지만 써두자면, 프롬프트만 복사한다고 해서 같은 결과가 나오지는 않습니다.

매일 같은 정보원을 관측하는 수집 처리와, Codex가 읽을 수 있는 입력 형식, 그리고 정해진 시각에 작동하는 메커니즘이 필요합니다.

분명 당신도 이 기사를 AI에게 읽히고, 각자 수집하고 싶은 장르 등 후술할 점들을 전달한다면, 저와 비슷한 IT 뉴스 수집 메커니즘을 만들 수 있을 것입니다!(AI에게 맡김)

메커니즘의 전체상

현재의 처리는 크게 5단계로 나뉘어 있습니다.

고정된 정보원으로부터 기사 취득
↓
제목, URL, 공개 일시, 짧은 설명을 JSON으로 변환
...

Python이 기사를 수집하고 선택하며, Codex는 마지막 단축화(Summarization)를 담당합니다.

Codex가 자유롭게 웹 검색을 하여 그 자리에서 기사도 선택하게 하는 구성으로는 만들지 않았습니다.

입력에 존재하지 않는 URL이나 사실을 섞기 어렵게 만들고, 취득 실패와 문장 생성 실패를 분리해서 조사하기 위해서입니다.

이 기사의 최소 구성에서는 출력을 Markdown 하나로 합니다.

목적별 랭킹이나 HTML 리더까지 포함하면 이야기가 길어지므로, 마지막에 발전 항목으로서 소개하겠습니다.

어디에서 뉴스를 모으고 있는가

현재는 20개의 고정 소스를 사용하고 있습니다.

매일 같은 장소를 관측하고 싶기 때문에, 검색 결과가 아닌 RSS, JSON API, 공식 사이트의 업데이트 정보를 우선시하고 있습니다.

일본어 기술 커뮤니티

• Zenn의 데일리 랭킹
• Qiita의 인기 기사 RSS
• Hatena Bookmark의 IT 카테고리 RSS
• GIGAZINE의 RSS

해외 개발자 커뮤니티

• Hacker News의 공식 API
• dev.to의 태그별 RSS

AI와 연구의 1차 정보

• OpenAI News
• Anthropic
• Google DeepMind
• Sakana AI
• Hugging Face Blog
• MIT News의 AI 카테고리

클라우드와 개발 기반

• AWS News Blog
• Google Cloud Blog
• Microsoft Azure Blog
• GitHub Changelog
• Cloudflare Blog
• Kubernetes Blog

일반 뉴스

• NHK
• BBC World

이전에는 X의 비공식 미러나 Reddit의 무인증 JSON 취득도 사용했습니다.

하지만 429, 403, 미러 중단이 계속되었기 때문에, 현재는 공식 블로그나 Changelog로 교체했습니다.

취득 에러를 매일 바라보는 것보다, 안정적인 1차 정보로 모으는 것이 운용하기 편했습니다.

설정은 코드에 직접 쓰지 않고 JSON으로 분리했습니다.

{
"sources": [
{
...

최소 버전으로는 처음에는 RSS만으로도 충분합니다.

Python에서는 feedparser를 사용하면 RSS와 Atom의 차이를 어느 정도 흡수할 수 있습니다.

python3 -m pip install feedparser

import feedparser
def fetch_rss(name: str, url: str, limit: int = 10) -> list[dict]:
    feed = feedparser.parse(url)
    ...

실제로는 타임아웃, 429와 5xx 재시도, 상대 URL 해결, 공개 일시의 정규화도 추가하고 있습니다.

다만, 우선은 몇 개의 RSS를 공통 JSON에 저장할 수 있다면, Codex로 전달하는 입구로서는 작동합니다.

Codex에 전달하는 JSON

수집원마다 데이터 형식이 다르기 때문에, Codex에 전달하기 전에 다음 형태로 맞춥니다.

{
"generated_for": "2026-07-26",
"items": [
...

item_id는 URL을 정규화하여 해시화한 값이어도 상관없습니다.

같은 기사를 중복해서 내보내지 않는 것과, 생성 후에 원문 기사와 대조하는 데 사용합니다.

공개 일시를 취득할 수 없는 기사를 어떻게 다룰지는 용도에 따라 다릅니다.

저의 운용에서는 뉴스 항목에서는 제외하고, 기술 기사로 읽을 경우에만 별도의 신선도 조건을 사용하고 있습니다.

실제로 사용 중인 프롬프트

현재의 프롬프트는 기사를 찾는 프롬프트가 아닙니다.

Python이 선택한 기사로부터, 표시용 짧은 일본어(한국어)를 만드는 프롬프트입니다.

공개용으로 경로 등을 일반화하면 다음과 같은 형태가 됩니다.

품질 검사와 랭킹(Ranking)이 완료된 입력 JSON으로부터, 표시용 짧은 일본어(한국어)를 만든다.
제약 사항:
- 외부 웹 검색이나 추가 취득을 수행하지 않는다
...

포인트는 기사 탐색과 일본어화(한국어화)를 하나의 프롬프트에 섞지 않았다는 점입니다.

수집원과 채택 기사를 미리 고정해 두면, 생성 결과가 바뀌었을 때 "기사 선택이 바뀐 것인지" 아니면 "문장만 바뀐 것인지"를 구분할 수 있습니다.

최소 버전으로는 품질 검사나 랭킹을 생략하고, 수집한 JSON을 그대로 입력으로 넣어도 작동합니다.

다만, 그 경우에는 오래된 기사나 유사한 기사가 섞이기 쉬워집니다.

셸 스크립트(Shell Script)에서 Codex를 호출하기

수집과 Codex 실행을 하나의 셸 스크립트로 통합합니다.

예시에서는 fetch_news.py가 입력 JSON을 만들고, Codex가 content.json을 저장합니다.

#!/bin/zsh
set -euo pipefail
ROOT_DIR="${0:A:h}"
...

--full-auto를 사용하므로, 전용 디렉토리 내에서 구동하는 것이 안전합니다.

처음에는 --dry-run에 해당하는 처리를 만들어, 입력과 저장 위치만 표시한 뒤 실제 실행을 하는 것을 권장합니다.

터미널에서는 작동하는데 자동 실행 시 실패한다면, codex의 경로를 찾지 못하고 있을 가능성이 있습니다.

launchd에서 보이는 PATH는 평소 사용하는 대화형 셸(Interactive Shell)과 같지 않을 수 있습니다.

그럴 경우에는 command -v codex로 위치를 확인하고, 스크립트 내에서 절대 경로를 사용합니다.

매일 아침 05:00에 자동 실행하기

macOS에서는 launchd를 사용합니다.

다음 plist를 ~/Library/LaunchAgents/com.example.daily-it.plist에 저장합니다.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
...

저장 후 구문을 검사하고 등록합니다.

plutil -lint ~/Library/LaunchAgents/com.example.daily-it.plist
launchctl bootstrap \"gui/$(id -u)\" \"...\"

설정을 변경한 경우에는 한 번 bootout을 한 뒤에 재등록합니다.

launchctl bootout "gui/$(id -u)/com.example.daily-it"

등록이 되었다는 것과 실제로 다음 날 아침에 작동했다는 것은 별개입니다.

첫날은 표준 출력(stdout)과 표준 에러(stderr) 로그를 확인하는 것이 안심됩니다.

야간에는 caffeinate로 Mac을 깨워두기

저의 경우, 야간에도 AI 에이전트에게 개발을 맡기는 일이 많기 때문에 Mac을 caffeinate로 유휴 상태 슬립(Idle Sleep)이 되지 않도록 설정해 둡니다.

그대로 05:00를 맞이하는 날이 많아, 뉴스 생성도 동일한 Mac에서 실행할 수 있습니다.

예를 들어, 야간 개발 스크립트가 돌아가는 동안에만 Mac을 깨워두고 싶다면 다음과 같이 합니다.

caffeinate -i zsh run-night-agent.sh

-i는 유휴 상태에 의한 시스템 슬립을 방지하며, 뒤의 명령어가 종료되면 억제도 해제됩니다.

AC 전원 연결 중에만 시스템 슬립을 방지하고 싶다면 -s도 사용할 수 있습니다.

caffeinate -s zsh run-night-agent.sh

시간을 정해서 사용하고 싶다면 초 단위로 지정할 수 있습니다.
예를 들어 8시간이라면 다음과 같습니다.

caffeinate -i -t 28800

화면까지 계속 켜둘 필요는 없기 때문에 평소에는 -d를 붙이지 않습니다.

이것은 Mac을 항상 켜두는 것을 모두에게 권장한다는 이야기가 아니라, 원래 야간 AI 개발로 인해 구동 중인 환경에 조간 뉴스 생성을 얹어서 운용하고 있다는 뜻입니다.

Mac이 켜져 있지 않았던 날은 아침에 보완하기

전원이 꺼져 있는 동안에는 당연하게도 05:00의 처리를 실행할 수 없습니다.

재부팅, 배터리 방전, 의도적인 종료도 있기 때문에 정기 실행(Scheduled execution)에만 맡기지 않는 것이 안전합니다.

그래서 아침 처리 과정에서는 당일 분량의 파일이 있는지 확인하고, 없다면 그 자리에서 생성합니다.

TODAY="$(date +%F)"
OUTPUT="output/${TODAY}-content.json"
if [[ ! -f "${OUTPUT}" ]]; then
...

제 환경에서는 기상 후 AI에게 "안녕(おはよう)"이라고 보내는 처리 과정에 이 확인 절차를 포함하고 있습니다.

매일 아침, 그날의 상황에 맞춘 데일리 노트(Daily note)를 만드는 스킬을 "안녕"으로 실행하는데, 동시에 IT 뉴스가 만들어져 있지 않다면 실행되도록 설정해 두었습니다.

야간의 caffeinate로 05:00에 실행할 수 있다면 아무것도 하지 않고, 생성되어 있지 않다면 아침에 보완하는 이중 구조입니다.

개인화(Personalize)해 나가는 부분

각자의 취향에 맞춰 나갈 경우, 코드보다 먼저 다음 사항들을 구상하여 AI에 반영하는 것이 좋습니다.

• 몇 시에 읽고 싶은가
• AI, 클라우드, Web 개발 등 추적하고 싶은 분야
• 국내 기사와 해외 기사의 비율
• 하루에 읽고 싶은 건수
• 입문용 기사를 포함할 것인가
• 한 줄 요약만으로 충분한가
• "왜 읽어야 하는가", "다음에 할 일"도 필요한가

정보원을 늘린다고 해서 반드시 좋아지는 것은 아닙니다.

매일 아침 읽을 수 있는 건수와, 수집 실패를 수정할 수 있는 범위부터 시작하는 것이 꾸준히 유지하는 비결입니다.

마치며 — 이 최소 구성의 한계

RSS의 설명문만으로는 기사 본문의 세세한 주장까지 확인할 수 없습니다.

배포된 날짜가 최초 공개일이 아닌 업데이트 날짜인 경우도 있습니다.

제목이 크게 다른 동일 이벤트는 URL 중복만으로는 제외할 수 없습니다.

또한, 이 구성은 "목적에 따라 선택하기", "이용 후의 평가를 통한 개선" 단계까지는 포함하지 않습니다.

그 단계까지 수행하려면 품질 게이트(Quality gate), 목적별 랭킹, 일반판과 개인화 버전, 이유가 포함된 피드백 등을 추가해야 합니다.

우선은 고정된 소스를 JSON으로 변환하고, 동일한 프롬프트로 매일 아침 생성하며, 실패 내용을 로그(Log)로 남기는 단계까지 만드는 것입니다.

이 형태라면 프롬프트만 전달하는 것보다 재현하기 쉽고, 각자의 취향에 맞춰 변경할 수 있습니다.

더욱 고안하고 있는 점은, 동료가 물어보고 수요가 있다면 기사로 작성할지도 모른다는 것입니다.

이제 정보 수집이나 뉴스 요약은 AI에게 맡기는 사람이 많을 것입니다.

또한 그 방법 역시 스킬이나 프롬프트, 다양한 노하우가 있을 것이라 생각합니다.

부디 뉴스 생성 계열의 추천하는 스킬이나 노하우, 추천 기사가 있다면 꼭 알려주세요.

저도 아직 개선할 점이 많다고 생각합니다. 그럼, 여기까지 읽어주셔서 감사합니다.

분명 이 글을 읽고 있을 동료를 향해
"이 뒷부분은 유료입니다, 라고는 말하지 않을 테니 읽고 싶다면 댓글이나 하트, 혹은 전파(布教)를 부탁드립니다"

Discussion