OpenDART, 솔직한 리뷰

한국에서 공시 데이터를 프로그래밍으로 다루려면 반드시 거쳐야 하는 곳이 OpenDART다. DART 시스템 자체가 궁금하다면 DART의 모든 것을 먼저 읽는 것을 추천한다. 여기서는 실제로 OpenDART를 써보면서 느낀 장단점을 솔직하게 리뷰하겠다.

DART의 역사

OpenDART를 이해하려면 DART 자체의 역사부터 봐야 한다.

1999년 서비스 시작 이후 27년. 서면으로 종이 서류를 제출하던 시대에서, 누구나 인터넷으로 공시를 열람하고 API로 데이터에 접근할 수 있는 시대까지 왔다.

OpenDART가 탄생하기까지

1세대: DART 오픈API (2013~2020)

2013년 8월, DART에서 처음으로 “오픈API” 서비스가 시작됐다. 공시 검색, 기업 개황 조회 등 기본적인 API를 제공했다. 별도로 “공시정보 활용마당”이라는 서비스도 운영됐다.

이 시기에는 API 범위가 제한적이었고, 재무제표 데이터에 구조화된 접근이 어려웠다.

2세대: Open DART (2020~현재)

2020년 1월 21일, 기존 오픈API와 공시정보 활용마당을 통합·확대 개편한 Open DART 시범서비스가 시작됐다. 시범 운영 기간(약 3개월) 동안 약 2,500명의 이용자가 총 2,770만 건의 공시정보를 활용했다. 일평균 36만 건이다.

2020년 4월 20일, 공식 서비스가 시작됐다. 현재 720만 건 이상의 공시문서에 접근 가능하며, 83개 API 엔드포인트를 6개 카테고리로 제공한다.

XBRL — 데이터 혁명의 시작

XBRL(eXtensible Business Reporting Language)은 재무 데이터를 기계가 읽을 수 있도록 표준화하는 기술이다. 한국은 이 분야에서 세계적으로 선도적인 위치에 있다.

도입 타임라인

2007년에 세계 최초로 도입했고, 2025년에 국제표준 인증까지 받았다. 2027년까지 전 상장사에 전면 적용될 예정이다. 택사노미 항목도 초기 920개에서 현재 약 8,000개로 확대됐다.

XBRL이 바꾼 것

재무제표의 각 숫자에 표준 태그가 붙으면, 기업 간 비교가 가능해진다. “매출액”이라고 쓴 회사와 “수익(매출액)“이라고 쓴 회사를 프로그래밍으로 같은 항목으로 인식할 수 있다. 적어도 이론적으로는.

XBRL 도입 이후 영문 DART 접속이 10,589건(2022)에서 50,000건 이상(2024)으로 급증했다. 외국인 투자자의 한국 기업 정보 접근이 크게 개선된 것이다.

아직 남은 과제

2024년 1분기 기준, XBRL 주석 공시를 직접 수행한 기업은 전체의 27.2%에 불과하다. 대부분이 외주로 작성하는데, 외주 작성 기업의 재공시율(정정공시)이 28~43%에 달한다. 선도 도입 기업의 약 30%가 정정공시를 경험했다.

XBRL 제출 품질 자체가 아직 안정되지 않은 상태다. 이건 시간이 해결할 문제이긴 하다.

좋은 점

1. 무료

완전 무료다. 인증키 발급만 하면 되고, 개인이든 기업이든 동일하게 사용할 수 있다. 전 세계적으로 봐도 이 규모의 공시 데이터를 무료로 API로 제공하는 경우는 많지 않다.

2. 정기보고서 항목의 구조화

이것이 OpenDART의 가장 큰 강점이다. 배당, 최대주주 지분율, 임원 현황, 직원 현황, 감사의견, 감사보수, 자기주식, 채무증권 등 정기보고서의 주요 항목이 구조화된 JSON으로 바로 제공된다.

