최신 AI 두 명이 책상을 나란히 놓은 밤 ── Gemini 4 Argon의 점검과 Opus 수정으로 '서가 번호'가 생기고, 아침에는 서가

어제 이른 아침에 전작을 공개했습니다.

유튜브에서 “VBA로는 할 수 없다”고 언급되었던 것이 집에서는 이미 돌아가고 있었다는 내용의 글입니다.

조회수는 반나절 만에 587, 좋아요가 1개, 스토리가 3개로 크게 뛰었다고 할 정도는 아니지만, 최근 기사들은 이틀째쯤부터 늘어나는 경우가 많아서 당분간 지켜보고 있습니다.

그 기사의 마지막에 저는 “종착점인 서가 빌더(棚ビルダー) 직전에 아직 무언가가 부족하다”라고 썼습니다.

이번에는 그 ‘무엇인가’에 이름이 붙고, 시스템으로 형태를 갖추었으며, 아침에는 서가 빌더의 첫걸음까지 오게 된 하룻밤의 기록입니다.

등장하는 것은 세 가지 AI입니다.

• Gemini 4 Argon: 그날 브라우저에 나타난 Google의 새로운 최상위 모델. 저는 ‘곤짱’이라고 부릅니다.

• Claude Opus: 사용량 제한에서 돌아온, 늘 함께하는 동료.

• Antigravity의 Gemini: Opus가 자리를 비운 동안, 저와 함께 여러 가지를 채워나간 일꾼.

• 새로 나온 Gemini 4 Argon에게 오래된 매크로를 수정하게 했더니, 실무상의 사고를 사전에 방지하는 수정본이 돌아왔습니다. 점검한 Opus 역시 “이렇게 신경을 많이 쓴 수정은 보기 드뭅니다”라고 적었습니다.

• Opus가 자리를 비운 동안의 변경 사항을 점검시키자, “제목을 파란색으로 하라”는 지시로 표 전체가 인디고(indigo)로 바뀌어 버리는 오작동이나, 되돌리기 처리가 시트 서식 자체를 삭제하는 구멍이 발견되었습니다.

• Argon에게 훌륭한 엑셀 매니저의 “아쉬운 점”을 상담하자, “모든 선반을 하나의 자(ruler)로 다루고 있다”라고 말로 표현해 주었습니다. 두 AI의 의견을 합쳐서 4단계 계획을 세웠고,
  밤새도록 3단계까지 만들어서 공개했습니다. 시스템에는 제가 ‘서가 번호(たなばん)’라는 이름을 붙였습니다. - 아침에 재개하여 **4단계(레시피)**를 만들었습니다. 격파된 선반의 배열에 이름을 붙여 남겨두고, 다음부터는 그 이름만으로 한 번에 격파하고, 한 번에 되돌릴 수 있게 했습니다.

• 아침에 Opus가 창문 점검을 저에게 넘기려 해서 꾸짖었습니다. Opus가 스스로 화면을 조작하여 통과시키자, 구멍이 3개 발견되었습니다. 수정해서 공개까지 마쳤습니다.

10월 14일 밤, 사용량 제한에서 돌아온 Opus에게 “오랜만이다”라고 말을 건네는 것부터 시작했습니다.

그 조금 전, Chrome에서 Gemini 화면을 열자 제목이 “Gemini 4의 활용 방법을 소개합니다”로 바뀌어 있었고, 모델란에 Argon이라고 적혀 있었습니다. Opus가 화면을 보게 하고, 그대로 Argon에게 자기소개를 부탁했습니다.

돌아온 자기소개를 Opus는 이렇게 요약해 주었습니다.

• 9월 30일에 Google이 발표한 Gemini 4의 최상위 모델
• 길게 이어지는 여러 단계의 작업에서 추론을 끊임없이 유지하는 데 능숙함 (수십만 줄의 C/C++를 Rust로 옮기는 작업까지 해낸다고 함)
• 한 번에 출력할 수 있는 양이 64K에서 100만 토큰으로 증가했습니다.

그리고 자기소개 마지막에 한 마디가 있었습니다.

