하네스 때문에 못 옮긴다고 믿었는데, 묶여 있던 건 5%였습니다

구글이 AI 모델 순위 상위권에서 사라졌다는 영상을 봤습니다. 코딩 얘기가 나오면 요즘은 Claude Code와 Codex 이야기만 오간다는 대목에서 고개를 끄덕였습니다. 제 터미널이 정확히 그렇습니다. 하루 종일 Claude Code가 떠 있고, 두 번째 의견이 필요하면 Codex를 부릅니다. Gemini는 안 씁니다.

그런데 안 쓰기로 결정한 기억이 없습니다. 어느 날 비교해보고 접은 것도 아니고, 뭔가에 데어서 지운 것도 아닙니다. 그냥 안 씁니다. 이게 좀 이상하게 느껴졌습니다. 결정한 기억이 없는데 결과는 확고한 상태를, 저는 보통 "그럴 만한 이유가 있어서"라고 설명해왔거든요. 이번에도 설명은 준비되어 있었습니다. 제 하네스가 Claude Code에 묶여 있어서 다른 걸 못 쓴다고요.

돌아보면 이런 선택이 꽤 많습니다. 지금 쓰는 셸, 지금 쓰는 에디터, 지금 쓰는 브라우저 확장 몇 개. 언제 정했는지 기억나는 게 거의 없습니다. 그런데 누가 물어보면 이유는 술술 나옵니다. 이게 순서가 뒤집힌 겁니다. 이유가 있어서 고른 게 아니라, 고른 상태가 오래 유지되니까 이유가 나중에 붙은 거죠. 붙은 이유는 대체로 그럴듯합니다. 그럴듯하니까 검증할 생각이 안 듭니다.

체감이 남의 요약과 그렇게 딱 맞아떨어지면, 오히려 한 번 열어보는 게 맞다고 생각했습니다. 맞아떨어졌다는 건 제가 그 요약을 검증 없이 받아들일 준비가 되어 있었다는 뜻이기도 하니까요.

42%가 언제 숫자인지를 저는 저장하지 않습니다

영상이 든 첫 근거는 코딩 용도 지출에서 Anthropic이 42%, 오픈AI가 21%이고 구글은 그 아래라는 조사였습니다. 이 숫자는 실제로 있습니다. Menlo Ventures의 LLM 마켓 업데이트에 나옵니다. 다만 2025년 중간 보고서입니다.

지금은 2026년 8월입니다. 1년 전 조사로 지금의 순위를 말하고 있었던 겁니다. 같은 곳의 연말 보고서를 보면 엔터프라이즈 LLM API 전체에서 구글이 21%까지 올라와 있습니다. 코딩만 떼어낸 최신 수치는 원문에서 확인하지 못했습니다. 2차 블로그들이 다른 숫자를 돌리는데 원문 확인이 안 돼서 쓰지 않기로 했습니다.

여기서 두 가지가 동시에 헷갈립니다. 코딩 지출과 전체 API 지출은 다른 축이고, 2025년 중반과 2025년 말은 다른 시점입니다. 영상은 앞 축의 옛 시점 숫자를 가져와서 "구글은 그 아래"라고 정리했습니다. 틀린 말은 아닙니다. 다만 "구글이 지금 몇 위인가"에 대한 답은 아니었습니다.

제가 이 함정에 유독 약한 이유가 있습니다. 저는 이런 점유율 숫자를 기사 제목으로 한 번 읽고 머릿속에 저장합니다. 그런데 저장할 때 시점은 같이 저장하지 않습니다. 그러고 반년쯤 뒤에 그 숫자를 "요즘"의 근거로 꺼냅니다. 숫자는 그대로인데 세계가 움직였다는 걸 계산에 넣지 않는 거죠.

시점을 빼고 저장하는 게 왜 편한지는 알 것 같습니다. 숫자에 날짜가 붙어 있으면 그 숫자를 쓸 때마다 "지금도 그런가"를 확인해야 합니다. 날짜를 떼면 그 확인이 없어집니다. 대화에서 인용하기도 편하고요. "코딩 지출의 42%가 Anthropic이래"는 말하기 쉬운데, "작년 중반 조사 기준으로 42%였는데 그 뒤로 안 봤어"는 말하기 어색합니다. 말하기 어색한 형태가 정확한 형태인 경우가 꽤 있습니다.

