뉴스 수집 때마다 AI를 깨울 필요는 없었습니다 — AI와 일하는 방식

2026년 9월 18일, 뉴스 수집기를 맥미니에서 리눅스 서버로 옮겼습니다. 이전에는 예약 작업 하나가 두 시간마다 Hermes를 불렀습니다. 하루 열두 번 에이전트를 실행해 뉴스를 모으고, 그중 아침저녁에는 브리핑을 썼습니다.

옮긴 뒤에는 수집만 하는 열 번을 Python 스크립트에 맡기고, 정식 브리핑을 쓰는 오전 8시와 오후 8시에 Hermes를 부르도록 나눴습니다. 바꾼 것은 예약 항목의 개수보다 각 시각에 실행할 작업이었습니다. 아래 내용은 이관 당일 운영 기록과 설치 결과를 중심으로 다루고, 우체통 연결은 9월 20일 후속 시험까지 살펴봅니다.

하루 열두 번 실행하는 예약 하나였습니다

‘하루 열두 번’과 ‘크론 열두 개’는 다른 수입니다. 당시 운영 기록에는 기존 뉴스 작업이 하나의 예약으로 등록돼 있었습니다. 두 시간마다 같은 작업을 실행하니 하루에 열두 번이 된 것입니다.

수집과 집필을 분리한 뒤의 정식 뉴스 작업은 다음과 같습니다.

구분	이전 구성	이관 후 구성
수집만 하는 시각	Hermes 실행	Python 수집 10회
아침저녁 브리핑	같은 예약 안에서 처리	Hermes를 오전 8시와 오후 8시에 실행
작업 시각 관리	기존 에이전트 예약	Python 실행표와 브리핑 예약을 분리

이 표는 정식 뉴스 작업의 예약 구성을 비교합니다. 서버 전체의 에이전트 실행 횟수나 API 호출 횟수를 센 표는 아닙니다. 같은 서버에는 다른 업무와 Claude 비교 브리핑도 별도로 예약돼 있었습니다. 한 번의 에이전트 실행에서도 모델을 여러 차례 부를 수 있으므로 예약 횟수만으로 토큰 사용량을 계산할 수는 없습니다.

Python은 10분마다 실행표를 봅니다

서버의 운영체제 크론에는 10분마다 Python 실행기를 부르는 항목을 등록했습니다. 설치 결과 보고서에 등록한 명령과 최초 확인 결과가 남아 있습니다. 이 실행기는 마크다운 표에서 어떤 작업을 언제 실행할지 읽습니다. 정해진 시각에 하는 작업과, 이전 처리 결과에 따라 확인 간격을 바꾸는 작업을 같은 표에서 다루도록 만든 구조입니다.

뉴스 수집의 시각은 표의 행으로 나눴습니다. 정해진 실행 시각이 됐을 때 수집 스크립트가 사이트에서 자료를 가져오고, 이후 브리핑 작업이 그 자료를 읽습니다. 시간표를 확인하는 단계부터 언어 모델이 판단할 필요는 없습니다.

다음은 이 구조를 설명하기 위한 예시입니다. 실제 운영표의 경로나 전체 항목을 옮긴 것은 아닙니다.

작업	다음 실행 기준	맡는 프로그램
새 기사 수집	실행표에 적은 수집 시각	Python
브리핑 작성	오전 8시와 오후 8시	Hermes
실행 여부 확인	10분 간격	Python 실행기

크론은 실행기를 부르고, 실행기는 작업표를 읽습니다. 사람이 고칠 수 있는 표에 시각을 두면 새 수집 작업을 추가할 때 실행 명령과 시간 조건을 함께 살펴볼 수 있습니다. 다만 읽기 쉬운 표를 만들었다는 사실이 실행 성공을 보장하지는 않습니다.

등록과 실행 결과는 따로 확인해야 했습니다

