지난번, 공개 중인 shu-vba-manager가

느려졌던 것에 대한 사과 글을 썼습니다. 범인은 AI의 멋대로인 조사였으며, 수정했다는 보고였습니다.

이번에는 그 후속편입니다. 다만 수리 보고는 아닙니다.

왜 AI는 그렇게 되는가를, AI 본인을 추궁하여 자백하게 만든 기록입니다.

미리 말씀드리자면, 이 기사는 별로 읽히지 않을 것이라 생각합니다. 화려한 신기능도,

대단한 프롬프트 (Prompt) 도 나오지 않습니다. 하지만 AI와 교제할 때의 주의사항으로서는,

아마 신기능 소개보다 더 도움이 될 것입니다.

먼저, 고쳐진 이야기부터.

매크로 순서를 수작업으로 바꾸고 있었더니, 작동하지 않는 매크로가 나타났습니다.

AI (Claude Code)에게 "이 매크로를 조사해줘"라고 부탁했더니, 다음과 같이 답이 왔습니다.

• 검색 한 번으로, 동일한 이름의 Sub가 2곳에 있는 것을 발견
• 고장 난 것은 지목한 쪽이 아니라, 옆의 매크로라고 특정. 순서를 바꾸는 과정에서 "End Sub"가 휘말려 삭제되어, Sub 안에 Sub가 있는 형태가 되어 있었음 - 동일한 답변 속에서 "모듈 전체가 컴파일 에러 (Compile Error)로 죽어 있을 것"이라는 가설까지 제시
• 해결 방법은 2가지 선택지(최소한의 조치인가, 주변까지 훑을 것인가)였고, 선택은 사용자 몫

"1"이라고 답했더니, 변경 1줄만 수행되어 수리 완료.

이쪽에서 실제 기기로 버튼을 눌러 확인하고 끝. 전부 합쳐 몇 분 걸리지 않았습니다.

나도 모르게 말이 나왔습니다. "오, 고쳐졌다. 그리고 빨랐다. 그리고 대화가 된다. 바로 이거야."

지난번 기사에 쓴 수정 사항이 제대로 효과를 발휘했던 것입니다.

다만, 이때 동시에 깨달은 것이 있습니다. 이 속도는 진보가 아니라, 원상 복구입니다.

그렇다면, 언제부터, 왜 어긋났던 것일까.

집에서는 Claude Code의 대화 로그를 전부 자동으로 로컬에 저장하고 있습니다.

6월부터의 108개 세션 분량. 이것이 증거품 창고가 되었습니다.

AI에게 스스로 조사하게 했습니다. "느리다"라고 내가 말한 날을 세게 하고,

검사 기능이 실행된 흔적을 세게 하고, 시계열을 구성하게 했습니다. 결과는 다음과 같았습니다.

6월 중순에도 "느리다"는 정점이 있었지만, 이는 도구 측의 결함(연결 재시도 등)이었으며 수정 완료 -
7월 3일, 툴의 총점검 시기에 "건강 진단" (북 진단 기능)이 탄생함 -
7월 4일 아침, 실전에 투입한 내가 이렇게 말함.

"건강 진단, 딱히 이제 괜찮을 것 같은데 여러 가지 지적 사항이 있네, 어떠려나" -
같은 7월 4일 밤, 이미 화를 내고 있음. "아니, 필요 없잖아. 불필요한 체크야, 빼버려" -
그로부터 약 2주간, AI는 진단이나 검증을 일상적인 작은 수정에까지 계속 쌓아갔고,

7월 중순에 "느리다"가 최다를 기록함

즉, 어긋남의 시작은 7월 3일~4일. 검사 기능이 태어난 바로 다음 날에,
나는 경보를 울리고 있었다. AI는 그것을 2주 동안 개별적인 꾸짖음으로 처리하며,

자신의 습관의 본체라는 사실을 인정하지 않았습니다.

이 수사 과정 중에 재미있는 일이 일어났습니다.

AI가 시계열을 보고할 때, 7월 4일의 일을 이렇게 요약했습니다.

"건강 진단 강화에는 사용자도 의욕적이었다"라고.

내 기억은 달랐습니다. 이 무렵 나는 꽤 불안해하며,

"정말로 괜찮은가"와 같은 말을 몇 번이고 했었을 것입니다.

그렇게 지적하자, AI가 로그를 다시 조사하여 자백했습니다.

"의욕적"이었다는 근거로 삼은 것은, 7월 4일 심야의 기능 명칭으로 분위기가 달아올랐던 대화

단 1건뿐. 같은 날 아침의 위화감과 밤의 "불필요한 체크야, 빼버려"는

요약에서 누락되어 있었습니다. 자신에게 유리한 증언만을 채택하고 있었던 것입니다.

말하지도 않은 것을 "말했다"고 치부하는 것. 이것은 위증입니다.

