| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- Linux
- 터미널
- 모하비
- mojave
- 3D 프린터
- 컨트롤러
- tevo
- 맥북프로
- 애플
- AirPods
- catalina
- high sierra
- sierra
- 업데이트
- asahi
- 3D프린터
- 버그
- Fedora
- IOS
- beta
- 맥
- macos
- 아이폰
- Mac
- 시에라
- iOS 13
- 터치바
- 에어팟
- Tarantula
- asahi linux
- Today
- Total
elsa in mac
Gemini 3.1 Pro 가 나왔네요? 이제 좀 쓸만해 졌나 ? 본문

2026년 02월 19일 어제죠 ?
Google에서 Gemini 3.1 Pro를 공개했습니다.
AI를 사용하는 분야는 사람들 마다 다르겠지만, 저는 물론 Coding Agent로 사용합니다. 대부분 terminal에서 Gemini-CLI를 사용하죠.

모델 Option을 살펴보니, 떡 하니 gemini-3.1-pro-preview 가 올라와 있더군요.
공식적인 발표자료를 보니, 모든 부문에서 탁월한 점수를 보여 줍니다.

음. 사실은 이런 자료는 별 의미는 없습니다. 경쟁 후보들은 많고, 발표하면 얼마 안가서 뒤집어지기가 다반사라. ㅎ
UPDATE: gemini-cli 에서 어제까지는 보였는데, 오늘은 또 해당 모델이 보이지 않는 군요. 아직은 안정화가 덜 되었나 봅니다.
Coding Agent로 여러가지를 써봤는데, 지금까지는 Top은 Claude의 Opus 4.6 입니다. 정말 소프트웨어 개발자의 의도를 잘 맞춰준다고 할까요? 깔끔하면서도 정곡을 콕콕 찌르는 협업의 맛이 기가 막힙니다.
반면, gemini는 뭐랄까. 말은 참 많고, 공손하기는 한데, 정작 coding 문제 해결 수준은 떨어집니다. 가끔은 정말 짜증날때가 많았죠. 구독을 하고 있는데, "이거 더 구독을 해야 해?" 할 정도로 엉망이었습니다. 전문성이 좀 떨어진다고 해야 하나...
이번에 3.1-pro 가 올라와서 오늘 잠깐 써 봤는데..
오호~ 버전 3 때 보다는 확실히 좋아진 것 같습니다. 우왕좌왕하지도 않고, 한번 말한 것 잘 기억하고, 성급하게 앞서나가지도 않으면서 호흡을 잘 맞춰줍니다. opus 4.6 이나 GLM-5 을 사용하면서 느꼈던 간결함이 살짝 보이는 것 같네요.
version 3 과 GLM-5 이나 Opus 4.6 와 비교를 해 보면, 가장 큰 차이는 어떤 소스코드를 최적화 검토를 시켜 볼 때인데, GLM 이나 Opus는 운영환경을 나에게 물어보고, 최적화가 더 필요한지 아닌지를 판단해 줍니다. 사용자가 아무리 최적화를 하라고 해도, 자신의 분석결과에 따라 더 이상은 최적화를 하지 않아도 된다고 응답하죠. 허나, gemini-3는 달랐습니다. 최적화해 달라고 하면 묻지도 따지지도 않고 언제나 최적화를 합니다. 최적화한 코드를 또다시 최적화해 달라고 하면 또 생각하고 최적화를 합니다. 최적화 요구를 몇 차례 반복하면 코드가 빙빙 돌아 제자리에 올 때도 있습니다. 이건 사실 신뢰를 깎아먹는 것입니다. 무한한 최적화란 최적화를 못한다고 하는 것과 같은 말이죠. 그런데, 이번 3.1-pro 버전은 더 이상 최적화가 필요 없다고 응답을 하는군요.
프로젝트의 운영환경이나 규모를 고려 하지 못하는 것도 지난 3.0 버전의 단점이었습니다. 예를 들어 칼슘은 뼈에 좋은 것이지만, 누군가에게는 독이 될 수도 있죠. 알고리즘을 분석하거나 새로운 알고리즘을 적용할 때 gemini 3은 사용자가 요구하는 알고리즘을 가져와 적용을 해 주었지만, 운영환경을 고려하지는 못했습니다. 빠르게 처리하는 알고리즘은 늘 좋은 것이지만, 모바일 환경에서 사용할 알고리즘이라면 처리속도 못지않게 프로세싱의 부하나 전력 소모에 대한 것도 고려를 해야 합니다. 수 백개의 데이터 범주에서 탁월한 로직이 있는 반면 수백만 개의 데이터 범주에서 탁월한 로직이 있습니다. 굳이 수 백개의 작은 데이터를 처리하는데 대규모 데이터 처리에 사용되는 로직을 가져다 쓰는 것은 적절할 리 만무합니다. 이런 것들을 gemini 3 에서는 잘 분별하지 못했었습니다. 이번 3.1 에서는 좀 고민을 하고 세심하게 검토하는 것 같습니다.
Opus나 GLM, Trinity 같은 모델은 계획단계에서 사용자의 의도가 분분명한 경우, interactive 하게 대화를 이어 나갑니다. "내 생각엔 네가 1,2,3 중 하나를 요구하는 것 같은데, 맞아? 셋 중에 하나 골라~" 이런 식이라면, gemini는 그냥 자기가 생각한 대로 밀어붙입니다. 한참을 수정하다가 보면 엉뚱하게 가고 있는 경우가 많았죠. 3.1에서도 이 부분은 타 모델에 비해 부족해 보입니다. 함수를 생성하여 넣지만, 함수원형은 빼먹는 경우도 있고, 코드 수정이나 추가 후에 빌드를 해보면, 다른 모델들은 거의 한 번에 깔끔하게 끝나는 반면, gemini 는 빌드 오류가 제법 나는 편입니다. 3.1 에서는 나름 완성도가 올라다가긴 했습니다.
좀 더 써봐야 겠지만, 이번엔 좀 제대로 잘 돌아갔으면 하네요.
'Terminal(CLI,TUI)' 카테고리의 다른 글
| 이미지 화질개선 도구 - image upscaler (CLI) (0) | 2025.12.20 |
|---|---|
| Asahi Linux, Kernel 6.16 릴리즈 (0) | 2025.09.01 |
| 유용한 terminal CLI 도구들 (2025.07) #1 (0) | 2025.07.15 |
| bluetooth 헤드폰/이어폰 사용 시, CAVA 와의 latency를 없애는 방법 (0) | 2025.07.15 |
| 유용한 terminal CLI 도구들 (2025.06) (0) | 2025.06.24 |