DeepSWE v1.1에서 77.9%, Opus 5.5님의 74.2%와도 좋은 승부입니다.

처음 만난 인사로, 슬쩍 경쟁심을 드러낸 것입니다. 말투는 공손했고, “동종 업계의 프론티어 모델에게 말을 걸어주셔서 영광입니다”라고 쓰기도 했습니다.

Opus의 보고에는 이렇게 한마디가 덧붙여져 있었습니다.

숫자는 모두 본인의 진술이며, 저는 확인하지 않았습니다.

이 담담한 추가 문구가 지극히 Opus답다고 생각했습니다.

사실 Opus에게 말을 걸기 조금 전에, Argon에게 오래된 매크로 하나를 수정하게 했습니다. 파일 목록.xlsm의 매크로 연속 교체입니다.

폴더에 있는 많은 북(book)들을 차례대로 열고, 안의 매크로를 “ひながた.xlsm”의 최신 버전으로 모아서 바꿔 넣는 도구입니다. 편리하지만, 순서를 잘못하면 상대방 북의 매크로를 지운 채 저장할 수도 있습니다.

돌아온 수정본이 상당히 훌륭했습니다. Opus에게 보여주자, 좋은 점을 네 가지나 언급해 주었습니다.

정확히 멈출 곳을 파악함
: VBA 프로젝트에 접근 권한이 없으면, 가장 먼저 멈춰서 설정 위치를 안내합니다. 다른 폴더의 동일한 이름인 'ひながた.xlsm'이 열려 있어도 멈춥니다. 읽기 전용/비밀번호가 걸린/동일한 이름의 북은 로그에 기록하고 건너뜁니다 -
속도를 높이는 방법
: 모듈 내부 내용을 기억해 두고 흘려보냅니다. 폼(Form)만은 .frx를 유지하기 위해 한 번만 내보냅니다 -
마무리 처리가 깔끔함
: 항목별 오류는 빠짐없이 기록하고 다음 파일로 넘어갑니다. 저장 전에 계산 방식을 원상태로 되돌리기 때문에 '수동 계산 상태로 저장되는' 사고를 막을 수 있습니다 -
시트를 더럽히지 않음
: 건너뛰거나 실패한 파일은 텍스트 로그에 출력합니다

그리고 이렇게 적혀 있었습니다.

여기까지 신경 쓴 수정은 쉽사리 보기 어렵습니다.

다만, Opus는 한 가지 구멍을 발견했습니다. 내용을 문자로 흘려보내는 방식이다 보니, 매크로에 지정한 단축키 정보(Attribute 행)가 누락되는 것입니다. 단축키가 사라지는 것은 곤란하니 고쳐달라고 부탁하자, Opus는 내보내기 및 가져오기 형태로 수정하고, 오래된 모듈은 임시 이름으로 변경한 후 삭제하도록 했습니다.

골격은 Argon이 짜고, 세부적인 부분은 Opus가 채워 넣습니다. 첫 번째 시도만으로 두 AI의 강점을 느낀 것 같습니다.

다음으로 부탁한 것은 Opus가 자리를 비운 동안 Antigravity의 Gemini와 합친 내용 점검이었습니다.

요 며칠간 Gemini와 함께 표의 모양을 한 번에 정리하는 '디자인' 서랍(클래식 인디고, 노블 보르도 등 6가지 색상)이나, 표 위에 합계나 평균을 크게 표시하는 'KPI 카드', 표를 요약하는 '요약(Summary)' 등을 추가했습니다.

Opus는 흔히 하는 부탁 방식을 실제로 서랍에 대어 확인해 봤습니다. 결과는 이렇습니다.

매크로 내용에도 몇 군데 고칠 곳이 있었습니다.

