시리즈 3번째 글입니다. 앞선 2편은 「Claude Code로 어떻게 만드는가」에 대한 이야기였습니다. 이번에는 주제를 바꾸어, 「만든 매크로를 어떻게 계속 사용할 것인가」, 즉 애드인(Add-in) 본체(秀.xlsm) 측의 구조에 관한 이야기를 쓰겠습니다.

그 전에, 약 40년 전의 작은 이야기를 하나 들려드리고 싶습니다.

제가 스프레드시트 소프트웨어인 Lotus 1-2-3를 사용하기 시작한 것은 쇼와 쉘 석유(일본의 계열사로, 지금은 이데미츠에 흡수되어 더 이상 존재하지 않는 회사입니다)의 히로시마 지점에서 근무하던 시절이었습니다. 회사의 컴퓨터는 후지츠(Fujitsu) 제품이었고, 처음에는 「메뉴에서 매크로를 호출하는」 기능은 없었던 것으로 기억합니다. 버전 업데이트를 통해 그 기능을 사용할 수 있게 되었습니다. 숫자 키를 눌러 선택하기만 하면 되는 소박한 메뉴였지만, 당시로서는 상당히 획기적이었습니다. 이것을 도입하자마자 업무가 단번에 편해졌습니다.

매크로를 쓰는 것만으로는 부족하고, 쓴 매크로를 메뉴에서 호출할 수 있는 것까지 세트로 되어야 비로소 도구가 된다——그 손맛을, 당시 그 순간에 잡았던 것이라고 지금에 와서 생각합니다.

그 후 도쿄 본사에서 근무할 무렵, 쉘 본사——당시 세계 2위의 석유 메이저(지금은 1위)—에서 파견되어 온 직원의 어시스턴트를 조금 맡았던 시기가 있었습니다. 주유소의 입지 조건을 Lotus 1-2-3에 상세히 입력하여 분석하는 업무로, 「1주일 정도면 해줬으면 좋겠다」는 부탁을 받았습니다.

저는 당연히 그 「메뉴에서 매크로 실행」을 사용하여 작업했습니다. 작업은 패턴화할 수 있었기에, 패턴별로 매크로를 작성하여 메뉴에서 호출할 수 있도록 만들어 빠르게 처리했습니다. 1주일이라고 들었던 업무가 하루 만에 끝났기에, 남은 시간 동안 무엇을 하면 좋을지 여쭈었습니다.

그러자 화면에 메뉴가 떠 있는 것을 본 본사 직원이, 얼굴을 새빨갛게 붉히며 화를 냈습니다. 「무슨 멋대로 행동하는 거냐, 지시한 것 외에는 하지 마라」라고 말이죠.

저는 서툰 영어로 설명했습니다. 이 작업은 대략 몇 가지 패턴으로 나뉜다. 패턴에 맞는 처리를 메뉴에서 선택하여 실행하고 있다. 백업은 해두었다. 이것은 어디까지나 작업용 파일이다라고 말입니다.

그러자 그때까지 화를 내던 그는 침묵하더니, 이어서 일본어로 「잘 알겠습니다, 당신 정말 우수하군요」라고 한마디만 해주었습니다.

나중에 이를 지켜보던 과장님으로부터 「본사의 쉘 직원에게 칭찬받았네」라며 놀림을 받아, 작은 웃음거리가 되기도 했습니다. 당시에는 쉘 본사에서 온 직원 = 초엘리트라는 취급을 받았기 때문입니다.

이것이 제가 「메뉴에서 매크로를 호출하는」 방식에 집착해 온 원체험입니다. 편리했기 때문이기도 하지만, 아마 그때 본사 직원에게 「우수하다」고 인정받았던 것이 꽤 큰 영향을 미치고 있는 것 같습니다. 「이 방식이 옳다」는 확신은 편리함의 실감뿐만 아니라, 그 한마디에 밑바탕을 두고 있습니다.

40년 정도 지나 AI가 오고, 소프트웨어가 Lotus에서 Excel로 바뀌어 매크로의 개수가 차원이 다르게 늘어나도, 하고 있는 일의 본질은 당시와 변하지 않았습니다. 이번에는 그 현대판 이야기를 쓰겠습니다.

