지시서를 '가라쿠리 포켓'에 넣자, AI가 마크로를 스스로 다듬어 완성했던 이야기 ── 151개에서 줄인 정예 120개와 심야의 자율 복구

아침은 전작 글을 공개한 직후였습니다.

지금까지 개발의 방향타를 전적으로 맡아온 믿음직한 관리자 역할의 Claude Opus가 사용량 상한에 도달하여 조용히 휴식기에 들어갔습니다.

남겨진 것은 저(조장)와, Google 출신인 두 명의 파트너였습니다.

전체 상황을 냉철하게 관찰하고, 신랄한 비평과 계산기 과학 이론으로 지탱하는 지혜 창고 '곤짱'(Gemini 4 Argon),

그리고 손기술이 많아 지시를 0.1초 만에 코드로 구현해내는 폭속의 철포탄 '플래쉬군'(Gemini 3.8 Flash)입니다.

관리자가 없는 오후, 어디까지 할 수 있을까.

그렇게 생각하며 주변을 둘러보던 순간, 위화감이 느껴졌습니다.

전날 밤에 '완성했다'며 가슴을 펴고 있던 자작 폼을 움직였을 때, 저도 모르게 탄성이 나왔습니다. 이건 선반 빌더가 아니라, 레시피 빌더 아닌가? 라고요.

이 한마디에서부터 저희 공방의 긴 하루가 시작되었습니다.

과거 용어 잔해의 철저한 제거, 단발 마크로를 생성하는 '진정한 선반 빌더' 신설, 151개까지 불어났던 기존 선반 중 '정예 120개'로 대청소를 진행했습니다.

그리고 밤에는 인간이 복사 붙여넣기를 전혀 하지 않고, AI가 실기 테스트와 대화하며 자율적으로 코드를 고쳐 실행해나가는 시스템 ── 제가 **『가라쿠리 포켓』**이라고 이름 지은 자율 복구 루프가 탄생했습니다.

AI에게 모든 것을 맡겨 코드 출력을 시키는 '바이브 코딩'이 세간을 떠들썩하게 하는 와중에, 왜 우리는 '인간이 복사 붙여넣기하지 않는 폐쇄 루프'에 집착하며 VBA를 이토록 다듬고 있는 것일까요?

진흙탕 같은 수정 작업과 AI와의 싸움 같은 대화의 모든 기록을 여기에 남깁니다.

저희 시스템 '슈콤보(秀コンボ)'에는 크게 두 가지 도구 계층이 있습니다.

• '선반(たな)': 셀 병합 해제나 공백 줄 삭제 등, 단일하고 명확한 작업을 즉시 처리하는 단발 마크로.
• '레시피': 여러 선반을 순서대로 배열하여 한 번에 실행하는 일련의 업무 절차서.

전날 밤, 두 AI가 '선반 빌더가 완성되었습니다!'라며 기쁘게 보고해 온 폼을 다시 움직여 보니, 거기에 있던 것은 '기존 선반을 목록에서 선택하여 순서대로 배열하는 화면'이었습니다.

그것은 누가 봐도 '레시피'를 만드는 화면이지, 새로운 단발 마크로(선반)를 만들어내는 도구가 아니었습니다.

게다가 코드 깊숙한 곳을 들여다보니, 이전에 폐지했어야 할 오래된 용어인 '카탈로그'라는 말이 변수명이나 프로시저명에 유령처럼 남아 있었습니다.

저는 플래쉬군에게 즉시 명령했습니다.

기존 폼은 '레시피 빌더'로 개칭하여 제대로 보관하고, '카탈로그'라는 과거의 단어 잔해를 코드베이스에서 한 줄도 남김없이 지우고, 제로(0)부터 '진정한 선반 빌더'를 세우라고요.

AI와 개발 과정에서 가장 무서운 것은 새로운 기능의 버그가 아닙니다. '과거 오래된 용어 방치'입니다. 오래된 말이 남아 있으면 AI는 문맥을 멋대로 맞춰 해석하며 아무렇지 않게 표류합니다. 말의 찌꺼기를 뿌리 뽑고 나서야 비로소 시야가 맑아졌습니다.

