자작 VBA 관리 도구 업데이트 알림 ── Excel MCP를 참고하여 열려 있는 통합 문서도 조작할 수 있게 만든 이야기

이 연재에서 몇 번인가 소개했던 자작 도구 vba_manager.py (GitHub에서 공개 중)를 크게 업데이트했기에 그 소식을 전합니다. 아울러, 직접 사용해 보며 알게 된 "무엇이 바뀌었는가"에 대한 이야기도 함께 나누고자 합니다.

원래 이 도구는 Excel의 VBA 코드를 관리하기 위한 것이었습니다. 매크로 목록 출력, 코드 추출, 수정 후 복구 등, 명령어로 구성된 9개의 도구일 뿐이었습니다.

이번 업데이트를 통해 시트 자체를 조작하는 기능을 추가하여 약 50개의 명령어가 되었습니다.

계기는 Stefan Broenner 씨가 공개한 Excel MCP (sbroenne/mcp-server-excel)를 접하게 된 것이었습니다. COM을 통해 Excel을 조작하는 MCP 서버로, 범위 편집·서식·그래프·피벗·PowerQuery까지 일通り 갖추고 있습니다. 매우 잘 만들어져 있습니다.

다만, Excel MCP는 "대상 파일은 Excel에서 닫아둔 상태"를 전제로 설계되어 있습니다. COM의 배타적 제어(Exclusive Control)를 고려하면 확실하고 올바른 판단이라고 생각합니다. 반면, 저는 秀.xlsm을 애드인(Add-in)으로 항상 열어두고 있으며, 작업 파일도 열어둔 채로 다루는 스타일입니다.

그래서 Excel MCP의 기능을 참고하면서, "열려 있는 통합 문서"를 대상으로 유사한 작업을 할 수 있는 기능을 Claude Code와의 대화를 통해 vba_manager.py에 추가해 나갔습니다. vba_manager.py는 원래 GetActiveObject를 통해 실행 중인 Excel에 측면에서 접속하는 구조이므로, 토대는 그대로 사용할 수 있었습니다.

크게 세 단계로 나뉩니다.

읽기 계열 (AI의 눈) ── 시트의 상태를 텍스트나 이미지로 확인

py vba_manager.py read-range A1:D10 # 셀 값을 텍스트 격자로
py vba_manager.py sheet-info # 시트 구성·사용 범위
py vba_manager.py screenshot A1:H30 # 범위를 PNG로

쓰기 계열 (AI의 손) ── 값·서식·행렬·검색 치환·인쇄 설정 등

py vba_manager.py write-range C1 "=SUM(A1:A10)"
py vba_manager.py format-range A1:D1 --bold --bg "#FFFF00"
py vba_manager.py find-replace 구 검색어 신 검색어 A1:Z99

중량급 ── 그래프·피벗·슬라이서·PowerQuery·데이터 모델

py vba_manager.py chart create A1:B5 --type column --title "월별 매출"
py vba_manager.py pivot create 원본데이터!A1:C100 --rows 부문 --values 매출
py vba_manager.py powerquery load 상품마스터 --to sheet

파일 경로를 생략하면 현재 Excel에서 열려 있는 활성화된 통합 문서(Active Workbook)가 자동으로 대상이 됩니다.

기능 목록보다 이 부분이 본론일지도 모르겠습니다.

이 연재의 제1회는 "대화하는 것만으로 매크로가 고쳐진다"는 이야기였습니다. 그것은 지금도 사실입니다. 다만, 그 당시의 AI가 보고 있었던 것은 코드뿐이었습니다. 코드를 읽고, 코드의 논리로 수정합니다. 매크로가 실제로 조작하는 시트가 어떻게 되어 있는지는 제가 말로 설명할 수밖에 없었습니다.

눈과 손이 생기면 이곳이 달라집니다. 실제로 있었던 사례를 하나 들겠습니다.

얼마 전, 공개 중인 "파일 목록" (폴더 하위의 파일을 Excel로 목록화하는 자작 도구)의 매크로를 AI에게 리뷰하게 했습니다. 검색 매크로 안에 다음과 같은 행이 있습니다.

wsTarget.Range("A1").AutoFilter Field:=1, Criteria1:="*" & CTV & "*"

코드만 읽으면 이것은 A열을 검색하고 있는 것처럼 보입니다. 하지만 이 시트의 A열은 일련번호이고, 파일명은 B열입니다. 즉, "검색어를 번호 열에 적용하고 있다 = 이 매크로는 고장 났다"라는 지적이 나와야 했습니다.

