자작 VBA 관리 도구(vba_manager.py)에 대한 이야기의 후속편입니다. Excel에서 열려 있는 상태의 통합 문서(Workbook)에 대해, 매크로 취득·치환부터 시트 편집까지를 명령어로 수행하는 Python 도구이며, 코드는 GitHub(shu-vba-manager)에 공개되어 있습니다.

지난 업데이트 기사에서는 Stefan Broenner 님의 Excel MCP를 참고하여 「눈」(시트를 읽는 기능)과 「손」(시트를 편집하는 기능)을 추가했다는 이야기를 썼습니다. 그 작업은 Claude의 새로운 모델인 Claude Fable과 함께 진행한 것이었습니다.

그런데 그 후, Fable을 사용할 수 없게 되었습니다. 아시는 분들도 많겠지만, 공개된 지 불과 3일 만인 6월 12일, 미국 상무부의 수출 관리 명령으로 인해 Fable 5 / Mythos 5에 대한 액세스가 중단되었기 때문입니다. 규제는 6월 30일에 해제되었고, 7월 1일에 이용이 재개되었습니다.

그리하여, Fable이 드디어 부활했기에 멈춰 있던 이 도구의 개수(改修)를 한꺼번에 진행했습니다. 그 기록입니다.

• 「철저하게 점검해 줘」라는 한마디로 시작했더니,
  스스로는 깨닫지 못했던 버그가 중대한 5건을 포함하여 십수 건이나 나왔다. 전부 수정하고 회귀 테스트(Regression Test)까지 통과시켰다 - 겸사겸사 편의성도 높였다.
  전체 매크로를 가로지르는 코드 검색(grep), 백업에서 되돌리는 undo 동선(restore), 명령어 열을 한 번에 실행하는 batch(Excel 실행을 포함해 6개 명령어 약 1초) 등을 추가했다 - 폼(Form)은 만드는 방식이 바뀌었다.
  행 구조를 8줄 쓰면, 정렬된 폼이 구축된다. 배치도 프리뷰는 Excel이 필요 없으며, 구축 후에는 스크린샷과 기계 검사(lint)로 검증하고, 기존 폼은 선언 코드로 역변환도 가능하다 - 마무리로 **통합 문서 건강 진단(checkup)**을 만들었다. 구성·호출 관계·폼 검사·죽은 코드(Dead Code) 검출을 하나의 리포트에 담았다. 10년 동안 키워온 자작 통합 문서에 돌려봤더니,
  삭제한 버튼의 이벤트 코드 7건이 발견되었다 - 다음 날에는 이를 발전시켜, 일본어 이름(健康診断 [건강진단])·이전과의 차이점(정기 검진)·종합 판정·수리 메모가 담긴 차트까지 만들었다. 실전에서는, 나 자신이 「고쳐야 하는데」라고 생각하며 방치해 두었던 「누르면 떨어지는(crash) 메뉴 버튼」을 기계가 지목하여, 단 한 마디로 수리할 수 있었다 - 셋째 날에는 검사 부분을 의심했다.
  모든 폼에서 울리는 경보나, 수리로 한 번도 이어지지 않는 검사는 제거했다. 의도적인 디자인은 「확인됨」으로 기록하는 메커니즘(--ack-all)을 추가했더니, 소견 103건이 실질적으로 0건·종합 판정 A가 되었다 - vba_manager.py는 8,782행·67개 명령어가 되었고, 도구 세트 전체로는 1.2만 행이 되었다. 전부 대화로 만들었다.

이 연재는 「대화하는 것만으로 매크로가 고쳐진다」에서 시작되었습니다. VBA 코드를 AI에게 넘겨서 고쳐달라고 하는 것이 아니라, 열려 있는 통합 문서에 Python으로 접속하여 취득도 치환도 저장도 끝내는 방식입니다. 지난 업데이트에서 거기에 「눈과 손」이 붙어, 시트 내용을 읽으면서 매크로를 고칠 수 있게 되었습니다.

즉, 도구는 갖춰져 있었습니다. 갖춰져 있었지만, 도구 자체의 점검은 하지 않았습니다.

재회한 Fable에게 내린 첫 번째 지시는 이것뿐입니다.

"VBA 매니저를 점검해 줘. 철저하게."

