본 기사는 EDINET DB의 블로그 기사 「"AI가 비싸지는" 것이 아니라 "적정화되는" 것 — 입력 토큰에서 차이가 발생하는 시대, 구조화 데이터베이스의 존재 이유」를 전재한 것입니다. 최신 버전은 그곳에 게재되어 있습니다.

2026년 5월 14일, Anthropic이 공지를 발표했습니다. 6월 15일부터 Claude의 유료 플랜(Pro / Max 5x / Max 20x / Team / Enterprise)에 「프로그램 이용 전용 월간 크레딧(monthly credits)」을 도입한다는 내용입니다. Claude Agent SDK, claude -p, Claude Code GitHub Actions, 서드파티(third-party) Agent SDK 앱의 이용이 이 전용 크레딧에서 차감되는 형태가 됩니다.

금액은 Pro가 월 20달러, Max 5x가 100달러, Max 20x가 200달러입니다. 구독료와 정확히 동일한 금액입니다. 이월은 되지 않으며, 다 사용한 후에 「usage credits」를 ON으로 설정하면 API 레이트(rate)에 따라 종량제로 과금되고, OFF 상태라면 다음 사이클까지 정지됩니다.

언뜻 보면 요금 체계의 정리로 보입니다. 하지만 그 배경에 있는 것은 AI 이용료가 「인건비처럼 쌓여가는」 단계에 진입했다는 것입니다. 누군가에게 작업을 의뢰하면 공수에 따라 비용이 발생하는 당연한 감각에 AI가 다가가는 것입니다. 이번에는 그 구조적 변화를 상장 기업 데이터를 예로 들어 실연해 보겠습니다.

Claude Code Max의 월 200달러 플랜은 지금까지 대화 UI뿐만 아니라 Claude Agent SDK나 claude -p도 동일한 레이트 제한 범위 내에서 구동할 수 있었습니다. 무거운 에이전틱 루프(agentic loop)를 돌리면 Claude Opus로 하루에 수백만 토큰을 처리하는 것도 드문 일이 아니었으며, API 직접 호출로 환산하면 월 수천 달러 상당의 사용이 가능했던 셈입니다.

6월 15일 이후에는 프로그램 이용이 전용 크레딧(Max 20x라면 월 200달러분) 범위 내로 제한됩니다. 이를 초과하면 「usage credits」를 활성화하여 종량제로 과금할지, 아니면 그달은 중단할지 둘 중 하나를 선택하는 형태가 됩니다. 레이트 제한(rate limit) 자체는 Claude Code 및 채팅과 공유된 상태를 유지하며, 별도 분리되는 것은 금액 부분입니다.

사용자 측면에서 보면 실질적인 가격 인상으로 비춰집니다. 다만 제공 측의 경제적 합리성 측면에서 보면, 지금까지 의도치 않게 제공해 왔던 「구독료의 20배 이상의 API 가치」가 정상 가격에 가까워지는 것뿐입니다. Anthropic 입장에서는 당연한 보정이며, OpenAI나 Google도 같은 방향으로 움직일 것이라고 생각하는 것이 자연스럽습니다.

즉, AI 요금 자체가 올라간다기보다는 구독으로 흡수할 수 있었던 차익(arbitrage)이 사라지고, 「사용한 만큼 비용이 발생하는」 구조로 돌아간다는 뜻입니다. 여기서부터는 AI를 업무에서 운용할 때의 판단 기준이 바뀝니다.

AI 이용이 「사용한 만큼」이 된다면, 앞으로 무엇을 최적화해야 할까요? 선택지는 크게 두 가지가 있습니다. 하나는 모델 단가를 낮추는 방향(Opus 대신 Sonnet을 사용하거나, 저렴한 모델로 전환하거나, 로컬 LLM을 구축하는 것)입니다. 다른 하나는 애초에 전달하는 토큰의 양을 줄이는 방향입니다.

전자만이 논의되는 경향이 있지만, 후자가 줄일 수 있는 단위가 압도적으로 큰 경우가 대부분입니다.

