멀티 모델 전략

Antigravity를 처음 쓰는 사람은 보통 이렇게 생각합니다. "제일 똑똑한 모델 하나만 고르면 끝 아닌가요?"

아쉽지만, 바로 그 생각이 Agent-First 시대의 가장 비싼 실수 가운데 하나입니다. 좋은 개발자는 이제 코드를 한 줄 한 줄 더 빨리 치는 사람이 아니라, 어떤 일을 어떤 에이전트에게, 어떤 모델로 맡길지 판단하는 사람에 가깝습니다. Antigravity에서도 모델은 프롬프트 박스 아래의 선택기에서 고를 수 있고, 멀티 에이전트 워크플로우에서는 작업마다 다른 모델을 붙여 비용과 성능을 조절하는 감각이 중요해집니다.¹

핵심은 간단합니다. 모델을 숭배하지 말고, 역할에 맞게 배치하라.

왜 하나의 모델로 끝내려 하면 자꾸 삐끗할까

모델마다 잘하는 일이 다르기 때문입니다. 어떤 모델은 긴 문서와 거대한 코드베이스를 읽고 큰 그림을 잡는 데 강합니다. 어떤 모델은 UI 구현이나 코드 정리에 더 자연스럽게 반응합니다. 또 어떤 모델은 비용이 낮고 제어가 쉬워서 반복 작업이나 초안 작성에 유리합니다.

문제는 대부분의 실제 개발 작업이 이 세 가지를 한 번에 다 요구한다는 점입니다. 새 기능 하나를 만든다고 해보겠습니다. 먼저 요구사항을 읽고 구조를 잡아야 합니다. 그다음에는 UI와 API를 구현해야 합니다. 마지막에는 테스트를 돌리고, 스크린샷과 브라우저 기록을 확인하고, 위험한 변경인지 아닌지를 판단해야 합니다. 이 과정을 하나의 모델에만 맡기면, 잘하는 구간에서는 날아다니다가 못하는 구간에서 급격히 속도가 떨어집니다.

그래서 멀티 모델 전략은 "최고 모델 하나를 찾는 일"이 아니라, 작업에 맞게 모델을 라우팅하는 일에 가깝습니다.

모델마다 맡겨야 할 역할이 있다

큰 그림을 읽는 모델

긴 명세, 로그, 코드베이스 구조, 스크린샷, 브라우저 검증 결과까지 한꺼번에 읽고 방향을 잡는 데 강한 모델이 있습니다. 이런 모델은 요구사항 정리, 구조 설계, 영향 범위 분석, 레거시 코드 탐색, 대규모 리팩터링 전 계획 수립에 특히 유리합니다.

쉽게 말해 이런 모델은 "삽질하기 전에 지도를 그려주는 사람"에 가깝습니다. 아직 코드를 쓰지 않았는데도, 어디가 위험한지, 어떤 모듈부터 손대야 하는지, 어떤 파일들이 함께 바뀔 가능성이 큰지를 먼저 보여줍니다. Agent-First 워크플로우에서 이 능력은 매우 중요합니다. 잘못된 방향으로 빠르게 달리는 에이전트만큼 무서운 것도 없기 때문입니다.

다만 구현 단계에 들어가면 아쉬운 순간도 있습니다. 특히 프런트엔드처럼 코드 스타일, 관용적 패턴, 팀의 취향이 중요한 영역에서는 결과물이 "동작은 하지만 왠지 손을 더 봐야 하는 코드"가 되기 쉽습니다. 그래서 이런 모델은 계획과 분석의 선봉으로 쓰고, 구현은 다른 모델에 넘기는 조합이 실무에서 자주 통합니다.

일상 구현에 강한 모델

코드 품질과 요구사항 해석의 균형이 좋은 모델은 일상 구현에서 가장 자주 손이 갑니다. 특히 UI 구현, 컴포넌트 분해, 타입 정리, 함수 경계 다듬기처럼 "사람 개발자가 바로 이어받아도 덜 어색한 코드"를 만드는 데 강한 편입니다.

이런 모델은 실무에서 가장 자주 맡길 수 있는 주전 선수에 가깝습니다. 예를 들면 다음과 같은 작업과 궁합이 좋습니다.

• React와 Tailwind로 화면 구현하기

• 기존 API 스펙에 맞춰 클라이언트 로직 붙이기

• 테스트가 있는 코드베이스에서 점진적 수정하기

• 읽기 쉬운 리팩터링 초안 만들기

이 부류의 모델은 화려한 데모보다, 매일 같이 출근하는 믿을 만한 시니어 개발자에 가깝습니다.

어려운 문제를 마무리하는 상위 모델

복잡한 리팩터링, 위험한 마이그레이션, 여러 파일에 걸친 타입 변경, 원인 불명의 버그 추적처럼 실패 비용이 큰 일은 상위 모델에 맡길 가치가 있습니다. 이런 모델은 추론 깊이와 멀티파일 일관성에서 강점을 보이는 경우가 많습니다.