Fable은 관점별로 4계통의 리뷰(기반·VBA 명령어·시트 편집·중량급 명령어와 문서의 정합성)를 병렬로 실행하고, 동시에 스크래치(Scratch) 테스트용 통합 문서에서 실제로 명령어를 구동하는 실운전 테스트를 수행했습니다. 수십 분 후 돌아온 보고에는 중대 5건·중간 9건·소규모 다수의 버그가 나열되어 있었습니다.

매일 사용하는 도구입니다. 그런데도 이만큼 나왔습니다. 몇 가지 소개하겠습니다.

가장 위험했던 것은 이것입니다. 프로시저(Procedure) 치환 명령어에는 단축키 정의(Attribute 행)를 유지하기 위한 특별한 경로가 있는데, 거기서 사용하던 End 검출 정규 표현식이 행 끝까지를 요구하고 있었습니다.

End Sub ' 末尾コメント (끝 주석)

이 형태에는 매치되지 않습니다. 그러면 치환 범위의 스캔이 다음 프로시저의 End Sub까지 늘어나게 되고, 조건이 맞으면 옆의 매크로를 통째로 휘말아 들여 삭제해 버립니다. 경고는 나오지 않습니다.

수정 사항은 정규 표현식(Regular Expression)이 끝부분의 주석을 허용하도록 만드는 단 한 줄의 코드였지만, 진짜 무서운 점은 그다음부터였습니다. Fable은 수정한 후 "Attribute 행 있음 × 끝부분 주석 있음 × 후속 Sub 있음"이라는 재현 조건을 테스트용 북(Book)에 실제로 만든 뒤, 수정 전이라면 삭제되었을 두 번째 Sub가 살아남는 것을 확인하고 나서야 완료되었다고 보고해 왔습니다. "고쳤습니다"라는 말보다 "더 이상 삭제되지 않는 모습"을 직접 보여주는 편이 훨씬 신뢰가 갑니다.

인수 분석(Argument Parsing) 과정에서 알 수 없는 옵션을 묵묵히 버리도록 설계되어 있었습니다. 이로 인해 발생하는 문제는 다음과 같습니다.

py vba_manager.py clear-range "Sheet1!A1:C10" --contets # ← 오타

--contents (값만 삭제)를 의도한 오타가 무시되고, 기본 동작인 즉, 값과 서식을 모두 삭제하는 쪽으로 넘어가 버립니다. 오타 한 글자 때문에 동작이 파괴적인 방향으로 변해버리는 것입니다. 현재는 알 수 없는 옵션이 감지되는 즉시 에러를 내며 중단되도록 수정되었습니다.

다른 이름으로 저장 시 기존 파일을 확인 없이 덮어쓰는 문제, 매크로 실행 후 Excel의 경고 설정(DisplayAlerts)이 해제된 채로 남는 문제, "시트 이름만" 범위를 지정했을 때 사용 범위 전역이 삭제 대상이 되는 문제 등도 모두 차단했습니다. 사람이 실수할 법한 일들을 하나하나 에러로 막아내는 방향으로 개선했습니다.

점검이 끝난 시점에서 "더 편리하게 만들 수 없을까, 철저하게"라고 물어보았습니다. 이번에는 사용성 관점에서 리뷰가 진행되었고, 약 20건의 제안이 돌아왔습니다. 저는 전부 실행했습니다. 주요 내용은 다음과 같습니다.

grep (전체 매크로를 가로지르는 코드 검색). "어떤 매크로가 ActiveSheet를 사용하고 있는가"를 단 한 번의 명령으로 [모듈] 프로시저명:행번호 형태로 반환합니다. 이전에는 모든 모듈을 내보내기(Export)한 뒤 수동으로 찾아야만 했습니다.

list-backups / restore (undo 동선). 이 도구는 치환할 때마다 5세대까지 백업을 자동으로 남기지만, 되돌리는 명령어가 없었습니다. 백업은 쌓이기만 하고, 정작 되돌릴 때는 수작업을 해야 했습니다. restore는 백업 파일 내의 VB_Name으로부터 대상 모듈을 특정하여, 대조 과정을 거친 안전한 경로로 다시 써넣습니다.

batch (명령어 열을 한 번에 실행). 이 도구는 명령어 하나당 Excel에 매번 COM 연결을 새로 하는 구조였는데, 이 부분이 가장 무거웠습니다. batch는 텍스트 파일에 작성된 명령어 열을 단 한 번의 연결로 흘려보냅니다. 실측 결과, Excel 자동 실행부터 뒷정리까지 포함하여 6개의 명령어를 처리하는 데 약 1초가 걸렸습니다.

