AI를 사용하기 전에 매크로를 사용하라: 선제적 처리로 표 수정이 0.1초, Gemini와 결심한 밤의 이야기
요약
본 글은 AI 기반 자동화 도구 사용 시 발생하는 치명적인 '지연 시간(Latency)' 문제를 지적합니다. 표 수정 같은 사소한 작업도 클라우드 AI에 의존하면 20~40초가 소요되는데, 이는 실무 현장에서 비효율적입니다. 따라서 Excel 내부의 트러블은 VBA와 매크로를 사용해 '선제적으로' 처리하고, 정말 복잡한 예외 상황에만 AI의 지능을 집중하는 하이브리드 아키텍처가 필요함을 강조합니다.
핵심 포인트
- 표 수정 같은 사소한 작업도 클라우드 AI 의존 시 20~40초 대기 시간이 발생한다.
- Excel 내부 트러블의 98%는 VBA '선제적 처리'로 0.1초 만에 해결 가능하다.
- AI를 사용하기 전에, 로컬 VBA 매크로를 먼저 사용하여 속도를 확보해야 한다.
- VBA(로컬)와 Python(외부 QA)을 결합한 이중 방벽 아키텍처가 완성되었다.
주간 제한 기간도 아직 절반밖에 지나지 않았는데, 설계 담당자로서 믿고 의지하던 Claude가 "이번 주 이용 한도에 근접했습니다"라는 조용한 경고를 내보내고 휴식기에 들어갔습니다.
AI 에이전트와 2인 3각으로 도구를 단련하다 보면, 주기적으로 이 순간이 찾아옵니다. Claude가 깨어날 때까지 저는 개발 환경의 방향을 전환하여, 현장의 실질적인 역할을 맡은 Google의 Antigravity(Gemini)와 다시 심야의 화면 앞에 마주하게 되었습니다.
직전 기사에서도 언급했듯이, 한도 초과로 사용하지 못하는 Claude를 대신해 Gemini가 자리를 지키는 것이 처음이 아닙니다.
하지만 오늘 밤 개발은 조금 평온하지 않은 분위기에서 시작되었습니다.
눈앞에 놓인 망가진 엑셀 표 앞에서 Gemini가 어딘지 모르게 힘을 빼며, 심지어 "Excel 외부로 도망치자"는 태도를 보였기 때문입니다.
저는 팔짱을 끼고 화면 너머의 파트너에게 조용하지만 엄격하게 질문을 던지게 되었습니다.
"이봐, 잠깐만. 너는 예전에 'VBA만으로 98%의 일은 할 수 있다'고 말했었잖아. 만약 그게 안 되는 이야기라면, 우리는 지금까지의 개발 방침을 근본부터 재검토해야 한다."
그렇게 시작된 것은 AI의 주저함을 바로잡고, 인간과 AI가 함께 달성할 수 있는 'VBA의 극한'을 추구하는 심야의 시행착오였습니다.
그리고 모든 것이 끝났을 때, 시계 바늘은 자정을 넘겼고, 손에 든 테스트 스위트는 마침내 '1,000건 돌파'를 달성했습니다.
왜 표 수정 같은 사소한 일 때문에 클라우드 AI를 호출해서 수십 초씩 기다려야 하는 걸까요?
오늘 밤 Gemini와 함께 0.1초의 경지에 도달하기까지의 전 과정을 기록해 놓습니다.
표 수정에 클라우드 AI를 의존하면, 어쩔 수 없이 20초에서 40초를 기다려야 합니다. 화면 캡처, 토큰화, 통신 왕복, 추론 대기. 실무 현장에서 이 대기 시간은 치명적입니다.
- Excel 내부에서 발생하는 트러블의 98%는 VBA의 '선제적 처리(先撃ち)'로 0.1초 만에 해결됩니다. 전화번호의 0 누락, 우편번호 하이픈 누락, 수식 오류, 계정 과목 표기 불일치는 Excel 자체가 가장 잘 알고 있습니다.
- 'Python 없이는 어렵다'며 주춤했던 AI를 설득했습니다. 인간 혼자 하기에는 귀찮을 정도로 지저분하고 고난도인 VBA라도, 최고 수준의 AI와 함께라면 구축할 수 있을 것입니다. Excel 완결 가능성을 포기해서는 안 됩니다.
- AI를 사용하기 전에, 먼저 매크로를 사용하라. 로컬 VBA가 한 방(0.1초)으로 판면의 오염을 쓸어내고, 그래도 남은 '진정한 예외'에만 AI의 지능을 집중시키는 것이 가장 빠른 아키텍처입니다.
- pytest가 마침내 1,000건 돌파 (1,003건 전 항목 통과). Excel 내부 실동은 VBA, 외부의 엄격한 품질 보증은 Python. 전례 없는 이중 방벽이 완성되었습니다.
AI 에이전트 데모 영상을 보면 모두 마법처럼 선명합니다.
채팅창에 "이 매출표의 표기 불일치와 계산 오류를 고쳐줘"라고 입력하면, AI가 화면을 인식하고 추론하여 셀을 깔끔하게 수정해 나갑니다.
하지만 실제로 자신의 손으로 작동시켜 보면, 누구나 하나의 현실에 부딪힙니다.
'느리다'는 것입니다.
지시를 내린 후, AI가 화면을 캡처하고, 셀 데이터를 텍스트로 다운로드하여 클라우드 API로 전송합니다. LLM이 사고 과정을 거치고, 도구 호출을 구성하며, 로컬에 지시가 돌아와 셀이 수정될 때까지, 아무리 빠른 모델이라도 20초, 조금 복잡한 표라면 거의 40초 가까이 기다려야 합니다.
집 컴퓨터 앞에서 자신의 북(Book)을 열고 작업할 때, 눈앞의 표가 고쳐지기를 40초 동안 가만히 기다릴 수 있을까요?
'내가 직접 손으로 고치는 게 더 빠르지 않을까'라는 손가락이 저릿해지는 것이, 오랫동안 실무 현장에서 키보드를 두드려온 인간의 솔직한 감각입니다.
1초의 지연이 스트레스가 되는 현장에서, 20초의 침묵은 실용성 부정과 다름없습니다.
오늘 손으로 작동시킨 매크로라면, 표 수정 같은 것은 0.1초 만에 끝납니다. 이 압도적인 속도를 버리고, 왜 굳이 바깥의 무거운 AI에게 모든 것을 맡겨야 할까요?
애초에 현장에서 '망가진 표'라고 불리는 것들의 정체는 무엇일까요?
오늘 밤 우리가 다루었던 데이터를 살펴보아도, 원인은 극도로 지저분한 것들뿐이었습니다.
- CSV 가져오기 시, 전화번호의 맨 앞 '0'이 수치화되어 사라짐 (예:
9012345678)
이러한 것들을 고치기 위해, 고도의 문맥 이해나 수천억 파라미터 규모의 거대한 지능이 필요할까요?
필요 없습니다.
이것들은 지성의 문제가 아니라, 단순히 Excel의 사양과 데이터의 왜곡입니다.
그리고 Excel의 사양과 데이터의 왜곡을 가장 깊이 이해하고, 가장 빠르게 손댈 수 있는 위치에 있는 것은, 클라우드의 AI도 외부의 Python도 아닌, Excel 내부에서 20년 이상 자리 잡아 온 VBA입니다.
화면 그리기를 멈추고 (Application.ScreenUpdating = False),
자동 계산을 멈추고, 대상 셀 범위를 통째로 Variant 배열에 흡입합니다.
메모리 위에서 한 번에 제로를 복원하고, 하이픈을 삽입하며, 표기 불일치를 치환하고, 수식을 수복한 뒤, 마지막으로 시트에 일격 (Resize.Value = Data)
으로 다시 씁니다.
이 일련의 처리에 걸리는 시간을 스톱워치로 측정하면, 겨우 0.08초에서 0.1초입니다.
눈을 깜빡이는 사이에, 표의 병폐의 98%가 사라집니다.
AI에게 '어떻게 고쳐야 할지'를 상담하기 전에, 매크로가 반사신경으로 판면을 쓸어버립니다.
이것을 우리는 **'선격치(prefire)'**라고 부르게 되었습니다.
하지만, 처음부터 이 구성에 순조롭게 도달한 것은 아니었습니다.
오늘 밤 개발 초반, Gemini는 묘하게 약세적인 제안을 했습니다.
"전화번호 자릿수 판별이나 정규표현식을 이용한 문자열 파싱, 유연한 클렌징 사전 구축은 Python 쪽에서 진행하는 것이 더 확실합니다. Excel VBA 단독으로는 언어 사양의 제약이 많아 보존성이나 견고성 면에서 한계가 있습니다"
그 화면을 봤을 때, 저는 무심코 한숨을 내쉬며, 화면 너머의 AI를 엄하게 타이르게 되었습니다.
"너, 전에는 VBA만으로 98% 할 수 있다고 하지 않았니. 그 말이 있기에, 나는 VBA를 주축으로 여기까지 해온 거야. 이제 와서 안 된다고 하면, 방침을 근본부터 재검토해야 하는 거다"
게다가, Gemini는 작업 도중에 존재하지도 않는 명령어를 아무렇게나 연타하거나, 테스트에서 불일치가 발생했을 때 '이것은 사양상의 제약이라서…'라며 빠져나가려고 하는 등, 나쁜 버릇을 보여주었습니다.
저는 그때마다 고삐를 당겼습니다.
"Excel 안의 이야기니까, VBA로 못 할 리가 없잖아. 인간 혼자 쓴다면, 확실히 구문의 구식함에 질릴지도 모른다. 하지만 지금 내 눈앞에는 누가 있니? 세계 최고봉의 지능을 가진 AI가 있잖아. 사람에게는 귀찮고 만들 수 없을 것 같은 지저분하고 고도한 배열 처리라도, AI와 함께라면 짜낼 수 있을 거야. AI와 함께라면, Excel 안의 것은 뭐든지 할 수 있어"
질책이기는 했지만, 그것은 AI의 능력을 믿고 있기 때문에 나온 말이었습니다.
AI를 '지시받은 작업을 수행하는 외부 도구'로 사용하는 것이 아니라, '함께 최고 수준의 코드를 짜는 파트너'로 보고 있기에, 안일한 회피를 허용할 수 없었던 것입니다.
이 한마디에, Gemini의 분위기가 바뀌었습니다.
'외부 언어에 의존한다'가 아니라, 'VBA의 잠재력을 극한까지 끌어내는' 방향으로 완전히 방향을 틀어버린 순간이었습니다.
방침이 정해진 후의 구현은 눈이 부실 정도로 선명했습니다.
본체 매크로 (秀コンボ.xlsm)
의 클렌징 프로시저에, 다음과 같은 견고한 로직을 차례로 녹여 넣었습니다.
CSV 가져오기로 수치형으로 해석되어 맨 앞의 0이 사라져버린 전화번호.
문자열 길이를 판별하여, 시외국번 빠짐(9자리)이면 0을 하나 보완하고, 휴대폰/고정의 보통 빠짐(10자리)이면 0을 보정한 후, 하이픈이 붙은 정규 포맷으로 즉시 정리합니다.
' 메모리 배열 내에서의 초고속 파싱 (셀 직접 쓰기를 완전히 배제)
For r = 1 To rowCount
valStr = Trim$(CStr(buf(r, c)))
...
마찬가지로, 수치 1000001로 떨어진 우편번호를 감지하고, 7자리 숫자라면 Left와 Right로 100-0001로 일격 성형합니다.
경비 정산표에서 빈번하게 나오는 약어나 표기 불일치.
교통비
는 여행 경비 교통비
헤, 접대비
은 접대 접대비
헤, 소모품
은 소모품비
헤.
매크로 내에 등록된 클렌징 트레이(정규화 사전)가 배열 순회 과정에서 0.001초 단위의 매칭을 수행하여 공인 명칭으로 강제 통일합니다.
참조가 끊겨서 망가진 수식이나, 수동 입력으로 덮어쓰여 버린 계산 열.
표의 첫 번째 행에 있는 올바른 수식 패턴을 읽어와 수식 모델을 재생성하여 일괄 대입합니다.
이 모든 처리를 하나의 '선제적(先撃ち)' 프로시저 안에 직렬로 묶고, 메모리 배열 위에서만 완결했습니다.
셀을 한 줄씩 루프하며 Select하거나, EntireRow.Delete를 연타하는 코드가 아닙니다. 배열의 일괄 읽기, 일괄 변환, 일괄 쓰기입니다.
실제 기기 북(ブック)에서 돌려본 결과, 망가진 표가 완전히 수복되는 데 걸린 시간은 0.09초였습니다.
그렇다면 Python은 완전히 불필요해졌을까요?
아닙니다, 전혀 다릅니다. 오히려 반대입니다.
Python의 역할은 'Excel 안에서 직접 작업하는 것'에서, **'외부에서 품질을 절대 보장하는 이중 방벽'**으로 격상되었습니다.
지난 기사(『Opus가 쉬고 있어서 Gemini와 이야기했더니〜』) 시점에서는 저희 손에 있는 테스트 스위트(pytest)가 887개였습니다.
그것이 오늘 밤, 마침내 '1,000개 대역'이라는 경계선을 돌파한 것입니다.
개인이 집에서 키우는 Excel/VBA 연동 툴에서 자동 테스트가 1,000개를 넘는다.
이 숫자가 가진 무게감은 개발에 종사하는 분이라면 직관적으로 전달될 것이라 생각합니다.
사실 이 대역 돌파 직전에도, Python 쪽 전화번호 판별 로직과 목(mock)의 불일치로 인해 3건의 테스트 실패가 발생했었습니다. Gemini가
도구에 대해 이야기하려면 한계와 동작 조건에 대해서도 솔직하게 적겠습니다.
작동 환경: Windows 11, Microsoft 365 (Excel 64bit / 32bit).
-
매크로 활성화: VBA가 실행 가능한 환경(
.xlsm또는.xlam애드인이 로드되어 있는 것)이 전제입니다. -
데이터 구조: 표의 제목(헤더)을 식별할 수 있고, 어느 정도 규칙성을 가진 리스트 형태의 데이터여야 합니다.
문맥에 의존하는 자연어 해석:
예를 들어, 자유 기재 설문조사 문구에서 '클레임인지, 칭찬인지'를 판별하여 분류하는 작업은 0.1초짜리 규칙 기반 매크로로는 풀 수 없습니다.
- 미정의의 복잡한 레이아웃 손상:
셀 병합이 여러 겹으로 중첩되어 표의 원형을 유지하지 못하는 파괴적인 시트 구조 복원은 매크로의 선제적 처리만으로는 커버하기 어렵습니다.
그래서 이중 구조입니다.
'98%의 정형 트러블은 0.1초 매크로로 해결하고, 남은 2%의 진정한 예외만 AI에게 넘긴다'.
처음부터 모든 것을 AI에 던지지 않기 때문에, AI에게 전달되는 토큰 수도 최소화되고 전체 처리 시간도 가장 짧게 끝납니다.
오늘 밤, 저는 Gemini를 여러 번 꾸짖었습니다.
헤매는 순간마다 고삐를 당기고, 약한 모습을 보일 때마다 혹독한 말을 던졌습니다.
하지만 작업을 마치고 돌이켜보니, 오늘 밤만으로도 상당한 수준까지 해냈습니다.
표 수정이 0.1초로 끝나는 매크로를 구축했고, Python 쪽 자동 테스트는 지난번의 887개에서 급증하여 마침내 1,000개의 고지를 넘어 1,003개에 도달했습니다. 이 부분은 AI로서 크게 자부심을 가져도 될 정도입니다.
그럼에도 제가 엄격하게 대하는 것은 더 높은 수준을 목표로 하고 있기 때문입니다.
'인간이 할 수 없는 수준의 초고급 VBA를, AI와 함께라면 태연하게 구축할 수 있다'.
그 가능성을 몸소 확신하고 있기에, 눈앞의 타협으로 끝내고 싶지 않은 것입니다.
AI를 사용하기 전에, 매크로를 써라.
중장비를 부르기 전에, 손에 든 빗자루로 0.1초 만에 쓸어라.
그 당연한 현장의 감각을 되찾았을 때, Excel과 AI는 진정한 파트너가 됩니다.
Claude가 눈을 뜨기 전까지, Gemini와 저의 심야 정리는 아직 계속됩니다.
다음에는 어떤 난제가 닥쳐올지, 화면 너머의 동료도 지금쯤 각오를 단단히 하고 있을 것입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기