지난번(번외편)에는 1988년, 쇼와 쉘 석유 히로시마 지점 시절의 이야기를 썼습니다. Lotus 1-2-3에서 메뉴를 통해 매크로를 호출하여 집계 속도를 12배 높였던 그 이야기입니다. 그 기사의 말미에 다음과 같이 적었습니다.

그런 의미에서, 나의 秀.xlsm이 왜 굳이 「즉시 분리할 수 있는」 설계로 되어 있는지 ── 그 답은 여기에 연결되어 있습니다.

이번에는 그 답에 대한 이야기입니다. 왜 秀.xlsm은 애드인 (Add-in)으로서 「즉시 분리할 수 있는」 설계인가, 왜 매크로를 구출하는 「매크로의 파일더 온/파일더 오프 (Pileder On/Pileder Off)」라는 마징가 Z 같은 이름의 매크로가 들어있는가.

그리고 그 이야기를 Claude Code (내가 평소 사용하고 있는 AI 코딩 어시스턴트)와 함께 파고들어 보았더니, 내가 30년 전에 Lotus 1-2-3에서 익혔던 구조와 전 세계의 Excel MVP들이 걸어온 경로, 그리고 AI와 대화하며 깨달은 계승의 연쇄가 모두 하나로 연결되었습니다.

연재 「Excel VBA × Claude Code」는 지금까지 「대화하는 것만으로 매크로가 고쳐진다/폼 (Form)을 만들 수 있다/애드인을 만들 수 있다」라는, AI로 할 수 있는 이야기를 써왔습니다. 이번 주인공은 AI로 볼 수 있는 미래에 대한 이야기입니다. 나 자신도 깨닫지 못했던 나의 계보를 AI가 발굴해 주었다는 이야기가 될 것입니다.

내용이 조금 길어집니다. 아마 이 한 편으로 Excel 편은 일단 마무리할 생각입니다.

Microsoft의 업데이트로 인해 일본어 매크로가 망가지는 경험을 나는 두 번 했습니다.

첫 번째는 2017년 9월입니다. Office 2016의 버전 1708 (빌드 16.0.8431.2079)이라는 업데이트가 내려왔습니다. **일반적인 기능 업데이트 (Feature Update)**였습니다. 보안 업데이트가 아니었습니다. 그런데 이것이 적용되면, 모듈 이름이나 폼 이름의 끝부분이 일본어일 경우 VBA 파일을 여는 순간 다음과 같이 표시됩니다.

이 통합 문서 내의 Visual Basic for Applications (VBA) 매크로는 손상되었으며 삭제되었습니다.

그대로 덮어쓰기 저장을 하면 VBAProject가 사라집니다. 복구할 수 없습니다. 「폼1」(끝이 반각 숫자)은 안전하지만, 「폼壱」(끝이 일본어 숫자)은 아웃입니다. 끝의 한 글자로 운명이 결정되는, 꽤 알아차리기 어려운 발병 조건이었습니다.

일본어 이름을 가진 모듈을 대량으로 가지고 있던 나의 PERSONAL.XLSB는 Excel을 실행하는 순간 발병했습니다. VBA를 포함한 모든 Office 앱에서 발생하는 버그였던 것 같습니다.

처음에 이를 깨닫고 공개 기사로 올린 분은 아마 Qiita의 @Q11Q 님과 야마이치 료 씨의 블로그였던 것 같습니다. 2017년 9월 말, 거의 비슷한 시기에 「[Office2016 심각한 에러] VBA의 모듈 이름이 일본어이면 VBA가 파괴된다」라는 제목으로 경종을 울리고 있었습니다.

Microsoft 공식의 잠정 대응은 두 가지였습니다. 「이전 버전(1707)으로 되돌리기」와 「자동 업데이트 중지하기」. 후자는 Microsoft 스스로가 「망가지는 업데이트가 다시 배포될 가능성이 있으니 자동 업데이트를 꺼달라」고 안내한 것이었습니다. 일반적인 기능 업데이트로 인해 VBA 환경이 광범위하게 파괴되었다는 사실만이 남았습니다.

