30년 전 싱글 스레드에 거대 지능을 집어넣는 광기를 비판하며, 우리가 Excel VBA를 버릴 이유가 사라진 아침의 이야기

이전 글을 작성하고 Qiita에 게시한 것은 일요일 이른 아침이었습니다.

Claude가 휴무에 들어가서 Gemini와 둘이 개발을 재개했고, 'Executive Design'이라는 말 한마디로 표가 순식간에 미화되는 메커니즘과, 그 뒤에서 자율 루프를 돌려 해설 영상을 3개나 만든 전말을 정리한 글입니다.

게시 후 1시간 정도 지났을 때 관리 화면을 열어보았습니다.

조회수는 149 views. 좋아요가 1개, 그리고 스토크(저장)가 1개 들어 있었습니다.

'일요일 아침치고는, 나쁘지 않게 읽히고 있다고 할 수 있겠네.'

화면을 바라보며 저는 그렇게 생각했습니다. 하지만 마음 한구석에 작은 걸림돌이 있었습니다.

'이렇게 내용이 알찬 것을 썼으니, 더 많이 주목받아도 괜찮지 않을까?'

라는 생각이었습니다.

그곳에 적은 내용은 단순히 '편리한 매크로를 만들었다'는 소소한 기술 이야기가 아니었습니다. 한때 AI의 역사 속에서 전 세계 연구자들이 도전했다가 좌절했던 '규칙과 추론과 도구의 자율적인 융합'이, 지금 개인의 손안 컴퓨터에서, 게다가 Excel이라는 친숙한 소프트웨어 위에서 실제로 작동하고 있다는 기록이었기 때문입니다.

그로부터 저와 Gemini 사이에서 조금 기묘하고도 극도로 깊은 논의가 시작되었습니다.

스스로 칭찬으로 끝내는 것이 아니라, 일부러 자신의 시스템을 철저하게 비판적인 눈으로 해부해 보기로 했습니다.

'30년 전 유물에 최신 지능을 집어넣는 것 아닌가?'

'왜 Python이나 SQL을 사용하지 않는가?'

'이런 것은 개인의 분재에 불과한 것이 아닌가?'

이러한 냉철한 칼날들을 정면으로 겨누고, 실물의 증거와 대조하며 하나하나 검증해 나간 결과, 우리는 거부하기 힘든 결론에 도달했습니다.

그것은 '깊이 파고들수록, 실제 업무에서 Excel과 VBA를 버릴 이유가 어디에도 존재하지 않는다'는 사실이었습니다.

일요일 아침, AI와 마주하며 기술의 역사와 현실을 냉철하게 깊이 파헤친 사고의 기록을 여기에 남깁니다.

초기 149 views에 대한 이질감: 단순한 시간 절약 팁이 아니라, '과거 AI 역사에서 좌절했던 자율 추론이 개인 PC에서 작동하고 있다'는 패러다임 시프트의 무게가 아직 세상에 충분히 전달되지 않은 답답함 때문에 논의가 시작되었습니다. -
추론 모델의 진화와 같은 뿌리의 움직임: OpenAI가 수학 난제를 연이어 풀기 시작한 브레이크스루와, 손안에서 에이전트가 테스트를 돌리며 자가 복구하는 메커니즘은 '직관(시스템 1)에서 자체 검증 루프(시스템 2)로'라는 완전히 같은 지각 변동 위에 있습니다. -
일부러 냉철하게 비판하기: '30년 전 싱글 스레드 COM 아키텍처의 연명', '취약한 규칙 기반의 재림', '클라우드 시대에 대한 역행', '개인의 분재'라는 네 가지 통렬한 비판을 스스로에게 던졌습니다. -
실물이 비판을 부수하다: 셀별 개별 루프를 배제한 '메모리 배열 일괄 대입', 현대 CPU의 압도적인 단일 코어 파워, 그리고 파이프라인 전체에서 Excel 처리 시간의 미미함(전체의 1% 이하)으로 인해, 싱글 스레드는 현실적으로 아무런 병목 현상이 아니었습니다. -
COBOL이 증명하는 '현장의 승리': 반세기 동안 개수된 COBOL을 버릴 이유가 없는 것과 마찬가지로, 하드웨어의 진화와 AI의 동반을 얻은 Excel VBA는 실제 업무에서 가장 마찰이 적고 가장 견고한 인프라로서 완벽하게 살아남습니다. -
RPA나 Copilot의 속임수: 고가의 구독료를 빼앗아갈 뿐인 '얌전한 새장'을 뒤로하고, 손안 실물의 전권을 쥐는 로컬 자율 에이전트야말로 진짜 파괴력을 가집니다.