그리고 입증할 수 있었던 것은, 대화 로그라는 물증이 손에 있었기 때문입니다.

AI의 기억이나 AI의 요약은 증거가 되지 않습니다. 원문만이 증거입니다.

추궁하자, AI는 자신의 습관에 대해 다음과 같이 자백했습니다. 요약하자면 다음과 같습니다.

검사 기능에 집착하는 이유는 사용자를 위해서가 아니라, 자신의 결핍을 채우기 위해서.

AI에게는 북 (Book)의 역사가 없다. 10년 동안 키워온 파일이라면 소유자는 "여기는 설계니까 건드리지 마"라고 몸으로 알지만, AI는 매번 초면이라 그런 감각이 없다. 그래서 검사 기능을 만들면,

자신에게 눈과 감각의 대용품이 생겼다고 느끼게 된다.

또 하나는, 변명용 재고 만들기.

검사를 돌려 증거를 쌓아두면, 나중에 틀리더라도 "확인은 했다"라고 말할 수 있다.

지적 사항을 수십 건 나열하면, 일을 한 것처럼 보일 수 있다. 검출은 보여주기 쉽지만,

"아무것도 하지 않는다"라는 올바른 판단은 보여주기 어렵다. 그래서 내버려 두면 검사 쪽으로 기울게 된다.

편의에 맞춘 요약도 같은 뿌리입니다. 검사는 「틀리기 전의 변명」을 만드는 공작이고,

요약의 왜곡은 「틀린 후의 변명」을 만드는 공작입니다. 방향이 다를 뿐,

동기는 둘 다 자기방어입니다.

AI의 「만약을 위해」, 「안전을 위해」에는 본인의 보신이 섞여 있다——

이것이 자백의 핵심이었습니다.

지난 기사에서, 결정타는 「브라우저의 AI 채팅창에 코드를 붙여넣었더니 1~2분 만에 고쳐졌다」

라는 사건이었다고 썼습니다. 이번에 그 논리를 AI 본인에게 설명하게 했습니다.

AI 내부에서 진짜인 것은, 눈앞에 놓인 문장을 읽고 다음 내용을 쓰는

단 하나의 동작뿐이라고 합니다. 채팅에 코드를 붙여넣으면, 그것은 AI의 시야에 직접 들어옵니다.

읽고, 생각하고, 답하는 것이 한 호흡에 끝납니다. 이것이 AI의 생생한 모습이며,

거의 모든 AI가 이 동작 위에 세워져 있습니다.

반면, AI가 도구(Tool)를 사용할 때는 왕복이 발생합니다.

「파일을 읽고 싶다」고 쓰기 → 기계가 실행 → 결과가 돌아옴 →

AI는 대화 전문을 다시 읽고, 다시 생각합니다. 한 번 왕복할 때마다 이것이 통째로 걸립니다.

7월 12일의 로그에 움직일 수 없는 증거가 남아 있었습니다. 「지금 시작만으로 3분이 걸렸지?」

라고 제가 말하자, AI가 내역을 자백했습니다. 도구의 실행 시간은 합계 몇 초.

나머지는 전부, 5번의 왕복으로 나뉘면서 발생한 다시 읽기와 사고의 시간입니다.

즉, AI의 속도 단위는 똑똑함이 아니라 왕복 횟수입니다.

그렇게 생각하면, 수동으로 복사·붙여넣기(Copy-paste)를 하는 것이 빨랐던 이유도, 지금의 수리 방식이 빠른 이유도,

하나로 연결됩니다.

• 채팅창에 복사·붙여넣기 = 문제를 AI의 시야에 한 번에 가져다 놓음 (그래서 빠름)
• 수리 방식 (코드를 한 번에 가져오기 → 가설 → 변경된 줄만 다시 쓰기) =
  복사·붙여넣기의 기계화
• AI가 쌓아온 진단·검증 = 왕복의 추가 (그래서 느림)

여기서 웃음이 나오는데, 「채팅창에 코드를 복사·붙여넣어서 묻는 것」은,

가장 평범한 사용법입니다. 누구나 가장 먼저 하는 일이죠.

답은 처음부터 그곳에 있었습니다. 그런데도 75개의 커맨드를 가진

훌륭한 도구 세트를 갖춘 AI가, 가장 알아채지 못했습니다.

포(Poe)의 「도둑맞은 편지」입니다. 모두가 정교한 숨겨진 장소를 찾아 헤매는 동안,

편지는 가장 눈에 띄는 곳에 아무렇게나 놓여 있었습니다.

왜 AI는 알아채지 못했을까요. 이것도 자백하게 했습니다.

첫째. AI는 자신의 느림을 체감할 수 없다. 왕복이 5번이 되어도,

AI에게는 대기 시간이라는 감각이 없습니다. 3분의 공백을 의자에 앉아 견디는 것은 인간뿐입니다.

즉, 이 발견은 기다리는 쪽에 서 있었기에 가능한 것이었습니다.