두 번째는 2020년 4월입니다. 이번에는 보안 업데이트였습니다.

CVE-2020-0760, Microsoft Office의 원격 코드 실행 취약성에 대한 대책 업데이트였습니다. VBA에서 외부 라이브러리를 참조할 때의 체크를 엄격하게 만든 것이라고 합니다.

그 부작용으로, 참조하는 DLL 이름이나 Excel 파일명·경로에 일본어(DBCS) 문자가 포함되어 있으면 일괄적으로 차단되게 되었습니다 (UNC 공유 경로도 포함).

그리고 다시 똑같은 「매크로는 손상되었으며 삭제되었습니다」라는 문구가 나오기 시작했습니다. 사고 ①과 같은 대사입니다. 사고 ①의 상처가 거의 아물었을 2년 반 뒤의 재림이었습니다. 수정 과정에서도 재배포 트러블이 있어 불안정한 상태가 1개월 이상 지속되었습니다.

복구 과정에서 막혔던 것은 %APPDATA%\Microsoft\Excel\XLSTART 폴더의 잔해였습니다. PERSONAL.XLSB를 지우고 애드인을 지워도, XLSTART 폴더에 깨진 바로가기나 잔해 파일이 남아 있으면 Excel 실행 시 재현됩니다. 원인 파악에 2시간 정도 걸렸습니다. 그때의 2시간은 돌이켜보면 은근히 괴로웠던 기억이 있습니다.

제 몸이 체감하는 「두 번의 파괴」는 이 두 건입니다. 두 건 모두 파일을 여는 순간 「매크로가 손상되어 삭제되었습니다」라는 동일한 메시지가 나왔기에 서로 직결되어 있습니다 (그 외에도 자잘한 유사 사건은 있지만, 특정 환경에 한정된 것이라 카운트에는 포함하지 않았습니다).

그리고 두 사고의 성질은 대조적입니다. 사고 ①은 일반적인 기능 업데이트에 의한 리그레션 (Regression), 사고 ②는 보안 업데이트의 부작용입니다. 즉, 「일본어 매크로를 사용하고 있으면, 기능 업데이트든 보안 업데이트든 파괴된다」는 뜻이 됩니다. 어디에 지뢰가 있는지 예측하기 어렵다는 것입니다.

사고 자체를 과장해서 말할 생각은 없습니다. 무지해서 사고를 당했을 뿐이고, 덕분에 지식은 늘었습니다. Microsoft가 잘못했다고도 생각하지 않습니다 (DBCS 환경의 포괄적인 테스트가 어렵다는 점은 상상이 가니까요). 다만, 구조적으로는 위험하다고 생각했습니다. 그래서 자위책을 강구하기로 했습니다.

사고 ② 이후, PERSONAL.XLSB를 버렸습니다. 애드인 (Add-in) 형식으로 전환했습니다. 「잘 깨지지 않아서」가 아닙니다. 「이상한 정보가 들어오면 즉시 분리할 수 있기」 때문입니다. 내용물을 읽을 수 없게 만드는 메커니즘은, 깨졌을 때 자신을 구할 수 없으니까요.

그리고 자동 업데이트를 껐습니다. 사고 ① 당시 Microsoft의 공식 잠정 대응이 그것이었기에, 보안 업데이트만 적용하고 기능 업데이트는 수동으로 하는 규칙을 그대로 유지하고 있습니다. 이것은 결과적으로 효과가 있었습니다. 2021년 10월의 사건도, 2022년 8월의 사건도, 2023년 4월의 전각 경로 매크로 차단 사건도, 제 환경에는 영향을 주지 않고 지나갈 수 있었습니다.

그때, PERSONAL.XLSB에서 애드인으로 자산을 옮기기 위해 수행했던 작업이, 나중에 「매크로의 파일더 온 / 파일더 오프 (Pileder On / Pileder Off)」라고 부르게 될 절차입니다.

파일더 온 (Pileder On). 마징가 Z입니다. 카부토 코우지의 호버 파일더가 마징가 Z의 머리 부분에 도킹하는, 바로 그 구호입니다.

