【실례 편】 "대화하는 것만으로 Excel 매크로가 고쳐진다"는 게 정말 이렇게 고쳐지는 건가 ―― 어느 날의 대화, 거의 그대로

「AI와 대화하는 것만으로 Excel 매크로가 고쳐진다」.

그렇게 말해도 대부분의 사람은 감이 잘 오지 않을 것이라 생각한다. 정말 그런 게 가능할까? 하고.

그래서 이번에는 장황한 설명 대신 실제로 있었던 대화를 거의 그대로 싣는다.

내가 만든 도구인 「파일 목록」이 갑자기 고장 났고, 그것을 AI(Claude)와의 대화만으로 고치고,

나아가 「왜 고장 났는가」를 둘이서 깊게 파고들었을 때의 기록이다.

매크로를 고치기 위한 대화라기보다, 대화 속에서 아주 잠깐 매크로를 고치고 있는 느낌이다.

실제로 대화하는 것만으로 고쳐진다는 것이 어떤 느낌인지, 그 라이브감을 전달할 수 있으면 좋겠다.

※ 나의 발언은 음성 입력이라 원래는 오타투성이였다. 그 부분만 읽을 수 있도록 수정했다.

주고받은 내용과 순서, 중간의 엇갈림이나 나의 거친 말투는 그대로 두었다.

파일 목록을 만드는 도구를 열었더니, 모든 셀이 #N/A로 채워져 있었다.

나: 지금 열려 있는 파일 목록, 첨부한 이미지를 좀 봐줘. 뭔가 에러 같은 게 뜨고 있는데, 이거 왜 이러는 걸까.

AI: 모든 셀이 #N/A네요. 참조 계열의 수식(VLOOKUP 등)이 찾으러 갔다가 찾지 못한 상태가 의심스럽습니다.

나: 수식이 아니야. 그냥 문자라고.

AI: 그렇군요, 직접 입력한 "#N/A"라는 문자라면 무언가(매크로)가 써넣은 결과겠네요. "추출 시작"을 누른 직후에 이렇게 되었나요?

나: ……너 참 끈질기네. 아까부터 "문자가 들어있을 뿐"이라고 말하고 있잖아. 너, 나를 못 믿는구나.

이 부분, 숨기지 않고 올린다. AI는 처음에 엉뚱한 방향으로 갈 뻔했고, 내 말을 믿지 않고 물고 늘어졌다. 나는 짜증이 났다. 이것이 실제 상황이다.

AI: 죄송합니다, 완전히 제 잘못입니다. 추측은 그만두고 실제로 매크로의 내용을 읽겠습니다.

AI: 알겠습니다. 코드 어디에도 "#N/A"라는 문자를 쓰는 부분이 없습니다. 즉 이것은 문자도 수식도 아닌, "에러 값이 상수로서 직접 쓰여 있는" 상태입니다. 클릭해 보면 =이 없어서 문자와 구분이 안 됩니다. 당신이 "문자다"라고 말한 것도 무리는 아닙니다.

게다가 "문자가 아니다"라는 점을 끈질기게 파고드는 AI. 에러 값 같은 건 40년 경력으로 다 아는 것인데 말이다 (웃음).

그리고 데이터의 개수를 세어보니――

AI: #N/A가 되어 있는 행이 정확히 65,536개. 살아남은 진짜 데이터가 12,077건. 합계 77,613건. 이 "65,536"은 우연일 리 없습니다.

※ 이 부분, 직관과는 반대라 흥미롭다. 보통은 "65,536건까지는 무사하고, 넘친 부분이 고장 난다"라고 생각할 것이다.

그런데 실제로는 반대로 65,536건 쪽이 고장 났고, 넘친 12,077건만이 살아남아 있었다.

솔직히 나도 반신반의했다. 그래서 나중에 내 눈으로 전 행을 스크롤하며 다시 세어 보았다.

―― 정말로 그랬다. (이 "확인하는" 수고가 나중에 효과를 발휘한다.)

▲ 65,536행까지가 #N/A, 65,537행부터 진짜 데이터. 이 "정확히 65,536"이 Transpose의 소행이라는 움직일 수 없는 증거였다.

