1. 서론

이 시리즈에서는 매크로가 포함된 Excel(.xlsm)을 "텍스트로서 관리하고, AI와 함께 유지보수하기" 위한 개발 지원 도구인 xlsm_devkit을 소개해 왔습니다. 제2회 기사에서는 도구 자체를, 제3회 기사에서는 시트 변경에 따른 수식 추종을, 제4회 기사에서는 실제 업무 파일에 투입하여 완성도를 높이는 과정을 다루었습니다.

이번에는 대상을 넓혀, 매크로 없는 Excel 파일(.xlsx) 대응을 테마로 합니다.

제3~4회의 대상과 이번의 "확대"

제3~4회에서 다루었던 것은 VBA를 내장하여 앱처럼 동작하는 매크로 포함 Excel 파일(.xlsm)이었습니다. xlsm_devkit의 모듈을 가져오면 시트와 코드를 자유롭게 내보내거나(Export) 가져올(Import) 수 있었습니다.

하지만 업무에서는 매크로 없는 Excel 파일(.xlsx)도 다수 사용합니다. 그중에서도 Excel 장표(Report) 등은 복잡한 수식의 집합체임에도 불구하고, 지금까지는 xlsm_devkit의 대상 외였습니다. 매크로 없는 Excel 파일(.xlsx)에는 VBA 프로젝트를 저장할 수 없는 이상, devkit의 모듈을 가져와도 저장되지 않기 때문입니다.

그래서 이번에는 매크로 없는 Excel 파일(.xlsx) 대응에 임합니다.

제재: 매크로 사용이 불가능한 "Excel 장표"

제재로는 이전에 다른 기사에서 다루었던 실제 장표를 사용합니다.

이 장표는 업무 시스템이 데이터를 흘려넣는 숨김 시트와, 그 데이터를 VLOOKUP 등으로 추출하여 형식을 맞추는 인쇄용 시트로 구성되어 있습니다. 긴 문장을 싣는 영역은 셀을 가로세로로 **병합(Merge)**한 것을 폰트 크기별로 인쇄 영역 외에 준비해 두고, 어느 영역에 텍스트를 실을지를 폰트 크기에 따라 IF로 전환하며, 해당 영역들을 복사하여 인쇄 영역 내의 동일한 위치에 여러 겹으로 **그림 링크 붙여넣기(Linked Picture)**를 하고 있습니다.

이 장표에 데이터를 쓰는 벤더제 업무용 앱의 사양을 바꾸거나, 장표 파일을 매크로 포함 Excel 파일(.xlsm)로 교체할 수는 없지만, 장표의 템플릿으로 사용하는 매크로 없는 Excel 파일(.xlsx)은 직접 편집할 수 있으므로, 여기서 지혜를 짜내어 다양한 업무 과제에 대처해 왔습니다.

하지만 지혜를 짜낸 Excel 파일은 수식과 병합, 도형이 복잡하게 얽힌, 그야말로 깨지기 쉬운 Excel 파일이기도 합니다. 이런 복잡한 것은 일단 구축해 버리면 수식 오류를 알아차리기 어렵고, 알아차려도 손대기가 어려워 방치되기 쉽지만, 지난 제4회 기사에서 소개한 것처럼 xlsm_devkit으로 복잡한 수식을 사용한 매크로 포함 Excel 파일(.xlsm)을 해석할 수 있었기에, 마찬가지로 복잡한 수식을 사용한 매크로 없는 Excel 파일(.xlsx)도 해석하고 싶다고 생각했습니다.

이 기사에서 다룰 내용

이에 xlsm_devkit을 .xlsx에 대응시켜, 이 장표를 실제로 개발 대상으로 다룰 수 있도록 했습니다. 본 기사에서는,