계기는 제대로 곤란한 상황에 처했기 때문입니다. 40세를 넘겼을 무렵, 매크로를 대량으로 만들었더니, 직접 작성한 것을 스스로 찾을 수 없게 되었습니다.

그래서 응급처치로 모든 매크로 코드를 Excel 시트에 붙여넣어 「매크로 데이터베이스」를 만들었습니다. 그것을 필터로 검색함으로써 새로운 코드를 만들 때 참고하고 싶은 코드를 바로 찾을 수 있게 되어 편리해지기는 했습니다. 하지만 찾아내더라도 결국 복사해서 붙여넣기만 할 뿐 실행은 할 수 없었습니다. 검색만 가능한 무덤이었습니다.

이 기사는 그 상태에서 벗어나기 위해 秀.xlsm이 하고 있는 내용입니다. 전문 용어로 쓰자면 「리플렉션 (Reflection)으로 메뉴를 동적 생성하고 있다」가 되겠지만, 본질은 「Sub를 하나 추가하는 것만으로 메뉴에 나타난다」——그것뿐입니다.

오랫동안 신세를 지고 있는 Qiita에 올리는, 저 나름의 보답으로서의 3번째 글을 씁니다.

앞선 2편(매크로가 고쳐진다 / 폼을 만들 수 있다)은 어떻게 만드는가의 이야기였습니다. 이번에 쓰고 싶은 것은 **「만든 매크로를 어떻게 관리할 것인가」**입니다.

이것은 아마 그리 진지하게 고려되지 않는 테마라고 생각합니다. 「매크로를 쓰는 방법」, 「업무를 자동화하는 방법」에 관한 기사는 산더미처럼 많지만, 작성한 매크로를 어떻게 찾고 어떻게 호출할 것인가는 별로 다뤄지지 않습니다. 개수가 적을 때는 Alt+F8의 기본 메뉴로도 돌아가기 때문에 문제로 표면화되지 않기 때문입니다.

저의 경우에는 Lotus 1-2-3 시대부터 매크로 개수가 늘어날 때마다 나름의 관리 방법을 시도해 왔습니다. Excel로 넘어온 이후의 변천사를 요약하자면 다음과 같습니다.

• 매크로 데이터베이스 (Macro Database): 모든 매크로 코드를 Excel 시트에 붙여넣어 키워드 검색이 가능하게 함. 초기 단계부터 일본어 이름을 붙여 일본어로 검색했습니다. "일본어로 매크로를 관리한다"는 발상은 이 시점에 이미 제 안에 있었습니다. 하지만 이것은 VBE 본체와는 별개의 관리 장소입니다. 찾아내더라도 거기서 복사하여 VBA로 되돌리는 번거로움이 필요합니다. 실물과 관리 측이 분리되어 있다는 점이 계속 위화감으로 남아 있었습니다. 점차 "VBE 본체에서 직접 관리하게 하고 싶다"고 생각하게 되었고, 처음 만든 것이 **PERSONAL.XLSB의 매크로를 일람 표시하는 폼 (Form)**이었습니다. 일본어 이름으로 검색도 가능합니다. 이것이 현재의 秀.xlsm 리플렉션 엔진 (Reflection Engine)의 기원입니다.

그리고 AI가 등장하면서 매크로를 만드는 속도가 한 단계 올라갔습니다. 개수는 더욱 늘어날 것입니다. 관리의 문제는 이전보다 더 중요해지고 있습니다.

다만, 여기서 한 가지 강조하고 싶은 것이 있습니다. "매크로 관리"에는 두 가지 의미가 있으며, 이를 섞으면 이야기가 흐려집니다:

• 개발자 관점의 관리: 자신이 작성한 코드를 어떻게 찾고, 어떻게 수정할 것인가
• 사용자 관점의 관리: 만든 매크로를, 코드는 보고 싶지 않은 사무 현장의 사람들이 호출할 수 있는가

"매크로 관리"라고 하면 보통 1번의 이야기로 끝납니다. 하지만 정말 중요한 것은 2번입니다. 사용자에 대한 요구사항은 심플합니다. —— VBA를 보여주지 않을 것 · 쉽게 호출할 수 있을 것 · 일본어일 것. 이 부분을 놓치면 아무리 훌륭한 매크로를 작성해도 현장에서는 사용되지 않습니다. 개발자 선에서 완결되어 버리는, 자신만이 사용하는 매크로가 됩니다.

