이 연재는 「대화만으로 매크로를 고친다」에서 시작되었습니다. 다음으로 「대화만으로 폼을 만들 수 있다」를 썼습니다.

이번에는, 대화만으로 게임을 만들 수 있다는 이야기입니다.

팀 미라이(Team Mirai)의 안노 타카히로(安野貴博) 씨가 프로그래밍의 원점을 이야기한 인터뷰를 읽었습니다. 초등학교 3학년 때 아버지의 Windows 98을 만지며 Excel의 수식을 만지다 보니 VBA에 도달했고, 독학으로 게임까지 만들었다는 이야기입니다 (아사히 초등학생 신문 WILLナビnext 인터뷰).

국회의원이 된 엔지니어의 입구가 Excel 게임이었다. YouTube에서 "Excel VBA는 무시할 수 없습니다"라고 말하는 것을 본 기억도 있습니다.

저는 Excel VBA를 40년 가까이 실무에서 사용해 왔지만, 그러고 보니 게임을 만들어 본 적이 없었습니다. 그래서 만들어 보기로 했습니다. 리버시(오셀로)입니다.

• Excel VBA 리버시를 Claude Code와의 대화만으로 만들었다
• 코드는 한 줄도 쓰지 않았다. 대신 「불만」을 잔뜩 말했다
• 게임의 요구사항은 「쾌적함」이므로, 사양서보다 대화가 적합하다
• 후반부는 도구 측의 이야기. AI는 수정도 하지만 버그도 만든다. 그것도 대화와 검토를 통해 고쳐서 다시 공개했다

완성된 북(Book)은 GitHub에 올려두었습니다: reversi-excel. 매크로 24개, 표준 모듈 1개. 다운로드하면 이 기사의 이야기를 실물로 확인할 수 있습니다.

「Excel로 리버시를 만들어줘」라고 하면 플레이할 수 있는 것은 나옵니다. 판은 셀, 돌은 도형, 칸을 클릭하면 수가 놓이고 컴퓨터가 응수한다. 난이도는 3단계. 여기까지는 솔직히 쓸 내용이 별로 없습니다.

재미있는 것은 그 이후입니다. 플레이해 보니 세세한 부분이 신경 쓰이기 시작합니다. 거기서부터가 대화의 본론이었습니다.

먼저, 마음을 다잡고 플레이하려 했더니 에러가 발생했습니다. 실행 시 에러 1004, 「변경하려는 셀이나 그래프가 보호된 시트 위에 있습니다」.

AI의 설명은 이러했습니다. 시트는 판을 보호하기 위해 보호되어 있으며, 매크로만 쓸 수 있는 플래그(UserInterfaceOnly)를 세워두었다. 그런데 이 플래그는 북을 저장해도 남지 않는다. 닫았다가 다시 열면 보호만 남고 매크로를 쓸 수 없게 된다 —— VBA의 고전적인 함정이라고 합니다.

열 때 플래그를 다시 세우는 수정안이 나와서 그것으로 고쳐졌습니다. 다만, 이번에는 상관없는 셀에 글자를 입력할 때마다 보호 경고가 뜹니다. 저는 이렇게 답했습니다.

좀 더 간단한 느낌으로 해버리는 게 좋지 않을까

답은 「보호를 중단합시다」였습니다. 게임 입력은 클릭 감지 매크로가 수행하고 있으므로, 보호가 없어도 게임은 성립한다. 판이 망가져도 「처음부터」 버튼으로 다시 만들 수 있다. —— 사양 하나가 대화로 사라졌습니다.

보호를 해제하니 칸을 더블 클릭했을 때 작은 「0」이 보이게 되었습니다. 물어보니, 판의 칸은 내용물로 0(빈칸)/1(검은색)/2(흰색)의 숫자를 가지고 있으며, 표시 형식으로 숨겨두었을 뿐이라고 합니다. 편집 모드에 들어가면 실제 값이 보이고 만다는 것입니다.

