소개
시도하고자 했던 것과 그 이유
에너지기업 CTO 관점에서 매일 확인해야 하는 전력·에너지 신기술과 정책 뉴스는 여러 매체에 흩어져 있는 기사를 취합해서, 중복 보도를 걸러내고, 향후 예상되는 영향과 후속 조치를 정리해서, 데일리브리핑을 만들고 메일로 받아보고자 하였습니다.
처음에는 std02 폴더에 다음 기능을 갖춘 로컬 프로그램을 만들었습니다.
- Google News RSS 검색어 11개로 국내외 전력·에너지 뉴스 수집
- 월요일 84시간, 화요일부터 금요일 36시간 범위 적용
- 유사 기사 중복 제거와 발행 매체 통합
- 후보 최대 40건, 상세 브리핑 최대 12건 선별
- 기사별 주요 내용, KEPCO 시사점, CTO 관점 액션 작성
- HTML/TXT 보고서 생성과 SMTP 이메일 발송
- Windows 작업 스케줄러를 이용한 평일 오전 7시 실행
- 설정, 수동 실행, 최근 보고서와 로그 확인을 위한 웹 대시보드
진행 방법
진행 개요
로컬 프로그램의 기능은 충분했지만 노트북이 꺼져 있으면 예약 시각에 실행할 수 없다는 한계가 있었습니다. 스터디장님이 알려주신 스킬과 플러그인으로 해결해보고 싶었습니다.
그래서 (1) gmail 플러그인을 설치하고,
(2) 로컬 프로그램의 검색 기준과 보고서 구조를 Codex 스킬로 옮기고, 클라우드 예약 작업에서 실행할 수 있도록 다음 두개의 스킬을 아래와 같이 분리했습니다.
- $cto-daily-briefing: 최신 뉴스를 조사하고 CTO 브리핑 이메일 패키지 작성
- $cto-daily-briefing-send: 완성된 패키지를 연결된 Gmail 계정으로 발송
작성과 발송을 분리한 이유는 수집 실패나 불완전한 보고서가 자동으로 이메일 발송되는 것을 막기 위해서입니다. 최종 목표는 노트북을 켜놓지 않아도 평일 오전 7시에 브리핑을 작성하고, 검증 조건을 통과한 경우에만 이메일로 보내는 것입니다.
(3) 마지막으로 두개의 스킬을 예약에 연속으로 실행시키도록 등록하였습니다.
어떤 도구를 사용했고, 어떻게 활용하셨나요?
- ChatGPT/Codex: 요구사항을 구체화하고 Node.js 프로그램, 테스트, 웹 UI, 실행 스크립트, 스킬과 예약 프롬프트를 작성했습니다.
- Node.js 18 이상: 로컬 단계에서 RSS 요청, 기사 본문 추출, 중복 제거, 중요도 계산, 보고서 생성과 SMTP 발송을 구현했습니다.
- Google News RSS: 로컬 프로그램의 주요 뉴스 후보 수집원으로 사용했습니다.
- HTML/CSS/JavaScript: 검색 조건, 수신자, SMTP 상태, 최근 보고서와 로그를 확인하는 운영 대시보드를 만들었습니다.
- Windows 작업 스케줄러: 로컬 프로그램을 평일 오전 7시에 실행하도록 구성했습니다.
- Codex Skill Creator: 로컬 프로그램의 검색 기준과 보고서 작성 절차를 재사용 가능한 개인 스킬로 만들고 유효성을 검사했습니다.
- Codex Scheduled Tasks: 로컬 폴더를 사용하지 않는 클라우드 예약 실행 구조를 설계했습니다.
- 웹 검색 및 원문 확인: 클라우드 작성 스킬에서 최신 기사와 공식 발표를 수집하고 수치·날짜·출처를 검증하도록 했습니다.
- Gmail 플러그인: 로컬 SMTP 대신 클라우드에서 인증된 Gmail 계정으로 수신자별 독립 발송을 수행하도록 설계했습니다.
- Node.js 내장 테스트 러너: 중복 제거, 요약 문장 경계, 월요일 수집 범위, 데이터센터 기사 편중 방지 등을 검증했습니다. 현재 자동 테스트 18개가 모두 통과합니다.
기존의 로컬 프그램을 클라우드 예약용 스킬 전환
로컬 프로그램을 그대로 예약하면 노트북 전원과 로컬 파일에 계속 의존하게 됩니다. 따라서 스킬에는 로컬 경로나 실행 명령을 넣지 않고 다음 기준 자체를 내장했습니다.
- 기존 검색어와 우선 키워드
- 월요일 84시간, 화~금요일 36시간 수집 원칙
- 후보 40건과 상세 12건 목표
- 동일 사건 통합과 복수 매체명 보존
- AI·데이터센터 기사 비중 제한
- 전력망, 요금·규제, ESS·VPP, 무탄소 전원, AI 활용, 공급망 관점의 분류
- 기사별 주요 내용, KEPCO 시사점, CTO 액션 작성 규칙
- 공식 발표와 원문을 우선하는 검증 기준
한국어 문자 메시지 스크린샷
클라우드 실행 흐름은 다음과 같습니다.
```text
Codex 클라우드 예약 작업
↓
$cto-daily-briefing
↓
웹 검색과 원문 검증
↓
중복 제거·주제 균형·CTO 관점 분석
↓
<CTO_DAILY_BRIEFING_EMAIL> 패키지 생성
↓
완성 조건 검사
↓
$cto-daily-briefing-send
↓
Gmail 수신자별 개별 발송
```
테스트와 보완
최초 스킬은 최근 36시간 내 검증 가능한 상세 기사를 최소 6건 확보하지 못하면 BRIEFING_NOT_READY를 반환하도록 했습니다. 실제 독립 테스트에서는 검증 가능한 기사가 기준에 미달해 이메일 패키지가 생성되지 않았습니다.
이 결과를 바탕으로 다음과 같이 보완했습니다.
1. 기본 수집 범위에서 6건 미만이면 최근 72시간으로 확장합니다.
2. 그래도 부족하면 최근 7일까지 확장합니다.
3. 확장 구간의 기사는 보충 자료 로 명시합니다.
4. 검증 가능한 기사가 4건 이상이면 축약 브리핑을 만듭니다.
5. 4건 미만이면 오래된 보고서를 재사용하지 않고 발송을 중단합니다.
보완 후 독립 테스트에서는 최근 7일 범위에서 검증 가능한 기사 4건을 확보해 축약 이메일 패키지를 정상 생성했습니다.
한국어 이메일 앱 스크린샷
한국어 웹사이트의 스크린샷
예약기능에 등록
부족한 기능이지만, 향후 클라우드 기반으로 반복 작업을 실행시키기 위해서, "예약" 기능에 위에서 만든 2개의 스킬( /CTO일일브리핑작성, /CTO일일브리핑발송)을 연속적으로 실행되도록 등록하였습니다.
한국어 앱 스크린샷
결과와 배운 점
1. 로컬 크롤러와 클라우드 웹 검색은 같은 검색어를 사용해도 결과가 같지 않습니다. RSS는 여러 검색 결과를 대량으로 가져올 수 있지만, 클라우드 웹 검색은 검색 색인, 노출 순위, 원문 접근 가능성의 영향을 받습니다.
2. 기사 수와 검증 수준 사이에 균형이 필요합니다. 기사 수를 늘리기 위해 검색 결과 요약문만 사용하면 정확도가 낮아지고, 모든 기사를 원문 기준으로 엄격히 확인하면 수집량이 크게 줄어듭니다.
3. 스킬은 프로그램 코드를 그대로 옮기는 작업이 아닙니다. 로컬 코드의 결정적 로직을 자연어 절차, 실패 조건, 출력 계약으로 바꿔야 예약 실행마다 결과가 일관됩니다.
4. 작성과 외부 전송은 분리하는 것이 안전합니다. 브리핑 생성 실패, 날짜 불일치, 링크 누락을 발송 전에 차단할 수 있습니다.
5. 실패도 정상 결과로 설계해야 합니다. 조건을 충족하지 못했을 때 오래된 브리핑을 보내는 것보다 BRIEFING_NOT_READY를 남기는 편이 안전합니다.
6. 완전한 무인 운영에는 실행 환경뿐 아니라 데이터 접근 방식도 바뀌어야 합니다. 노트북 전원 문제는 클라우드 예약으로 해결할 수 있지만, 로컬 RSS 수집량을 재현하려면 클라우드에서 사용할 수 있는 뉴스 API나 RSS 도구가 추가로 필요합니다.
앞으로의 계획이 있다면 들려주세요.
1. 최소 2주 동안 로컬 프로그램과 클라우드 스킬을 같은 시각에 병행 실행해 기사 수와 핵심 기사 일치율을 비교합니다.
2. 웹 검색 외에 클라우드에서 사용할 수 있는 RSS, 뉴스 API 또는 전용 MCP 도구를 검토합니다.
3. 검색 주제를 한전 직접 이슈, 전력망, 요금·규제, ESS·VPP, 무탄소 전원, AI 활용, 해외 공급망으로 나눠 주제별 최소 후보 수를 확보합니다.
4. 원문 확인률과 출처별 성공률을 기록해 검색어와 출처 우선순위를 조정합니다.
5. 최근 7일 확장 기사의 허용 비중과 축약 브리핑 발송 기준을 실제 운영 결과에 맞춰 조정합니다.
6. 작성 결과를 날짜별로 클라우드 저장소에 보관해 일간·주간·월간 변화와 과거 판단을 추적할 수 있도록 합니다.
7. 충분한 비교 데이터가 쌓이면 로컬 프로그램을 종료하고 클라우드 예약 스킬로 완전히 전환할지 결정합니다.
앞으로의 계획이 있다면 들려주세요.
현재 단계는 로컬 자동화의 업무 규칙을 클라우드 스킬로 옮기는 데는 성공했지만, 기사 수집량과 원문 접근성은 추가 보완이 필요한 상태입니다. 완성된 시스템으로 단정하기보다 로컬 결과를 기준선으로 삼아 수집 품질을 비교하고 개선해보겠습니다.