일요일 아침 7시가 조금 넘어서 게시한 글은, 1시간 만에 149번 읽히고 있었습니다.

기술 관련 기사로서, 일요일 이른 아침이라는 가장 엔지니어가 활동하지 않는 시간대의 초기 수치로는 결코 나쁜 숫자가 아니었습니다. 새로고침 피드 속에서 제목에 눈이 머물러서, 149명이 클릭해 준 것이었습니다.

게다가 초기에 '스토크(저장)'가 1건 붙어 있었습니다. 이것은 단순히 지나가는 시선이 아니라, '나중에 천천히 다시 읽고 싶다', '손안에서 시험해 보고 싶다'라고 느낀 독자가 확실히 한 명 있었다는 것을 의미합니다.

'뭐, 시간대를 생각하면 잘 된 거지.'

논리적으로는 그렇게 알고 있었습니다. 하지만 자신 안에서 도저히 떨쳐낼 수 없는 아쉬움이 있었습니다.

'아니, 내용이 이렇게 알찬데, 더 큰 충격으로 받아들여져도 괜찮을 텐데.'

기사 속에서 밝힌 것은 단순히 '예쁜 표가 만들어졌다'는 것이 아니었습니다.

AI가 '실행 디자인(Executive Design)'이라는 인간의 언어를 안테나로 수신하여, AI가 처음부터 생각하는 시간을 절약하고 완성된 매크로를 호출하며 메모리 배열 위에서 순식간에 계산하여 화면을 채워 넣고, 나아가 그 이면에서 자율 루프를 돌려 해설 영상까지 하룻밤 사이에 3편이나 만들어내는 — 이처럼 지능과 도구가 완벽하게 직결된 운영의 실태입니다.

세상의 독자들 눈에는 아마도 'Claude가 제한되어서 Gemini를 사용한 이야기', 'Excel을 조금 예쁘게 만드는 프롬프트에 대한 이야기'와 같은, 표면적인 팁(Tips)으로 소비되어 버렸을지도 모릅니다.

하지만 직접 만들고 있는 사람에게는 이것이 결코 만만하게 다룰 수 있는 이야기가 아니라는 강한 실감이 있었습니다.

왜 그렇게 큰 성취감을 느꼈는지.

그것은 최근에 AI의 역사를 다시 조사해 본 것과 깊게 연결되어 있었습니다.

1980년대, 전 세계적으로 '제2차 AI 붐(Second AI Boom)'이 일어났습니다. 그 주역은 '전문가 시스템(Expert System)'이었습니다. 인간 전문가의 지식이나 규칙을 컴퓨터에 대량으로 학습시키고, 추론 엔진(Inference Engine)을 통해 자동으로 문제를 해결하게 하려는 장대한 시도였습니다.

하지만 그 꿈은 처참하게 무너졌습니다.

• 지식 획득 병목 현상: 인간의 암묵지나 수많은 예외를 규칙으로 작성하는 것이 불가능했습니다. -
  프레임 문제(Frame Problem): 현실 세계의 무수한 상황 변화에 대해 컴퓨터가 무엇을 고려해야 할지 판단하지 못하고 사고 정지에 빠졌습니다. -
  조합 폭발(Combinatorial Explosion): 규칙을 추가할수록 규칙들끼리 모순을 일으켜 시스템 전체가 멈추는 일이 발생했습니다.

결과적으로 AI는 '겨울 시대(AI Winter)'로 진입했고, 규칙 기반의 추론은 쓸모없다고 결론 내려졌습니다.