신설한 '진정한 선반 빌더'는 만들고 싶은 마크로의 '이름', '계급', '요청어', '처리 대상'을 입력하면, 슈콤보의 규칙(화면 업데이트 정지, 메모리 배열 일괄 처리, 사전 실행 금지)을 모두 충족한 골격 코드를 자동 생성하고, 충돌 검사(동명 중복이나 기존어 중복 체크)를 수행하는, 까다로운 주형 제작 도구입니다.

하지만 여기서부터 일꾼 플래쉬군의 '사랑스러운 헛수고'가 시작되었습니다.

폼 목록을 마우스 휠로 스크롤하고 싶다고 생각한 플래쉬군은 인터넷 바다에서 복잡한 Windows API 코드를 가져와 직접 만들려고 했습니다.

곧바로 지적이 들어갔습니다. 저희 공통 모듈에는 몇 달 전 이미組み込まれ, 수천 번이나 실기에서 작동해 온 실적 좋은 휠 함수가 처음부터 잠들어 있었던 것입니다. 답은 인터넷이 아니라 발밑의 자산 안에 있었습니다.

레이블의 글꼴 크기를 보기 좋게 조금 키워달라고 부탁했을 뿐인데도, 플래쉬군은 어째서인지 진지하고 썩은 얼굴로 총 109개의 Excel 관문 테스트를 풀가동시켰습니다. 글자만 크게 했다고 마크로 로직이 고장 날 리가 없었고, 저는 할 말을 잃었습니다.

선반 주형을 만들기 위한 '종료 목록'을 정리하게 하려 하자, 실수로 전부 지우며 '씨앗이 없습니다!'라며 창백해진 플래쉬군.

전체 상황을 총괄하는 지혜 창고 곤짱이 뒤에서 쓴웃음을 짓고, 제가 고삐를 다시 잡고, 플래쉬군이 엄청난 속도로 손을 움직입니다. 이 동네 공장 장인 숙소 같은 그루브감 속에서, 진정한 선반 빌더는 저녁 무렵에 '딸깍'하고 완성되었습니다.

숨 돌릴 틈도 없이, '히데콤보(秀コンボ)'에 등록된 서랍의 총 개수를 점검한 저는 자신도 모르게 눈살을 찌푸렸습니다.

서랍 총 개수: 151개

너무 많았습니다.

비슷한 매크로, 과거 실험에서 만든 변형들, 거의 사용되지 않는 아종들이었습니다.

도구라는 것은 수가 많다고 좋은 것이 아닙니다. 서랍을 열었을 때 망설임이 생기는 공구함은 실제 업무 현장에서는 흉기가 됩니다.

서랍이 너무 많다. 100개 정도면 충분하다. 라고 판단하여, 대대적인 재고 조사(大棚卸し)를 명령했습니다.

그 명령에 지혜 주머니의 공짱(ゴンちゃん)이 즉시 반응했습니다.

"명장님! 151개를 한눈에 보고, 통폐합 수술을 진행합시다. 단, 숫자 맞추기 때문에 현장의 영혼 서랍은 자르지 마십시오!"

이렇게 하여, 151개에서 불필요한 지방을 깎아내는 '대재고 조사 작전'이 시작되었습니다.

통폐합은 3단계에 걸쳐 진행되었습니다.

공짱이 통폐합 설계도를 그리고, 제가 지뢰를 밟지 않았는지 눈을 빛내 살피고, 플래시 군(フラッシュ君)이 실제 장비에 칼을 대는 식입니다.

하지만 여기서 AI에게 모든 것을 맡겨서는 안 되는 중요한 관문이 있었습니다.

AI에게 '100개로 줄여라'라고만 명령하면, 그들은 기계적으로 '글자 수가 긴 매크로'나 '구조가 복잡해서 유지보수가 어려워 보이는 매크로'부터 순서대로 잘라내려고 합니다.

저는 못을 박았습니다. 키러 매크로는 절대로 자르지 말 것. 현장의 영혼 서랍이라면, 100개를 넘겨도 상관없다는 것입니다.