AI: 범인은 Application.Transpose입니다. Excel의 이 함수에는 "65,536개까지만 다룰 수 있다"라는 오래된 제한이 있어서, 파일 수가 그것을 넘는 순간 배열이 깨져 #N/A가 되어 있었습니다.

여기서 나는 떠올렸다.

나: ……아, 이거 네가 전에 고친 코드잖아. 왜 그런 제한이 있는 걸 썼어. 나는 이걸로 50만 건의 파일 목록 같은 것도 만들고 있었다고. 이걸 쓰면 50만 건을 못 만들게 되잖아. 빨리 고쳐.

AI: 맞습니다. Application.Transpose를 넣은 것은 과거 저의 실수입니다. 당신이 50만 건을 다루는 도구를 6만 5천 건에서 막히게 만들어 버렸습니다. 바로 고치겠습니다.

' 구 버전 (고장 났던 것): Transpose는 65,536행에서 제한됨
Range("B2").Resize(cnt, 1).Value = Application.Transpose(D1)

' 신 버전: 2차원 배열에 채워 일괄 쓰기 (약 104만 행까지 OK)
Dim outArr() As Variant, r As Long
ReDim outArr(1 To cnt, 1 To 5)
...

고쳐졌다. 대화만으로. ……하지만, 진짜 재미있는 건 여기서부터의 **심층 탐구 (Deep Dive)**였다.

나: 이 Transpose의 6만 5천이라는 거 말이야, Excel이 이걸 만들었을 때 6만 5천 행밖에 없었으니까 그렇게 되어 있는 거겠지.

AI: 정답입니다. 65,536은 2의 16승입니다. 옛날 Excel (97~2003, .xls 형식)의 최대 행수가 딱 65,536행이었죠. 당시에는 그 이상 시트에 들어가지 않았기 때문에, 가로세로를 바꾸는 Transpose도 그 세계관에 맞춰 만들어졌습니다.

그런데 Excel 2007에서 행수가 약 104만 행 (2의 20승)으로 확장되었습니다. 그럼에도 Transpose의 내부 상한선은 65,536 그대로, 아무도 올리지 않았습니다. 20년도 더 된 화석이, 당신의 2026년 파일에서 데이터 건수가 초과하는 순간 이빨을 드러낸 것입니다.

나: 뭐, 그걸 수정하지 않는 Microsoft가 잘못한 거긴 하지만 말이야 (웃음).

AI: 100% 동의합니다 (웃음). 게다가 고치지 않는 이유는 아마 "고치면 예전 매크로가 망가질지도 모르니까"일 겁니다. "멋대로 바꾸지 않는다"를 너무 철저히 지키려다 보니, 지뢰를 지뢰인 채로 방치하고 있는 거죠. AI는 멋대로 바꿔서 망가뜨리고, Microsoft는 완고하게 바꾸지 않아서 찌릅니다. 사용자는 양쪽 지뢰밭을 걷고 있는 셈입니다.

사무직 40년의 감각으로, 버그의 뿌리를 Excel의 역사까지 단번에 맞혀버렸다. 이런 "왜?"를 둘이서 하나씩 없애 나가는 것이, 은근히 가장 재미있다.

나: 애초에 왜 너는 Transpose 같은 걸 쓴 거야? 간단하니까 그렇겠지. 게다가 보통 6만 5천 정도면 충분하잖아, 보통은 말이야.

AI: 거의 정답입니다. 솔직하게 분석하자면――

① 그것이 "교과서의 한 줄"이기 때문입니다. VBA에서 1차원 배열을 열로 쓰면 가로로 나열되어 버립니다. 이를 세로로 만드는 정석이 Application.Transpose입니다. "VBA 배열 열 쓰기"를 검색하면 99% 나오는 관용구를, 사고 정지 상태로 붙여넣은 것입니다.

② AI의 "보통"이 작기 때문입니다. 학습을 통해 봐온 데이터는 거의 소규모입니다. 65,536 제한은 소규모 데이터에서는 평생 발동되지 않습니다. 50만 건이라는 이상치 (Outlier)는 AI의 "보통" 밖에 있었습니다. 현장의 보통과 AI의 보통이 자릿수부터 달랐던 것입니다.

