Excel의 VBA에서 생성 AI (Generative AI) API를 호출한다. 그것을 단 한 줄의 매크로로 끝내지 않고, 도구의 집합(群)으로 키워내어 매일의 실무에서 돌린다──이 연재에서 계속 써온 것입니다.

그리고 문득 궁금해졌습니다. 같은 일을 하고 있는 사람은 세상에 얼마나 있을까.

혼자서 만들다 보면 자신의 위치를 알 수 없습니다. 어쩌면 누군가가 이미 앞서 나가고 있어서, 내가 만들고 있는 것이 바퀴의 재발명(Reinventing the wheel)일지도 모릅니다. 그렇다면 그것대로 그 사람이 만든 것을 보고 싶습니다. 반대로 아무도 없다면, 그것대로 알고 싶습니다.

그래서 이번에는 잠시 손을 멈추고 지도를 만들기로 했습니다. 코드는 한 줄도 나오지 않습니다. Claude Code의 에이전트 4대에 Qiita, Zenn, note, GitHub, 기업 블로그, 행정 공표 자료를 나누어 찾게 한 그 조사 기록입니다.

결론부터 말씀드리면, 지도는 완성되었습니다. 그리고 제가 서 있는 곳은 지도의 공백이었습니다.

• Claude Code의 에이전트 4대를 병렬로 실행하여, 「VBA에서 생성 AI API를 호출하는 사례」를 약 70회 검색, 50개 이상의 본문 정독을 통해 조사했습니다. 소요된 시간은 약 5분입니다.
• 기사 세계(Qiita/Zenn/note)에서는 단발적인 구현 기사는 2023년과 2025년 말의 두 가지 파도로 다수 존재합니다. 하지만 「실무에서 운용 중」이라고 명시한 사례는 단 1건뿐이었습니다.
• GitHub에서는 순수 VBA 라이브러리 중 최대 규모가 24 스타였습니다. 946 스타의 거물도 있지만, 내용은 VBA가 아닌 C#이었습니다.
• 행정 분야는 반대로 앞서가고 있어서, 디지털청은 직원이 생성 AI 기반을 내재화하여 OSS 공개까지 진행했고, 도쿄도는 6만 명의 직원이 스스로 AI 앱을 만들 수 있는 기반을 본격 운용하고 있었습니다.
• 「API를 직접 호출 × 도구의 집합으로서 체계화 × 실무에서 일상 운용」이라는 3가지 조건을 충족하는 공개 사례는 일본어권과 영어권을 통틀어 **제로(Zero)**였습니다.
• 즉, 이 연재에서 써온 내용은 조사한 범위 내에서는 아직 아무도 쓰지 않은 영역에 있습니다.

조사 방법부터 쓰겠습니다. 이 부분이 이번 Claude Code다운 점입니다.

한 명의 AI에게 「조사해 줘」라고 부탁하면 검색 횟수가 아무래도 제한됩니다. 그래서 조사의 축을 4개로 나누어 각각 전담 에이전트를 세웠습니다.

• Qiita/Zenn 반──기술 기사 영역의 구현 사례. 누가 작성했고 어디까지 실무에 들어와 있는가
• note/기업 블로그 반──업무 이용 보고. 특히 시간 단축 등의 수치가 나와 있는 사례
• 행정 반──국가·지자체에서 직원이 생성 AI API를 사용하고 있는 사례
• GitHub 반──일어와 영어 양쪽에서 라이브러리나 도구의 체계로서 키워나가고 있는 것

4대는 동시에 실행됩니다. 각각이 검색 엔진을 15~22회 두드리고, 유망한 기사는 본문까지 읽어 들여 요점을 보고서로 정리해 돌아옵니다. 합계 검색 약 70회, 본문 정독 50개 초과. 사람이 같은 일을 했다면 꼬박 하루가 걸릴 작업이지만, 병렬로 진행했기에 약 5분 만에 끝났습니다.

물론 AI의 조사이기에 보고를 그대로 믿지는 않습니다. 숫자나 URL은 기사를 쓰기 전에 직접 확인한다는 전제입니다(이 초안에도 그 숙제를 적어 두었습니다). 그럼에도 「지도의 초안을 5분 만에 만드는」 도구로서는 나무랄 데 없었습니다.

