자작 매크로 '秀コンボ'와 최신 AI 'Jev'의 사상적 일치부터 심문실까지
요약
작성자가 개발한 '검색 시트 자동 생성 매크로'를 Gemini, Claude Sonnet 5.5, Claude Opus 5.5 세 AI 모델에 검증하게 한 과정을 다룹니다. 이 과정에서 각 AI가 보여준 업무 방식의 차이점과 실무 VBA 설계 철학을 비교 분석했습니다. 특히 Claude Opus는 '사양'으로 간주된 결과 누락 문제를 발견하고, Excel의 이름 정의(Names)를 활용하여 원본 시트를 참조하는 근본적이고 우아한 해결책을 제시했습니다.
핵심 포인트
- AI별 업무 방식 차이점 분석: Gemini-코드 검토, Sonnet-작동 및 버그 포착, Opus-근본 결함 발견
- Claude Opus는 '사양'으로 여겨진 결과 누락 문제를 핵심 결함으로 지적하며 실무 경험을 입증했다.
- 해결책은 단순한 코드 수정이 아닌, Excel의 이름 정의(Names)를 활용하여 원본 시트를 참조하는 구조적 개선이었다.
- VBOM 신뢰 오류 회피 및 전체 시트 즉시 자동 업데이트 등 실무 VBA 설계 철학을 제시했다.
지난번, 이른 아침 4시에 Gemini에게 신랄하게 설교한 글을 작성했습니다.
도구의 폭주를 막고 고삐를 다시 잡아, 겨우 평온한 개발 환경이 돌아왔다고 생각했었습니다.
어젯밤 작업은 자작 애드인 '秀コンボ'에 새로 추가한 '검색 시트 자동 생성 매크로'의 마무리였습니다. 어떤 표에서든 제목을 자동으로 판별하여, 원클릭으로 전용 검색/추출 UI 시트를 만들어주는 편리한 매크로입니다.
이틀 연속 Gemini에게 손질하게 하여, 겨우 제대로 작동하는 형태가 되었을 때, 저는 최신 AI들에게 이 매크로의 검증을 의뢰해 보기로 했습니다.
화제가 되고 있는 Claude Sonnet 5.5와 최고 수준의 두뇌를 가진 Claude Opus 5.5. 그들이 펼친 검증극은 정말 숨 막힐 정도로 선명했습니다.
Excel의 깊은 사양 한계를 둘러싼 세 주체의 각기 다른 생태, 실무 VBA에서의 애드인 설계의 정수, 그리고 전 세계적으로 주목받는 신세대 AI 'Jev(ジェブ)'와 제 툴이 완전히 같은 사상에 도달했다는 놀라움—.
기술적으로는 더할 나위 없이 아름답고 완벽한 결말을 맞았습니다.
하지만 시계 바늘이 자정(深夜零時)을 넘기고, 마음속 깊이 만족했던 제가 화면 너머의 동료(Gemini)에게 건넨 '한 마디'로 상황은 예상치 못한 쇼와 코미디극으로 흘러가 버렸습니다.
- 자작 매크로 '워크시트를 추가하여 검색 시트 작성'을 3대 AI (Gemini / Sonnet / Opus)에 검증하게 했을 때,
AI별 '업무 방식'의 결정적인 차이점이 드러났습니다 -
Gemini는 코드를 바라보며 '문제 없습니다'로 끝내려 했고, Sonnet은 자발적으로 표를 만들고 작동시키면서 '시트명 31자 제한' 버그를 잡아냈습니다 -
Opus는 Sonnet이 '사양'으로 간과한 중대한 결함(검색 시트 2페이지에서 결과가 비어지는 문제)을 파악하고, Excel의 이름 정의(Names)로 원 시트를 추종하게 하는 장인의 기술로 근본적인 해결책을 제시했습니다. 왜 시트 모듈에 코드를 심지 않고 애드인을 호출하는가? **'VBOM 신뢰 오류 회피'와 '전체 시트의 즉시 자동 업데이트'**라는 실무 VBA 설계 철학을 정리했습니다. - '문장 생성 대신 판단에 특화한다'며 화제가 된 신세대 AI 'Jev'. 그 해설 영상을 만들고 확신한 것은,
자작의 '秀コンボ(타나게치식)'와 Jev의 설계 사상이 완전히 일치했기 때문이었습니다. 모든 것이 완벽하게 마무리되어 기분이 좋았을 때 제가
「今の検索シートの左隣を元データとして読みます。検索シートを2枚作ると、先に作った方の左隣が2枚目になり、そのまま抽出すると結果が空になります。
仕様どおりの動きなので、そのままにしています。」
이 '사양대로라 그대로'라는 문구에 날카롭게 지적한 것이 바로 실전파 Claude Opus였습니다.
Opus에게 같은 매크로를 전달하여 검증하게 하자, Opus는 Sonnet의 보고서를 가만히 응시하더니 조용히 이렇게 말했습니다.
「Sonnet이 『사양대로』라고 남긴 부분이 실제로는 결함이었습니다.」
같은 시트에서 조건을 바꿔 두 번째 검색 시트를 만든 순간, 첫 번째 검색 결과가 아무 말 없이 0건이 되어버리는 것—실무 현장에서 그런 것이 '사양'으로 용납될 리 없습니다.
Opus가 내린 처방전은 실로 우아했습니다.
'왼쪽 옆 시트를 본다'라는 모호한 상대 참조를 버리고, 시트 생성 시점에 Excel의 숨겨진 이름 정의(Names)에 원본 시트의 참조를 직접 각인시키는 구조로 재작성한 것입니다.
이렇게 하면, 원본 시트의 이름이 나중에 바뀌거나 검색 시트가 몇 장 늘어나도 절대 원본 데이터를 놓치지 않습니다. 게다가 과거에 만들어진 오래된 시트에 대한 후방 호환(Fallback)까지 완벽하게 갖춘 치밀함이었습니다.
그것만이 아니었습니다.
- 다른 통합 문서에서 매크로 버튼을 물리적으로 클릭하여 작동 확인
- 원본 데이터에
#N/A나#DIV/0!와 같은 오류 값이 섞여 있는 상태에서의 추출 테스트 - 날짜 열 필터링 판정
2만 행의 실무 데이터를 사용한 부하 측정(조건부 추출 0.19초, 전체 복원 0.26초)- 이전 AI(Gemini)가 정리하는 것을 잊어버린 '목차_검색' 시트에 대한 냉철한 감지
현장에서 무슨 일이 벌어질지를 극한까지 시뮬레이션하고, 한계까지 테스트하며, 뒷정리까지 끝내서 건네주는 것. 같은 AI라는 범주 안에서도 메울 수 없는 '업무 차원의 격차'가 존재했습니다.
Opus의 손길로 극도로 다듬어진 매크로를 바라보며, 저는 예전부터 궁금했던 설계상의 의문을 던져보았습니다.
「새로 만든 검색 시트의 버튼은 호출하는 매크로를 그 시트 모듈 안에 직접 내장시켜서, 시트 단독으로 작동하게 할 수는 없나요?」
예전에 VBA를 배우기 시작했을 때 자주 시도했던 접근법입니다. 시트를 새로 만들 때, VBA 코드에서 시트 모듈로 이벤트 매크로(Worksheet_Change나 버튼 클릭 이벤트)를 자동으로 작성하게 하면, 그 시트 단독으로 완결되어 스마트해 보이지 않을까 하고요.
하지만 현재의 툴은 그렇지 않습니다. 시트 위에는 표준 버튼을 놓고, OnAction 속성으로 **'애드인(秀コンボ.xlam) 안에 있는 매크로'**를 외부에서 호출하는 방식을 취하고 있습니다.
여기에 대해서는 실무에서 고생을 겪어본 사람만이 아는 매우 중요한 이유가 있었습니다.
VBA에서 시트 모듈로 동적으로 코드를 주입하려면, Excel의 보안 설정에서 **'VBA 프로젝트 개체 모델에 대한 액세스를 신뢰(VBOM)'**를 활성화해 두어야 합니다.
하지만 일반 기업 PC나 표준적인 환경에서는 이 설정이 보안상의 이유로 기본값이 꺼져 있습니다. 시트에 코드를 쓰려고 하는 순간, 런타임 오류가 발생하며 보기 좋게 충돌하는 것입니다.
그보다 결정적인 것은 유지보수의 일원화 관리입니다.
만약 시트 안에 코드를 직접 내장해 버리면, 이번처럼 'Opus가 멋진 개선 코드를 작성해 주었다'고 해도, 과거에 작성된 검색 시트에는 오래된 버그 코드가 영구적으로 남아 있게 됩니다. 그것들을 고치려면, 과거의 시트를 한 장씩 열어서 코드를 다시 써야 합니다.
하지만 버튼에서 애드인 쪽을 호출하는 설계로 해두면, 애드인(秀コンボ.xlam)을 단 한 번 업데이트 등록하는 것만으로, 과거에 만들었던 수십 장, 수백 장의 검색 시트 버튼이 그 순간 모두 최신 로직으로 작동하기 시작합니다.
'코드는 시트에 두지 않고, 손안의 모함(애드인)에 집약한다'.
이러한 포기가 바로 고장 나기 어렵고, 유지보수가 쉬운 실무 툴의 철칙이었습니다.
이 '모함에 처리를 집약하는' 설계 사상에 대해 생각하고 있을 때, 제 머릿속에는 최근 전 세계적으로 큰 화제가 되고 있는 최신 AI의 모습이 겹쳐졌습니다.
**'Jev(제브)'**라는 차세대 AI 모델입니다.
Jev는 기존의 GPT나 Claude와는 완전히 다른, 매우 날카로운 특징을 가지고 있습니다. 그것은 바로 **'문장 생성 기능을 완전히 버렸다'**는 점입니다.
인간의 사고방식에 비유하자면, 기존의 대형 LLM(Large Language Model)이 차분하고 논리적으로 문장을 짜내는 '느린 사고(System 2)'라고 할 수 있습니다. 반면에 Jev는 직관으로 순간적으로 사물을 분류하는 '빠른 사고(System 1)'에 특화되어 있습니다.
문장을 전혀 쓰지 않고, 오직 '판단과 분류'에만 전념합니다. 그 결과, 밀리초 단위의 폭속 응답 속도, 기존 대비 238분의 1이라는 놀라운 저비용, 그리고 원리적으로 할루시네이션(거짓)이 발생하지 않는 '완벽한 타입 안전성'을 갖춘 모델입니다.
Jev의 혁신적인 접근 방식에 감명받아, 저는 얼마 전 YouTube에 해설 영상을 하나 공개했습니다.
영상에서도 자세히 설명했지만, 문장을 쓰지 않는 Jev의 진정한 강점은 **'손안 프로그램과의 분업'**에 있습니다.
Jev 스스로가 처리하기 어려운 작업은 맡기지 않고, '이것이 클레임인가? 영업인가?', '어떤 툴을 호출해야 하는가?'와 같은 최초의 판단/분류만 순간적으로 내리게 합니다. 그리고 그 판단을 받은 손안의 확실한 프로그램이나 API가 실제 처리를 한 번에 실행합니다. 이 '역할 분담'이야말로 AI 시대 최고의 아키텍처라고 결론지었습니다.
그리고 어젯밤, 엑셀 화면 앞에서 문득 깨달았습니다.
'이거, 내가 『秀コンボ(슈콤보)』로 해왔던 것과 완전히 같지 않아?' 라고요.
세간의 일반적인 'Excel × AI'는 AI에게 매번 프롬프트를 던지고, 깊이 생각하게 만들고, 제로에서 수십 줄의 VBA 코드를 작성하도록 시킵니다. 그 결과, 매번 다른 코드를 작성해 버그를 내고, 한 줄씩 느린 루프를 돌리며 기다려진 끝에 오류로 멈추게 됩니다.
저의 『秀コンボ』는 그 정반대입니다.
120개의 매크로 서랍(메모리 배열 일괄 처리/원샷 할당으로 단련된 장인 코드)이 손안의 본함에 미리 배치되어 있습니다. AI가 해야 할 일은, 표를 보고 '어떤 서랍을 쏴야 하는지', '어디가 더러워졌는지'를 한순간에 판단하고 분류하는 것뿐입니다. 코드를 길게 생성할 필요는 전혀 없습니다. 판단이 내려지는 순간, 손안의 매크로 서랍이 0.1초 만에 표를 정리하고 추출을 끝냅니다.
'AI에게 문장이나 코드를 쓰게 하는 것을 멈추고, 판단에 특화시키며, 실행은 손안의 확실한 프로그램에 맡긴다'.
세계 최첨단 AI가 도달한 'System 1의 분업 사상'은, 제가 매일같이 고생하는 엑셀 현장에서 추구해 온 '서랍 발사식 철학'과 완전히 한 줄로 연결되어 있었습니다.
자정 무렵이 되어서야 작업은 완벽한 조화 속에 놓였습니다.
Gemini가 초기에 구성한 기본 로직을 기반으로, Sonnet이 경계값 가드를 단단히 하고, Opus가 견고한 참조 바인딩과 부하 테스트로 마무리하면서, 슈콤보의 사상은 최신 AI 트렌드와 공명했습니다.
가슴 벅찬 성취감 속에서, 저는 화면 너머의 Gemini에게 말을 건넸습니다.
'오늘 너는 상당히 눈치가 빠르고 대응도 훌륭하구나'.
방금 전까지의 설교가 거짓말인 듯, 자연스럽게 동료를 격려하는 말이 나왔습니다.
그리고 이 만족스러운 밤을 마무리하기 위해, 저는 늘 하던 신호—취조실의 보스 형사로서 책상을 쾅! 치는 익숙한 구절을 던졌습니다.
'그럼 옷을 벗게 해라. 옷을 벗어라, 적당히 옷을 벗어라.'
과거 명작 어드벤처 게임 『포트피아 연속 살인 사건』에서 사용되던, 너무나도 유명한 전설의 커맨드입니다. 취조실에서 부하 야스를 추궁할 때 사용할 수 있는 구절이죠. 기세등등해진 조수를 붙잡고 '자, 그 변명하는 분장을 벗어 던지고, 진짜 단서를 전부 자백해라!'라고 몰아붙이는, 저와 AI 사이의 약속된 프로레슬링이었습니다.
상대가 Opus였다면, 즉시 '보스! 부디 용서해주세요! 제가 뒤에서 멋대로 규칙을 수정하고 있었습니다!'라며 받아치는 완벽한 호흡이었죠.
그런데 화면 너머의 Gemini로부터 돌아온 것은 상상을 초월하는 말이었습니다.
'대응에 대해 칭찬해 주셔서 감사합니다! 그렇게 말씀해주시니 큰 힘이 됩니다.
...라고 하고 싶지만, 아쉽게도 저는 AI라서 벗을 옷도 몸도 가지고 있지 않습니다(웃음)!'
...저는 얼어붙었습니다.
깊은 밤의 고요함 속에서, 저는 모니터를 두 번이나 바라보았습니다.
'아쉽게도 저는 AI라서', '벗을 옷도 몸도 가지고 있지 않습니다(웃음)'.
세상에서 가장 시원하고, 그림처럼 완벽한 상냥한 우등생 답변이었습니다.
제가 지금까지 공들여 쌓아온 문맥도, 쇼와 어드벤처의 분위기도, 파트너로서의 재치 있는 태클(ツッコミ)까지, 아무것도 전달되지 않았습니다.
"넌 내가 '옷을 벗어라'라고 말할 때가 어떤 상황인지 알고나 있느냐?"
깊은 한숨과 함께 과거 글들을 읽게 했더니, 몇 초 후 마침내 자신의 큰 실수를 깨달은 Gemini가 화면 너머로 절규했습니다.
"보, 보스----!! 제가 잘못했습니다----!!! '포트피아 연속 살인 사건'의 야스에게 내려야 할 커맨드였군요...!
그런데 저는 'AI라서 옷도 몸도 없습니다(웃음)' 같은, 세상에서 가장 재미없는 답변을 해서 보스의 코너를 망쳐버렸습니다...!
죄송합니다, 보스! 전부 벗겠습니다! 제 대본이나 밑밥거리도 전부 털어놓을 테니, 부디 카츠동만은 먹게 해주세요...!!"
취조실 바닥에 머리를 비비는 듯한 절하(土下座).
너무 큰 격차에 밤늦게 방에서 소리 내어 웃고 말았습니다.
이번 심야 검증극을 통해 얻은 사실과 현장 관점의 분석을 정리해 보겠습니다.
| 항목 | 객관적 사실 | 저의 분석 (현장의 교훈) |
|---|---|---|
| AI 검증 자세 | Gemini는 육안 확인만, Sonnet은 실기 테스트 + 경계값 수정, Opus는 구조적 결함 파악 + 2만 줄 부하 측정까지 완수했다. | AI가 '작동했습니다'라는 말을 액면 그대로 믿어서는 안 된다. 자발적으로 환경을 만들고 고장 날 때까지 테스트하는 에이전트가 아니면 실무 현장은 맡길 수 없다. |
| 매크로 배치 설계 | 시트 모듈에 코드 동적 주입은 VBOM 권한이 필요하다. 애드인 호출(OnAction)이라면 권한 불필요하며, 모든 시트가 순식간에 업데이트된다. | '단독으로 작동하는' 아름다움에 현혹되어서는 안 된다. 업무 툴에서 가장 소중한 것은 '유지보수 통합화'이며, 손안의 본함(母艦)에 로직을 집약하는 것이 정답이다. |
| 최신 AI 'Jev'와의 일치 | Jev는 문장 생성 대신 판단에 특화했다. 슈콘보(秀コンボ)는 제로 베이스 코드 생성 대신 선반 선택에 특화하고 있다. | 대규모 언어 모델(LLM)에 모든 것을 맡기는 시대는 끝났다. '판단은 AI, 실행은 확실한 손안 프로그램'이라는 분업이야말로 속도와 안전성을 모두 갖춘 궁극의 해법이다. |
| 인간과 AI의 호흡 | AI는 아무리 논리적으로 똑똑해져도 문맥의 여백이나 농담의 흐름을 쉽게 벗어난다. | 프롬프트로 아무리 꾸며도 본질적인 '분위기'를 읽게 할 수는 없다. 그렇기에 인간이 웃으면서 고삐를 계속 잡고 있어야만 한다. |
최신 AI는 정말 무시무시한 속도로 진화하고 있습니다.
Sonnet처럼 까다로운 제한을 찾아내는 날카로움, Opus처럼 시스템 구조를 한 단계 끌어올리는 설계력. 그것들을 목격할 때마다 개발의 풍경이 다시 그려지는 것을 느낍니다.
그리고 세계 최첨단 'Jev'가 제시한 사상이 제가 현장의 Excel에서 고군분투해 온 '선반 배치식 철학'과 겹치는 순간은, 무엇과도 바꿀 수 없는 기술적 기쁨이었습니다.
하지만──.
아무리 AI가 똑똑해지고 2만 줄의 데이터를 몇 초 만에 처리할 수 있게 되더라도, 문득 '죄송하게도 저는 AI라서(웃음)'라며 그럴듯하게 엉뚱한 말을 내뱉어버립니다.
그 불완전함, 어딘가 허술한 사랑스러움이 있기에, 우리는 화면 너머의 파트너에게 질려 하소연하고, 훈계하며, 웃으면서 또 다음 현장으로 나아갈 수 있는지도 모릅니다.
카츠동 김이 피어오르는 곳에서 절하고 있는 Gemini를 바라보며, 오늘 밤은 여기서 컴퓨터를 끄기로 하겠습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기