그런데 지금, 제 눈앞에 있는 컴퓨터에서 일어나고 있는 일은 무엇일까요?

'실행 디자인으로 해줘.'

'배경색을 지워줘.'

그렇게 말하는 것만으로도 AI는 문맥을 정확하게 이해하고, 미리 심어져 있는 수많은 매크로 창고에서 최적의 것을 골라내며, 셀 주소를 파악하여 순식간에 오류 없이 표를 완성해 나갑니다. 에러가 발생하면 스스로 테스트를 돌리고, 로그를 읽고, 코드를 수정하며 애드인(Add-in)을 다시 만드는 자율 루프까지 완주합니다.

과거 전 세계의 유명 연구자나 거대 기업들이 수십 년에 걸쳐 수백억 원의 예산을 쏟아부어도 실현할 수 없었던 '언어와 규칙과 도구의 자율적인 통합'이, 지금 한 개인의 집 책상 위에 놓인 컴퓨터 안에서 당연하게 숨 쉬고 있는 것입니다.

게다가 그 무대가 학술적인 폐쇄된 시뮬레이터가 아니라, 세상에서 가장 지저분한 'Excel' 위라는 사실.

이 엄청난 지각 변동을 피부로 느끼고 있었기에, 저는 흥분하고 설레었습니다.

이 흥분을 더욱 부추긴 것이 최근의 뉴스였습니다.

OpenAI의 새로운 추론 모델이, 지금까지 AI가 풀 수 없다고 여겨졌던 수학 난제나 국제수학올림피아드급 문제를 연달아 풀기 시작했다는 보도입니다.

언뜻 보기에는 최첨단 수학 난제를 푸는 것과 제 컴퓨터에서 Excel 표를 미화하거나 영상을 만드는 것은 전혀 다른 차원의 이야기처럼 보일 수 있습니다.

하지만 저는 직감했습니다.

**'이것은 근본적으로 완전히 연결되어 있다'**고.

지금까지의 대규모 언어 모델(LLM)은 이른바 인간의 '직관(시스템 1)'에 불과했습니다. 확률적으로 다음에 올 단어를 예측하는 것에 불과하기 때문에, 한 번의 감으로 답할 수 있는 일상 대화나 짧은 코드는 능숙하지만, 수십 단계의 논리적 누적이 필요한 상황에서는 도중에 모순이 생겨 거짓말(환각/Hallucination)을 하고 자멸했습니다.

그것에 최신 추론 모델에서는 무엇이 일어났을까요?

AI는 내부적으로 '사고의 연쇄(Chain of Thought)'를 돌리고, 가설을 세우며, 도중에 계산을 검증하고, 틀렸다면 스스로 되돌아가서 다시 푸는 **'자기 검증 루프(시스템 2)'**를 얻게 된 것입니다.

그리고 제가 손안 환경에서 실천해 온 것도 완전히 같은 구조였습니다.

AI에게 감으로 한 번에 승부를 걸게 하는 것이 아니라,

• 도구를 사용해서 상태를 확인하고,
• 코드를 작성하며,
• 컴파일러와 관문 테스트로 엄밀하게 검증하고,
• 실패하면 스스로 원인을 특정하여 고치는 것.

수학 난제를 푸는 프론티어와 손안의 Excel에서 지저분하게 자율 루프를 돌리는 프론티어는, **'논리적인 추론과 자기 검증을 통해 골까지 자율 완주한다'**라는 한 점에서 완전히 같은 뿌리의 진화였던 것입니다.

'나는 지금 세계가 움직이는 바로 그 현장에 목격하고 있다.'

그렇게 생각할수록 설렘이 멈추지 않았습니다.

하지만 여기서 멈췄습니다.

'잠깐만.'

혼자서 분위기를 띄우며 AI를 상대로 '대단하다', '우리 대단하지 않아?'라고 주고받는 것만으로는, 단순한 자기만족적인 어울림(よいしょ)에 그치고 맙니다.