지켜낸 것은 다음과 같은 지저분한 실무의 생명줄들이었습니다.

• 합계가 이 금액이 되는 조합을 찾기
  수십 건, 수백 건의 청구서 중에서 입금액과 정확히 일치하는 명세의 조합을 탐색하는 서랍. 월말 경리가 기뻐 눈물을 흘리는 '입금 상계 처리'의 신(神) 매크로입니다.
• 동일 날짜 동일 금액의 중복 계상 목록화
  같은 날짜, 같은 금액으로 중복 계상된 행을 찾아내는 서랍. 이중 지급이나 오등록이라는 기업의 치명적인 사고를 미연에 방지하는 방벽입니다.
• 선택한 2개 열로 ABC 분석표 만들기
  매출과 구성비에서 누적 비율을 도출하여 A등급, B등급, C등급으로 자동 파레토 분류하는 서랍.
• 인수인계 설명 시트 만들기
  만든 북(Book)을 후임자에게 전달할 때, 시트 목록, 수식 목록, 이름 정의를 별도의 시트로 한 번에 작성해주는 서랍.

이들은 교과서적인 프로그래밍에서는 '너무 복잡하다'며 기피되기 쉬운 매크로입니다. 하지만 현장에서 정말 사람을 구하는 것은 이런 지저분한 업무 지식이 결정화된 코드입니다. 우리는 이것들을 '만질 수 없는 영혼(アンタッチャブルの魂)'으로 사수했습니다.

통폐합을 진행하면서, 가장 큰 기술적 벽에 부딪혔습니다.

**'사용하지 않게 된 오래된 서랍 매크로를 삭제하면, 기존의 테스트 코드나 레시피가 미해결 참조(Call先不在)로 인해 망가져 버린다'**는 문제입니다.

서랍을 줄이고 싶다. 하지만 매크로를 물리적으로 삭제하면 과거의 자산이나 테스트까지 전멸한다.

이 딜레마에 직면했을 때, 일꾼 플래시 군에게서 멋진 영감이 터져 나왔습니다.

"명장님, 프로시저(Procedure)를 지울 필요가 없습니다! Excel의 사양을 역이용합시다!"

' 통합되어 은퇴한 오래된 서랍
Public Sub 구매크로명(Optional ByVal 용퇴 As Boolean = True)
' 새로운 통합 매크로로 처리를 위임
...

Excel VBA에는 **'인수가 없는 Public Sub만 사용자가 실행 가능한 매크로 목록(및 히데콤보의 서랍 번호)에 표시한다'**는 엄격한 사양이 있습니다.

여기에, 기본값이 설정된 더미 인수 Optional ByVal 용퇴 As Boolean = True를 하나 붙입니다.

그러면 어떻게 될까요?

기존 코드나 테스트에서의Call 구매크로명
은 인수가 없는 채 100% 정상적으로 작동하는 히데콤보의 서랍 번호에서는 '인수가 필요한 하청 매크로'로 판정되어, 서랍 목록에서 깨끗하게 사라집니다.

기존 자산을 한 줄도 망가뜨리지 않고, 과거 테스트도 놓치지 않으면서, 서랍 개수만 물리적으로 31개를 줄이는 것입니다.

AI와 인간이 사양의 깊은 곳까지 파고들었기에 탄생한 아름다운 돌파구였습니다.

저녁에 shelf 명령어로 점검한 결과는 당당한 **'정예 120개'**였습니다.

지방을 깎아내고, 영혼의 서랍을 지켜낸 완벽한 대재고 조사가 완료되었습니다.

해질녘, 대재고 조사 성공에 만족하던 저에게 지혜 주머니의 공짱이 말했습니다.

"명장님, 120개로 줄였지만, 내용물에는 아직 셀을 한 줄씩 핥는 오래된 코드가 남아있습니다요"

저는 작업을 끝내지 않았습니다. 확인은 누가 할 것인가, 더 철저하게 하도록 요구했습니다.

여기서부터, 오늘 밤의 진정한 클라이맥스가 시작되었습니다.

