결론부터 말하면, 비용과 속도를 최우선으로 하면서 분류, 추출, 짧은 채팅 답변, RAG 답변, 자동 완성처럼 단순한 작업을 대량 처리한다면 Gemini 3.5 Flash-Lite를 선택하세요. 다단계 에이전트, 도구 사용, 코딩, 컴퓨터 사용 또는 잘못된 결과의 비용이 큰 작업이라면 Gemini 3.6 Flash가 더 적합합니다.
두 모델은 2026년 7월 21일 Google의 Flash-tier 업데이트에서 출시되었으며, 모두 최대 100만 입력 토큰을 지원합니다. 핵심은 어느 모델이 절대적으로 “더 좋은가”가 아닙니다. 현재 작업의 품질, 지연 시간, 비용 요구사항에 맞는 모델을 선택하는 것입니다.
명명법도 먼저 정리해 두겠습니다. 주력 Flash 모델은 3.6으로 올라갔지만 Lite 티어는 3.5에 머물렀습니다. 따라서 이 글은 3.5 Flash-Lite와 3.6 Flash를 비교합니다. 표기 오류가 아닙니다.
간단한 선택 기준
수백만 번 실행되는 단순 작업은 Flash-Lite를 기본값으로 사용하세요.
작업에 다음 요소가 포함되면 3.6 Flash로 전환하는 것이 좋습니다.
- 여러 단계의 추론
- 함수 호출 또는 외부 도구 사용
- 코드 작성·수정·검토
- 브라우저 또는 데스크톱 조작
- 오류가 금전적·운영상 비용으로 이어지는 응답
판단이 어렵다면 Flash-Lite로 먼저 운영한 뒤, 품질이 부족한 요청 유형만 3.6 Flash로 승격하세요. 대부분의 서비스는 하나의 모델만 사용하는 것보다 요청 특성에 따라 라우팅하는 편이 효율적입니다.
가격과 속도 비교
| 특성 | Gemini 3.5 Flash-Lite | Gemini 3.6 Flash |
|---|---|---|
| 모델 ID | gemini-3.5-flash-lite |
gemini-3.6-flash |
| 입력 가격 | $0.30 / 100만 토큰 | $1.50 / 100만 토큰 |
| 출력 가격 | $2.50 / 100만 토큰 | $7.50 / 100만 토큰 |
| 처리량 | 초당 약 350개 출력 토큰 | 별도 게시되지 않음 |
| 컨텍스트 창 | 100만 토큰 | 100만 토큰 |
| 무료 티어 | 예, 속도 제한 적용 | 예, 속도 제한 적용 |
Flash-Lite는 모든 토큰 기준으로 더 저렴합니다.
- 입력 토큰: 5배 저렴
- 출력 토큰: 3배 저렴
- 공개 처리량: 초당 약 350 출력 토큰
채팅 입력, 자동 완성, 대량 분류처럼 사용자 체감 지연 시간이 중요한 워크로드에서는 이 처리량 차이가 중요합니다.
Google은 3.6 Flash의 별도 초당 토큰 수를 게시하지 않았습니다. 다만 3.6 Flash는 대체하는 3.5 Flash보다 약 17% 적은 출력 토큰을 생성하므로, 다단계 작업에서는 표시된 단가만으로 판단하기보다 실제 완료 시간과 총 토큰 사용량을 함께 측정해야 합니다.
현재 요금은 Gemini API 가격 페이지와 Gemini 3.6 Flash 가격 분석에서 확인할 수 있습니다.
품질과 벤치마크
가격 차이는 어려운 작업에서의 추론 여유로 이어집니다.
에이전트형 터미널 작업을 평가하는 Terminal-Bench 2.1에서 다음 점수가 보고되었습니다.
| 모델 | Terminal-Bench 2.1 |
|---|---|
| Gemini 3.5 Flash-Lite | 54 |
| Gemini 3.6 Flash | 78.0 |
24점 차이는 다단계·도구 기반 작업에서 3.6 Flash가 더 강력하다는 점을 보여줍니다.
3.6 Flash는 실제 브라우저나 데스크톱을 조작하는 능력을 측정하는 OSWorld-Verified에서 83.0점을 기록했습니다. 코딩에서는 SWE-Bench Pro 58.7%, DeepSWE v1.1 49%를 기록했습니다. 브라우저 조작, 파일 수정, 코드 검토, 티켓 처리처럼 여러 단계가 연결되는 에이전트 작업은 3.6 Flash에 맞습니다.
반대로 Flash-Lite를 단순히 “약한 모델”로 볼 필요는 없습니다. Terminal-Bench 2.1의 54점은 이전 Lite 세대의 31점에서 개선된 결과입니다. Flash-Lite는 분기와 도구 호출이 많지 않은 작업에서 빠르고 저렴하게 충분한 품질을 제공하도록 설계된 모델입니다.
Google의 Flash 모델 페이지와 출시 발표도 두 모델을 같은 방식으로 구분합니다.
- Flash-Lite: 대량 처리 중심
- 3.6 Flash: 깊은 추론과 복잡한 작업 중심
작업별 모델 선택
아래 표를 초기 라우팅 규칙으로 사용한 뒤, 실제 프롬프트와 운영 데이터로 조정하세요.
| 작업 | 권장 모델 |
|---|---|
| 대량 분류 또는 정보 추출 | Flash-Lite |
| 채팅 어시스턴트 및 짧은 답변 | Flash-Lite |
| 검색된 컨텍스트 기반 RAG 답변 | Flash-Lite |
| 자동 완성 스타일의 지연 시간 민감 UX | Flash-Lite |
| 검색 규모의 전체 요청 파이프라인 | Flash-Lite |
| 다단계 에이전트 | 3.6 Flash |
| 도구 사용 및 함수 호출 체인 | 3.6 Flash |
| 코딩 및 코드 검토 | 3.6 Flash |
| 컴퓨터 사용: 브라우저 또는 데스크톱 | 3.6 Flash |
| 오류 비용이 큰 중요 답변 | 3.6 Flash |
실무에서는 다음처럼 나눌 수 있습니다.
- 하루에 천만 건의 지원 티켓을 태깅한다면 Flash-Lite
- 긴 문서에서 정형 필드를 추출한다면 Flash-Lite
- RAG 검색 결과를 짧게 정리한다면 Flash-Lite
- 스택 트레이스를 읽고 여러 파일을 수정한 뒤 풀 리퀘스트를 생성한다면 3.6 Flash
- 외부 API를 연속 호출하며 상태를 판단해야 한다면 3.6 Flash
이전 gemini-3.5-flash에서 업그레이드하는 경우에는 3.6 Flash vs 3.5 Flash 비교도 참고하세요.
동일한 작업 부하의 비용 비교
매일 입력 1,000만 토큰과 출력 200만 토큰을 사용하는 배치 요약 또는 추출 파이프라인을 가정해 보겠습니다.
| 모델 | 입력 1,000만 토큰 | 출력 200만 토큰 | 일일 총액 |
|---|---|---|---|
| Flash-Lite | $3.00 | $5.00 | $8.00 |
| 3.6 Flash | $15.00 | $15.00 | $30.00 |
이 워크로드에서 3.6 Flash는 약 3.75배 더 비쌉니다.
- Flash-Lite: 하루 $8.00, 월 약 $240
- 3.6 Flash: 하루 $30.00, 월 약 $900
다만 실제 차이는 항상 3.75배로 고정되지 않습니다.
- 입력 비중이 높은 작업: 최대 5배 차이에 가까움
- 출력 비중이 높은 작업: 약 3배 차이에 가까움
예를 들어 긴 RAG 컨텍스트, 대규모 문서 처리, 대량 입력 분류는 입력 비중이 높으므로 Flash-Lite의 비용 장점이 더 커집니다. 반대로 긴 생성 응답을 많이 만드는 작업은 두 모델의 비용 차이가 상대적으로 줄어듭니다.
따라서 질문은 단순히 “3.6 Flash가 가능한가?”가 아닙니다.
내 트래픽 규모에서 더 높은 품질을 위해 호출당 3~4배의 비용을 지불할 가치가 있는가?
검색 규모의 반복 파이프라인이라면 대체로 Flash-Lite가 맞습니다. 코드 변경, 티켓 생성, 운영 자동화처럼 오류 비용이 큰 에이전트라면 3.6 Flash가 맞을 가능성이 높습니다.
Apidog에서 두 모델을 A/B 테스트하는 방법
추측으로 모델을 선택하지 마세요. 동일한 프롬프트를 두 모델에 전송하고 품질, 응답 시간, 응답 구조를 비교하세요.
Gemini API는 REST 엔드포인트이므로 Apidog에서 요청을 복제해 모델 ID만 바꾸면 됩니다.
1. API 키를 환경 변수에 저장하기
API 키를 요청 본문이나 Git 저장소에 직접 넣지 마세요. Apidog 환경 변수에 저장합니다.
GEMINI_API_KEY=your_api_key
요청에서 환경 변수를 참조합니다.
{{GEMINI_API_KEY}}
2. Flash-Lite 요청 만들기
모델 ID를 gemini-3.5-flash-lite로 설정하고 실제 서비스 프롬프트를 전송합니다.
{
"model": "gemini-3.5-flash-lite",
"prompt": "다음 지원 티켓을 billing, bug, feature 중 하나로 분류하세요."
}
응답 본문, 상태 코드, 지연 시간을 기록합니다.
3. 요청을 복제하고 3.6 Flash로 변경하기
동일한 요청을 복제한 뒤 모델 ID만 변경합니다.
{
"model": "gemini-3.6-flash",
"prompt": "다음 지원 티켓을 billing, bug, feature 중 하나로 분류하세요."
}
프롬프트, 샘플 데이터, 생성 매개변수는 동일하게 유지해야 모델만 비교할 수 있습니다.
4. 응답 품질과 지연 시간 비교하기
다음 기준을 정해 비교하세요.
- 올바른 분류 또는 추출 비율
- JSON 형식 준수 여부
- 누락 필드 여부
- 잘못된 추론 또는 환각 여부
- 응답 시간
- 출력 토큰 수
- 요청당 비용
5. 자동 어설션 추가하기
“충분히 좋다”를 주관적인 인상으로만 판단하지 말고, 반복 가능한 검사로 정의하세요.
예를 들어 다음 항목을 검증할 수 있습니다.
- HTTP 상태 코드가
200인지 - 응답에 필요한 JSON 필드가 있는지
- 분류 결과가 허용된 값 목록에 포함되는지
- 코드 생성 결과에 특정 함수 또는 파일명이 포함되는지
간단한 분류 응답이라면 다음과 같은 형태를 기대할 수 있습니다.
{
"category": "bug",
"confidence": 0.94
}
운영 기준을 정한 뒤, 해당 기준을 통과하는 가장 저렴한 모델을 기본 경로에 배치하세요. 실패율이 높거나 더 깊은 추론이 필요한 요청만 3.6 Flash로 라우팅하면 됩니다.
테스트 요청을 저장하면 반복 실행할 수 있습니다. 모델 업데이트 이후 품질이나 지연 시간이 바뀌는지 확인하려면 Apidog에서 API 테스트를 주기적으로 재실행하도록 예약하세요.
Apidog는 요청 전송, 응답 비교, 어설션 확인을 도와주지만 모델을 실행하거나 어떤 답변이 더 “스마트한지” 판단하지는 않습니다. 최종 품질 기준은 서비스 요구사항에 맞게 직접 정의해야 합니다.
시작하려면 Apidog를 다운로드하고 Gemini 엔드포인트 요청을 두 개 만들어 보세요.
자주 묻는 질문
Flash-Lite는 3.6 Flash의 열등한 버전인가요?
아니요. 두 모델은 비용, 품질, 속도 곡선에서 서로 다른 지점에 있습니다.
Flash-Lite는 더 저렴하고 빠르지만 어려운 추론 작업에는 한계가 있습니다. 3.6 Flash는 비용이 더 들지만 복잡한 추론과 에이전트 작업에서 더 강력합니다. 단순하고 대량인 작업에서는 Flash-Lite가 더 빠르고 저렴하므로 오히려 더 적합할 수 있습니다.
하나는 3.5이고 다른 하나는 3.6인 이유는 무엇인가요?
이번 업데이트에서 Google은 주력 Flash 모델을 3.6으로 올렸지만 Lite 티어는 3.5를 유지했습니다. 동일한 릴리스에는 3.5 Flash Cyber 보안 모델도 포함되었습니다.
같은 계열이지만 버전 번호가 다릅니다. Flash-Lite의 3.5를 오래되거나 지원이 중단된 모델이라는 의미로 해석하면 안 됩니다.
두 모델의 컨텍스트 창은 동일한가요?
네. 두 모델 모두 최대 100만 입력 토큰을 지원합니다.
긴 컨텍스트 자체는 모델 선택 기준이 아닙니다. 대신 작업의 추론 난이도, 지연 시간, 비용을 기준으로 선택하세요.
하나의 앱에서 두 모델을 함께 사용할 수 있나요?
네. 권장되는 패턴입니다.
- 단순하고 저렴하며 대량인 요청 → Flash-Lite
- 복잡하고 오류 비용이 높은 요청 → 3.6 Flash
API 형태가 동일하므로 모델 ID만 바꿔 전환할 수 있습니다. 이 구조는 A/B 테스트와 점진적 롤아웃에도 적합합니다.
무료로 테스트할 수 있나요?
두 모델 모두 Google AI Studio에서 속도 제한이 적용된 무료 티어를 제공합니다. Google은 무료 티어 데이터를 제품 개선에 사용할 수 있으므로, 민감한 데이터를 보내기 전에는 약관을 확인하세요.
결론
간단하고 대량이며 비용과 속도가 중요한 작업에는 Flash-Lite를 기본값으로 사용하세요.
다음과 같은 요청은 3.6 Flash로 승격하세요.
- 다단계 추론이 필요한 요청
- 도구 호출과 상태 판단이 필요한 에이전트
- 코드 생성·수정·검토
- 브라우저 또는 데스크톱 조작
- 오류가 큰 비용으로 이어지는 응답
추상적으로 선택하지 말고 실제 프롬프트를 두 모델에 모두 전송하세요. 품질, 지연 시간, 토큰 사용량, 실패율을 측정한 뒤 결과에 따라 라우팅 규칙을 정하는 것이 가장 안전합니다. Apidog를 사용하면 이 비교를 두 개의 재현 가능한 API 요청으로 관리할 수 있습니다.


Top comments (0)