Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
VBA 환경에 대한 한계와 AI의 적용 가능성에 대한 논의가 활발합니다. 글쓴이는 VBA가 구조적 감옥이 아니며, GAS나 Python COM 서버를 활용하여 외부 최신 AI(Claude/Gemini)와 연결하고 있음을 강조합니다. 또한, AI 리팩토링의 위험성을 '핀포인트 수정'과 '관문 테스트'로 극복했다고 설명하며 자신의 개발 환경을 소개합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이틀 전 밤에 공개한 이전 글이 감사하게도 큰 반향을 얻고 있습니다.
직접 만든 환경인 '秀コンボ'에서 발생했던 통신 침묵 사건과, Claude 자신이 내장했던 취약한 결정론을 Gemini가 폭로하고 수정했던 일련의 과정을 정리한 글입니다.
관리 화면을 열어보니 조회수는 3,752 views를 기록했습니다. 이로써 3개 글 연속으로 2,000회를 돌파하게 되었습니다.
'꽤 많이 읽히네'라며 놀라고, 손에 있는 Excel을 만지작거리면서 감사함을 느꼈습니다.
그런 와중에 어제 유튜브에서 해설 영상이 올라온 것을 보았습니다.
제목은 'VBA만 할 수밖에 없는 엔지니어는 존재하는가'라는 취지의 것이었습니다.
아직 공개된 지 하루도 되지 않은 영상이었지만, 조회수도 물론 중요했지만 무엇보다 댓글 창의 열기에 눈을 빼앗겼습니다. 현장 엔지니어와 사무직 분들로부터 절실하고 생생한 목소리가 줄줄이 적혀 있었습니다.
'임의로 프로그래밍 환경을 구축할 허가조차 받기 어려워서, 결국 VBA밖에 없다.'
'바다 건너(최신 기술)에 동경하는 사람처럼, 오늘도 VBA를 쓰면서 외부 세계를 생각하고 있다.'
'VBA 전담 수요는 있을 것이다. 핵심부에 부정적 유산인 스파게티 코드가 있어서, 아무도 사양서(仕様書)를 만들 수 없으니까.'
화면을 스크롤하면서 저는 '세상에서는 시대에 뒤떨어졌다고 여겨지기 쉽지만, 현장의 최전선에서 VBA와 진지하게 마주하고 있는 사람들이 지금도 이렇게나 많구나'라며 놀랐고, 어딘가 마음이 든든해지는 기분이 들었습니다.
하지만 동시에 영상의 해설이나 댓글 창 속에서 반복적으로 언급되는 '포기'라는 단어에도 눈길이 갔습니다.
'VBA에는 구조적인 감옥(檻)이 있다. Office 파일 내부에서만 작동하기 때문에, 외부 세계로는 나갈 수 없다.'
'AI와 VBA는 궁합이 안 좋다. 실행 환경 자체가 오피스 앱이라서, AI 스스로 디버깅할 수가 없는 게 힘들다.'
'업무와 코드가 밀접하게 결합되어 있어서, AI가 리팩토링(refactoring)을 하게 하면 새로운 혼돈이 생긴다.'
그러한 말들을 바라보면서, 저는 집 컴퓨터에서 돌아가는 저의 개발 환경을 되돌아보았습니다.
그리고 문득 생각했습니다.
'어라...? 이거 혹시 제 손에서는 이미 되어 있는 게 아닐까?'
세상이 '불가능하다', '무리가다'라고 포기하고 있는 벽을, 저는 집 컴퓨터에서 끈질긴 공들임(工夫)을 거치면서 벌써 넘어선 것이 아닌가.
오늘 밤은, 영상과 댓글 창의 뜨거운 논의에 힘을 얻으면서, 손에 있는 실기에서 돌아가는 '또 다른 현실'에 대해 써보려고 합니다.
어제 유튜브 영상의 열기: 'VBA만 할 수밖에 없는 엔지니어는 존재하는가'라는 영상 댓글 창에는 환경 구축이 허락되지 않은 현장의 절실한 목소리가 넘쳐흘렀고, 지금도 VBA가 현장의 심장부를 지탱하고 있다는 현실을 재확인했습니다. -
영상 속 '외부로 나갈 수 없다'는 오해: VBA는 감옥에 갇혀 있는 것이 아닙니다. GAS(Google Apps Script) 중계기를 거치면 Google Workspace와 연결되며, 직접 만든 Excel 조합으로는 로컬의 최신 AI(Claude / Gemini)와 직접 파이프를 연결하여 대화하고 있습니다. -
댓글 창의 'AI는 자체 디버깅할 수 없다'는 포기: AI가 Excel 실행 환경을 직접 건드릴 수 없는 것은 도구를 준비하지 않았기 때문입니다. Python의 MCP 서버(Excel 매니저)로 직접 COM(Component Object Model)을 장악하게 함으로써, AI 스스로 전체 컴파일을 거치고 테스트를 돌려서 자가 복구하는 루프는 이미 제 손에서 매일 작동하고 있습니다. -
'리팩토링으로 혼돈이 생긴다'는 것을 막는 이중 방벽: 코드 전체를 AI에게 맡기지 않고, 지시된 줄만 0.09초 만에 교체하는 '핀포인트 수정(patch-procedure)'과, 전체 컴파일 + 테스트 전 문 합격을 의무화한 '관문 테스트'로 안전성을 완벽하게 확보하고 있습니다. -
사양서가 없는 문제도 자동화 가능: docs
(사용 설명서 생성), flow
(Mermaid 흐름도), checkup
（健康診断）そしてマクロの頭数行から手順書を自動組み立てる仕組みにより、ブラックボックスは構造的に消滅させられます.
왜 Copilot은 VBA를 직접 편집하지 않는가: VBA는 외부로 나갈 수 없을 뿐만 아니라, Win32 API나 파일 시스템을 건드릴 수 있는 '너무 강력한 로컬 권한'을 가지고 있기 때문에, 클라우드의 Copilot에서는 안전 관리가 어려워 손댈 수 없다는 것이 현장의 견해입니다.
그리고 지금, 제가 부딪히고 있는 '진짜 벽': 세상이 '할 수 없다'고 말하는 것은 제 책상 위에서 넘어설 수 있었을지도 모릅니다. 그렇기 때문에 저는 지금 '수학의 난제조차 푸는 AI의 지능을 어떻게 자율적인 '선반 빌더(shelf builder)'로 승화시킬 것인가'라는, 그 너머에 있는 진짜 벽과 씨름하고 있습니다.
어제 공개된 영상은 1993년 Excel 5.0에 VBA가 탑재된 이래의 역사를 되돌아보며, 'VBA는 처음부터 엔지니어가 아닌 사람(회계나 영업)을 위해 만들어졌다', '매크로 기록과 환경 구축이 필요 없다는, 세계에서 가장 낮은 진입 장벽이었다'라는 본질을 짚어낸 매우 볼만한 내용이었습니다.
다만, 그 영상의 전개나 댓글란의 논의를 읽어보면, 몇 가지 '결정적인 포기'가 공통된 전제로서 이야기되고 있었습니다. 주로 다음 세 가지입니다.
'VBA는 구조적인 우리 안에 갇혀 있어 외부 세계로 나갈 수 없다'
Office 파일 내부에서만 작동하고, 단독 앱도 웹 서비스도 만들 수 없다. 그래서 핵심 시스템이나 웹과 연결하려면, SQL이나 PowerShell 같은 외부 기술에 의존할 수밖에 없다는 견해입니다.
'AI는 Excel 실행 환경을 직접 건드릴 수 없어 셀프 디버깅이 안 되어 궁합이 나쁘다'
댓글란에서 강력한 공감을 얻었던 의견입니다. AI에게 코드를 작성하게 할 수는 있지만, 실행 환경이 오피스 데스크톱 앱이기 때문에, 작성된 후의 디버깅을 AI 스스로 자율적으로 할 수 없다. 사람이 복사 붙여넣기(copy-paste)하여 에러를 전달해야 하므로 실용성에 미치지 못한다는 포기입니다.
'업무와 코드가 밀접하게 결합되어 있어, AI가 리팩토링하면 새로운 혼돈이 생긴다'
현장의 매크로는 이어 붙인 스파게티 코드투성이이며, 사양서도 없습니다. 거기에 AI의 손을 넣으면, 불필요한 곳까지 수정해 버려서 업무가 다운될 것이라는 공포입니다.
이 모든 것은 현장에서 몇 년 동안 VBA와 씨름해 온 사람이라면 '맞는 말이다'라고 깊이 고개를 끄덕일 만한 현실적인 고민들뿐이었습니다.
오랫동안 오피스의 구석에서 외롭게 매크로를 써온 저 자신도, 완전히 똑같은 벽에 부딪혀 왔기 때문입니다.
하지만 화면을 바라보며 저는 문득 정신을 차렸습니다.
'잠깐만. 이 세 가지가 제 책상 위 컴퓨터에서는 어느새 전부 작동하고 있는 거 아닌가?'
영상에서는 'VBA의 세계는 Excel이나 Access 파일 내부에서 완결된다. 우리 안에서는 최강이지만, 우리 밖으로는 나갈 수 없다'고 이야기했습니다.
하지만 현장에서 고생하며 손으로 직접 해온 실감에 비추어 말씀드리자면, VBA는 결코 우리 안에 가두어져 있지 않습니다.
예를 들어, 제 책상 위에서는 **'GAS(Google Apps Script) 중계기'**가 일상적으로 작동하고 있습니다.
VBA의 표준 기능인 HTTP 통신(MSXML2.ServerXMLHTTP)을 사용해 Google 드라이브에 둔 간단한 GAS 웹 API로 JSON을 던집니다. 이 작은 파이프 하나만 연결하는 것만으로, Excel 시트와 Google Workspace(스프레드시트, Gmail, 드라이브 파일들)는 아무 문제 없이 실시간으로 양방향 연결됩니다.
게다가, 제가 직접 만든 개발 환경인 '秀コンボ'에서는 Excel의 UserForm에서 로컬 커맨드라인을 건드리며 최신 AI(Claude CLI나 Gemini)와 직접 파이프를 연결하고 있습니다.
화면 버튼을 누르면, 뒤에서 작동하는 AI에게 시트 구조가 전달되고, 단 몇 초 만에 결과가 돌아옵니다.
핵심 시스템의 데이터를 끌어오거나, 클라우드 서비스와 대화하거나, AI의 거대한 지능을 호출하는 것 모두, VBA 손끝에서 외부를 향해 '파이프'를 하나 뻗어주는 것으로 충분합니다.
외부로 나갈 수 있는 것이 아니라, 외부와 연결하기 위한 작은 중계기를 어떻게 구성하느냐의 문제였던 것입니다.
댓글란에서 가장 깊은 공감을 얻었던 것은, 'AI와 VBA는 궁합이 안 좋다. 실행 환경이 오피스 앱이라서, 작성된 후 디버깅을 AI가 셀프로 할 수 없는 게 힘들다'는 지적이었습니다.
이 의견은 현재 일반적인 AI 사용 방식, 즉 브라우저의 채팅창에 'VBA를 작성해 줘'라고 요청하고 출력된 코드를 사람이 Alt+F11로 VBE(Visual Basic Editor)를 열어 붙여넣는 운영 방식을 유지하는 한, 100% 정확한 지적입니다.
사람이 AI와 Excel 사이를 오가는 '복사-붙여넣기 파이프' 상태에서는, AI가 자신이 작성한 코드가 작동했는지, 아니면 문법 오류로 멈췄는지를 알 방법이 없습니다.
하지만 그것은 'AI와 VBA의 궁합이 나쁘다'는 문제가 아닙니다.
AI 스스로에게 Excel 실행 환경을 직접 만지게 할 도구(인터페이스)를 제공하지 않았기 때문입니다.
제 손에는 Python으로 자체 제작한 MCP 서버 **'Excel Manager (vba_manager.py)'**가 그 역할을 담당하고 있습니다.
이 도구의 정체는 Windows의 **COM (Component Object Model)**을 통해, AI가 외부에서 Excel 프로세스 자체를 직접 장악하는 메커니즘입니다.
AI가 COM을 직접 조작할 수 있기 때문에, 제 환경에서는 다음 사항들이 '인간의 손길을 전혀 거치지 않고' 자동으로 돌아갑니다.
get으로 프로시저를 읽어내고, patch-procedure로 수정된 줄만 직접 되돌립니다. - 전체 컴파일 자율 실행: VBE의 '디버그 > VBAProject 컴파일'(CommandBars Id 578)을 AI 스스로 외부에서 눌러 구문 오류나 미정의 변수를 감지합니다. - 테스트 일괄 실행: 테스트용 Sub 프로시저(test_*)를 자동으로 실행하고, 반환값이나 에러 코드를 AI가 직접 받습니다. - 에러 라인 지목 및 수정: 컴파일이나 테스트가 실패할 경우, 에러 메시지와 해당 행 번호를 AI가 스스로 읽어내고, '여기가 잘못되었다'라고 자율적으로 고친 후 다시 테스트를 실행합니다.이전 글에서 쓴 사건이 바로 그 살아있는 증거였습니다.
Claude가 심어놓은 취약한 하드코딩 코드로 인해 통신이 멈췄을 때, 로그를 조사하고 VBE의 코드를 읽고, InStr 함수로 재작성하여 관문 테스트 67개를 전원 합격시키고, GitHub의 pytest 760개까지 통과시켜 완료한 것은 파트너인 Gemini였습니다. 저 자신은 코드를 한 줄도 수정하지 않았습니다.
'AI는 Excel을 셀프 디버그할 수 없다'는 것이 아닙니다.
직접 COM을 건드릴 도구를 준비해 주기만 한다면, AI는 컴파일부터 테스트, 에러 복구까지 완벽하게 셀프로 완료할 수 있습니다.
'업무와 코드가 밀접하게 결합되어 있어, AI에게 리팩토링을 시키면 새로운 카오스(버그)가 생긴다'는 지적 역시 현장의 절실한 체감입니다.
AI에게 '이 매크로를 깔끔하게 해줘'라고 던져주면, AI는 좋은 의도로 변수명을 멋대로 바꾸거나 작동하던 기존 로직을 통째로 잘라내어 오히려 작동하지 않게 만드는 경우가 잦습니다.
이 카오스를 막기 위해, 제 손에는 **'이중의 방벽'**을 설치하고 있습니다.
프로시저 전체를 통째로 다시 쓰도록 하는 것을 원칙적으로 금지합니다.
AI에게는 '수정해야 할 줄의 변경 전'과 '변경 후'만 지정하게 하고, 단 0.09초 만에 핀포인트로 해당 줄만 교체하는 전용 명령어(patch-procedure)를 사용하게 합니다. 이는 주변의 무관한 코드나, 과거 장인이 남긴 절묘한 로직을 AI가 마음대로 건드릴 여지를 물리적으로 박탈하기 위함입니다.
코드를 수정한 후에는 본래 북(book)에 직접 손대지 않고, 메모리 상에서 복사본을 열어 '전체 컴파일'과 '테스트 Sub'를 일괄로 돌리는 **'관문(gate)'**이라는 시스템을 거칩니다.
테스트가 한 개라도 떨어지거나, 컴파일이 통과되지 않으면 수정은 즉시 폐기됩니다. 합격 도장(PASS)이 찍힌 것만이 비로소 본체에 반영됩니다.
더 나아가, 매크로를 건드리기 직전에는 반드시 자동 백업을 취하고, 버튼 하나로 원래 상태로 되돌릴 수 있는 경로(restore)도 마련해 두었습니다.
'AI가 코드를 망친다'는 것은 AI의 능력 문제라기보다는, AI에게 코드를 만지게 할 때의 안전 관리(하네스와 게이트) 설계 문제였던 것입니다.
댓글란에는 '현장의 매크로는 사양서도 없는 잡동사니 조합투성이다. 사양서 작성이나 VBA 그대로 리팩토링할 수요는 있을 텐데'라는 의견도 있었습니다.
이 문제에 대해서도, 제 손의 도구에는 처음부터 해답이 내장되어 있습니다.
docs (사용 설명서 자동 생성)전체 북(book)의 구성, 시트별 역할, 포함된 매크로 목록과 개요를 한 번의 명령어로 Markdown 형식의 사양서(_last_docs.md)로 작성합니다. - flow
(매크로 흐름도 / Mermaid)
해독 불가능한 스파게티 코드(spaghetti code)를 분석하여, 조건 분기나 루프 구조를 Mermaid 차트의 흐름도로 자동 생성합니다. 코드를 읽지 않아도 처리 흐름이 한눈에 도식화됩니다. - checkup
(건강진단 / 의무 기록)
손상된 참조 설정(MISSING)이나, 존재하지 않는 매크로를 호출하는 미해결 호출(unresolved call), 너무 긴 프로시저 등을 자동으로 감지하고, 수리 이력을 의무 기록으로 축적합니다. - 서랍의 절차서(手順書)를 조립하는 메커니즘
매크로 상단에 몇 줄의 주석(요청 내용/처리 대상/목표)만 남겨두면, 화면을 열 때마다 VBA 자체가 일본어 절차서(언제 사용되는지/목표/절차)를 자동으로 조립합니다.
누군가 작성한 매크로가 블랙박스화되는 이유는 '사양서를 다른 곳에 수동으로 쓰기' 때문입니다.
매크로 자체에 사양을 담아 AI가 언제든 그것을 읽고 해설해 줄 수 있는 환경을 만든다면, '전문화(属人化)'라는 문제가 구조적으로 성립할 수 없게 됩니다.
여기서 영상에서 언급했던 'VBA는 구조적인 우리 안에 갇혀 있어 외부 세계로 나갈 수 없다'는 명제로 돌아갑니다.
저는 이 판단이 사실은 완전히 반대 아닌가라고 생각합니다.
'VBA는, 우리 밖으로 너무 쉽게 나가버릴 수 있기 때문에 Microsoft가 Copilot에 VBA의 직접 편집을 할 수 없게 막아둔 것이 아닐까?'
세간에서는 'Microsoft가 VBA를 버리려고 하기 때문에', '오래된 기술이라서'라고 해석하는 경향이 있습니다.
하지만 아키텍처 관점에서 보면 이유는 훨씬 명확합니다.
VBA는 Office 안에 갇혀 있는 정도가 아닙니다.
WScript.Shell즉, 사용자의 손안 Windows 머신에 극도로 강력한 로컬 권한을 가지고 있습니다.
만약 클라우드 위에서 작동하는 Microsoft Copilot이 사용자의 로컬 환경에 있는 VBA를 직접 생성하고, 직접 컴파일하여 실행할 수 있는 권한을 갖게 된다면 어떻게 될까요?
AI의 사소한 오인이나 프롬프트 인젝션(prompt injection)으로 인해 로컬 PC의 파일이 수정되거나, 외부의 위험한 스크립트가 호출될 위험을 클라우드 서비스로서 보장하는 것은 극히 어렵습니다.
그렇기 때문에 Microsoft는 사용자의 손안 머신에 일절 부작용을 미치지 않는, '클라우드상의 안전한 새장(鳥籠)'으로서 Python in Excel를 제공할 수밖에 없었던 것이 아닐까 합니다.
VBA는 외부로 나가지 못하는 약한 언어가 아닙니다.
로컬의 모든 권한을 쥐고 너무 쉽게 외부로 나가버릴 수 있는 강력한 칼날이기 때문에, 본가 클라우드 AI조차도 고삐를 잡는 것을 주저하고 있는 것입니다.
그리고 로컬 환경에서 직접 안전망(MCP 서버와 관문 테스트)을 구축한 개인 개발자이기에, 그 강력한 칼날을 AI에게 직접 맡길 수 있게 된—이것이 제 손안에서 보이는 현실적인 풍경입니다.
외부 세계와도 연결되고, AI가 직접 COM 객체를 건드리게 하여 셀프 디버깅을 돌릴 수 있고, 사양서까지 자동으로 조립될 수 있게 되었습니다.
세간의 해설 영상이나 댓글란에서 '불가능하다', '무리가 된다'고 논쟁되는 벽은, 매일 밤 집 컴퓨터에서 끈질기게 공들여 온 결과, 어느새 제 손안에서 작동하게 된 것이었습니다.
그렇다면, 이제 제 도구는 완성된 것일까요?
솔직히 말하자면, 지금 저는 멈춰 서 있습니다.
'꽤 잘 되었다'라는 느낌은 있지만, 오랫동안 VBA를 써온 저의 피부 감각이 마음 한구석에서 **'아직 무언가 부족하다'**라고 속삭이고 있는 것입니다.
최근 AI의 발전을 보면, 국제 수학 올림피아드급 난제를 풀었다는 놀라운 뉴스가 쏟아져 나옵니다. 세계 최전선에서 AI의 지능은 전례 없는 높은 곳으로 치솟고 있습니다.
그 엄청난 지능을 바라보고 있노라니, 절실하게 생각하게 됩니다.
'수학 난제조차 풀 수 있는 지능이 있다면, 엑셀 매크로 세계도 훨씬 더 이질적인 차원의 고품질의 상상할 수 없는 무언가를 할 수 있지 않을까?'
지금 손안에서 작동하는 '지정된 수식을 넣기', '표를 액티브 디자인으로 정리하기', '피벗 만들기'와 같은 작업들은, AI가 가진 엄청난 잠재력에 비추어 볼 때, 아직 아주 작은 몇 퍼센트의 입구에 불과하지 않을까요?
AI의 능력이 부족해서는 아닙니다.
그 거대한 지능을 현장의 실무라는 장소에서 100% 해방시키기 위한 '틀(시스템)'이, 아직 제 손안에서 따라잡지 못하고 있는 것입니다.
지난번 Gemini와 심야에 대화하면서 하나의 종착점을 보게 되었습니다.
정리된 선반 부품을 골라 배열하는 것만으로 업무 레시피가 구성되고, 부족한 부품은 AI가 백그라운드에서 자동 테스트를 돌려 선반에 추가해 주는 **'선반 빌더(Tana Builder)'**라는 완성형 구상입니다.
하지만 저는 거기서 멈췄습니다.
표면의 UI(빌더)를 만들기 전에, 해결해야 할 '뒷단 시스템 설계 숙제'가 아직 눈앞에 산더미처럼 쌓여 있기 때문입니다.
어떤 표가 와도 망가지지 않는 선반 매크로 인터페이스, 여러 개의 선반을 안전하게 바통 터치시키는 연쇄 메커니즘, 실패했을 때 순식간에 되돌릴 수 있는 세이프티넷(safety net).
세상이 논하는 '불가능하다'는 벽을 넘어선 그 너머에서, 저는 지금 이 '다음 벽' 앞에서 팔짱을 끼고 있습니다.
본고에서 다룰 '객관적인 사실'과 저 자신의 '견해(주관)'를 정리하겠습니다.
YouTube 영상 및 댓글 반응: 어제 공개된 영상 『VBA만 가능한 엔지니어는 존재하는가』에 대해 현장 기술자나 사무직 직원들로부터 수많은 절실한 댓글이 쏟아지고 있습니다. -
손안 구현 및 테스트 실적: 직접 만든 Excel 매니저(MCP 서버)를 통해 AI가 COM을 직접 조작하여 전체 컴파일(Id 578) 및 테스트 Sub를 실행하는 셀프 디버그 환경이 실제로 존재하며, 관문 테스트 67개, pytest 760개를 통과했습니다. -
외부 연동 및 시각화 구현: GAS 중계기를 통한 Google Workspace 연동, patch-procedure (핀포인트 행 치환), docs (설명서 생성), flow (Mermaid 흐름도)가 손안 환경에서 구동되고 있습니다.
VBA의 자유도에 대한 해석: VBA는 '우리 밖으로 나갈 수 없다'기보다는, Win32 API나 파일 조작 등 '너무 바깥으로 나갈 수 있는 강력한 권한'을 가지고 있기 때문에, 클라우드의 Copilot이 직접 편집하는 것을 피할 수밖에 없다는 고찰. -
'아직 부족하다'는 이질감: 현재의 매크로 실행이나 선반 작업은 실용적인 단계에 있지만, 프론티어 AI의 지능에서 보면 아직 그 잠재 능력의 극히 일부만을 끌어내고 있다는 직관.
본고에서 언급한 툴들의 동작 조건과 현재의 한계점도 솔직하게 명시하겠습니다.
동작 환경: Windows상의 데스크톱 버전 Excel(Microsoft 365 권장)과 Python(pywin32) 환경이 필요합니다. -
설정 요건: 외부에서 VBE를 조작하기 위해, Excel의 'VBA 프로젝트 개체 모델에 대한 액세스를 신뢰' 활성화가 필수입니다. -
공개 현황: 핵심 MCP 서버 vba_manager.py는 GitHub(shu-excel-manager)에서 공개하고 있지만, UI를 포함한 애드인(秀コンボ)이나 AI 연동 메커니즘은 현재도 자택 환경에서의 개인 검증 및 개수 작업을 계속하는 단계입니다. -
안전성의 한계: 파괴적이지 않은 하네스나 백업 메커니즘을 갖추고 있지만, 외부 파일에 대한 직접 쓰기나 통신 등, 북(book) 밖의 영역에 영향을 미치는 매크로의 자동 실행은 완벽하게 차단할 수 없습니다.
어제 영상 댓글란에 적혀 있던 한 분의 말이 아직도 깊이 마음에 남아 있습니다.
'바다 건너편을 동경하는 사람처럼, 오늘도 VBA를 쓰면서 '외부 세계는 지금 어떻게 되어가고 있을까' 생각합니다.'
마음대로 환경 구축도 허락되지 않고, 새로운 툴 도입도 불가능한 사무실 구석에서, 그래도 매일의 업무를 조금이라도 앞으로 나아가게 하기 위해, 외롭게 VBA 키보드를 계속 두드리고 있는 사람들이 있습니다.
세상은 'VBA 따위는 시대에 뒤떨어졌다', '개인 의존성의 극치다', '엔지니어라고 부르지 않는다'고 쉽게 치부합니다.
하지만 그 제약투성이의 환경 속에서, 현장의 사람이 끈질기게 공들여 온 덕분에, 일본 업무의 심장부는 오늘도 멈추지 않고 돌아가고 있는 것입니다.
그리고, 최신 AI라는 지능과 COM을 직접 다루는 도구를 얻게 되자, 그 '버려졌다고 여겨졌던 언어'는 세상의 엔지니어들이 상상조차 못 할 만큼 강력한 팔다리로 다시 태어났습니다.
저는 아직도 앞으로 보일 '선반 빌더(棚ビルダー)'의 완성 포기를 생각하지 않습니다.
전국의 오피스 구석에서 오늘도 조용히 VBA와 마주하고 있는 동료들의 목소리에 힘을 얻으면서, 저는 오늘 밤도 집 컴퓨터로 이 다음 벽 너머를 목표 삼아 설계도를 다시 그리고 있습니다.