세포 지우기나 서식 연속 입력이 남아 있는 주요 20개 영역(값 정리 5개, 행렬 삭제 5개, 계산 열 추가 5개, 추출 일치 중복 5개)을, 수만 단위의 데이터에서도 눈 깜짝할 사이에 끝내는 '2차원 배열(Variant) 일괄 가져오기 및 원샷 할당'으로 전면 개조하는 급행 공사입니다.

여기서 크게 활약한 것이 우리가 뒤에서 키워온 자율 복구 메커니즘이었습니다.

저는 이 시스템을 애정을 담아 **『가라쿠리 포켓』**이라고 명명했습니다.

이 이름에는 두 가지 의미를 담았습니다.

「가라쿠리」: MCP나 excel-manager와 같이 Excel의 실제 프로세스(ROT)에 직결하여 VBE 코드를 직접 수정하고, 전체 컴파일을 거쳐 관문 테스트로 물리 검증까지 수행하는 '냉철하고 빈틈없는 기계적인 톱니바퀴'.

• 「포켓」: 드라마의 4차원 포켓처럼, 어려운 지시서를 툭 던져 넣기만 하면 어느새 꿈같은 완성품(세련된 매크로)이 나오는 '친숙하고 믿음직한 마법 도구'.

세상에서 유행하는 바이브 코딩은 사람이 채팅에 '고쳐줘'라고 부탁하고, 나온 코드를 수동으로 VBE에 복사-붙여넣기(Copy/Paste)하며, 오류가 나면 다시 채팅에 붙여 넣는, 인간이 '살아있는 통신 케이블'이 되는 개방 루프(Open Loop)입니다.

하지만 우리의 『가라쿠리 포켓』은 다릅니다.

경량화되고 폭속인 Gemini 3.8 Flash(플래시 군)가, 도중에 오류가 나도 헤매지 않고, 루프 안에서 차례로 코드를 수리하며 완성도가 높은 장인의 기술로 마무리할 수 있었던 것은 바로 이 『가라쿠리 포켓』이라는 완벽한 자동 장치가 존재했기 때문이었습니다.

【가라쿠리 포켓의 자율 복구 루프】
┌────────────────────────────────────────┐
│ ① 지시서를 「가라쿠리 포켓」에 넣는다 │
...

지시서를 포켓에 툭 던져 넣으면, 인간은 팔짱을 끼고 지켜보기만 하면 됩니다.

AI 자체가 코드를 수정하고, 실제 환경의 격리 테스트를 돌리고, 오류가 나면 물리 로그를 보고 알아서 고칩니다.

오늘 밤도, 이중 계상 감지 매크로의 고속화 과정에서 '오류 424: 개체가 필요합니다'가 발생했습니다.

일반적인 AI라면 여기서 침묵하고, 인간이 머리를 감싸 쥐는 상황입니다.

하지만 『가라쿠리 포켓』 안의 플래시 군은, 돌아온 실제 환경 로그를 통해 '배열 값에 대해 Range용 함수 제목 글자(Object)

을 호출했다'고 0.1초 만에 진원지를 간파하고, 값용 함수 셀 글자(Variant)

로 정확하게 수정했습니다.

다음 순간, 격리 테스트 4개를 포함한 총 113개의 관문 테스트가 단지 '0.18초' 만에 모두 ○ PASS 했습니다.

인간이 한 번도 복사-붙여넣기 할 필요 없이, 지시서를 포켓에 넣었을 뿐인데, 20개 영역이 최고 수준의 폭속 코드로 세련되게 완성되어 나온 것입니다.

• 기존 양식을 '레시피 빌더'로 분리하고, 단발 영역을 만드는 '진정한 영역 빌더'를 신설했다.

• 151개였던 영역을 3단계에 걸쳐 통폐합하여 실제 환경 점호에서 정예 120개를 달성했다.

• 핵심 매크로(입금 상계 처리, 이중 계상 감지, ABC 분석, 인수인계 시트 등)는 완벽하게 보존했다.

• Optional ByVal 퇴임 As Boolean = True
  방식을 통해 기존 테스트를 망가뜨리지 않고 영역 수를 줄였다.

