요약: Google은 Gemini 3.5 Flash를 GA로 소개하면서 agentic execution, coding, long-horizon task에 최적화된 Flash 모델이라고 설명했습니다. 1M 토큰 컨텍스트, 65k 최대 출력, thinking 지원, thought preservation이 핵심입니다. 동시에 기본 thinking effort가 high에서 medium으로 바뀌었고, low thinking도 코드·에이전트 작업에서 개선됐다고 안내합니다. 실무에서는 작업 난이도별 라우팅 기준을 정하는 것이 중요합니다.
Flash 계열 모델은 보통 “빠르고 저렴한 모델”로 이해됩니다. 하지만 Gemini 3.5 Flash 설명은 단순 요약 모델이 아니라 agentic execution과 coding task를 전면에 둡니다. 즉, 단일 질문 답변보다 여러 단계의 코드 탐색, 도구 호출, 하위 에이전트 실행, 긴 문맥 유지에 쓰라는 신호입니다.
문제는 모든 작업을 같은 effort로 돌리면 비용과 지연 시간이 불안정해진다는 점입니다. 간단한 타입 오류 수정과 30개 파일 아키텍처 변경은 같은 모델을 써도 다른 실행 정책이 필요합니다. Google 문서는 Gemini 3.5 Flash의 기본 thinking effort가 medium으로 바뀌었고, low thinking이 더 짧은 코드·에이전트 작업에서 좋아졌다고 설명합니다. 이 말은 운영자가 effort를 명시적으로 설계해야 한다는 뜻입니다.
실무 기준은 “작업 위험도와 탐색 범위”입니다. 빠르게 답해도 되는 작업은 low, 일반적인 코드 수정은 medium, 장기 계획과 복잡한 도구 사용이 필요한 작업은 high 또는 더 강한 모델 후보를 검토합니다. 모델 선택보다 먼저 라우팅 규칙을 문서화해야 합니다.
low thinking은 짧고 경계가 명확한 작업에 적합합니다. 예를 들어 타입 에러 원인 설명, 단일 함수 리팩터링 제안, README 일부 업데이트, 테스트 실패 로그 요약, 간단한 SQL 쿼리 작성 같은 작업입니다. 이들은 긴 추론보다 정확한 문맥 추출과 빠른 응답이 중요합니다.
좋은 low 작업의 조건은 세 가지입니다. 첫째, 입력 파일 수가 적습니다. 둘째, 성공 기준이 명확합니다. 셋째, 실패해도 위험이 낮습니다. 예를 들어 “이 TypeScript 에러를 설명하고 수정 후보를 2개 제시해줘”는 low로 충분할 수 있습니다. 반면 “결제 모듈 구조를 바꿔줘”는 low에 넣으면 안 됩니다.
low thinking 프롬프트에는 탐색 금지 조건을 넣는 것이 좋습니다. “관련 파일 2개만 보고 답하라”, “코드 수정 없이 원인만 설명하라”, “추측이면 추측이라고 표시하라”처럼 범위를 좁히면 품질이 안정됩니다. 빠른 모델에게 넓은 문제를 던지면 속도 장점이 사라지고, 결과도 애매해집니다.
Gemini 3.5 Flash의 기본 effort가 medium이라는 점은 운영 기본값으로 의미가 있습니다. medium은 대부분의 개발 보조 작업에 적당한 균형점입니다. 여러 파일을 읽고, 테스트 실패를 해석하고, 작은 PR을 만들고, API 사용 예제를 작성하는 수준이라면 medium에서 시작하는 편이 좋습니다.
medium 작업은 보통 다음 특징을 가집니다.
예를 들어 “로그인 폼 validation을 서버 에러와 통합하고 테스트를 추가해줘”는 medium에 적합합니다. 모델은 UI 코드, API 클라이언트, 테스트 파일을 봐야 하지만 시스템 전체를 재설계할 필요는 없습니다. 이 정도 작업에 high를 기본으로 쓰면 비용이 커지고 대기 시간이 늘어납니다.
복잡한 마이그레이션, 보안 민감 코드, 데이터 손실 가능성이 있는 작업은 별도 라우팅이 필요합니다. 예를 들어 인증 구조 변경, 결제 로직 수정, 멀티테넌트 권한 검사, 데이터베이스 마이그레이션, 대규모 의존성 업그레이드는 medium으로 바로 실행하기보다 계획 단계와 검토 단계를 나눠야 합니다.
이런 작업에서는 모델에게 바로 수정하게 하지 말고 먼저 설계안을 받습니다. 영향 범위, 위험, 테스트 계획, 롤백 방법을 작성하게 한 뒤 사람이 승인하거나 별도 에이전트가 리뷰합니다. Gemini 3.5 Flash가 긴 컨텍스트와 agentic task에 강하더라도, 운영 리스크가 큰 작업은 프로세스로 제어해야 합니다.
또한 1M 토큰 컨텍스트가 있다고 해서 저장소 전체를 매번 넣으면 안 됩니다. 긴 컨텍스트는 “필요할 때 버틸 수 있는 여유”이지 “무제한으로 넣어도 되는 공간”이 아닙니다. 관련 파일 후보를 검색하고, 요약하고, 필요한 부분만 넣는 구조가 여전히 중요합니다.
Gemini 3.5 Flash 문서는 multi-turn conversation에서 intermediate reasoning을 자동으로 유지하는 thought preservation을 언급합니다. API 변경 없이 적용된다는 설명은 대화형 코딩 에이전트에 중요합니다. 사용자가 “방금 방식 말고 다른 접근으로 해줘”라고 했을 때, 이전 탐색 맥락을 더 잘 유지할 수 있기 때문입니다.
하지만 운영자는 이를 블랙박스로만 믿으면 안 됩니다. 대화가 길어질수록 요구사항이 바뀌고, 이전 가정이 틀릴 수 있습니다. 따라서 긴 작업에서는 중간중간 “현재 결정”, “남은 작업”, “검증 결과”를 외부 상태로 요약해 저장하는 편이 안전합니다. 모델 내부 보존과 애플리케이션 레벨 작업 로그를 함께 쓰는 구조가 가장 안정적입니다.
예를 들어 코딩 에이전트 세션에는 다음 상태를 남깁니다.
이렇게 하면 세션이 끊기거나 모델을 바꿔도 작업을 회복할 수 있습니다.
출처: Google AI for Developers, Gemini 3.5 Flash 문서 및 Gemini API release notes의 2026년 5월 19일 GA 공지.
