지금 제 화면은 좌우로 나뉘어 있습니다. 왼쪽 절반은 Excel, 오른쪽 절반은 Claude Code입니다. 왼쪽의 통합 문서(Workbook)는 열어둔 채로, 저는 셀을 선택하거나 서식을 정리하면서 오른쪽의 AI와 일본어로 대화를 나누고 있습니다.

이전에 매크로 목록의 [AI 수정] 버튼을 누르면 대화할 필요도 없이 매크로가 고쳐져서 돌아온다는 이야기를 쓴 적이 있습니다.

(다시 한번 「AI 요약 설명」 예고를 건너뜁니다. 죄송합니다, 그전에 꼭 쓰고 싶었던 밤이 있었습니다.)

이번에는 그 뒤를 잇는 발견에 관한 이야기입니다. 결론부터 말씀드리면, 「고쳐진다」는 입구에 불과했습니다. 어느 밤의 작업을 처음부터 끝까지 기록하여, 그것을 통해 알게 된 전말을 적어보겠습니다. 코드는 거의 나오지 않습니다. 나오는 것은 대화입니다.

• 열려 있는 Excel에 AI가 올라타서, 「지금 내가 선택하고 있는 셀」을 읽으며 대화로 작업을 진행했습니다.
• 셀의 내용에서 대화 로그 저장 이름의 결함을 발견했고, 원인을 추적하게 했더니 AI가 로그의 0.8초 차이를 물증으로 삼아 진범(저장 처리의 병행 실행)을 지목했습니다.
• 덤으로 발견된 이중 저장은 총 100장이 넘었습니다. 본문의 완전 일치만을 근거로 정리하여, 대화는 단 한 건도 잃지 않고 해결했습니다.
• Excel 측에는 「시트마다 서브 폴더를 제외하는 설정」이 추가되었습니다. 매크로 추가는 실질적으로 1행입니다. 셀의 서식은 제가 직접 정리했고, AI는 그것을 스크린샷으로 보고 사용 설명서를 작성했습니다.
• 이 작업의 전부가 통합 문서를 닫지 않고 진행되었습니다. 파일을 닫은 뒤 전달하는 방식으로는 이 대화가 성립되지 않습니다.
• 「AI는 VBA 지식이 풍부하다」는 것은 누구나 깨닫습니다. 본론은 그 너머에 있습니다. 열어둔 채로 대화하며 만들면, 사람이 쓰지 않았을 수준의 도구로 성장한다는 이야기입니다.

한밤중의 작업은 이 한마디에서 시작되었습니다.

AI의 답변은 두 개의 파일명이었습니다. 파일 관리 도구인 「파일 목록.xlsm」과 애드인(Add-in)입니다. 이어서 묻습니다. 「지금 선택하고 있는 셀의 내용, 알고 있나요?」 ── 돌아온 답변은 대화 시트의 B25와 그 내용이었습니다.

제 도구에는 「대화」라는 시트가 있고, AI와의 대화 로그가 자동으로 저장되는 폴더 목록이 나와 있습니다(이 메커니즘은 나중에 설명하겠습니다). B25에 들어있던 것은 다음과 같은 파일명이었습니다.

2026-07-30 12-03 UCY3-c_5i-r-4gYzv89emvrw.md

「내용을 보고 눈치채지 못하겠나요?」라고 묻자, AI는 주변 셀을 읽고 유사한 것들을 나열해 왔습니다. YouTube의 채널 ID가 그대로 파일명이 되어 있는 것. httpsyoutu.be로 시작하는 것. URL을 붙여넣으며 시작한 대화는 URL이 그대로 제목이 되어 있었던 것입니다. 목록만 봐서는 내용을 읽을 수 없습니다.

여기까지가 몇 차례의 대화였습니다. 파일을 다시 연 횟수는 0번입니다.

메커니즘을 먼저 설명하겠습니다. 제 환경에서는 Claude Code의 대화가 끝날 때마다 후크(Hook)를 통해 Python 스크립트가 실행되어, 대화 전문이 Obsidian 보관소에 1회 대화 = 1장의 Markdown 파일로 저장됩니다. 파일명은 「날짜 시각 제목」입니다. 제목은 AI가 붙이지만, 붙이지 못했을 때는 첫 발언의 발췌본이 사용됩니다. URL만 붙여넣으며 시작한 대화는 이 발췌본이 URL이 됩니다 ── 그것이 B25의 정체였습니다.

고치는 방법은 대화로 결정했습니다. 제목의 재료에서 URL과 ID를 제외한다. 발언이 「해설해서 저장해 주세요」와 같은 정형화된 문구뿐이라면, 무슨 내용인지는 AI 측의 답변에 나와 있으므로 그쪽에서 가져온다. AI가 그 자리에서 스크립트를 수정하고, 과거의 실제 데이터 16건으로 판정만 테스트해 보입니다.