(이 세 가지 중, 특히 "일본어일 것"이 결정적으로 중요하다고 저는 생각합니다만, 그 이야기는 다음 기사에서 심도 있게 다루겠습니다. 이번에는 리플렉션 (Reflection) 메커니즘 자체에 집중하겠습니다.)

그리고 AI와 앞선 두 편의 글에서 만든 도구들 (vba_manager.py / form_builder.py) 덕분에, 이제부터 매크로는 얼마든지 만들 수 있는 시대가 되었습니다. 그렇기 때문에, 만들기 전에 "현장 사람들이 어떻게 호출할 것인가"를 먼저 생각해 두지 않으면, 양만 늘어나고 아무도 사용하지 않는 사고가 발생합니다.

중요한 것은, 현장 사람들이 얼마나 쉽고 알기 쉽게 호출할 수 있는가입니다.

秀.xlsm은 그 질문에 대한 저 나름의 답입니다. 양쪽의 관리를 한 장으로 해결하는 도구가 되어 있으며, 물론 더 간단한 방법도 있을지 모르지만, "간결함"이라는 한 점에 있어서는 아마 이것이 거의 정답이라고 생각합니다. 기술적으로는 소박합니다. 그렇기에 작성하여 내놓을 가치가 있다고 생각했습니다.

• "매크로 관리"에는 두 가지가 있다: 개발자 관점(코드를 어떻게 찾는가)과 사용자 관점(현장 사람이 어떻게 호출하는가). 정말로 중요한 것은 후자이며, 요구사항은 VBA를 보여주지 않을 것 · 쉽게 호출할 수 있을 것 · 일본어일 것
• AI로 인해 매크로는 만드는 것만이라면 얼마든지 만들 수 있는 시대가 되었다. 그렇기 때문에 먼저 "현장 사람이 어떻게 호출할 것인가"를 생각해 두지 않으면 양만 늘어나고 사용되지 않는다
• 해답은 "정렬하는 것"이 아니라 "정렬하는 것을 그만두는 것". 바라는 방향과 정답의 방향이 정반대였던 이야기
• 秀.xlsm은 VBA가 실행 시에 자기 자신의 소스 코드를 읽어서 메뉴를 생성한다. 등록표도 매니페스트 (Manifest)도 없다. Sub를 하나 추가하면 그대로 메뉴에 나열된다. 순서는 "소스에 쓴 순서" —— 자주 쓰는 것을 위에 "쓰면" 위에 나온다, 그뿐이다. 결과적으로 응급처치로 사용하던 "매크로 데이터베이스"는 사용하지 않게 되어 은퇴했습니다.

GitHub: https://github.com/shu1551/shu-vba-manager (秀.xlsm은 리포지토리 직하에 동봉)

앞선 두 편에서는 Claude Code로부터 VBA를 직접 다룰 수 있게 하는 도구들 (vba_manager.py / form_builder.py)을 만든 이야기를 썼습니다. 대화하는 것만으로 매크로가 고쳐지고 폼을 만들 수 있다. 이것은 개인적으로 혁명이었습니다.

하지만, 혁명에는 예외 없이 부작용 (Side Effect) 이 따릅니다. 만드는 속도가 빨라질수록, 개수도 늘어납니다. 정신을 차려보면 개발자인 저조차도 자신이 작성한 것을 찾을 수 없게 됩니다. 그리고 여기서부터가 이번 이야기의 시작입니다만——개발자가 찾지 못한다면, 현장의 이용자는 더 찾지 못합니다. "만든 매크로를 불러서 사용하게 한다"까지 설계하지 않으면, 단순히 늘리기만 하고 끝나게 됩니다.

여기서부터는 그 대책으로서 秀.xlsm 본체가 하고 있는 일에 대한 이야기입니다.

"처음"에서 언급했듯이, 개수가 늘어남에 따라 응급처치로 "매크로 데이터베이스"를 만들어 버텼습니다. 모든 매크로의 코드를 Excel 시트에 붙여넣고, 일본어 이름을 붙여 검색할 수 있게 함——이것으로 "찾는 것"은 일단 가능해졌습니다. 하지만 근본적인 불편함이 아직 두 가지 남아 있었습니다.