AI로 주식 리서치를 시켜봤을 때도 같은 자리에서 틀렸습니다. 그때 정정된 건 제가 뽑아낸 위험 목록이 아니라 제가 깔고 시작한 전제였습니다. 이번에도 정정된 건 순위가 아니라 그 순위를 제가 언제 읽었는지였습니다. 두 번 다 결론이 틀린 게 아니라 결론 밑에 깔린 시점이 틀렸습니다. 이런 종류의 오류는 반박당하지 않고 그냥 통과합니다. 숫자 자체는 진짜니까요.

반박 근거가 주장을 뒷받침하고 있었습니다

두 번째 근거가 더 재미있었습니다. OpenRouter는 여러 모델을 한 API로 붙여 쓰게 해주는 중계 서비스입니다. 사용량 순위가 공개되니까 "개발자들이 실제로 뭘 고르나"의 대리 지표로 쓰기 좋아 보입니다. 8월 초 주간 토큰 사용량 상위 열 개 중 여덟 개가 중국 모델이었고, 조사들은 그 이유를 하나로 설명합니다. 비용입니다.

그러니까 이 순위표는 "누가 제일 똑똑한가"를 재는 표가 아닙니다. "같은 일을 제일 싸게 하는 게 뭔가"를 재는 표입니다.

그리고 여기서 논리가 자기 발에 걸립니다. 영상 후반부의 주장은 구글이 "가장 싸게, 가장 많은 사람에게" 쪽으로 게임의 규칙을 바꾸고 있다는 것이었습니다. 그 주장을 반박하는 근거로 OpenRouter 순위를 들면, 그 순위표가 정확히 "싼 게 이긴다"를 보여주고 있습니다. 반박하려고 꺼낸 자료가 반박 대상을 뒷받침합니다.

한 가지 더 있습니다. OpenRouter 트래픽은 특정 앱 하나가 크게 흔듭니다. 8월 초에 Nous Research의 에이전트 하나가 쓴 양이 추적되는 다른 앱 마흔아홉 개를 합친 것과 맞먹었습니다. 이런 분포에서 모델별 순위는 "개발자들의 선택"이 아니라 "그 달에 어느 에이전트가 크게 돌았나"에 가깝습니다.

대리 지표로 못 쓴다는 얘기가 아닙니다. 대리 지표는 원래 대리 지표라서 씁니다. 다만 무엇의 대리인지는 적어야 합니다. 그게 안 적혀 있으면 읽는 사람이 자기가 확인하고 싶은 것의 대리로 읽습니다. 저도 그랬습니다. "개발자들이 뭘 고르나"가 궁금했으니까 그 순위표를 개발자 선호도로 읽었고, 그 표가 실제로 재는 게 가격이라는 건 나중에야 봤습니다. 지표는 그대로인데 제가 붙인 이름이 틀렸던 겁니다.

종합 지수를 코딩 성적으로 읽었습니다

세 번째가 제가 제일 크게 잘못 읽고 있던 것입니다.

Artificial Analysis가 Gemini 3.7 Flash에 매긴 것은 Intelligence Index입니다. 직전 버전보다 올랐습니다. 그런데 이건 여러 평가를 묶은 종합 지수입니다. 코딩 순위가 아닙니다. 저는 "AA에서 뒤처졌다"는 문장을 읽고 머릿속에서 곧바로 "코딩을 못한다"로 번역했습니다. 두 문장은 같은 문장이 아닙니다.

그래서 코딩 벤치마크만 따로 봤습니다. Gemini 3.7 Flash가 나오면서 공개된 비교표가 있더군요. 일곱 항목 중 넷을 이기고 셋을 집니다. 프로덕션 코드와 웹 개발, 기업 워크플로우 자동화, 복잡한 문서 처리에서는 앞서고, 터미널에서 오래 돌면서 스스로 고치는 종류의 과제에서는 뒤집니다.

이 표를 보고 제 요약이 바뀌었습니다. "구글이 코딩에서 밀렸다"는 문장은 항목마다 답이 다른 질문에 하나의 답을 붙인 것이었습니다.

