새 모델이 더 좋아졌다는 소식만으로 전체 자동화를 갈아타기보다, 복잡한 판단은 Gemini 3.6 Flash, 반복·대량 처리에는 Gemini 3.5 Flash-Lite처럼 작업의 실패 비용과 처리량에 맞춰 나누는 편이 안전합니다.
Gemini 3.6 Flash와 Gemini 3.5 Flash-Lite가 함께 공개되면서 “무엇이 더 좋은 모델인가”보다 “우리 자동화의 어느 단계에 넣어야 하는가”가 더 중요한 질문이 됐습니다. 두 모델은 같은 일을 조금 더 잘하는 대체재라기보다, 에이전트 흐름에서 맡길 역할이 다른 선택지에 가깝습니다.
핵심 요약
- Gemini 3.6 Flash는 코드·문서 분석·여러 단계의 판단처럼 결과 품질이 중요한 중심 작업에 맞습니다.
- Gemini 3.5 Flash-Lite는 분류, 추출, 초안 후보 생성처럼 빠르게 많이 처리해야 하는 하위 작업에 어울립니다.
- 공식 가격만 비교하지 말고, 작업 하나를 끝내는 데 드는 재시도·도구 호출·사람 수정까지 함께 기록해야 합니다.
- 새 모델 전환은 전체 교체가 아니라 대표 작업으로 검증한 뒤 제한된 흐름부터 넓혀 가는 방식이 안전합니다.
목차

왜 이번 선택은 ‘성능 1등’ 문제가 아닐까요?
Google은 2026년 7월 21일 Gemini 3.6 Flash와 Gemini 3.5 Flash-Lite를 공개했습니다. 발표에서 3.6 Flash는 코딩·지식 업무·멀티모달 작업을 위한 주력 모델로, 3.5 Flash-Lite는 낮은 지연과 높은 처리량이 중요한 흐름을 위한 모델로 설명됩니다. 즉, 둘을 같은 한 줄 벤치마크로 세우기보다 업무 단계별 병목을 푸는 조합으로 보는 편이 실무적입니다.
예를 들어 고객 문의 1만 건에서 담당 부서와 문서 종류를 먼저 나누는 단계는 빠른 분류가 중요합니다. 반면 예외 사유를 읽고 답변 초안을 만들거나, 여러 시스템의 정보를 대조해 실행 계획을 만드는 단계는 더 신중한 판단이 필요합니다. 앞 단계가 느리면 대기열이 쌓이고, 뒷단계가 부정확하면 사람이 되돌리는 비용이 커집니다.
두 모델의 역할을 어떻게 나눌까요?
Google의 공개 정보에 따르면 Gemini 3.6 Flash의 API 가격은 입력 100만 토큰당 1.50달러, 출력 100만 토큰당 7.50달러입니다. Google은 이전 3.5 Flash 대비 출력 토큰 사용량이 줄고 여러 단계 작업에서 추론 단계와 도구 호출이 감소한다고 설명합니다. 이 수치는 공급사 발표 수치이므로, 실제 워크로드에서는 반드시 같은 입력 묶음으로 확인해야 합니다.
Gemini 3.5 Flash-Lite는 입력 100만 토큰당 0.30달러, 출력 100만 토큰당 2.50달러로 안내됐고, 높은 처리량과 낮은 지연이 필요한 에이전트 검색·문서 처리 사례가 제시됐습니다. 단순히 ‘저렴한 모델’로만 두기보다, 앞단의 대량 처리 작업을 맡기고 중요한 예외를 상위 모델로 보내는 구조가 어울립니다.

| 작업 특성 | 먼저 검토할 선택 | 확인할 기준 |
|---|---|---|
| 코드 변경 계획, 복합 문서 해석, 예외 판단 | Gemini 3.6 Flash | 정확도, 불필요한 수정, 재시도, 도구 호출 |
| 분류, 정보 추출, 짧은 요약 초안, 대량 전처리 | Gemini 3.5 Flash-Lite | 처리량, 지연, 누락률, 예외 전송률 |
| 외부 시스템 변경, 게시·발송 직전 판단 | 모델 단독 결정 대신 승인 단계 | 근거 기록, 권한 범위, 되돌리기 가능성 |
에이전트 흐름에 넣는 4단계 기준
새 모델을 도입할 때는 이름이나 벤치마크 점수보다 각 작업의 실패 비용을 먼저 적어보세요. 다음 네 질문을 순서대로 적용하면 라우팅 규칙을 단순하게 시작할 수 있습니다.
- 이 작업은 얼마나 자주 발생하나요? 하루 수천 번 반복되는 전처리라면 속도와 비용의 비중이 커집니다.
- 실패를 사람이 쉽게 되돌릴 수 있나요? 내부 초안과 외부 발송은 같은 기준으로 다루면 안 됩니다.
- 정답을 확인할 규칙이 있나요? JSON 형식, 필수 필드, 참조 문서 일치처럼 자동 검사가 가능하면 빠른 모델을 더 넓게 사용할 여지가 생깁니다.
- 예외는 어디로 보내나요? 낮은 신뢰도, 긴 입력, 규칙 충돌을 감지하면 상위 모델이나 검토 대기열로 넘기는 탈출구가 필요합니다.
- 뉴스·문서 수집 뒤 제목과 주제를 나누는 단계는 Flash-Lite 후보로 둡니다.
- 여러 출처의 주장 충돌을 정리하고 독자에게 줄 결론을 만드는 단계는 3.6 Flash 후보로 둡니다.
- WordPress 게시처럼 외부 상태를 바꾸는 단계에는 모델 선택과 무관하게 검증·승인을 둡니다.
전환 전에 확인할 운영 체크리스트