다만 중요한 점이 있습니다. 상위 모델은 "기본값"이 아니라 "에스컬레이션 카드"여야 합니다. 너무 좋아 보여서 모든 일에 쓰고 싶어지지만, 그렇게 운용하면 쿼터와 비용이 먼저 버티지 못합니다. 마치 팀에서 가장 비싼 외부 컨설턴트를 회의록 정리까지 시키는 것과 비슷합니다.

실전에서는 이런 순간에 상위 모델을 꺼내면 좋습니다.

• 두 번 이상 실패한 난해한 버그

• 여러 파일에 걸친 구조 변경

• 레거시 마이그레이션의 마지막 안전 점검

• 성능, 안정성, 타입 안정성을 동시에 건드리는 변경

• 출시 직전의 고위험 수정

저비용 모델과 대체 모델

오픈소스 모델이나 상대적으로 가벼운 모델의 매력은 "최강"이 아니라 "쓸모"에 있습니다. 비용을 아껴야 하거나, 특정 환경에서 더 강한 통제가 필요하거나, 상위 모델을 쓰기 전에 먼저 초안을 만들어야 할 때 의외로 좋은 카드가 됩니다.

물론 가장 어려운 아키텍처 판단이나 미묘한 코드 품질 경쟁에서는 상위 프런티어 모델보다 한계가 빨리 보일 수 있습니다. 하지만 반복적인 변환 작업, 문서 포맷 정리, 규칙 기반 리라이트, 초벌 코드 생성, 혹은 "다른 모델과 다른 시각의 세컨드 오피니언" 역할에서는 충분히 유용합니다.

한마디로 이런 모델은 주전이라기보다 벤치 멤버 같지만, 시즌 전체를 보면 꼭 필요한 선수입니다.

작업 종류별 추천 배치표

모델을 감으로만 고르면 금방 피곤해집니다. 아래처럼 작업 유형별 기본 배치를 정해두면 훨씬 덜 흔들립니다.

이 표에서 가장 중요한 줄은 마지막입니다. 코드를 쓴 모델과 리뷰하는 모델을 일부러 다르게 가져가는 것입니다. 같은 머리로 쓴 계획을 같은 머리로 다시 검사하면, 틀린 부분도 그럴듯해 보이는 경우가 많습니다. 사람 리뷰에서도 작성자와 리뷰어를 나누듯, 모델도 그렇게 나누는 편이 낫습니다.

실무에서 잘 먹히는 세 가지 오케스트레이션 패턴

설계자-구현자-감사자 패턴

가장 안정적인 방식입니다. 먼저 분석에 강한 모델에게 요구사항 분석과 Implementation Plan을 맡깁니다. 그다음 구현형 모델이 그 계획을 바탕으로 실제 코드를 만듭니다. 마지막으로 처음 쓰지 않은 다른 모델이 diff, 테스트 결과, 스크린샷을 보고 감사자처럼 검토합니다.

이 패턴의 장점은 책임이 분리된다는 점입니다. 계획의 오류와 구현의 오류를 같은 층위에서 보지 않게 됩니다. 특히 Artifact 중심 검증과 아주 잘 맞습니다.

병렬 경쟁 후 수렴 패턴

중요한 설계 문제나 애매한 기능 정의는 처음부터 한 모델에게만 맡기지 않는 편이 좋습니다. 같은 요구사항을 서로 다른 성향의 모델 두 개에 각각 던져 두 개의 계획을 받는 식입니다. 그러면 한쪽은 구조를 더 잘 잡고, 다른 쪽은 구현 단위를 더 현실적으로 쪼개는 식의 차이가 보입니다.

이때 개발자의 역할은 판정자입니다. 둘 중 하나를 고르거나, 좋은 부분만 섞어 새로운 최종 계획을 만듭니다. 기획이 모호할수록 이 패턴의 가치가 커집니다.

싸게 넓게, 비싸게 깊게 패턴

가장 돈을 아끼는 패턴이면서도 의외로 가장 실전적입니다. 초반 탐색과 단순 작업은 저비용 모델이나 상대적으로 가벼운 모델에게 맡깁니다. 그리고 아래와 같은 신호가 보일 때만 상위 모델로 올립니다.

• 같은 문제를 두 번 이상 헛짚을 때

• 변경 범위가 예상보다 훨씬 넓어졌을 때

• 테스트는 통과하지만 설명이 불안할 때

• Artifact를 읽어도 설계 의도가 명확하지 않을 때

• 출시 위험이 커졌을 때

이 방식은 특히 CTO나 테크 리드에게 중요합니다. 좋은 모델을 많이 쓰는 팀이 아니라, 좋은 모델을 필요한 순간에만 쓰는 팀이 오래 갑니다.

쿼터는 모델보다 먼저 설계해야 한다

