기술 신호2026-06-22

한 달에 프런티어 모델 4개

Gemini 3.5 Pro가 6월에 일반출시, 모델 교체 주기가 분기에서 주로

6월 한 달에만 GPT-5.5, Gemini 3.5 Pro, Grok 5, Microsoft 7종이 쏟아졌다. 모델 층의 우위가 분기가 아니라 주 단위로 줄었고, 제품을 한 모델에 박아두면 더 싸고 강한 모델로 못 갈아탄다.

6월이 끝나기도 전에 프런티어 모델이 네 개 나왔다. OpenAI는 GPT-5.5(Pro와 Instant 변형 포함)를, 구글은 Gemini 3.5 Pro를 6월 일반출시 목표로 내놓았다. xAI의 Grok 5가 베타로 풀렸고, Microsoft는 자체 모델 일곱 종을 한꺼번에 공개했다. 한 시장 집계는 6월을 "역대 가장 큰 모델 출시의 달"로 불렀다.

숫자가 말하는 건 단순하다. 모델 한 개를 골라 제품의 중심에 세우면, 한 달 뒤 더 싸거나 더 강한 모델이 그 자리를 노린다.

한눈에 보기

6월 신규 프런티어 GPT-5.5, Gemini 3.5 Pro, Grok 5, Microsoft MAI 7종
Gemini 3.5 Pro 컨텍스트 2M 토큰, Deep Think 추론
GPT-5.5 가격 입력 $5 / 출력 $30 (1M 토큰), 캐시 입력 $0.50
Gemini 3.1 Pro 가격 입력 $2 / 출력 $12 (200K까지, 초과 시 두 배)
교체 주기 프런티어 4개 / 30일

가격이 한 달 만에 다시 떨어진다

같은 일을 시켜도 모델마다 청구서가 다르다. GPT-5.5는 출력 100만 토큰에 $30, 같은 작업을 Gemini 3.1 Pro로 돌리면 $12다. 분류나 요약처럼 단순한 일에 프런티어 출력 토큰을 쓰면 자릿수 큰 청구서가 온다. 캐시 입력을 쓰면 GPT-5.5 입력이 $5에서 $0.50으로, Gemini 쪽은 1M당 $0.15 수준까지 내려간다.

숫자를 현실에 대 보자. 하루에 출력 토큰을 1,000만 개 쓰는 제품이라면, GPT-5.5로는 출력만 하루 $300, 한 달이면 약 $9,000이다. 같은 작업을 Gemini 3.1 Pro로 돌리면 하루 $120, 한 달 약 $3,600이다. 코드를 바꾸지 않고 호출 대상만 바꿔도 월 5,000달러 넘게 갈린다. 1인 SaaS 개발자에게 이 차이는 가격표를 다시 짜야 할 수준이다.

문제는 이 가격표가 고정이 아니라는 점이다. 6월에만 네 번 흔들렸다. 오늘 최적인 조합이 다음 달엔 두 번째로 밀린다. 작업마다 다른 모델이 정답이 되기도 한다. 어려운 추론은 프런티어로, 분류와 태깅은 더 싼 모델로 나누면 같은 품질에 비용만 깎인다.

컨텍스트 창이 제품 설계를 바꾼다

Gemini 3.5 Pro는 2M 토큰 컨텍스트를 노린다. 코드베이스 전체나 긴 문서 묶음을 한 번에 넣고 추론을 시킬 수 있다는 뜻이다. 1년 전만 해도 128K가 표준이었다. 컨텍스트가 커지면 RAG 파이프라인을 단순화할 수 있고, 거꾸로 길어진 입력의 토큰 비용을 다시 계산해야 한다.

여기서 갈린다. 컨텍스트 한도, 추론 깊이, 가격이 모델마다 다르게 움직이니, "어떤 모델이 제일 좋냐"는 질문은 "이 작업에 어떤 모델이 맞냐"로 쪼개진다.

우위가 주 단위로 줄었다

분기마다 한 번씩 새 모델을 보던 시절은 지났다. 30일에 프런티어 네 개면, 모델 그 자체로 쌓는 해자는 몇 주짜리다. 인디 메이커나 AI 우선 팀이 특정 모델의 출력 형식, 함수 호출 방식, 프롬프트 버릇에 코드를 깊게 맞춰두면, 더 나은 모델이 나와도 옮기는 비용이 커서 못 옮긴다.

여기서 흔한 오해가 하나 있다. 새 모델이 자주 나오니 매번 따라가야 한다는 압박이다. 사실은 반대다. 모델이 자주 바뀔수록, 따라가기 쉬운 구조를 만들어 두는 쪽이 이긴다. 매번 손으로 마이그레이션하는 팀은 출시 주기에 끌려다니고, 호출을 추상화해 둔 팀은 새 모델을 평가셋에 한 번 돌려 보고 더 나으면 갈아끼운다. 출시 빈도가 높아질수록 이 차이는 누적된다.

무엇을 고정하고 무엇을 바꿀 것인가

바뀌는 것과 바뀌지 않는 것을 갈라야 한다. 모델 이름, 가격, 컨텍스트 한도는 한 달이면 바뀐다. 반면 내가 푸는 문제의 정의, 좋은 출력의 기준, 실패 사례 모음은 잘 바뀌지 않는다. 후자를 코드와 평가셋으로 단단히 잡아 두면, 전자는 설정값으로 흘려보낼 수 있다. 모델을 고르는 일이 아니라 작업을 정의하는 일에 시간을 쓰는 게 핵심이다.

anyAX 관점

모델을 제품의 심장에 직접 박지 말고, 갈아끼우는 부품처럼 다뤄야 한다. 호출부를 라우터 한 겹으로 감싸 두면, 출력 100만 토큰 $30짜리를 같은 품질의 $12짜리로 바꾸는 일이 설정값 하나가 된다. 6월에 가격표가 네 번 흔들렸다는 건, 이 추상화가 한 달에 한 번씩 돈을 아껴준다는 뜻이다.

반대로 한 모델의 프롬프트 버릇과 파싱 규칙에 제품을 맞춰 깊게 박아두면, 2M 컨텍스트 같은 새 능력이 나와도 그 위에서 설계를 다시 못 짠다. 써보는 것과 워크플로에 박는 것은 다르다. 1인 SaaS 개발자에게 진짜 자산은 어느 모델을 쓰느냐가 아니라, 모델이 바뀌어도 그대로 굴러가는 평가셋과 프롬프트 회귀 테스트다. 모델은 한 달이면 바뀌고, 내가 가진 작업 정의와 검증 장치는 남는다.

참고