## 📝 한줄 요약
관리 대상 상장기업이 많아질수록 DART를 회사별로 열어보는 방식은 금방 한계에 부딪힌다. 최종 목표는 관련 기업의 주요 공시를 매시간 자동으로 스크리닝하고, 본문 요약과 원문 링크를 담당자에게 보내는 것이다. 이번에는 공개 상장기업 1곳을 대상으로 하루 3회 실행하는 Hermes Skill을 만들어 조회·요약·Telegram 전송까지 먼저 검증했다.
바쁘시면 이것만 읽어도 돼요:
- 목표는 여러 관리 대상 상장기업의 주요 공시를 매시간 자동 스크리닝하는 것이다.
- 첫 단계에서는 공개 상장기업 1곳과 하루 3회 일정으로 범위를 줄였다.
- 접수번호를 기준으로 이미 확인한 공시를 구분했다.
- 공시가 없으면 “없음”, 확인하지 못하면 not_checked로 처리했다.
- 새 공시는 DART 본문을 열어 핵심 내용 2~4개로 요약하고 Telegram으로 보낸다.
- 다수 기업·매시간 운영과 실제 신규 공시의 연속 중복 제거는 아직 not_checked다.
## 🎯 이런 분들께 도움돼요
- 여러 상장기업을 동시에 관리하는 회계·재무·투자 실무자
- 실사나 사후관리 과정에서 주요 공시를 빠르게 선별해야 하는 사람
- “확인했지만 없음”과 “조회 실패”를 구분해야 하는 사람
- 원문 링크만 모으는 데서 그치지 않고, 업무에 필요한 내용을 먼저 요약받고 싶은 사람
## 😫 문제 상황 (Before)
업무를 하다 보면 한 회사만 보는 경우보다 여러 회사를 동시에 관리하는 기간이 더 많다. 회사 수가 늘어나면 DART 검색도 그대로 늘어난다. 회사명을 하나씩 검색하고, 새 공시가 있는지 보고, 정정공시인지 확인한 다음, 다시 본문을 열어 금액과 날짜를 읽어야 한다.
실무에서 필요한 것은 모든 공시의 단순 나열도 아니다. 공급계약, 자금조달, 소송과 제재, 거래정지, 감사의견, 주요 자산 거래처럼 판단에 영향을 줄 수 있는 공시를 먼저 보고 싶다. 정정공시라면 무엇이 바뀌었는지도 바로 알아야 한다.
내가 만들고 싶은 최종 모습은 명확했다.
> 관리 대상 상장기업 목록을 기 준으로 DART를 매시간 확인하고, 새로 접수된 주요 공시만 선별해 본문을 요약한 뒤 담당자에게 자동 발송한다.
다만 처음부터 여러 회사와 매시간 실행을 한꺼번에 붙이면 어디서 문제가 생겼는지 찾기 어렵다. 그래서 공개 상장기업 1곳과 하루 3회 조회로 시작했다. 회사 이름은 사례글에서 공개하지 않는다.
## 🛠️ 사용한 도구
- 에이전트: Hermes Agent
- 모델: GPT-5.6 Sol
- 원천 데이터: 금융감독원 전자공시시스템 DART
- 자동 실행: Hermes Cron Jobs
- 결과 전달: Telegram Bot
- 검증 범위: 공개 상장기업 1곳, 하루 3회
- 목표 범위: 관리 대상 상장기업 다수, 매시간 주요 공시 스크리닝
- 보안 원칙: 회사별 내부 관리정보, Bot Token과 사용자 식별값은 사례글에 포함하지 않음
---
## 🔧 작업 과정
### 1. 큰 목표를 한 종목짜리 Skill로 줄였다
처음 요청은 짧았다.
```text
대상회사 DART 공시를 조회하여 새로운 공시 사항이 올라왔는지 확인
```
여러 회사를 한 번에 다루기 전에 한 곳을 정확히 조회하는 작은 Skill부터 만들었다. 목표 조회 시각은 09:30·13:30·17:00 KST로 정했다. 정정공시를 제외하지 않고, 신규 공시가 없더라도 조회 완료 시각을 남기도록 했다. DART 접속이나 회사 식별에 실패하면 “공시 없음”으로 넘기지 않고 not_checked로 표시하게 했다.
업무 기준은 7개 필드로 나눴다.
1. Use when: 언제 실행할지
2. Input: 회사 식별정보와 기존 접수번호 등 무엇이 필요한지
3. Judgment: 어떤 공시를 포함하고 무엇을 미확인으로 둘지
4. Steps: 어떤 순서로 조회하고 비교할지
5. Output: 결과를 어떤 형식으로 보여줄지
6. Verification: 무엇을 확인해야 완료인지
7. Failure repair: 실패하면 무엇을 갱신하지 말아야 하는지
이 단계에서는 자동 발송까지 욕심내지 않았다. 공개 상장기업 1곳을 대상으로 DART 조회가 제대로 되는지부터 확인했다.
---
### 2. 공시가 0건인 첫 실행에서 중복 기준의 허점을 찾았다
2026년 7월 25일 첫 실행에서는 당일 신규 공시가 없었다.
> 신규 공시 없음 — 2026-07-25 14:34 KST 기준 확인 완료
0건도 필요한 결과였다. “검색했지만 없음”과 “검색하지 못함”을 구분할 수 있기 때문이다.
첫 실행에서는 Skill의 허점도 드러났다. 초안은 “직전 조회 시각 이후”의 공시를 찾도록 작성했다. 그런데 DART 기본 검색표에는 접수시각이 아니라 접수일자만 보였다. 같은 날짜에 여러 번 확인하거나 앞으로 매시간 조회한다면 시각만으로는 신규 문서를 안정적으로 구분하기 어렵다.
전체 Skill을 다시 쓰는 대신 신규 판정 규칙만 고쳤다.
- 수정 전: 직전 조회 시각 이후인지 판단
- 수정 후: 고유 접수번호 또는 DART 문서 링크를 기존 기록과 비교
매시간 조회로 확장하려면 제목이나 날짜보다 변하지 않는 고유값이 필요했다. 접수번호를 선택한 이유다.
---
### 3. 예약 실행과 Telegram 전달을 붙였다
한 종목 조회가 작동하는 것을 확인한 뒤 Skill을 Hermes에 설치했다. 예약 실행은 매번 독립된 새 세션에서 시작하므로, 이전 대화를 기억한다고 가정할 수 없다. 접수번호를 별도 상태로 남기는 구조가 필요했다.
전달 채널은 Telegram으로 정했다.
```text
Telegram으로 전송해보자
```
현재 프로토타입에는 09:30·13:30·17:00 KST 세 개의 Cron Job을 연결했다. 상태에는 다음 정보만 저장했다.
- 회사 식별자
- 마지막 성공 조회 시각
- 접수일자별로 확인한 DART 접수번호
공시 본문이나 요약, 사용자 대화는 저장하지 않았다. 조회가 실패하면 상태도 갱신하지 않는다. 실패 시각을 성공 기준으로 덮어쓰면 그 사이에 올라온 공시를 놓칠 수 있기 때문이다.
예약 작업 한 건을 즉시 시험 실행해 DART 조회 성공과 Telegram 전달 오류 없음까지 확인했다.
---
### 4. 제목 알림을 본문 요약으로 바꿨다
공시 제목과 링크만 받아서는 실무자가 다시 원문을 열어야 한다. 여러 회사를 매시간 확인하는 목표라면 이 과정도 줄여야 했다.
```text
해당 공시를 열어서 그 공시의 일부를 요약해서 알려주면 좋겠어
```
Skill에 다음 규칙을 추가했다.
- 신규 공시의 DART 본문 또는 공시 뷰어를 실제로 연다.
- 금액, 비율, 날짜, 계약상대방, 정정 사유, 제재와 거래 관련 조치를 우선 추출한다.
- 제목만 보고 내용을 추측하지 않는다.
- 원문이 “예정”, “추진 중”, “미확정”이라고 쓴 내용은 그 상태를 유지한다.
- 공시별 핵심 내용 2~4개와 원문 링크를 함께 보낸다.
이 과정을 반영한 Skill 버전은 v0.1.4다.
앞으로 여러 회사를 다룰 때는 공시 유형별 우선순위도 필요하다. 예를 들어 공급계약은 금액·매출액 대비 비율·기간, 자금조달은 규모·조건·납입일, 제재 공시는 벌점·기간·거래 영향이 먼저 보여야 한다. 이 유형별 분류는 아직 설계 단계다.
---
### 5. 최근 1개월 공시 5건으로 요약 알림을 시험했다
공시가 없는 날만으로는 본문 요약을 확인할 수 없었다. 공개 상장기업 1곳의 최근 1개월 공시를 예시 데이터로 사용했다.
```text
최근 1개월 공시 대상으로 Telegram 메시지 1회 전송해보자
```
해당 기간에 확인된 공시는 5건이었다. 각 접수번호의 DART 본문을 열어 다음 유형의 내용을 확인했다.
- 상장 관련 심사와 후속 일정
- 불성실공시 관련 사유와 제재
- 공급계약 금액, 이행률과 계약기간 정정
- 공공기관 거래 제한의 변경 예정 사항
다섯 건 모두 본문에서 핵심 숫자와 날짜를 대조한 뒤 Telegram으로 한 번 전송했다. 과거 1개월 조회는 형식 검증을 위한 테스트였기 때문에 일일 자동조회 상태에는 합치지 않았다. 테스트 데이터 때문에 이후 공시가 이미 처리된 것으로 보이면 안 된다고 판단했다.
---
### 6. 원문 날짜 표기 하나 때문에 전송이 멈췄다
Telegram 전송 전에는 공시 본문에 기대한 숫자와 날짜가 실제로 있는지 검사했다. 첫 검증에서는 연도가 네 자리인 날짜 형식을 찾았지만, DART 원문은 연도를 두 자리로 줄여 표시하고 있었다.
검증이 실패하자 메시지를 보내지 않고 중단했다. 원문 표기에 맞게 확인 조건을 고친 뒤 다섯 건을 다시 열어 검증했고, 그 후에만 메시지를 보냈다.
처음에는 사소한 표기 차이라고 생각했다. 하지만 여러 회사를 매시간 돌릴 계획이라면 이런 실패를 조용히 무시하는 편이 더 위험하다. 확인이 끝나지 않은 알림은 보내지 않고 이유를 남기는 쪽을 택했다.
---
## ✅ 결과 (After)
### Before vs After
| 항목 | Before | 현재 프로토타입 | 최종 목표 |
|---|---|---|---|
| 대상 회사 | 회사별로 직접 검색 | 공개 상장기업 1곳 | 관리 대상 상장기업 목록 전체 |
| 조회 주기 | 필요할 때 수동 확인 | 하루 3회 자동 실행 | 매시간 자동 실행 |
| 공시 범위 | 사람이 검색 결과를 확인 | 신규·정정공시 포함 | 주요 공시 유형별 자동 분류 |
| 신규 판정 | “직전 확인 이후”라는 기억 | 접수번호·문서 링크 비교 | 회사별 접수번호 상태 관리 |
| 공시 없음 | 확인 여부가 불명확 | 완료 시각과 함께 “없음” 전달 | 회사별·회차별 확인 상태 제공 |
| 조회 실패 | 공시 0건과 혼동 가능 | not_checked — 실패 원인 | 실패 회사만 분리해 재시도·경고 |
| 내용 확인 | 원문을 하나씩 다시 열람 | 본문 핵심 내용 2~4개 요약 | 공시 유형별 중요 항목 우선 요약 |
| 결과 전달 | 별도 자동 전송 없음 | Telegram 자동 전송 | 담당자·업무별 라우팅 |
| 시간 절감 | 미측정 | 미측정 | 운영 후 측정 예정 |
### 실제로 확인한 범위
- Hermes 로컬 Skill 설치와 v0.1.4 로드
- 공개 상장기업 1곳의 신규·정정공시 조회
- 09:30·13:30·17:00 KST Cron Job 세 개 활성화
- 예약 작업 즉시 실행 성공
- Telegram 전달 오류 없음 확인
- 최근 1개월 공시 5건의 DART 본문 열람
- 본문 요약과 원문 링크를 포함한 Telegram 메시지 1회 전송
- 과거 조회 테스트를 운영 상태와 분리
### 아직 확인하지 않은 범위
다음 항목은 완료된 것처럼 쓰지 않았다.
- 여러 관리 대상 회사를 한 번에 조회하는 회사 목록 관리
- 매시간 실행 일정
- 공시 중요도 자동 분류
- 회사·담당자별 메시지 라우팅
- 실제 신규 공시가 도착한 후 다음 실행에서 같은 접수번호가 제외되는 연속 검증
- 장기간 운영 기준의 시간 절감과 누락 감소 효과
현재 상태는 “한 종목으로 핵심 흐름을 검증한 프로토타입”이다. 다수 기업·매시간 운영은 다음 단계이며 아직 not_checked다.
## 💬 이 과정에서 배운 AI 활용 팁
### 효과적이었던 것
1. 큰 목표를 한 종목으로 줄였다.
여러 회사와 매시간 실행부터 시작했다면 조회 오류인지, 중복 판정 오류인지 구분하기 어려웠을 것이다.
2. 날짜 대신 접수번호를 기준으로 삼았다.
실행 주기가 짧아질수록 변하지 않는 고유값이 중요했다.
3. 0건과 실패를 분리했다.
“신규 없음”은 성공적인 조회 결과이고, not_checked는 확인하지 못한 상태다.
4. 요약 전에 원문을 열게 했다.
제목만으로는 금액, 기간, 정정된 내용과 영향까지 알 수 없었다.
5. 테스트 데이터와 운영 상태를 섞지 않았다.
과거 한 달을 조회해도 오늘의 중복 방지 상태에는 넣지 않았다.
### 이렇게 하면 안 돼요
1. 한 종목에서 성공했다고 다수 기업 운영도 검증됐다고 쓰면 안 된다.
2. 하루 3회 예약을 매시간 자동화가 완료된 것처럼 표현하면 안 된다.
3. 제목만 보고 주요 공시 내용을 추측하면 안 된다.
4. 예정 사항을 확정된 결과처럼 요약하면 안 된다.
5. 조회 실패를 “신규 공시 없음”으로 처리하면 안 된다.
6. 회사별 내부 관리정보, Bot Token이나 사용자 식별값을 사례글과 스크린샷에 노출하면 안 된다.
## 🌍 다른 업무에 적용한다면?
같은 구조는 DART 외에도 새 항목을 반복 확인하는 업무에 적용할 수 있다.
- 거래소 공시와 감독기관 제재
- 정부 입찰·조달 공고
- 법령과 행정규칙 개정
- 회사 보도자료와 IR 자료
- 신용등급과 평가의견 변경
- 산업 뉴스와 경쟁사 신제품
사이트마다 고유한 비교 키가 필요하다. DART에는 접수번호가 있고, 다른 사이트에는 공고번호나 문서 URL, 제품 ID가 있을 수 있다. 날짜나 제목만으로 비교하면 같은 날 여러 건이 올라오거나 제목이 바뀔 때 놓칠 가능성이 있다.
## 🚀 앞으로의 계획
1. 관리 대상 회사 목록을 별도 입력으로 분리하고 회사별 DART 식별정보를 연결한다.
2. 각 회사의 마지막 확인 접수번호를 독립적으로 관리한다.
3. 실행 주기를 하루 3회에서 매시간으로 바꾸고, 처리시간과 중복 실행 여부를 확인한다.
4. 공급계약·자금조달·소송·제재·감사의견·거래정지 등 주요 공시 분류 규칙을 만든다.
5. 회사와 공시 중요도에 따라 담당자별 메시지를 나누는 방식을 시험한다.
6. 실제 신규 공시가 올라온 날 연속 두 번 실행해 중복 제거를 검증한다.
7. 일정 기간 운영한 뒤 수동 확인 시간과 누락 건수를 측정한다.