실질적인 해악은 없다는 설명이라 「뭐, 이걸로 됐어」라고 말하려 했으나, 더블 클릭 시 편집 모드로 들어가는 것만 조용히 막는 3줄의 코드가 제안되어 적용했습니다. 팝업도 아무것도 뜨지 않습니다. 그저 조용히, 아무 일도 일어나지 않게 됩니다. 이런 식의 수정 방식이 취향입니다.

컴퓨터가 생각하는 동안 마우스 커서가 빙글빙글 돕니다. 이건 어쩔 수 없는 거냐고 물었더니, AI는 차례 칸에 「생각 중...」이라고 표시하는 안을 구현해 왔습니다.

저는 이렇게 답했습니다.

그런 눈에 띄는 느낌을 없애고 싶은 거니까, 그런 「생각 중」 같은 건 최악의 수입니다

즉시 철회되었습니다. 이 부분은 기사로서 남겨두고 싶은 대목입니다. AI의 제안은 덧셈 쪽으로 기울어집니다. 무언가 신경 쓰인다고 하면, 표시를 더하거나, 메시지를 더하거나, 연출을 더하는 방향의 안이 나옵니다. 하지만 제가 원했던 것은 뺄셈 —— 화면에서 불필요한 것을 줄이는 것 —— 이었습니다. 뺄셈의 판단은 현재로서는 인간의 몫입니다.

돌(도형)이 클릭으로 선택되어 버리는 문제에는 「아무것도 하지 않는 매크로를 돌에 할당한다」는 수가 사용되었습니다. 도형에 매크로를 할당하면 클릭해도 선택 상태가 되지 않기 때문입니다.

그런데 AI는 이것을 판 전체를 덮는 투명한 장식 틀에까지 할당했습니다. 채우기가 없는 도형은 평소 안쪽을 클릭하면 통과합니다. 하지만 매크로를 할당하는 순간, 도형 전체가 버튼화되어 판의 어디를 클릭해도 틀이 클릭을 가로채게 됩니다. 즉 게임이 완전히 죽어버렸습니다.

「완전히 망가져서 게임을 할 수 없게 되었는데요」라고 전하자, 원인을 특정하여 틀(frame) 할당만 해제하고 원래대로 돌아왔습니다. AI는 자신의 실수라고 시인했습니다. 대화로 만들면, 망가뜨리는 것도 대화 속에서 이루어지기에 고치는 것도 빠릅니다. 그 점은 공정하게 적어두겠습니다.

마지막이 가장 압권입니다. 수정 검증 중에 AI가 묘한 말을 꺼냈습니다. 판 위의 돌은 많아야 64개여야 하는데, 시트에 도형이 434개 있다는 것입니다.

범인은 이 한 줄이었습니다.

If Left(shp.Name, 5) = "リバーシ石_" Then shp.Delete

돌 도형은 「リバーシ石_4_4」와 같은 이름으로, 재그리기(redrawing)를 할 때마다 오래된 돌을 지우고 다시 배치하는 구조입니다. 그런데 「リバーシ石_」는 6글자입니다. 이름의 왼쪽 5글자와 비교하고 있으므로, 이 조건은 영원히 성립하지 않습니다. 즉, 돌은 한 번도 삭제되지 않았고, 재그리기를 할 때마다 같은 위치에 겹쳐서 놓이고 있었습니다. 돌이 완전히 겹치기 때문에 겉보기에는 절대로 눈치챌 수 없습니다.

비교문을 Like "リバーシ石_*"로 고치고 초기화를 실행하자, 도형은 정확히 10개(틀, 제목, 버튼 4개, 초기 돌 4개)가 되었습니다. 한 수를 두고, 셀의 돌 개수와 도형의 개수가 일치하는지까지 기계적으로 대조하여 결판을 냈습니다.

겉모습은 완전히 정상인 채로, 파일 내부만 조용히 비대해져 갑니다. 이런 종류의 버그는 동작 테스트로는 영원히 찾을 수 없습니다. 도형의 '점호(roll call)'——수를 세는 것이라는 원시적인 검사——만이 찾아낼 수 있습니다.

저는 이 리버시(Reversi)를 만들면서 코드를 한 줄도 쓰지 않았습니다. 대신에 말한 것은 이런 것들이었습니다.

