처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.07.22 33

제미나이 최신 모델이 temperature를 무시하기 시작했어요 — 샘플링 튜닝 시대의 끝

Hacker News 원문 보기
제미나이 최신 모델이 temperature를 무시하기 시작했어요 — 샘플링 튜닝 시대의 끝

제미나이(Gemini) API 문서에 조용히, 그런데 꽤 중요한 변경 사항이 올라왔어요. 최신 모델부터 temperature, top_p, top_k 파라미터가 deprecated, 그러니까 더 이상 지원하지 않는 기능으로 지정됐다는 내용인데요. 더 놀라운 건 처리 방식이에요. 이 값을 보내면 에러가 나는 게 아니라, API가 하위 호환을 위해 받아주기는 하는데 그냥 무시해버리거든요. 기존 코드가 멀쩡히 돌아가는 것처럼 보이지만 실제로는 아무 효과가 없는 상태가 되는 거예요.

이 파라미터들이 뭐였냐면요

LLM은 다음에 올 토큰(단어 조각)을 확률 분포로 예측하고, 그중 하나를 뽑는 방식으로 글을 생성해요. temperature는 이 뽑기의 과감함을 조절하는 값이에요. 낮추면 확률 높은 토큰만 골라서 답이 일관되고 예측 가능해지고, 높이면 확률 낮은 토큰도 뽑혀서 다양하고 창의적인 답이 나와요. top_p는 누적 확률 상위 몇 퍼센트 안의 토큰만 후보로 쓰겠다는 제한이고, top_k는 확률 상위 k개만 후보로 남기겠다는 제한이고요. 지금까지는 '분류 작업은 temperature 0, 창작은 0.9' 같은 튜닝이 LLM 개발자의 기본 소양처럼 여겨졌죠.

왜 없애는 걸까요

구글의 설명은 이래요. 최신 모델들은 포스트 트레이닝(사후 학습) 과정에서 함께 튜닝된 내부 동적 샘플링 전략을 쓰는데, 개발자가 샘플링 값을 수동으로 건드리면 오히려 추론 품질이 떨어지고, 같은 말을 반복하는 루핑 현상이 생기고, 지시를 제대로 따르지 않는 문제가 발생했다는 거예요. 모델이 '지금은 신중하게 뽑을 때, 지금은 다양하게 뽑을 때'를 스스로 판단하도록 학습됐는데, 바깥에서 고정값으로 덮어쓰면 그 균형이 깨진다는 거죠.

대안도 제시했어요. 결정적인 출력이 필요해서 temperature를 0으로 내리던 경우라면, 이제 구조화된 출력(structured outputs), 그러니까 JSON 스키마를 지정해서 응답 형식 자체를 강제하는 responseSchema 기능을 쓰라고 해요. 반대로 창의적인 결과를 위해 temperature를 올리던 경우라면 프롬프트에 직접 '다양한 관점으로, 과감하게' 같은 지시를 넣으라는 거고요. 그리고 출력의 성격은 thinking_level 파라미터, 그러니까 모델이 답하기 전에 굴리는 추론의 깊이를 minimal부터 high까지 조절하는 값으로 통제하는 방향이에요.

사실 업계 전체의 흐름이에요

이게 구글만의 독특한 결정은 아니에요. OpenAI도 o1 계열부터 추론 모델에서는 temperature 설정을 아예 막았거든요. 추론 모델은 답을 내기 전에 내부적으로 생각의 사슬을 굴리는데, 이 과정의 샘플링을 사용자가 흔들면 추론 자체가 망가지기 때문이에요. 그러니까 샘플링 파라미터의 퇴장은 모델이 단순 텍스트 생성기에서 추론 시스템으로 바뀌면서 생기는 구조적 변화라고 보는 게 맞아요. 개발자가 쥐는 제어의 지점이 '토큰을 어떻게 뽑을까'라는 저수준에서 '무엇을 어떤 형식으로 답하게 할까'라는 고수준으로 올라간 거죠.

실무에서 당장 확인할 것

제일 위험한 건 조용한 무시예요. LangChain 같은 추상화 레이어나 사내 공통 SDK에서 temperature를 기본값으로 넘기고 있다면, 에러가 안 나니까 아무도 눈치를 못 채요. 모델 버전만 올렸는데 출력의 성격이 달라져서 하위 파이프라인이 흔들리는 상황이 생길 수 있는 거죠. 제미나이를 쓰는 팀이라면 세 가지를 점검해보세요. 첫째, 코드에서 샘플링 파라미터에 의존하는 곳이 어디인지 찾고, 둘째, 결정성이 필요한 곳은 responseSchema 기반 구조화 출력으로 옮기고, 셋째, 출력 품질은 파라미터가 아니라 평가(eval) 데이터셋으로 관리하는 체계를 만드는 거예요. 재현성의 근거를 파라미터 값에서 스키마와 테스트로 옮기는 게 이번 변화의 실무적 결론이거든요.

정리하면, temperature를 만지작거리던 시대가 저물고 프롬프트와 스키마로 제어하는 시대가 왔다는 신호예요. 여러분 프로젝트에는 temperature에 의존하는 코드가 얼마나 남아 있나요? 이런 제어권 회수, 개발자 입장에서 편해진 걸까요 아니면 빼앗긴 걸까요?


🔗 출처: Hacker News

이 뉴스가 유용했나요?

이 기술을 직접 배워보세요

AI 도구, 직접 활용해보세요

AI 시대, 코딩으로 수익을 만드는 방법을 배울 수 있습니다.

AI 활용 강의 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.