OpenDART로 주요사항보고서 읽는 법
OpenDART를 처음 쓰면 대개 정기보고서나 재무제표부터 본다 (OpenDART의 전체적인 장단점은 OpenDART, 솔직한 리뷰 참고). 하지만 실제로 시장이 먼저 반응하는 경우는 종종 주요사항보고서 쪽이다.
문제는 이 영역이 단순 검색으로는 관리가 어렵다는 점이다. 기업이 유상증자를 했는지, 타법인 주식을 취득했는지, 대규모 공급계약을 맺었는지, 소송이 발생했는지를 지속적으로 보려면 구조화된 이벤트 관점이 필요하다.
이 글은 OpenDART 주요사항보고서 API를 이용해 어떤 사건을 구조적으로 추적할 수 있는지, 어떤 영역은 API만으로 충분하고 어떤 영역은 원문 공시까지 내려가야 하는지 실전 기준으로 정리한다.
주요사항보고서는 왜 중요한가
정기보고서는 기업의 기준선을 보여준다. 주요사항보고서는 그 기준선을 흔드는 사건을 보여준다.
예를 들어:
- 유상증자
- 전환사채 발행
- 자산 양수도
- 타법인 주식 취득
- 대규모 공급계약
- 소송
이런 사건은 다음 실적에 반영되기 전에 먼저 공개되는 경우가 많다. 미국 EDGAR에서는 8-K가 비슷한 역할을 한다 (자세한 내용은 8-K item map 읽는 법 참고). DART에서 주요사항보고서는 숫자의 선행 신호에 가깝다.
| 문서 축 | 역할 |
|---|---|
| 정기보고서 | 기본 구조와 기준선 |
| 재무제표 | 결과 숫자 |
| 주요사항보고서 | 구조 변화와 사건 발생 |
| 원문 공시 | 세부 조건과 문구 강도 |
OpenDART에서 무엇을 API로 잡을 수 있나
OpenDART 개발가이드에는 주요사항보고서 주요정보 관련 API 묶음이 정리되어 있다. 이 영역의 장점은 사건별로 구조화된 필드를 받을 수 있다는 점이다.
대표적으로 잡기 좋은 사건은 다음과 같다.
| 사건 유형 | 왜 중요한가 | API만으로 충분한가 |
|---|---|---|
| 유상증자/무상증자 | 희석, 자금조달 목적 | 일부는 충분, 조건은 원문 필요 |
| 전환사채/신주인수권부사채 | 희석, 금리, 전환 조건 | 원문 확인 필요 |
| 자산 양수도 | 포트폴리오 재편 | 원문 확인 권장 |
| 타법인 주식 취득/처분 | 투자 전략 변화 | API + 원문 |
| 공급계약 | 매출 가시성 | 원문 필수 |
| 소송/우발부채 | 비용과 평판 리스크 | 원문 필수 |
핵심은 이벤트 발견은 API가 잘하고, 조건 해석은 원문이 더 잘한다는 점이다.
어떤 사건은 API만으로 충분하고 어떤 사건은 원문이 필요한가
구조화 데이터는 필드가 정리돼 있어 스크리닝에 강하다. 하지만 계약 조건, 예외 조항, 종료 조건, 상환 조건 같은 텍스트는 원문이 더 중요하다.
| 사건 | API 활용도 | 원문 필요성 |
|---|---|---|
| 단순 발행/취득 여부 파악 | 높음 | 중간 |
| 금액, 상대방, 날짜 파악 | 높음 | 중간 |
| 조기상환, 해지, 조건 변경 | 낮음 | 매우 높음 |
| 공급계약 세부 조항 | 낮음 | 매우 높음 |
| 소송 리스크 문구 강도 | 낮음 | 매우 높음 |
즉 OpenDART는 탐지 엔진, 원문은 해석 엔진으로 쓰는 게 가장 효율적이다.
실전 모니터링 체계는 어떻게 짜야 하나
기업 이벤트를 실전적으로 보려면 개별 조회보다 watch 구조가 필요하다.
기본 구조는 아래와 같다.
corp_code확보- 기업군 watchlist 구성
- 주요사항보고서 API 호출
- 이벤트 유형 분류
- 고신호 이벤트만 원문 공시로 확장
- 다음 정기보고서/실적과 연결
| 단계 | 목적 |
|---|---|
| 탐지 | 어떤 사건이 발생했는가 |
| 분류 | 어떤 종류의 이벤트인가 |
| 우선순위 | 고신호/저신호를 구분 |
| 해석 | 조건과 문구를 원문으로 확인 |
| 추적 | 이후 재무와 실적에 반영되는지 확인 |
어떤 이벤트를 먼저 봐야 하나
모든 주요사항보고서를 다 같은 무게로 볼 필요는 없다. 아래는 우선순위 기준이다.
| 우선순위 | 이벤트 | 이유 |
|---|---|---|
| 매우 높음 | 유상증자, CB/BW, 대규모 차입 | 희석과 자금구조 변화 |
| 높음 | 자산 양수도, 타법인 주식 취득 | 전략과 포트폴리오 변화 |
| 높음 | 공급계약, 해지 | 매출 가시성과 수요 변화 |
| 중간 | 소송, 담보 제공 | 비용과 리스크 전이 |
| 중간 | 이사회 결의류 | 본질 변화가 있는지 추가 확인 필요 |
좋은 모니터링은 공시를 다 읽는 것이 아니라, 고신호 이벤트만 빠르게 골라내는 것이다.
이벤트를 잡고 나서 무엇을 다시 추적해야 하나
좋은 이벤트 파이프라인은 탐지에서 끝나지 않는다. 사건별로 다음 확인 숫자와 문서를 같이 정해둬야 한다.
| 이벤트 | 다음에 볼 것 |
|---|---|
| 유상증자, CB/BW | 희석 구조, 자금 사용처, 다음 분기 자본 구조 |
| 자산 양수도 | 투자 규모, 차입 변화, 감가상각 또는 손상 가능성 |
| 공급계약 | 다음 분기 매출 반영, 고객 집중도, 해지 조건 |
| 소송 | 충당부채, 우발부채, 감사 문구 변화 |
| 타법인 주식 취득 | 투자 목적, 지분법 영향, 회수 가능성 |
이렇게 연결해두면 주요사항보고서는 뉴스 알림이 아니라 다음 재무 변화를 준비하는 리스트가 된다.
watchlist를 설계할 때 가장 많이 놓치는 것은 무엇인가
watchlist 자동화는 기업 이름을 모아두는 것으로 끝나지 않는다. 아래 세 가지가 빠지면 대부분 금방 무너진다.
corp_code를 기준으로 기업 식별을 고정하지 않는다- 이벤트 우선순위가 없어 모든 공시를 비슷하게 본다
- 사건 이후 다음 정기보고서까지 이어지는 추적 칼럼이 없다
실전에서는 “무슨 이벤트가 나왔나”보다 “그래서 다음에 뭘 다시 확인하나”가 더 중요하다. 좋은 watchlist는 공시를 많이 쌓는 구조가 아니라, 다음 행동을 남기는 구조다.
API와 원문을 같이 써야 하는 이유를 한 문장으로 정리하면
API는 탐지에 강하고, 원문은 해석에 강하다. 이 차이를 분리하지 못하면 자동화가 금방 흐려진다.
예를 들어 유상증자 사건은 API만으로도 발생 여부, 금액, 날짜를 잡을 수 있다. 하지만 할인율, 납입 구조, 자금 사용처, 예외 조항은 원문이 더 중요하다. 공급계약도 마찬가지다. 계약 체결 사실은 API로 잡되, 해지 조건과 실제 효력은 원문을 봐야 한다.
그래서 좋은 파이프라인은 API를 만능처럼 쓰지 않는다. API는 고신호 사건을 골라내고, 원문은 그중 정말 중요한 사건의 문맥을 확인하는 역할로 나눈다.
정기보고서와 연결해야 하는 이유는 무엇인가
주요사항보고서는 사건을 먼저 보여주지만, 그 사건이 실제로 얼마나 중요했는지는 다음 정기보고서와 재무제표에서 드러난다. 그래서 이벤트 파이프라인은 정기보고서 추적과 붙어야 완성된다.
예를 들어 공급계약은 다음 분기 매출과 매출채권으로 이어질 수 있고, 자산 양수도는 감가상각이나 차입 구조 변화로 이어질 수 있다. 소송은 충당부채나 감사 문구 변화로 이동할 수 있다. 결국 좋은 이벤트 자동화는 발생 여부에서 끝나지 않고 나중에 숫자로 어떻게 남았는가까지 이어져야 한다.
이 연결이 있어야 주요사항보고서는 알림 피드가 아니라 분석 도구가 된다. 사건을 잡는 것보다, 사건이 나중에 어디에 남는지 추적하는 구조가 훨씬 중요하다.
이벤트 우선순위 점수는 어떻게 잡으면 좋은가
모니터링 시스템은 결국 우선순위 설계가 핵심이다. 실전에서는 아주 정교한 모델보다 아래 세 질문으로 점수를 잡아도 충분하다.
- 자본 구조를 바꾸는가
- 다음 분기 숫자를 흔들 가능성이 큰가
- 원문을 읽어야 할 조건이 많은가
이 기준으로 보면 유상증자, CB/BW, 대규모 계약 해지, 소송 확대 같은 사건은 높은 점수를 받는다. 반대로 단순 결의나 반복성 공지는 낮은 점수로 내려갈 수 있다. 이렇게 태깅해두면 이벤트가 많아도 실제로 사람이 읽어야 할 공시 수는 크게 줄어든다.
좋은 이벤트 파이프라인은 공시를 다 수집하는 시스템이 아니라, 중요한 공시를 빨리 위로 올리는 시스템이다.
그리고 그 우선순위 체계가 있어야 watchlist가 실제로 운영 가능한 도구가 된다.
결국 이벤트 자동화의 핵심은 수집량이 아니라 해석 가능한 큐를 만드는 것이다. 사람이 읽어야 할 공시를 빨리 좁혀주지 못하면 좋은 API도 금방 소음이 된다.
그래서 좋은 주요사항보고서 파이프라인은 속보 알림 시스템이 아니라, 다음 숫자를 준비시키는 우선순위 시스템에 더 가깝다.
이 감각이 있어야 이벤트 수집이 실제 분석으로 이어진다. 그렇지 않으면 공시를 많이 모아도 결국 읽지 못하는 알림 더미만 쌓이게 된다.
좋은 시스템은 더 많이 모으는 시스템이 아니라, 더 빨리 중요도를 나누는 시스템이다.
주요사항보고서 파이프라인도 결국 그 원칙을 따라야 한다.
운영 효율이 크게 달라진다.
실전에서 중요하다.
효과가 크다.
분명하다.
실용적이다.
실패하는 파이프라인은 어떤 모습인가
주요사항보고서 자동화에서 자주 실패하는 이유는 다음과 같다.
1. API 결과만 보고 원문을 안 본다
실제 조건은 원문에 더 잘 드러난다.
2. 이벤트를 모두 같은 등급으로 본다
유상증자와 단순 이사회 결의는 무게가 다르다.
3. 정기보고서와 연결하지 않는다
사건을 감지하고도 이후 실적에 반영됐는지 안 보면 의미가 반감된다.
4. 기업 단위 watchlist가 없다
한 번 검색하고 끝내면 지속 추적이 안 된다.
실전 체크리스트
- 우리 watchlist 기업의
corp_code가 정리돼 있는가 - 주요사항보고서 API에서 어떤 이벤트를 수집할지 범주가 정의돼 있는가
- 이벤트별 우선순위가 정해져 있는가
- 고신호 이벤트는 자동으로 원문까지 내려가게 되어 있는가
- 다음 정기보고서와 실적에 연결해 추적하고 있는가
- 같은 이벤트가 반복될 때 누적 비교가 가능한가
FAQ
OpenDART로 주요사항보고서를 전부 대체할 수 있나
아니다. 탐지에는 좋지만, 세부 조건 해석은 원문 공시가 필요하다.
어떤 이벤트를 가장 먼저 봐야 하나
희석, 자금조달, 대규모 자산 거래, 공급계약 변화를 우선순위 높게 둔다.
API만으로 충분한 경우는 언제인가
단순 발생 여부, 금액, 날짜, 기업 간 비교 스크리닝 단계에서는 충분할 수 있다.
원문이 꼭 필요한 경우는 언제인가
해지 조건, 조기상환, 전환 조건, 특약, 문구 강도 해석이 필요한 경우다.
정기보고서와 어떻게 연결하나
이벤트 발생 후 다음 분기 또는 연간 보고서에서 실제 숫자와 주석이 어떻게 변했는지 확인한다.
참고한 공식 자료
- OpenDART 개발가이드: https://opendart.fss.or.kr/guide/main.do
- OpenDART 공시정보 활용마당: https://opendart.fss.or.kr/disclosureinfo/biz/main.do
- OpenDART 주요사항보고서 주요정보 가이드: https://opendart.fss.or.kr/guide/main.do?apiGrpCd=DS005
- DART 보고서정보: https://dart.fss.or.kr/introduction/content2.do
관련 글
- DART의 모든 것 — DART 전자공시의 전체 구조와 공시 유형 분류
- 전자공시 대량 수집은 왜 느리고 어디서 막히나 — API 호출 제한과 대량 수집 전략
정리
OpenDART 주요사항보고서 API는 “이벤트 탐지”에 강하다. 반면 원문 공시는 “조건 해석”에 강하다. 둘을 분리해서 쓰면 공시 모니터링 품질이 크게 올라간다.
좋은 파이프라인은 이벤트를 다 모으는 것이 아니라, 중요한 이벤트를 빠르게 분류하고 다음 재무와 연결해 보는 구조를 갖는다.