그런데 더 신경 쓰인 건 다른 쪽입니다. 뒤지는 항목의 성격이 하필 제가 매일 하는 일과 겹칩니다. 저는 터미널에서 에이전트를 길게 돌립니다. 그러니까 제 체감이 틀린 건 아니었습니다. 다만 제 체감은 일곱 항목 중 셋에 대한 체감이었고, 저는 그걸 일곱 항목 전체의 결론으로 말하고 있었습니다.

체급 문제도 있습니다. 이 표에서 구글 쪽은 Flash 등급입니다. 싸고 빠른 급이고, Pro는 아직 안 나왔습니다. 싼 등급을 상대의 주력과 붙여서 "밀렸다"고 하면, 이긴 항목이 넷이나 나오는 쪽이 오히려 설명이 안 됩니다. 밀렸다는 결론을 유지하려면 "그런데 왜 넷이나 이겼나"에 답해야 하는데, 영상에도 제 머릿속에도 그 답이 없었습니다.

터미널 벤치 1위와 2위의 0.4%p를 태스크 개수로 바꿔봤을 때도 정확히 이 자리였습니다. 태스크 하나가 채 안 되는 차이를 근거로 모델을 갈아탈지 고민하고 있었고, 정작 제 하네스에는 두 달 반 동안 아무것도 검증하지 않은 게이트가 돌고 있었습니다. 그때 배운 게 있다고 생각했는데, 같은 실수를 두 번째로 하고 있었습니다. 지표를 정밀하게 읽는 일에 시간을 쓰면서, 그 지표가 제 일과 무슨 상관인지는 안 물어본 겁니다.

만료일이 붙은 가격은 구조가 아니라 유인입니다

가격을 보면 "싸게 많이 뿌린다"는 해석이 그럴듯해집니다. 3.7 Flash는 직전 등급의 절반 값입니다. 그런데 이 가격에는 유효기간이 있습니다. 2026년 12월 31일까지고, 이듬해 1월 1일부터 두 배가 됩니다.

만료일이 붙은 가격은 구조가 아니라 유인입니다. 평가 기간 동안 워크플로우 안에 모델을 박아 넣으려는 도입가죠. 실무에서 이게 왜 중요한지는 분명합니다. 지금 단가로 파이프라인 원가를 계산하면, 그 계산이 넉 달 뒤에 두 배가 됩니다.

저는 이 함정을 한 번 밟았습니다. AI 부채 얘기를 쓰면서 제 워크플로우의 단가 노출을 따져봤을 때 나온 결론이 그거였습니다. 지금 단가를 상수로 놓고 짜면, 단가가 변수라는 사실이 나중에 청구서로 통보됩니다. 그래서 이번에는 캘린더에 12월 1일 알림을 하나 걸어뒀습니다. "Gemini 플래시 단가 재계산"이라고만 적었습니다.

다만 이 논의가 제 터미널에서 하는 일을 바꾸지는 않습니다. 추론 원가가 내려간다고 해서 제가 지운 CLI를 다시 설치하지는 않으니까요. 값이 싸다는 건 써볼 이유는 되어도 옮길 이유는 못 됩니다. 옮기는 비용은 청구서가 아니라 제 시간으로 나가고, 그건 할인이 안 됩니다. 왜 그런지가 이 글의 나머지입니다.

영상에서 제일 튼튼했던 대목

세 근거를 다 깎아놓고 나니 영상을 통째로 깎은 것처럼 됐는데, 그건 아닙니다. 검증하다가 오히려 더 튼튼해진 대목이 하나 있었습니다. 규모입니다.

Gemini 앱이 8월 11일에 월간 사용자 10억 명을 넘겼습니다. 이 숫자를 보면 "가장 비싼 모델을 전부에 물릴 수 없다"는 제약이 수사가 아니라 산수라는 게 보입니다.