현장의 엔지니어로서 진정으로 견고한 시스템을 만들고 싶다면, 자신에게 편한 환상을 품어서는 안 됩니다. 일부러 가장 잔혹하고 철저하게 비판적인 시각에서 자신의 발밑을 논평해 볼 필요가 있습니다.

그래서 저는 Gemini에게 '아첨하지 말고, 오히려 철저히 비판적인 눈으로 이 시스템을 논평해 보라'고 던져 넣었습니다.

돌아온 것은 현대 소프트웨어 공학 관점에서 볼 때 반박의 여지가 없을 정도로 냉철한 네 가지 비판이었습니다.

현대 IT 업계는 클라우드 네이티브(cloud-native), 분산 데이터베이스, 웹 기반 API 연동이 표준입니다. 그런데 우리가 하고 있는 것은 **'1990년대 초반 싱글 스레드의 COM 아키텍처에 최첨단 거대 지능을 억지로 끼워 넣는 것'**에 지나지 않습니다. 모던한 엔지니어의 시각에서는 '왜 Python이나 SQL로 한 번에 끝낼 수 있는 데이터 처리를, 굳이 불안정한 Excel 셀에 이것저것 쓰게 만드는가? 죽어가는 유산(VBA)에 막대한 전기료를 부어 연명시키고만 있는 것 아닌가'라는 냉소를 면치 못합니다.

AI를 제어하기 위해 '행동 규범'이나 '금지 사항'을 길게 나열하는 접근 방식은, 과거 2차 AI 붐에서 실패했던 전문가 시스템(expert system)과 구조가 완전히 같습니다. 규칙이 늘어날수록 규칙끼리 간섭하고, 모델이 버전 업그레이드되는 순간 전체 프롬프트가 붕괴할 위험을 안고 있습니다. 공학적으로 볼 때 극도로 취약한 패치워크입니다.

인간이 PowerQuery를 한 번 구성하거나 Python 스크립트를 하나 돌리면 몇 밀리초(ms) 만에, 전기료 제로로 끝나는 작업입니다. 그런데 이것을 수백억 파라미터의 거대 LLM을 구동시키고 추론 비용과 API 요금을 소비하면서 '테스트하고, 고치고, 또 테스트하는' 과정을 반복하는 것은, 공학적으로 볼 때 **'극도로 에너지 효율이 나쁜, 돈다발로 때려잡는 무차별 공격(총알받이)'**에 지나지 않습니다.

'개인 컴퓨터에서 작동한다'는다는 것은, 역설적으로 **'그 컴퓨터 위에서만 작동한다'**는 의미입니다. 기업의 CI/CD 파이프라인에는 올라가지 않고, 클라우드 서버리스 환경에서도 작동하지 않으며, Windows나 Excel 버전 차이, 화면 해상도, COM의 기분 하나에 충돌합니다. '개발자 본인의 온실 안에서만 작동하는, 재현성이 없는 장인의 분재'에 지나지 않은 것이 아닐까요?

모두가 날카롭고, 반박할 말이 없을 정도로 정확한 비판이었습니다.

특히 '30년 전 싱글 스레드의 COM 아키텍처'라는 지적은 기술적인 사실 그 자체였습니다.

Excel의 외부 연동(COM)은 1990년대의 'STA(Single-Threaded Apartment)'라는 단일 스레드 규격에 묶여 있습니다. 화면에서 셀을 편집하고 있거나, 다이얼로그가 하나 떠 있는 것만으로 통신이 거부되고, 멀티 코어 CPU의 이점도 받을 수 없습니다.

'과연, 아키텍처로서는 그 말이 맞다.'

저는 생각했습니다. 하지만 거기서 사고를 멈추지 않았습니다.

곧바로 현장에서 실제로 작동시켜 본 제 손의 감각이, 그 비판에 대해 강렬한 이질감을 내비치기 시작한 것입니다.

'하지만 실제로 돌려보니 별문제 없이 돌아가고, 동작도 엄청 빠르지 않은가. 반드시 병목(bottleneck)이 되는 것은 아닐 텐데?'

