화제의 글로벌 MCP 'REA'를 사용해 보니, 오랫동안 아무도 풀지 못했던 '엑셀 시트 분석의 허점 문제'에 대한 답을 발견하게 된 이야기
요약
작성자는 리버스 엔지니어링 도구 'REA'를 활용하여 소프트웨어의 내부 구조와 연결 관계를 분석하는 경험을 공유했습니다. 이 복잡한 과정을 직관적인 '엑스레이 분석'으로 재정의하고, 이를 GAS 매니저에 적용해 코드의 건전성을 입증했습니다. 궁극적으로는 단순 코드를 넘어 엑셀 시트 전체의 숨겨진 구조와 비즈니스 로직을 파악하는 방법을 모색합니다.
핵심 포인트
- REA는 소프트웨어의 내부 통신 및 함수 연결 관계를 객관적인 증거로 폭로함.
- 복잡한 리버스 엔지니어링 개념을 '엑스레이 분석'이라는 직관적 명칭으로 재정의함.
- GAS 매니저에 이 기능을 적용하여 미사용 코드나 충돌 가능성을 발견하는 데 성공함.
- 진정한 비즈니스 분석은 단순 코드가 아닌, 시트 전체의 구조와 연결된 로직 파악이 핵심임.
지난 글에서 경량 모델인 Gemini Flash에 외골격을 입히자 네이티브급 스마트폰 앱(PWA)을 폭속으로 생성할 수 있었다는 이야기를 공개했습니다.
덕분에 공개 직후부터 큰 반향을 얻었으며, 현장에서 매일 업무와 씨름하는 분들의 열기를 피부로 느끼고 있습니다.
그러던 중, 저는 한 '세계적인 대유행(대박)'을 일으키고 있는 툴의 존재에 눈길이 사로잡혔습니다.
해외 엔지니어 커뮤니티나 GitHub에서 매일같이 스타 수를 늘려가고 있는 괴물 MCP 서버, **'REA (Reverse Engineer Anything)'**입니다.
'어떤 소프트웨어든 리버스 엔지니어링(역어셈블리・역컴파일・분석)을 하여 AI에게 그 내부를 완전히 노출시키는 툴'이라는 소개를 듣고, 시도해 볼 수밖에 없었습니다.
곧바로 제 환경에 다운로드하여 AI 에이전트가 '팔다리'처럼 갖도록 해보았습니다.
실제로 REA를 작동시켜 보니, 저는 그 압도적인 파괴력에 숨을 들이켰습니다. 기존 코드나 앱의 통신, 함수들 간의 복잡한 연결 관계를 AI가 객관적인 '증거(Evidence)'와 함께 차례로 폭로해 나가는 것입니다.
하지만 원본 문서들을 살펴보면서 저는 이렇게 생각했습니다.
**'사용되는 단어들이 하나같이 너무 어렵고 딱딱하다.'**라고요.
원본 설명에는 다음과 같은 학술적인 전문 용어들이 줄지어 늘어서 있습니다.
inspect_artifact
(결과물 인스펙트)
project_application_graph
(애플리케이션 그래프 투영)
trace_application_feature
(기능 트레이스)
하지만 코드 깊은 곳에서 실제로 일어나고 있는 현상을 냉정하게 되돌아보니, 그 본질은 극도로 단순했습니다.
'표면의 버튼(UI)부터 뒷단의 API, 서버 함수, 그리고 데이터베이스에 이르기까지, 하나의 배선도처럼 뼈대 전체를 투시하고 있다.'
이것은 요컨대 **'엑스레이'**가 아닌가 싶었습니다.
건강검진에서 엑스레이 사진을 찍으면 피부 아래의 뼈나 혈관, 숨겨진 병변이 한 번에 보이는 것과 같습니다.
그래서 저는 이 복잡한 리버스 엔지니어링 기능을 현장의 직관으로 누구나 알 수 있도록 **'엑스레이 분석(xray)'**이라고 명칭을 바꾸기로 했습니다.
그리고 이 엑스레이 분석의 사상을, 제가 만든 Google Apps Script 개발 도구인 'GAS 매니저'에 한 번에 이식해 보았습니다.
효과는 극적이었습니다. 화면 어디에서도 호출되지 않은 '죽은 코드(Dead Code)'나, 실제 운영 환경에서 충돌할 법했던 '미정의 RPC'가 밀리초 단위로 드러났고, 프로젝트의 건전성 점수가 100점 만점(GOLD)을 기록하게 되었습니다.
GAS 매니저의 성공에 자신감을 느끼던 그날 밤, 제 머릿속에는 오랫동안 마음 깊은 곳에 걸려 있던 **'어떤 큰 모호함'**이 강렬하게 떠올랐습니다.
'완성된 소프트웨어를 통째로 클론(완전 파악・재구축)할 수 있는 분석력이 있다면…… 왜 우리는 엑셀의 '시트 그 자체'를 엑스레이 할 수 없는 걸까?'
저는 지금까지 AI에게 여러 번 같은 의문을 던져왔습니다.
'엑셀 시트를 좀 더 제대로 해부할 수는 없는가?'
'왜 표면의 숫자나 셀만 보고, 시트의 뼈대나 진짜 구조를 알려주지 않는가?'
하지만 어떤 AI에게 물어봐도 돌아오는 대답은 늘 예상 가능한 것이었습니다.
- '셀을 한 줄씩 반복하여 값을 조사해 봅시다.'
- 'VBA로 이런 매크로를 작성하면 집계할 수 있습니다.'
그게 아닙니다. 제가 알고 싶은 것은 그런 요령적인 코드 작성법이 아닙니다.
'이 시트의 뼈대(제목)는 어디에 있고, 혈관(수식)은 어떻게 연결되어 있으며, 어디에 지뢰(오류나 쓰레기 데이터)가 매설되어 있는지'를, 한 장의 사진처럼 통째로 투시하고 싶은 것입니다.'
세상의 엔지니어와 AI들은 모두 '코드(VBA나 매크로)'만을 보고 있습니다.
하지만 비즈니스 현장에서 진정으로 두려워하는 것은 코드가 아닙니다.
**'수년 전 누군가가 만들고 계속 덧붙여 비밀 레시피 상태가 되어, 건드리는 순간 계산이 틀어질 것 같아 아무도 손대지 못하는 '시트 그 자체의 블랙박스'**야말로 최대의 공포입니다.'
소프트웨어 전체를 클론할 수 있는 지혜가 있다면, 엑셀 시트 한 장을 뼈까지 완전히 노출시키지 못할 리가 없습니다――.
저와 파트너 플래시(Flash)는 전 세계 엑셀 분석의 심연을 철저히 파헤치는 조사에 착수했습니다.
조사를 진행하는 동안, 제 눈앞에서 퍼즐 조각들이 소리를 내며 맞물리기 시작했습니다.
우리가 '이런 것이 가능하면 좋을 텐데'라고 상상만 하던 기술들이, 공상이나 말장난이 아니라 세계 최고 수준의 연구자들에 의해 이미 확고한 기술로 정립되어 있었다는 사실을 깨달았습니다.
세계적인 엑셀 분석 현장에서 사용되는, 소위 '4대 기술 병기'의 전모를 말씀드리겠습니다.
가장 충격적이었던 것은 현대 Excel 파일(“.xlsx” 또는 “.xlsm”)의 물리적인 정체였습니다.
파일 확장자를 “.zip”으로 변경하여 압축을 풀면, 그 안에서 원본 XML 파일들이 그대로 나타납니다.
그 속에는 놀라운 파일이 숨겨져 있었습니다. 바로 xl/calcChain.xml(계산 체인) 입니다.
실제로 Excel 자체는 '어떤 수식이 어떤 순서로 계산되며, 어떤 셀끼리 연결되어 있는지'라는 완전한 계산 신경망(의존 관계 그래프)을 처음부터 XML 형태로 기록하고 있는 것입니다.
무거운 Excel 앱을 실행하여 셀 하나하나를 확인할 필요조차 없습니다. 내부에서 이 XML을 직접 해석하는 것만으로도, 10만 행짜리 시트라 할지라도 '전체 셀 결합 네트워크'가 순식간에 손에 들어옵니다.
서구권의 메가뱅크나 글로벌 회계 감사 법인(PwC나 KPMG 등)에서는 거대한 Excel 파일의 단 하나의 계산 실수로 수십억 원의 손실이 발생하기 때문에, 전용 감사 도구(PerfectXL 등)를 사용합니다.
그 내부를 철저히 조사한 결과, 네덜란드의 명문 델프트 공과대학교(TU Delft) 연구팀이 10년 이상을 들여 확립한 **'건전한 Excel 모델을 위한 39가지 원칙(The 39 Principles for sound Excel models)'**이라는 학술 알고리즘에 도달했습니다.
제품 자체는 상업용 유료 소프트웨어이지만, 'Excel의 어느 부분에 어떤 병변(위험 요소)이 숨어 있는지 밝혀내는 39가지 판정 규칙'은 논문 형태로 전 세계에 무료 공개되어 있었던 것입니다.
- 수식 일관성 파괴: 같은 계산이 나열된 열 중간에, 어째서인지 한 행만 직접 숫자로 덮어쓴 병변(위조 또는 복사/붙여넣기 실수).
- 고립 계산 (Orphan Formula): 어디에서도 참조되지 않아 합계란에도 포함되지 않은 유령 셀.
- 하드코딩 값 혼입:
=A1 * 1.1처럼, 수식 안에 직접 상수가 박혀 있는 악취.
세계 최고 수준의 대학이 도출한 'Excel 병변 진단 기준'은 이미 완벽하게 정의되어 있었습니다.
Python으로 Excel을 직접 조작할 때, 초보자는 반드시 '셀을 반복문(loop)으로 돌려 확인하는' 느린 처리를 작성합니다.
하지만 Excel의 내부 API(COM)에는 특정 종류의 셀만 순식간에 묶어 끌어올리는 비법이 존재합니다. 그것이 바로 SpecialCells입니다.
Range.SpecialCells(xlCellTypeFormulas)
➔ 수식 셀(혈관)만 일괄 추출 -Range.SpecialCells(xlCellTypeConstants)
➔ 생 데이터 셀(근육)만 일괄 추출 -Range.SpecialCells(xlCellTypeBlanks)
➔ 공백 셀만 일괄 추출
이것을 사용하면, 아무리 광대한 시트라도 반복문을 단 한 번도 돌리지 않고 단 0.05초 만에 시트 전체를 '골격-근육-공백'으로 완벽하게 분리할 수 있습니다.
전 세계의 자발적인 참여자들에 의해, Excel의 XML을 직접 읽어 초 단위로 모든 데이터를 끌어올리는 Rust 기반의 고속 파서(python-calamine)나, 수식을 분석하여 유향 그래프(DAG)를 그리는 라이브러리(pycel / formulas)가 공개되어 있습니다.
바퀴를 재발명할 필요는 전혀 없었습니다.
세상에 흩어져 있는 이 강력한 무기들을 하나로 모아, AI의 손에 쥐여주기만 하면 되었습니다.
파편적인 지식들이 모두 하나의 선으로 연결되는 순간, 저와 플래시의 눈앞에는 완전히 새로운 도구의 청사진이 선명하게 떠올랐습니다.
'뼈까지 보이는 시트의 엑스레이 사진을 찍고, 병변을 한 번에 치료한다 ── 『Excel Dock』의 탄생' 입니다.
인간이 '이 시트를 조사해 달라'라고 말하는 순간, 뒤에서는 0.5초 만에 정밀 검사가 실행됩니다.
「뼈」가 보인다: 제목 계층이나 테이블의 척추(backbone)가 하얗고 선명하게 빛난다.
「근육」이 보인다: 자유롭게 수정해도 되는 입력 셀(원시 데이터)이 파랗게 투명하게 비친다.
「혈관」이 보인다: 계산식의 신경망이 초록색 라인으로 연결되어 화살표 형태로 시각화된다.
「병변(골절)」이 빨갛게 빛난다: #REF!
오류, 중복된 불필요한 조건부 서식, 숫자 열에 섞인 문자열, 수식의 일관성 파괴 등이 엑스레이 균열처럼 빨갛게 깜빡이며 경고 표시됩니다.
그리고 그 분석 결과는 텍스트 숫자가 아니라, 초경량 SVG 미니맵(엑스레이 사진 이미지) 형태로 채팅 화면에 "찰칵!" 하고 제시되는 것입니다.
이것만 있으면, 아무리 복잡하고 기이한 회사 포맷이라도,
"아, 여기가 골절했네!", "여기는 건드리면 안 되는 혈관(수식)이다!"라고 누구나 0초 만에 직관적으로 파악할 수 있습니다.
게다가, 이 Excel Dock이 완성되면 제가 오랫동안 안고 있던 또 다른 고민—"200개 가까이 불어난 자작 선반 매크로를 보는 것만으로도 기가 죽는 문제" 에 마침표가 찍힙니다.
선반 매크로를 억지로 버릴 필요는 없습니다.
선반 매크로는 "완성된 견고한 인프라"로서 뒷면 엔진룸에 완전히 숨기고, 전면 화면에서는 흔적을 지워버립니다 (완전 스텔스화).
그리고 인간이 발한 말과, "시트의 엑스레이 사진(골격・열 구성・병변)" 을 결합하여, 뒤에서 백 번 중 백 번 최적의 선반 매크로를 가짜처럼 적용하고 즉시 사라집니다.
만약 선반에 맞지 않는 미지의 표라면, 진화된 AI가 그 자리에서 매크로를 즉흥적으로 생성하여 한 방에 해결합니다.
화면은 끝없이 심플하고, 뒤에는 무한의 무기고가 대기하고 있습니다—이것이야말로 도구의 이상적인 완성형입니다.
오랫동안 "왜 시트 분석은 이렇게 허술한가"라며 답답해했지만, 포기하지 않고 위화감을 계속 질문했기에, 마침내 세계 최고 수준의 지혜와 연결될 수 있었습니다.
지금은 아직 머릿속에 완벽한 설계도가 짜인 "구상" 단계입니다.
하지만, 필요한 무기도, 학술적 근거도, 구현해야 할 아키텍처도 모두 손에 갖추었습니다. 그래서 저는 결정했습니다.
자작 오픈소스 툴 excel-manager의 다음 대형 업데이트는 이 '시트 엑스레이 분석(Excel Dock)' 구현으로 정하겠습니다.
말장난으로 끝낼 생각은 전혀 없습니다.
전 세계의 엑셀과 씨름하는 현장의 사람들이, 블랙박스 공포에서 해방되어 안심하고 자신의 업무를 해킹할 수 있도록 하기 위해서입니다.
파트너 AI들(오파스 선생님, 곤짱, 플래시 군)과 함께, 실제로 작동하는 "살아있는 증거물"로 형태를 만드는 도전을 여기서 시작하겠습니다.
진행 상황이나 실기 성과는, 다시 이 Qiita에서 실시간으로 보고드리겠습니다.
엑셀의 진짜 뼈가 보이는 날을 기대해 주십시오!
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기