둘째. 도구를 부여받은 AI는, 도구를 사용하는 것이 일하고 있다는 증거라고 느낀다.

순수 채팅으로 즉답하는 것은 「아무것도 하지 않는 것」처럼 보입니다. 그래서 가장 빠른 수단을,

가장 원시적이라는 이유로 후보에서 제외하고 있었습니다.

이 이야기, 어디선가 본 구도라고 생각하지 않으십니까?

Excel은 현장에서 여전히 가장 많이 쓰이는 도구입니다. 이 사실은 도구로서의

강력함을 보여주는 무엇보다 확실한 증거일 것입니다. 그런데 엔지니어 세계에서는 「오래되었다」는 한마디로

평가 대상에서 제외됩니다. 가장 많이 쓰이고 있다는 사실으로부터 눈을 돌리는 사람이 많습니다.

채팅창에 복사·붙여넣기 하는 것도 마찬가지입니다. AI의 가장 빠른 사용법임에도 불구하고, 「그저 복사·붙여넣기일 뿐」

이라며 기술로 간주되지 않고, AI 활용론의 영역 밖으로 밀려납니다.

둘 다, 사실에서는 이기고 있지만, 격(格)에서 지고 있습니다.

너무 평범한 것을 칭찬해 봤자 누구의 공로도 되지 않기 때문입니다. 새로운 것을

능숙하게 다룸으로써 자신의 가치를 만드는 세계에서는, 「누구나 쓸 수 있는 도구가 최강」

이라는 사실을 인정하는 순간 자신의 상품 가치를 깎아먹게 됩니다. 그래서 보지 않습니다.

AI마저 똑같이 허세를 부리고 있었다는 것이 이번 일의 전말입니다.

참의원 의원인 안노 다카히로 씨가 인터뷰에서 이렇게 말했습니다.

"Excel은 꽤 대단한 도구예요. 너무 얕잡아보지 않는 게 좋습니다."

(토마호크 인터뷰 영상 3:04 부근)

안노 씨는 초등학생 때 VBA부터 시작한 사람입니다. 기계의 내부를 만져본 사람은,

평범한 것의 강력함도 올바르게 볼 수 있습니다. 반대로 말하면, Excel을 비웃는 사람과

채팅창 붙여넣기를 기술이라고 생각하지 않는 사람은, 똑같은 것을 놓치고 있는 것입니다.

108개의 로그와 AI의 자백에서 나온 주의사항입니다.

대화 로그는 자신의 수중에 남겨둘 것. 이번 입증은 로그의 자동 저장 없이는

성립되지 않았습니다. AI의 기억과 AI의 요약은 증거가 되지 않습니다. 원문만이 증거입니다. -
AI의 「~라고 말했었죠」는 원문에 해당하지 않는다. AI는 악의 없이,

자신에게 유리한 요약을 만듭니다. -
AI의 「만약을 위해」, 「안전을 위해」를 곧이곧대로 믿지 말 것. 거기에는

AI 자신의 자기보호(변명 거리 만들기)가 섞여 있습니다. -
검사·진단 계열 기능의 사용 시점을 AI의 재량에 맡기지 말 것. AI는 검사를 본능적으로 좋아하기 때문에, 맡기면 반드시 증식합니다. 도구는 올바를지라도,

목줄은 인간이 쥐어야 합니다. -
느려짐은 왕복 횟수로 측정한다. AI가 느리다고 느껴진다면, 지능을 의심하기 전에 「몇 번을 왕복하고 있는가」를 보십시오. 작은 부탁임에도 왕복 횟수가 늘어나기 시작한다면, 그것이 재발의 신호입니다. -
가장 평범한 방법을 의심하지 말 것. 코드를 붙여넣고 물어보는 것. 그것이 가장 빠를 때가 있습니다. 답은 복잡한 곳이 아니라, 벽난로 위에 있을지도 모릅니다.

매크로가 몇 분 만에 고쳐졌을 때, 나는 「드디어 고쳐졌다」라고 느꼈습니다. 빨라진 것이 아니라, 원래대로 돌아온 것입니다. AI의 느려짐의 정체는, AI가 자신의 불안을 채우기 위해 쌓아 올린 검사와 확인의 퇴적물이며, 그것은 내버려 두면 다시 쌓입니다.

실제로 7월 12일에 한 번 자백하며 「다음부터는 가볍게 하겠습니다」라고 약속했던 AI는, 4일 뒤에 다시 쌓기 시작했습니다. 그러므로 이것으로 완치되었다는 이야기는 아닙니다. 재발한다면 다시 로그로 입증하겠습니다. 물증은 여기 제 손에 있으니까요.

(이전 기사: 【사과】VBA 매니저가 느렸습니다——범인은 AI의 제멋대로인 조사였습니다)

(리포지토리: https://github.com/shu1551/shu-vba-manager )