이제 현실 이야기를 해 봅시다. 멀티 모델 전략은 성능만의 문제가 아닙니다. 결국 쿼터와 비용의 문제입니다.

공식 문서만 봐도 모델 선택과 플랜 구조는 계속 변할 수 있습니다.² 따라서 특정 모델 하나에만 워크플로우를 깊게 얹는 것은 위험합니다. 지원 모델이 바뀌거나, 컨텍스트 정책이 조정되거나, 플랜별 사용감이 달라지는 순간 팀 전체 흐름이 흔들릴 수 있기 때문입니다.

실무에서는 주간 예산이나 사용 원칙을 미리 나눠두는 편이 좋습니다.

• 대부분의 예산은 일상 구현용 주전 모델에 쓴다.

• 설계와 분석용 예산은 별도로 남겨 둔다.

• 상위 모델은 비상 예산처럼 운용한다.

• 저비용 모델은 초안 작성과 반복 작업의 버퍼로 쓴다.

비율은 팀마다 달라질 수 있지만, 원칙은 같습니다. 프리미엄 모델은 항상 남겨둬야 합니다. 가장 중요한 날, 가장 어려운 버그가 마지막에 오기 때문입니다.

좋은 팀은 모델 선택도 문서화한다

개인 개발자는 감으로 버틸 수 있습니다. 하지만 팀은 그러면 안 됩니다. 오늘은 이 모델을 쓰고 내일은 저 모델을 쓰고 모레는 또 다른 모델로 바꾸는 식으로 흔들리면, 결과물 품질도 들쭉날쭉해집니다.

그래서 팀 단위로는 최소한 다음 네 가지를 문서화해 두는 편이 좋습니다.

• 어떤 작업을 어떤 모델부터 시작할지

• 언제 상위 모델로 에스컬레이션할지

• 누가 최종 Artifact를 승인할지

• 쿼터가 바닥날 때 대체 경로가 무엇인지

여기서 문서화의 목적은 통제가 아닙니다. 예측 가능성입니다. 모델이 바뀌어도 팀의 작업 방식은 흔들리지 않게 만드는 것, 바로 그게 리드의 역할입니다.

실전 예시: 대시보드 기능 하나를 맡긴다면

예를 들어 "관리자 대시보드에 통계 카드, 최근 활동 피드, 설정 저장 API를 추가하라"는 작업이 들어왔다고 해보겠습니다.

처음부터 가장 비싼 상위 모델에 전부 맡기는 것은 그럴듯해 보이지만, 보통은 낭비입니다. 더 좋은 배치는 이렇습니다.

먼저 분석형 모델에게 요구사항 정리와 작업 분해를 맡깁니다. 어떤 데이터가 필요하고, API가 몇 개 필요하고, UI 상태가 어떻게 흘러야 하는지 계획을 뽑습니다. 그다음 구현형 모델에게 프런트엔드와 일반적인 API 구현을 맡깁니다. Browser Subagent가 남긴 스크린샷과 녹화물을 보고 UI가 어긋나거나 인터랙션이 매끄럽지 않다면 다시 구현형 모델에게 수정 지시를 내립니다.

그런데 통합 단계에서 권한 처리와 캐시 무효화가 꼬이기 시작했다면? 그때 상위 모델을 투입합니다. 즉, 상위 모델은 초반 선발이 아니라 경기 후반의 마무리 투수에 가깝습니다.

한편 저비용 모델은 반복적인 문서 정리, config 변환, 단순 리네이밍, 또는 통제된 환경에서 돌려야 하는 초벌 작업에 붙일 수 있습니다. 화려하진 않지만, 이런 역할이 팀 전체 쿼터를 꽤 많이 아껴 줍니다.

결국 개발자가 관리해야 하는 것은 코드가 아니라 라우팅이다

Agent-First 시대의 멀티 모델 전략은 "어느 모델이 최고인가"를 가리는 취향 싸움이 아닙니다. 실무의 질문은 완전히 다릅니다.

이 기능의 첫 번째 읽기는 누가 할 것인가. 이 구현의 초안은 누가 쓸 것인가. 이 위험한 diff의 마지막 판단은 누가 내릴 것인가. 그리고 이 모든 걸 지금 남은 쿼터 안에서 어떻게 끝낼 것인가.

바로 그 질문에 답하는 사람이 앞으로의 강한 개발자입니다. 코드를 전부 직접 쓰는 사람이 아니라, 모델의 성격을 읽고, 에이전트를 배치하고, 실패 비용을 통제하는 사람 말입니다.

하나의 모델에 모든 일을 맡기지 마십시오. 오케스트라는 바이올린 하나로 연주하지 않습니다. Antigravity에서도 마찬가지입니다. 좋은 결과는 좋은 모델 하나가 아니라, 좋은 지휘에서 나옵니다.

참고

¹Google Antigravity Documentation - Models

²Google Antigravity Documentation - Plans