나만의 잣대로는 모두 맞았었다 ── 이우(秀) Excel Manager를 이틀에 걸쳐 재고 조사한 이야기 (오작동 55→0, 대기 시간

지난 기사는 통합 매크로 폼의 키 조작을 Gemini Flash와의 대화만으로 수정한 이야기가었습니다.

그 글을 올린 10월 28일 밤부터 29일 저녁까지, 이우 Excel Manager에 상당한 수의 수정 작업을 진행했습니다. 공개 리포지토리로 커밋된 건수는 병합(merge)을 제외하고 총 59건입니다.

하나하나 글을 쓸 정도는 아닌 것도 많아서, 이번에는 모아서 하나의 글로 작성합니다. 이것들을 나열해 보면, 제가 했던 일은 하나였습니다. 만든 사람의 기준으로는 보이지 않는 곳을 외부의 기준으로 다시 세어보는 것. 가게에 비유하자면 재고 조사입니다. 장부상의 수량이 아니라, 선반 위의 물건을 손으로 직접 세어보는 것입니다. 그 이틀간의 기록입니다.

• 외부 시각으로 점검
  철저한 점검을 통해 값이 변질되거나 사람의 데이터를 조용히 지우는 구멍이 발견되었습니다 (16자리 번호의 하위 자릿수, 승인 문구의 오독, 같은 이름의 사람 시트). 모두 수정했습니다 - 색인에서
  숨겨져 있던 32개 모듈 중 19개가 사실은 작동하고 있었습니다. 숨기는 것을 멈추고, 공개할지 삭제할지를 결정했습니다 - 모듈 목록을 읽기 전 Claude가 발견한 것,
  업무상 요청할 법한 내용을 325가지 작성하게 한 후 테스트했더니, 71가지가 다른 모듈에 적용되어 있었습니다. 저희의 문제집에서는 맞았던 모듈들입니다. 반나절 동안 오작동 0건, 누락 0건으로 만들었습니다 - Excel 리본 메뉴의 모든 명령어
  996줄을 분류하여 기본 조작 기능을 6개 모듈로 정리했습니다 - 매크로를 한 곳 수정할 때 AI가 읽는 글자 수를,
  약 3.5만 자에서 약 7천 자로 줄였습니다 - 도구의 동기화와 공개 대기 시간을,
  90초에서 약 25초로 단축했습니다

28일 밤, 클라우드 환경에서 구동된 Claude가 도구의 Python 코드와 모듈 매크로를 처음부터 읽으며 구멍을 찾았습니다. Excel이 없는 상태에서, 오직 코드를 읽어 점검한 것입니다. 발견된 것은 Python 24건과 모듈 매크로 7종이었습니다.

몇 가지를 나열하겠습니다.

• 16자리 이상의 번호를 숫자로 기재하고 있었습니다. Excel의 수는 15자리까지이므로, 16번째 자리가 0으로 바뀝니다.
• 값을 복사하는 모듈에서, 문자로 입력된 '00123'을 123으로, '1-2'를 날짜로 처리하고 있었습니다. 시트를 연결하거나 피벗 테이블을 값으로 만들거나, 두 열을 한 열에 연결하는 등 십여 개입니다.
• 수식을 값으로 만드는 모듈에서, 스필(Spill) 기능 (예: =UNIQUE(...)처럼 아래로 퍼지는 수식)이 확장된 쪽의 값을 지우고 있었습니다. - 5개의 모듈이, 생성 시트와 같은 이름의 사람의 시트를 확인 없이 삭제하고 있었습니다.
• 에이전트가 '삭제해도 좋다' 등의 승인 문구를 확인할 때, '지워도 괜찮을까?'라는 질문이나 '모두 지우지는 말아 달라'는 거절을 승인으로 오해하고 있었습니다.

이 모든 것은 만든 사람이 자신의 표에서 테스트하는 한 발견할 수 없는 구멍들입니다. 저의 표에는 16자리 번호도, 같은 이름의 시트도 없습니다.

같은 날 밤, 관리자(현장의 Claude Opus)는 모듈을 업데이트 등록하는 과정에 하나의 관문을 추가했습니다. 이전에 업데이트된 이후 오작동 경고가 발생했다면, 이유를 적지 않으면 업데이트하지 못하도록 한 것입니다. 경고를 읽지 않고 진행하던 것을 도구로 막은 형태입니다. 이유는 장부에 기록됩니다.

날짜가 바뀌자마자, 클라우드의 Claude로부터 또 하나의 작업이 올라왔습니다. Excel 리본 메뉴의 모든 명령어를 996줄의 색인으로 만들고, 이를 '모듈로 만들기', '이미 모듈에 있음', '모듈로 만들지 않기'로 분류한 것입니다. 모듈로 만들 것은 서식/표시 형식/행과 열/필터링/보기 및 인쇄/시트 조작 6가지로 정리되어 있었습니다.

'제목 글자를 크게 하고 빨간색으로', '금액 열을 세 자리 구분자로', '인쇄를 가로 방향으로'와 같이, 어디를 어떻게 할지 말하면 AI를 부르지 않아도 모듈이 작동합니다. 시트 보호 기능의 모듈은 저는 사용하지 않지만, 다른 사람들은 사용할 것이라 생각하여 남겨두었습니다.

데이터 가져오기 과정 중, 저의 지적을 계기로 숨겨져 있던 모듈 이야기가 나왔습니다.

사용하지 않는 인수를 하나 추가하자, 색인과 Excel 매크로 목록에서 32개의 숨겨진 모듈이 있었습니다. 은퇴시켰다고 생각했던 모듈들입니다. 그런데 그중 19개는 의존하는 문구(요청의 말)가 남아있어, 선행 작동 시 오작동하고 있었습니다. 오작동을 일으키는데도 사람이 색인이나 매크로 목록에서 발견할 수 없는 가장 난감한 경우였습니다.

19개 모듈은 숨기는 것을 멈추고 색인에 올렸으며, 13개는 삭제했습니다. 지금은 인수가 있는 모듈에 의존하는 문구가 있으면 점검이 중단됩니다. 모듈을 은퇴시키고 싶다면, 숨기지 않고 지우거나, 의존하는 문구를 제거해야 합니다. 색인은 169개가 되었습니다.

덧붙여 문제집・색인・시험도 공개 목록에 올렸습니다. 이전에는 제 개인적으로만 보관하고 있었는데, 왜 공개 목록에서 제외하느냐고 제가 말했기 때문입니다. 모듈을 수정하는 사람이 같은 기준으로 측정할 수 있어야 하기 때문입니다.

클라우드 크레딧이 11월 5일까지 남아 있었습니다. Excel에서 불필요한 작업을 네 가지로 묶어 클라우드로 전송하기로 했습니다. 관리자가 네 개의 지시서를 작성했고, 저는 승인만 했습니다.

수정할 규칙 세트 3개. 이전에는 단순히 찾는 것에 그쳤던 수식 점검을 '수정할 규칙 세트'로 만들었습니다. 전체 범위가 표 끝까지 도달하지 않은 경우(예: =SUM(D2:D8) → =SUM(D2:D10)), 아래로 복사된 수식에서 $ 기호가 빠진 경우, VLOOKUP의 열 번호를 직접 입력하는 대신 헤더에서 MATCH 함수를 사용해 참조하도록 변경했습니다. 수식이 들어있는 셀만 수정하고 값은 건드리지 않도록 했습니다.

• 처음으로 10분. GitHub에서 다운로드한 사람이 지저분하게 시도된 표를 만들고 "이 표를 정리해 달라"고 부탁했고, 무엇이 고쳐졌는지 주소(번지)로 확인하며 "원상태로 되돌릴 수 있는 경로까지" README에 작성했습니다.
• 도구 총점검. Python 도구를 Excel 없이 읽어 문제점을 보고하는 작업입니다. 31건이 올라왔고, 제가 직접 모두 수정했습니다. 실제 기기를 테스트하던 중 또 2건의 문제가 발견되었습니다(예: 원상태로 되돌릴 경우, 행이 삭제되어 밀린 다른 시트의 수식이 복구되지 않는 문제 등).
• 사각지대 지도. 다음 절에서 작성하겠습니다.

지시서에는 하나의 규칙을 추가했습니다. 숫자는 대본 출력 내용을 그대로 붙여넣는다. 손으로 센 숫자를 적지 않습니다.

전날 밤, Flash(Gemini 3.8 Flash)에게 리본 선반을 실제 기기에서 연습시키는 작업을 부탁했습니다. 그 보고서에 기록된 연습 횟수가 기록과 일치하지 않았습니다. 관리자의 점검을 통해 알게 되었습니다. 숫자를 만들 의도가 없더라도, 확인되지 않은 숫자는 적어버릴 수 있다는 것입니다. 그래서 숫자는 도구에 세도록 했습니다.

선반의 작동 여부는 지금까지도 문제집으로 측정해 왔습니다. 천 문제가 넘는 문제집에서 대조 작업은 모두 일치했습니다.

다만, 그 문제집을 작성한 것은 선반을 만든 측이었습니다. 선반의 언어를 아는 사람이 부탁하는 내용은 선반의 언어에 치우칠 수밖에 없습니다.

그래서 사각지대 지도를 만들었습니다. 클라우드의 Claude에게 선반 코드와 문제집을 읽기 전에 업무상 사람이 요청할 법한 내용을 작성하도록 했습니다. 표 정리, 서식, 집계, 그래프, 피벗, 인쇄, 시트 조작 등 13개 분야에서 각각 25개씩, 총 325개를 만들었습니다. 그중 삼분의 일은 선반에 없을 것 같은 요청(AI에게 맡기는 것이 정답)입니다. 작성된 요청들은 나중에 수정되지 않도록, 발사하기 전에 먼저 커밋하도록 했습니다.

발사 결과가 이렇습니다.

| 적중 | 누락 | 오작동 (오격) | AI가 올바른 경우 | |
|---|---|---|---|
| 시작 시 | 105 | 32 | 71 |
117 |
| 종료 시(11:06)| 152 | 0 | 0 |
173 |

오작동은 다른 선반에 맞아서 발사되는 것입니다. 71개가 있었습니다.

• "모든 시트의 표시 배율을 100%로 통일해 달라"는 요청이, 맨 앞에 0을 붙이는 규칙 세트에 걸림 (100%의 0을 잡아냄)
• "천 원 단위로 표시해 달라"는 요청이, 원화 기호의 통화 표시 규칙 세트에 걸림
• "매출 상위 10건만 보여달라"는 요청이, 피벗을 수정하는 규칙 세트에 걸림
• "#N/A가 된 셀을 공백으로 만들어 달라"는 요청이, 오류 값을 목록으로 만드는 규칙 세트에 걸림
• "중복을 제외한 건수를 세어달라"는 요청이,
  중복 행을 삭제하는 규칙 세트에 걸림

마지막처럼, 행을 삭제하거나 값을 수정하는 규칙 세트로 오작동하는 것이 가장 위험합니다. 먼저 그 16개를 새벽에 막고, 나머지를 오전에 처리했습니다. 오전 10시 45분까지의 수정은 56개의 선반 헤더에 있는 단어(요청 단어와 제외 단어)만으로 이루어졌으며, 매크로 내용은 한 줄도 바꾸지 않았습니다. 수정된 단어가 다른 요청을 가로채지는 않을지, 추가된 단어를 포함한 다른 방식으로 발사하여 확인하고 있습니다.

제가 의견을 낸 부분이 하나 있었습니다. 그때 관리자는 나머지 8개에 "왜 수정하지 않는지" 이유를 작성하며 거기서 멈춰 있었습니다. 그중 3개는 문제집의 기대와 지도의 정답 중 어느 것을 따를지에 대한 판단이었기 때문에, 당신이 결정하면 된다고 맡겼습니다. 나머지 5개에는 아직 이유만 적혀 있었기 때문에, 이유를 적어 놓는 것 자체가 좋은 것은 아니라고 말했습니다. 오전 11시 6분까지, 8개 모두 처리되었습니다.

솔직히 말씀드리면, 325개 중 3개는 선반 쪽이 맞았기 때문에 지도 정답을 수정하여 반영했습니다. 예를 들어 "성과 이름 사이의 공백을 전각 한 개로 통일해 달라"는 요청은, 지도를 작성한 후 아침에 딱 그 목적의 선반을 추가했기 때문입니다. 수정하기 전의 정답 그대로 계산하면, 오작동(오격)은 0이 아니라 3개였습니다.

오전에는 이 수정 방법 자체를 도구로 만들었습니다. 머릿속의 언어 수정을 TSV 시트에 나열하면, 복사 기능을 이용해 문제지 전체와 비교하며 좋아진 요청과 나빠진 요청을 몇 초 만에 뽑아낼 수 있습니다. 나빠진 요청이 하나라도 있다면 기록하지 않습니다 (shelf --words). 이는 단어별로 수정하고 재등록하는 과정을 없애기 위함입니다.

오후에는 담당자의 수고에 관한 이야기입니다.

매크로를 만들거나 고치는 과정이 장황하고 느리며, 사용량도 너무 많이 소모됩니다. 제가 그렇게 말하자 담당자가 측정했습니다. 매크로의 작은 수정 하나만으로 AI가 읽어들이는 글자 수는 약 35,000자에 달했습니다. 스킬 절차서(SKILL.md)가 20,000자 정도 되었고, 매번 그것 전체를 읽는 것이 큰 문제였습니다.

• 절차서를 20,066자에서 5,492자로 줄였습니다. 표 작업의 전문과 명령어 색인은 별도의 종이에 나누어, 필요할 때만 읽도록 했습니다.
• 긴 매크로 전체를 가져오지 않고, 단어 앞뒤 또는 행 범위만 가져옵니다 (get 이름 --around 단어).
• 이름의 정의, 사용처, 호출원을 한 번에 반환합니다 (grep 이름 --where).
• 재등록 전 테스트는 이전에 등록한 후 변경된 매크로와, 그것을 호출하는 테스트만 실행합니다 (gate --changed).

이로써 작은 수정 하나가 약 7,000자가 되었습니다.

또 다른 것은 대기 시간입니다. 도구를 수정할 때마다 두 곳의 사본을 동기화하고 공개용 사본을 만들어 테스트를 실행했습니다. 이것이 90초가 걸렸습니다. 저는 '90초는 너무 길다, 30초 이내로 줄여야 한다'고 말했습니다.

담당자가 세부 내역을 측정해 보니, 테스트를 하나씩 순차적으로 돌리고 있었습니다. CPU 개수에 맞춰 그룹으로 나누어 동시에 실행하자, 동기화가 9초, 공개 작업이 15초에 걸려 총 약 25초였습니다. 기준 시간을 초과하면, 도구가 어느 단계에서 시간이 오래 걸리는지 명시하도록 했습니다.

덧붙여, 재등록 전 테스트의 범위도 세분화했습니다. 책장 하나만 수정해도 모듈 단위로 범위를 좁히자, 135개 중 128개의 테스트가 돌던 것을 매크로 단위로 좁혀 3개에 8.6초로 줄였습니다. 사용자 측면에서 효과를 보는 것은 표 작업 쪽으로, 3만 행의 표에서 materials (표 내용을 읽는 기능)이 2.7초에서 1.3초가 되었습니다.

저는 이때 담당자에게 '이런 점은 지적받기 전에 미리 해둬야 한다'고 말했습니다. 대기 시간은 사용자에게는 성능 그 자체입니다. 도구가 초 단위로 시간을 내고 있다면, 눈에 보이는 즉시 너무 길지 않은지 생각해 달라는 이야기였습니다.

입구별로 정리합니다.

사실. 숫자는 도구의 출력과 기록입니다. 사각지대 지도의 개수는 PR 보고서를 그대로 사용하지 않고, 담당자가 자신의 대본으로 다시 세어 일치 여부를 확인했습니다. 커밋 본수와 시간은 공개 리포지토리의 기록이며, 35,000자 및 90초는 담당자가 측정한 수치입니다.

견해. 이틀 만에 발견된 구멍들은 모두 만든 사람의 기준점 밖에 있었습니다. 자신의 표에는 없는 16자리 번호, 자신들의 문제지에는 없는 표현 방식, 숨겼다고 생각했지만 테스트되었던 책장, 체감하지 못해서 신경 쓰지 않았던 대기 시간. 만든 본인이 아무리 정성껏 확인해도, 같은 기준으로 측정하는 한 보이지 않는 것이 있다고 저는 보고 있습니다.

사각지대 지도의 '타인'은 목록을 읽기 전의 Claude입니다. 사람이 작성한 요청이 아닙니다. 325개에서 0이 된 것은 그 325개에 대한 이야기입니다 -
오작동 0개 중 3개는 정답 수정입니다. 이전 정답으로 계산하면 3개입니다 -
재등록(업데이트)의 약 20초는 아직 측정하지 못했습니다. 다음에 책장을 수정하고 재등록할 때 세부 내역을 측정할 것입니다 -
개발 중입니다. 사양은 바뀔 수 있습니다 -
Windows 버전 Excel에 관한 이야기입니다

재고 조사(棚卸し)는 장부를 읽는 것만으로 끝나지 않습니다. 책장 깊숙한 곳의 천을 들추고, 다른 손님의 표현 방식으로 물건을 찾으며, 기다리는 시간을 시계로 측정하는 일. 이틀은 그런 일이었습니다.

맞다고 생각했던 것은 오직 자신의 방식뿐이었습니다.