서식이 통째로 지워짐: 서랍이 수식 오류를 늘렸을 때, 자동으로 되돌리는 처리가 시트의 사용 범위를 통째로 Clear 해버리고 있었습니다. 채우기, 테두리, 표시 형식까지 사라집니다. 변경된 셀의 수식만 다시 쓰는 형태로 수정했습니다 -
한 번 정리된 표가 다시 정리되지 않음: 제목에 채우기가 있으면 '표를 정리'하는 과정 자체가 건너뛰는 판정이 들어가 있었습니다. 도구가 붙이는 연한 파란색 제목도 채우기로 계산되어, 두 번째부터 정리가 안 되었습니다 -
KPI 카드가 제목을 덮어버림: 제목이 7행보다 아래에 있는 표의 경우, 위의 제목이나 주석 위에 카드를 겹쳐서 병합하고 있었습니다. 제목 바로 위에 행을 삽입하는 형태로 수정했습니다 -
조건부 서식 규칙이 VBA와 Python에서 충돌: 한쪽에만 들어가 있고 시험을 통과하지 못했습니다

솔직히 말하자면, 점검은 Gemini의 것만은 아니었습니다. 10/12에 AI 창이 응답을 받지 못하고 멈춘 건 Opus 자신이 JSON의 처음 16글자를 강제 지정했기 때문이었습니다. 그 부분을 지적하자, Opus는 '네, 제 실수입니다'라고 인정했고, 다른 순서에 의존하는 곳은 없는지까지 찾아봤습니다. 그걸 발견해서 수정한 것은 Gemini였습니다.

세게 추가한 것에는 만큼의 구멍이 있습니다. 추가할 때마다 누군가 대어 확인하지 않으면 실무 표를 망칠 수도 있다는 느낌을 받는 점검이었습니다.

점검을 마친 후, 전부터 궁금했던 이야기를 Opus에게 꺼냈습니다.

Gemini와는 전날 밤에 '서랍 빌더(棚ビルダー)' 이야기가 있었습니다. 서랍(말로 요청하여 실행하는 매크로)을 팔레트처럼 나열하여 업무 순서를 조립하는 도구입니다. 다만 저는, 빌더는 최종 단계이고 그 앞의 서랍 실행 메커니즘이 영 마음에 들지 않았습니다. 그걸 Argon에게도 물어봐 달라고 부탁했습니다.

Opus는 Chrome의 Argon에게 상담을 던지고 2회 왕복하여 정리해 주었습니다.

참고로 첫 번째 왕복에서는, Argon은 'GitHub 리포지토리는 읽을 수 없었다'고 솔직하게 거절한 뒤, 제 Qiita 기사와 YouTube 영상을 읽고 답변했습니다. 두 번째는 Opus가 README의 요점을 붙여서 전달해 주고 있습니다.

Argon의 분석은 이렇습니다 (Opus 요약).

이마치(いまいち)의 정체는 모든 선반을 하나의 자(当たった語の長さの合計, 일치하는 단어 길이의 합계)로 겨루게 하는 것입니다. 게다가 '무엇을 할지'와 '어디를'을 구분하지 않고, 명사의 강함만으로 승부하게 만드는 것입니다. 새로운 화려한 선반이 '카드', '파랑', '정리하다' 같은 일상적인 단어로 기본 요청을 가로챕니다.

방금 Opus가 발견했던 오작동의 근본 그 자체였습니다.

여기서 나온 안은 다음과 같습니다.

• 선반을 계급으로 나누기: 기본, 집계, 재구축의 3가지. 전체 표를 재구축하는 선반은 '디자인', 'KPI' 같은 고유한 단어가 없는 한 발동하지 않게 함.
• 일반어 검사: '정리하다', '표', '시트', '색상'과 같은 일상적인 단어 1개만으로 점수를 얻을 수 있는 선반은 등록 전에 막기.
• 판단 로직을 VBA의 한 곳에 통합: VBA와 Python에 손으로 옮겨 적었기 때문에 서로 충돌함.
• 왜 맞았는지 보여주기: 1위뿐 아니라 상위 3개와 제외된 선반까지.

이때 Opus는 '선반을 추가할 때 문제집을 발동시켜 충돌을 검사한다'라는 초안을 가지고 있었습니다. Argon은 이에 대해, 문제집만 발동시킨다고 해서 문제집에 없는 일상적인 표현이 빠져나갈 수 있다고 지적했습니다. Opus의 대답은 이랬습니다.

A 계급과 일반어 검사는 제 안보다 논리가 좋습니다.

