Gemini 4 Pro 코딩 인증이 뜨는 이유와 제대로 검증하는 법

“Gemini 4 Pro만으로 만들었다”고 쓰면 개발자들의 관심을 끌 수 있을까. AI 코딩 도구를 둘러싼 경쟁이 거세지면서 모델 이름 자체가 콘텐츠의 제목이 됐다. 그러나 지금 물어야 할 것은 어느 진영이 이겼느냐가 아니다. 그 결과물을 누가 다시 실행해도 확인할 수 있느냐다.

Gemini 4 Pro는 아직 공식 모델명이 아니다

2026년 9월 22일 기준, Google DeepMind의 모델 카드 목록에는 Gemini 3.1 Pro와 Gemini 3.8 Flash 등이 올라와 있다. Gemini 4 Pro라는 공개 모델은 없다. Gemini API 가격표에서 확인되는 Pro 계열 최신 모델도 gemini-3.1-pro-preview다.

따라서 지금 “Gemini 4 Pro로 코딩했다”는 문구를 공식 제품 사용 기록으로 받아들이기는 어렵다. 내부 시험판이나 차기 모델을 추측한 표현일 수 있지만 Google이 공개한 모델 ID와 연결되지 않는다. 모델 선택 화면이나 API 응답, CLI 세션에 찍힌 정확한 이름을 함께 제시해야 검증할 수 있는 정보가 된다.

이름의 혼선 자체는 관심을 끄는 재료다. 커뮤니티 대화에서도 새로운 Gemini의 소감을 묻는 질문이 곧 Claude나 다른 코딩 모델과의 비교 농담으로 번졌다. 특정 도구만 사용했다는 선언이 반대편 사용자의 확인 욕구를 자극한다는 의견도 많았다.

모델보다 실행 도구가 결과를 크게 바꾼다

Gemini로 코딩한다는 말에는 여러 작업 방식이 포함된다. 채팅창에서 코드를 복사할 수도 있고 Google AI Studio에서 앱을 생성할 수도 있다. Gemini Code Assist의 에이전트 모드나 터미널용 Gemini CLI도 선택지다.

Gemini CLI는 프로젝트 파일을 읽고 수정하며 셸 명령과 웹 검색을 실행하는 오픈소스 에이전트다. GEMINI.md에 프로젝트 규칙을 저장하고 @src/처럼 경로를 지정해 문맥을 넣을 수 있다. MCP 연결과 비대화형 실행도 지원한다. 2026년 9월 15일 나온 안정판 0.60.0은 확장 기능 동의 절차와 샌드박스 경계 검사를 강화했다.

Claude Code도 파일 편집과 셸 실행, MCP, 비대화형 출력 기능을 갖춘 터미널 에이전트다. 같은 Gemini 모델이라도 AI Studio와 Gemini CLI에서 결과가 다를 수 있다. 같은 Claude 모델 역시 채팅과 Claude Code에서 작업 완주율이 달라질 수 있다. 모델의 추론 능력과 에이전트의 파일 탐색·도구 호출·오류 복구 능력을 나눠서 봐야 한다.

써본 사람들 사이에서는 Gemini가 긴 문맥을 읽고 작은 기능을 빠르게 만드는 데 유용하다는 반응이 있다. 대규모 수정에서는 응답이 느려지거나 연결 재시도와 과도한 파일 변경 때문에 작업이 끊긴다는 불만도 나온다. 어느 쪽도 모델명만으로 설명되지는 않는다.

그림판 과제는 한 번에 만든 화면보다 버그가 중요하다

AI 코딩 모델을 비교하려면 결과가 눈에 보이면서도 내부 구현을 속이기 어려운 과제가 좋다. 벡터 그림판은 이 조건에 잘 맞는다. 자유곡선만 그리는 앱은 간단하다. 하지만 객체 선택과 이동, 부분 지우기, 실행 취소까지 넣으면 데이터 구조와 좌표 계산이 드러난다.

빈 저장소에서 Vite와 React, TypeScript로 시작한다고 하자. requirements.md에는 자유곡선·직선·사각형·원·폴리라인, 색상과 굵기 변경, 객체 선택과 이동, z-order, undo·redo를 적는다. 각 도형은 Canvas에 바로 굽지 않고 객체 배열이나 SVG 요소로 보존하도록 요구한다.

부분 지우기는 특히 좋은 함정이다. 배경색 선을 위에 덮는 방식은 겉보기에는 성공한다. 그러나 원본 객체를 옮기면 지웠던 선이 다시 나타난다. 화면 캡처 한 장으로는 발견하기 어렵다.

프롬프트에는 “기능 구현 후 테스트를 실행하고 실패 원인을 고쳐라”를 넣는다. 산출물은 소스 코드, 실행 명령, 테스트 결과, 남은 결함 목록이다. Gemini CLI 공식 가이드도 편집 뒤 npm test 같은 명령으로 결과를 확인하도록 안내한다.

비교 게시물에는 프롬프트보다 실행 기록이 더 필요하다

재현 가능한 비교는 두 도구에 같은 커밋과 같은 요구사항을 제공하는 데서 시작한다. Gemini CLI는 프로젝트 폴더에서 gemini를 실행하고 Claude Code는 같은 위치에서 claude를 실행한다. 모델 자동 선택을 썼다면 그 사실도 기록해야 한다.

공개할 항목은 여섯 가지면 충분하다. CLI 버전과 실제 모델 ID, 시작 커밋, 최초 프롬프트, 사람이 추가로 개입한 횟수, 테스트 로그와 최종 diff다. 소요 시간만 재서는 오래 고민해 정확히 고친 실행과 빠르게 오답을 만든 실행을 구별하지 못한다.

한 번의 성공을 모델 전체의 성능으로 확대해서도 안 된다. 같은 과제를 새 세션에서 세 차례 이상 실행하면 결과의 편차를 볼 수 있다. 기능별 통과 여부를 나누고 빌드 실패와 런타임 오류, 회귀 버그를 별도로 세면 자극적인 승패표보다 훨씬 쓸모 있는 자료가 된다.

바이럴 데모와 실제 생산성은 다른 질문이다

Google의 2025년 DORA 연구는 AI가 조직의 강점과 약점을 증폭한다고 설명했다. METR이 숙련된 오픈소스 개발자 16명과 실제 이슈 246개를 시험한 연구에서는 당시 AI 도구 사용군의 작업 시간이 오히려 19% 늘었다. 연구진은 특정 개발자와 2025년 초 도구에 한정된 결과라고 선을 그었다.

짧은 데모가 무의미하다는 이야기는 아니다. 개인 개발자나 소규모 팀은 그래픽 편집기처럼 경계가 분명한 과제로 새 모델을 탐색하는 비용을 줄일 수 있다. 다만 “몇 분 만에 완성”이라는 문장은 검수와 수정 시간을 감추기 쉽다.

Gemini라는 이름은 클릭을 만들고 Claude와의 비교 구도는 댓글을 부른다. 하지만 다음 AI 코딩 게시물에서 오래 남을 정보는 승자 선언이 아니다. 정확한 모델 ID, 움직이면 되살아나는 선 하나, 그리고 그 버그를 잡아낸 테스트 기록이다.