그리고 이 제약이 경쟁사에는 없습니다. 오픈AI와 Anthropic은 모델이 사업의 전부라서, 프론티어에서 1등을 못 하면 존재 이유가 흔들립니다. 구글은 안드로이드와 크롬과 지메일과 지도와 유튜브를 이미 들고 있고, 그 위에 10억 명이 올라가 있습니다. 그러니까 1등 모델의 이득과 원가가 같은 저울에 올라갑니다. 성능 1등의 이득은 몇 달이면 따라잡히는데, 10억 명이 만드는 비용은 매일 나갑니다.

여기까지는 영상 그대로 맞다고 봅니다. 다만 이 논증이 커버하는 범위는 구분해야 합니다. 이건 소비자 제품에 모델을 어떻게 물릴지에 대한 논증입니다. 개발자용 코딩 모델을 왜 늦추는지는 이걸로 설명되지 않습니다. 3.5 Pro가 늦은 사유로 알려진 건 원가가 아니라 코딩 성능이었으니까요.

두 얘기가 자꾸 한 문장에 섞이는 게 이 주제의 어려운 점이라고 생각합니다. 소비자 쪽 논리는 원가고, 개발자 쪽 논리는 신뢰인데, 바깥에서 보면 둘 다 "구글이 어떻게 하고 있나"로 보입니다. 그래서 원가 얘기로 개발자 쪽 질문에 답한 것처럼 되는 순간이 자주 생깁니다.

모델이 늦는 건 기다리면 되지만 CLI가 죽으면 설정이 죽습니다

날짜를 정렬하다가 5월 19일에 두 개가 겹쳐 있는 걸 봤습니다.

하나는 I/O 무대입니다. 순다르 피차이가 Gemini 3.5 Pro를 프리뷰하고 6월에 내놓겠다고 했습니다. 그 뒤로 세 번의 공개 기한을 놓쳤고, 이유로 알려진 건 코딩 성능입니다. 6월 말에 코딩을 개선하려고 학습 데이터를 갈았는데 결과가 실망스러웠다고 합니다. 그 사이에 나온 건 Flash 등급뿐이고, 8월 하순까지 3.5 Pro는 API에 모델 ID도 가격 행도 없습니다.

다른 하나가 이 글의 축입니다. 같은 5월 19일에 구글은 Gemini CLI를 종료한다고 공지했습니다. 6월 18일부로 요청 처리를 멈춘다는 내용이었습니다.

개발자한테는 두 번째가 첫 번째보다 큽니다. 모델이 늦는 건 기다리면 됩니다. 늦는 동안 제가 하던 일은 그대로 돌아가니까요. 그런데 CLI가 죽으면 설정이 죽습니다. 기다림의 대상이 아니라 손실입니다.

누가 끊겼는지가 특히 눈에 남았습니다. AI Pro와 울트라 구독자, 그리고 무료로 쓰던 개인 사용자가 6월 18일에 끊겼습니다. 코드 어시스트 스탠다드나 엔터프라이즈 라이선스가 있거나 구글 클라우드를 통해 깃허브 연동을 쓰는 조직은 그대로 유지됐고요. 돈을 내던 개인도 포함해서, 개인 개발자를 먼저 끊었습니다.

숫자로 보면 합리적인 정리로 보입니다. 개인 라이선스는 매출 비중이 작고 지원 부담은 크니까요. 그런데 개발 도구의 채택 경로를 생각하면 얘기가 달라집니다. 저를 포함해서 대부분은 개인으로 먼저 써보고, 손에 익은 다음에 회사에 들여옵니다. 회의에서 "이거 도입합시다"라고 말하는 사람은 이미 집에서 몇 달 써본 사람이죠. 개인을 끊는다는 건 그 경로의 입구를 막는 겁니다. 지금 엔터프라이즈 매출은 남지만, 3년 뒤에 그 매출을 만들어줄 사람이 지금 입구에서 돌아섭니다.

그리고 돌아선 사람은 돌아섰다는 사실을 말하지 않습니다. 그냥 다른 걸 씁니다. 이탈 지표에 안 잡히는 종류의 손실이고, 저도 지금까지 아무 데도 말한 적이 없습니다. 이 글이 처음입니다.

구글이 붙인 사유는 이랬습니다. "당신의 필요가 바뀌었다. 이제는 여러 에이전트가 서로 통신하며 일을 나눠야 한다." 그리고 남기는 것도 명시했습니다. Antigravity CLI가 Gemini CLI의 가장 중요한 기능을 유지한다고요. Agent Skills, Hooks, Subagents, Extensions 네 개를 이름으로 적어뒀습니다.