이유는 간단합니다. 대부분의 AI 업무 처리에서는 입력 토큰(input token)이 출력 토큰(output token)의 5~20배를 차지하기 때문입니다. 긴 문서를 읽게 하고 짧은 답변을 얻어내는 형식이 전형적이기 때문입니다. Claude Sonnet의 입력 단가는 출력 단가의 5분의 1이지만, 양에서 압도적으로 역전되어 결국 월 비용의 대부분은 입력 측에서 결정됩니다.

여기서 알 수 있는 것은 하나입니다. 「AI에게 무엇을 읽힐 것인가」를 컨트롤할 수 있는 쪽이 앞으로의 비용 싸움에서 유리해집니다. 입력을 PDF 전문 전달에서 필요한 구조화 데이터(structured data)로 대체할 수 있다면, 모델을 저렴한 것으로 바꾸는 것보다 훨씬 큰 절감 효과를 얻을 수 있다는 구도입니다.

이제부터 실연에 들어갑니다. 주제는 소프트뱅크 그룹(도쿄증권거래소 9984, EDINET 코드 E02778)입니다. 질문은 단 하나입니다.

소프트뱅크 그룹(증권 코드 9984)의 최근 5년간 순이익 추이를 알려주세요.

이를 세 가지 경로로 던져서 결과와 입력 토큰량을 비교하겠습니다.

경로 1: AI 에이전트에게 그대로 질문하기 (Web 검색 기반) -
경로 2: 유가증권보고서(有報) PDF를 직접 다운로드하여 통째로 첨부하기 -
경로 3: EDINET DB의 MCP를 연결하여 구조화 API를 통해 가져오기

먼저 가장 소박한 방법부터 시작합니다. 질문만 던지고, AI 측에서 알아서 웹을 검색하여 답하게 하는 방식입니다. 이번에는 Perplexity를 사용했습니다. AI 검색 엔진으로서 널리 사용되고 있으며, MCP와 같은 외부 데이터 소스 연결 기능은 없고 순수하게 웹 검색 기반으로 답하는 도구입니다.

결과는 그럴싸하게 나옵니다. FY2021이 4.99조 엔으로 최고익, FY2022~FY2024는 적자, FY2025에는 1.15조 엔으로 흑자 전환. 여기에 더해 "2026년 3월기는 순이익 5조 22억 엔으로 과거 최고 수준"이라는 속보까지 보충해 줍니다. 웹 검색 기반의 강점은 바로 여기에 있습니다. 새로운 정보도 포착할 수 있다는 점입니다.

반면 약점은 출처가 분산된다는 것입니다. 이번에는 10개의 소스를 참조했다고 표시되었지만, 각각 증권사 사이트, 지방 신문, 뉴스 애그리게이터 등 독립된 2차 소스(Secondary Source)입니다. 숫자가 미묘하게 다를 때, AI 측에서도 어떤 것이 옳은지 검증하지 않습니다. 출처가 제각각이기 때문에, 나중에 "이 숫자의 근거는 무엇인가?"라고 물었을 때의 설명 책임이 분산됩니다.

입력 토큰(Input Token)량은 사용자 측의 질문 문장과 AI가 취득한 여러 웹 페이지의 본문을 합산하는 형태가 되며, 전형적으로 수천~수만 토큰 규모입니다. Perplexity 측에서 내부적으로 요약 및 압축을 수행하기 때문에 절대치는 보기 어렵지만, 웹 전문을 전부 읽을 정도까지는 아닌 정도의 양감입니다.

다음은 반대편의 극단적인 방법인 "AI에게 유보(有報, 유가증권보고서) 그 자체를 읽히는" 방식입니다. 소프트뱅크 그룹의 최신 유가증권보고서(FY2025, 2025년 6월 26일 제출)를 EDINET에서 다운로드하여, PDF 통째로 Claude나 ChatGPT에 첨부하고 동일한 질문을 던집니다.