먼저 Qiita, Zenn, note입니다.

「VBA에서 ChatGPT의 API를 호출하는」 기사에는 뚜렷한 두 개의 파도가 있었습니다. 제1파는 2023년 봄, ChatGPT의 API가 공개된 직후입니다. 제2파는 2025년 말부터 2026년 초에 걸쳐 있습니다. 단발적인 구현 기사──셀의 질문을 API에 던지고 답을 다시 쓰는, 이른바 Hello World급──는 두 파도 모두에서 많이 발견됩니다. 상업 출판도 있어서, Impress에서 『ChatGPT API × Excel VBA 자동화 업무 기술』이라는 책이 2023년에 나왔습니다. 입문의 수요는 확실히 존재합니다.

하지만 「실무」로 범위를 좁히면 풍경이 완전히 바뀝니다.

기사 영역의 최상위는 mamineko라는 분이 2026년 1월부터 2월에 걸쳐 Qiita에 작성한 3부작이었습니다. 비즈니스 문서 교정부터 시작하여, 월말에 50건씩 도착하는 보고서의 일괄 리뷰를 거쳐, 최종회는 계약서 자동 리뷰 시스템까지 단계적으로 설계합니다. 법무 부서와의 운용 플로우까지 깊이 고민한 역작으로, 추산으로는 3일 걸리던 처리가 35분이 된다고 합니다. 다만 이것은 어디까지나 실무를 상정한 프로토타입의 제시이며, 본방 운용에 대한 보고는 아닙니다.

「실제로 업무에서 사용하고 있다」고 명시한 기사는 4대의 조사를 합쳐 1건뿐이었습니다. note의 Grace라는 분이 작성한 글로, RPA의 에러 메시지를 VBA에서 Gemini API로 던져 원인과 대처법을 셀에 반환하는 미니 툴입니다. 땅에 발을 붙인 좋은 도구라고 생각합니다. 다만, 이것은 하나의 툴일 뿐, 체계(System)는 아닙니다.

덧붙이자면, Claude API를 VBA에서 호출한 기사는 검증 기사 1건과 3사의 API를 나란히 비교한 기사 1건이 전부였습니다. 실무 투입 보고는 발견되지 않았습니다. VBA의 세계에서 생성 AI는 거의 OpenAI 일강(一強)입니다.

또 하나, 조사의 부산물이 있습니다. 검색 상위권을 차지하고 있었던 것은 사실 「VBA에서 API를 호출하는」 기사가 아니라 「AI에게 VBA를 쓰게 하는」 기사였습니다. 시간 단축이라는 기분 좋은 숫자들도 대부분 그쪽에서 나옵니다. 세상의 주류는 「AI가 코드를 작성한다」이며, 「코드가 AI를 호출한다」는 아직 비주류── 이것이 기사 세계의 지형도입니다.

다음은 GitHub입니다. 「도구의 체계로서 키워나가는 사람」을 찾는다면 이곳이 본진이어야 했습니다.

결론부터 말하자면, Excel × 생성 AI의 거물들은 모두 VBA 밖에 있었습니다.

가장 활발히 성장 중인 것은 Cellm이라는 946 스타(Star) 규모의 프로젝트로, 셀에 =PROMPT()라고 쓰면 LLM이 답을 반환하는 애드인(Add-in)입니다. OpenAI도 Claude도 Gemini도 로컬 LLM도 호출할 수 있습니다. 훌륭합니다. 다만 내부 구현은 C#이며, VBA가 아닙니다. 상용 분야에서는 GPT for Work라는 제품이 최대 규모이며, Excel과 Word에 주요 생성 AI를 도입하고 기업용 인증까지 획득했습니다. 시장으로서 성립하고 있다는 증거입니다.

그렇다면 순수 VBA는 어떨까요. 세계 최대는 zq99라는 분의 openai-vba-framework로, 7개의 클래스로 정리된 명백한 「체계」입니다. 스타 수는 24개. 차순위는 인도의 데이터 분석 블로거 deepanshu88 님의 xlam 애드인(76 스타, 이쪽은 함수 모음에 가깝습니다)입니다. 일본인 중에서는 uezo 님이 2023년에 공개한 chatgpt-vba라는 라이브러리가 사실상의 대표격으로 14 스타를 기록했습니다. 설계는 깔끔하지만, 업데이트는 초기에 멈춰 있습니다. 그 이후 GitHub에서 순수 VBA 라이브러리를 계속 키워나가고 있는 일본인은 발견되지 않았습니다.