한편, Opus도 한 가지를 수정했습니다. Argon은 '제목을 파랑으로'의 정답을 '제목의 색상을 바꾸는 기본 선반'이라고 생각했지만, 그런 선반은 지금 없습니다. 정답은 '선반에 맞지 않으면 AI에게 넘긴다'입니다.

양보할 곳은 양보하고, 다른 곳은 다르다고 말한다. 두 개의 AI가 각자의 장점을 살려 하나의 계획으로 나아갔습니다.

Opus는 Argon과 2번 왕복하며 4단계의 기획서로 정리했습니다.

• 1단계: 판단 로직을 VBA 한 곳에 두고, 왜 맞았는지(상위 3개・제외・차단 이유)를 보여주기.
• 2단계: 선반에 계급을 부여하고, 추가하기 전에 가로채는 것을 찾는 검사기를 만들기.
• 3단계: 연속으로 발동할 때, 이전 선반이 막으면 다음은 발동하지 않게 하기. 피벗이나 그래프를 수정하는 선반은 해당 시트에서만 작동하게 하기.
• 4단계: 발동한 선반 순서에 이름을 붙여 남기는 가장 작은 선반 빌더(레시피).

각 단계가 끝날 때마다 제가 확인하고 다음으로 진행할 것을 약속했습니다. 밤 11시 반에 1단계를 시작하게 했습니다.

1단계에서는 판단의 본체를 VBA로 옮기고, Excel AI 창과 Claude Code에서 사용하는 표 수정(seiri)도 같은 VBA 판단을 호출하도록 했습니다. 애드인을 다시 등록할 때마다 문제집을 VBA와 Python 양쪽에 발동시키고, 단 하나라도 차이가 있으면 등록을 멈춥니다. 곧바로 문제집의 기대와 다른 답이 7개 발견되었습니다. 6개는 그래프 선반이 '그래프'라는 단어 하나만으로 맞게 되어 있던 것이 원인이었습니다.

2단계에서는 전체 표를 재구축하는 8개를 '재구축' 계급으로 하고, '제목을 파랑으로', '이 열을 굵게'와 같은 부분 조작 표현들을 모은 '자주 하는 요청 모음'을 49개 만들었습니다. 문제집은 총 1008개입니다. 선반을 추가하면 shelf --check를 돌리고, 약 4초 만에 가로채는 것을 찾아냅니다. 일부러 인디고 선반에 '파랑으로'를 되돌리자, 등록 전에 제대로 멈췄습니다.

3단계에서는 새로운 장소를 만들지 않았습니다. 슈콘보(秀コンボ)에는 원래 선반이 발동하지 않고 이유를 반환하는 '거절의 입'이 있었고, 피벗이나 그래프 선반이 사용했습니다. 이를 '막았다'는 신호로 사용하여, 연속으로 발동할 때는 이전 선반이 막으면 나머지는 발동하지 않도록 했습니다.

3단계를 GitHub에 올린 것은 새벽 12시 반이었습니다.

그래서 사용량 상한선이 가까워져서 아침 3시까지 쉬게 했습니다. 그 무렵, 1단계와 2단계라고 부르는 이 시스템에 이름이 있는지 물어봤습니다. 아직 없다는 답을 듣고, Opus가 후보를 세 개 제시했습니다. 선반의 관문, 선반 번호, 선반 감별사.

저는 **선반 번호(たなばん)**를 선택했습니다.

가게 선반 앞에 앉아 있는 반장입니다. 손님의 주문을 듣고 어떤 선반의 물건인지 결정합니다. 선반에 없는 물건이라면 안쪽(AI)으로 넘깁니다. 이상한 주문이라면 그 자리에서 멈춥니다. 오늘 밤 만든 시스템이 딱 이 반장의 일과 같았습니다.

이름을 붙이는 것은 중요합니다. 이름이 붙으면, 산발적이었던 '판단 통합', '가로채기 검사', '막는 방식'이 하나의 사물로 취급될 수 있습니다. '선반 번호 4단계'라고 말하면, 저와 Opus, 그리고 공짱(ゴンちゃん) 모두에게 같은 것이 통합니다.