구 2026-07-30 12-03 UCY3-c_5i-r-4gYzv89emvrw
신 2026-07-30 12-03 이 채널의 동영상을 모두 저장해서, 내용을

읽을 수 있는 이름이 되었습니다. 여기서 제가 「우선, 선택하고 있는 셀의 분량만큼만 바꿔 보세요」라고 지시하여 1건만 실제 파일을 교체했을 때 ── 이야기가 예상치 못한 방향으로 꺾입니다.

같은 일시의 대화 로그가 또 한 장 있었습니다. 게다가 내용은 동일했고, 그쪽에는 「관료 업무의 실태와 방향성」이라는 제대로 된 제목이 붙어 있었습니다. URL 이름의 파일은 이름이 나빴던 것이 아니라, 같은 대화가 이중으로 저장되어 있던 짝꿍이었습니다.

중복을 청소하는 것만으로 앞으로 나아갈 수도 있었습니다. 거기서 나온 것이 이번 절의 제목인 한 마디입니다(가면 데카(仮面デカ)는 제가 직접 만든 영상 시리즈의 탐정 캐릭터입니다). 원인을 모르는 채 청소해 봤자 다시 쌓인다. 그러니 추적해 달라, 라고 말이죠.

AI는 설정 파일과 로그를 읽고, 몇 분 만에 물증을 제시했습니다. 저장된 로그 중 이 두 줄입니다.

2026-07-30T14:43:14.868 sync :: wrote=1 :: 689eabe8-….jsonl
2026-07-30T14:43:15.671 session=7e25ed71 :: wrote: …YouTubeチャンネル動画一括保存.md

차이는 0.8초. 대화 저장 처리는 두 계통이 있어서(종료 시 실행되는 것과, 다음 실행 시 누락된 것을 회수하는 것), 세션을 닫고 다음 세션을 열면 이 두 가지가 거의 동시에 실행됩니다. 같은 대화를 붙잡습니다. 한쪽은 URL의 발췌 이름, 다른 한쪽은 AI가 붙인 좋은 이름. 서로의 결과를 모르는 채 각각 한 장씩 작성한다──이중 저장의 진범은 바로 이 병행 실행이었습니다. 게다가 한쪽이 주장하는 세션 ID는 실제 파일과 일치하지 않는 유령 ID여서, 옛 이름을 지우는 뒷정리가 헛수고였다는 사실까지 밝혀졌습니다.

대책도 대화로 결정하여 그 자리에서 적용했습니다. 쓰기 작업을 락(Lock)으로 직렬화(Serialization)한다. 쓸 때, 동일한 시작 일시와 본문 내용이 완전히 일치하는 오래된 파일을 회수한다. 실행 시의 회수 처리가 너무 길어서 락을 얻지 못하므로, 1회당 작업량을 줄여 54초를 14초로 단축한다. 적용한 후에는 일부러 두 계통을 동시에 실행하는 재현 테스트까지 수행하여, 새로운 중복이 발생하지 않는 것과 반대로 오래된 중복이 회수되는 것을 확인했습니다.

그리고 전체를 세어보게 했더니, 이중 저장은 URL 이름 파일 정도가 아니었습니다. 72 그룹·94 쌍. 대부분은 '제대로 된 제목끼리의' 중복이었기에 지금까지 눈치채지 못했을 뿐이었습니다. 제목 한 줄을 제외한 본문의 완전 일치만을 근거로 83장을 일괄 삭제했고, 앞서 수동으로 지운 분량을 합쳐 총 100장이 넘었습니다. 남은 대화 로그는 179장. 내용이 같은 것만 지웠기 때문에 대화는 단 한 건도 유실되지 않았습니다.

셀 내용에 대한 잡담 같은 한 마디에서 진범과 재발 방지까지. 여기까지 아마 1시간 정도 걸렸을 것입니다.

청소를 마치고 목록을 다시 뽑아보니, 이번에는 Obsidian의 설정 파일 10개가 목록 맨 앞에 나열되었습니다. 보관함 폴더 안에 .obsidian이라는 설정 폴더가 있고, 목록 매크로는 하위 폴더까지 긁어오기 때문입니다.

AI는 "목록 측에서 제외하는 것은 어떠냐"라는 합리적인 제안을 해왔기에, 저는 제동을 걸었습니다. "그것은 근본을 바꾸는 것입니다"──목록은 그곳에 있는 것을 정직하게 보여주는 도구입니다. 10년 이상 그 규칙으로 키워왔습니다. 표시가 마음에 들지 않는다고 해서 도구의 원칙을 굽히는 것은 본말전도입니다.