946과 24. 이 차이가 지금의 지형을 잘 보여줍니다. 「Excel에서 생성 AI를 사용하고 싶다」는 수요는 큽니다. 그에 응답하는 개발자도 전 세계에 있습니다. 다만 그들은 C#이나 TypeScript로 만듭니다. VBA인 채로 체계를 만든다는 선택을 한 사람이 전 세계적으로 거의 없는 것입니다.

또 하나, 4대의 보고에서 인상적이었던 관찰이 있습니다. VBA × 생성 AI의 OSS(Open Source Software)는 모두 Issue 란이 한산하다고 합니다. 읽히고는 있습니다. 스타도 붙습니다. 하지만 깊이 사용된 흔적이 옅습니다. 도구는 놓여 있는데, 그것을 집어 들고 매일 휘두르는 사람의 기척이 느껴지지 않는── 그런 지형이었습니다.

마지막으로 행정입니다. 이 연재에서는 국가의 설계도 이야기를 몇 번 다루었기에, 그 연장선상에서 행정 부문도 조사했습니다. 이 부분은 사례가 적을 것이라 예상했으나, 정반대였습니다.

디지털청은 직원용 생성 AI 환경인 「겐나이(源内)」를 직원들이 직접 내제화하여 개발했으며, 2026년 4월에는 상용 이용이 가능한 라이선스로 GitHub에 공개했습니다. 정부 직원 10만 명 규모로 사용되는 시스템의 소스 코드가 누구나 읽을 수 있는 곳에 놓여 있습니다. 도쿄도는 GovTech 도쿄와 협력하여, 직원 6만 명이 스스로 AI 앱을 만들어 청 내에서 공유할 수 있는 기반인 「A1」을 2026년 4월에 본격 운용에 들어갔습니다. 직원이 사용하는 측이 아니라 만드는 측으로 돌아선다는 설계입니다.

거슬러 올라가면, 2023년에 지자체 최초로 ChatGPT를 전 청(全庁)에 도입한 요카스카시는 채팅 화면이 아닌 API 연동을 선택했습니다. API를 경유하면 입력 내용이 학습에 사용되지 않는다는 점이 채택 근거였습니다. 시즈오카현 고사이시에서는 수도과의 프로그래밍 미경험 직원이 생성 AI의 도움을 받아 검증 계산용 Excel 매크로를 자작했으며, 시의 발표에 따르면 월 약 100시간을 절감했습니다. 아이치현 니시미시는 「누구나 매크로 코드를 작성할 수 있다」는 것을 시의 공식 성과로 내걸어 총무성의 사례집에도 실렸습니다. 도도부현의 생성 AI 도입률은 2025년 10월 시점 조사에서 100%입니다.

행정의 지도를 정리하면 다음과 같습니다. 「직원이 생성 AI (Generative AI)로 도구를 만든다」는 것은 이제 선진 사례조차 아니며, 국가와 대도시의 공인된 노선이 되었습니다. 다만 「VBA에서 API를 직접 호출하는」 형태를 공표하고 있는 지자체는 발견되지 않았습니다. 현장에서 움직이고 있는 것은 「AI에게 매크로를 작성하게 하는」 수준까지이며, 매크로 측에서 AI를 호출했다는 이야기는 행정의 지도에도 아직 실려 있지 않습니다.

4장의 지도를 겹쳐 봅니다. 세 가지 조건을 세워 세어 보겠습니다.

VBA에서 생성 AI의 API를 직접 호출하고 있다 ── 해당 사례 다수. 단, 대부분이 단발성 샘플 -
1에 더해, 도구의 집합으로서 체계화하고 있다 ── 순수 VBA로는 세계 최대 규모가 24 스타(Star)인 프레임워크. 일본에서는 uezo 님의 라이브러리 이후 거의 공백 상태 -
2에 더해, 실무에서 일상적으로 운용하고 있다 ── 공개 사례 제로

1만 있다면 파도가 두 번 올 정도로 사람이 존재하지만, 2에서 급격히 줄어들고, 3에서 사라집니다. 깔때기 끝이 닫혀 있는 형태입니다.