그 네 개가 지금 제 레포에 있는 것과 정확히 같습니다. 개념은 살아남은 겁니다. 그럼 옮기는 게 뭐가 어렵냐는 질문이 자연스럽게 따라옵니다. 저는 그 질문에 "많이 어렵다"고 답해왔는데, 근거를 대본 적이 없다는 걸 그때 알았습니다.

그래서 제 레포를 열어봤습니다

이 블로그 레포에 자동화가 얼마나 쌓여 있는지 저는 감으로만 알고 있었습니다. 감으로는 "많이"였습니다.

실제로 세어보니 5,382줄이었고, 그중 런타임에 묶여서 이식 못 하는 건 훅 스크립트 234줄과 설정 파일 36줄이었습니다. 5%입니다.

나머지 95%는 어느 모델이 읽는지 모릅니다. 스킬 스무 개는 블로그 도메인 규칙입니다. 길이 정책, frontmatter 스키마, AdSense 정책 대조 목록, 문체 체크리스트 같은 것들이죠. 파이썬 발행 스크립트는 Blogger API를 부르고 frontmatter를 파싱합니다. 어느 CLI가 자기를 실행했는지 알 방법이 없고, 알 필요도 없습니다.

그리고 그 234줄이 묶여 있는 이유는 bash라서가 아닙니다. bash는 어디서나 돕니다. 묶여 있는 건 규약입니다.

가장 중요한 게 둘입니다. session-start.sh는 세션이 시작될 때 이전 세션 인수인계 파일과 마케팅 컨텍스트와 메모리 인덱스를 뱉습니다. 그게 컨텍스트 앞에 붙는다는 규약이 없으면, 저 스크립트는 그냥 파일 세 개를 화면에 출력하는 스크립트입니다. pre-commit-check.sh는 커밋 직전에 구글 OAuth 자격증명과 API 키 패턴을 훑고 걸리면 종료 코드 1을 냅니다. 그 코드가 커밋을 막는다는 규약이 없으면, 저건 경고문을 출력하고 커밋이 그냥 되는 스크립트입니다.

둘 다 스크립트가 하는 일이 아니라 런타임이 그 결과를 어떻게 대접하는지에 걸려 있습니다. 구글이 "훅을 남긴다"고 한 건 이 대접을 남긴다는 뜻이 아닙니다. 개념을 남긴다는 뜻이죠. 이벤트 이름과 차단 규약은 새 문서를 읽고 다시 맞춰야 합니다.

이게 라이브러리를 갈아타는 것과 다른 지점이라고 생각합니다. 라이브러리는 인터페이스가 문서에 적혀 있고, 잘못 부르면 그 자리에서 터집니다. 타입이 안 맞거나 함수가 없거나 예외가 납니다. 그런데 런타임 규약은 "이 출력이 어디에 붙는가", "이 종료 코드가 무엇을 막는가" 같은 형태입니다. 잘못 맞춰도 스크립트 자체는 성공합니다. 종료 코드 0이 나오고 로그도 정상이고, 다만 아무 일도 안 일어납니다.

발행 파이프라인이 조용히 고장 나는 이유가 정확히 이겁니다. 실패가 실패처럼 안 생겼습니다. 시크릿 스캔이 안 돌면 커밋이 그냥 됩니다. 성공한 것과 구분이 안 됩니다. 그래서 옮긴 뒤에 필요한 건 "돌았나"가 아니라 "막아야 할 걸 실제로 막았나"인데, 이건 일부러 걸리는 입력을 넣어봐야 알 수 있습니다.

그게 234줄에 대한 정직한 이식 비용입니다. 하루 일감입니다. 일주일 일감은 아닙니다. 다만 그 하루가 코드 고치는 하루가 아니라 규약 읽고 맞추는 하루라는 게 좀 다릅니다.

그 5%도 이미 대비돼 있었습니다

세다가 이상해서 git 로그를 봤습니다. 도구 무관한 규칙 파일과 Codex용 진입점이 같은 날 같은 커밋에서 들어와 있더군요. 커밋 메시지는 "양쪽 런타임 공통 자동화 계약 정리"였습니다.