read-range --tsv (읽기/쓰기 왕복). 매크로 수정은 "get으로 파일에 내보내기 → 편집 → replace로 되돌리기"라는 왕복 프로세스가 확립되어 있었지만, 셀 값은 화면 표시만 가능할 뿐 수정하려면 직접 손으로 옮겨 적어야 했습니다. 이제 읽은 범위를 TSV로 내보내고, 편집한 뒤, write-range로 다시 써넣을 수 있습니다. 매크로와 동일한 형식이 셀에도 적용되게 되었습니다.

가장 크게 변한 것은 폼(UserForm)입니다. 이전 글에서 "대화만으로 폼을 만들 수 있다"고 썼지만, 당시의 실체는 AI가 좌표를 하나하나 암산하여 add_btn(f, "BtnOK", "OK", 80, 160, 60, 20)와 같이 배치하는 방식이었습니다. 동작은 하지만, 라벨의 세로 정렬이 맞지 않거나 버튼 높이가 들쭉날쭉한 등의 세세한 어긋남은 사람이 직접 보고 수정해야 했습니다.

이번에는 레이아웃 엔진(form_layout.py)을 만들어 폼을 "행(row) 구조"로 작성할 수 있게 했습니다.

build_form("F_Order", "受注入力", rows=[
    heading("顧客情報"),
    row(lbl("顧客名"), txt("txtName", required=True)),
    ...

이것이 전부입니다. 라벨 열의 너비를 맞추고, 입력란의 오른쪽 끝을 맞추고, 버튼을 오른쪽 아래에 동일한 크기로 나열하며, Enter와 Esc를 할당하고, 탭 순서를 시선 순서로 만드는 등의 계산은 모두 Python 측에서 수행합니다. required=True를 붙인 항목은 라벨에 "*"가 붙고, 실행 버튼에는 "입력해 주세요"라는 빈 값 체크(Empty Check) 코드 초안까지 자동으로 삽입됩니다.

제작 후의 검증도 기계화했습니다. 폼(Form)을 실제로 화면에 표시하여 스크린샷을 찍는 명령, 겹침·넘침·불일치·탭 순서 어긋남을 검사하는 lint, 컨트롤의 테두리와 이름을 이미지에 그려 넣는 오버레이(Overlay). lint는 코드와의 정합성도 확인하여, 컨트롤을 삭제했음에도 이벤트 프로시저(Event Procedure)가 남아 있는 '고아 핸들러(Orphan Handler)'도 검출합니다.

역방향도 있습니다. 기존 폼을 분석하여 위의 선언 코드로 **역변환(Reverse conversion)**하는 명령(--to-layout)입니다. 역변환한 코드를 그대로 실행하면 동일한 폼이 생성된다는 것을 왕복 테스트(Round-trip test)로 확인했기에, 오래된 폼의 대규모 수정은 '선언으로 변환 → 선언 편집 → 재구축' 방식으로 바뀌었습니다. 탭이 있는 폼(MultiPage)도 일괄 대응합니다.

단 하나, 할 수 없었던 것도 있습니다. 셀 범위를 선택하게 하는 RefEdit 컨트롤은, COM을 통한 삽입이 Excel 측의 보안 설정에 의해 차단된다는 것을 실기 테스트를 통해 확인했습니다. 이는 TextBox + '선택' 버튼 + Application.InputBox(Type:=8)의 조합으로 대체하고 있습니다. 동작 측면에서는 오히려 이 방식이 더 안정적입니다.

하루의 마무리로, 지금까지의 부품들을 하나로 묶은 checkup이라는 명령을 만들었습니다. 통합 문서(Workbook)를 명령 하나로 진찰하고, Markdown 형식의 리포트를 생성합니다. 확인하는 항목은 구성(시트·매크로·폼의 목록화), 존재하지 않는 매크로 호출(복사 붙여넣기 수정 시 흔히 발생하는 '한 글자만 다른 Call'의 검출), 폼의 기계 검사(겹침·탭 순서·삭제된 컨트롤의 이벤트 코드가 남아 있는지 여부), 백업 상황입니다.

시험 삼아 10년 동안 키워온 자작 업무용 통합 문서를 돌려보았습니다. 결과가 흥미로웠습니다. 매크로 본체(101개·2,376행)는 소견 제로(Zero). 그런데 폼 쪽에서 죽은 이벤트 코드 7건이 나왔습니다. 내용을 보니 '검색 버튼'의 잔해였습니다. 예전에는 글자를 입력하고 버튼을 눌러 검색하는 방식이었는데, 이후 '입력하는 즉시 필터링'하는 방식으로 진화시키면서 버튼만 지우고 코드는 남겨두었던 것입니다. 페이지 이동 버튼의 잔해도 있었습니다. 10년 치 진화의 흔적이 진단서에 떠오른 격입니다. 7건 모두 현재 로직이 다른 곳에서 살아있음을 확인한 후, 그 자리에서 삭제했습니다(물론 자동 백업 기능과 함께).

진단은 '읽기 전용'이므로 안전합니다. 닫혀 있는 문서를 진찰할 때는 읽기 전용 + 매크로 자동 실행을 중단한 상태로 열도록 설계했습니다. 회사에 잠들어 있는 '누가 만들었는지 모를 매크로 포함 문서'에도, 깨우지 않고 청진기를 댈 수 있습니다.

사실 이 checkup은 기사를 마무리한 다음 날 한 단계 더 발전했습니다. 우선 이름입니다. 일본어 별칭으로 호출할 수 있게 했습니다.

py vba_manager.py 건강진단

이 연재에서 줄곧 '매크로 이름은 일본어로 해도 된다'고 써온 입장에서, 자신의 도구 명령어가 영어로만 남아 있는 것은 멋이 살지 않았기 때문입니다.

내용도 건강검진답게 바뀌었습니다. 진단할 때마다 결과를 문서별 이력으로 기록하여, 다음부터는 '이전과의 비교'를 자동으로 출력합니다. 새로 나타난 소견, 해결된 소견, 매크로·시트·폼의 증감 등을 보여줍니다. 행 번호의 차이로는 차이(diff)를 내지 않는 구조이므로, 코드가 길어진 것만으로는 소란을 피우지 않습니다. 리포트 상단에는 종합 판정(A=소견 없음 / B=소견 있음 / C=손상된 참조·호출 있음)이 붙으며, 시트 쪽도 진찰하게 되었습니다. 수식 오류 셀, 참조 설정 손상(잠들어 있는 문서가 작동하지 않는 주요 원인입니다) 등을 확인합니다. VBA에 암호가 걸린 문서를 만났을 경우에는 오류 없이 시트 쪽만 축소 진단하는 방식으로 자동 전환됩니다.

수정 측면에는 영향 범위(impact)라는 명령을 추가했습니다. '이 매크로를 건드리면 어디까지 파급되는가'를 수정 전에 목록화합니다. 호출처는 간접 호출까지 거슬러 올라가며, 시트 위의 버튼이나 폼의 이벤트로부터의 경로도 출력합니다.

그리고 '차트(Medical Record)'. 수정 후에 健康診断 --note "무엇을 고쳤는가"라고 입력하면, 그 한마디가 이력에 남습니다. --history로 과거의 진단을 목록화할 수 있으며, 각 진단 사이에 어떤 소견이 사라졌는지까지 표시됩니다. AI가 고쳐준 수정 사항은 직접 손으로 고쳤을 때만큼 기억에 남지 않습니다. 이는 AI와 일하며 느끼는 솔직한 실감입니다. 그래서 기억하는 대신 떠올릴 수 있는 메커니즘을 도구 쪽에 갖추게 했습니다.

다른 자작 통합 문서(매크로 214개·4,245행)에 건강검진을 실시했더니, 종합 판정 C가 나왔습니다. 메뉴의 버튼이 존재하지 않는 매크로를 호출하고 있었습니다. 매크로 이름을 변경했을 때 버튼 쪽의 호출만 남겨진, 이른바 한 글자 오타 버그였습니다.

솔직히 고백하자면, 이곳은 저 스스로도 "고쳐야지"라고 자각하면서 몇 년 동안 방치해 두었던 부분이었습니다. 머릿속에만 있던 "언젠가 고치겠다"라는 리스트를, 기계는 망설임도 사양도 없이 지목해 옵니다. 호출 대상을 한 글자 수정하고 재검진을 실시하자 판정은 B로 돌아갔고, 비교란에는 "해소 1"이 표시되었습니다. 진단 → 수리 → 재진단으로 치유를 확인하는, 건강검진의 패턴이 한 바퀴 돈 순간이었습니다.

또 하나 솔직하게 적자면, 실전용 통합 문서에 차례차례 적용하다 보니 처음에는 진단 측의 오탐(False Positive)도 발생했습니다. Win32 API 선언(Declare) 호출, 실행 시점에 호출 대상이 결정되는 동적인 Application.Run, 객체의 메서드 호출 등—모두 "존재하지 않는 매크로"라고 오보되었고, 시트 위의 버튼에 등록된 매크로를 "어디에서도 호출되지 않음"으로 취급하는 간과도 있었습니다. 원인을 고칠 때마다 다음 진단의 비교란에 "해소 5", "해소 12"라고 자동으로 보고되어 오기 때문에, 검사기를 단련하는 작업 그 자체의 정답 맞히기가 되기도 했습니다. 진단기가 처음부터 똑똑했던 것이 아니라, 실제 통합 문서에 부딪히며 똑똑해진 것이 실체입니다.

셋째 날은 폼(Form) 검사 차례였습니다. 애드인(Add-in) 본체 17개와 업무용 통합 문서 9개, 총 26개의 폼을 진단 리포트와 실제 표시되는 스크린샷을 대조하며 한 장씩 총점검했습니다. 진짜 수리 사항도 꽤 나왔습니다. 삭제한 버튼의 이벤트 코드 잔해 10건, 실행 버튼이 리스트 가장자리에 걸쳐 있던 겹침, 단 하나뿐인 작은 폰트 오타, 제각각인 탭 이동 순서. 모두 자동 백업 기능을 사용하여 그 자리에서 바로 수정했습니다.

그런데 고쳐도 고쳐도 소견(Finding)의 합계가 줄어들지 않았습니다. 애드인 측은 103건. 내용을 보니 대부분이 "폰트 크기가 맞지 않음", "같은 행의 버튼 너비가 3종류임" 같은 종류였는데, 모두 의도적으로 설정한 디자인이었습니다. 검색창만 크고, 화살표 버튼만 작았습니다. 제작자의 말에 따르면, 의도적으로 그렇게 만든 것이니 그 부분을 검사하는 쪽이 이상하다는 것이었습니다.

맞는 말이었습니다. 소견 측이 아니라 검사 측을 의심하며 하나씩 실적을 조사했습니다.

• "Enter 키의 기본 버튼 미설정" —— 17개 중 17개 모두에서 발생했습니다. 모든 곳에서 울리는 경보는 경보가 아닙니다. [제거]
• "컨트롤 겹침" —— 경계가 딱 맞닿아 있는 인접한 컨트롤 20건을 겹침으로 취급하고 있었습니다. 허용 오차 2pt로 [해소]
• "폰트 혼재" —— 수작업으로 10년간 가꿔온 폼에는 11.8pt나 14.1pt 같은 소수점 단위가 흔히 존재합니다(확대/축소나 복사 시의 반올림 오차). 육안으로 구분이 불가능한 1.5pt 미만의 차이는 보고하지 않기로 했습니다.
• "같은 행의 버튼 너비가 3종류", "왼쪽 끝 세로 라인이 많음" —— 과거 그 어떤 수리로도 이어지지 않았던 검사였습니다.
• 시트 측의 "고스트 행(파일 비대화의 후보)" —— 테두리를 그려 놓은 입력란, 즉 설계 자체를 비대화로 취급하는 오탐을 하고 있었습니다. [제거]

그럼에도 마지막에 남는 것이 정말 의도적인 폰트의 구분 사용입니다. 기계는 의도를 읽을 수 없습니다. 이 부분은 검사의 정밀도가 아니라 메커니즘으로 해결했습니다. 건강검진 --ack-all이라고 입력하면, 현재 나타난 소견을 "확인됨(의도적)"으로 등록하여 이후에는 건수나 종합 판정에도 포함하지 않고, 리포트 끝에 사실로서 계속 남겨둡니다. 판단을 바꾸고 싶다면 --unack로 되돌릴 수 있습니다. 검사 로직의 변경으로 다시는 나타나지 않게 된 오래된 등록 사항은 진단할 때마다 자동으로 정리됩니다.

참고로, 이날의 개수는 Claude Sonnet과 진행하였고, 마무리 단계에서 Fable에게 리뷰를 부탁했더니 이 신규 메커니즘이 '확인됨' 리스트를 너무 많이 지워버리는 잠재적 버그를 1건 찾아냈습니다. 만든 눈과는 다른 눈으로 점검하는 것—도구의 개수에도 건강검진이 필요한 모양입니다.

결과적으로 애드인 본체(매크로 312개·4,845행·폼 17개)와 업무용 통합 문서 모두 소견 0건·종합 판정 A가 되었습니다. 제로로 만든 것이 아니라, 고쳐야 할 것을 고치고 의도적인 것을 의도적이라고 기록한 결과로서의 제로입니다. 기계는 사실을 세고, 의도는 인간이 판정합니다. 그 판정을 도구가 기억합니다. 셋째 날에 이르러서야 건강검진은 마침내 그 역할 분담에 안착했습니다.

첫날의 개수부터 셋째 날의 검사 대청소까지 포함한 결과입니다(실측치).

항목	내용
수정된 버그	중대 5 · 중급 9 · 소규모 다수 (작업 중 발견하여 수정한 것 수 건 포함)
...

기사를 쓰기 전, 문득 「しゅう VBAマネージャー (슈 VBA 매니저)」로 검색해 보았더니 Google의 AI 개요(AI Overviews)가 나타났습니다. Qiita의 기사와 GitHub 리포지토리(Repository)를 근거로, 이 도구를 저의 작품으로서 설명해 주고 있었습니다. 연재를 계속해 온 성과가 검색 엔진의 지식에 통합된 것 같아, 이는 조금 기쁜 일이었습니다.

하지만, 저는 엔지니어가 아닙니다. 그저 사무원일 뿐입니다.

다만, 한 가지 마음에 걸리는 것이 있었습니다. 검색 결과의 설명에서는 「도입에는 Python이 필요하며, 그 지식이 없으면 어렵다」는 취지의 말을 하곤 합니다. 이것은 틀렸다고, 제작자로서 말해두고 싶습니다.

「대화하는 것만으로 매크로가 고쳐지는」 환경을 만드는 데 무엇이 필요한가. 그 장벽을 솔직하게 세어 보겠습니다.

장벽 1: Python 설치. 공식 사이트에서 인스톨러(Installer)를 다운로드하여 실행하기만 하면 됩니다. Python에 대한 지식은 전혀 필요하지 않습니다. 코드를 쓰고 읽는 것은 AI의 일이며, 인간이 하는 것은 일본어(한국어)로 말하는 것뿐입니다. 이 연재의 제목이 「대화하는 것만으로」인 이유가 바로 그것입니다. 「Python을 사용하는」 것이 아니라 「Python이 놓여 있는」 것뿐이라고 말하는 편이 실태에 더 가깝습니다.

장벽 2: pywin32 추가. 커맨드(Command)를 한 줄 입력하기만 하면 됩니다 (pip install pywin32). 그것조차 도입한 AI에게 「pywin32를 설치해 줘」라고 말하면 해줍니다.

장벽 3: GitHub로부터의 다운로드. 이것은 확실히 초보자에게는 가장 「모르는 세계」일지도 모릅니다. 하지만 실제로 하는 일은 리포지토리 페이지에서 초록색 「Code」 버튼을 누르고 「Download ZIP」을 선택하는 것—그뿐입니다. Git 커맨드는 필요 없습니다. 잘 모르겠다면 YouTube에서 「GitHub 사용법」을 검색하면 초보자용 해설 영상이 얼마든지 나오고, 심지어 AI에게 「이 페이지에서 파일을 다운로드하고 싶어」라고 물으면 절차를 알려줍니다.

장벽 4: Excel 설정. 「VBA 프로젝트 개체 모델에 대한 액세스 신뢰(Trust access to the VBA project object model)」에 체크를 하나 합니다 (신뢰 센터(Trust Center) 안에 있습니다). 이 부분이 가장 잘 알려져 있지 않아서 README에 적어 두었습니다.

장벽 5: Claude Code 도입. 솔직히 말하면, 가장 「새로운 것을 한다는 느낌」이 드는 것은 이 부분입니다. 다만 공식 절차가 잘 정비되어 있으므로 순서대로 하면 설치됩니다.

세어 보면 알 수 있듯이, 어떤 장벽이든 필요한 것은 「지식」이 아니라 「처음 하는 조작을 한 번 해보는 것」입니다. 전부 합쳐도 휴일 오전 중에 끝날 작업량이라고 생각합니다. 그리고 가장 큰 안심 요인은, 막히면 이제 막 도입하려는 바로 그 AI에게 물어보면 된다는 것입니다. 도입에 관한 질문부터 이미 대화는 시작되어 있습니다.

이것은 상상으로 쓰는 것이 아닙니다. 저 자신이 그랬기 때문입니다. Python 환경도 GitHub 조작도, 저는 Claude에게 물어보면서, 혹은 시키면서 넘어왔습니다. 장벽의 높이를 자신의 발로 직접 재본 적이 없는데, 정신을 차려 보니 반대편에 와 있었다는 것이 솔직한 심정입니다.

또 하나, 본론과는 벗어나지만 남겨두고 싶은 말이 있습니다.

최근 2개월 정도 사이, 일본의 대형 SIer들이 잇따라 Anthropic(Claude의 개발사)과의 제휴를 발표했습니다. 4월에는 NEC(일본 기업 최초의 글로벌 파트너, 그룹 약 3만 명에게 Claude 전개), 5월에는 Hitachi(그룹 약 29만 명)와 Fujitsu(약 10만 명). 게다가 대상 영역으로 관공서 · 금융 · 중요 인프라와 같이 「실수가 허용되지 않는」 분야가 명시되었습니다. 나아가 Microsoft 스스로도 Microsoft 365 Copilot에 Claude를 통합하여, Excel 내부에서 사용할 수 있게 했습니다.

「Excel/VBA는 오래되었고, 특정 개인에게 종속(属人化, Silo)되므로 클라우드로 가야 한다」는 이야기를 지난 10년 동안 계속 들어왔습니다. 종속된다고 말하는 근거는 「만든 본인만이 코드를 읽을 수 있다」는 것이었을 겁니다. 그런데 AI가 VBA를 읽고 고칠 수 있게 된 지금, 그 근거 자체가 사라지고 있습니다. 이 연재에서 해온 일은 뜻하지 않게 그 실연(Demonstration)이었던 것이라고 생각합니다.

과장된 말은 하고 싶지 않으므로, 사실과 견해를 구분해 두겠습니다. 제휴의 규모와 시기는 공표된 사실입니다. "AI는 Excel을 대체하는 것이 아니라, Excel을 다시 만드는 쪽으로 돌아섰다" —— 이것은 저의 견해입니다. 정답 확인은 몇 년 후에 하고 싶습니다.

지난 업데이트 기사에서 "가장 변한 것은 대화의 내용"이라고 썼습니다. 이번에는 한 단계 더 나아가, 대화가 "이것을 고쳐줘"가 아니라 "점검해 줘", "더 좋게 만들 수 없을까", "전부 다 해줘"로 바뀌었습니다. 무엇을 고칠지 제가 지정하지 않았음에도, 제가 사용하는 도구의 빈틈이 발견되고 메워져 갑니다. 도구의 점검과 개수를 도구에게 맡기는, 그러한 순환이 드디어 돌아가기 시작했다는 느낌이 듭니다.

물론, 고친 것도 AI라면 버그를 심은 것도 AI입니다. 그 점은 서로 마찬가지라고 해두죠.

마지막으로 하나만 덧붙이자면, 저는 사무원입니다. 프로그래머가 아닙니다. 그 사무원의 손에 지금 1만 행이 넘는 Python 제 툴 세트가 있습니다. 전문가가 본다면 어떻게 평가할지는 모르겠지만, 적어도 저 혼자서는 평생 걸려도 쓰지 못했을 것입니다. 쓴 것은 AI였고, 제가 한 것은 "고치고 싶다", "더 좋게 만들고 싶다"라고 일본어로 계속 말하는 것뿐이었습니다.

지금까지 "프로그래밍은 자신과는 상관없는 일"이라며 벽 앞에서 멈춰 서 있던 사람이야말로, 한 번 시도해 볼 시대가 되었다고 생각합니다. 벽은 AI가 함께 넘겨줄 것입니다.

지금 제가 하고 있는 일이 바로 그 증명일지도 모르겠습니다.

다음 회차에는 새로운 퀵(Quick) 계열 툴에 관한 이야기를 쓸 예정입니다.