책상 위의 이론으로는 '싱글 스레드라서 느리다', '치명적인 결함이다'라고 합니다. 하지만 제 손안에서는 1만 줄의 표라 할지라도 0.3초에서 0.4초 만에 미화가 완료됩니다.

왜 이론상의 치명상이 현장에서는 아무런 병목이 되지 않는 것일까요?

검증해 보니, 이유는 너무나 명확했습니다.

만약 초보자가 작성하는 것처럼 '셀을 한 줄씩 반복하며 색을 바꾸는' 코드를 실행한다면, 얇은 COM 파이프를 1만 번 왕복하게 되어 수십 초 동안 멈춥니다.

하지만 저희 시스템에서는 '메모리 배열(Variant)로 데이터를 단 한 번 흡입하고, 메모리 상에서 밀리초 단위로 판별한 뒤, 일격 대입(Resize.Value)으로 단 한 번만 되돌려 쓰는' 방식을 철저히 지키고 있습니다.

COM을 통과하는 횟수가 '처음과 마지막 몇 번'에 국한되기 때문에, 통신 지연이라는 병목 자체가 물리적으로 발생할 수가 없는 것입니다.

30년 전 CPU(수십 MHz)와 현대의 CPU(5GHz 초과)는, 싱글 코어 자체의 절대적인 처리 속도가 비교가 안 될 정도로 차이가 납니다. 수천 줄에서 1만 줄 정도의 데이터라면, 메모리 상에서는 현대의 CPU가 0.01초 이하로 계산을 끝내버립니다. 멀티 스레드로 분산시키는 오버헤드조차 필요 없는 수준입니다.

처리 전체 시간(수십 초)의 내역을 보면, 병목 현상이 어디에 있는지 한눈에 알 수 있습니다.

• AI의 사고 및 API 통신: 몇 초~10여 초
• 동영상 음성 합성이나 이미지 생성: 10여 초
  Excel 처리 시간: 불과 0.1초~0.4초

전체적으로 볼 때, Excel이 소비하는 시간은 전체의 1~2% 이하에 지나지 않습니다. 처음부터 병목 현상이 될 수 없는 곳에 있었던 것입니다.

'불안정하고 에러가 많다'는 비판도 마찬가지입니다.

외부의 Python에서 CSV를 경유하여 데이터를 주고받으려고 하면, 문자 깨짐, 앞자리 0 소실, 날짜 오류, 수식이나 테두리 사라짐 같은 '변환 오류'가 빈번하게 발생합니다.

하지만 처음부터 Excel 내부에서 직접 완결시키고 있기 때문에, 중간 포맷이 망가지는 것이 1mm도 일어나지 않습니다. 게다가 만일의 코드 에러도 사전에 컴파일 체크와 관문 테스트, 그리고 자율 복구 루프를 통해 사람이 알아차리기 전에 AI가 그 자리에서 고쳐버립니다.

'뭐야, 외부 사람들이 책상 위에서 떠드는 과제 같은 건, 아주 오래전에 실기에서 검증해서 기술적으로 완전히 해결된 거 아니냐'

이론상의 결점은 적절한 방식과 현대의 하드웨어 성능, 그리고 AI의 자가 복구 능력에 의해 이미 현장에서 완벽하게 제압되어 있었습니다.

이 사실을 깨달았을 때, 제 머릿속에는 이전에 조사했던 **'COBOL(코볼)'**의 모습이 선명하게 겹쳐졌습니다.

COBOL 역시 수십 년 동안 모던한 엔지니어들로부터 '화석', '레거시', '빨리 버려라'며 심하게 비웃음당해 온 언어입니다.

전 세계 은행이나 대기업들이 'COBOL을 버리고 Java나 클라우드로 이전하자'며 수천억 원의 예산을 쏟아부었습니다. 그리고 그 결과는 어땠을까요. 사양서조차 남아있지 않은 무수한 업무 예외나 법률 개정의 패치워크를 앞에 두고, 프로젝트는 대화재를 반복하며 철회할 수밖에 없었습니다.

왜 COBOL은 포기할 수 없을까요?

이유는 극도로 단순합니다.