AI는 지적하기 전에 시트를 보았습니다. sheet-info

시트 구성을 확인하고, 헤더 행을 읽고, 나아가 실제로 필터를 걸어 동작을 측정했습니다. 그 결과, 시트에는 이미 B열 기점(B1:F)으로 오토필터(AutoFilter)가 적용되어 있었으며, Field:=1은 B열=파일명에 적용되고 있다는 것을 알 수 있었습니다. 7.8만 행의 실제 데이터에 "md"로 필터링하니 1,773건이 나왔습니다. 매크로는 정상적으로 작동하고 있었습니다.

AutoFilter의 Field는 시트의 열 번호가 아니라 필터 범위의 왼쪽 끝에서부터 센 상대적인 번호입니다.

시트의 열	A (번호)	B (파일명)	C (폴더)	D (갱신 일시)
필터 범위 B1:F 내에서는	― (범위 외)	Field 1	Field 2	Field 3

이 시트에는 이미 필터가 **B열 기점(B1:F)**으로 걸려 있었기 때문에, Field:=1은 A열이 아니라 B열=파일명에 적용되고 있었습니다. 즉, 이 코드가 올바른지 여부는 코드만으로 결정되는 것이 아니라, 현재 시트에 어떤 범위로 필터가 걸려 있는지에 따라 결정됩니다.

그래서 "실물을 보고 나서 말한다"는 방식이 효과가 있었다는 이야기입니다.

결과적으로 지적은 다음과 같이 이루어졌습니다 ── "버그가 아니다. 다만 기존 필터에 대한 암묵적인 의존성이므로, 누군가 필터를 해제하면 검색 결과가 조용히 0건이 된다. 범위를 명시하는 편이 좋다". 수정 후에는 AI가 스스로 그 검색 매크로를 실행하여 동일하게 1,773건이 나오는 것까지 확인한 뒤에야 "고쳐졌습니다"라고 말해왔습니다.

코드만 볼 수 있는 AI였다면, 정상적인 코드를 "버그"라고 판단하여 고치다가 진짜 버그를 만들었거나, 아무것도 깨닫지 못하고 그냥 지나쳤을 것입니다. "코드로서 올바른가"가 아니라 "실물과 정합성이 있는가"를 확인한 뒤에 말을 하게 된 것입니다. 코드 안의 Offset(0, 4)가 무엇을 가리키는지도 시트를 보면 한눈에 알 수 있습니다 (B열의 파일명에서 오른쪽으로 4칸 이동 = F열의 경로). 대화하는 것만으로 매크로가 고쳐지는, 그 "대화"의 내용이 이전과는 다르게 훨씬 깊어졌습니다.

충돌이 아니라 용도에 따른 구분입니다.

• 닫힌 파일을 확실하게 일괄 처리한다 → Excel MCP
• 열려 있는 통합 문서를 그 자리에서 보고, 만지고, 확인한다 → vba_manager.py

열려 있는 상태에서 조작하는 방식에는 대가도 따릅니다. 프로그램을 통한 변경은 Excel의 실행 취소 (Undo) 기록을 삭제합니다. 따라서 vba_manager의 편집 계열 명령은 기본적으로 저장하지 않습니다. Excel 화면에서 확인한 뒤, 괜찮으면 저장하고, 아니면 저장하지 않고 닫아서 변경 사항을 폐기할 수 있습니다. 실행 취소 (Undo)의 역할은 그런 방식으로 확보하고 있습니다.

사소한 부분이지만, 이번 업데이트에 함께 포함된 내용입니다.

• 치환 계열 명령은 실행 전에 자동으로 백업을 생성합니다 (통합 문서 전체 + 모듈 단위의 2단계 백업)
• .bas 파일의 문자 인코딩 사고 (CP932를 UTF-8로 덮어써서 일본어가 깨지는 현상)를 임포트 전에 기계적으로 감지하여 중단합니다.
• Excel이 실행되지 않은 상태에서 경로를 지정하면 자동화용 Excel이 새로 실행되지만, 이때는 애드인(Add-in)이나 PERSONAL.XLSB가 로드되지 않습니다. 평소처럼 사용하려면 수동으로 실행한 Excel을 사용해 주세요 (도구가 경고를 표시합니다).

사용법에 대한 자세한 내용은 README에 정리되어 있습니다. VBA 코드 관리만이 목적이라면 기존처럼 9개의 명령만으로 충분하며, 그 외의 기능들은 부수적인 것이므로 방해가 되지는 않을 것입니다.