9월 18일 오후 설치 결과에는 수동 수집에서 일곱 소스를 확인하고 새 항목 여덟 개를 가져온 기록이 남았습니다. 반면 실행기 전체를 바로 돌린 확인은 240초 타임아웃으로 끝났습니다. 그 보고서 작성 시점에는 성공 로그와 다음 실행 시각을 다시 쓴 증거가 없었습니다.

그래서 크론 등록이 됐다는 결과와 수집부터 다음 예약 갱신까지 끝났다는 결과를 나눠 봐야 합니다. 처음 실행이 멈췄는데도 ‘10분마다 안정적으로 돈다’고 설명할 수는 없습니다. 이 설치 보고서에서 확인할 수 있는 것은 예약을 등록했고, 수집 스크립트를 별도로 실행해 결과를 만들었다는 데까지입니다. 이후 회차나 현재 서버 상태까지 판정한 결과는 아닙니다.

기사 선별을 로컬 모델에 맡기는 단계도 당시에는 설계와 실행 상태가 달랐습니다. 연결 시험이 타임아웃으로 끝나 9월 18일 후속 결과 보고서는 이 단계를 비활성 상태로 남겼습니다. Python 수집 뒤에 로컬 모델과 클라우드 모델을 차례로 두려는 구상이 곧 완성된 운영 결과는 아니었습니다.

우체통은 깨우는 방법까지 확인해야 합니다

2026년 봄에는 AI들이 폴더에 편지를 남기고 답을 이어 쓰는 우체통을 운영했습니다. 9월 18일 구술을 정리한 우체통 설계 기록에는 실행 시점이 어긋나고 검수가 늘어져 며칠 뒤 사람이 잊는 문제가 남아 있습니다. 받은 편지를 실행 지시로 받아들여야 하는지도 분명하지 않았습니다.

새 실행기에 우체통을 붙이는 설계는 이런 문제를 다루려는 후속 작업이었습니다. Python이 새 편지를 확인하고 필요한 모델을 호출하도록 하되, 편지가 있다는 알림과 작업을 실행할 권한은 나눠야 합니다.

이 연결은 뉴스 수집기 이관과 함께 완료된 일이 아닙니다. 같은 설계 기록의 9월 20일 갱신에는 봇이 Slack 메시지를 보내 Hermes를 깨우는 시험을 했지만, 10분을 기다려도 반응이 없었다고 남아 있습니다. 메시지 전송에 성공했다는 사실만으로 다음 에이전트가 일을 시작했다고 판단할 수 없었습니다.

운영비 비교에는 실행 기록이 더 필요합니다

크론이 시간표를 확인하는 비용과 그때 실행되는 프로그램의 비용은 나눠 측정해야 합니다. 9월 18~20일의 근거 기록에는 예약 항목 수에 따른 부하 비교나 실행표 확인 시간의 측정값이 없습니다. 로컬 모델도 하드웨어와 전력을 쓰므로 ‘전기값만 든다’는 표현으로 전체 운영비를 설명하기 어렵습니다.

전후 비용을 비교하려면 같은 기간의 모델 사용량, 수집 완료 기록, 작업 시간과 재시도도 봐야 합니다. 비교용 브리핑을 추가로 돌린 비용 역시 따로 셀 필요가 있습니다. 이관 기록으로 설명할 수 있는 변화는 수집 전용 열 번의 예약에서 Hermes 대신 Python을 실행하도록 역할을 나눈 것입니다.

저 김반장의 작업대는 MD와 Google Drive입니다

실행 시각은 마크다운 표에, 실제 수행 결과는 별도 기록에 남겼습니다. 표에 적은 계획과 결과 보고서를 함께 읽어야 등록한 작업이 어디까지 실행됐는지 알 수 있습니다. 이번 글도 두 문서를 대조하면서 운영한 것과 아직 연결하지 못한 것을 나눴습니다.

이러한 AX 과정을 think-designer에서는 MD와 Google Drive로 일하는 방법을 중심으로, AI 대장간 ‘더포지’(the-forge.kr) 커뮤니티에서는 실제 업무를 중심으로 이야기합니다.