그럼 어떻게 할 것인가. 시트별로, 그 시트만 하위 폴더를 긁어오지 않도록 설정할 수 있게 만든다. 이것은 AI의 안이 아니라 제가 내놓은 답입니다. 전체 규칙은 바꾸지 않는다. 각 시트가 자신의 사정을 스스로 갖는다. 매크로에 추가한 코드는 실질적으로 이 한 줄이었습니다.

If ActiveSheet.Range("M1").Value = 1 Then SKIP_SUB = True

여기서부터의 분업이 이번에 가장 쓰고 싶었던 장면입니다. AI가 처음에 배치한 설정 셀에 제가 주문을 넣습니다. "숫자만 넣어서는 알 수 없습니다. L1에 '하위 제외'라고 라벨을 쓰고, M1에 입력하는 형식으로 만드세요". AI가 다시 배치합니다. 이번에는 제가 마우스를 잡고, 기존 라벨과 같은 오렌지색 채우기와 테두리를 그 자리에서 서식에 맞춰 정리합니다. "형식을 조금 더 다듬었습니다. 잘 보세요"라고 말하자, AI는 열려 있는 시트를 스크린샷으로 찍어서 제가 정리한 형태를 확인하고, "설명서 시트의 11번에 설명을 추가해 주세요"라는 지시에 따라 기존 10개 항목과 같은 형식의 매뉴얼을 덧붙였습니다.

솔직히 말하면 셀 서식 정도는 "대부분 제가 하는 게 더 빠릅니다"라고 말했습니다. 실제로 그렇게 말했습니다. 하지만 그래도 괜찮습니다. 빠른 사람이 하면 됩니다. 저는 셀과 서식을 고치고, AI는 코드와 로그와 문서를 고칩니다. 같은 북(Book)을 양쪽에서 동시에 만지고 있는 것이니까요.

덤으로 작은 팁을 하나 드리자면, 수정할 때마다 목록 전체를 다시 불러오면 정렬 순서가 바뀌어서 무엇이 바뀌었는지 눈으로 쫓을 수 없게 됩니다. 그래서 단 1건만 수정할 때는 AI에게 셀을 다시 쓰거나 행을 삭제하는 작업만 시켜서 정렬 순서를 유지하도록 했습니다. 인간이 화면으로 확인할 수 있는 형태를 유지하는 것──이것 또한 운영의 정답 중 하나이며, 코드 어디에도 적혀 있지 않은 내용입니다.

자, 그럼 지금까지의 몇 시간을 성립시켰던 전제를 다시 한번 적겠습니다. 북(Book)은 단 한 번도 닫지 않았습니다.

AI에게 Excel을 다루게 하는 방법은 세상에 여러 가지가 있지만, 흔히 보이는 방식은 "닫힌 파일을 전달하고, 처리한 뒤, 돌려받는" 형태입니다. 라이브러리의 사정상 그렇게 됩니다. 그것이 나쁘다는 뜻은 아닙니다. 무인으로 대량의 파일을 처리한다면 오히려 그쪽이 정답입니다.

다만, 닫힌 파일을 전달하는 방식은 비유하자면 조서만 전달받는 탐정과 같습니다. 현장에는 들어갈 수 없습니다. "지금 내가 선택하고 있는 셀"도 "방금 내 손으로 정리한 서식"도 조서에는 실리지 않습니다. 사건이 끝난 뒤에야 서류로 보고를 받을 뿐입니다.

이번 AI는 현장에 있었습니다. 제가 B25를 보고 있으면 B25를 읽고, 다음에 B37로 옮기면 B37을 다시 읽습니다. 제가 서식을 정리하면 그 화면을 찍어서 확인합니다. 수정은 그 자리에서 실행되며, 결과는 1초 후에 제 눈앞의 시트(Sheet)에 나타납니다. "대화하며 고친다"는 것은 AI가 현장에 있을 때만 성립합니다. 제 도구(VBA 매니저·GitHub에 공개되어 있습니다)가 처음부터 "열려 있는 북에 함께 올라탄다"는 설계인 이유도 바로 이것 때문입니다.

그럼, 제목에 대한 이야기입니다.

[AI 수정] 버튼에 관한 글을 썼을 때, 제가 내세운 셀링 포인트는 "고쳐진다"였습니다. 고장 난 매크로가 버튼 하나로 고쳐져서 돌아온다. 그것만으로도 충분히 사건이었습니다.

하지만 이 밤의 작업을 되돌아보면, 일어나고 있었던 것은 수리가 아니었습니다. 대화 로그의 저장 계통은 원인 자체부터 고쳐졌고, 재발 방지와 테스트까지 따라붙었습니다. Excel에는 새로운 설정 기구가 단 한 줄로 생겨났고, 매뉴얼까지 갖춰졌습니다. 그 어느 것도 "만들어라"라고 설계서를 건넨 적이 없으며, 셀을 바라보며 나눈 잡담에서 시작되어 대화의 왕복 속에서 형태를 갖추게 된 것들입니다.