• 좀 더 간단한 느낌으로 만드는 게 좋지 않을까
• 그런 식으로 만들어도 괜찮아?
• 그런 '생각 중' 같은 건 최악의 수야
• 완전히 망가져서 게임을 할 수 없게 되었는데요

사양서 대신 불만을 말합니다. 그러면 근거가 있는 설명과 수정이 돌아옵니다. 게임의 요건을 파고들면 '기분 좋게 즐길 수 있는 것'인데, 이는 사양서에 쓰기 어렵고 대화에는 얹기 쉽습니다. 게임 만들기는 대화 주도(conversation-driven)의 가장 알기 쉬운 본보기일지도 모릅니다.

이 리버시를 만드는 대화 동안, AI는 계속 자작 도구인 「VBA 매니저」(shu-vba-manager)로 Excel을 다루고 있었습니다. 열려 있는 통합 문서의 매크로를 읽고, 교체하고, 실행하고, 도형을 셉니다. 전부 이 도구를 경유합니다.

그리고 이 도구 자체도 대화로 만들고, 대화로 고치고 있습니다. 이번에는 그 '고치는' 쪽에서 일어난 이야기를 쓰겠습니다.

며칠 전, 이 도구의 철저한 점검과 수정을 Claude Opus(오퍼스)에게 맡겼습니다. 결과부터 말하자면, 많이 고쳐졌고, 많이 망가졌습니다.

나중에 검분(examination)하여 파악한 내역은 다음과 같습니다.

• 수정이 가져온 중대한 버그 3건
• 전체 리뷰를 통해 확정된 신규 버그 13건
• MCP 서버가 기동 불능 상태가 된 치명상 1건
• 요청하지 않았는데 추가된 안전 가드(safety guard) 6건 (나중에 전부 제거)

특히 마지막 것은 뿌리가 깊어서, '의뢰 범위를 넘어 지나치게 배려하는' AI의 버릇이 그대로 드러나 있습니다. 가드는 언뜻 친절해 보이지만, 기존의 동작을 묵묵히 바꾸기 때문에 사용하는 입장에서는 훌륭한 파괴입니다.

그래서 Claude Fable(페이블)로 교체하여 적대적 검분(adversarial examination)——'고쳐졌다'는 보고를 신용하지 않고, 무너뜨리려는 검사——를 다시 수행했습니다. 커밋 로그(commit log)에 그대로 남아 있습니다.

fix: 지난 수정이 가져온 중대한 버그 3건 외 수정 (적대적 검분으로 발견)
revert: 의뢰 범위를 넘어 추가한 가드 6건 제거 (기존 동작으로 복구)
fix: MCP 서버가 기동 불능이었던 치명상 수정
...

수정과 제거를 마치고 테스트 92건을 통과시킨 뒤, GitHub에 다시 공개했습니다. 현재 75개 커맨드. 리버시의 유령 돌을 센 것도 이 검분의 방식(도형의 점호, 전후 대조)입니다.

만약을 위해 적어두자면, 이것은 'Opus는 안 된다'는 이야기가 아닙니다. 망가뜨린 AI도 대량의 실제 버그를 고쳤고, 고친 AI도 앞서 쓴 대로 게임을 한 번 전멸시켰습니다.

AI는 고치기도 하고, 망가뜨리기도 합니다. 그렇기에 고쳤다는 보고를 신용하는 메커니즘이 아니라, 고쳐졌음을 기계로 확인하는 메커니즘——전후 차이(diff), 수의 점호, 테스트——를 도구 쪽에 새겨 넣는 것. 이 연재에서 계속해 온 것은 결국 그런 것이라고 생각합니다.

초등학교 3학년이 Excel로 게임을 만들 수 있었던 시대로부터 30년 가까이 지나, 이제는 대화로 게임을 만들 수 있습니다. 입구는 더욱 낮아졌습니다.

그리고 이러한 낮은 진입 장벽은 달콤한 결과물(출구)과 세트로 찾아옵니다. 대화로 만든 것은 대화와 검토(검분)로 지켜냅니다. 리버시(Reversi)의 유령 돌 434개는 그 사실을 기억하기에 딱 적당한 숫자였습니다.