미국 SEC EDGAR만 해도 이런 항목을 구조화된 API로 제공하지 않는다. EDGAR에서 배당 정보를 얻으려면 10-K 원문을 파싱하거나 XBRL에서 추출해야 한다. OpenDART는 API 한 번 호출로 끝난다.

3. 데이터 범위

720만 건 이상의 공시문서에 접근 가능하다. 한국 자본시장에서 법적으로 의무화된 모든 공시를 담고 있다. 83개 엔드포인트로 공시 검색, 재무제표, 지분 공시, 주요사항보고서, 증권신고서까지 단일 플랫폼에서 제공한다.

일평균 이용 규모가 공시정보 API 26만 건, 재무정보 API 1.6만 건으로 활발하게 사용되고 있다.

4. XBRL 기반 재무제표

XBRL로 태깅된 재무제표를 JSON/XML로 직접 받을 수 있다. 택사노미 ID가 포함되어 있어서, 계정과목의 국제 표준 매핑이 이론적으로 가능하다.

불편한 점

여기서부터가 본론이다. 실제로 OpenDART를 써서 데이터를 다뤄본 사람이라면 공감할 이야기들이다.

1. HTTP 200 에러 패턴

가장 큰 설계 문제다. 모든 응답이 HTTP 200으로 반환된다. 에러가 발생해도 200이다.

에러 여부는 응답 body의 status 필드를 직접 파싱해야 한다.

{
  "status": "013",
  "message": "조회된 데이타가 없습니다."
}

REST API의 기본 원칙에 어긋난다. HTTP 상태코드(401, 404, 429 등)를 사용했어야 하는 부분이다. 이 때문에 모든 API 호출마다 응답 body를 먼저 파싱하고 status를 확인하는 보일러플레이트가 필요하다.

2. 종목코드가 아닌 고유번호 사용

일반적으로 알려진 종목코드(6자리)로 바로 조회할 수 없다. DART 고유번호(8자리, corp_code)를 사용해야 한다.

종목코드 → 고유번호 변환을 위해 먼저 고유번호 파일(corpCode.xml)을 다운로드하고 파싱해야 한다. 이 파일은 ZIP으로 제공된다.

삼성전자 → 종목코드: 005930 → DART 고유번호: 00126380

“005930”을 넣으면 바로 조회되면 좋겠지만, 매번 고유번호를 변환해서 넣어야 한다. 사소해 보이지만 자동화에서 한 단계가 추가되는 것이다.

3. 계정명 비정규화

이것이 데이터 분석에서 가장 큰 고통이다. 재무제표 API에서 account_nm(계정과목명) 필드는 기업이 자유롭게 작성한 한글 이름이다.

동일한 회계 항목이 이렇게 다르게 등록된다:

삼성전자: "매출액"
SK하이닉스: "수익(매출액)"
현대차: "영업수익"
LG에너지솔루션: "매출"

모두 같은 “Revenue”인데, 문자열이 전부 다르다.

account_id(XBRL 택사노미 ID)가 존재하지만, 모든 항목에 대해 표준화되어 있지는 않다. 특히 주석 항목이나 기업 자체 생성 계정은 택사노미 ID가 없거나 일관되지 않다.

기업 간 재무 비교를 하려면 계정명 매핑/정규화 작업이 필수다. 이걸 수작업으로 하면 수천 개 기업의 각기 다른 계정명을 일일이 대응시켜야 한다.

4. 텍스트 데이터 미제공

공시서류 원문을 ZIP 파일로 다운로드할 수 있지만, 내부는 비정형 XML/HTML이다.

사업의 내용, 감사보고서, 경영진단의견(MD&A), 위험 요인 같은 텍스트 데이터는 구조화된 API로 제공되지 않는다. 이 텍스트 데이터를 활용하려면:

1. ZIP 다운로드
2. 압축 해제
3. XML/HTML 파싱

이 과정을 거쳐야 한다. 문제는 HTML 구조가 문서마다 제각각이라서 범용 파서를 만들기 극히 어렵다는 것이다. 기업마다, 연도마다, 심지어 같은 기업의 같은 보고서도 섹션마다 HTML 구조가 다르다.

