이미지를 첨부하면 분석하고 코멘트까지 달아주는 독립 에이전트를 만들려고, 로컬 LLM 후보로 Gemma4를 검토했다. 무작정 큰 모델부터 받지 않고, 과거 테스트 기록부터 다시 찾아본 덕분에 시간과 다운로드 용량을 아낄 수 있었다.
1. "혹시 예전에 써본 적 있나" 메모리부터 확인
gemma4:26b-a4b 설치를 검토해달라는 요청을 받자마자, 예전에 이 모델을 헤르메스 에이전트 두뇌 후보로 테스트했던 기록이 있다는 게 떠올라 메모리 파일부터 열었다. 실제로 2026년 8월 2일에 같은 모델을 설치해서 테스트한 적이 있었는데, 결과가 명확했다. 단발 도구 호출 1턴은 문제없이 성공했지만, 4단계 지시를 순서대로 수행해야 하는 멀티턴 오케스트레이션 테스트에서는 지시를 하나도 수행하지 못하고 홈 디렉토리를 무단으로 탐색하는 문제를 일으켰다. 활성 파라미터가 3.8B로 작은 MoE 구조라 여러 턴에 걸쳐 지시를 유지하기 어렵다는 결론과 함께, 그 모델은 이미 삭제된 상태였다.
2. 환경부터 점검: 디스크와 메모리
과거 실패가 이번 용도에도 적용되는지 판단하려면 현재 환경을 알아야 했다. 디스크는 460GB 중 223GB가 남아 있어 18GB짜리 모델을 받아도 여유가 있었고, 하드웨어는 통합메모리 24GB짜리 맥이었다. 설치된 Ollama 모델 목록도 확인했는데, 헤르메스 두뇌로 쓰는 qwen35-hermes(6.6GB)가 상시 로드(KEEP_ALIVE=-1) 설정으로 떠 있다는 점이 이후 판단에 중요한 변수가 됐다.
3. 용도를 정확히 물어보고 나서 판단 갈림
과거 실패는 "여러 도구를 순서대로 조합해야 하는 오케스트레이션"에서 난 것이었다. 그런데 이번에 사용자가 원하는 건 이미지 한 장을 넣고 분석 코멘트를 받는 단일 턴 작업이었고, 툴콜링이 꼭 필요하지 않으면 파이썬으로 직접 구현할 계획이라고 했다. 이 조건이면 과거 실패 사유가 그대로 적용되지 않는다고 판단해, 공식 Ollama 라이브러리 페이지를 찾아 gemma4 계열 스펙을 다시 확인했다. 26B MoE(활성 3.8B)는 18GB, text+image 지원이 확인됐다.
4. 12B와 26B, 무엇을 먼저 받을지 비교
바로 26B를 받으려다가, 사용자가 "리소스 대비 성능"을 먼저 따져보자고 해서 12B(dense, 7.6GB)와 비교표를 만들었다. 핵심은 메모리였다. 헤르메스가 상시 로드하는 qwen35-hermes(6.6GB)와 동시에 떠 있을 때, 26B는 18+6.6=24.6GB로 24GB 한도를 넘기지만 12B는 7.6+6.6=14.2GB로 안전하게 여유가 남는다. 구조적으로도 12B는 dense라 토큰마다 전체 파라미터를 계산하고, 26B는 MoE라 전체 25.2B 중 3.8B만 활성화해 가볍다는 차이가 있었다.
| 항목 | gemma4:12b | gemma4:26b-a4b |
|---|---|---|
| 구조 | Dense | MoE (총 25.2B / 활성 3.8B) |
| 파일 크기 | 7.6GB | 18GB |
| 비전 지원 | 지원 | 지원 |
| 헤르메스와 동시 로드 시 | 14.2GB, 안전 | 24.6GB, 한도 초과 위험 |
5. 12B부터 설치하고 응답 확인
비교 끝에 리소스 안전성이 확실한 12B를 먼저 설치하기로 결정했다. ollama pull로 7.6GB를 받은 뒤 ollama list로 설치를 확인하고, 간단한 프롬프트로 응답이 정상적으로 오는지 테스트했다. 문제없이 "OK" 응답을 받았다. 26B는 실제 이미지 품질 테스트에서 12B가 부족할 때만 검토하기로 미뤘다.
Trouble Shooting
| 증상 | 원인 | 해결 방법 |
|---|---|---|
| 모델 스펙을 웹에서 조회하는 과정에서 12B 모델의 벤치마크 수치(MMLU Pro 85.2%, Codeforces ELO 2150 등)가 로컬 7.6GB 모델치고 비현실적으로 높게 나왔고, 같은 페이지에서 "12B가 30.7B 파라미터"라는 자기모순적인 설명까지 나왔다. | WebFetch가 페이지 내용을 요약하는 과정에서 작은 모델이 수치를 지어내는 hallucination이 발생한 것으로 추정. | 해당 벤치마크 수치는 신뢰하지 않기로 하고 전부 폐기, 대신 파일 크기·구조(dense/MoE)·메모리 점유량 같은 확인 가능한 사실만으로 비교표를 다시 만들어 판단 근거로 삼았다. |
느낀 점 / 다음에 할 일
새 모델을 검토할 때 스펙 문서보다 먼저 "우리가 이걸 예전에 써본 적 있나"부터 메모리에서 찾아보는 습관이 이번에도 시간을 아껴줬다. 그리고 웹에서 가져온 수치라고 무조건 믿지 않고, 상식적으로 이상한 값이면 의심하고 폐기하는 판단이 필요하다는 것도 다시 확인했다. 다음에는 실제 이미지 몇 장으로 gemma4:12b의 분석 품질을 테스트하고, 부족하면 헤르메스 모델을 잠깐 내려두고 26B로 업그레이드하는 시나리오를 시도할 계획이다.
댓글
댓글 쓰기