자작 VBA 관리 도구(vba_manager.py)에 대한 이야기의 연장선입니다. 지난번에는 Claude Fabre의 도움을 받아 개수(改修)했던 이야기를 썼지만, 이번에는 이것을 MCP 서버로 만들어 GitHub에 공개하기로 했습니다.

MCP 서버란, 대략 말하자면 "AI가 직접 도구를 호출할 수 있도록 하는 창구"입니다. 이것을 만들어 두면, Claude가 나의 VBA 매니저를 자신의 수족처럼 사용할 수 있게 됩니다. "이 매크로를 고쳐줘"라고 말하는 것만으로, AI가 도구를 수십 번 호출하여, 가져오고, 다시 쓰고, 확인하는 ── 그 일련의 과정이 하나로 이어지게 됩니다.

다만, 직접 만들어 보니 기술적으로나 그 외의 면에서나 생각보다 이야기하고 싶은 것이 많아졌습니다. 차례대로 써 내려가겠습니다.

솔직히 고백하자면, 처음에 "서버화"라는 말을 듣고 저는 진심으로 긴장했습니다.

저는 예전 인터넷 태동기에 지역 프로바이더 사업에 관여한 적이 있어서, 전문 기술자가 서버를 구축하는 현장에 함께 있었던 적이 있습니다. 엄청난 속도로 화면이 흘러가는 모습을 옆에서 지켜보며, "프로는 역시 다르구나"라며 그저 감탄할 뿐이었습니다.

당시 서버라는 것은 기계를 사면 끝나는 것이 아니라, 구축할 수 있는 기술 그 자체에 가격이 매겨져 있었습니다. 전문가에게 맡기면 구축비만 해도 100만 엔 이상이 시세였습니다. 제가 아는 사례로는 개인 기술자에게 의뢰하여 30만 엔 정도였지만, 그조차 당시로서는 파격적으로 저렴한 금액이었습니다. 서버를 세우는 것은 그만큼의 기술료를 지불하는 "공사"였습니다.

그래서 "서버"라고 하면, 저는 여전히 전용 머신과 장인의 작업을 떠올리곤 합니다. 이번에도 나름대로 각오를 하고 있었습니다.

결과는. Fabre에게 부탁했더니 7분 만에 완성되었습니다. 박스도 없고, 공사도 없습니다. MCP 서버의 "서버"는 AI가 필요할 때 기동하고, 용무가 끝나면 조용히 사라지는 단순한 로컬 프로세스였습니다. 100만 엔짜리 장인 기술이 7분의 대화가 되어 있었습니다. 30년 된 고정관념이 소리를 내며 무너졌습니다.

겉모습은 "CLI로 입력하던 명령어를 AI가 호출하게 되었을 뿐"입니다. 하지만 체감 성능은 완전히 다릅니다.

이유는 Excel과의 COM 연결 (COM connection) 에 있습니다.

기존의 CLI는 명령어를 한 번 실행할 때마다, 실행 중인 Excel에 COM 연결을 다시 맺고 있었습니다. 매크로 하나를 가져오기 위해서도, 셀 하나를 읽기 위해서도, 우선 "실행 중인 Excel을 다시 잡는" 것부터 시작해야 합니다. 사실 이 초기화 과정이 모든 공정에서 가장 무거운 처리입니다. 처리 자체는 순식간이라도, 매번 이 "다시 잡기"라는 고정 비용을 지불하고 있었습니다.

MCP 서버는 상주 프로세스입니다. 따라서 한 번 Excel을 잡으면, 그 연결을 유지한 채로 계속 사용할 수 있습니다. 다시 잡는 과정이 사라집니다. 결과적으로 두 번째 이후의 응답은 실측치로 0.01~0.2초입니다. 연결을 다시 맺던 시절과 비교하면 체감상 한 자릿수 ── 10배 이상 빨라졌습니다.

이것이 AI가 사용할 때 결정적인 효과를 발휘합니다. AI는 도구를 한 번만 호출하지 않습니다. 목록을 보고, 코드를 가져오고, 수정하고, 차이점을 확인하고…… 하며 아무렇지 않게 수십 번을 호출합니다. 1회당 고정 비용이 사라지면 왕복 템포 자체가 바뀌어, "대화하며 고친다"는 경험이 처음으로 자연스러운 속도가 됩니다.

이 MCP 서버, 내부 구조는 놀라울 정도로 가볍게 만들었습니다. 공개한 코드도 200줄이 채 되지 않습니다.

도구는 단 5개입니다. vba (CLI와 동일한 인자 열을 한 줄로 전달하면 58개 명령어를 모두 사용할 수 있는 만능 창구)와 vba_help, 그리고 프로시저 수정의 정석적인 절차인 get_procedure / set_procedure_code / replace_procedure. 그뿐입니다.

