Gemini 3.5 Flash 코딩 에이전트 첫 주 — 7가지 실측 후기
코딩 에이전트 비용이 부담돼서 더 싼 모델로 바꿔볼까 고민해 본 적 있으시죠? 본인도 그랬어요. 5월 19일 구글 I/O 26에서 Gemini 3.5 Flash가 정식 출시(GA)되면서 첫 주 동안 본인 실제 작업 7가지에 돌려봤어요.
Flash의 핵심은 가격이에요. 1M 입력 $1.50·출력 $9. GPT-5.5($5/$30)·Claude Opus 4.7($5/$25)과 비교하면 약 3분의 1 수준. 그런데 구글이 "에이전트와 코딩에서 프런티어 성능"이라고 표현할 만큼 단순 저가 모델이 아니라 장기·다단계 작업까지 노린 모델이거든요.
이번 글은 첫 주 7가지 작업에서 Flash가 어디서 본전이고 어디서 한계인지, GPT-5.5·Claude Opus 4.7과 어떻게 분기하는지 정리. 모든 수치는 5월 19일부터 5월 26일까지 직접 측정한 본인 데이터예요.

1. 보일러플레이트·정형 코드 생성 — Flash 압승 구간
가장 본전 큰 작업. CRUD API 엔드포인트, React 폼 컴포넌트, DB 스키마 마이그레이션, 설정 파일 같은 정형 코드 생성. 패턴이 명확한 작업이라 Flash가 속도·비용 모두 우위예요.
본인 첫 주 측정 — Next.js API 라우트 12개를 Flash로 생성했는데 Opus 4.7로 같은 작업 했을 때와 품질 차이가 거의 없었어요. 속도는 체감으로 더 빨랐고, 비용은 약 3분의 1. 정형 작업에 비싼 모델 쓰는 건 돈 낭비더라고요.
본인 노하우 — (1) 기존 코드에서 패턴 예시 1~2개를 프롬프트에 첨부, (2) "이 패턴 그대로 나머지 엔드포인트 생성해" 지시, (3) 생성 후 lint·타입 체크로 검증, (4) 통과하면 채택. 이 흐름이면 Flash로 정형 작업 90% 처리 가능해요.
2. 테스트 코드 자동 작성 — 커버리지 빠르게 채우기
두 번째 본전 구간. 기존 함수·컴포넌트의 단위 테스트·통합 테스트 작성. 테스트는 정형성이 높아서 Flash가 빠르게 잘 처리해요.
본인 실측 — 기존 유틸 함수 28개에 대한 Jest 테스트를 Flash로 일괄 작성. 평균 함수당 30초 정도로 케이스를 뽑아줬고, 엣지 케이스 누락은 본인이 한 번 더 검토해서 보완. 커버리지 60%대에서 85%로 끌어올리는 작업이 한나절 만에 끝났어요.
본인 노하우 — (1) 테스트 프레임워크·컨벤션을 프롬프트에 명시, (2) "해피 패스 + 엣지 케이스 + 에러 케이스 다 작성해" 지시, (3) 생성된 테스트 직접 실행해서 통과 확인, (4) 의미 없는 테스트(항상 통과하는 더미)는 제거. 테스트 작성은 Flash로 충분해요.
3. 레거시 코드 리팩터링·마이그레이션 — 단계 쪼개면 안정적
세 번째 작업. 오래된 클래스 컴포넌트를 함수형 + 훅으로 전환, JavaScript를 TypeScript로 마이그레이션 같은 작업. 규모가 크지만 패턴이 반복돼서 Flash로 처리 가능해요. 단 한 번에 통째로 던지면 안 돼요.
본인 실측 — 파일 40개 TypeScript 마이그레이션을 처음엔 한 번에 던졌더니 중간에 타입 정의가 흔들렸어요. 그래서 파일 5개씩 묶어서 8단계로 쪼개고 단계마다 컴파일 검증을 넣었더니 안정적으로 완료. Opus 4.7보다 단계 설계를 더 신경 써야 했지만 비용은 3분의 1이라 본전이었어요.
본인 노하우 — (1) 마이그레이션을 5~7개 작은 묶음으로 쪼개기, (2) 묶음마다 컴파일·테스트 검증, (3) 통과하면 git commit으로 체크포인트, (4) 실패하면 그 묶음만 재시도. AI 코딩 에이전트 활용 패턴은 AI 코딩 에이전트 순위 비교 후기에서 모델별 차이를 더 자세히 정리했어요.