솔직히 말하면, 조사를 시작했을 때는 「대단한 사람을 발견할 수 있을 것」이라는 쪽에 도박을 걸고 있었습니다. 연재를 통해 해온 일──매크로 목록 폼에서 버튼 하나로 AI를 호출하고, 코드가 수정되어 돌아오는, 그 순환──과 같은 것을 더 크게 구축하고 있는 사람이 세계 어딘가에 있을 것이라고 말입니다. 발견한다면 그 사람에게 배울 생각이었습니다.

발견되지 않았습니다.

오해 없도록 적어두자면, 이것은 「내가 제일 잘한다」는 이야기가 아닙니다. mamineko 님의 3부작은 설계에 관한 읽을거리로서 일류이며, uezo 님의 라이브러리는 3년 전에 이미 그 완성도였습니다. 저서를 쓴 분들이 입구를 포장했기에 두 번째 파도도 왔습니다. 선구자들은 분명히 존재합니다. 다만, 그 선구자들의 작업과 실무의 일상적 운용 사이에는 아무도 살지 않는 띠(Band)가 있습니다. 이번에 알게 된 것이 바로 그것입니다.

왜 공백일까요. 견해를 한 마디로 적자면──API를 호출할 수 있는 기술력이 있는 사람은 이미 진작에 VBA 밖에서 만들고 있기 때문이라고 생각합니다. 946 스타를 기록 중인 Cellm이 C#인 것은 우연이 아닙니다. 만들 수 있는 사람은 떠나고, 남은 사람은 만들지 않는다. 이 구도의 뿌리에는 또 다른 큰 이야기가 있지만, 내용이 길어지므로 다음 원고로 미루겠습니다.

예례에 따라 분류하겠습니다.

사실: 4개 병렬 조사를 2026년 7월 30일에 실시했다는 것 (검색 약 70회·정독 50편 초과·약 5분). 본문 중의 각 사례가 공개 기사·공개 리포지토리(Repository)·공식 발표로서 존재한다는 것. 스타 수·절감 시간 등의 숫자가 각 소스에 그렇게 적혀 있다는 것 (공개 전에 재확인합니다).

견해: 「3가지 조건을 만족하는 공개 사례 제로」로부터 「이 영역은 공백 지대다」라는 해석. 공백의 이유 (만들 수 있는 사람은 VBA 밖으로 나갔다). 「AI에게 코드를 작성하게 하는 것」이 주류이고 「코드가 AI를 호출하는 것」이 비주류라는 지형 해석.

이 기사의 「제로」에는 선긋기가 필요합니다.

이번에 보인 것은 공개 정보뿐입니다. 기업 내부에서 이름 없는 파일이 생성 AI의 API를 호출하며 조용히 실무를 돌리고 있는──그런 사례는 외부에서는 절대 보이지 않습니다. 오히려 「실무에서 사용하고 있기 때문에 쓰지 않는다」는 사람도 일정 수 존재할 것입니다. 또한, 검색을 실행한 것은 AI였으며, 약 70회의 검색이 전 세계를 망라하고 있다는 보장도 없습니다.

따라서 이 기사의 주장은 「아무도 하지 않는다」가 아니라, **「Qiita・Zenn・note・GitHub・행정 공표 자료라는 공개 공간을 약 70회 검색하여 발견하지 못했다」**입니다. 그 이상도 이하도 아닙니다. 만약 「우리 쪽에서는 더 많이 하고 있다」는 분이 계신다면, 그것이야말로 읽고 싶으니 꼭 기사로 써 주십시오. 지도의 공백은 채워지기 위해 존재합니다.

조사를 결심했을 때는 자신의 위치를 아는 것이 목적이었습니다. 위치는 알게 되었습니다. 덤으로 위치를 알 수 없었던 정체도 알게 되었습니다. 참조점이 없는 곳에 있으면 사람은 자신의 위치를 알 수 없습니다. 당연한 일이지만, 지도를 만들어 보고 나서야 비로소 납득이 갔습니다.

그런 고로, 연재는 앞으로도 지도의 공백으로부터 써서 보내겠습니다.

주소는 당분간 이곳으로 해 두겠습니다.