모델 선택과 비용/속도 전략: Gemini·Claude·OpenAI 옵션을 목적에 맞추기
모델 선택의 결론: '최고 성능'이 아니라 '업무 적합도'
Antigravity에서 에이전트를 돌려보면 금방 체감합니다. 같은 작업이라도 어떤 날은 "빠르게 여러 번"이 이득이고, 어떤 날은 "한 번에 제대로"가 이득입니다. 이때 모델 선택을 '최고 성능 1개로 고정'해버리면, 비용이 새고 속도가 느려지거나(또는 둘 다), 반대로 품질이 흔들려 검증/수정에 더 많은 시간이 듭니다. 모델 선택은 코스트–레이턴시–지능(추론/정확도)의 3차원 트레이드오프를 관리하는 일입니다.1
그래서 이 챕터의 목표는 단순합니다.
Antigravity의 작업 유형을 몇 가지로 나누고, 각 유형에서 무엇을 우선순위로 둘지(속도, 추론, 코드 품질, 대화 비용)를 기준으로 Gemini·Claude·OpenAI 계열을 어떻게 배치하면 합리적인지를 제시합니다.1
네 가지 판단 축: 속도, 추론(신뢰성), 코드 품질, 대화 비용
모델을 고르기 전에 '내 작업이 무엇을 가장 많이 소모하는지'를 먼저 봅니다.
첫째, 속도(체감 UX)입니다. 특히 Editor View에서 짧은 왕복이 반복되는 작업은 토큰/초(throughput)뿐 아니라 TTFT(Time To First Token)가 체감에 더 크게 작용합니다.2
둘째, 추론(지능)과 신뢰성입니다. 에이전트가 Plan–Execute–Verify로 여러 단계를 밟을수록, 중간에 한 번 삐끗한 출력이 다음 단계에서 눈덩이처럼 커집니다. 이때는 "가끔 천재"보다 "항상 일정"인 모델이 더 이득입니다.1
셋째, 코드 품질입니다. 여기서 말하는 품질은 '정답률'만이 아니라, 프로젝트 컨벤션을 지키는지, 변경 범위를 최소화하는지, 테스트/리팩터링을 함께 제안하는지 같은 실무적 품질입니다. 같은 기능을 만들더라도 리뷰 시간과 롤백 위험이 크게 달라집니다.3
넷째, 대화 비용(토큰 비용 + 대화 설계 비용)입니다. 토큰 비용은 계산 가능한 숫자이고, 대화 설계 비용은 "다시 물어보는 횟수"로 나타납니다. 저렴한 모델이 한 번에 못 끝내면, 결국 비싸질 수 있습니다.4
비용 계산을 '감'이 아니라 '식'으로 바꾸기
API형 모델 비용은 기본적으로 입력/출력 토큰에 비례하고, 출력 토큰이 입력보다 비싼 경우가 많아 긴 답변을 유도하면 비용이 급격히 늘어납니다.4
요청 1회의 비용은 다음처럼 잡으면 됩니다.4
요청 비용 = (입력 토큰/1,000,000 × 입력 단가) + (출력 토큰/1,000,000 × 출력 단가)
여기서 중요한 습관은 한 가지입니다. "답을 더 길게"가 아니라 "증거(Artifacts)를 더 정확히"로 요청을 바꾸는 것입니다. 같은 검증 목적이라도, 긴 설명 대신 테스트/리포트/패치 같은 아티팩트로 끝내면 출력 토큰을 확 줄일 수 있습니다.
또 하나의 실전 팁은 "월 비용"을 대충이라도 먼저 잡는 겁니다. 추정이 있으면 모델 선택이 '감정'에서 '결정'으로 바뀝니다. LLM 비용/속도 추정을 한 화면에 비교하는 방식(요청 수·토큰 수·속도·손익분기점)을 쓰면, 같은 품질을 더 싸게/빠르게 만드는 여지가 바로 보입니다.4
Antigravity 작업 유형별 '권장 모델 성격'
여기서는 제품이나 조직마다 모델 명칭과 버전이 달라도 적용 가능한 형태로 정리합니다. 예를 들어 Flash/mini/nano는 "저비용·고속", Pro/Sonnet은 "중간", Opus/최상위는 "고신뢰·고비용" 성격으로 이해하면 됩니다.5참고로 클로드 모델도 선택을 하면 사용할 수 있습니다.
| 작업 유형(Antigravity에서 자주 나오는 형태) | 우선순위 | 권장 모델 성격 | 왜 이렇게 고르나 |
|---|---|---|---|
| Editor View에서 짧은 반복(리네이밍, 작은 함수 수정, 문서 정리) | 속도·저비용 | Flash/mini급 | 대기시간이 생산성을 좌우하고, 실패해도 수정 비용이 작다.12 |
| "이 코드를 왜 이렇게 짰지?" 같은 이해/설명, 코드 리뷰 초안 | 코드 품질·일관성 | Sonnet/중간급 | 설명과 구조화가 필요하고, 스타일 일관성이 리뷰 시간을 줄인다.3 |
| 다단계 에이전트(여러 파일 수정 → 테스트 → 수정 반복) | 신뢰성·추론 | 상위(reasoning/opus급) 또는 상위+중간 조합 | 한 번의 오류가 체인을 망친다. '일정한 성공률'이 총비용을 낮춘다.1 |
| 대규모 컨텍스트(모노레포/긴 문서/여러 로그를 한 번에 읽히기) | 컨텍스트·추론 | 대컨텍스트 Pro 계열 | RAG를 잘해도 결국 "한 번에 들여보낼 수 있는 양"이 품질을 좌우한다.26 |
| 대량 배치(수천 파일 린트 수정, 마이그레이션 스크립트 생성, 요약 리포트) | 저비용·처리량 | Flash/저가 + 검증 강화 | 대부분은 규칙 기반이고, 실패분만 상위 모델로 에스컬레이션하면 된다.14 |
가장 실용적인 전략: 기본 모델 + 에스컬레이션(승급) + 라우팅
'무조건 좋은 모델' 대신, Antigravity에서는 아래 3단 구조가 가장 잘 맞습니다.
첫째, 기본 모델(Default)을 정합니다. 일상 편집, 짧은 Q&A, 초안 생성은 저비용 모델로 처리해 "대화 횟수" 자체를 늘립니다. Antigravity의 장점은 많이 시켜볼수록 워크플로가 정제된다는 데 있는데, 이 단계에서 고가 모델을 쓰면 실험 자체가 위축됩니다.
둘째, 승급(Escalation) 규칙을 둡니다. 예를 들어 "테스트가 2번 연속 실패", "아티팩트가 스키마를 못 맞춤", "영향 범위가 5개 파일을 넘음" 같은 조건이 나오면 상위 모델로 바꿉니다. 이때 중요한 건 감정적 승급이 아니라, Verify 결과(Artifacts)를 기준으로 승급하는 겁니다.
셋째, 라우팅(Routing)을 명시적으로 설계합니다. 모델 선택을 코드에 박아두지 말고, 요청의 유형(짧은 편집/리팩터/대규모 읽기/배치)을 기준으로 모델을 선택하게 합니다. 모델 라인업은 분기마다 바뀌기 때문에, 아키텍처를 '교체 가능'하게 만드는 것이 장기 비용을 줄입니다.7
Gemini·Claude·OpenAI를 '경쟁'이 아니라 '역할'로 배치하기
세 공급자는 서로 대체재이기도 하지만, 실무에서는 역할이 갈립니다.
Gemini 계열은 전통적으로 큰 컨텍스트와 고처리량(특히 Flash 계열)이 강점인 포지션으로 자주 쓰입니다. 길게 읽히는 작업이나 속도 중심 경로에 배치하면, 사용자가 기다리는 시간이 줄고 비용도 예측하기 쉬워집니다.12
Claude 계열은 일관성과 지시 준수, 코드/문서의 정돈감이 강점으로 자주 평가됩니다. 즉 "당장 돌아가는 코드"보다 "리뷰 가능한 코드"가 중요한 경로(리팩터링, 코드 리뷰, 설계 문서)에서 체감 차이가 큽니다.13
OpenAI 계열은 생태계(도구 호출, 에이전트/자동화 패턴의 표준화)가 강점인 축으로 많이 활용됩니다. 이미 OpenAI 중심으로 도구/SDK를 깔아둔 조직이라면 전환 비용이 줄어들고, 모델 교체보다 라우팅·검증 설계에 집중하기 쉬워집니다.7
정리하면, "셋 중 누가 더 똑똑한가"보다 "내 파이프라인의 어느 구간을 맡길 것인가"가 질문이 됩니다.
출력 토큰을 줄이는 3가지 습관(= 비용/속도 동시 개선)
모델을 바꾸기 전에, 출력 토큰부터 줄이면 체감이 큽니다.
첫째, 결과물을 '설명'이 아니라 '형식'으로 받습니다. 예를 들어 "왜 그런지 설명해줘" 대신 "패치(diff) + 테스트 결과 + 변경 요약(3줄)"로 고정합니다. 형식이 고정되면 군더더기가 줄고, Verify도 쉬워집니다.
둘째, 스트리밍을 기본값으로 둡니다. 같은 총 생성 시간이더라도 TTFT가 줄면 사용자는 "빠르다"고 느끼고, 중간에 원하는 방향이 아니면 즉시 끊어 비용을 절약할 수 있습니다.2
셋째, 긴 대화를 '요약 아티팩트'로 접습니다. 대화가 길어질수록 입력 토큰이 늘고 TTFT도 악화됩니다. 일정 단계마다 핵심 결정, 제약, 미해결 이슈를 한 장 아티팩트로 정리해 다음 요청의 입력을 짧게 만듭니다.
당신의 팀에 맞는 '1주일 모델 실험' 체크리스트
모델 선택은 한 번의 회의로 끝나지 않습니다. 대신 1주일만 제대로 실험하면, 이후는 운영이 됩니다.
먼저 작업을 3개로 쪼갭니다. "짧은 편집", "중간 난도(리뷰/리팩터)", "장거리(여러 파일+테스트)"로 나눠 각 10개씩 샘플을 만듭니다.7
각 샘플에 대해 성공 기준을 아티팩트로 정의합니다. 예를 들어 "테스트 통과", "린트 0", "PR 요약 포함", "스키마 준수"처럼 사람의 호불호를 최소화합니다.
저비용 모델을 기본으로 돌린 뒤, 실패한 케이스만 상위 모델로 승급해 해결률과 총 비용(토큰)을 비교합니다. 이때 '상위 모델만 썼을 때' 대비 얼마나 절약되는지 보는 것이 핵심입니다.4
이 과정을 끝내고 나면, 모델은 취향이 아니라 업무 적합도와 총비용으로 선택됩니다.
참고
1Choosing LLMs for AI Agents: Cost, Latency, Intelligence Tradeoffs
2LLM Leaderboard (Intelligence, speed, TTFT, price) — Artificial Analysis
3Choosing the Right AI Model for Coding: A Developer's Decision Guide for 2026
4Free LLM Speed & Cost Estimator | Simulations4All
5LLM API Pricing Comparison (2025): OpenAI, Gemini, Claude | IntuitionLabs
6AI Tools Compared: ChatGPT vs Claude vs Gemini vs Copilot (2026)
7How to Choose a Large Language Model (LLM): Why Model Selection Is Harder Than It Looks
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.