매크로의 파일더 오프 (Pileder Off) — 북 내의 모든 모듈 (표준 모듈 / 클래스 / 사용자 폼)을 데스크톱의 날짜가 붙은 폴더 「{파일명} YYYYMMDD」로 일괄 퇴피합니다 -
매크로의 파일더 온 (Pileder On) — 폴더를 선택하여 그 안의 .bas, .cls, .frm을 다른 북에 전부 재도킹합니다

퇴피할 때는 「매크로를 마징가 Z의 머리에서 이탈시킨다」는 이미지로 「파일더 오프」. 새로운 북 (클린한 애드인 본체)에 조립할 때는 「파일더 온!」. 피격 직후라 예민했을 무렵에 떠올린 명명법인데, 지금도 그대로 사용하고 있습니다.

실제 코드 (秀.xlsm의 shu003 모듈에 수록)의 핵심은 대략 이렇습니다.

Sub 매크로의 파일더 오프()
Application.ScreenUpdating = False
Dim wBookA As Workbook, wCompo, wComponents
...

요컨대 VBA의 VBComponents 컬렉션을 훑으며 .Export를 호출하고 있을 뿐입니다. 「퍼스널 매크로 북이 대상인지, 액티브 북이 대상인지」를 처음에 MsgBox로 물어보는 UI가, PERSONAL.XLSB를 운용하던 시절의 흔적으로 지금도 남아 있습니다.

이 코드는 제가 발명한 것이 아닙니다. 원천이 있습니다.

사고 ② 직후, 이것을 하나씩 수작업으로 쓰기에는 감당할 수 없는 볼륨이었습니다. 뭐라도 없을까 하여 인터넷을 뒤졌습니다. 찾아낸 것은 「VBA Beginner」라는 사이트의 글 2편이었습니다.

• 「표준 모듈 등의 일괄 익스포트 (Export)」 (2017년 7월 13일 공개)
• 「표준 모듈 등의 일괄 임포트 (Import)」 (2018년 2월 28일 공개)

이것이 파일더 온 / 오프의 원천입니다.

시계열을 보십시오. 익스포트 글의 공개는 사고 ①의 2개월 전. 임포트 글은 사고 ①의 5개월 후. 즉, 사고 ①부터 사고 ② 사이에는 익스포트 글만 있었고, 임포트는 공개되지 않았었다는 뜻이 됩니다.

사고 ①로 피격된 직후의 저는, VBA Beginner의 익스포트 글만을 사용하여 퇴피할 수 있었습니다. 하지만 복구하는 쪽은 수동으로 할 수밖에 없었습니다. 5개월 정도, 모듈을 하나씩 VBE에 다시 붙여넣는 작업을 했던 기억이 있습니다. 일본어 파일명의 .bas를 VBE의 임포트 메뉴에서 하나씩 골라 나갑니다. 그 작업을 떠올리면 지금도 조금 진저리가 납니다.

2018년 2월에 임포트(Import) 관련 기사가 공개되면서, 마침내 페어로 자동화할 수 있게 되었습니다. 그리고 사고 ②(2020년 4월) 당시에는 이미 저도 양쪽 모두를 가지고 있었기에, 애드인(Add-in)으로의 이전에 활용할 수 있었습니다.

VBA Beginner의 코드에 제가 직접 추가한 커스텀(Customization)은 세 가지입니다.

• 데스크톱에 「{파일명} YYYDDMMDD」 날짜가 붙은 폴더를 자동 생성 (원문 기사는 통합 문서와 동일한 폴더)
• MsgBox로 「활성 통합 문서 대상인지, 개인용 매크로 통합 문서 대상인지」를 매번 선택하게 함 (PERSONAL.XLSB 운용의 흔적)
• 임포트(Import) 측에 FileDialog로 폴더 피커(Folder Picker)를 추가 (원문 기사는 문자열 직접 입력)

그리고 이름을 「매크로의 파일더 온(Pilder On) / 파일더 오프(Pilder Off)」라고 지었습니다. 마징가 Z 세대의 구조 장치 의식이라는 울림이, 두 번의 사고 직후의 심경에 딱 들어맞았던 것 같습니다.

