최근에는 이전부터 계속 갖고 싶었던 에디터를 AI와 바이브 코딩(Vibe Coding)으로 만들고 있습니다.

그 과정에서 느낀 점을 기사로 써보고자 합니다.

저의 현재 코딩 파트너는 에이전트형 IDE인 「Antigravity」이며, 사용하기 시작한 지 3주 정도 지났습니다.

Antigravity에는 Google 계열의 Gemini Models와 Claude and GPT models 두 가지가 있습니다. 이번에는 Gemini Models에 대해 정리해 보겠습니다.

이 Gemini Models는 처음 모델 선택 화면을 보았을 때 누구나 한 번쯤 이렇게 생각하지 않을까요?

「3.5 Flash와 3.1 Pro…… 어라, 숫자가 작은 Pro가 더 똑똑한 거야?」

「3.5가 더 최신 세대 같은데, 왜 Pro가 상위 모델로 취급받는 거지?」

버전 숫자와 모델의 등급(Pro / Flash)이 뒤섞여 있어서, 직관적으로 어느 것을 선택해야 할지 매우 알기 어렵습니다.

저 자신도 처음에는 고개를 갸웃거리며 사용했지만, 「기능 추가」 「디버깅」 「앱 전체 리팩터링 (Refactoring)」 등 다양한 작업에서 양쪽을 비교해 본 결과, 각각의 명확한 특성과 최적의 활용법이 보였습니다.

이 기사에서는 이 혼란스러운 네이밍의 이면부터, 제가 실제 개발에서 체험한 모델별 장단점, 그리고 토큰 소비를 억제하는 팁까지 저를 위한 메모로서 정리해 보고자 합니다.

먼저, 가장 큰 의문인 「버전의 역전 현상」에 대해서입니다. 결론부터 말하자면, Gemini의 네이밍은 **「릴리스된 세대(숫자)」**와 **「모델의 역할(Pro / Flash)」**이라는 두 가지 축이 동시에 움직이고 있기 때문에 이러한 혼란이 발생합니다.

세대 (버전): 3.1 $
ightarrow$ 3.5 (모델의 기본 기술이나 베이스 데이터의 업데이트 시기)

등급 (종별): Flash (고속·저비용형) $
eq$ Pro (심층 사고·범용형)

즉, **「이전 세대의 최고봉 모델 (3.1 Pro)」**과 **「차세대 경량·고속 모델 (3.5 Flash)」**이 화면상에 동시에 나열되어 있는 것입니다.

주변의 예로 들자면, **「한 세대 전의 최고 사양 모델 (Pixel 9 Pro)」**과 「최신 세대의 표준 모델 (Pixel 10a)」 같은 느낌일까요? 최신 세대의 a 모델은 충분히 빠르고 다루기 쉽지만, 특징적인 최신 기능이나 카메라 성능(AI로 치면 복잡한 논리 추론이나 초거대 문맥 유지 능력)에 있어서는 한 세대 전이라 하더라도 Pro 모델이 우세하다는 식의 느낌이라고 생각합니다.

그렇다면 실제 코딩에서 어느 정도 차이가 날까요? 제가 일상적인 개발에서 테스트해 본 실감을 바탕으로 해설하겠습니다.

평소 특정 컴포넌트에 대한 기능 추가, 혹은 에러 로그를 붙여넣어 버그를 수정하는 등의 작업에서는 3.5 Flash (Medium)를 사용했습니다.

솔직히, 이 영역에서는 3.5 Flash (Medium)로 거의 불만이 없습니다.

베이스가 되는 AI 기술 자체가 새로운 덕분에, 최신 라이브러리의 표기법이나 구문에도 매끄럽게 대응해 줍니다. 무엇보다 답변 속도가 매우 빨라서, 「수정하고, 시도하고, 다시 고치는」 작은 시행착오 사이클이 매우 쾌적하게 돌아갑니다.

다만, 가끔 조금 무거운 수정이 될 때는 좀처럼 해결되지 않을 때가 있어서, 그럴 때는 (High)를 써보기도 했지만 별다른 변화는 느끼지 못했습니다. 추론은 깊어지지만 사고 시간은 늘어나기 때문에, 버그가 잘 고쳐지지 않을 때 (High)를 사용함으로써 얻는 안심감 때문에 전환하는, 그런 분위기였습니다.

또한, 구현 전의 디스커션(Discussion)이나 구현 계획서 작성은 추론이 깊은 편이 좋다고 생각하여 (High)를 사용해 구현 계획서를 만들고, 구현 단계에서는 (Medium)을 사용하는 식으로 구분해서 사용하기도 했습니다.

실제로는 전환하는 것을 잊어버려서 계속 (Medium) 상태이거나 (High) 상태인 경우도 자주 있었습니다.

하지만 어느 한쪽 때문에 큰 문제가 발생한 적은 거의 없었습니다.

반면, 확실하게 차이를 느낀 것은 **「앱 전체에 걸친 구조 변경이나 리팩터링 (Refactoring)」**을 수행했을 때였습니다.

