구글이 2026년 7월 21일에 Gemini Flash 계열 세 모델을 한꺼번에 내놨어요. 3.6 Flash, 3.5 Flash-Lite, 그리고 보안 특화 모델인 3.5 Flash Cyber. 대부분의 소식은 "값이 내렸다", "토큰을 덜 쓴다"는 벤치마크 요약으로 끝나는데, 정작 Dify로 워크플로를 돌리는 사람에게 진짜 중요한 건 그 표에 안 적혀 있어요. 모델 이름만 바꿔 끼웠다가 조용히 발등을 찍을 수 있는 변경점들이 이번 업데이트에 숨어 있거든요.
그래서 이 글은 "3.6 Flash가 얼마나 좋아졌나"를 소개하는 데 시간을 쓰지 않아요. 좋아진 건 이미 다들 알아요. 대신 Dify에서 이 모델로 갈아탈 때 실제로 깨지는 것, 그리고 그 변화가 왜 오히려 Dify 사용자에게 유리하게 작용하는지를 짚어볼게요.
먼저 결론부터: 이번 업데이트의 핵심은 "말이 짧아진 것"
성능 지표를 하나하나 나열하는 대신 딱 한 문장으로 요약하면, 3.6 Flash의 진짜 개선점은 똑똑해진 게 아니라 말수가 줄었다는 거예요. 구글은 Artificial Analysis Index 기준으로 같은 작업에 출력 토큰을 3.5 Flash보다 17% 적게 쓴다고 밝혔고, Datacurve의 DeepSWE 같은 벤치마크에서는 최대 65%까지 줄었어요.
이게 왜 벤치마크 점수보다 중요하냐면, 에이전트는 추론하고 도구를 부르고 그 결과를 다시 읽어 다음 행동을 정하는 걸 수십 번 반복하는 구조라, 모델이 매 단계 말을 길게 하면 그 장황함이 곧바로 비용으로 쌓여요. 3.5 Flash는 성능은 괜찮았지만 답을 부풀리는 버릇이 있었고, 3.6은 바로 그 버릇을 고친 모델이에요.
구글 발표 기준 출력 단가가 100만 토큰당 9달러에서 7.50달러로 내려왔는데(입력은 1.50달러 그대로), 하루 1000만 토큰을 쓰는 서비스라면 단가 인하만으로 일 90달러에서 75달러로, 월 450달러가 빠져요. 월 1억 토큰 규모의 에이전트라면 월 4500달러가 절약되고요. 여기에 토큰을 17% 덜 쓰는 효과, 그리고 첫 시도에 작업을 끝내는 비율이 높아져 재시도로 낭비되는 토큰까지 줄어드는 걸 곱하면, 실제 절감폭은 단가 인하만 봤을 때보다 더 커져요. 모델 문자열 한 줄 바꿔서 얻는 절감이라, 품의서에 그대로 옮겨 적을 수 있는 숫자예요.
Temperature가 조용히 무시?
여기서부터가 이 글을 쓴 이유예요. 3.6 Flash에는 벤치마크 표에 안 나오는 파괴적 변경점이 있는데, 이걸 모르고 넘어가면 로그만 봐서는 절대 못 잡는 버그를 심게 돼요.
구글 API 문서에 따르면 3.6 Flash, 3.5 Flash-Lite, 3.5 Flash Cyber부터 temperature, top_p, top_k 세 개의 샘플링 파라미터가 폐기됐어요. 그런데 문제는 폐기 방식이에요. 지금 당장은 이 값을 넣어도 에러가 안 나요. 400도, 경고도 없이 그냥 조용히 무시돼요. 요청은 200 OK를 받고, 응답도 멀쩡하게 돌아와요. 겉으로는 아무 문제가 없어 보이죠.
이게 왜 위험한지는 temperature=0을 생각해볼게요. 분류, 추출, 라우팅처럼 매번 같은 입력에 같은 출력이 나와야 하는 노드에서, 많은 사람이 temperature를 0으로 박아 재현성을 확보해요. 그런데 3.6 Flash에서는 이 0이 무시돼요. 요청은 여전히 200 OK를 받는데, 우리가 믿고 있던 결정성 보장은 사라진 상태인 거죠. 파이프라인은 멀쩡히 도는데 어느 날부터 같은 입력에 다른 결과가 나오기 시작하고, 에러 로그는 깨끗하니 원인을 찾는 데 며칠을 태우게 돼요. 여기서 특히 고약한 건 회귀 테스트예요. temperature=0으로 고정해두고 모델 출력을 저장된 기댓값과 비교하던 스냅샷 테스트가 모델 교체 후 흔들리기 시작하는데, 그게 설정 문제가 아니라 모델 성능이 나빠진 것처럼 보여서 엉뚱한 데서 원인을 찾게 되거든요.
Dify 를 사용하는 우리에게도 신경쓰이는 부분이예요. Dify의 LLM 노드는 노드마다 Temperature 슬라이더(0에서 1), Top P, Frequency Penalty, Presence Penalty를 그대로 노출하고, Precise·Balanced·Creative 프리셋까지 제공해요. 즉 3.6 Flash 노드에서도 Temperature 슬라이더는 여전히 움직이고, Precise 프리셋도 선택돼요. UI는 "내가 이 값을 조절하고 있다"고 말하는데, 모델은 그 값을 전혀 안 듣는 거예요. 슬라이더를 0으로 내려놓고 "이 노드는 결정론적"이라고 안심하던 사람이라면, 그 안심의 근거가 이번 모델부터 사라졌다는 걸 반드시 알아야 해요.
한 겹 더 있어요. OpenRouter 같은 게이트웨이를 경유해 모델을 붙이는 경우, 게이트웨이 쪽 모델 정보에는 여전히 temperature와 top_p가 지원 파라미터로 올라와 있고, 게이트웨이가 그 값을 받아 모델로 전달까지 해요. 그런데 정작 모델은 무시하죠. Dify에서 설정하고, 게이트웨이가 받아서 넘기니까 "당연히 적용됐겠지" 싶은데, 실제로는 이중으로 속는 구조예요. 값이 전달되는 것과 값이 적용되는 건 완전히 다른 얘기라는 걸, 이번만큼은 눈으로 확인하고 넘어가야 해요.
그럼 재현성은 어떻게 확보하나: 설계 철학이 바뀐 거예요
temperature가 사라진 걸 단순한 기능 삭제로 보면 곤란해요. 이건 "출력을 어떻게 통제할 것인가"의 무게중심이 파라미터에서 프롬프트로 옮겨갔다는 신호예요.
구글이 제시한 공식 대체안은 명확해요. temperature=0으로 잡던 결정성을, 이제는 시스템 인스트럭션과 구조화 출력(JSON 스키마), 그리고 검증 로직으로 확보하라는 거예요. 다시 말해 "모델아 랜덤성을 낮춰줘"라고 다이얼을 돌리는 방식에서, "출력 형식과 규칙을 프롬프트에 명시하고 스키마로 강제한다"는 방식으로 무게중심이 옮겨간 거죠. 파라미터를 없앤 뒤 출력이 이전만 못해졌다면, 대개는 시스템 인스트럭션을 더 구체적으로 다듬는 것으로 회복되고 오히려 나아지는 경우가 많아요.
이 변화는 Dify 사용자에게 은근히 유리해요. Dify는 원래 노드 안에서 프롬프트를 정교하게 짜고, 출력을 구조화(structured output)하고, 다음 노드에서 그 결과를 검증하는 흐름을 짜기 좋은 도구거든요. temperature 다이얼에 의존하던 통제를 프롬프트와 스키마로 옮기라는 요구는, Dify가 잘하는 방식으로 오라는 얘기와 같아요. 파라미터 튜닝으로 재현성을 맞추던 팀보다, 프롬프트와 워크플로 구조로 품질을 잡던 팀이 이번 전환에서 덜 흔들려요.
prefill로 출력을 유도하던 습관도 막혀요
파라미터만큼 자주 안 알려졌지만 실무에서 걸리는 변경점이 하나 더 있어요. 구글 문서에 따르면 3.6 Flash부터는 마지막 입력 턴이 모델(assistant) 역할로 끝나는 요청이 거부돼요. 400 에러가 나죠.
이게 뭐가 문제냐면, 그동안 출력을 특정 형식으로 강제하려고 assistant 턴을 미리 살짝 채워두는 기법을 많이들 썼어요. 응답 첫머리에 "Translation:"이나 JSON 여는 중괄호를 미리 넣어두고 모델이 그 뒤를 이어 쓰게 만드는 식이죠. 이 prefill 패턴이 3.6 Flash에서는 통째로 막혀요. Dify 워크플로에서 이런 식으로 출력을 유도하는 노드를 짜뒀다면, 모델만 바꿨을 때 그 노드가 400을 뱉으며 멈출 수 있어요. 앞서 말한 대체안과 같은 결론인데, 이제는 prefill이 아니라 시스템 인스트럭션과 스키마로 형식을 강제해야 해요.
Flash-Lite와 thinking_level: 같은 모델을 두 얼굴로 쓰는 법
3.5 Flash-Lite는 성격이 달라요. 똑똑함이 아니라 처리량이 목적이라, Artificial Analysis 측정 기준 초당 350토큰으로 3.5 계열 중 가장 빠르고, 가격은 입력 0.3달러, 출력 2.5달러(100만 토큰당)예요. 흥미로운 건 이 저가 모델이 몇몇 에이전트·코딩 평가에서 이전 상위 모델이던 3 Flash를 넘어선다는 점인데, 예전에 3 Flash를 쓰던 자리를 더 싸게 대체할 여지가 생긴 거죠.
여기서 실무적으로 놓치기 쉬운 지점이 thinking_level이에요. 3.x 세대부터 숫자로 주던 thinking_budget이 minimal·medium·high 같은 문자열 enum으로 바뀌었는데, 3.6 Flash는 기본이 medium, Flash-Lite는 기본이 minimal이에요. 단순 추출·분류·라우팅처럼 양으로 밀어붙이는 노드는 minimal로 두어 지연과 비용을 최대한 눌러야 하고, 반대로 Flash-Lite를 하위 에이전트로 쓸 거라면 조심해야 해요.
구글 문서가 직접 경고하듯, Flash-Lite의 기본값 minimal은 자율 에이전트 용도에는 부적합해서 다단계 작업 중간에 도구 호출을 멈춰버리거든요. 에이전트가 코드를 쓰거나 외부 API를 호출하는 노드라면 thinking_level을 medium이나 high로 의도적으로 올려줘야 해요. 같은 모델을 상황에 따라 다른 얼굴로 굴리는 이 조절이, Flash-Lite를 제대로 쓰는 핵심이에요.
한 가지 냉정하게 볼 점도 있어요. 가장 싼 선택지의 값이 세대를 거치며 계속 올라왔거든요. 2.5 Flash-Lite가 입출력 $0.1/$0.4였는데 3.1 Flash-Lite가 $0.25/$1.5, 이번 3.5 Flash-Lite가 $0.3/$2.5예요. 대량 저비용 처리가 목적이라면, Flash-Lite를 당연하게 고르기 전에 내 트래픽 규모에서 다른 저가 모델과 실제 비용을 견줘보는 게 맞아요.
3.5 Flash Cyber는 지금 신경 쓸 필요 없어요
세 번째 모델인 3.5 Flash Cyber는 보안 취약점을 찾고 검증하고 패치하는 데 특화된 모델로, 구글의 코드 보안 에이전트 CodeMender를 여러 개 병렬로 돌려 통합 보고서를 만드는 구조예요. 다만 이중용도 위험 때문에 정부와 신뢰할 수 있는 파트너에게만 제한 접근으로 풀렸고 일반 API로는 안 열려 있어요. Dify에 지금 얹을 수 있는 대상이 아니니, "이런 방향이 나오고 있다" 정도만 알아두면 돼요.
왜 정작 Pro는 같이 안 나왔나
많은 사람이 기다린 Gemini 3.5 Pro는 이번에 빠졌어요. 구글은 파트너와 테스트 중이며 준비되는 대로 풀겠다고만 했고, 동시에 Gemini 4를 위한 가장 야심 찬 사전학습에 들어갔다고 덧붙였어요. Pro가 왜 빠졌는지를 두고 일부 매체는 구글이 확보하지 못한 연산 용량을 과대판매하고 있다는 지적을 전했는데, Pro를 안정적으로 서비스할 여력이 모자라 확장 사고를 켠 Flash가 그 자리를 대신 메우는 경우가 잦다는 관찰이에요.
실무적으로 끌어낼 결론은 하나예요. 최상위 추론이 급한 워크로드라면 Pro가 열릴 때까지 기다리지 말고, Flash의 thinking_level을 high로 끌어올려 버티거나 다른 제공사의 상위 모델을 병행하는 게 현실적이에요. 그리고 이 "여러 제공사를 한 워크플로에 섞는다"는 게 Dify에서는 노드 설정만 바꾸면 되는 일이라, Pro 공백기를 버티는 데 오히려 Dify가 유리해요.
2.5 폐기 후 3.5가 아닌 3.1로 가라고?
마이그레이션이 급하지 않다고 미뤄도 되는 건 어느 시점까지예요. 구글 폐기 일정에 따르면 gemini-2.5-flash와 2.5-flash-lite는 2026년 10월 16일에 종료돼요. 지금 이 두 모델 위에 워크플로를 올려둔 팀이라면 대략 석 달 안에 옮겨야 하는 셈이죠. 그런데 "석 달이나 남았네" 하고 느긋해지면 곤란해요. 문서상 종료일이 10월인데도, 개발자 포럼에는 그 전부터 2.5 계열 호출이 간헐적으로 404를 뱉기 시작했다는 신고가 올라와 있거든요. 폐기 예정 모델은 종료일 전에 서빙 용량이 줄면서 먼저 불안정해질 수 있으니, 날짜만 믿고 마지막까지 끌지 않는 게 안전해요.
여기서 문서를 대충 보면 놓치는 함정이 있어요. 구글이 2.5-flash-lite의 공식 후속으로 지정한 건 이번에 나온 3.5-flash-lite가 아니라 3.1-flash-lite예요. 최신이라고 3.5로 바로 점프하고 싶겠지만, 그건 문서가 안내하는 한 세대 업그레이드가 아니라 두 세대를 건너뛰는 결정이라 별도로 검증해야 해요. 최신 모델로 가는 게 나쁜 선택은 아니지만, "당연한 후속"으로 착각하고 넘어가면 안 되는 지점이에요.
한 가지 더, Computer Use(에이전트가 화면을 직접 조작하는 기능)를 쓸 계획이라면 지금은 지원 여부를 문서만으로 확정하기 어려워요. 구글 자체 문서들 사이에서도 3.6 Flash와 Flash-Lite의 Computer Use 지원 표기가 서로 엇갈리거든요. 이 기능이 워크플로의 핵심 경로에 있다면, 문서를 믿지 말고 자기 계정과 엔드포인트에서 직접 찔러본 뒤에 결정하는 게 안전해요.
액션 플랜은 뭘까요?
정리하면 이번 업데이트에서 Dify 사용자가 챙길 건 벤치마크 숫자가 아니라 세 가지 행동이에요.
첫째, 3.6 Flash 노드에서 Temperature 슬라이더와 Precise 프리셋을 여전히 믿고 있었다면, 그 통제가 이제 안 먹힌다는 걸 전제로 재현성이 중요한 노드를 점검하세요.
둘째, 그 재현성을 시스템 인스트럭션과 구조화 출력, 검증 노드로 옮겨 다시 설계하세요.
셋째, prefill로 출력을 유도하던 노드가 있다면 400 에러가 나기 전에 프롬프트 방식으로 바꿔두세요.
한 가지 실무 팁을 더하면, Dify의 Gemini 연동은 플러그인이 구글 API에서 모델 목록을 동적으로 가져오는 방식이라 새 모델 ID가 UI에 곧바로 안 뜰 수 있어요. 실제로 Dify 커뮤니티에는 구글이 모델 ID를 바꾸면서 호출이 깨진 사례가 보고돼 있고요. 새 모델이 안 보이면 Gemini 플러그인을 최신으로 올리고, 자기 API 키가 접근 가능한 모델 목록을 직접 확인해보면 대부분 해결돼요. 결국 이번 Flash 업데이트의 실속은 값이 싸진 데 있는 게 아니라, 출력 통제 방식이 파라미터에서 프롬프트로 넘어갔다는 데 있고, 그 전환을 가장 부드럽게 받아낼 수 있는 게 프롬프트와 워크플로 구조로 품질을 잡는 Dify라는 점이에요.
오픈네트웍시스템 ㅣ 권태규