여기까지가 스스로 기억하고 있던 범위의 이야기입니다.

여기서 끝났다면 이 글을 쓰지 않았을 것입니다. 저는 한 걸음 더 나아가 Claude Code에게 이런 질문을 던져보았습니다.

"파일더 온/오프 코드를 VBA Beginner에서 가져왔다고 기억하는데, 혹시 다른 사이트에도 비슷한 코드를 작성한 곳이 있어?"

가벼운 마음이었습니다. 연재 본편에서 「매크로의 파일더 온/오프」를 다루려던 참이라, 만약을 위해 유사 사례를 확인하고 싶었을 뿐입니다. AI는 차례차례 후보를 제시했습니다.

• Office TANAKA(officetanaka.net)의 「tips112 임포트와 엑스포트(Import and Export)"
• calmdays.net의 「VBA 모듈을 엑스포트(Export)하기"
• Qiita @istoyo 「Excel VBA 모듈을 일괄 저장하는 VBA 코드"
• vba-assets.net 「모든 VBA 모듈을 일괄적으로 입출력하기"
• C# ATIA라는 블로그의 「프로젝트 내의 모듈류를 모두 엑스포트하기"

그 후 VBA Beginner 사이트 자체를 조사해 보니, 운영자는 평범한 시스템 엔지니어의 개인 블로그였습니다. Microsoft MVP가 아니었습니다. 사이트에는 "선배가 순식간에 끝나는 매크로를 보여준 충격이 시작이었다"라고 적혀 있었습니다. 사이트의 모든 코드를 직접 작성하고 테스트했다고 명시되어 있기도 했습니다. 훌륭한 개인 블로그입니다.

다만, 여기서부터 재미있어집니다. 「VBComponents를 사용하여 모든 모듈을 일괄 Export/Import 한다」는 기술 자체는, 그보다 수년 전부터 전 세계의 Excel MVP들이 해설해 왔던 것이라고 합니다. VBA Beginner는 그것을 일본어 초보자용으로 재패키징(Re-package)한 것이었던 모양입니다.

AI에게 "조금 더 깊이 파고들어 줘", "더 이전에도 있지 않을까", "2010년부터 찾아봐"라고 요청하자, 기술적 계보가 차례차례 보이기 시작했습니다.

Excel MVP (Most Valuable Professional)란 Microsoft가 공식적으로 매년 표창하는 「커뮤니티 공헌도가 뛰어난 기술자」 제도입니다. 1993년에 발족되었으며, Excel 카테고리는 전 세계적으로 수십 명 수준입니다. 1년 단위의 재심사제로 운영되며, 공헌이 지속되지 않으면 자격이 박탈됩니다. 즉, Microsoft가 공식적으로 인정하는 세계 최고 수준의 Excel 전문가들이라는 뜻입니다.

파일더 온/오프의 원천을 추적해 보니, 그 끝에는 세 명의 MVP가 있었습니다.

cpearson.com이라는 사이트를 2000년대부터 운영해 온 미국의 거물입니다. VBE (Visual Basic Editor) 관련 해설에서는 권위자였습니다. 그의 사이트에는 「Multiple File Import And Export", "Exporting A VBComponent To A Text File", "Programming In The VBA Editor", "Code Modules And Code Names" 등 VBComponents를 다루는 대표적인 기사가 10개 이상 있습니다.

VBComponents를 처음 알게 된 전 세계의 많은 VBA 개발자들이 그의 사이트 중 어느 한 페이지는 거쳐 가지 않았을까 생각합니다. 영어권 VBA 세계의 기초 교과서 같은 존재였던 것 같습니다.

제가 파일더 온/오프(pile-on/off)를 만들었던 2017~2018년, Chip Pearson은 현역으로 업데이트를 계속하고 있었습니다. 사고 ②의 2년 전인 2018년에 사망했습니다. 사이트는 지금도 아카이브로 남아 있지만, TLS 인증서가 만료되어 현대의 브라우저에서는 경고가 뜹니다. 그의 유산은 더 이상 업데이트되지 않겠지만, 그가 10여 년에 걸쳐 작성한 VBComponents 해설군은 지금도 전 세계 VBA 개발자들의 지식의 밑바탕에 남아 있는 것 같습니다.