5. 호출 제한

인증키당 일일 10,000~20,000건 제한이다. 전체 상장사(약 2,500개)의 전체 기간 데이터를 한꺼번에 수집하려면 제한에 걸린다.

예를 들어, 전체 상장사의 최근 5년 분기 재무제표를 수집하려면:

• 2,500개 기업 × 20분기 = 50,000건
• 일일 제한에 도달하면 며칠에 걸쳐 수집해야 한다

분당 제한은 명시되지 않지만, 과도한 요청 시 차단될 수 있다.

참고로, SEC EDGAR는 초당 10건(일일 환산 86만 건+)이다. 비교 자체가 안 된다.

6. 검색 기간 제한

corp_code(기업 고유번호)를 지정하지 않고 전체 검색하면, 검색 기간이 3개월로 제한된다. 특정 기간의 전체 공시를 수집하려면 3개월씩 끊어서 반복 호출해야 한다.

7. 페이지네이션

한 페이지 최대 100건으로 제한된다. 대량 데이터 조회 시 반복 호출이 필요하다.

8. 데이터 정합성

일부 기업/기간의 재무 데이터가 누락되어 있다. XBRL 제출 품질도 아직 불안정해서, 외주 작성 기업의 재공시율이 28~43%에 달한다.

다른 나라와 비교하면

OpenDART의 위치를 객관적으로 파악하려면 다른 나라의 전자공시 API와 비교해볼 필요가 있다.

SEC EDGAR (미국)

EDGAR의 강점은 인증 불필요, 압도적 호출 한도, 전문검색, 실시간 갱신이다. OpenDART의 강점은 정기보고서 항목의 구조화다.

솔직히 API 인프라 측면에서는 EDGAR가 압도적이다 (EDGAR 시스템의 전체 구조는 EDGAR의 모든 것에서 다룬다). 하지만 OpenDART가 제공하는 배당, 최대주주, 임원 보수 같은 구조화된 정기보고서 데이터는 EDGAR에서 얻으려면 직접 파싱해야 한다.

EDINET (일본)

일본도 2008년부터 XBRL을 도입했다. Inline XBRL(iXBRL) 비중이 높아서 HTML과 XBRL이 통합된 형태로 제공되는 점이 특징이다.

Companies House (영국)

영국은 조회뿐 아니라 API로 공시 제출까지 가능하다는 점이 독특하다.

종합

OpenDART는 정기보고서 구조화에서 최고 수준이지만, API 인프라(호출 한도, 설계 품질, 전문검색)에서는 뒤처진다.

앞으로의 기대

XBRL 전면 확대 (2027)

2027년까지 전 상장사 재무공시가 XBRL로 전환된다. 이것이 완성되면:

• 모든 상장사의 재무제표가 기계 판독 가능한 표준 포맷으로 제공
• 택사노미 ID 기반으로 기업 간 자동 비교가 가능
• 주석까지 XBRL화되면 차입금 만기, 재고 구성, 유형자산 변동 같은 상세 데이터도 구조화

2028년부터는 XBRL 주석 상세 공시가 분기별(연 4회)로 전환되니, 데이터의 적시성도 크게 개선될 것이다.

기대하고 싶은 것들

• 전문검색 API: 공시서류 원문을 키워드로 검색하는 기능. EDGAR에는 있다.
• 호출 한도 완화: 일 10,000건은 대규모 분석에 부족하다.
• 표준 HTTP 상태코드 도입: HTTP 200 에러 패턴을 개선해주면 좋겠다.
• 종목코드 직접 조회: corp_code 변환 없이 종목코드로 바로 조회.
• 텍스트 데이터 구조화: 사업의 내용, 감사보고서 등의 텍스트를 API로 제공.

그럼에도 불편한 점

XBRL이 전면 확대되고 API가 개선되어도, 근본적으로 남는 문제가 있다.