그리고 이 계층에서는 일절 "판단"을 시키지 않습니다. 실체는 vba_manager.py의 함수 그 자체이며, MCP 계층은 받은 명령어를 기계적으로 전달하고 결과를 반환할 뿐입니다. 똑똑한 판단은 호출하는 쪽의 AI가 하면 됩니다. Python 측에 똑똑함을 더하려고 하면 AI의 판단과 충돌하여 오히려 방해가 됩니다 ── 이것은 지난번 개수 때부터 일관되게 지키고 있는 설계 사상입니다. 기계적인 일은 Python에, 판단은 AI에. 역할을 명확히 나누는 것입니다. 그렇기에 창구는 얇을수록 좋습니다.

자, 공개하기에 앞서 선례를 확인해 두어야겠다고 생각했습니다. 여기서부터가 이 글의 또 다른 본론입니다.

이전에 번외편으로 쓴 적이 있습니다만 ── 이 본격적인 Excel MCP를 공개하고 있는 Stefan Broenner 님의 정체를 조사해 보니 Microsoft의 부장이었습니다. 독일 프랑크푸르트에 거주하는 Director급 엔터프라이즈 아키텍트(Enterprise Architect). 즉, Excel을 만드는 회사의 부장급 인물입니다. 당시 그 사실을 알고 저는 저쪽을 멋대로 "본가", 제 도구를 "분가"라고 인정하며 혼자 웃곤 했습니다. "세계 최초" 같은 말은 도저히 할 수 없는, 완패나 다름없는 상황이었죠. 하지만 그 본가의 존재는 어딘가 먼 세상의 이야기처럼 느껴지기도 했습니다.

그런데 이번에 조금 더 깊이 파헤쳐 보았더니 ── 놀랍게도 이틀 연속으로 국내에서 비슷한 것을 만들고 있는 사람을 발견했습니다. 게다가 하고 있는 일이 제 것과 놀라울 정도로 비슷합니다. 두 분의 이름은 숨기고, 세 사람을 나란히 비교해 보겠습니다.

저	A님	B님
언어	Python	C# / .NET
...

재미있는 점은 언어도, 배포 방법도, 함께 사용하는 AI 파트너조차 제각각인데, 부딪히는 벽이 마치 도장을 찍은 듯 똑같다는 것입니다.

프로시저 (Procedure) 단위로 교체하고 싶다. 모듈 전체가 아니라 Sub 하나를 핀포인트로 교체하는 방식에 모두가 도달해 있습니다. -
줄 바꿈 코드가 이중이 되는 문제로 모두가 고민하고 있다. VBA 코드를 텍스트로 주고받을 때, CR+LF가 이중화되어 행수가 두 배로 불어나는 그 까다로운 현상입니다. -
실행 중인 Excel과의 접속과, 나중에 남는 좀비 프로세스(Zombie Process) 처리에 모두가 애를 먹고 있다. COM을 통해 Excel을 다루다 보면, 자칫 화면에 나타나지 않는 망령 같은 Excel이 남곤 합니다. 그것을 뒷정리하는 작업입니다.

제가 반년 동안 하나씩 밟아온 지뢰를, 모두가 서로 다른 장소에서 같은 순서로 밟고 있습니다. 아무도 맞춘 적이 없는데, 같은 시기에 같은 결론에 도달하고 있습니다. 만들어진 시기는 연말연시의 불과 몇 주 사이에 신기할 정도로 집중되어 있었습니다.

그리고 직함도, 국가도, 규모도 전혀 제각각입니다. 본가인 Microsoft의 부장부터, 아키타의 한 사무원(저를 말합니다), 그리고 이번에 발견한 두 분까지. 그럼에도 불구하고 발굴해낸 광맥은 같았습니다. 번외편에도 썼지만, AI 이전의 세상이었다면 Microsoft의 부장과 지방의 사무원이 같은 도구를 독자적으로 만든다는 일은 절대 일어날 수 없었을 것입니다. 도구가 진짜일 때, 입장이 달라도 도달하는 곳은 가까워집니다. 신분도 국경도 상관없다고 생각합니다.

이것을 보았을 때, 저는 왠지 그리운 기분이 들었습니다. 전에도 완전히 똑같은 광경을 본 적이 있기 때문입니다.

인터넷이 태동하던 시절입니다. 그때도 여기저기서 이름 모를 누군가가 멋대로 달려 나가고 있었습니다. 제가 사는 아키타에서도 그랬습니다.