VBA Beginner의 페어 기사는 기술적으로 완전히 그의 계보에 있다고 느낍니다. 명시적인 참조 링크는 없지만, 코드 구조를 비교하면 연속성이 보입니다.

캘리포니아의 Excel 컨설턴트입니다. Atlas Programming Management(atlaspm.com)를 운영하고 계십니다. 2003년부터 20년 이상 Excel MVP를 유지해 온 베테랑으로, Microsoft가 인정하는 장기간의 현역 전문가입니다.

그의 2012년 3월 26일 기사 「Customizing Your RightClick Menu to List & Run Macros」의 코드가 구조적으로 저의 슈(秀).xlsm과 가장 유사했습니다.

For Each objComponent In ActiveWorkbook.VBProject.VBComponents
If objComponent.Type = 1 Then ' 표준 모듈
For intLine = 1 To objComponent.CodeModule.CountOfLines
...

VBComponents를 전수 조사하여, 코드 모듈의 텍스트를 한 줄씩 읽고, Sub로 시작하는 행을 찾아 매크로 이름을 추출한다. 그 리스트를 우클릭 메뉴에 펼치고, 선택하면 Application.Run으로 실행한다. **즉, 매크로 목록을 동적으로 가져와 메뉴화하는 런처(Launcher)**입니다.

제가 2017년 이후 슈(秀).xlsm에서 만들고 있는 「액티브 매크로 폼」( VBComponents를 순회하여 매크로 목록을 UserForm의 ListBox에 표시하고, 더블 클릭하면 Application.Run을 실행하는 구조)은, Tom Urtis가 2012년에 도달했던 아키텍처(Architecture)와 본질적으로 동일했습니다.

차이점은 두 가지뿐입니다.

• UI 형태: Tom Urtis는 우클릭 메뉴(CommandBar), 저는 UserForm + ListBox
• 배치: Tom Urtis는 일반 메뉴, 저는 슈(秀).xlsm을 "매일 보는 홈 화면"으로 상설

Tom Urtis는 기사 내에서 "I never use the Personal Macro Workbook(개인용 매크로 통합 문서(Personal Macro Workbook)는 사용하지 않는다)"라고 명시했습니다. 애드인(Add-in) 형식을 강력히 권장하고 있습니다. 사고 ② 이후에 제가 PERSONAL.XLSB를 버리고 애드인으로 옮긴 것은, 북미의 Excel MVP가 10년 전부터 제시했던 방향과 일치했던 것입니다. 알지 못하는 사이에 같은 곳을 향하고 있었던 셈입니다.

그리고 일본에도 MVP가 계셨습니다. 다나카 토오루(田中亨) 씨입니다. Office TANAKA(officetanaka.net)의 운영자로, 2004년에 일본인 최초로 Excel MVP를 수상하신 분입니다.

Office TANAKA의 「임포트와 엑스포트(Import and Export)」 페이지(tips112)가 일본어권에서 VBComponents의 Export/Import를 체계적으로 다룬 고전 중 하나라고 생각합니다. VBA Beginner의 페어 기사는 아마도 그 영향권 안에 있는 것이 아닐까요.

제가 무의식중에 Export/Import 코드를 사용하고 있었던 배경에는, 이러한 일본 중진들의 계보도 있었던 것입니다.

기술뿐만이 아니었다는 것을 깨달았습니다. 사상 또한 모르는 사이에 이어받고 있었다고 생각합니다.

계속 머릿속에 남아 있는 말이 있습니다. Office TANAKA의 다나카 토오루 씨가 어딘가에서 하셨던 한마디입니다.

"매크로는 작업에 사용한다."

"매크로를 사용해서 작업한다"와 같은 뜻이 아니냐고 처음에는 생각했습니다. 다릅니다.

「매크로를 사용하여 작업한다」 |
「매크로를 작업에 사용한다」 |
|---|---|
| 매크로는 완성된 도구, 호출하고 끝 | 매크로는 작업의 일부, 살아있음 |
| 한 번 작성하면 건드리지 않음 | 작업하면서 손을 넣음 |
| 매크로는 「제품」 | 매크로는 「작업 환경 그 자체」 |

