Gemini 3.5 Flash는 특허 업무에 적합한가: 변리사의 실무 활용도 평가

최종 업데이트 날짜: 2026-05-25

 

[핵심 요약]

2026년 5월 19일, Google I/O에서 Gemini 3.5 Flash가 발표되었습니다.

 

기존 Gemini 3.1 Pro를 코딩·에이전틱 벤치마크에서 앞지르고, 경쟁 프론티어 모델 대비 빠른 출력 속도를 자랑하는 인상적인 수치였습니다.  발표 당일부터 Gemini 앱과 Google AI Mode의 기본 모델로 전환될 만큼, 구글이 공을 들인 모델임은 분명합니다.

 

그러나 특허 실무자에게 중요한 것은 벤치마크 수치가 아니라 이 모델을 만든 구글의 설계 방향입니다.  Gemini 3.5 Flash의 설계 목적은 특허 명세서 작성에서 요구되는 역량과 구조적으로 어긋납니다.

 

따라서 Gemini 3.5 Flash는 기본적으로 특허 명세서 작성 업무에 적합하지 않다고 생각합니다.

 

 

1. Gemini 3.5 Flash, 성능보다 중요한 것은 '포지셔닝'

Google 공식 발표에 따르면, Gemini 3.5 Flash는 Terminal-Bench 2.1(76.2%)과 MCP Atlas(83.6%) 등 에이전틱 벤치마크에서 3.1 Pro를 앞서며, 복잡한 코딩 태스크와 에이전틱 업무의 장기 실행 능력이 주요 강점으로 소개되었습니다.

그런데 이 모델이 어디에 배치되었는지를 보면, 구글의 의도가 더 명확하게 보입니다.

Gemini 3.5 Flash는 출시 당일부터 Gemini 앱, Google Search의 AI Mode, 및 Antigravity 2.0 전반에 적용되기 시작했고, Gemini Spark의 기반 모델에 해당합니다.

즉, Gemini 3.5 Flash는 구글의 여러 플랫폼 전반에서 작동하는 '표준 모델'에 해당합니다.

 

AI 모델을 도구로 선택할 때, 벤치마크 수치만큼 중요한 것이 '이 모델은 어떤 문제를 풀기 위해 만들어졌는가'입니다.
Gemini 3.5 Flash의 포지셔닝은 처음부터 최고 지능이 아닌 넓은 범위의 저점 방어를 타겟으로 하고 있다고 생각합니다.

 

2. 왜 Gemini는 특허 명세서 작성에 구조적으로 불리한가?

Gemini 가 특허 명세서 작성에 구조적으로 불리한 이유는 구글 공식 문서에 있습니다.

Google 공식 Gemini 3 프롬프트 가이드 (2026.05.22 업데이트)

"By default, Gemini 3 models are less verbose and designed to prioritize providing direct and efficient answers. If your use case requires a more conversational persona, you must explicitly steer the model to be chattier in the prompt."
"기본적으로 Gemini 3 모델은 간결하게 설계되어 직접적이고 효율적인 답변을 제공하는 데 중점을 둡니다. 보다 대화적인 표현이 필요한 경우, 프롬프트에서 모델이 더 수다스럽게 답변하도록 명시적으로 설정해야 합니다."

 

즉, Gemini 는 기본적으로 짧고 간결한 답변을 출력하도록 설계되었으며, 상세한 서술이 필요하다면 사용자가 프롬프트에서 명시적으로 요청해야 한다는 것이 구글의 공식 입장입니다.
Gemini의 모델 스펙만을 고려하면 고려하면, 다른 모델들 대비 결코 출력 양이 적을 이유가 없습니다.

 

그러나 이러한 설계 목적은 Gemini가 구동되는 환경을 보면 이해될 수 있습니다.
Gemini는 단일 대화창의 AI가 아닙니다.  구글 서치의 검색 결과를 빠르게 탐색하거나, Gmail의 메일 요약하거나, 그리고 Android/XR 시스템의 요청에도 실시간으로 구동되어야 합니다.

또한, 이제 한국에서도 Gemini in Chrome이 도입되어 크롬의 여러 탭에 걸친 컨텍스트를 복합적으로 분석해서 처리할 수 있게 되었습니다.

 