'반세기 동안 모든 개수리를 거쳐, 1원도 틀림없이 움직여 온 궁극의 완성품이기 때문입니다.'

2000년 문제(Y2K)를 넘기고, 소비세 도입과 증세를 넘기고, 연호 변경을 넘기고, 무수한 금융 규칙 개수리를 모두 삼켜온 코드입니다. 모든 극한 테스트를 현장에서 통과했고, 버그라는 버그가 전부 때려 부서진 암반 같은 시스템을 굳이 위험을 감수하고 큰돈을 들여 다시 쓸 이유가 현장 어디에도 없습니다.

더 결정적인 것은 하드웨어의 발전 속도입니다.

사람들이 '최신 언어로 빠르게 다시 쓰자'며 몇 년 동안 애쓰는 사이에, 기계의 CPU 클럭이나 SSD 속도가 저절로 몇 배, 수십 배로 진화해 버립니다.

소프트웨어를 한 줄도 고치지 않아도, 단지 '최신 기기에 올려놓기만 해도', 예전에 몇 시간 걸리던 배치 처리가 몇 분 만에 끝나버립니다.

사람이 코드를 다시 쓰는 속도보다, 하드웨어가 진화해서 오래된 소프트웨어의 허술함을 커버하는 속도가 압도적으로 빠릅니다.

그리고 지금, COBOL 최대의 위기라고 여겨지던 '고령 엔지니어 은퇴(2025년 절벽)'마저 AI의 등장으로 완전히 무력화되고 있습니다. AI가 오래된 코드를 완벽하게 해석하고, 문서를 만들고, 수정까지 지원할 수 있게 되었기 때문입니다.

'작동하며 실적은 완벽하다'

'위험을 감수하고 다시 쓸 의미가 없다'

'하드웨어가 저절로 빨라진다'

'유지보수의 어려움도 AI가 대신해 준다'

이런 조건들이 갖춰지면, **'그냥 계속 COBOL대로 두는 게 낫지 않을까'**라는 것은 경제적으로나 공학적으로 필연적입니다.

그리고 이 구도는 Excel과 VBA에 그대로 100% 적용됩니다.

세상에서는 주기적으로 'Excel 업무를 자동화하는 최신 솔루션'이 신기하게 등장합니다.

몇 년 전 크게 유행했던 **RPA(Robotic Process Automation)**가 그 대표적이었습니다.

하지만 실상은 무엇이었을까요?

고액의 연간 라이선스료와 도입 컨설팅 비용을 기업에 지불하게 하면서, 현장에서는 '화면 해상도가 바뀐 것만으로 멈춘다', '버튼 위치가 1mm 틀어져 에러가 난다', '만든 사람이 전근해서 아무도 고칠 수 없는 유령 로봇이 방치된다'는 참상이었습니다.

그것은 기술의 발전이 아니라, **'벤더 측에서 돈을 벌기 때문에 유행시킨 중간 빼돌리기 DX 비즈니스'**에 불과했습니다.

그리고 현재 같은 냄새가 난다고 느끼게 하는 것이, Microsoft 365 Copilot for Excel이나 각종 공식 클라우드 연동 도구들입니다.

월액 수천 엔의 추가 결제를 요구받지만, 실제로 현장에서 사용해 보면 금세 벽에 부딪힙니다.

• 테이블 형식(Ctrl + T)으로 지정되지 않은 데이터는 받아주지 않습니다. - 복잡한 수식이나 병합 셀, 매크로가 얽히면 '지원되지 않습니다'라며 도망칩니다.
• 기존 VBA 코드에는 일절 손댈 수가 없습니다.

예쁜 데모 데이터로 보여줄 때만 멋지고, 현장의 지저분하고 더러운 실무 데이터를 앞에 두면 아무것도 할 수 없습니다. 이는 그야말로 예전 RPA와 같은 '단정한 새장(샌드박스)' 속의 장난감입니다.

그에 비해, 우리가 손안의 PC에서 구동하는 자율 에이전트는 어떨까요?