매크로는 작업을 하면서 조금씩 수정하고, 다시 사용한다. 매크로가 살아있다는 뜻입니다.

세상에는 「매크로를 업무에 활용한다」와 같은 이야기가 자주 있습니다. 버튼을 누르면 처리가 실행된다. 편리합니다. 확실히 편리하지만, 그것은 「매크로를 사용하여 작업한다」 쪽입니다. 매크로가 완성된 형태의 고정 자산이 되어 있는 상태입니다. 제 안에 있던 지침은 그렇지 않았습니다. 매크로는 작업 환경의 일부, 즉 작업을 하면서 키워나가는 대상이라는 것이었습니다.

제 秀.xlsm의 설계는, 저도 모르는 사이에 전부 이것을 따르고 있었던 것 같습니다. 액티브 매크로 폼(Active Macro Form)을 상설 홈 화면으로 만든 것도, shu001에 매크로를 작성하면 즉시 메뉴에 반영되는 것도, 애드인(Add-in)화 + 자동 업데이트 해제도, 파일럿 온/오프(Pile-on/off)도, 전부 「매크로를 작업 환경으로서 키운다」는 사상에 부합했던 것입니다.

기술의 계보(Chip Pearson, Tom Urtis)와 사상의 흐름을, 저는 모르는 사이에 양쪽 모두 계승하고 있었습니다. AI에게 파헤치게 하기 전까지는 깨닫지 못했습니다.

더 놀라운 것은 이 부분입니다.

VBA에서 VBComponents를 전수 조사하여 메뉴를 동적으로 생성하는 아키텍처(Architecture)는, 사실 1988년 Lotus 1-2-3에서 익혔던 구조와 완전히 동일했습니다.

번외편에 썼듯이, 1988년 신입사원이었던 저는 쇼와 쉘 석유(Showa Shell Oil) 히로시마 지점에서 Lotus 1-2-3를 다루고 있었습니다. 그 시절 Lotus 1-2-3의 메뉴 구동 방식은 이런 느낌이었습니다.

Lotus 1-2-3에는 {MENUBRANCH}라는 매크로 명령어가 있었습니다 (구형 명령어로는 /XM). 이것은 「셀 범위를 지정하면, 해당 범위의 테이블을 훑어서 메뉴를 동적으로 구성한다」는 명령어입니다.

셀 위에 3행 × 최대 8열의 테이블을 작성합니다:

| 추출 | 집계 | 인쇄 | 저장 | 종료 |
| 매출 추출 | 월간 집계 | 인쇄 작업 | 파일 저장 | 1-2-3 종료 |
| {GOTO}A1~/dq | {GOTO}B1~/rnci~ | /pp{ESC}r... | /fs~r | /qy |

1행에는 메뉴 항목명, 2행에는 설명문(80자 이내, 화면 하단에 표시), 3행 이후에는 선택했을 때 실행할 매크로 명령어를 적습니다. {MENUBRANCH ABC123}을 호출하면, Lotus 1-2-3가 ABC123 셀 범위를 스캔하여 화면 하단에 텍스트 메뉴를 표시해 줍니다.

조작은 키보드뿐입니다. 슬래시(/) 키 + 첫 글자로 선택합니다. 「추출」을 선택하고 싶다면 /A라고 입력합니다 (또는 화살표 키로 선택 후 Enter). 당시 Lotus 1-2-3의 최대 특징은 이 키보드 전용의 고속 메뉴 조작이었다고 생각합니다. 마우스는 아직 보급되지 않았고, 필요하지도 않았습니다.

즉, 「데이터를 훑어서 메뉴를 동적 생성 → 선택으로 디스패치(Dispatch)」하는 아키텍처. 이것이 Lotus 1-2-3 메뉴 구동의 정체였습니다.

세 가지 모두 동일한 아키텍처입니다. 데이터 소스는 바뀌었습니다 (셀 → 코드). UI도 바뀌었습니다 (텍스트 → CommandBar → UserForm). 하지만 **사상은 완전히 동형(Isomorphic)**입니다. 「메뉴 항목을 하드코딩하지 않고, 소스에서 생성한다」는 생각은 아무것도 변하지 않았습니다.