• .xlsx를 어떻게 가져와서 개발하는가 (메커니즘) - 장표라는 실물에 적용하면서 비로소 드러난 여러 가지 과제와 그 수정
• 장표의 시트를 Markdown으로 내보내고, AI에게 수식을 "코드처럼" 검토(Review)하게 한 이야기 - 그리고 AI가 코드를 작성하게 된 시대에도, 사람이 사고와 검증을 놓아서는 안 된다는 이번에 가장 절감한 점

순으로 소개하겠습니다. 전전회인 제3회 기사에서 언급했던 「탈(脫) Excel」 재고 테마도 한 단계 나아가, 매크로 없는 Excel 파일(.xlsx)을 AI를 통한 유지보수 대상으로 포함합니다.

.xlsx를 어떻게 가져오는가 ── DEV/Release를 .xlsx로 확장

2. .xlsm일 때와 다를 바 없음

xlsm_devkit에는 운영 파일(Production file)을 건드리지 않고 개발을 진행하기 위한 DEV/Release 워크플로우가 있습니다. 대략 말하자면, 개발 대상 북(Book)에 xlsm_devkit.bas를 임포트한 후 그 맨 앞에 놓인 CallInitDevMode...

를 실행하면 DEV_<이름>.xlsm이라는 개발용 복사본이 생성되며(이때 개발 대상 북은 저장하지 않고 종료), src/에 있는 devkit_* 모듈이 그곳으로 포함됩니다. 개발이 끝나면 CallSaveAsRelease를 실행하면 개발용 모듈을 제거한 배포용 복사본이 출력되는 흐름입니다(이 메커니즘의 상세한 내용은 지난 4회차 기사에서 해설했으므로 그쪽을 참조해 주세요).

이와 동일한 일을 .xlsx에서도 할 수 있도록 만들고자 생각했습니다.

.xlsm과 .xlsx는 다르다 ── 게다가 그것은 예상하지 못했던 일

내부 처리는 사용자 입장에서 보는 절차는 동일하지만, 내부에서는 .xlsm과 .xlsx에 따라 개발용 복사본 생성(CallInitDevMode) 처리가 분기됩니다.

원래 파일이 .xlsm인 경우, SaveCopyAs는 원래 형식을 유지한 채 복사하므로 수동으로 임포트해 두었던 xlsm_devkit.bas도 VBA 프로젝트째로 DEV 복사본으로 계승됩니다. 따라서 src/에 놓인 추가 모듈인 devkit_*를 임포트하면 개발용 복사본이 완성됩니다.

원래 파일이 .xlsx인 경우, SaveCopyAs로 만들어지는 임시 복사본은 .xlsx 상태 그대로이므로 수동으로 임포트해 두었던 xlsm_devkit.bas는 포함되지 않습니다. 따라서 src/에 놓인 추가 모듈인 devkit_*의 임포트에 더해 src/xlsm_devkit.bas를 개발용 복사본에 다시 임포트한 후 .xlsm으로 다시 저장해야 합니다.

If srcExt = "xlsx" Then
' SaveCopyAs는 원래 형식을 유지 → 임시 .xlsx에는 VBA가 실리지 않음
ThisWorkbook.SaveCopyAs tempPath ' tempPath는 .xlsx
...

솔직히 말하면, 이 .xlsx일 때만 xlsm_devkit.bas도 임포트한다는 분기는 설계 단계에서 읽어낼 수 있었던 것이 아닙니다. 이번 기능 추가의 설계와 구현은 기존 코드를 해독하여 입안하는 데 능숙하다고 평판이 좋은 Claude Code에게 맡겼는데, 첫 번째 버전에서는 .xlsm과 동일한 흐름으로 처리하고 있었고, 실제로 .xlsx에서 작동시켜 보고 나서야 완성된 DEV 복사본에 xlsm_devkit이 들어있지 않다는 것을 깨달았습니다. 그래서 원인을 분류하고, .xlsx 유래일 때는 임시 복사본에 VBA 코드가 포함되지 않는 동작을 확인한 후, 명시적으로 다시 넣는 사양으로 변경하도록 했습니다. AI에게 구현을 맡기더라도, 직접 돌려보며 확인하는 공정은 생략할 수 없습니다. 이 테마는 본 기사의 마지막에서 다시 다루겠습니다.