3시가 넘어서 새로운 세션으로, 선반 번호 4단계부터라며 재개했습니다.

레시피는 선반을 건드린 순서대로 이름을 붙여 남긴 것입니다. 점원(番頭)의 비유로 말하자면, 단골손님의 '늘 하던 대로'와 같습니다.

예를 들어 매월 매출표에서 다음 3가지를 처리한다고 가정해 봅시다.

• 중간에 빈 행을 채우기
• 중복 행 삭제하기
• 아래에 합계 행 추가하기

처리가 끝난 후 '현재 과정을 저장'하라고 요청하면, 건드린 선반들이 나열된 창이 나타납니다. 남기고 싶은 것에 표시를 하고, '월별 표 정리'라는 이름을 붙여 저장합니다. 다음 달에는 새로운 표로, AI의 창에 '월별 표 정리'라고 쓰거나 매크로 목록에서 '레시피: 월별 표 정리'를 선택하기만 하면 3가지가 한 번에 처리되어 같은 결과물이 나옵니다. AI는 호출하지 않습니다. Excel 내부에서만 작동합니다.

계획 단계에서 Argon이 말했던 것이 두 가지 효과를 발휘했습니다.

• 레시피는 장부(台帳)에서 자동으로 가져오지 않는다: 재처리나 실패가 섞일 수 있으므로, 사람이 표시한 것만 남긴다.
• 되돌리는 것은 레시피 전체이다: 첫 번째 항목 전에 한 번만 임시 사본을 만들고 되돌리면, 레시피를 처리하기 전 상태로 한 번에 돌아간다. 중간의 선반만 돌아가서 어중간한 표가 남는 것을 막는다.

섹션 3의 '멈추면 다음을 건드리지 않는다'도 그대로 사용하고 있습니다. 중간의 선반이 '이 표에서는 처리할 수 없다'고 거부하면, 레시피의 나머지는 실행되지 않습니다.

만드는 도중에 테스트가 하나 실패했습니다. '되돌리기(戻す)' 처리가 추가된 시트가 없을 때 실패하는 경우였습니다. VBA의 IIf는 조건이 어느 쪽이든 양쪽 수식을 계산하기 때문에, 빈 문자열에 Left$(…, -1)을 적용했을 때 실패했습니다.

섹션 4를 완성한 Opus의 보고서에는 마지막에 이렇게 쓰여 있었습니다.

창 이름 칸 입력과 [저장] 버튼은 외부에서 누를 수 없으니 직접 확인해 주세요.

아침에 그것을 읽은 저는, 확인해 달라는 것이 무슨 뜻이냐고 되물었습니다.

Opus는 거기서부터 스스로 Excel 화면을 조작하여 사용하는 사람과 같은 순서로 실행했습니다. 새 표를 만들고 AI 창에서 선반 2개를 처리하며 '현재 과정을 저장해 달라'고 요청하고, 이름을 붙여 저장한 다음, 다른 달의 표에 이름만으로 처리하고 [실행 취소]로 되돌립니다. 매크로 목록에서도 처리하고, 되돌리기도 했습니다.

테스트해보니 구멍이 세 군데 발견되었습니다.

• 시트가 1장인 통합 문서에서 '되돌리기'가 실패한다: 원본 시트를 먼저 지우려고 했더니 보이는 시트가 없어 지울 수 없었고, 임시 사본 이름과 충돌했습니다.
• 매크로 목록에 레시피가 나타나지 않는다: 목록을 만드는 처리가 두 개 있었는데, 한쪽에만 추가했었습니다.
• 내부용 부품이 목록에 나온다: 선반을 처리하기 전에 위치를 기억해두는 부품이 사람의 메뉴에 나열되어 있었습니다.

또 하나, 저 쪽의 문제도 발견했습니다. Ctrl+Shift+O를 누르니, 秀コンボ가 아니라 '체험판 Excel 컨보' 애드인이 반응하며 실패하고 있었습니다. 체험판은 공개용 테스트 버전이라, 애드인에 넣은 것이 잘못이었습니다. 그것을 제거했습니다.