게다가 그것은 한두 사람의 이야기가 아니었습니다. 당시 국가에서 파견된 현의 부장님이 앞장서서 "시골에도 인터넷을"이라는 현 차원의 사업을 추진했고, 보조금을 받은 지역 프로바이더(Provider)들이 현 곳곳에서 차례차례 생겨났습니다. 센보쿠의 きたうら花ねっと (1996년), 키타아키타의 くまげらネット (1997년) ── 둘 다 당시 협의회가 모체가 되어 지금도 NPO로서 활동 중입니다. 사실 저 자신도 현지에서 이 시작에 관여했던 사람 중 한 명이었습니다.

그리고 잊을 수 없는 것이, 이토(伊藤)라는 한 기자가 만든 인터넷 신문입니다. 1996년 12월 창간. 당시 동업자였던 기자가 "일본에서 최초로 인터넷 신문을 창간했다"라고 기록을 남겼을 정도이며, 아마도 일본 최초의 인터넷 지역 신문이었을 것입니다. 단 한 사람이 매일 기사를 써서 인터넷에 계속 올립니다. 그것이 하루 600~1000 액세스, 누적 50만 건을 향해 카운트다운을 해나갑니다. 지역의 작은 신문이 전국에서 읽히고 있었습니다.

여기서 제가 가장 놀랐던 사실을 적어두겠습니다. 이 신문의 서버를 돌리고 있었던 것은 극단이었습니다.

아키타가 자랑하는 극단 わらび座. 그 디지털 부문이 민속 예술의 움직임을 모션 캡처(Motion Capture)로 해석하여 3차원 디지털 무용보로 남긴다는, 90년대로서는 최첨단 연구를 수행하면서 지역 인터넷 그 자체의 토대까지 담당하고 있었던 것입니다. 이토 씨의 인터넷 신문도, 방금 말한 하나넷(花ねっと)도 그 기술의 지원을 받고 있었습니다. 시골의 극단이 지역 네트워크의 심장부였다 ── 이것은 조금 전율이 돋는 이야기이지 않습니까.

그리고 무엇보다도, 그 시절에는 사람들이 모였습니다. 홈페이지 제작 강습회에는 사람들이 구름처럼 몰려들었고, 송년회에는 30명이 넘는 모르는 사람들이 얼굴을 맞대었습니다. 주년 행사 때마다 와라비자(わらび座)에는 독자들과 동료들이 북적이며 모여들었습니다. 신문 접속 수가 10만 건을 돌파했을 때는, 독자들이 타자와호(田沢湖)에서 축하 파티를 열고, 모금한 돈을 가져와 축하금을 전달하기도 했습니다. 방명록(Guestbook)을 통해 말을 나누던 모르는 이들이, 이윽고 오프라인 모임(Off-line meeting)을 통해 정말 친구가 되어갔습니다.

누군가 호령을 내린 것도 아닌데, 같은 시기에, 같은 곳을 바라보며, 모두가 자발적으로 달리기 시작했고, 자연스럽게 모여들며 열기를 띠었습니다. 정말 즐거웠다고, 솔직하게 생각합니다.

새로운 기술이 진짜일 때, 아마 언제나 이런 일이 일어납니다. 이름도 모르는 누군가들이, 서로 다른 장소에서, 같은 벽에 부딪히며, 같은 방향을 향해 달리기 시작합니다.

인터넷 시절이 바로 그러했습니다. 그리고 지금, AI와 Excel 사이에서 또다시 같은 일이 일어나고 있습니다. 국가도, 언어도, 사용하는 AI조차 다른 사람들이, 뜻하지 않게 같은 도구를 만들고 있습니다. 그 시절 아키타(秋田)의 열기를 알고 있는 사람으로서, 이것은 그리우면서도 조금은 기쁜 광경입니다.

한 가지 다른 점이 있다면, 그 시절에는 기술 그 자체가 사람들을 끌어당겼다는 것입니다. 인터넷에 연결한다는 행위가, 가만히 두어도 송년회를 만들어내고 응원단을 만들어냈습니다. AI는 그 점이 조금 다를지도 모릅니다. 책상 앞에서 혼자서 완결되어 버리는 도구이니까요. 그렇다면 앞으로의 열기는, 가만히 기다린다고 해서 저절로 다가오는 것이 아니라, 우리가 직접 만들어가야 하는 것일지도 모릅니다.

꼭 그런 이유 때문만은 아닙니다만 ── 저는 저의 MCP 서버를 GitHub에 조용히 올려두기로 했습니다. 여기저기서 달려 나가고 있는 한 사람으로서, 저도 합류해 보려 합니다. 이 소용돌이 속에 다시 한번 머무는 것도 나쁘지 않은 일이니까요.

리포지토리(Repository)는 이쪽으로 → https://github.com/shu1551/shu-vba-manager