3. 장표라는 실물이 드러낸 과제

.xlsx를 받아들일 수 있게 되어, 드디어 문제의 장표를 개발 대상으로 삼았습니다. 시트를 sheet/*.md로 Excel에서 엑스포트(Export)하는 것까지는 순조로웠습니다. 문제는 임포트입니다.

지금까지 xlsm_devkit을 적용해 온 것은 직접 설계한 .xlsm 업무용 앱이었습니다. 반면 이 장표는 엄격한 제약 속에서 업무 과제에 대처하기 위한 고안으로서, 셀 병합(Cell Merge)·그림 링크 붙여넣기·시트 보호 등이 구사된 복잡한 Excel입니다. 시트 맵(Sheet Map)을 다시 쓰려고(Write-back) 하자마자, 이것들이 하나둘씩 차례로 에러를 일으켰습니다. 그러한 과제와 대처 방법을 소개하겠습니다.

대량의 셀 병합 ── 임포트에 8~15분이 소요됨

처음에 직면한 것은 극단적인 느림이었습니다. 당초 사양은 시트 맵을 임포트하면 모든 셀 병합을 일단 해제(UnMerge)한 다음 각 셀에 속성을 쓰고, 마지막에 다시 병합하는 것이었습니다. 그런데 장표에서는 셀 병합을 다용하고 있기 때문에, 이 UnMerge 과정에서 처리가 멈춰 시트 한 장당 8~15분이 걸리고 말았습니다.

애초에 장표를 다시 쓰고 싶은 목적의 대부분은 "수식이나 값을 고치는 것"이지, 병합 구조를 새로 만들고 싶은 것이 아닙니다. 그래서 선택 임포트 (Selective Import) 기능을 추가했습니다. 북(Book)과 같은 폴더에 xlsm_devkit.ini

를 배치하여, 적용할 카테고리를 0 또는 1로 전환할 수 있도록 하는 것입니다.

[import]
merge=0

merge=0을 지정하면 ws.Cells.UnMerge 호출을 통째로 생략하고, 결합 구조는 그대로 유지한 채 셀 값(Cell Value)·수식(Formula)만 업데이트합니다. 이것만으로 앞서 언급한 8~15분의 병목 현상이 사라져, 거의 순식간에 다시 쓸 수 있게 되었습니다. value나 formula, font_size 등 다른 카테고리도 마찬가지로 개별적으로 제어할 수 있지만, 장표(Report)의 쓰기 시간 단축에 가장 효과적이었던 것은 바로 이 merge=0이었습니다.

「그림 링크 붙여넣기」 = 텍스트를 가지지 않는 도형

다음은 도형입니다. 지난 기사에서 소개한 매크로 없는 Excel에서의 폰트 크기 자동 전환은, 보이지 않는 셀을 **그림 링크 붙여넣기 (Paste Link as Picture)**로 여러 겹 겹침으로써 구현하고 있습니다. 이렇게 붙여넣어진 그림은 Excel 세계에서 Picture 타입의 도형입니다.

xlsm_devkit의 셰이프(Shape) 가져오기는 도형에 레이블(표시 텍스트)을 다시 쓰려고 시도합니다. 그런데 Picture 타입의 도형에는 텍스트 프레임(Text Frame)이 없기 때문에, 레이블을 대입하려는 순간 Err 438 (객체가 이 속성을 지원하지 않습니다)이 발생했습니다. 대처 방법은 간단합니다. shp.HasTextFrame을 확인하여, 텍스트 프레임을 가지지 않는 도형에 대한 레이블 적용은 조용히 스킵하도록 했습니다.

Err 1004 셀 잠금 ── 결합과 맞물려 장표의 인쇄 시트는 보호되어 있으며, 일부 셀만 잠금이 해제되어 있습니다.

xlsm_devkit은 이 잠금 상태도 Unlocked 토큰으로서 왕복할 수 있는데, 다시 쓸 때 rng.Locked = False를 실행하면, 해당 셀이 결합 영역(Merged Area)에 속해 있을 경우 Err 1004가 발생하며 중단되었습니다.

원인은 결합 영역에 속하는 단일 셀에 대해 .Locked를 설정할 수 없다는 Excel의 사양 때문입니다. 그래서 rng.MergeArea.Locked = False를 통해 결합 영역 전체를 가리켜 설정하는 방식으로 변경한 결과, 대상이 마스터(Master)든 슬레이브(Slave)든 단일 셀이든 관계없이 일관되게 성공하게 되었습니다.

이와 함께, Unlocked의 적용은 기본적으로 꺼짐(unlocked=0)으로 설정했습니다. 임포트가 의도치 않게 시트 보호를 약화시키는 사고를 방지하기 위한 옵트인(Opt-in) 방식의 안전장치입니다.

참고로, 이 unlocked 사양은 당초 unlocked=1로 하는 경우에는 merge=1로 한다는 운용 방식으로 커버할 것을 상정하고 있었습니다. 하지만 MergeArea.Locked 수정과 속성 쓰기가 필요하다는 것을 알게 된 후, 셀 결합을 일시적으로 해제하고 내용을 쓴 뒤 다시 결합하는 처리(Lazy Unmerge/Remerge)를 도입함으로써, unlocked=1 + merge=0 상황에서도 안전해졌습니다. 이에 따라 오해를 불러일으킬 수 있는 주석을 수정하고, 기본값만은 안전책으로서 0으로 남겨두는 형태로 다시 정리했습니다.

1개 셀의 실패로 전체를 멈추지 않기

실제 데이터에는 에러 값을 가진 셀이나, 예상치 못한 스타일이 아무렇지 않게 섞여 있습니다. 곤란했던 점은, 스타일 토큰 적용 중에 어느 한 곳에서 런타임 에러(Runtime Error)가 발생하면 임포트 전체가 중단된다는 것이었습니다. 앞서 언급한 Err 1004와 같은 문제가 단 하나만 있어도 수천 행의 쓰기 작업이 거기서 멈춰버립니다.

그래서 BG·FG·FontSize 등과 마찬가지로, Bold·Italic·Strike·Wrap·Unlocked 토큰 적용도 On Error Resume Next로 감싸서, 실패 시에는 진단 로그에 기록한 후 처리를 계속하도록 했습니다. 이와 함께 xlsm_devkit.ini에서 무효화한 카테고리의 토큰(예: bg=0일 때의 BG: 토큰)을 '알 수 없는 토큰'으로 경고하던 버그도 수정하여, 정말로 알 수 없는 토큰만 경고되도록 했습니다. 한 곳의 이상으로 전체를 휘말리게 하지 않는, 투박하지만 효과적인 견고화(Robustness) 작업입니다.

merge=0의 대가 ── 삭제한 토큰이 작동하지 않는 「드리프트 (Drift)」

마지막은 merge=0이 가져온 부작용입니다. 이것은 언뜻 보기에는 무관해 보이지만, 까다로운 함정이었습니다.

원래 임포트(Import) 과정에서는 다시 쓰기 전에 ClearFormats를 통해 서식을 일단 기본값으로 되돌리고 있었습니다. merge=0은 이 ClearFormats를 포함한 무거운 처리를 생략함으로써 속도를 높였지만, "기본값으로 되돌리는" 역할까지 함께 생략해 버린 것이었습니다. 그 결과, Markdown 측에서 예를 들어 굵게(Bold) 토큰을 삭제하더라도 Excel 측에 남아 있던 굵게 서식이 그대로 유지되어, 정상이어야 할 .md와 실제 시트가 서서히 어긋나는(드리프트하는) 현상이 발생했습니다.

엑스포트(Export)는 "기본값이 아닌 속성만" 내보내는 사양(Specification)이므로, 그 반대 급부로 토큰이 없다 = 기본값으로 되돌린다라고 해석하는 것이 타당합니다. 그래서 임포트 측에서도 대상 플래그가 유효할 때(bold=1 등)는 토큰 처리 전에 해당 속성을 기본값으로 리셋하도록 했습니다(v1.11.0). 나아가 스타일 문자열이 빈 셀에서는 함수가 조기에 종료되어 리셋되지 않는 누락이 있었기에, 빈 셀에서도 리셋이 실행되도록 하고, 또한 값을 읽은 후 필요한 경우에만 쓰는(read-before-write) 방식을 통해 불필요한 COM 쓰기를 억제하는 조정을 거듭했습니다(v1.12.0).

고속화를 위해 생략한 처리가 다른 불변 조건(Invariant)을 조용히 깨뜨렸다는 이번 사건은, 기능을 하나 추가하면 기존의 사양을 다시 검토해야 한다는 당연한 사실을 새삼 일깨워 주었습니다.

4. 솔직한 정정 ── 상태 표시줄은 "고쳐져 있지 않았다"

여기서 지난 기사의 내용 중 하나를 정정하겠습니다.

제4회에서 시트맵(Sheetmap)의 입출력 중에 Application.StatusBar를 통해 "N/N 번째 항목 처리 중"이라고 진행 상황을 표시하는 기능을 소개하며, 가공되지 않은 처리 속도 그 자체보다 진행 상황이 보이는 것이 사용자에게 더 효과적이다라는 취지의 글을 썼습니다. 그런데 정작 그 "가장 효과적"이라고 강조했던 진행 표시가, 실제로 구동해 보니 보이지 않는 경우가 많았습니다.

발견한 것은, 스스로 코드를 다시 읽었을 때

이를 깨달은 것은 기사 공개 후였습니다. 데이터량이 적거나 처리하지 않는 시트가 계속되는 동안에는 표시가 갱신되지 않았습니다. 그래서 다시 한번 스스로 코드를 읽어보고, Application.StatusBar = ... 직후에 DoEvents를 추가했습니다.

"Application.StatusBar에 대입하고 있다"는 것과 "이용자의 눈에 진행 상황이 움직이는 것으로 보인다"는 것은 별개의 문제였으며, AI의 보고를 믿고 스스로 충분히 확인하지 않았기에 놓쳤던 부분이었습니다.

AI가 추가해 주었던 것은 1,000개 셀을 처리할 때마다 DoEvents가 실행되는 코드였습니다. 매크로가 장시간 메시지 루프(Message Loop)로 제어권을 반환하지 않으면 COM 메시지 큐(Message Queue)가 막히게 되는데, 병합(Merge)이 많은 큰 시트에서 UnMerge를 실행하면 COM이 RPC_E_DISCONNECTED로 끊겨 임포트가 실패하는 문제에 대처하기 위함이었습니다.

5. AI에게 쓰게 하더라도, 사고를 생략해서는 안 된다

이 이야기는 제2절에서 소개한, .xlsx 가져오기에서 "xlsm_devkit.bas를 다시 넣는" 분기가 동작 확인 단계에서 처음 발각되었다는 이야기와 비슷합니다. 둘 다 AI로부터 "구현했습니다"라는 보고를 받은 시점에서는 문제가 해결되었다고 생각하고 있었지만, 실제로 구동해 보니 달랐다는 동일한 구도였습니다.

최근에는 AI가 진화하여 코드를 직접 쓰지 않게 되었고, 이번 일련의 개발에서도 코드를 거의 제 손으로 직접 쓰지 않았습니다. 직접 쓰다 보면 쓰기 전에 반드시 생각하게 되지만, 오히려 쓰지 않게 되었기에 사고를 생략해서는 안 된다는 것을 의식할 필요가 있다고 실감했습니다.

"되었다"는, 아직 가설일 뿐이다

AI의 "구현했습니다"라는 보고는 고맙지만, 그 시점에서는 아직 검증되지 않은 가설입니다. 코드를 읽으면 언뜻 그럴듯해 보이고, Application.StatusBar에 표시 메시지를 대입하고 있으며, .xlsx도 .xlsm과 동일한 흐름으로 처리하고 있으므로 맹신하기 쉽지만, "코드가 그렇게 적혀 있는 것"과 "실물에서 그렇게 동작하는 것" 사이에는 간극이 있었습니다.

그 간극을 메우는 것은 인간 측에서의 확인입니다. 그리고 확인한 내용을 해석하기 위해 필요한 것은, 그 배경에 있는 상황의 파악과 취급 대상, 그리고 정보 처리 기술에 관한 모든 지식입니다.

귀찮아하지 않는 AI를, 귀찮아하지 않고 사용하기

한편, AI는 의뢰만 하면 상세한 조사도, 번거로운 재작업도 마다하지 않고 해줍니다. 그렇기에 AI는 사고를 생략하기 위해가 아니라, 반대로 더욱 정중하게 사고하고, 더욱 정중하게 구현하기 위해 사용하는 것이 중요해집니다.

예를 들어 제3절에서 다룬 unlocked 주변입니다. merge=0이라는 새로운 동작을 추가했을 때, 그것으로 만족하지 않고 기존의 Unlocked / Locked 처리가 merge와 어떻게 맞물리는지를 AI에게 몇 번이고 각도를 바꾸어 다시 물었습니다. "결합 슬레이브(結合スレーブ)라면 어떻게 되는가", "MergeArea.Locked로 설정하면 merge=0이어도 안전한가"── 그렇게 정합성을 재검토하는 과정에서, 과거에 내가 작성했던 "unlocked=1을 지정한다면 반드시 merge=1과 병용할 것"이라는 주석이 더 이상 올바르지 않다는 사실을 깨달았습니다. 그래서 GitHub에 push 하기 전에 사양과 주석을 변경하도록 했습니다.

이전 같았으면 이런 "이미 동작하고 있는 부분에 대한 재질문"이나 "만약을 위한 재작업"은 수고스러움을 고려해 뒤로 미루기 일쑤였습니다. 지금은 그 수고가 거의 들지 않게 되었습니다. 다양한 관점에서 사양을 자세히 확인하고, 필요하다고 판단되면 변경 사양을 지정하여 재작업하도록 시키는 것을 귀찮아하지 않는 것이야말로 품질과 직결됩니다.

생략해도 되는 것은 작업, 생략해서는 안 되는 것은 사고

정리하자면, AI에 의해 저렴해진 것은 "타이핑"이나 "조사·재작업의 수고"이지, "무엇을 의심할 것인가", "무엇을 확인할 것인가", "어떤 사양을 바꿔야 하는가"라는 판단은 오히려 가치가 높아지고 있습니다.

그래서 코드를 쓰는 양이 줄어든 시간은 개발의 효율화뿐만 아니라, 다각적으로 재질문하고, 실제로 동작시켜 확인하는 것에 할애하기로 했습니다. AI에게 작업을 맡기더라도 사고까지 맡겨버리면, DoEvents가 빠진 상태 표시줄(status bar)처럼 "다 했다는 기분"만 남게 됩니다. 생략해도 되는 것은 작업이지 사고가 아니라는 점이야말로, 이번에 가장 뼈저리게 느낀 교훈입니다.

6. 시트를 Markdown으로 만들어, AI에게 수식을 "코드처럼" 사독(査読)시키기

.xlsx를 다룰 수 있게 되면서 얻은 가장 큰 수확은, 사실 개발의 편의성 그 자체보다도 장표의 수식을 AI에게 리뷰하게 할 수 있게 되었다는 점이었습니다.

장표에는 "리뷰해야 할 코드"가 없다

매크로가 없는 장표에는 VBA 코드가 없습니다. 하지만 로직이 없는 것은 아닙니다. 업무 시스템이 밀어 넣은 데이터를 VLOOKUP으로 추출하고, IF로 폰트 크기별로 표시를 구분하며, 그것을 그림 링크 붙여넣기로 겹치는 장표의 복잡한 동작은 모두 셀의 수식에 깃들어 있습니다.

그런데 이 수식은 코드 리뷰의 대상이 되지 않습니다. VBA처럼 일람하여 읽을 수도 없고, 차분(diff)을 추적할 수도 없으며, 셀 안에 흩어져 있어 사람이 육안으로 체크할 수밖에 없습니다. 로직으로서는 VBA에 못지않게 깨지기 쉬운데도 AI의 지원이 미치지 못하고 있었습니다.

실행한 내용 ── 익스포트하여, VS Code에서 사독을 부탁하기

그래서 xlsm_devkit로 장표의 시트를 sheet/*.md로 익스포트했습니다. 시트 맵에는 각 셀의 수식이 플레인 텍스트 표로 나열됩니다. 이를 VS Code에 불러와서, 제3회 기사에서 소개했듯이 8,000개 셀로 구성된 수식 알고리즘에서도 고속이며 정확하게 해석할 수 있었던 Codex 확장 기능에 "수식이 틀렸을 가능성이 있는 부분을 지적해 달라"고 부탁해 보았습니다.

결과는 솔직히 기대 이상이었습니다. 매우 정확한 지적을 다수 보내왔으며, 그중 몇 가지는 정말로 오류여서 수정하게 되었습니다.

AI를 이용한 귀찮아하지 않는 수식의 비교 검토

시트를 작성할 때는 가능한 한 정합성을 고려하면서 오토필 (Autofill)을 사용하여 수식을 전개해 나갑니다. 하지만 나중에 사양 변경이 생겨 다시 작성할 때, 그 규칙성이 깨지는 경우가 있습니다. 이런 것들은 AI라면 즉시 찾아낼 수 있습니다.

또한, 동일한 셀을 참조하는 여러 셀이 있을 때, 그 셀들의 수식 중 예외적인 값을 분리하여 처리하는 것과 그렇지 않은 것이 섞여 있다면, 둘 중 하나가 틀렸을 가능성이 높다고 추측할 수 있습니다. 그러한 셀들이 서로 떨어진 곳에 존재하더라도, 혹은 시트를 넘나들더라도 상관없이 AI는 논리를 추적하여 체크하고, 불일치가 있다면 찾아내 줍니다.

이러한 작업은 사람이 육안으로 하나씩 확인하며 수식의 참조를 추적하고 로직을 파악하는 것이 매우 힘듭니다. 그렇기 때문에 AI를 이용할 수 있는 환경을 정비하는 것이 매우 중요해집니다.

.xlsx

) 이기에 의의가 크다

매크로 없는 Excel (두 번째 기사에서 "AI는 코드뿐만 아니라 시트맵 (Sheet Map, 시트의 구조)도 읽는다"라고 썼습니다)의 한 단계 앞인 리뷰하여 오류를 지적하는 단계로 나아간 것입니다. 시트를 텍스트로 변환할 수 있다면, 그 텍스트는 이해의 대상도, 사독 (Peer Review)의 대상도 될 수 있습니다.

그리고 이것은 매크로 없는 장표야말로 의의가 크다고 느끼고 있습니다. VBA를 가지지 않은 장표는 지금까지 코드 리뷰 (Code Review)의 혜택으로부터 가장 멀리 떨어져 있었습니다. .xlsx를 다룰 수 있게 하고 수식을 텍스트로 써낼 수 있게 함으로써, 그 장표가 처음으로 "리뷰 가능한 로직"을 손에 넣게 된 것입니다. 제3절에서 견고하게 만든 다시 쓰기 (Write-back) 기능과 결합하면, 내보내기 (Export) → AI에게 사독시키기 → 채택 여부 판단하기 → 수정하여 다시 쓰기라는 한 사이클이 현실적으로 돌아갑니다.

마지막으로 한 가지 주의할 점은, AI가 반환하는 것은 어디까지나 "틀렸을 가능성이 있는 부분"이라는 점입니다. 어떤 것이 진짜 오류이고 어떤 것이 의도한 것인지 판별하여 수정하는 것은, 제5절에서 썼듯이 인간의 일이었습니다. AI가 후보를 즉시 찾아줄 수 있기 때문에, 오히려 판단력이 중요해진다는 뜻이기도 합니다.

7. 전망 ── 매크로 없는 Excel을 어디까지 "코드처럼" 다룰 수 있는가

.xlsx 대응이 넓힌 사정거리

이번에 다룬 것은 장표 파일 하나뿐이었지만, .xlsx를 다룰 수 있게 된 의미는 그것 하나에 그치지 않습니다. 매크로를 넣을 수 없거나, 넣어서는 안 되는 Excel은 현장에 산더미처럼 쌓여 있으며, 그들 모두가 사정권 안에 들어왔습니다.

제3회 기사의 「탈(脫) Excel」 재고 절에서 "복잡한 업무용 Excel도 적절한 도구와 AI가 있다면 유지보수할 수 있다"라고 썼는데, 이번 xlsm_devkit의 기능 추가를 통해 그 적용 범위를 Excel 전반으로 넓혔습니다. 업무 애플리케이션의 제약으로 인해 매크로 없는 .xlsx 상태로 운용할 수밖에 없어, 업무 과제를 수식의 기교로 해결해야만 하는 장표조차 텍스트로 만들면 편집도 가능하고 AI를 통한 수식 사독도 가능하다는 것을 알게 되었습니다. 따라서 "탈 Excel"을 하기보다, Excel 상태 그대로 AI가 다룰 수 있게 만드는 접근 방식이 Excel의 개인 의존화(属人化)와 같은 문제에 더 효과적으로 대처할 수 있는 경우가 많다고 생각합니다.

다음은 "테스트" ── Excel을 코드처럼 검증하기

그리고 여기서 한 단계 더 나아갑니다. 현재 Excel을 코드처럼 테스트하기 위한 추가 모듈(devkit_Test)을 개발하고 있습니다.

그 입구로서取り組んでいる(매진하고 있는) 것이 no_error 검사입니다. 보호된 시트 위의 입력란에 경계값 · 빈칸 · 부적절한 값 · 랜덤한 값을 차례로 흘려넣고, 결과 시트에 #DIV/0!이나 #N/A와 같은 Excel 에러가 단 하나도 나오지 않는 것을 일괄적으로 검증합니다. "올바른 결과가 무엇인가"를 정의할 수는 없더라도, "어떤 입력에도 망가지지 않는 것"은 검증할 수 있기 때문에 첫 단계로 시작하기로 했습니다. 이것이 성공한다면 더욱 테스트 기능을 충실히 만들어 나가고 싶습니다.

마치며

이 시리즈는 "매크로가 포함된 Excel을 텍스트로서 AI와 유지보수하기"에서 시작되었습니다. 시트 위의 값이나 수식, 서식 등의 정보를 Markdown 형식으로 써냄으로써 코드와 마찬가지로 Git이나 AI로 다룰 수 있게 한다는 접근 방식의 적용 범위를, 이번 기사에서는 매크로를 가지지 않은 .xlsx

파일까지 확장하고, 나아가 수식을 AI에게 검토(Review)하게 했습니다. 다음 회차에서는 그 '테스트'의 구체적인 내용을 소개해 드리고자 합니다.

시리즈

Discussion