Gemini API 사고모델 사용시 주의사항
Thought Signature 오류로 인한 400 Error 문제
최근에 Gemini 3, 3 pro 모델이 나왔다.
가격도 가격인데 성능이 정말 뛰어나더라...
기존에 만들었던 번역툴 모델을 gemini 3 pro preview로 바꿨더니 성능이 2배 이상 좋아졌다.
인간시대의 끝이 온것인가...
조금 비싼것만 빼면 최고의 일상용 멀티모달이 아닐까?
이걸 활용해서 이것저것 해보던 와중 API Document에 사고 서명(Thought Signature)이라는게 보여서 쭉 한번 읽어보았다. 기존에 만들던 프로젝트들이 chating UI 기반이 아닌 structured output 기능을 활용한 업무 도구였기 때문에 한번도 겪지 못했지만 만약 그렇지 않았다면 이번 모델 사용 시 어마어마한 오류가 발생하지 않았을까?
기존에 내가 LLM을 쓰던 방식이다.
이제 나오는 2.5 flash/pro, 3 flash/pro 모델들에서는 모델이 복잡한 문제(수학/코딩, Tool Calling, Agent Workflow)를 풀때 '내부 메모'같은게 생성된다. 기본적으로 Gemini API는 Stateless(상태 비저장 이라고하는데 그냥 매번 api로 콜을 던질때 fresh 한 뇌로 맞이한다고 생각하면 된다)이기 때문에 이전 대화나 추론 과정을 기억하지 못한다. 그래서 위 사진처럼 나는 이전 질문, 대답을 컨텐츠에 같이 녹여 넣어서 맥락을 주입하곤 했던 것이다.
이 녀석 들이 나오면서 이전에 내가 쓰던 방식에 구멍이 생겼다.
아래 사진은 Gemini 2.5 시리즈, 3 시리즈 들의 소통 파이프라인이다.
중간에 Signature라는 친구가 메모리에 저장되게 되는데 단순히 나처럼 query, response text만 다시 query로 쏘는 케이스는 해당 Signature를 놓치게 된다. 아래 사진은 Signature를 놓치는 케이스.
옳게된 사용 방법 예시
https://gist.github.com/kimi230/420041c9ca504c16ed7b073c321a32eb
나처럼 텍스트만 추출하여 쓰던 사람들은 아래와 같은 방식으로 변화를 따라가도록 하자.
chat_session 을 쓰는것도 좋은 방식
https://gist.github.com/kimi230/8ffab8ba20cc40707c00b25c4448659d
이제부터는 response.text 만 챙기는 습관을 버리고, response.candidates[0].content 객체 전체를 대화 기록에 append 하는 습관을 들여보자.
참고 자료
- [Google AI - Thinking Guide] (https://ai.google.dev/gemini-api/docs/thinking)
- [Google AI - Thought Signatures] (https://ai.google.dev/gemini-api/docs/thought-signatures)
- [Google AI - Function Calling] (https://ai.google.dev/gemini-api/docs/function-calling)