이 경로의 장점은 출처가 1차 정보(EDINET에 제출된 유보) 하나로 압축된다는 것입니다. AI가 추론에 사용하는 정보원은 제출 서류 그 자체입니다. 설명 책임이 명확해집니다.

반면 양은 상당히 많습니다. 이번 PDF는 320페이지이며, 텍스트를 추출하면 약 40만 자입니다. OpenAI의 토크나이저(Tokenizer, GPT-4o 계열)로 측정하면 약 30만 토큰입니다. Claude Sonnet 4.6의 입력 단가는 100만 토큰당 3달러이므로, 기업 한 곳당 약 0.9달러가 소요됩니다. 동일한 질문을 100개 기업에 반복하면 입력 측에서만 90달러가 듭니다.

게다가 AI 측에도 부담이 됩니다. 30만 토큰의 컨텍스트(Context)를 추론으로 처리하는 데 시간이 걸리며, 레이아웃 붕괴나 단위 착오(천 엔, 백만 엔, 억 엔)와 같은 오독의 여지도 남습니다. "PDF에서 순이익을 추출한다"는 목적 하나만을 위해 AI에게 320페이지를 다 읽히는 것은, 사람을 고용해 재무제표를 읽게 하는 것과 유사한 비용 구조를 가집니다.

여기까지가 현재의 "웹에서 묻기"와 "PDF 읽히기"라는 양극단입니다. 그 사이에 있는 것이 구조화 API입니다.

세 번째는 EDINET DB가 제공하는 구조화 API를 MCP(Model Context Protocol)를 통해 AI에 연결하는 방법입니다. AI가 대화 과정에서 필요한 필드(Field)만 골라낼 수 있게 됩니다. 이번에는 Claude.ai에 EDINET DB의 MCP 커넥터를 연결한 상태에서 동일한 질문을 던졌습니다.

Claude는 먼저 search_companies로 EDINET 코드를 조회한 뒤, 다음으로 get_financials를 통해 5년 치 재무 시계열 데이터를 가져옵니다. 반환된 JSON에는 각 연도의 순이익, 매출, 영업이익 등이 확정된 값으로 들어있기 때문에, AI는 이를 바탕으로 그대로 차트와 표로 정리합니다.

이번 질문을 위해 실제로 API로부터 받은 입력 토큰량은, 필요한 3가지 지표(매출, 영업이익, 순이익)로만 한정하면 5년 치에 불과 약 250 토큰입니다. 모든 필드를 가져와도 5,700 토큰 정도입니다. 30만 토큰의 PDF와 비교하면 말 그대로 차원이 다릅니다.

출처는 경로 2와 마찬가지로 유보의 구조화된 XBRL 데이터입니다. EDINET에 제출된 숫자를 연결 기준 및 통화 단위를 맞춘 상태로 가져오기 때문에, 자릿수 오독은 구조적으로 발생하지 않습니다.

3가지 경로를 동일한 질문과 동일한 기업으로 비교하면 다음과 같습니다.

대략 정리하자면, 웹 검색 (Web Search)은 저렴하지만 출처가 분산되고, PDF 전문은 출처는 명확하지만 무거우며, 구조화 API + MCP는 출처가 명확하면서도 가볍다는 3층 구조로 되어 있습니다.

앞으로 AI 요금이 적정화됨에 따라 선택되는 경로는 바뀔 것입니다. 지금까지는 "PDF를 전부 읽게 해도 구독 서비스 범위 내라면 무료나 다름없었기" 때문에 PDF 경로에도 합리성이 있었습니다. 앞으로는 그 무게(비용)가 요금에 직접적으로 반영될 것입니다. "가볍고, 출처가 1차 자료이며, 필요한 만큼만 가져올 수 있는" 경로로 흘러가는 것은 자연스러운 움직임입니다.

입력 토큰 (Input Token)을 구조화 API로 집중시키면, 비용 측면 외에 또 하나의 큰 변화가 일어납니다. 바로 정확도입니다.