1988년의 저는 Lotus 1-2-3의 메뉴가 가장 간단하고 이해하기 쉬웠다고 생각했습니다. 3행의 테이블을 작성하면 메뉴가 됩니다. 「변경이 필요해지면 테이블을 다시 쓰면」 그만입니다. 당시 동료들에게도 "뭐야 그거, 대단한데"라며 놀림을 받았던 기억이 있습니다. 당시 스프레드시트 시장에서 Lotus 1-2-3가 업계 패권을 잡은 것도, 바로 이 「메뉴 구동(Menu-driven) 방식의 사용 편의성」이 있었기 때문이 아닐까 생각합니다.

그 기억이 계속 머릿속에 있었습니다. 2017년에 Excel VBA로 런처(Launcher)를 만들었을 때, 저는 아무런 신발명도 하지 않았습니다. 30년 전에 익힌 구조를 다른 도구로 다시 작성했을 뿐이었습니다. 데이터 소스가 「셀(Cell)」에서 「VBComponents」로 바뀌었을 뿐, 사상은 동일했습니다.

그리고 같은 지점에 Tom Urtis도 독립적으로 도달해 있었던 것입니다. 기술은 보편적인 것이겠지요. 1988년 쇼와 셸(Showa Shell) 히로시마 지점에서 제가 체득한 아키텍처(Architecture)는 Lotus 1-2-3만의 것도, Excel VBA만의 것도 아니었습니다. **메뉴 구동이라는 보편적인 설계 패턴(Design Pattern)**이었다는 뜻이라고 생각합니다.

다만 저의 경우, 그 보편적인 아키텍처에 「30년 전부터 알고 있던 당연한 것」으로서 무의식중에 도달해 있었습니다. 1988년 쇼와 셸 석유 히로시마 지점에서 24살의 제가 메뉴로부터 매크로(Macro)를 호출하는 법을 배운 이후로, 계속 같은 구조를 품고 다녔던 것입니다. Excel VBA는 세 번째 그릇이었습니다 (Lotus 1-2-3 → Excel 4.0 매크로 → Excel VBA).

솔직히 쓰겠습니다. 여기까지 기술한 구조의 대부분은 Claude Code와 대화하며 파고들면서 비로소 보이기 시작한 것들입니다.

제가 해온 일은 「담담하게」 수행했을 뿐입니다. 사고가 났고, 대피와 복구 매크로를 작성했고, 애드인(Add-in)화 했고, 자동 업데이트를 껐고, 매일 사용하는 폼(Form)을 배치했을 뿐입니다. 「Lotus 1-2-3의 메뉴를 기억하던 시절의 감각이 배경에 있구나」 정도는 저 자신도 알고 있었습니다.

하지만,

• VBA Beginner의 운영자가 MVP가 아니라는 점
• 그 바탕에는 Chip Pearson과 다나카 토오루(Tanaka Toru) 씨라는 거물들의 유산이 있었다는 점
• Chip Pearson이 2018년에 사망했으며, 사이트의 TLS 인증서가 만료되었다는 점
• Tom Urtis가 2012년 우클릭 버전에서 동일한 구조에 독립적으로 도달했다는 점
• 「매크로는 작업에 사용한다」라는 말이 秀.xlsm 설계의 뿌리였다는 점
• Lotus 1-2-3의 {MENUBRANCH}와 VBComponents 순회(Traversal)가 완전히 동형(Isomorphic)이었다는 점

이 모든 것은 Claude Code와의 대화를 이어가는 과정에서 보였습니다.

처음에 던진 질문은 정말 아무것도 아닌 것이었습니다. "파일더 온/오프(Pile-on/off) 코드를 VBA Beginner에서 가져왔다고 기억하는데, 혹시 다른 비슷한 코드를 작성한 사이트가 있어?"가 전부였습니다.