4. 가장 어려운 디버깅 — 여전히 Claude Opus 4.7이 우위
분기가 가장 명확한 구간. 원인이 불명확한 버그, 여러 모듈이 얽힌 복잡한 디버깅, 미묘한 동시성·메모리 문제는 Flash보다 Opus 4.7이 안정적이에요. Opus 4.7은 93개 작업 벤치마크에서 Opus 4.6 대비 13% 더 풀었고, 둘 다 못 풀던 4개 작업까지 해결할 만큼 어려운 작업에 강점이거든요.
본인 실측 — 간헐적으로 재현되는 race condition 버그를 Flash에 3번 물었는데 표면적 증상만 짚고 근본 원인을 놓쳤어요. 같은 문제를 Opus 4.7에 올렸더니 비동기 호출 순서 문제를 정확히 짚었어요. 어려운 20%는 Opus로 분기하는 게 시간·비용 모두 본전이에요.
본인 노하우 — (1) 버그 재현 단계·로그·환경을 최대한 첨부, (2) Flash로 먼저 시도(싸니까), (3) 2~3번 시도해도 근본 원인 못 짚으면 즉시 Opus로 승급, (4) Opus 답변으로 수정 후 Flash로 회귀 테스트 작성. 모델을 난이도로 분기하면 비싼 호출을 최소화할 수 있어요.
5. 코드베이스 탐색·문서화 — 긴 컨텍스트 처리 본전
다섯 번째 작업. 처음 보는 코드베이스 구조 파악, 함수 의존성 추적, README·주석 자동 생성. Flash도 긴 컨텍스트를 충분히 처리해서 비용 대비 본전이 커요. 가장 큰 대용량 분석은 6월 나올 Gemini 3.5 Pro(2M 토큰)가 더 강하겠지만 일반 코드베이스엔 Flash로 충분해요.
본인 실측 — 약 1만 5천 줄 규모 오픈소스 레포를 Flash에 통째로 넣고 "핵심 모듈 5개와 데이터 흐름 설명해" 요청. 정확한 구조 요약을 받았고, 이어서 주요 함수 50개에 JSDoc 주석을 일괄 생성. 문서화 작업이 반나절 만에 끝났어요. Opus로 했다면 비용이 3배였을 작업이에요.
본인 노하우 — (1) 레포를 파일 트리 + 핵심 파일 내용으로 정리해서 첨부, (2) "구조 → 데이터 흐름 → 진입점 순서로 설명해" 지시, (3) 받은 요약을 본인이 코드로 한 번 검증, (4) 문서화는 Flash로 일괄 처리. 대용량 분석 본전은 Claude Opus 4.7 1M 컨텍스트 실전 활용법과 비교해서 모델을 고르면 돼요.
6. 멀티시간 자율 빌드 — 사람이 단계 설계하면 본전
본인이 가장 신중하게 본 구간. Flash로 멀티시간 자율 빌드(예: 작은 SaaS 기능 통째로 구현)를 맡길 수 있느냐. 결론은 "가능하지만 사람이 단계를 설계하고 체크포인트를 잡아야 본전"이에요.
본인 실측 — 알림 기능(이메일 + 인앱) 전체 구현을 Flash에 맡겼는데, 한 번에 통째로 던지니 중간에 방향을 약간 잃었어요. 그래서 (1) DB 스키마, (2) 백엔드 API, (3) 큐 워커, (4) 프런트 UI, (5) 테스트 5단계로 쪼개고 단계마다 자가검증 프롬프트("작성 후 직접 실행해 통과 확인하고 보고해")를 넣었더니 안정적으로 완료. 완전 무인 멀티시간은 아직 Opus 4.7이 더 안정적이지만, 사람이 설계하면 Flash로도 충분히 본전이에요.
본인 노하우 — (1) 멀티시간 작업을 5~7단계로 명확히 쪼개기, (2) 단계마다 자가검증 + git commit 체크포인트, (3) 1시간마다 본인이 중간 리뷰, (4) 방향 어긋나면 그 단계만 재지시. 사람이 감독자 역할만 하면 비용 절반으로 멀티시간 작업 가능해요.
7. 모델 자동 라우팅 — 난이도로 분기하는 규칙이 핵심
마지막이자 가장 중요한 패턴. 모든 호출을 Flash로 돌리는 것도, 모두 Opus로 돌리는 것도 정답이 아니에요. 작업 난이도로 모델을 자동 분기하는 라우터를 짜는 게 본전이에요.
본인 실측 본전 라우팅 규칙 — (1) 정형 작업(보일러플레이트·테스트·리팩터링·문서화) → Flash. (2) 일반 기능 구현 → Flash 먼저, 막히면 Opus 승급. (3) 어려운 디버깅·아키텍처 설계 → 처음부터 Opus 4.7. (4) 대용량 한 번에 분석 → 6월 Gemini 3.5 Pro 또는 Opus 4.7. 이 규칙으로 본인 5월 API 비용이 약 62% 줄었어요(본인 사용 패턴 기준, 절대 수치는 다를 수 있음).
본인 노하우 — (1) 작업 시작 전 난이도를 3단계(쉬움·보통·어려움)로 라벨링, (2) 쉬움·보통은 Flash, 어려움은 Opus로 라우팅, (3) Flash가 2~3번 막히면 자동 승급 규칙 적용, (4) 월말에 모델별 호출 비율·비용 점검해서 라우팅 규칙 조정.
Flash 한계 3가지 — 첫 주에 부딪힌 부분
본인 첫 주 실측에서 만난 한계 3가지. (1) 가장 어려운 추론 — 복잡한 동시성·미묘한 알고리즘 버그는 Opus 4.7 대비 누락이 약간 더 잦았어요. 어려운 20%는 Opus 분기 필요. (2) 방향 유지 — 한 번에 큰 작업 던지면 중간에 방향 흔들림. 단계 쪼개기로 회피. (3) 가장 큰 컨텍스트 — 2M 토큰급 초대형 분석은 6월 Pro 대기. Flash 컨텍스트로도 일반 코드베이스는 충분하지만 거대 모노레포 한 번에는 한계.
본인 추정 — (1)은 6월 Pro로 보완 가능, (2)는 프롬프트 설계로 회피, (3)도 Pro 대기. 한계 영역은 Opus 4.7로 분기하면서 강점 영역에서 Flash로 비용 뽑는 게 본전이에요.
Flash 첫 주 셋업 가이드 — API 키부터 IDE 연결까지
처음 시작하는 분을 위해 본인이 첫날 거친 셋업 순서를 정리할게요. 어렵지 않아요.
(1) Google AI Studio 접속 — 구글 계정으로 로그인 후 API 키 발급. 무료 크레딧으로 첫 작업을 테스트할 수 있어요. (2) 모델 ID 확인 — Gemini 3.5 Flash의 모델 ID를 코드·도구에 지정. (3) IDE 연결 — Antigravity 2.0은 기본 통합이라 바로 쓸 수 있고, Cursor·Windsurf는 설정에서 Gemini API 키를 넣고 Flash를 모델로 선택. (4) 첫 작업 테스트 — 정형 코드 생성(API 라우트·테스트 코드)부터 시작해 속도·품질 체감.
본인 노하우 — (1) 무료 크레딧 한도 안에서 충분히 테스트 후 유료 전환 판단, (2) API 키는 환경변수로 관리(코드에 하드코딩 금지), (3) 첫날은 정형 작업으로 감 잡고 둘째 날부터 난이도 분기 규칙 정립. Antigravity 2.0 IDE 첫 주 셋업은 Google Antigravity 2.0 IDE 첫 주 5빌드 후기에서 더 자세히 다뤘어요.
비용·속도·품질 분기 정리 — 한눈에 보는 본전 매핑
첫 주 실측을 작업 종류별로 한 번에 정리할게요. 어떤 작업에 어떤 모델이 본전인지 매핑이에요.
(1) 보일러플레이트·테스트·문서화·정형 리팩터링 → Flash. 비용 3분의 1, 속도 빠름, 품질 차이 거의 없음. 일상 코딩의 대부분이 여기 속해요. (2) 일반 기능 구현 → Flash 먼저, 막히면 Opus 승급. 폴백 규칙으로 비용 최소화. (3) 가장 어려운 디버깅·복잡 아키텍처 설계 → Claude Opus 4.7. 어려운 작업 강점이 비용을 정당화. (4) 초대용량 코드베이스 한 번에 분석 → 6월 Gemini 3.5 Pro(2M 토큰) 대기 또는 분할 처리.
본인 노하우 — (1) 작업의 80%는 Flash로 충분하다는 전제로 시작, (2) Flash가 2~3번 막히는 어려운 20%만 Opus로, (3) 월말 모델별 호출 비율·비용을 점검해 분기 규칙 조정. 핵심은 '싸니까 다 Flash'도 '좋으니까 다 Opus'도 아니라 작업 난이도로 자동 분기하는 습관이에요. 이 매핑만 잡아도 코딩 비용을 안정적으로 관리할 수 있어요.
마무리 — 지금 당장 할 수 있는 3가지
(1) Google AI Studio에서 Flash API 키 발급 — 무료 크레딧으로 첫 작업 테스트. 정형 코드 생성부터 시작하면 속도·비용 차이 바로 체감. (2) 난이도 라우팅 규칙 1개 만들기 — "테스트·보일러플레이트는 Flash, 어려운 디버깅은 Opus"부터 적용. 한 달 비용 점검하면 절감 폭 확인 가능. (3) 멀티시간 작업은 단계 쪼개기 + 자가검증 — 5~7단계로 쪼개고 체크포인트 잡으면 Flash로도 안정적. 5월 26일 기준 본인 실측 7가지 패턴 중 정형 작업·테스트·문서화 3개부터 Flash로 옮기는 걸 추천해요.