단일 모델의 포로가 되지 말자: Antigravity에서 Gemini 3, Claude 4.5, GPT-OSS를 유연하게 전환하는 법
AI로 코드를 작성한 지도 거의 2년이 됐습니다. 처음에는 Copilot 자동 완성을 사용했고, 이후에는 Cursor의 Agent 모드를 거쳐 이제는 온갖 AI IDE를 접하고 있습니다. 계속 무기를 바꿔 드는 검객과도 같습니다. 검마다 잘 맞는 기술은 있지만, 모든 상황에 통하는 검은 없습니다.
그러다 Antigravity를 만났습니다.
가장 놀라웠던 점은 Gemini 3 Pro를 무료로 쓸 수 있다는 것도, Claude 4.5를 지원한다는 것도 아니었습니다. 바로 언제든 모델을 전환할 수 있다는 점이었습니다. 이런 ‘모델 선택권’ 덕분에 더 이상 ‘어떤 모델이 더 좋은가’를 고민하지 않고 ‘이 작업에는 어떤 모델이 더 적합한가’를 생각할 수 있게 됐습니다.
오늘은 Antigravity에서 멀티 모델 전략을 활용하는 방법을 이야기해 보겠습니다.
왜 ‘단일 모델 의존’에서 벗어나야 할까?
혹시 이런 느낌을 받아 본 적이 있나요? 특정 AI 도구에 익숙해지면 어느새 그 도구의 사고방식에 ‘길들여집니다’.
예를 들어 저는 Claude를 오래 사용했습니다. Claude의 코드 스타일에 점점 익숙해지다 보니 무슨 문제를 만나든 무의식적으로 ‘Claude라면 어떻게 처리할까?’부터 생각하게 됐습니다. 하지만 Claude가 모든 일을 잘하는 것은 아닙니다. 복잡한 시스템 아키텍처를 설계하게 하면 큰 그림을 놓치고 세부 사항에 빠질 때가 많고, 아주 긴 컨텍스트를 처리할 때는 가끔 핵심 정보를 빠뜨립니다.
Gemini는 어떨까요? 긴 컨텍스트가 강점이고 아키텍처 계획도 뛰어나지만, 작성한 코드가 가끔 그 언어와 프레임워크의 관습에 충분히 자연스럽지 않습니다.
오픈 소스 대안인 GPT-OSS는 자유도가 높지만, 성능 상한이 상용 모델에 미치지 못하는 것도 사실입니다.
모델마다 자신만의 강점과 사각지대가 있습니다.
한 모델만 붙잡고 씨름하기보다 작업 특성에 맞는 도구를 선택하는 편이 낫습니다. 나사를 박는 데 망치를 쓰지 않는 것과 같습니다. 도구는 문제를 해결하기 위한 것이지 숭배하기 위한 것이 아닙니다.
Antigravity란? 3초 만에 이해하기
Antigravity는 Google이 2025년 말에 선보인 실험적 개발 플랫폼으로, ‘Agentic Development Platform’(에이전트 중심 개발 플랫폼)을 표방합니다.
쉽게 말하면 코드를 대신 작성해 주는 데 그치지 않고, 스스로 사고하고 실행하는 프로그래밍 파트너에 가깝습니다.
현재 세 가지 대규모 언어 모델을 지원합니다.
Gemini 3 Pro: Google의 플래그십 모델입니다. 컨텍스트 창이 매우 크고(200만 token), 복잡한 추론과 긴 문서 이해에 강합니다.
Claude Sonnet 4.5: Anthropic의 최신 코딩 전문 모델입니다. 코드 생성 품질이 매우 높고 요구 사항을 이해하는 능력이 뛰어납니다.
GPT-OSS: 로컬 배포가 가능한 OpenAI의 오픈 소스 모델입니다. 데이터 프라이버시 요구가 높거나 비용을 절감하려는 상황에 적합합니다.
Antigravity에서 모델을 전환하는 방법은 간단합니다. 설정 클릭 → 모델 선택 → 완료. 전체 과정이 3초도 걸리지 않습니다.
상황별 선택: 어떤 작업에 어떤 모델을 쓸까?
상황 1: 복잡한 논리 추론 → Gemini 3 Pro 우선
지난달에 작업 의존 관계, 실패 재시도 메커니즘, 리소스 할당 전략이 포함된 분산 작업 스케줄링 시스템을 설계해야 했습니다. 먼저 Claude에게 설계안을 요청했는데, 곧바로 코드부터 작성하기 시작했습니다. 스레드 풀은 어떻게 설계할지, 데이터베이스 테이블 구조는 어떻게 정의할지부터 다뤘습니다.
코드를 못 썼다는 뜻은 아닙니다. 다만 그때 제게 필요했던 것은 구체적인 구현보다 거시적인 아키텍처였습니다.
Gemini 3 Pro로 바꾸자 먼저 전체 아키텍처 다이어그램을 제시한 뒤 각 모듈을 단계적으로 풀어 나갔습니다. ‘동시 처리량을 고려하면 먼저 무상태 설계를 적용하는 것이 좋습니다. 그래야 수평 확장이 더 쉬워집니다…’와 같은 설명도 덧붙였습니다.
제 판단 기준: 여러 단계의 추론이 필요하거나, 많은 컨텍스트를 유지해야 하거나, 전략적 차원의 사고가 필요한 작업이라면 Gemini가 대체로 더 좋은 선택입니다.
상황 2: 프런트엔드 코드 생성 → Claude 4.5 우선
프런트엔드 개발은 제가 모델을 가장 자주 전환하는 상황입니다.
Tailwind로 UI를 만들 때 Claude의 성능은 놀라웠습니다. ‘검색과 필터링 기능이 있고 페이지네이션과 정렬을 지원하는 데이터 테이블’이라고 설명하면 구조가 명확하고 스타일도 적절한 React 컴포넌트를 바로 생성합니다.
더 놀라운 점은 상태 관리와 이벤트 처리까지 알아서 정리하고, loading 상태와 오류 경계도 추가한다는 것입니다.
Gemini로 같은 작업을 해 본 적도 있습니다. 기능은 구현했지만 코드 스타일이 자주 ‘React답지’ 않았습니다. 때로는 class 컴포넌트를 사용하고, 때로는 state 관리가 혼란스러워 여러 스타일을 섞어 놓은 것처럼 보였습니다.
제 판단 기준: 품질이 높고 모범 사례에 맞는 코드 구현이 필요할 때는 Claude가 더 믿음직합니다.
상황 3: 알고리즘과 수학 중심 작업 → 상황에 따라 선택
알고리즘 문제나 수학적 유도가 필요한 작업에서는 두 모델의 성능 차이가 크지 않지만 스타일은 다릅니다.
Claude는 더 간결한 해법을 제시하는 편이고 코드 가독성도 좋습니다. Gemini는 때때로 단순한 문제를 복잡하게 만들지만, 가끔은 더 기발한 접근 방식을 내놓습니다.
저는 Gemini가 먼저 접근 방식을 제안하고 Claude가 구현하게 합니다. 이렇게 하면 알고리즘의 정확성과 높은 코드 품질을 모두 확보할 수 있습니다.
상황 4: 풀스택 개발 → 조합해서 사용
최근 풀스택 프로젝트를 진행하며 다음과 같은 조합 방식을 찾았습니다.
- 요구 사항 분석 단계: Gemini로 기능 목록을 정리하고 기술 스택 결정
- 아키텍처 설계 단계: Gemini가 시스템 아키텍처 문서(AI Plan) 작성
- 백엔드 개발: Gemini가 API 인터페이스를 설계하고 Claude가 구체적인 로직 구현
- 프런트엔드 개발: 전 과정에서 Claude 사용
- 테스트와 최적화: 두 모델을 섞어 사용하며, 문제가 생긴 부분은 다른 모델로 전환해 시도
이렇게 역할을 나누니 한 모델만 사용할 때보다 개발 효율이 최소 30% 높아졌습니다. 무엇보다 코드 품질이 눈에 띄게 좋아졌습니다. 아키텍처가 명확하고 구현은 우아하며 bug도 줄었습니다.
팀의 모델 선택 기준을 만드는 방법
기술 팀에서 멀티 모델 전략을 제대로 활용하려면 내부 벤치마크 테스트를 한 차례 진행하는 것이 좋습니다.
학술 논문에서 볼 수 있는 표준 benchmark가 아니라 실제 비즈니스에 맞춘 테스트여야 합니다.
1단계: 테스트 작업 설계
최근 수행했던 대표적인 개발 작업 5~10개를 고릅니다. 예를 들면 다음과 같습니다.
- 사용자 권한 시스템 설계
- 데이터 시각화 컴포넌트 작성
- 레거시 모듈 리팩터링
- 결제 프로세스 구현
작업은 팀의 주요 기술 스택과 비즈니스 상황을 아우를 수 있어야 합니다.
2단계: 멀티 모델 병렬 테스트
같은 작업을 Gemini, Claude, GPT-OSS로 각각 수행합니다. 변수를 통제해야 합니다. 프롬프트는 가능한 한 동일하게 유지하고 특정 모델에 추가적인 이점을 주지 마세요.
3단계: 다차원 평가
다음 항목을 기준으로 평가하는 것이 좋습니다.
| 항목 | 가중치 | 설명 |
|---|---|---|
| 코드 정확성 | 30% | 실행되는지, 로직이 올바른지 |
| 코드 품질 | 25% | 가독성과 유지 보수성이 좋은지, 팀 규칙을 따르는지 |
| 완료 속도 | 20% | 프롬프트 입력부터 사용 가능한 코드가 나오기까지 걸린 시간 |
| 컨텍스트 이해도 | 15% | 요구 사항을 정확하게 이해하고 누락하지 않았는지 |
| 리소스 사용량 | 10% | Token 사용량과 응답 시간 |
팀의 선임 엔지니어가 점수를 매기고 최종 결과를 취합합니다.
4단계: 선택 가이드 작성
테스트 결과를 토대로 내부 문서를 작성합니다.
【프런트엔드 컴포넌트 개발】→ Claude 우선, Gemini 차선
【백엔드 API 설계】→ Gemini가 설계안 작성, Claude가 구현
【데이터베이스 설계】→ Gemini(복잡한 관계) / Claude(간단한 CRUD)
【Bug 수정】→ 해당 코드를 작성한 모델로 수정
【기술 조사】→ Gemini(긴 문서 이해)이 문서는 고정된 규칙이 아닙니다. 모델 업데이트와 비즈니스 변화에 맞춰 정기적으로 조정해야 합니다.
실전 예시: 하나의 기능을 완성하는 전체 개발 과정
실제 사례를 통해 멀티 모델 협업 과정을 보여 드리겠습니다.
작업: 실시간 협업을 지원하는 Markdown 편집기 구현
Step 1: 요구 사항 분석(Gemini 3 Pro)
먼저 Gemini에게 요구 사항을 전달했습니다.
“Notion과 비슷한 협업 경험을 제공하는 다중 사용자 실시간 협업 Markdown 편집기를 만들려고 합니다. 필요한 기능 모듈과 권장 기술 선택을 분석해 주세요.”
Gemini는 구조화된 분석 문서를 출력했습니다.
- 핵심 기능: 리치 텍스트 편집, Markdown 파싱, 실시간 동기화
- 기술 선택:
- 편집기: Slate.js 또는 TipTap
- 실시간 동기화: Yjs + WebSocket
- 백엔드: Node.js + Redis
- 핵심 과제: 충돌 해결, 오프라인 지원, 성능 최적화
Step 2: 아키텍처 설계(Gemini 3 Pro)
Gemini에게 아키텍처를 더 구체화하도록 요청했습니다.
“위 분석을 바탕으로 데이터 흐름도와 모듈 구분을 포함한 상세한 시스템 아키텍처 문서를 작성해 주세요.”
Gemini는 시퀀스 다이어그램이 포함된 전체 문서를 생성하고 잠재적인 성능 병목 지점도 몇 가지 짚어 줬습니다.
Step 3: 핵심 코드 구현(Claude 4.5)
Gemini의 아키텍처 문서를 Claude에게 전달했습니다.
“다음 아키텍처 문서를 바탕으로 핵심 편집기 컴포넌트와 실시간 동기화 로직을 구현해 주세요…”
Claude가 코드를 작성하기 시작했습니다. 진행 도중 Yjs 통합에는 다소 익숙하지 않다는 점을 발견해 Gemini로 전환해서 Yjs에 관한 구체적인 질문을 몇 가지 한 뒤, 다시 Claude에게 돌아와 작업을 계속하게 했습니다.
Step 4: UI 구현(Claude 4.5)
프런트엔드 UI는 전 과정에서 Claude를 사용했습니다.
“왼쪽에는 파일 트리, 가운데에는 편집 영역, 오른쪽에는 협업자 목록이 있는 간결한 편집기 UI를 설계해 주세요. Tailwind CSS를 사용하세요.”
Claude가 생성한 UI는 매우 세련됐고 반응형 처리도 훌륭했습니다.
Step 5: 테스트와 최적화(혼합 사용)
테스트 단계에서 여러 사람이 동시에 편집할 때 가끔 커서가 튀는 문제가 발견됐습니다.
먼저 Claude에게 물었더니 선택 영역 동기화 문제라고 진단했지만 해결 방법은 충분히 우아하지 않았습니다.
Gemini로 전환하자 Operation Transformation(OT)을 기반으로 한 최적화 접근 방식을 제안했습니다.
마지막으로 Claude에게 이 접근 방식에 따라 관련 로직을 다시 작성하게 했고 문제가 해결됐습니다.
전체 과정을 한 모델만으로 진행했다면 2~3시간은 더 걸렸을 것입니다.
사용 중 마주치는 함정과 주의 사항
물론 멀티 모델 전략도 완벽하지는 않습니다. 몇 가지 주의할 점이 있습니다.
함정 1: Gemini 3 Pro의 사용량 제한
Antigravity는 개인 사용자에게 무료지만 Gemini 3 Pro에는 사용량 제한이 있습니다. 팀원 여러 명이 동시에 사용하면 ‘사용량을 모두 소진했습니다’라는 메시지가 나타날 수 있습니다.
대안: 핵심 작업에는 Gemini를 사용하고 일상적인 코딩은 Claude로 전환하면 사용량을 아낄 수 있습니다.
함정 2: 전환 비용
모델을 자주 바꾸면 보이지 않는 비용이 생깁니다. ‘이 작업에는 어떤 모델이 더 좋을까?’를 생각하는 데 몇 초가 필요합니다. 간단한 한 줄 코드 자동 완성이라면 이런 고민 자체가 낭비입니다.
제 방식: 간단한 작업에는 한 모델을 고정해서 사용하고(저는 Claude를 선택했습니다), 복잡한 작업에서만 전환을 고려합니다.
함정 3: 응답 속도 차이
Gemini 3 Pro는 일반적으로 Claude보다 사고 시간이 깁니다. 특히 복잡한 작업에서는 더 그렇습니다. 끊김 없는 코딩 흐름을 가장 중요하게 생각한다면 이 점을 고려해야 합니다.
함정 4: 모델 업데이트에 따른 변화
AI 모델은 빠르게 업데이트됩니다. 오늘 Gemini가 잘하는 일을 다음 달에는 Claude가 더 잘할 수도 있습니다. 모델의 역량 변화를 계속 살펴보고 특정 방식에 의존하지 않아야 합니다.
마치며
Antigravity를 한동안 사용하면서 점점 더 확신하게 됐습니다. 미래 개발자의 핵심 경쟁력은 얼마나 많은 API를 외웠는지가 아니라, 여러 AI가 협업하도록 만드는 방법을 아는 데 있습니다.
현재 소프트웨어 아키텍처가 마이크로서비스와 분산 시스템을 중시하듯, AI 보조 개발도 ‘멀티 모델 협업’ 방향으로 발전하고 있습니다. 각 모델은 하나의 specialized service이고 개발자는 orchestrator(오케스트레이터)입니다.
이런 관점에서 보면 Antigravity의 멀티 모델 지원은 단순한 기능이 아니라 새로운 개발 패러다임입니다.
단일 모델의 포로가 되기보다 이런 유연성을 받아들이는 편이 낫습니다. 결국 우리의 목표는 어떤 모델이 가장 강력한지 증명하는 것이 아니라 더 나은 코드를 작성하는 것이기 때문입니다.
Antigravity를 사용해 보셨나요? 댓글에서 멀티 모델 활용 경험을 공유해 주세요.
FAQ
Antigravity는 어떤 대규모 언어 모델을 지원하며, 각각 어떤 특징이 있나요?
**Gemini 3 Pro**: Google의 플래그십 모델로, 200만 token의 초대형 컨텍스트를 제공합니다. 긴 텍스트 이해, 복잡한 추론, 아키텍처 설계에 강하며 여러 단계의 사고가 필요한 작업에 적합합니다.
**Claude Sonnet 4.5**: Anthropic의 코딩 전문 모델로, 코드 생성 품질이 매우 높고 요구 사항을 정확하게 이해합니다. 프런트엔드 개발, 특히 Tailwind와 React에서 뛰어나며 API 설계도 훌륭합니다.
**GPT-OSS**: 로컬에 배포할 수 있는 OpenAI의 오픈 소스 모델입니다. 데이터 프라이버시 요구가 높거나 비용을 절감하려는 상황에 적합하지만, 성능 상한은 상용 모델보다 다소 낮습니다.
Antigravity에서는 3초 만에 모델을 전환할 수 있어 작업 특성에 따라 유연하게 선택할 수 있습니다.
어떤 작업에 어떤 모델을 사용할지 어떻게 결정하나요?
**Gemini 3 Pro**: 복잡한 논리 추론, 긴 문서 이해, 시스템 아키텍처 설계, 기술 조사
**Claude 4.5**: 프런트엔드 코드 생성, 특히 React와 Tailwind, 백엔드 API 구현, 고품질 코드가 필요한 작업
**조합 사용**: 알고리즘 작업에서는 Gemini가 접근 방식을 제안하고 Claude가 구현하게 합니다. 풀스택 프로젝트에서는 Gemini가 아키텍처를 설계하고 Claude가 구현을 맡게 합니다.
**선택 원칙**: 먼저 이 작업에 가장 필요한 역량이 무엇인지 자문해 보세요. 큰 그림이 필요한지 코드 품질이 중요한지, 빠른 응답이 필요한지 깊은 사고가 필요한지 판단한 뒤 습관이나 선호가 아닌 답에 따라 모델을 선택합니다.
팀을 위한 모델 선택 기준은 어떻게 만들 수 있나요?
1) **테스트 작업 설계**: 주요 기술 스택을 아우르는 대표적인 개발 작업 5~10개를 고릅니다.
2) **멀티 모델 병렬 테스트**: 같은 작업을 서로 다른 모델로 각각 수행하되 프롬프트 변수를 통제합니다.
3) **다차원 평가**: 코드 정확성(30%), 코드 품질(25%), 완료 속도(20%), 컨텍스트 이해도(15%), 리소스 사용량(10%)을 평가합니다.
4) **선택 가이드 작성**: 결과를 바탕으로 ‘프런트엔드는 Claude, 아키텍처는 Gemini’와 같은 규칙을 내부 문서로 정리합니다.
모델의 성능은 계속 발전하므로 기준을 정기적으로 업데이트해야 합니다.
멀티 모델 전략을 사용할 때 주의해야 할 함정은 무엇인가요?
**사용량 제한**: Gemini 3 Pro에는 사용량 제한이 있어 팀원 여러 명이 동시에 사용하면 ‘사용량 소진’ 메시지가 나타날 수 있습니다.
**전환 비용**: 자주 전환하면 어떤 모델을 쓸지 고민해야 하므로 간단한 작업에서는 오히려 시간을 낭비할 수 있습니다.
**응답 속도 차이**: Gemini는 일반적으로 Claude보다 사고 시간이 길어 코딩 흐름에 영향을 줄 수 있습니다.
**모델 업데이트에 따른 변화**: AI 모델은 빠르게 발전하므로 계속 관심을 기울이고 특정 방식에 의존하지 않아야 합니다.
**권장 방식**: 간단한 작업에는 Claude처럼 한 모델을 고정해 사용하고, 복잡한 작업에서만 전환을 고려하세요. 각 모델의 성능도 정기적으로 다시 평가해야 합니다.
1분 읽기 · 게시일: 2026년 2월 28일 · 수정일: 2026년 9월 4일
댓글
GitHub로 로그인하여 댓글을 남기세요