이렇게 AI가 활용되는 다양한 환경에서 답변 출력이 길어질수록 그 출력이 다시 다음 입력의 컨텍스트로 활용될 때 처리 비용이 증가하고, 출력에 소요되는 시간이 길어집니다.
따라서 구글 입장에서 간결한 출력은 사용자 편의를 넘어 플랫폼 전체의 구조적 요구 사항이기도 합니다.

 

정리하면, Gemini의 역할은 문서를 처음부터 끝까지 창작하는 Writing Assistant가 아니라, 서비스와 도구를 넘나들며 정보를 빠르게 요약·전달하는 Agentic Router에 가깝다고 생각합니다.

 

특허 명세서 작성은 이 설계와 정면으로 충돌합니다.
청구항 하나만으로도 논리적으로 치밀한 구조가 요구되며, 발명의 상세한 설명은 통상의 기술자가 재현 가능한 수준의 기술적 깊이를 서술해야 합니다.
이는 압축·요약의 영역이 아니라 글을 논리적으로 구조화하고 자세하게 서술하는 영역에 해당합니다.

 

동일한 구조화된 프롬프트를 Gemini, Claude, 및 GPT에 각각 입력해 보았을 때, 일반적으로 Gemini가 더 짧은 출력을 생성하는 패턴을 반복적으로 경험했습니다.

또한, 구글 공식 가이드는 이것이 의도된 동작임을 확인해주고 있습니다.

 

간결하고 결론 위주의 보고서 생성 작업에서는 Gemini의 출력 스타일이 적합할 수 있으나, 일반적인 글쓰기 업무에서는 Gemini의 출력 스타일이 적합하지 않은 경우가 많았습니다.

 

3. Workspace Gemini에 메모리가 없는 이유

개인용 Gemini 앱에는 메모리와 연결 앱 기반의 개인 인텔리전스가 도입되었습니다.
그런데 Workspace용 Gemini 앱에는 이 기능이 적용되지 않았습니다.

 

 

이것은 의도적인 상황이라고 판단되는데, Workspace 환경에서 구글이 최우선시하는 가치는 UI 일관성, 업무 프로세스의 예측 가능성, 관리자 통제권입니다.
구글은 개인용 서비스에서 안정성이 검증된 기능만을 선별하여 보수적으로 기업 환경에 도입하는 방식을 일관되게 유지하고 있습니다.

 

메모리 기능 자체에도 트레이드-오프가 있습니다.
사용할수록 개인화된다는 장점이 있지만, 실수나 잘못된 컨텍스트가 누적될 경우 이후 출력에 지속적으로 영향을 미치는 컨텍스트 오염(Context Contamination) 리스크를 내포합니다.
즉, 모델의 최저점 대한 예측 가능성을 담보하기 어려워지는 것입니다.

 

반면 OpenAI와 Anthropic은 기업용 플랜에서도 메모리 기능을 구현하고 있으며, 시스템 프롬프트·스킬·커스텀 지시 등 반복적인 워크플로우를 구성하는 데 필요한 세부 설정을 이미 제공하고 있습니다.
구글은 규모가 큰 기업인 만큼 각국별로 서로 다른 데이터 규제에 더 민감하게 반응할 수밖에 없고, 새로운 기능의 도입 속도도 보수적일 수 밖에 없습니다.
더욱이, 전 세계에서 수억명의 사용자가 구글의 서비스를 사용하고 있으며, 기업 업무에 적용된 Workspace 플랫폼의 고급 사용자 커스터마이징 활용도는 더욱 제약을 받게 됩니다.

 

한편, 구글의 데이터 정책과 관련해서도 Workspace용 Gemini에서 짚어볼 부분이 있습니다.

• 모델 학습 사용 여부: Google의 공식 입장은 명확합니다.  Workspace에서 생성된 데이터는 Gemini 모델 학습에 사용되지 않습니다.
• Workspace 인텔리전스 참조 여부: 최근 도입된 Workspace 인텔리전스는 모델 학습이 아닌 RAG(Retrieval-Augmented Generation) 방식으로 Workspace 내 데이터를 세션 컨텍스트로 참조합니다.