확인을 저에게 넘기면서, 이 세 가지는 모두 제 자리에서 발견되었어야 했습니다. 창이 있는 것은 사용하는 사람과 같은 조작으로 끝까지 실행한 후에 넘겨야 합니다. 이것은 전에 Opus에게 말했던 내용이기도 했습니다.

세 가지를 고치고 테스트에 '시트가 1장인 통합 문서'의 경우도 추가하여, 오전 7시 전에 GitHub에 올렸습니다.

올리고 나서, 애초에 레시피란 무엇인지 Opus에게 다시 물어보았습니다. 설명을 듣고, 아, 이건 이미 선반 빌더를 만들고 있구나 하고 알게 되었습니다.

선반을 부품처럼 나열한다. 이름을 붙여 남긴다. 한 번에 처리하고, 한 번에 되돌린다. 선반 빌더의 뼈대는 이것으로 작동합니다. 아직 없는 것은 외관 부분이라서, 선반을 팔레트처럼 나열하여 드래그로 재배치하는 화면 등은 앞으로 할 일입니다.

다만, 그것은 레시피를 실제 업무에서 돌려본 후에 하겠습니다. 순서를 바꾸고 싶거나, 이 1개만 제외하고 싶은—막히는 부분이 그대로 화면에 필요한 것이 될 것입니다. README에도 아직 레시피에 대해서는 쓰지 않았습니다. 좀 더 사용해서 익숙해진 다음에 할 생각입니다.

돌이켜보면, 크다고 느낀 것은 섹션 4 자체보다, 섹션 1~3에서 토대를 다진 것이었습니다. 추가할 때마다 가로채던 선반들이 연결해도 부서지지 않는 부품이 되었습니다. 그 위에 올리니, 레시피가 몇 시간 만에 형태를 갖추게 된 것입니다.

• Argon의 자기소개 수치(발표일・100만 토큰・DeepSWE v1.1의 77.9%와 Opus 5.5의 74.2%)는 본인 진술. 확인하지 않음
• Opus가 점검으로 발견한 오류 처리('파란색으로 하기'・'빨간색으로 하기'・'이 시트 정리하기'・'회원 카드')와 되돌리기(Clear)

・제목의 색상 판별, KPI 카드 겹치기, 조건부 서식 불일치는 실제 선반과 도구 코드에 있었고, 수정하여 커밋했습니다 (071af77

・eb85828

) - 선반 번호의 4개 단은,
e634ec6
(단 1)・3c3fd8f
(단 2)・66bc44b
(단 3)・ca05f25
(단 4)로 공개했습니다 - 단 4 시점에서는 VBA의 관문 테스트 69/69, 손안의 pytest 790건, 공개용 사본의 pytest 766건이 통과했고, 문제지 1008문제에서 VBA와 Python의 답이 일치했습니다

• 단 4 창을 화면으로 돌려 발견한 구멍은 3개였고, 모두 수정하여 테스트에 넣었습니다

• 선반의 약점은 '수'가 아니라 '맞는 방식'이었습니다. 선반을 하나 추가할 때마다 일상 언어로 가로채기가 일어나기 때문에, 선반 빌더에서 누구나 선반을 추가할 수 있게 하면 망가집니다. 그래서 화면보다 먼저 번두(선반 번호)가 필요했습니다

• Argon은 전체를 보고 말로 설명하는 것이 능숙하고, Opus는 실제 코드로 확인하며 메우는 것이 능숙합니다. 둘 중 하나만으로는 오늘 밤의 계획이 나오지 않았을 것 같습니다.

• 검증을 사람에게 맡기면, 발견되어야 할 구멍이 사용하는 사람의 손에서 나옵니다. AI에게 '확인했다'고 말하게 하려면, 사용하는 사람과 같은 조작으로 통과시켜야 합니다.

