Ollama + 오픈소스 LLM 실전 벤치마크 — 보안 분석, 블로그 작성, 도구 호출까지
서론
클라우드 AI 서비스 비용이 부담될 때, 로컬 GPU로 코딩 에이전트를 돌릴 수 있다면 어떨까? RTX 4060 8GB라는 가장 흔한 미드레인지 GPU에서 오픈소스 LLM 3종을 실전 태스크로 테스트했다. Ollama v0.30.6을 사용해 Qwen 3.5 4B, Qwen 3.6 35B, Gemma4 12B를 동일 조건에서 비교했다.
결론부터 말하면 — 코딩 보조는 된다. 글쓰기는 안 된다. 그리고 그 사이의 경계선이 생각보다 정확하다.
1. 테스트 환경
| 항목 | 사양 |
|---|---|
| GPU | NVIDIA RTX 4060 8GB GDDR6 |
| CPU | Intel i7-14700K (20C/28T) |
| RAM | 32 GB |
| OS | Windows 11 |
| 런타임 | Ollama v0.30.6 |
테스트 모델 3종:
| 모델 | 파라미터 | 양자화 | VRAM |
|---|---|---|---|
| Qwen 3.5 4B | 4.2B | Q4_K_M (4-bit) | 3,173 MB |
| Qwen 3.6-35B-A3B | 34.7B (활성 3B) | IQ2_M (2-bit) | 6,091 MB |
| Gemma4 12B | 11.9B | Q4_K_M (4-bit) | 5,743 MB |
Qwen 3.6은 35B 모델이지만 MoE 구조라 활성 파라미터는 3B 수준이다. 8GB VRAM에 맞추려면 2-bit 극한 양자화가 필요했다.
2. 보안 취약점 분석 — 코딩은 된다
Express.js 코드에 5개의 보안 취약점을 의도적으로 삽입하고, 각 모델에게 "전부 찾고 수정 코드를 제시하라"고 요청했다.
| 모델 | 발견 | 시간 | tok/s | 특징 |
|---|---|---|---|---|
| Qwen 3.5 | 3.5/5 | 22초 | 69.5 | 가장 빠름. 토큰 위조를 비고란에만 언급 |
| Qwen 3.6 | 4/5 | 33초 | 55 | 품질 최고. JSON 구조 완벽 |
| Gemma4 | 4/5 | 154초 | 17.3 | 가장 느리나 전체 통합 수정 코드 제공 |
SQL Injection 2건, Path Traversal, 토큰 위조는 3모델 모두 정확히 잡았다. 공격 시나리오(' OR '1'='1, ../../etc/passwd)도 구체적이었고, 수정 코드(파라미터 바인딩, JWT 전환, path.resolve 검증)도 실전 투입 가능한 수준이었다.
단, "token 없이도 next()가 호출되어 인증 없이 통과"하는 5번째 취약점은 3모델 모두 놓쳤다. 이건 코드 흐름을 전체적으로 추적해야 보이는 미묘한 버그로, 12B 이하 모델의 한계선을 보여준다.
3. Thinking 모드 — 똑똑하지만 욕심이 과하다
Qwen 3.5와 3.6은 reasoning 모델이라 모든 응답에 "thinking" 과정을 먼저 생성한다. 이게 문제다.
컨텍스트 4096 토큰에서, 모델은 thinking만 하다가 실제 답변을 출력하지 못하고 멈춰버렸다. 8192로 올리자 해소됐고, 16384에서는 짧은 코딩 문제(O(n²)→O(n) 최적화)를 1.4초 만에 77토큰으로 정확히 풀었다.
핵심 공식은 이렇다:
- Thinking에 종이(컨텍스트)를 충분히 주면, 정확하고 빠르다
- 종이가 부족하면, 생각만 하다 시간이 다 간다
/no_think 태그로 thinking을 끄려 해봤지만, GGUF 환경에서는 작동하지 않았다. Ollama CLI의 --nothink 플래그도 빈 응답만 반환했다.
4. 블로그 작성 — 여기서 벽이다
같은 모델들에게 오늘의 벤치마크 데이터를 주고 한국어 블로그를 써달라고 했다. 결과는 참혹했다.
- Gemma4: 한국어 프롬프트에 중국어로 응답. 내용도 테스트 데이터가 아닌 일반적 Ollama 가이드
- Qwen 3.6: 한국어로 썼지만 Express.js 코드 튜토리얼로 주제 이탈
- Qwen 3.5: 역시 중국어. 게다가 같은 내용을 반복 출력하는 루프에 빠짐
프롬프트를 강화해봤다. "반드시 한국어로만", "아래 데이터를 그대로 사용하라", "없는 정보 추가 금지". 결과는 약간 나아졌지만 본질적으로 같았다. Qwen 3.6이 392토큰짜리 메모를 써낸 것이 최선이었다.
코딩에서 4/5를 맞추던 모델이 왜 블로그에서 전멸하는가? 두 가지 원인이다:
- 2-bit 양자화로 언어 구분력이 저하됐다. 한국어와 중국어 토큰 확률이 비슷해져서 혼동한다.
- "정답이 있는 문제"와 "창작"은 다른 능력이다. 코드 분석은 패턴 매칭에 가깝지만, 주어진 데이터를 읽고 구조화된 글로 엮는 것은 훨씬 높은 지시 준수력을 요구한다.
5. 도구 호출 — Gemma4만 된다
Ollama 모델의 capabilities 필드를 확인하면:
- Gemma4 12B:
completion, tools, thinking, vision - Qwen 3.5/3.6:
completion만
Gemma4에게 "YAML 검증 파이썬 스크립트를 짜서 실행하라"고 요청하자, 96초 만에 58줄짜리 스크립트를 생성하고 run_python tool_call까지 성공했다. 테스트 픽스처 4개를 자동 생성하고, yaml.safe_load로 파싱 검증까지 하는 완성도였다.
다만 이건 단일 턴에서의 성공이다. 실행 → 에러 → 수정 → 재실행의 멀티 턴 에이전트 루프는 컨텍스트 누적으로 8192 토큰을 압박하게 되어, 안정적인 운용은 어렵다.
6. 결론 — 인턴은 된다, 시니어는 안 된다
| 영역 | 가능 여부 | 비고 |
|---|---|---|
| 단일 함수 버그 수정 | ✅ | 1.4~22초 |
| 코드 리뷰 (단일 파일) | ✅ | 4/5 정확도 |
| YAML/JSON 검증 | ✅ | 15~25초 |
| 도구 호출 (Gemma4) | ✅ | 단일 턴 한정 |
| 한국어 블로그 작성 | ❌ | 언어 혼동 + 주제 이탈 |
| 멀티파일 디버깅 | ❌ | 컨텍스트 부족 |
| 복잡한 규칙 준수 | ❌ | 지시 준수력 한계 |
"파일 하나, 함수 하나, 명확한 지시" — 이 범위 안에서 로컬 LLM은 비용 0의 코딩 인턴으로 쓸 수 있다. 상위 에이전트(Opus, Sonnet)가 태스크를 잘게 쪼개 던지고, 결과를 검수하는 구조라면 실전 투입도 가능하다.
다만 현재의 한계는 GPU가 아니라 양자화다. 8GB VRAM에 35B를 우겨넣으려면 2-bit까지 깎아야 하고, 그 순간 반복 붕괴, 언어 혼동, 창작 불가가 따라온다. 같은 모델이 24GB GPU에서 4-bit로 돌아간다면, 오늘 실패한 블로그 작성도 가능해질 수 있다.
RTX 4060은 PoC를 검증하기에 충분했다. 두뇌는 되는데 몸이 안 따라주는 것 — 그걸 정량적으로 증명한 하루였다.