3.5 Flash에게 전체 리팩터링 (Refactoring)을 맡기면, 눈앞의 파일은 깔끔하게 정리해 주지만, "A 파일을 수정했더니 결과적으로 D 파일의 타입 정의 (Type Definition)가 깨진다"라거나 "프로젝트 전체의 설계 사상과 일부 컴포넌트 사이의 정합성이 맞지 않게 된다"와 같은 아쉬운 실수가 발생하는 경우가 있었습니다.

여기서 모델을 3.1 Pro (High)로 전환하여 동일한 지시를 내려 보았더니, 동작이 꽤 달라졌습니다.

3.1 Pro는 프로젝트 전체의 코드 구조나 의존 관계 (Dependency)를 머릿속에 넓게 유지한 채 사고하는 느낌이 있었으며, 여러 파일에 걸친 영향 범위를 미리 내다본 상태에서 파탄 없는 정확한 제안을 해주었습니다. "아, 전체상을 조망하며 생각하는 능력은 역시 Pro가 한 수 위구나"라고 실감한 순간이었습니다.

Antigravity를 사용하다 보면 피할 수 없는 문제가 바로 「계정 이용 한도 (Quota · 토큰 상한)」 문제입니다. 모델이나 설정에 따라 이 소모 속도에는 상당한 차이가 발생합니다.

쿼터 (Quota) 소모 속도 (단가): 3.1 Pro 쪽이 확실히 더 무겁습니다. 최상위 모델이기 때문에 이용 한도 소모가 큰 편입니다.

백그라운드에서 생성되는 토큰 수: 의외일 수도 있겠지만, 3.5 Flash (High) 쪽이 사고 토큰 (Reasoning Token) 수가 불어나는 경우가 있는 것 같습니다. Flash는 빠른 시행착오 루프(만들고 테스트하고 수정하는 과정)를 백그라운드에서 여러 겹 회전시켜 답을 내는 설계로 되어 있기 때문입니다.

여기서 포인트가 되는 것은 끝에 붙어 있는 Reasoning (사고 강도) 지정입니다.

처음에는 막연히 "정확도가 높은 편이 좋겠지"라고 생각하여 (High)로 설정하기 쉽지만, 제가 한동안 사용해 보며 도달한 결론은 **"일상적인 사용이라면 3.5 Flash는 Medium으로 충분하다"**는 것입니다.

(High)에서 (Medium)으로 낮춤으로써 다음과 같은 이점이 있었습니다.

• 불필요한 장고 (백그라운드에서의 시행착오)가 줄어들어 응답 속도가 매우 빨라짐
• 생성되는 사고 토큰 수가 억제되어 이용 한도 (Quota)를 더 오래 유지하기 쉬움

일상적인 간단한 수정이나 코드 생성이라면 Medium에서도 답변의 정확도는 거의 떨어지지 않습니다. 한도를 신경 쓰며 조심스럽게 사용하기보다, Medium으로 거침없이 개발을 진행하는 편이 더 낫다고 생각합니다.

이러한 경험을 거쳐, 현재 저는 Antigravity에서 다음과 같은 3단계 전환 규칙으로 운용하고 있습니다.

스텝 1 (기본 스타일): 3.5 Flash (Medium)

• 기본값은 이것 하나입니다. 속도도 빠르고 비용도 최소한입니다. 평소의 기능 추가나 디버깅의 9할은 이것으로 완결됩니다.

스텝 2 (조금 까다로울 때): 3.5 Flash (High)

• 복잡한 알고리즘이나, 한 번에 고쳐지지 않는 수수께끼 같은 에러를 마주하면 사고 강도를 High로 높여 재시도합니다.

• 구현 전의 디스커션(Discussion)이나 구현 계획 작성 등, 강한 사고 강도가 있어야 되돌아오는 작업(Backtrack)이 적을 것 같은 경우에는 High가 좋아 보입니다.

스텝 3 (설계 변경 · 전체 수정): 3.1 Pro (High)

• 앱 전체의 리팩터링 (Refactoring), 대규모 공통화, 설계의 초기 구축 등 "실패하고 싶지 않은 전체 작업"일 때만 결정적인 순간에 전환합니다.

버전 숫자만 보면 혼란스러운 Gemini이지만, "스피드와 국소 수정의 3.5 Flash", "전체 설계와 깊은 사고의 3.1 Pro"라는 역할을 이해하면 단번에 개발 파트너로서 다루기 쉬워집니다.

향후 등장할 것으로 기대되는 3.5 Pro (Flash의 속도감과 Pro의 사고력이 융합된 본래의 모델)의 출시를 즐겁게 기다리며, 우선은 이 구분법으로 스트레스 없는 AI 개발 환경을 만들어 보세요!

또한, Gemini Model은 이용 한도 소모량이 내용에 따라 꽤 달라지는 것 같아서, 무거운 것과 가벼운 것의 차이가 꽤 크게 느껴지기도 합니다. 이 부분에 대해서도 또 깨닫는 것이 있다면 기사로 써보고 싶습니다.

끝까지 읽어주셔서 감사합니다!