2026년 5월 8일입니다. Gemini CLI 종료 공지보다 열하루 전이고, 실제 서비스 중단보다 마흔하루 전입니다.

저는 그때 이식성을 대비한 게 아니었습니다. 하고 싶었던 건 Codex한테 두 번째 의견을 받는 거였습니다. 같은 규칙을 두 도구에 두 번 적어놓으니 한쪽만 고쳐지는 일이 반복돼서, 도메인 규칙을 도구 무관한 파일 하나로 빼고 진입점만 둘로 나눴습니다. 목적은 중복 제거였고, 결과가 런타임 이식성이었습니다.

이게 좀 얄궂습니다. 특정 도구에 갇히는 걸 걱정해서 한 일은 아무것도 없는데, 게을러서 한 일이 그 문제를 절반 넘게 해소해놨습니다. 중복을 두 번 고치기 싫다는 이유가 결과적으로는 제일 실용적인 판단이었던 거죠.

그래서 이식성이라는 게 대비해서 얻는 성질이 아닐 수도 있겠다는 생각이 듭니다. 대비하려면 옮길 곳을 미리 정해야 하는데, 그건 예측이라 대체로 틀립니다. 반면 "같은 걸 두 군데 적지 않는다"는 규칙은 옮길 곳을 몰라도 지킬 수 있습니다. 그리고 그 규칙을 지키다 보면 도구에 대한 서술과 일에 대한 서술이 자연스럽게 갈라집니다. 갈라진 상태가 곧 이식 가능한 상태고요.

거꾸로 말하면, 지금 제 레포에서 제일 못 옮기는 부분은 제가 제일 열심히 만든 부분이 아니라 제가 한 번도 정리 안 한 부분입니다. 훅 스크립트가 그렇습니다. 잘 돌아서 손댈 일이 없었고, 손댈 일이 없으니 두 번 적을 일도 없었고, 그래서 규약이 그 안에 그대로 눌어붙어 있습니다.

그리고 이걸 알고 나서 제 설명이 무너졌습니다. "하네스가 Claude Code에 묶여 있어서 다른 걸 못 쓴다"는 게 제가 스스로에게 해온 설명이었는데, 세보니 묶인 건 5%고, 그 5%도 하루치 일감이고, 나머지 95%는 넉 달 전에 제가 이미 도구 무관하게 만들어놨습니다.

무너지고 나서 보니 "묶여 있다"는 말이 두 가지를 한꺼번에 가리키고 있었습니다. 하나는 옮기는 데 비용이 든다는 것이고, 다른 하나는 옮기고 싶지 않다는 것입니다. 앞의 것은 세면 나옵니다. 파일 몇 개, 규약 몇 개, 며칠. 뒤의 것은 세어지지 않습니다. 세어지지 않으니까 앞의 것에 얹어서 말하게 됩니다.

그러면 편해집니다. "안 옮긴다"는 제 결정이라 설명할 의무가 생기는데, "못 옮긴다"는 사정이라 설명이 필요 없습니다. 저는 넉 달 동안 제 선택을 사정으로 바꿔서 말해온 셈입니다. 그것도 아무도 안 물어봤는데 스스로에게요.

이런 문장은 팀에서도 자주 듣습니다. 레거시라서 못 바꾼다, 일정이 없어서 못 한다, 구조상 어렵다. 대부분 절반쯤 사실이고 절반쯤은 우선순위입니다. 저는 그런 말을 들으면 "어느 쪽이 몇 퍼센트냐"를 묻는 편인데, 정작 제 하네스에 대해서는 넉 달 동안 안 물어봤습니다.

그럼 왜 안 쓰나

남은 답을 정직하게 적으면 셋인데, 셋 다 벤치마크가 아닙니다.

제일 큰 건 근육입니다. 하루에 수십 번 치는 명령이 손에 박혀 있습니다. 비용이라고 부르기도 민망한데, 실제로는 이게 가장 크게 작용합니다. 새 도구를 열어놓고도 손이 옛날 명령을 치고 있으면, 그 도구가 더 좋아도 하루를 못 버팁니다. 성능 차이는 며칠에 한 번 체감되는데 손에 안 맞는 건 분 단위로 체감되니까요. 비교가 안 되는 싸움입니다.