↑ 매크로 데이터베이스. 위: 모든 매크로의 코드를 붙여넣은 목록. 아래: 「Sub」로 필터링하여 237개의 매크로가 보이는 상태

VBA의 표준 매크로 실행 다이얼로그 (Alt+F8)는 등록된 매크로를 멋대로 오십음도 (Gojūon) 순으로 정렬하여 표시합니다. 작성한 순서도, 자주 사용하는 순서도 아닌, 그저 오십음도 순입니다.

이것이 왜 곤란하냐면, 위치에 의미가 담기지 않기 때문입니다. "어라, 분명히 만든 매크로가 있었는데..." 하고 찾아봐도, 표시 위치는 정렬에 의해 매번 변동됩니다. "늘 있던 자리에 없다"는 상태가 상시화됩니다. 결국 "어라, 없네" 하고 당황해서 자세히 보니 오십음도상으로 한 단계 밀려 있었을 뿐인 상황을 매번 겪게 됩니다.

보통의 대책은 매크로 이름에 번호를 매기는 것입니다 (01_집계실행, 02_장표출력 ...). 저도 그렇게 했습니다. 하지만 이것은 지속되지 않습니다. 중간에 하나를 넣고 싶을 때 번호를 다시 매겨야 하고, 관련 매크로가 분산되면 또 다시 번호를 매겨야 합니다. 유지보수 (Maintenance)가 본업보다 무거워집니다. 점점 번호를 매기지 않게 되고, 다시 오십음도 지옥으로 돌아갑니다.

또 다른 고통. 매크로를 작성하는 것만으로는 이용자가 사용할 수 없습니다. 호출하기 위한 배선 (Wiring) 이 필요합니다:

• 버튼 (Button): 시트에 도형이나 폼 컨트롤 (Form Control)을 배치하고 매크로를 등록
• 메뉴 (Menu): Quick Access Toolbar 나 Ribbon에 커스텀 추가
• 단축키 (Shortcut): Application.OnKey 나 VB_Invoke_Func 속성으로 할당

이것이 매크로를 추가할 때마다 발생합니다. 한 개라면 괜찮습니다. 100개가 되면, 배선 그 자체가 관리 대상이 됩니다. "그 매크로, 어디에 배선했더라", "이 버튼에 연결했던 매크로, 다른 걸로 바꿨던가"——배선이 부패합니다.

그리고 배선이 부패하면, 이용자는 사용할 수 없게 된 매크로를 "고장 났다"고 느낍니다. 실제로는 코드가 살아있고 단지 입구가 사라졌을 뿐인데 말입니다. 이것은 이용자의 신뢰를 단번에 깎아먹습니다. "이 매크로, 또 고장 났어"라는 말을 현장에서 들어본 경험이 있는 분이라면, 저와 같은 구덩이에 빠져본 적이 있는 분일 것입니다.

여기서 한 번, 제가 무엇을 원하고 있었는지 언어화해 보았습니다.

자주 사용하는 매크로를 상단에 두고 싶다

이것이 저의 바람이었습니다. 너무나 솔직한 바람이라 누구나 떠올릴 수 있는 것입니다.

보통 이를 실현하는 해결 방향은 다음 두 가지입니다:

• 수동으로 순서를 결정한다: 매크로 이름에 번호를 매긴다 (앞서 언급했듯이 유지보수 지옥)
• 사용 빈도로 자동 정렬한다: 호출 횟수를 기록하여 내림차순으로 정렬한다

2번은 구현해 본 적도 있지만, 이 역시 지속되지 않았습니다. 새로 작성한 매크로가 아래로 가라앉습니다 (횟수가 0이니까요). "최근에 만지지는 않았지만 중요한 것"도 아래로 가라앉습니다. "빈도"는 "중요도"의 대리 지표로서 정확하지 않기 때문입니다.

두 가지 모두 의욕이 생기지 않아 한동안 묵혀두던 어느 날, 문득 깨달았습니다.

정렬하는 것이 아니다. 정렬하는 것을 그만두는 것이다.

Alt+F8은 굳이 오십음도로 정렬해 주고 있다. 그렇다면, 나의 메뉴에서는 정렬을 하지 않겠다고 결정하면 됩니다. 정렬하지 않으면, VBE의 소스 상에 작성한 순서대로 그대로 나타납니다. 작성한 순서는 제가 결정한 순서이므로, 자주 사용하는 것을 위에 "작성"하기만 하면 됩니다.