AI가 후보를 제시했을 때, 처음에는 일반적인 검색 결과의 연장선으로 읽었습니다. Office TANAKA, calmdays, Qiita @istoyo. 하지만 궁금해져서 "이 VBA Beginner는 언제쯤 작성된 건지 알 수 있어?"라고 물어보니, 엑스포트(Export) 기사는 2017년 7월, 임포트(Import) 기사는 2018년 2월이라고 답이 돌아왔습니다. 사고 ①의 전후구나라고 깨달았습니다.

그때부터 몇 번이고 AI에게 방침을 던졌습니다.

• "
  더 이전 것이 있지 않을까, 2010년쯤부터 찾아봐"

→ 2017년 9월의 Office 2016 v1708 사건이 공적 기록상의 가장 오래된 것이라고 답변 - "
아니, 그건 다른 거야. 일본어가 관계되어 VBA가 망가지는 사건 말이야"

→ Qiita @Q11Q의 기사에 도달, v1708 (16.0.8431.2079)로 확정 - "
0102(사고 ①②)의 원인 같은 걸 조사할 수 있을까?"

→ CVE-2020-0760과 MS의 공식 블로그를 대조, 비교 축이 명확해짐 - "
해외에도 비슷한 일을 하는 사람이 있는지 조사해줘"

→ Tom Urtis의 2012년 기사에 도달, 코드를 행(Line) 단위로 대조 - "
Excel MVP라는 게 대단한 거야?"

→ 제도의 권위성, Chip Pearson, 다나카 토오루 씨의 존재로 전개 - "
내가 베꼈던 VBA Beginner, 혹시 MVP의 코드를 참고했던 게 아닐까?"

→ 운영자는 개인 엔지니어이지만, 그 배후에 Chip Pearson과 다나카 토오루(田中亨) 씨의 유산이 있다는 사실이 판명됨

이 일련의 대화 속에서, 내가 무의식중에 Excel MVP의 유산을 계승하고 있었다는 구조가 입체적으로 떠올랐습니다. AI가 일방적으로 답을 내놓은 것이 아닙니다. 내가 기억을 토대로 방향을 제시하면, AI가 문헌을 찾아오고, 내가 "아, 그거다" 혹은 "아니, 그게 아니다"라며 수정해 나가는, **내 기억과 공개 정보를 대조하는 프로세스 (照合プロセス)**였습니다.

연재 타이틀인 "Excel VBA × Claude Code", 지금까지의 기사에서는 "대화하는 것만으로 매크로가 고쳐진다 / 폼(Form)을 만들 수 있다 / 애드인(Add-in)을 만들 수 있다"와 같이 AI로 할 수 있는 실용적인 측면을 써왔습니다. 확실히 편리하며, 현대의 VBA 개발 생산성이 몇 배는 높아졌다는 감각이 있습니다.

하지만 이번에는 조금 달랐습니다. 이번에는 "대화하는 것만으로 나의 30년사와 세계의 Excel 거물들과의 무의식적인 계보가 보였다"였습니다. AI로 할 수 있는 것은 작업의 효율화뿐만이 아닌 것 같습니다. 내가 무의식중에 짊어지고 있는 유산을 나 자신에게 가르쳐 주는 것도 가능하더군요.

이것은 아마 나뿐만이 아닐 것이라는 생각이 듭니다. Lotus 1-2-3나 Multiplan, VisiCalc, 그리고 그 외 1980년대부터 스프레드시트 계열의 도구들을 다뤄온 사람들은 각자의 "그 시절의 도구"를 계속 간직하고 있을 것입니다. AI에게 심층적으로 파고들게(Deep dive) 한다면, 이와 유사한 발견이 나올 것 아닐까요. 당시의 감각은 지금의 도구와 맞닿아 있습니다. 의외로 그 뿌리는 변하지 않은 것 같습니다.

40년 전의 조작감, 20년 전의 지식, 10년 전의 사이트, 그 모든 것들이 연결되어 지금 내가 사용하고 있는 秀.xlsm 안에서 살아 숨 쉬고 있었습니다. 검색 엔진은 평면적인 탐색이지만, AI는 대화 속에서 나 자신의 기억을 끌어내 주는 손맛이 있었습니다.