그다음은 전환 비용이 아니라 재검증 비용입니다. 지금 이 파이프라인은 도는 게 확인된 상태입니다. 발행 조건을 세고, 시크릿 스캔이 커밋을 막고, 세션 인수인계가 붙습니다. 다른 런타임으로 옮기면 234줄을 고치는 데 하루가 아니라, 그 하루 뒤에 "이게 진짜 도나"를 확인하는 데 며칠이 듭니다. 그리고 발행 파이프라인은 조용히 고장 나는 종류입니다. 게이트가 안 도는 걸 두 달 반 동안 못 알아챈 적이 있으니, 이건 제 추측이 아니라 관측입니다.

마지막 하나가 구글에게 제일 비싼 항목입니다. 6월 18일에 한 번 끊긴 도구입니다. 개인 사용자를 먼저 끊고 엔터프라이즈 라이선스만 남긴 도구고요. 여기에 설정을 다시 넣는 결정은 벤치마크 점수로 뒤집히지 않습니다.

모델 순위는 몇 달이면 바뀝니다. 실제로 바뀌어왔고요. 작년 11월에 Gemini 3이 나왔을 때 여러 축에서 ChatGPT를 앞섰고, 12월에 샘 알트먼이 사내에 코드 레드를 걸었습니다. 광고 계획을 멈추고 에이전트를 미루고 인력을 ChatGPT 품질로 돌렸죠. 그러니까 지금 구글을 두고 하는 얘기를 여덟 달 전에는 오픈AI를 두고 했습니다. 여덟 달 만에 방향이 반대로 돌았습니다.

그런데 한 번 끊긴 CLI에 대한 불신은 여덟 달로 안 돌아옵니다. 이 비대칭이 구글의 실제 손실이라고 봅니다. 3.5 Pro가 내일 나와서 모든 항목을 1등 해도, 제가 그걸 쓰려면 6월 18일에 끊긴 그 자리로 돌아가야 합니다. 성능은 발표로 바뀌는데 신뢰는 시간으로만 바뀌고, 그 시간을 단축하는 방법을 저는 모릅니다.

굳이 방법을 찾자면 하나 있긴 합니다. 안 끊겠다는 약속이 아니라, 끊을 때 어떻게 하겠다는 약속입니다. 유예 기간이 몇 달이고 설정을 어떤 형식으로 내보내주고 대체 경로가 어디인지를 미리 적어두는 쪽이요. 서비스는 언젠가 끝납니다. 그건 예상 가능한 일이고, 예상 가능한 일에 대한 절차가 없다는 게 불신의 실제 내용입니다. 개인 사용자한테 준 건 종료일 한 줄이었습니다.

AI 설계 발표자료를 만들고 반년 뒤에야 공감이 왔던 얘기를 쓸 때는 문제가 반대 방향이었습니다. 그때는 제 하네스가 낡아서 문제였습니다. 이번엔 안 낡아서 문제입니다.

잘 도는 하네스는 대안을 평가하지 않게 만듭니다. 고장이 나야 밖을 보는데, 고장이 안 나니까 밖을 볼 계기가 없습니다. 평가하지 않으니 대안이 얼마나 좋아졌는지 모르고, 모르는 상태에서 "밀렸다"는 남의 요약을 제 판단으로 씁니다. 그게 이 글의 시작이었고요.

이게 도구가 좋을수록 심해진다는 게 좀 얄궂습니다. 불편한 도구를 쓰면 매일 대안을 검색하게 되는데, 편한 도구를 쓰면 검색할 이유가 없습니다. 그래서 잘 고른 도구일수록 다음에 잘 고를 기회를 줄입니다. 저는 이걸 안정성이라고 불러왔는데, 절반은 안정성이고 절반은 시야가 좁아진 상태였습니다.

제가 안 한 것

여기까지 쓰고 나서 이 글의 가장 큰 구멍을 적어둬야겠습니다. 저는 3.7 Flash를 제 레포에 붙여보지 않았습니다.