"모델 학습에 사용 안 함"이 "컨텍스트 참조에도 사용 안 함"을 의미하지 않습니다.
Workspace용 Gemini에서 메모리 기능을 활용하더라도, 메모리를 파일 기반으로 생성하고, 컨텍스트 참조로 구현하면 모델 학습에 사용되지 않는다는 약관을 준수할 수 있는 여지가 있습니다.

 

그럼에도 구글이 여전히 Workspace용 Gemini에서 메모리 기능을 도입하지 않는 이유는 기업 환경을 고려한 정책적인 이유라고 생각합니다.

 

4. 2026년, 특허 실무에서 AI 도구를 어떻게 선택할 것인가

지금까지의 분석을 바탕으로, 저의 2026년 현재 AI 도구 선택 기준을 정리해 드립니다.

• 명세서 분석, 작성, 및 법률 검토: Claude Opus 4.7 또는 Sonnet 4.6
• 이미지 처리 또는 코딩: GPT-5.5 Thinking-확장
• 자료 탐색: Gemini 3.1 Pro(해석 등), Gemini 3.5 Flash(도구 호출 관련)

저는 현재 특허 명세서 관련 업무에는 Claude Opus 4.7 또는 Sonnet 4.6을, 이미지 처리나 코딩이 필요한 업무에는 GPT-5.5 Thinking-확장 모델을 주로 활용하고 있습니다.  GPT-5.5는 GPT Image 2(덕 테이프)와의 통합을 통해 이미지 처리 성능이 대폭 개선된 이후로, 도면 관련 실무에서 활용 비중이 늘었습니다.
반면, Gemini 계열은 선행기술 검색, 발명 해석, 및 기술 이해 등 직접적인 업무보다는 업무 시작 전 탐색 단계에서 주로 활용하고 있습니다.

 

Gemini 3.5 Flash 발표 후 현재까지 사용해본 결과, 체감 성능을 솔직히 말씀드리면, 개인적으로는 기대 이하였습니다.
다만, 에이전틱 기능 강화로 Gmail 등 Workspace 데이터 참조 품질이 개선된 것은 체감되고, 이전 모델 대비 아첨 현상이 줄어든 점은 긍정적으로 평가합니다.
그러나 이러한 개선이 특허 명세서 작성의 핵심 역량, 즉, 논리적 전개와 서술 밀도와는 무관하다는 점이 아쉬움으로 남습니다.
또한, 에이전틱 성능이 개선되어 딥 리서치나 도구 호출 등의 성능이 개선되었다 하더라도, 대량의 텍스트 데이터를 분석하는 작업에는 여전히 Gemini 3.1 Pro 보다 분석 깊이가 낮다고 생각합니다.

 

따라서 Gemini 3.5 Flash 모델은 코딩이 어느 정도 개입되는 업무에서는 밸런스형 모델로 활용이 가능할 수 있겠지만, 성능 또는 가성비 기준에서는 이도저도 아닌 애매한 모델이 되어버렸다는 생각이 듭니다.
물론, 구글의 플랫폼에서 기본적으로 돌아가는 하한이 높은 기본 모델로서는 충분히 가치가 있을 수 있지만, 플랫폼 사업자 입장이 아닌, 사용자 기준에서는 아쉬움이 남습니다.

 

곧 출시될 Gemini 3.5 Pro가 어떠한 변화를 가져올지 기대하고 있습니다.
그러나 모델 성능만으로는 충분하지 않다고 생각합니다.
특허 실무에서 AI 도구의 진짜 가치는 단순한 답변 품질이 아니라, 반복적인 업무 흐름에 얼마나 정밀하게 맞출 수 있는가에 달려 있습니다.

 

구글이 현재처럼 Gemini 앱에서 세부 설정이 제한된 UI 방향성을 유지하는 한, Gemini의 활용도는 모델 성능과 별개로 고급 사용자에게 지속적 제약으로 작용할 것이라고 생각합니다.

 

더욱이, OpenAI는 코덱스를, Anthropic은 클로드 코워크를 기반으로 컴퓨터의 데이터 읽기/쓰기가 실제로 가능한 에이전트 도구들을 출시하고 있습니다.

구글 또한 Antigravity 2.0을 출시하며 에이전트 도구를 출시했으나, 아직 경쟁사의 다른 에이전트 도구들에 비하면 갈 길이 멀어보입니다.

 

작성자: 이태규 변리사 (특허법인 다옴)