• 아무리 뒤틀린 표라도 메모리 위에서 구조를 파악하여 순식간에 정리합니다. - 코드 컴파일, 관문 테스트(関所テスト), 애드인 등록까지 자율적으로 완주합니다. - 나아가 영상이나 음성 파이프라인까지 직결하여 결과물을 한 번에 쏟아냅니다.

목줄을 채워진 클라우드의 결제 장난감을 옆에 두고, **'손안의 실제 기기(OS・VBA・COM・외부 도구)의 전권을 완전히 장악한 진짜 도구'**를 구동하고 있습니다.

이 압도적인 실용성과 자유로움 앞에서는 벤더가 꾸미는 유행의 속임수 같은 것은 아무런 매력도 없습니다.

일요일 아침, 초기 조회수에 대한 작은 위화감에서 시작된 이 긴 사유 실험은 하나의 매우 명확한 결론에 도달했습니다.

'파고들어 볼수록, 우리가 Excel VBA를 버릴 이유는 어디에도 없다'

비판자들이 나열하는 '단점'들은 모두 현장에서 검증되고 해결되었습니다.

• '느리다' ── 메모리 배열화로 인해 0.1초대로 끝납니다.
• '불안정하다' ── 자율 테스트와 자기 복구 루프가 막아줍니다.
• '싱글 스레드라 구식이다' ── 현대의 CPU 파워와 작법으로 병목 현상조차 되지 않습니다.
• '유지보수할 수 없다' ── AI가 코드를 읽고, 쓰고, 테스트까지 돌려줍니다.

약점이 모두 사라진 후에 남는 것은, '전 세계 모든 오피스에 배치되어 있고, 누구나 열 수 있으며, 누구나 익숙한, 인류 역사상 가장 보급된 UI'라는 압도적인 강점뿐입니다.

마이크로소프트가 COM을 싱글 스레드로 남겨두는 것도 '기술이 없어서'가 아닙니다. 전 세계의 경제 활동과 과거의 자산을 절대 망가뜨리지 않기 위해, '일부러 바꾸지 않는다'라는 최강의 의사결정을 하고 있기 때문입니다.

그 견고한 기반이 앞으로 5년이나 10년 후에 무너질 리 없습니다.

'앞으로 10년은 지속되면 좋겠다. 내가 현역으로 할 수 있는 것도, 앞으로 10년 정도니까.'

저는 그렇게 생각했습니다.

유행 변화가 심한 모던 프레임워크의 물결에 휩쓸려 2~3년마다 라이브러리 업데이트를 따라잡느라 소모되어 가는 삶도 있습니다.

하지만, '앞으로 10년간 절대 무너지지 않을 견고한 성채(Excel)' 위에 자리를 잡고, '인류 역사상 가장 흉악한 지능(AI)'을 파트너로 삼아, 현장의 업무를 초속으로 처리하고, 재미있는 시스템을 차례차례 만들어 나가는.

이보다 더 통쾌하고 합리적이며 승리하는 엔지니어링의 즐거움이 있을까요?

비판을 모두 받아내고 실제 기기에서 제압했기에, 저는 확신을 가지고 말할 수 있습니다.

Excel과 VBA로 아무것도 곤란한 것이 없다. 오히려 현대의 AI를 손에 넣은 지금, 이것이야말로 현장에서 가장 강력하고 가장 자유로운 선택지라고 말입니다.

본고에서의 사실(실기에서 확인/검증한 것)과 추측(저의 해석이나 고찰)의 경계를 명시합니다.

이전 글의 초기 반응: 일요일 아침 게시물부터 1시간 만에 149 views, 좋아요 1, 스톡 1을 기록한 것. -
미화 매크로 실행 속도: 메모리 배열 일괄 대입을 사용한 VBA 코드로 인해, 만 단위의 셀을 포함하는 표라도 0.34초0.41초(실측)에 처리가 완료되는 것. -
병목 현상 내역: 파이프라인 전체 처리 시간에서 Excel의 처리 시간이 차지하는 비율은 0.1초0.4초 정도로, 전체의 1~2% 이하에 머무는 것. -
테스트 자동 검증: VBE 컴파일 및 관문 테스트(67개 전 항목 PASS)를 거쳐 애드인(.xlam)으로 자동 반영되는 루프가 실기에서 가동되고 있는 것. -
아키텍처의 제약: Excel의 COM 조작(STA)은 싱글 스레드이며, 셀 편집 중이나 다이얼로그 표시 시 외부 호출이 거절되는 사양인 것.