이 글에 나온 코딩 성적은 전부 발표된 표에서 온 것입니다. 남이 고른 벤치마크에서 남이 고른 상대와 붙인 결과죠. 제가 이 글의 앞부분에서 영상을 두고 지적한 게 정확히 그겁니다. 시점과 측정 대상을 확인하지 않고 요약을 자기 판단으로 쓰는 것. 저는 시점은 확인했고 측정 대상은 구분했는데, 그 표가 제 작업과 같은 종류인지는 확인하지 않았습니다.

제 작업이 뭔지는 이 레포에 적혀 있습니다. 스킬 스무 개짜리 도메인 규칙을 읽고, 만 자 넘는 한국어 본문을 쓰고, frontmatter 스키마를 맞추고, 발행 전에 조건을 확인하고, 파이썬 스크립트로 Blogger API를 호출합니다. 저 벤치마크들이 이 작업의 어느 부분을 예측하는지 저는 모릅니다. 터미널 쪽 항목이 예측하는 부분은 짐작이 가는데, 그건 제가 지는 쪽으로 읽은 항목이고요.

그래서 이 글의 결론은 "Gemini가 실은 괜찮다"가 아닙니다. 그건 제가 말할 수 있는 게 아닙니다. 말할 수 있는 건 둘입니다. 제가 안 쓰는 이유로 들어온 근거 셋이 서로 다른 걸 재고 있었다는 것, 그리고 그 자리를 하네스로 메꿨더니 하네스도 5%였다는 것.

남은 건 안 해봤다는 사실뿐인데, 이게 제가 짠 게 하네스가 아니라 아웃터 루프였다는 걸 알았을 때와 같은 모양입니다. 도구를 평가하는 루프가 아예 없었습니다. 평가를 안 하니까 판단이 필요 없고, 판단이 필요 없으니까 남의 요약이 그 자리를 채웁니다.

생각해보면 제 레포에는 글을 검사하는 절차가 여러 겹 있습니다. 길이를 세고, 내부링크를 세고, 문체를 대조하고, 커밋 직전에 시크릿을 훑습니다. 산출물에 대해서는 이렇게 촘촘한데, 그 산출물을 만드는 도구 자체를 점검하는 절차는 한 줄도 없습니다. 도구는 한 번 고르면 끝인 것처럼 취급해왔습니다.

그러니까 이 글에서 제가 발견한 구멍은 Gemini를 안 써본 게 아닙니다. 안 써봤다는 사실을 넉 달 동안 몰랐다는 것도 아니고요. 안 써본 상태를 근거 있는 판단이라고 말해왔다는 것입니다. 근거는 남이 만들었고, 저는 그걸 제 것처럼 옮겼습니다.

다음에 할 건 둘입니다. 하나는 12월 1일에 단가를 다시 계산하는 것. 다른 하나가 더 중요한데, 234줄을 진짜로 한 번 옮겨보는 겁니다.

옮길 생각이 없어도 해봐야 한다고 보는 이유가 있습니다. 이건 옮기려는 작업이 아니라 가격표를 붙이는 작업이거든요. 지금은 이식 비용이 "모름"으로 되어 있고, 모르는 값은 계산에 못 들어갑니다. 못 들어가니까 저는 매번 그 자리를 "많이"로 채워왔고, "많이"는 언제나 안 옮기는 쪽 결론을 냅니다. 실제로 이틀이 나오든 일주일이 나오든, 숫자가 붙는 순간 그건 비교 가능한 항목이 됩니다. 지금은 비교 자체가 안 되는 상태고요.

비용을 실제로 알기 전까지는 "묶여 있어서 못 옮긴다"와 "익숙해서 안 옮긴다"를 구분할 방법이 없고, 저는 넉 달 동안 둘을 구분하지 않은 채로 전자라고 말해왔습니다.

구글이 왕좌에서 내려왔는지는 이 글로 답이 안 나옵니다. 애초에 제가 답할 수 있는 크기의 질문도 아니었고요. 제가 답을 얻은 건 다른 질문입니다. 저는 순위표를 근거로 도구를 고른다고 생각했는데, 실제로 고른 건 순위가 아니라 6월 18일에 안 끊긴 쪽이었습니다.