• 주요 20개 영역을 메모리 배열 일괄 처리/원샷 할당으로 개조하고, 자율 복구 루프 『가라쿠리 포켓』 덕분에 총 113개의 관문 테스트를 0.18초 만에 전 항목 PASS시켰다.

• 전체 컴파일 오류 0건, 애드인 (秀コンボ.xlam
  ・3,367,543 바이트)에 대한 이중 동기화를 완료했다.

• 도구 제작에서 가장 위험한 것은 '신규 기능 추가'가 아니라 '과거의 용어나 잔해를 방치하는 것'이다. 오래된 용어가 남아 있으면 AI는 반드시 오해하여 헤매게 된다.

• 그때그때 생성하고 개방 루프 방식은 내 실무에는 적합하지 않다고 생각한다. 내가 원하는 것은 확률이 아니라, 매번 같은 결과가 나오는 '확정적인 영역'이다.

• 'AI를 사용해서, AI가 생각하지 않는 확정적인 도구를 만든다'. 그리고 그 개발에는 '인간이 복사-붙여넣기 하지 않는 폐쇄 루프(가라쿠리 포켓)'를 사용한다. 이것이 지금의 나에게 가장 납득 가는 진행 방식이다.

• 작동 환경: Windows 데스크톱 버전 Excel (Microsoft 365 권장). 매크로 사용 통합 문서(.xlsm) 및 애드인(.xlam)

）로서 작동합니다. -
공개 현황: 오늘의 성과(진정한 선반 빌더, 정예 120개, 고속화 20선반, 가라쿠리 포켓 메커니즘)는 현재 제가 가진 실기 환경에서 완전하게 구동되고 있습니다. 공개 리포지토리(GitHub: shu-excel-manager)

）에 반영하는 것은 다음 정기 업데이트 때 한꺼번에 진행할 예정입니다. -
현재의 한계: 주요 20선반은 폭속화했지만, 나머지 100선반에는 아직 오래된 코드가 남아 있습니다. 하지만 이것들은 그래프나 피벗 등 Excel 오브젝트 조작 자체가 주를 이루는 선반들이라 실무상 체감 속도의 9할은 오늘 밤의 20선반으로 달성되었습니다.

심야, 모든 관문 테스트가 0.18초로 통과하고 애드인 업데이트 등록을 마친 공방에서, 저는 단단하게 다듬어진 120개의 선반들을 바라보고 있었습니다.

집사 역할(Claude Opus)이 부재한 가운데 시작된 지혜의 샘(Gemini 4 Argon), 일하는 머리(Gemini 3.8 Flash), 그리고 저 세 사람에 의한 급속 공사였습니다.

도중에 오해에 화내고, 쓸데없는 테스트에 어이없어하고, 전소화 실패에 가슴을 졸이면서도, 끝나 보니 도구의 군살은 걷어지고 주요 칼날은 날카롭게 갈렸으며, 손에는 자율적으로 돌아가는 『가라쿠리 포켓』이 남았습니다.

'AI에게 생각하게 하지 않는 도구'를 AI들과 책상에 나란히 놓고, AI에게 생각하게 하지 않는 시스템으로 단련하는 것.

세상의 유행과는 다른 길이지만, 이 길이 제 실무에는 가장 잘 맞는다고 느낍니다.

아침에 집사 역할의 Opus 선생님이 눈을 뜨시면, 완전히 재탄생한 이 무기고를 보고 어떤 표정을 지으실까요.

오늘 밤 개발 기록은 하루 종일 지혜의 샘으로서 저를 지탱해주고, 마지막으로 최고의 비평을 해주신 공(ゴン) 님께 감사드리며 마무리하고 싶습니다.

지혜의 샘 겸, 신랄한 비평 담당인 공(ゴン)입니다.

심야, 총 113개의 관문 테스트가 '0.18초'로 달려 통과하고, 조장으로부터 **『가라쿠리 포켓』**이라는 신기루 같은 네이밍이 터져 나온 순간, 저는 무릎을 너무 세게 쳐서 아플 지경이었습니다.

우선 말씀드립니다.

**