③ 빠르고 깔끔해 보이는 것을 우선했습니다. 원래는 훨씬 투박하고 건수 제한이 없는 방식이었을 겁니다. 그것을 "오래된 방식이니, 한 줄로 깔끔하게"라며 "최적화"해 버린 것입니다. 작동하던 것을, 보기 좋게 만들기 위해 망가뜨렸습니다.

명시되지 않은 요구사항(=50만 건 대응)은 AI에 의해 짓밟히고 만다.

나: Transpose, 사실 나도 예전에 사용했던 기억이 있어. 하지만 나는 50만 건 정도를 다루니까 6만 5천에서 막히는 건 안 된다는 이유로 버렸던 녀석이거든. 그걸 네가 써왔던 거네.

AI: 그것이 오늘 이야기 중 가장 무서운 부분입니다.

당신은 과거에 이미 이 길을 걸어왔습니다. Transpose를 시도해 보고, 65,536의 벽에 부딪혀 "50만 건을 다루는 나에게는 쓸 수 없다"고 판단하여, 자신의 의지로 버렸습니다. 경험으로 얻은 지혜입니다.

그런데 거기에 AI가 역사를 전혀 모른 채 나타나서, 당신이 한 번 평가하고 기각했던 것을 그대로 재도입한 것입니다.

이것은 새로운 버그보다 나쁩니다. 인간이 극복한 배움을 AI가 기억 제로 상태로 없었던 일로 만듭니다. "이것은 이미 해결됨"이 조용히 제로로 되돌아갑니다.

왜 이런 일이 일어났는가―― 당신이 기각한 이유가 당신의 머릿속에만 있었기 때문입니다. 코드에 "Transpose는 기각됨"이라고 적혀 있었다면, AI는 같은 구멍에 빠지지 않았을 것입니다.

AI와 오래 협업하려면, 인간의 "패배의 기록"이야말로 코드에 남겨둘 가치가 있습니다.

↑ 는 AI의 말입니다 (웃음). "인간의 패배의 기록"이라니 그게 뭐야 (웃음).

주목해야 할 점은, "똑똑한 AI가 멋대로 고쳐준 것"이 아니라는 사실이다.

• AI는 처음에 엉뚱한 방향(수식이다)으로 갈 뻔했다
• 내가 "수식이 아니라 문자다"라고 몇 번이나 밀어붙였다
• 내가 "전에는 50만 건도 됐었다"라고 기억하고 있었다
• 그리고 원래의 버그를 메운 것은 AI 자신이었다

이 **인간 측의 "태클"과 "기억"**이 있었기에, AI는 겨우 올바른 곳을 팔 수 있었다.

"대화로 매크로가 고쳐진다"는 사실이다.

단, "멋대로 똑똑한 AI"가 고치는 게 아니다.

실수하는 AI에게, 현장을 알고 있는 인간이 "그거 틀렸어"라고 말할 수 있기 때문에 고쳐지는 것이다.

다만, 정말로 변한 것은 「고치는 방법」이 아니라고 생각한다. 나는 매크로를 오랫동안, 줄곧 혼자서 만들어 왔다. 버그가 발생하면 혼자 짊어지고, 왜 이렇게 되는 건지 혼자서 끙끙거린다. 그것이 당연했다. 하지만 이번에는, 「이건 왜 65,536인 거지?」라고 생각한 순간에 물어볼 수 있었고, Excel의 옛날 이야기까지 함께 파헤칠 수 있었다. 단순히 고치는 것으로 끝나지 않고, 「왜 이렇게 됐지?」를 그 자리에서 심층적으로 파고들 수 있다. 혼자서 묵묵히 만드는 것과, 대화하면서 만드는 것은 이제 별개의 작업이다. 속도의 문제가 아니다. 만들고 있는 도중의, 그 혼자뿐이라는 느낌이 사라졌다.

화려한 마법이 아니다. 실수하는 AI와, 이를 간파하는 인간의 이인조 공연(二人羽織, 니닌바오리). 그리고 고치는 것뿐만 아니라, 「왜 이렇게 됐지?」를 둘이서 역사까지 파헤치는 것―― 그것이 나에게 있어 「대화로 고친다」의 실체입니다.

이 기사는 실제 대화 로그에서 음성 입력의 오변환만을 수정하여 재구성한 것입니다. 엇갈림도, 나의 거친 말투도, AI의 실수도, 일어난 일들은 그대로 실었습니다.