- 대표 작업 10~20개를 고릅니다. 자주 발생하는 정상 사례와 실패 비용이 큰 예외 사례를 함께 넣습니다.
- 같은 입력을 기존 경로와 후보 경로에 실행합니다. 결과 품질뿐 아니라 형식 위반, 재시도, 도구 호출, 처리 시간을 남깁니다.
- 작업별 기준을 정합니다. 예를 들어 분류는 누락률, 문서 작성은 사람 수정량, 코드 작업은 테스트 통과 여부로 봅니다.
- 제한된 흐름부터 적용합니다. 되돌릴 수 있는 내부 작업부터 시작하고, 기준을 넘지 못하면 이전 경로 또는 검토 대기열로 돌아갑니다.
- 모델 별칭과 종료 안내를 함께 관리합니다. Google 문서는 안정 버전·미리보기·최신 별칭이 서로 다른 변경 특성을 가진다고 안내합니다. 운영 중인 모델 ID와 변경 공지를 연결해 두면 갑작스러운 교체에 덜 흔들립니다.
결국 중요한 것은 ‘더 싼 호출’이 아니라 ‘더 적은 되돌림’입니다
Gemini 3.6 Flash와 3.5 Flash-Lite의 동시 등장은 모든 작업을 하나의 최고 모델로 몰아넣는 방식에서 벗어날 계기입니다. 판단이 무거운 단계, 대량으로 흘려보내야 하는 단계, 사람이 최종 확인해야 하는 단계를 나누면 비용과 속도, 품질을 동시에 다루기 쉬워집니다.
이번 주에는 자동화 한 개를 골라 보세요. 각 단계를 ‘대량 처리’, ‘복합 판단’, ‘외부 변경’으로 표시한 뒤, 대표 입력 10개로 두 경로를 비교해 보면 됩니다. 작은 라우팅 규칙 하나가 다음 모델 변경 때의 혼란을 크게 줄여줍니다.
자주 묻는 질문
Gemini 3.6 Flash가 더 좋다면 모든 작업에 쓰면 되나요?
반드시 그렇지는 않습니다. 대량 분류나 짧은 추출처럼 처리량과 지연이 중요한 작업은 Flash-Lite가 더 알맞을 수 있습니다. 같은 작업 묶음에서 총 처리 비용과 수정량을 비교해 결정하세요.
모델을 두 개 쓰면 운영이 더 복잡해지지 않나요?
처음에는 두세 개의 규칙만 두는 편이 좋습니다. 예를 들어 ‘대량 전처리’, ‘복합 판단’, ‘외부 변경 전 검토’ 세 구간으로 나누고, 예외만 상위 경로로 보내면 복잡도를 통제할 수 있습니다.
공식 성능 수치를 그대로 운영 기준으로 삼아도 되나요?
공식 수치는 후보를 고르는 출발점입니다. 입력 길이, 도구 구성, 프롬프트, 실패의 정의가 다르면 결과도 달라집니다. 실제 대표 작업을 이용한 비교가 필요합니다.
새 모델은 바로 운영에 넣어도 되나요?
외부 시스템을 바꾸거나 고객에게 결과를 보내는 흐름이라면 바로 전체 전환하기보다 작은 범위에서 확인한 뒤 넓혀 가는 편이 안전합니다. 실패 시 이전 경로나 사람 검토로 돌아갈 조건도 먼저 정해 두세요.
참고 자료
- Google: Gemini 3.6 Flash, 3.5 Flash-Lite, 3.5 Flash Cyber 발표
- Gemini API 모델 문서
- Gemini API 사용량 및 속도 제한 문서
- FLOWIT: AI 에이전트가 멈추기 전에, 모델 변경 런북
이 글이 마음에 드세요?
FLOWIT on YouTube
영상으로도 FLOWIT을 이어서 보세요
AI 자동화, Claude Code, n8n, 데이터 분석 흐름을 블로그와 영상으로 함께 정리하고 있습니다.
AI가 이슈를 닫기 시작했다면: GitHub 자동화에 승인·근거·되돌리기를 넣는 법
MCP가 Stateless로 바뀌는 날: 7월 28일 전 AI 에이전트 연동에서 점검할 6가지
AI 에이전트 성과, 토큰 수 대신 위임 작업으로 측정해야 하는 이유