AI가 VBA나 Windows에 대한 지식을 방대하게 가지고 있다는 사실 자체는 이미 모두가 알고 있습니다. 실제로 제 파일 목록의 핵심인 폴더 순회(Folder traversal)는 AI와 협업하여 다시 작성한 이후, Windows API를 직접 호출하는 비재귀(Non-recursive) 방식으로 돌아가고 있으며, 이는 사무원의 독학 VBA로는 도달할 수 없었던 수준의 코드입니다. 하지만 지식의 풍부함은 입구에 불과합니다. 단 한 번의 지시로 나오는 것은 잘 만들어진 기성품입니다. 대화하며 만들면, 도구는 기성품이 아니라 그 현장의 형태에 맞게 성장합니다. "목록은 정직하게 내놓는 도구", "순서는 바꾸지 않는다", "라벨이 없으면 알 수 없다"──그런, 코드 어디에도 적혀 있지 않은 집안의 규칙들이 대화의 왕복마다 새겨지기 때문입니다.

이전에 "기술의 정답과 운영의 정답은 별개"라고 적었습니다. 이번에 거기에 하나를 더한다면 이렇습니다. 운영의 정답을 전달하는 가장 빠른 수단은, 사양서가 아니라 현장에서의 대화였습니다.

관례대로 분류하겠습니다.

사실: 이 기사의 작업이 2026년 7월 31일 새벽, 단 1회 세션에서 이루어졌다는 점(대화 로그가 남아 있습니다. 오늘 밤부터는 단 한 장뿐입니다). 저장 로그의 0.8초 차이와 병행 재현 테스트. 중복 72그룹·94쌍, 일괄 삭제 83장, 정리 후 179장(숫자는 공개 전에 재확인합니다). 매크로에 추가된 내용이 실질적으로 1행이라는 점. 작업 중 북을 닫지 않았다는 점.

견해: AI에게 Excel을 다루게 하는 공개 사례의 대부분이 닫힌 파일 방식이라는 관측(망라적 조사는 아닙니다. 이 영역의 지도는 이전에 측정했습니다 = 링크는 게재 순서 확정 후 교체). "대화하며 만들면 도구가 현장의 형태로 성장한다"는 주장 그 자체.

열려 있는 방식이 만능은 아닙니다. COM으로 조작할 수 있는 로컬 Excel과, 화면 앞에 인간이 있다는 전제가 필요합니다. 무인 배치 처리(Batch processing)나 대량 파일의 일괄 변환이라면 닫힌 파일을 전달하는 방식이 적합합니다. 이번 Obsidian 측의 수정도 Python 스크립트에 관한 이야기이며, VBA만으로 한 이야기가 아닙니다. 그리고 이 "파일 목록" 북 자체는 이전에 썼듯이 미공개 상태로 유지됩니다.

덧붙여, 솔직히 고백하자면 이 밤의 초반에 저는 AI의 답변이 느리다고 투덜거렸습니다. 대화하며 만든다는 것은, 그런 거리낌 없는 거리감까지 포함하는 것입니다.

서두에서 링크한 「대화하는 것만으로 매크로가 고쳐진다」는 개발 환경 이야기는 3분 반 분량의 영상으로도 만들어 두었습니다. 합성음성 (Synthetic Voice) 캐릭터 두 명이 대화를 주고받으며 해설하는 형식입니다.

그리고 고백하자면, 이 영상 자체도 AI와의 대화를 통해 거의 자동으로 구성된 것입니다. 대본 텍스트를 한 장 쓰면, 음성 합성 (Speech Synthesis)부터 스탠딩 일러스트 (Standing Illustration), 영상 조립에 이르기까지 AI와 함께 키워온 파이프라인 (Pipeline)이 작동합니다. 「대화하는 것만으로 만들 수 있는」 것은 매크로뿐만이 아니었습니다. 이 제작 메커니즘에 관한 이야기도 언젠가 쓰게 될지도 모릅니다.

탐정은 현장에 없으면 일을 할 수 없습니다. 조서를 아무리 쌓아두어도, 0.8초의 물증은 현장의 로그 (Log) 안에만 있었습니다.

AI를 현장에 투입하는 선을 1년 동안 계속 그어오며, 이 밤, 그 선 너머에 「고쳐진다」가 아닌 「만들 수 있다」가 기다리고 있었다는 것을 알게 되었습니다. 다음에는 드디어, 여러 번 예고했던 「AI 요약 설명」을 쓰겠습니다. 아마도요.

현장 보고는 이상입니다.