유가증권보고서 (有報) PDF를 AI에게 직접 읽히면 오독이 발생하기 쉬운 부분이 몇 군데 있습니다. 3자리 구분 숫자를 잘못 읽거나, 단위(백만 엔, 천 엔, 억 엔)를 혼동하거나, 연결 재무제표와 개별 재무제표를 혼동하거나, 여러 페이지에 걸친 표를 집계하지 못하는 경우입니다. 이는 AI의 추론 실수라기보다, PDF의 레이아웃과 수치 표현의 특성에서 기인하는 오독입니다. 입력값이 길어질수록 거기서 추출한 중간값의 오독이 하류 태스크 (Downstream Task) 전체를 왜곡합니다.

구조화 API에서 반환되는 데이터는 XBRL (금융청 EDINET의 XML 기반 공시)의 구조화된 값을 연결 기준 (Consolidated basis)으로 정규화하여 제공합니다. "revenue", "operatingIncome", "netIncome"이라는 필드가 전사 공통 정의로 되어 있으며, 자릿수·단위·통화가 통일된 확정값으로 반환됩니다. AI 측의 처리는 "수치를 해독하는 것"이 아니라 "이미 확정된 수치를 사용하여 무언가를 하는 것"이 되어, 할루시네이션 (Hallucination)이 개입할 여지가 크게 줄어듭니다.

즉, 구조화 API로 전환하면 입력 토큰 절감을 통한 비용 절감과 할루시네이션 감소를 통한 정확도 향상이 동시에 일어납니다. 비용과 품질이 트레이드오프 (Trade-off) 관계가 아니라 같은 방향으로 움직이는 보기 드문 구도가 됩니다.

EDINET DB는 일본 상장 기업 3,800개 이상의 유가증권보고서, 분기보고서, 결산 단신을 XBRL로부터 구조화하여 REST API와 MCP로 제공하는 서비스입니다. 동일한 운영 주체로서 부동산·REIT를 대상으로 한 FUDOSAN DB, 방재·기상·재해 영역의 BOUSAI DB를 운영하고 있으며, 나아가 법인 데이터베이스 등 다른 영역의 구조화 데이터 인프라도 정비해 나가고 있습니다.

이들에 공통된 설계 사상은 하나입니다.

"공개되어 있지만, AI나 사람이 즉시 사용할 수 있는 형태가 아닌" 1차 정보를 구조화하여 개방하는 것입니다.

유가증권보고서는 법적으로 공개 데이터입니다. 누구나 접근할 수 있어야 합니다. 하지만 PDF 안에 갇혀 있고, 업종 분류는 제각각이며, 기업마다 재무 항목의 이름조차 다릅니다. 제도적으로는 오픈되어 있어도 실질적으로는 클로즈드 (Closed)에 가까운 상태가 오랫동안 지속되어 왔습니다.

조금 보충하자면, 유가증권보고서는 2014년 이후 PDF와 병행하여 XBRL이라는 기계 판독 가능 포맷 (Machine-readable format)으로도 제출되고 있습니다. 이것은 구조화된 1차 정보 그 자체이지만, 기업마다 독자적인 택소노미 (Taxonomy) 확장이 허용되는 관계 때문에 항목명 (element_id)이 회사마다 제각각입니다. "매출액"이라는 동일한 개념이라도 A사는 jpcrp_cor:NetSales, B사는 jpcrp030000-asr_E12345-000:CustomNetSalesElement와 같이 서로 다른 라벨로 제출됩니다. 여기에 연결 기준인지 개별 기준인지의 구분, IFRS / JP GAAP / US GAAP의 차이, 전기 재무제표 수정 플래그 등, 생(raw) XBRL을 실용 가능한 상태로 만들기 위해서는 업계 전반에 걸친 명칭 통일 및 정규화 처리 계층이 필요합니다. EDINET DB가 하고 있는 일은 바로 이 계층을 전사·전 연도 분량으로 굳혀서 AI가 단 한 번의 쿼리로 사용할 수 있게 만드는 것입니다.