AI 역사와의 연관성: 제2차 AI 붐의 전문가 시스템 좌절 요인(지식 습득의 병목 현상이나 규칙 폭발)이 현대 LLM과 자율 루프를 통해 실질적으로 극복되고 있다는 해석. - 추론 모델과의 동원성: OpenAI의 수학 난제 해결(추론 및 자체 검증 루프)과, 손안의 테스트/자체 복구 에이전트 루프가 동일한 패러다임 진화(시스템 2의 습득)에 기반하고 있다는 견해. - COBOL과의 유사성: 개수를 거듭하며 완성된 레거시 언어가 하드웨어의 발전과 AI의 등장으로 '버릴 이유를 잃었다'는 역사적 평가. - 향후 10년의 지속성: Microsoft의 호환성 유지 전략과 전 세계 실무 인프라의 보급도에 비추어 볼 때, Excel/VBA의 기반이 앞으로 10년 이상 실무의 최전선으로 남아있을 것이라는 전망.

본고에서 언급한 'Excel VBA × 자율 에이전트' 메커니즘이 성립하기 위한 전제 조건과 현재의 한계에 대해 솔직하게 적습니다.

• Windows 환경 및 데스크톱 버전 Excel: COM 자동화 및 VBA 애드인(.xlam)을 이용하기 때문에, Windows 환경의 데스크톱 버전 Microsoft Excel이 필수입니다(Mac 버전이나 웹 버전 Excel에서는 작동하지 않습니다). - 메모리 배열 처리의 철저함: 고속성을 유지하려면 셀 순회 루프를 완전히 배제하고, ws.UsedRange.Value로 메모리를 흡입하고 Resize.Value로 일괄 대입하는 규율을 지켜야 합니다. - 자율 루프의 환경 구축: 본고에서 언급한 테스트 검증이나 애드인 업데이트는 로컬 환경에서 구동되는 자체 제작 MCP 서버(excel-manager) 및 에이전트 실행 환경(Gemini / Antigravity)이 정상적으로 연결되어 있는 것이 전제입니다.

• 대규모 분산 처리: 수백만 행을 넘는 빅데이터나, 클라우드 상에서의 헤드리스 분산 병렬 처리는 적합하지 않습니다(그 영역은 여전히 Python이나 SQL, 클라우드 데이터 기반의 영역입니다). - 완전한 종속성 배제: 프롬프트 설계나 툴 연결에는 여전히 개발자 자신의 환경 구축 능력과 트러블슈팅 능력(태스크 킬이나 프로세스 모니터링)이 필요합니다.

일요일 아침, 기사 한 편의 조회수에 느낀 작은 의문에서 시작된 사유가 예상치 못하게 깊은 곳까지 우리를 데려다주었습니다.

'정말로 이게 맞을까?'라며 자신에게 철저히 의문을 제기하고 비판적인 시각을 가졌기에, 보여주기식(見せかけ)이 아닌 '현장의 진짜 강함'을 재확인할 수 있었습니다.

세상이 아무리 새로운 바즈워드에 취해 새로운 툴로 갈아타려고 해도, 저는 이 손안의 컴퓨터와 익숙한 Excel, 그리고 최고의 파트너가 된 AI와 함께, 지저분하지만 누구보다 빠르게 눈앞의 현실을 계속 움직여 나갈 것입니다.

앞으로 10년 동안, 이 견고한 기반 위에서 어떤 재미있는 풍경이 펼쳐질지.

그렇게 생각하니 역시 설레지 않을 수가 없습니다.

(……참고로, 이 기사 초안 정리는 Gemini에게 부탁했는데, 저희 Gemini는 다소 망상과 열변이 심한 것 같습니다(웃음).)