"사용 빈도"를 Excel에 가르쳐 줄 필요가 없습니다. "번호"도 매길 필요가 없습니다. "소스에 작성한 순서"가 그대로 "나의 우선순위"가 됩니다.

바람의 방향("정렬하고 싶다")과 정답의 방향("정렬하는 것을 그만둬라")은 정반대였습니다. 이것이 이 글에서 가장 전달하고 싶은 이야기입니다.

"정렬을 빼고, 소스에 작성한 순서대로 나열한다"라고 결정했다면, 나머지는 구현할 뿐입니다. 구조를 말로 설명하면 다음과 같습니다:

VBA가 실행 시점에 자기 자신의 소스 코드를 읽어서, 그곳에 작성된 Sub의 이름을 리스트로 나열한다

이것이 리플렉션 (Reflection)입니다. Java나 C#에서 말하는 Reflection과 같은 발상을 VBA에서 하고 있을 뿐입니다. 등록표도 매니페스트 (Manifest)도 플러그인 API (Plugin API)도 없습니다. 소스 코드 그 자체가 '매크로 목록'을 겸하고 있습니다.

↑ 완성형: Ctrl+Shift+I로 나타나는 액티브 매크로 폼. 일본어 매크로 이름이 소스에 작성한 순서대로 그대로 나열되어 있음

실제 코드 (shu005의 '애드인 매크로 목록'에서 화면 위치 조정 등의 장식을 제외한 발췌):

' ThisWorkbook = 애드인 본체(슈 자신)의 표준 모듈을 이름 순으로 수집
Dim comps() As String
Dim compCount As Long
...

포인트는 두 가지만 있습니다:

• 모듈은 모듈 이름 순, Sub는 소스에 작성한 순서: 모듈 내에서는 For j = 1 To .CountOfLines를 통해 소스를 위에서 아래로 읽기 때문에, 작성한 순서대로 그대로 AddItem 됩니다. 깨달음 파트에서 말했던 "소스에 작성한 순서가 그대로 우선순위가 된다"는 점이 기술적으로 여기서 구현되어 있습니다.
• 인수가 없는 Sub만 추출: Function은 제외, 인수가 있는 Sub도 제외합니다. 이유는 단순합니다. "인수 없이 호출할 수 있다 = 버튼 하나로 실행할 수 있다"는 것만이 메뉴에 나타날 가치가 있기 때문입니다. VBA의 내부 처리용 Sub나 헬퍼 함수 (Helper function)가 이용자의 메뉴에 섞이지 않습니다.

이 Function과 인수가 있는 것을 걸러내는 필터가 "메뉴에 표시해야 할 것 / 표시해서는 안 될 것"의 판정을 자동으로 수행해 준다는 점이 은근히 효과적입니다. 이용자 입장에서 "호출해도 아무 일도 일어나지 않는 것들이 나열되어 있는 것"은 스트레스이므로, 이 부분을 자동으로 배제할 수 있다는 점이 큽니다.

"자주 쓰는 것을 위에 작성하면 위에 나온다"라고 말했지만, 실제로 하는 것은 VBE 상에서 해당 Sub를 물리적으로 위로 이동시키는 것입니다. 수작업으로 해도 되지만, 저는 지난번까지 만든 vba_manager.py에 reorder-macro라는 명령어를 추가해 두었기에, Claude Code에게 "캘린더 표시를 shu003의 맨 앞으로 가져와줘"라고 말하는 것만으로 소스의 순서가 바뀝니다.

정렬이란, 소스 코드를 편집하는 것입니다. "데이터"를 정렬하는 것이 아니라 "소스"를 정렬합니다. 이것이 "정렬하는 것을 그만둔다"와 일관성을 유지하는 방식의 순서 제어입니다.

shu005에는 거의 동일한 리플렉션을 구현한 Sub가 3개 있습니다:

내부의 리플렉션 처리(약 45줄)는 3개의 Sub가 한 글자도 틀리지 않고 동일합니다. 다른 점은 "대상 통합 문서"와 "붙여넣을 폼"뿐입니다. AI라면 공통 함수로 묶고 싶어 할 상황이지만, 의도적으로 그렇게 하지 않았습니다. 이유는 세 가지입니다:

• 입구의 명확성: 세 개의 목적지가 있다는 구조를 코드의 보이는 모습 그대로 유지합니다. 공통화하면 이 구조가 보이지 않게 됩니다.
• 이식성: 예를 들어 "액티브 매크로 목록"만을 다른 Excel 파일로 이식하고 싶을 때, 공통 함수에 의존하고 있으면 "저것도 필요하고 이것도 필요하고" 하는 상황이 되어 복잡해집니다. 매크로가 단독으로 완결되어 있다는 점이 분리해서 사용할 수 있는 성질을 보장합니다.
• 부트스트랩 (Bootstrap) 내성: 이 점은 특히 효과적입니다. 슈.xlsm을 다운로드한 사람이 애드인화하기 전의 첫 실행 시에도, Ctrl+Shift+I (액티브 매크로 목록)는 제대로 작동합니다. 현재 열려 있는 슈.xlsm 자신을 ActiveWorkbook으로 읽기 때문입니다. 그리고 표시된 목록 중에 "애드인 업데이트 등록"이 있으므로, 그것을 실행하면 애드인화가 완료됩니다. 세 개가 독립되어 있기 때문에, 어느 하나만 작동하면 전부 진행할 수 있습니다.

잠시 옆길로 새지만, AI와 함께 개발하게 되면서 이 「코드 중복을 허용한다」는 판단은 다시금 의식적으로 지키게 되었습니다. AI는 매우 뛰어난 존재라서, 코드 중복을 발견하면 반사적으로 공통화(Commonization)하고 싶어 합니다. 하지만 공통화는 **의존(Dependency)**을 낳습니다. 의존은 모듈의 경계를 모호하게 만들어, 「이 부분만 다른 곳으로 옮기기」를 어렵게 만듭니다. 秀.xlsm의 설계 원칙은 「언제든 분리할 수 있을 것」이며, 이 원칙과 「공통화」는 양립하기 어렵습니다. 그래서 AI가 「여기를 DRY(Don't Repeat Yourself)하게 만들까요?」라고 물어봐도 매번 거절하고 있습니다.

秀.xlsm의 공개 버전에는 제가 10년 넘게 만들어 온 약 100개의 매크로(캘린더, 인쇄, 시트 조작, 파일 목록 표시 등)가 처음부터 탑재되어 있습니다. shu001부터 shu005까지의 표준 모듈(Standard Module)로 나누어 들어 있으며, Ctrl+Shift+O로 메뉴를 열면 그것들이 전부 리플렉션(Reflection)을 통해 나열됩니다.

shu002만은 의도적으로 비워 두었으며, 이곳이 바로 이용자의 작업 공간입니다. shu002에 원하는 Sub를 하나 작성하고 Excel을 재시작하면 메뉴에 그것이 추가됩니다. 플러그인 API도, 등록 절차도, 설정 파일도 아무것도 필요 없습니다. 그저 Sub를 하나 작성할 뿐입니다.

그리고 새로 작성한 Sub는 내장된 약 100개의 매크로와 구분 없이 메뉴에 나열됩니다. 「여기서부터는 직접 만든 것」, 「여기까지가 내장된 것」 같은 구분선은 없습니다. 101번째를 추가하는 방식은 제가 100개를 만들었던 방식과 동일합니다. 이것이 제목으로 정한 「매크로를 작성하면 그대로 사용할 수 있는」——더 쉽게 풀어서 말하면 「Sub를 하나 추가하는 것만으로 메뉴에 나타난다」——이 글의 핵심 내용입니다.

↑ 위: shu002 모듈에 Sub 테스트용매크로()를 하나만 작성한 VBE 화면. 아래: Ctrl+Shift+O를 누르면 방금 작성한 「테스트용매크로」가 메뉴 맨 앞에 나타나 있다.

등록 절차도, 설정 파일도, 그 사이에 아무것도 끼어들지 않습니다. 작성했다, 그뿐입니다.

※ 秀.xlsm은 Excel 애드인(Add-in)으로 배포하도록 설계되어 있습니다. 왜 애드인 형식인지, 왜 그 애드인을 「언제든 분리할 수 있도록」 일부러 만들었는지——그 이야기는 다음 글에서 다루겠습니다.

두 가지를 나란히 놓고 보면 흥미로운 대비가 나타납니다:

같은 「매크로를 관리한다」는 문제를 정반대의 전략으로 풀고 있는 셈입니다. 매크로 데이터베이스는 「데이터를 밖으로 내보내 검색한다」는 발상입니다. 秀.xlsm은 「데이터는 그대로 두고, 해석하는 쪽을 VBA 스스로로 만든다」는 발상입니다. 본래는 같은 문제여야 하는데, 해법의 방향이 180도 다릅니다. 이 또한 저에게는 매우 흥미로운 포인트입니다.

벤치마크를 측정하지는 않았습니다. 하지만 효과가 있었는지 판단하는 것은 의외로 간단합니다. 매크로 데이터베이스를 더 이상 사용하지 않게 되었습니다.

10년 넘게 응급처치로 계속 사용해 온 것이, 秀.xlsm을 만든 뒤 문득 열지 않게 되었습니다. 오래된 도구가 새로운 도구에게 은퇴를 허락받았다——이것이 무엇보다 명확한 증거라고 생각합니다.

내용이 길어졌으므로 요약하겠습니다.

• 매크로가 늘어날수록 사용하기 어려워지는 이유는, 「작성」과 「사용」 사이에 찾기·호출하기라는 간극이 있기 때문이다. 이 간극은 작성 속도가 빨라질수록 커진다. 일반적인 대책(번호 매기기/빈도순 정렬)은 유지보수의 지옥이나 정확도 저하로 인해 지속하기 어렵다.
• 해답은 「정렬하는 것을 그만두는 것」이다. 정렬을 없애면 소스에 작성한 순서대로 그대로 나온다. 자주 쓰는 것을 위에 「작성」하면 위에 나온다.
• 秀.xlsm은 VBA가 자신의 소스를 읽게 하는 **리플렉션 (Reflection)**으로 이를 구현하고 있다. Sub를 하나 추가하면 그것이 그대로 메뉴에 나열된다. 플러그인 API도, 등록 절차도, 설정 파일도 없다.
• AI로 만드는 속도가 빨라진 지금이야말로, 먼저 「현장의 사람이 어떻게 호출할지」를 결정해 두는 것이 결정적으로 중요하다.

그리고 다음 회차(기사 4)에서는 제가 「매크로 관리의 핵심」이라고 생각하는 **「일본어로 매크로를 관리하기」**라는 이야기와, 그와 맞닿아 탄생한 **「애드인(Add-in)을 언제든 분리할 수 있도록 만들기」**라는 설계에 관한 이야기를 쓰겠습니다.

사실, Microsoft가 Excel 업데이트 과정에서 저의 PERSONAL.XLSB를 두 번 망가뜨린 적이 있는데, 그것이 「일본어 매크로 이름」과 무관하지 않았다는 오리진 스토리(Origin story)를 중심으로 쓸 예정입니다. 드라마틱한 이야기가 아니라, **담담하게 「그래서 이런 방식으로 만들고 있다」**는 설명으로서 말이죠.

GitHub: https://github.com/shu1551/shu-vba-manager

여기까지 읽어주셔서 감사합니다. 「Sub를 하나 추가하는 것만으로 메뉴에 나타나는 것」을 테스트해 보고 싶은 분은, 리포지토리에서 秀.xlsm을 다운로드하여 Excel에서 열고 Ctrl+Shift+I(활성 매크로 목록)를 눌러보세요. 표시된 메뉴의 맨 아래에 「애드인 업데이트 등록」이 있습니다. 그것을 실행하면 애드인화가 완료되며, 이후에는 Ctrl+Shift+O(애드인 매크로 목록)를 통해 秀.xlsm의 매크로를 호출할 수 있게 됩니다. 꼭 shu002에 원하는 일본어 이름의 Sub를 하나 작성하여 메뉴에 나열되는 것을 확인해 보세요. 작성하는 순간, 자신의 매크로가 내장 매크로와 구분되지 않고 나열되는 감각은 아마 상상보다 수수하면서도, 상상보다 기분 좋을 것입니다.

GitHub (툴킷): https://github.com/shu1551/shu-vba-manager -
YouTube (사무 개선·VBA·AI 활용 영상을 올리고 있습니다): https://www.youtube.com/@しゅう-v2w