이 "공개되어 있지만 사용할 수 없는" 상태가 개인 투자자와 전문 애널리스트, 중소기업과 대기업, 지방과 도쿄 사이에 정보의 비대칭성을 낳았습니다. 데이터 인프라를 정비한다는 것은 그 비대칭성을 제도적이 아니라 실질적으로 없애는 것과 직결됩니다.

2026년 3월에 관련 에세이를 한 편 썼습니다. "'아는 것'이 무기였던 시대가 끝난다" — 정보 격차의 라스트 마일 (Last Mile)에 관한 내용입니다. 요점 하나를 인용하겠습니다.

세상에는 "인간이 데이터를 보기 위한 UI"가 무수히 존재하는 반면, "AI가 데이터를 읽기 위한 구조화 데이터"는 압도적으로 부족하다.

인쇄 혁명은 "정보의 양"을 바꾸었습니다. 인터넷은 "정보에 대한 접근"을 바꾸었습니다. AI는 "정보의 처리 능력"을 바꾸었습니다. 하지만 AI가 본래의 힘을 발휘하기 위한 "라스트 마일"이 남아 있습니다. 그것이 바로 1차 데이터의 구조화입니다.

그때는 하나의 "사상"으로서 작성했습니다. 이번 6월 15일의 Claude 요금 체계 변경은, 그 사상이 경제적 합리성의 측면에서 추인된 사건이라고 느낍니다.

AI를 저렴하게, 무제한으로 사용할 수 있었던 시대에는 라스트 원 마일(Last One Mile)을 누가 담당할지가 모호했습니다. AI 측에서 PDF를 힘으로 읽어내면 그만이었고, 구독 모델(Subscription)의 차익 거래 과정에서 비용이 명확히 보이지 않았기 때문입니다. 하지만 앞으로는 다릅니다. "읽는 비용이 보이는" 상태에서, 구조화된 데이터가 있느냐 없느냐가 AI 에이전트 운용의 월간 비용을 좌우하게 됩니다.

사상으로서 옳았는지 여부를 떠나, 구조화되지 않으면 사업으로서 지속할 수 없는 단계로 접어들었다는 뜻입니다.

6월 15일의 Claude 요금 체계 개편은 단발적인 뉴스로 보면 "프로그램 이용이 별도 과금 체계로 분리된다"는 이야기일 뿐입니다. 하지만 그 배경에는 AI의 단가가 장기적으로 적정화되는 흐름이 있으며, 이는 Anthropic에 국한된 움직임이 아닙니다.

이러한 흐름 속에서 AI 활용의 비용 경쟁은 모델 선택에서 "무엇을 읽게 할 것인가"로 무게 중심이 이동합니다. 월 200달러로 원하는 만큼 API를 마음껏 호출할 수 있던 시대가 끝나면, 입력 토큰(Input Token)을 구조화된 1차 데이터에 얼마나 가깝게 맞출 수 있느냐가 운용 비용의 자릿수를 결정하게 됩니다.

EDINET DB가 일본 상장 기업 데이터에 대해 수행하고 있는 노력은 이러한 구조적 변화를 앞서 내다본 설계입니다. 동일한 사상을 바탕으로 부동산(FUDOSAN DB), 방재(BOUSAI DB) 등 영역을 가로로 확장하며 정비 작업을 진행하고 있습니다. AI가 저렴하고 정확하게 다룰 수 있는 1차 데이터를 갖춰 놓는다면, AI 요금이 어떻게 변하더라도 운용 측면에서의 선택지로서 계속 기능할 것입니다.

무료 플랜에서도 API 키를 발급할 수 있습니다. MCP 서버는 설정 파일 한 줄로 연결이 가능합니다. Claude Code를 비롯하여, 사용 중인 AI 클라이언트에서 한 번 시도해 보시기 바랍니다.

• 원문 기사 (최신판·도표 포함): https://edinetdb.jp/blog/ai-cost-input-tokens-structured-db
• 개발자용 문서: https://edinetdb.jp/developers