과거 데이터는 바뀌지 않는다

XBRL 의무화가 2024년부터 단계적으로 시작됐지만, 그 이전의 공시 데이터는 비정형 HTML/XML 그대로다. 2011년~2023년의 공시 원문은 앞으로도 직접 파싱해야 한다. XBRL이 전면 적용되어도 과거 데이터에 소급 적용되지 않는다.

시계열 분석을 하려면 과거 데이터는 여전히 파싱이 필요하다.

기업이 작성하는 데이터의 한계

공시 서류는 기업이 직접 작성한다. 금감원이 서식을 규정하지만, 서술 방식은 기업 재량이다. 같은 서식이라도 기업마다 표현이 다르고, 같은 기업도 연도별로 표기가 바뀐다.

XBRL 택사노미가 있어도 기업이 임의로 확장 택사노미를 생성할 수 있다. 표준 택사노미에 없는 항목은 기업 자체 ID를 부여하는데, 이런 항목은 기업 간 비교가 안 된다.

API가 커버하지 못하는 영역

OpenDART API가 아무리 확대되어도, 사업보고서의 텍스트 섹션(사업의 내용, 경영진단의견, 위험 요인)은 본질적으로 자유 서식이다. API로 구조화하기 어렵다. 텍스트에서 인사이트를 뽑으려면 결국 자체 파싱 + NLP가 필요하다.

정정공시의 복잡성

같은 기업, 같은 기간의 보고서가 정정공시로 여러 버전 존재할 수 있다. API가 이를 명확히 구분해주지 않아서, 최신 정정본만 사용하도록 직접 필터링해야 한다.

10분 체크리스트

• 내가 필요한 데이터가 구조화 API로 바로 오는지 먼저 확인했는가
• corp_code 변환과 호출 제한을 작업 설계에 반영했는가
• 재무 숫자와 텍스트 원문을 같은 방식으로 얻을 수 없다는 점을 이해했는가
• 정정공시와 과거 데이터 파싱을 별도 문제로 보고 있는가
• OpenDART의 장점과 불편함을 같이 설명할 수 있는가

FAQ

OpenDART는 무료인가

그렇다. 무료지만 호출 제한과 키 발급 절차가 있다.

OpenDART만으로 모든 공시 분석이 가능한가

아니다. 정기보고서 구조화는 강하지만 텍스트 원문 파싱과 과거 데이터 처리에는 한계가 있다.

EDGAR보다 항상 좋은가

정기보고서 구조화는 강점이 있지만, API 인프라와 전문검색은 EDGAR가 더 낫다.

가장 먼저 겪는 불편은 무엇인가

HTTP 200 에러 패턴, corp_code 변환, 계정명 비정규화, 호출 제한이 대표적이다.

관련 글

• 파이썬으로 재무제표 분석하기 — OpenDART 데이터를 파이썬으로 실제 분석하는 방법
• 전자공시 대량 수집은 왜 느리고 어디서 막히나 — 호출 제한과 대량 수집 전략

정리

OpenDART는 세계적으로 드문 수준의 무료 전자공시 API다. 특히 정기보고서 항목의 구조화에서는 SEC EDGAR보다 낫다. XBRL 도입에서도 세계 최초(2007)라는 역사를 갖고 있고, 2027년 전면 적용이라는 야심찬 로드맵을 진행 중이다.

하지만 현실에서 쓰려면 불편한 점이 많다. HTTP 200 에러 패턴, 고유번호 변환, 계정명 비정규화, 텍스트 데이터 미제공, 호출 제한. 이런 것들이 쌓이면 데이터 수집 자동화의 진입 장벽이 된다.

DartLab은 이 간격을 메우기 위해 만들어졌다. OpenDART API가 제공하지 않는 텍스트 데이터를 직접 파싱하고, 계정명 변동을 자동으로 추적하고, 정정공시를 필터링하고, 주석 데이터를 구조화한다.

자세한 사용법은 문서를 참조하자.