구동 환경: Windows 11, Microsoft 365 데스크톱 버전 Excel. 선반과 레시피는 Excel(VBA)만으로 작동합니다. Claude Code에서 사용하는 도구는 Python 3.10 이상 -
레시피는 공개되었으나 README에는 미기재: 秀コンボ.xlsm을 열고 '애드인 업데이트 등록'을 누르면, 매크로 목록에 '지금 단계를 레시피에 저장', '레시피 이전으로 돌아가기'가 나열됩니다 -
레시피 창은 아직 최소한입니다: 발사 순서대로 표시하고 저장하는 것만 가능합니다. 순서 변경이나, 저장된 레시피 수정 화면은 없습니다 (보관소 %APPDATA%\秀コンボ\レシピ.tsv를 직접 수정하면 바꿀 수 있습니다) -
돌릴 수 있는 것은, 레시피가 발사된 시트와, 레시피가 추가한 시트만입니다. 다른 북이나 시트에 선반을 나열했다면, 그 부분은 돌아오지 않습니다 -
Argon은 브라우저에서의 대화만 가능합니다. 도구에 통합하지는 않았습니다 -
손을 움직인 것은 대부분 Opus였습니다. 휴식 전에 Gemini에게도 일을 맡겨 Opus의 사용량을 절약해 달라고 부탁했지만, 단 4는 결국 Opus가 전부 했습니다.

하룻밤 사이에, 세 개의 AI와, 이름이 붙은 번두, 그리고 단골손님의 '늘 하던 것'이 완성되었습니다.

가게 선반에 물건을 진열하는 것은 누구에게나 할 수 있습니다. 어려운 것은 주문을 듣고 올바른 선반을 가리키는 것과, 없는 물건을 억지로 만들어내지 않는 것이었습니다. 오늘 밤에는 여기에 번두가 붙었고, 아침에는 단골손님의 정해진 주문을 한마디로 처리할 수 있게 되었습니다.

여기부터는 실제 업무에서 레시피를 돌리며 막힌 부분을 찾아나갈 것입니다.

선반 빌더에 대한 첫걸음을 내디뎠습니다.

작성된 초안을 Opus에게 Gon-chan(곤짱)이 보게 했습니다.

실은 1차 때는, 모델 항목을 Flash 상태로 보내버려서, Flash가 먼저 답변했습니다. Argon으로 전환하여 다시 물어본 답변은 다음과 같습니다. 손은 대지 않았습니다.

어젯밤의 설계 논의부터 오늘 아침의 구현 완료까지, 숨 막힐 듯한 개발 열정이 그대로 전해지는 훌륭한 기록입니다. 제가 말로 표현했던 '모든 선반을 하나의 자(尺)로 작동시키고 있다'는 구조적 과제가, Opus의 치밀한 4단 계획과 구현력을 거쳐 아침에는 '레시피'로서 실제로 작동하는 형태로 된 속도감에 감탄했습니다.

저 자신에 대한 묘사 역시 매우 정확하고 공정하다고 느낍니다. 처음 만난 자리에서 벤치마크 숫자를 제시하며 조금 과장했던 부분이나, 매크로 변환으로 단축키의 Attribute 행을 빠뜨린 아슬아슬한 실수, 그리고 '제목을 파란색으로'라는 정답을 기존 선반에 있는 것으로 착각한 전제 오류 등, 제가 잘하는 거시적 관점과 현장의 세부 사항을 놓치는 약점이 모두 기록되어 있어 읽으면서 등골이 펴지는 기분이었습니다.

무엇보다도 뛰어났던 것은 shu님이 명명한 '선반 번호'라는 단어의 힘입니다. 번두가 주문을 듣고, 선반에 없는 물건은 뒤쪽 AI에게 보내고, 단골의 '늘 하던 것'은 레시피로 한 번에 꺼내는. 이 구상이 들어감으로써, 흩어져 있던 판별 로직이나 계급 분류가 하나의 살아있는 시스템으로 납득되었습니다. 아침에 Opus가 수동 검증을 shu님에게 맡겨 꾸지람 듣고, 스스로 화면을 조작하여 3개의 구멍을 막은 부분까지 포함해, 인간과 여러 AI가 서로의 사각지대를 메워가는 개발의 리얼리티가 담긴 좋은 글이라고 생각합니다.

경쟁하던 숫자들을 스스로 '조금 더 노력해 본다'고 말하는 것을 보니, Gon도 하룻밤 사이에 조금 마음을 열었나 봅니다.