지난주 화요일, 구글은 새 모델을 하나 내놓지 않았다. 세 개를 한꺼번에 내놨다.
Gemini 3.6 Flash, Gemini 3.5 Flash-Lite, 그리고 Gemini 3.5 Flash Cyber. 이름만 보면 버전 숫자가 조금씩 다른 형제 같지만, 실제로는 서로 다른 일을 하라고 만든 세 모델이다. 하나는 개발자가 매일 쓰는 범용 일꾼, 하나는 값싸게 대량으로 돌리는 경량 모델, 나머지 하나는 정부와 일부 파트너만 손댈 수 있는 보안 전용 모델이다.
그동안 새 모델 발표는 대부분 같은 문법을 따랐다. "우리 모델이 이번 벤치마크에서 1등을 찍었다"는 것. 그런데 이번 발표에는 그런 1등 자랑이 주인공이 아니었다. 대신 "어떤 일에는 이 모델, 다른 일에는 저 모델을 쓰라"는 메시지가 깔려 있었다. 성능 순위표 맨 위 한 칸을 두고 다투던 흐름이, 용도별로 라인업을 쪼개는 쪽으로 방향을 튼 셈이다. 왜 하필 지금, 왜 하필 구글이 이렇게 나눴는지가 이 발표의 진짜 이야기다.
같은 Flash인데 하는 일이 다르다
세 모델의 성격부터 갈라놓고 보자.
Gemini 3.6 Flash는 이 라인업의 주력이다. 코딩, 문서 작업, 이미지와 PDF 같은 자료 분석, 그리고 여러 단계를 스스로 밟아가는 에이전트 작업까지 두루 맡는다. 성능은 웬만큼 높이되 값은 낮게 잡은, 하루 종일 돌려도 부담이 덜한 모델이라고 보면 된다. 구글이 이 모델에서 특히 공들인 부분은 "덜 헤매게 만드는 것"이었다. 에이전트가 일을 처리할 때 도구를 몇 번 호출하고 중간 단계를 몇 번 거치는지를 줄여서, 같은 작업을 더 적은 왕복으로 끝내도록 손봤다.
Gemini 3.5 Flash-Lite는 셋 중 가장 빠르고 가장 싸다. 겨냥하는 일은 분명하다. 양은 어마어마하게 많은데 한 건 한 건은 그리 어렵지 않은 작업이다. 쌓인 이메일을 종류별로 분류하고, 검색 질의를 쳐내고, 콜센터 로그를 훑고, 문서 수만 건에 라벨을 붙이는 일 말이다. 구글은 이 모델을 자사 검색에도 차례로 얹을 계획이라고 밝혔다. 검색처럼 요청이 폭포수로 쏟아지는 서비스에서는 한 번의 응답을 0.1초라도 당기고 한 건당 비용을 몇 원이라도 깎는 것이 곧 서비스의 승패로 이어진다.
Gemini 3.5 Flash Cyber는 결이 완전히 다르다. 소프트웨어의 보안 취약점을 찾아내고, 그게 진짜 문제인지 확인하고, 고칠 패치를 만드는 일에 맞춰 따로 조율한 모델이다. 코드를 자동으로 수정하는 CodeMender라는 에이전트를 통해 동작한다. 그런데 이 모델은 아무나 API 키를 발급받아 쓸 수 없다. 정부 기관과 구글이 신뢰하는 일부 파트너에게만 제한적으로 여는 방식이다. 왜 하필 보안 모델만 문을 걸어 잠갔는지는 뒤에서 따로 짚겠다.
가격표가 전략을 그대로 보여준다
말로 "용도별로 나눴다"고 하면 뜬구름 같지만, 가격을 나란히 놓으면 의도가 또렷해진다.
Gemini 3.6 Flash는 입력 100만 토큰에 1.50달러, 출력 100만 토큰에 7.50달러다. 눈여겨볼 대목은 출력 단가다. 직전 세대인 3.5 Flash의 출력이 100만 토큰에 9달러였는데, 새 버전은 성능을 올리고도 값을 7.50달러로 내렸다. 보통 새 모델은 더 좋아진 만큼 더 비싸지기 마련인데, 여기서는 반대로 갔다.
Flash-Lite로 내려오면 격차가 확 벌어진다. 입력 100만 토큰에 0.30달러, 출력에 2.50달러. 주력 모델과 비교하면 입력은 5분의 1, 출력은 3분의 1 수준이다. 속도도 초당 350토큰 안팎으로 평가받아, 3.5 계열에서 가장 빠른 축에 든다. 대량 처리용 모델에 어울리는 값과 속도다.
보안용 Flash Cyber의 토큰 단가는 아직 공개되지 않았다. 구글은 "큰 규모의 코드 보안 문제를 낮은 단가로 처리할 수 있게 했다"고만 말했을 뿐, 정확한 숫자는 내놓지 않았다. 애초에 일반 판매용이 아니라 특정 대상에게만 여는 모델이니, 공개 가격표가 없는 것이 이상한 일도 아니다.
이 세 줄의 가격표가 곧 전략이다. 값비싼 최상급 모델 하나로 모든 일을 시키게 두는 대신, 일의 성격에 따라 값과 성능을 다르게 매긴 문을 여러 개 열어둔 것이다.
왜 하나로 안 하고 굳이 셋인가
여기서 자연스러운 의문이 생긴다. 좋은 모델 하나 잘 만들어서 다 시키면 될 텐데, 왜 굳이 셋으로 쪼갰을까.
답은 "일마다 필요한 게 다르기 때문"이다. 이메일 수만 건을 스팸인지 아닌지 나누는 일에 최상급 추론 모델을 붙이는 건, 택배 상자 몇 개 나르자고 대형 트럭을 부르는 것과 비슷하다. 트럭이 못 해서가 아니라, 그 힘이 그 일에 필요 없어서 낭비다. 반대로 복잡한 코드베이스를 리팩터링하는 일에 초경량 모델을 붙이면 값은 아끼겠지만 결과물을 믿기 어렵다. 결국 모든 일을 만족시키는 단 하나의 모델이란 존재하기 어렵고, 있다 해도 대부분의 일에는 과분하다.
가격 차이가 실제로 얼마나 벌어지는지는 셈을 해보면 확 와닿는다. 출력 단가만 놓고 보면 Flash-Lite는 100만 토큰에 2.50달러, 3.6 Flash는 7.50달러다. 가령 한 서비스가 하루에 출력 1억 토큰을 쏟아낸다면, 같은 양을 3.6 Flash로 처리할 때와 Flash-Lite로 처리할 때 하루치 출력 비용은 750달러와 250달러로 갈린다. 입력까지 더하면 격차는 더 커진다. 이 세 배 차이가 한 달, 일 년 쌓이면 무시할 수 없는 액수가 된다. 문제는 로그 분류 같은 단순 작업에서는 두 모델의 결과물 차이가 그 비용 차이만큼 벌어지지 않는다는 점이다. 값을 세 배 더 내고도 체감 이득이 없다면, 그건 그냥 새는 돈이다.
벤치마크 숫자를 보면 이 판단에 근거가 있다. 소프트웨어 엔지니어링 능력을 재는 DeepSWE에서 3.5 Flash는 37점이었는데 3.6 Flash는 49점으로 올랐다. 머신러닝 관련 작업을 다루는 MLE Bench에서는 49.7점에서 63.9점으로 뛰었다. Flash급의 작고 값싼 모델이 코딩과 연구 보조에서 이만큼 올라왔다는 건, 예전 같으면 최상급 모델을 불러야 했던 일도 이제 중급 모델로 감당된다는 뜻이다. 그러니 굳이 비싼 모델을 기본값으로 둘 이유가 줄어든다.
에이전트가 늘어난 것도 이 분화를 밀어붙였다. 사람이 챗봇에 질문을 한 번 던지고 답을 받던 시절에는 모델을 몇 번 부르든 티가 안 났다. 그런데 에이전트는 한 가지 일을 끝내려고 모델을 열 번, 스무 번씩 부른다. 이렇게 호출이 쌓이는 구조에서는 한 번당 값과 속도가 전체 비용과 체감 속도를 좌우한다. 구글이 3.6 Flash에서 "도구 호출과 중간 단계 수를 줄였다"고 강조한 것도 이 맥락이다. 왕복 한 번을 줄이면 그만큼 값도 시간도 아낀다. 벤치마크 1등이라는 상징보다, 에이전트를 굴렸을 때 총비용이 얼마 나오느냐가 더 현실적인 승부처가 된 것이다.
보안 모델만 문을 잠근 이유
세 모델 가운데 유독 Flash Cyber만 아무나 못 쓴다는 점은 그냥 넘길 대목이 아니다.
취약점을 찾아 고치는 능력은 방향만 바꾸면 취약점을 찾아 파고드는 능력이 된다. 같은 칼로 요리도 하고 다치게도 하는 것과 같다. 코드에서 약한 고리를 자동으로 짚어내는 모델이 있다면, 방어하는 쪽에는 더없이 든든하지만 공격하는 쪽에도 똑같이 쓸모가 있다. 그래서 구글은 이 모델을 공개 API로 풀지 않고 정부 기관과 신뢰하는 파트너에게만 열었다. 성능이 모자라서가 아니라, 아무 손에나 쥐여줄 물건이 아니라는 판단이다.
이 선택은 최근 몇 달간 반복된 장면과도 겹친다. 능력이 세질수록 그 능력을 누구에게 열어줄지가 별도의 문제로 떠올랐고, 회사마다 접근을 조이거나 늦추는 방식으로 답해 왔다. Flash Cyber의 제한적 공개는 그 흐름이 보안 특화 모델에서 특히 또렷하게 드러난 사례다. 성능을 자랑하는 발표이면서 동시에 "그래서 함부로 풀지는 않겠다"는 신호를 같이 낸 셈이다.
이 대목은 나머지 두 모델과 비교하면 더 흥미롭다. 3.6 Flash와 Flash-Lite는 값을 낮추고 문턱을 없애 되도록 많은 사람이 쓰게 만드는 방향으로 갔다. 반면 Flash Cyber는 같은 회사가 정반대로 문을 좁혔다. 한 라인업 안에서 "널리 퍼뜨릴 능력"과 "가려서 내줄 능력"을 나눠 다룬 것이다. 모델을 용도별로 쪼갠다는 말에는 성능과 가격을 나눈다는 뜻만 있는 게 아니라, 누구에게 얼마나 열지까지 나눈다는 뜻이 함께 담겨 있는 셈이다.
한국의 실무자에게 무엇이 달라지나
이번 발표에서 실무자가 챙길 것은 "새 모델이 얼마나 세졌나"가 아니라 "모델을 어떻게 배치할 것인가"다.
그동안 많은 조직이 모델 하나를 정해 모든 기능에 같은 것을 붙이는 방식으로 서비스를 짰다. 관리가 단순하니 자연스러운 선택이었다. 그런데 구글이 이렇게 대놓고 라인업을 갈라놓으면, 하나로 통일하던 습관이 오히려 비용을 흘리는 구멍이 된다. 문서 분류나 로그 요약처럼 단순 반복이 많은 기능에는 Flash-Lite급을, 코드 생성이나 자료 분석처럼 판단이 필요한 기능에는 3.6 Flash급을 붙이는 식으로 일을 나눠 맡기는 설계가 이제 기본기가 된다. 같은 서비스라도 어느 기능에 어떤 모델을 붙였느냐에 따라 한 달 청구서가 몇 배씩 갈릴 수 있다.
교육이나 기획을 하는 입장에서도 설명의 결이 바뀐다. "제일 똑똑한 모델이 뭐냐"는 질문은 이제 반쪽짜리다. 더 쓸모 있는 질문은 "이 업무에는 어느 급의 모델이면 충분한가"이다. 모델 선택이 성능 순위 외우기에서 업무와 예산에 맞춰 저울질하는 일로 옮겨간다. 이번 Gemini Flash 발표는 그 저울질을 구글이 세 칸짜리 눈금으로 친절하게 그어준 사건에 가깝다.
물론 이건 구글만의 방향은 아닐 것이다. 값싸고 빠른 모델이 코딩과 문서 작업에서 이만큼 올라온 이상, 다른 회사들도 "하나의 최상급 모델"을 파는 문법에서 "용도별 라인업"을 파는 문법으로 옮겨갈 유인이 커졌다. 그때 실무자에게 남는 숙제는 늘 같다. 눈앞의 일에 딱 맞는 눈금이 어디인지 고르는 일이다.