로컬 테스트를 거친 오픈코드용 최고의 LLM

OpenCode 가 Ollama 로 로컬 호스팅된 여러 LLM 과 함께 작동하는 방식을 테스트해 보았고, 비교를 위해 OpenCode Zen 에서 제공하는 무료 모델 몇 가지를 추가했습니다.

현재 OpenCode 는 AI 개발 도구 생태계에서 가장 유망한 도구 중 하나입니다.

TL;DR - OpenCode 에 가장 적합한 LLM

로컬 환경의 명백한 승자: Qwen 3.5 27b Q3_XXS (llama.cpp 기반)

IQ3_XXS 양자화는 모든 8 개의 단위 테스트가 통과하고, 완전한 README 를 포함하며 16GB VRAM 환경 (CPU+GPU 혼합) 에서 초당 34 토큰의 속도를 보이는 완벽한 작동 가능한 Go 프로젝트를 제공했습니다. 별 5 점, 단점은 없습니다. 이것이 제가 로컬 OpenCode 세션에 사용하는 주된 모델입니다.

Qwen 3.5 35b (llama.cpp) — 코딩에는 빠르지만 모든 것을 검증해야 함

35b 모델은 빠른 에이전트 코딩 작업에 탁월합니다. 하지만 마이그레이션 맵 테스트에서 심각한 신뢰성 문제를 드러냈습니다. 두 번의 IQ3_S 실행에서 63–73% 의 슬러그 불일치를 보였고, IQ4_XS 양자화에서는 페이지 슬러그를 완전히 포함하지 않고 8 개의 서로 다른 페이지를 같은 URL 로 매핑하는 카테고리 경로를 생성했습니다. IndexNow 작업에서의 코딩 품질은 genuinely 좋았으므로 이 모델을 사용하는 가치가 있습니다. 다만, 구조적이고 규칙 준수가 필요한 작업에서는 출력에 절대적으로 의존하지 말고 반드시 검증해야 합니다. 검증은 선택 사항이 아닙니다.

놀랍도록 좋은 성능: Bigpicle (OpenCode Zen 제공)

작업 완료까지 가장 빨랐습니다 (1 분 17 초). 더 중요한 것은, 코딩을 시작하기 전에 Exa Code Search 를 사용하여 IndexNow 프로토콜 사양을 실제로 검색한 유일한 모델이었다는 점입니다. 첫 시도에 모든 올바른 엔드포인트를 찾았습니다. OpenCode Zen 에 접근 권한이 있다면, 이 모델은 그 성능에 비해 훨씬 뛰어난 결과를 보여줍니다.

좋지만 ‘고급 사고 (high thinking)’ 모드에서만 사용 가능: GPT-OSS 20b

기본 모드에서는 GPT-OSS 20b 는 실패합니다. 죽은 길인 WebFetch 호출에 부딪히면 멈춥니다. 하지만 고급 사고 모드로 전환하면 진정으로 유능한 코딩 어시스턴트가 됩니다: 플래그 파싱 완료, 올바른 배치 로직, 단위 테스트 통과 등 빠르게 모든 작업을 수행합니다. 이를 단정하지 않고 기억해 두세요. GPT-OSS 20b 는 고급 모드에서도 구조화된 작업에서는 실패했습니다.

에이전트 코딩에는 건너뛰세요: GPT-OSS 20b (기본), Qwen 3 14b, devstral-small-2:24b

이 모델들은 예전에 채팅 및 생성 작업에서 속도가 빨라 저의 즐겨찾기였습니다. 하지만 에이전트 모드에서는 모두 실제 문제가 있습니다. Qwen 3 14b 는 무언가를 찾을 수 없다고 인정하는 대신 문서를 환각합니다. GPT-OSS 20b (기본) 는 WebFetch 가 실패하면 멈춥니다. Devstral 은 기본적인 파일 작업에서 혼란을 겪습니다. OpenCode 의 경우, 원속도보다 지시 사항 준수 및 도구 호출 품질이 훨씬 더 중요합니다.

테스트 개요

opencode 에서 실행 중인 각 모델에게 두 가지 작업/프롬프트를 부여했습니다:

1. 제 웹사이트 변경 사항을 알리기 위해 Bing 과 다른 검색 엔진의 indexnow 엔드포인트를 호출하는 Go 기반 CLI 도구를 만들어 주세요.
2. 웹사이트 마이그레이션 맵을 준비하세요.

Indexnow 프로토콜이 무엇인지 아시죠?

두 번째 작업에 관해 말씀드리자면, 이 웹사이트의 일부 오래된 게시물을 블로그 URL 형식 (예: https://www.glukhov.org/post/2024/10/digital-detox/) 에서 토픽 클러스터 (이 글의 URL 과 같이: https://www.glukhov.org/ai-devtools/opencode/llms-comparison/) 로 마이그레이션하는 계획이 있습니다. 따라서 저는 각 LLM 에게 저의 전략에 따라 마이그레이션 맵을 준비해 달라고 요청했습니다.

대부분의 LLM 은 로컬 호스팅된 Ollama 에서 실행했고, 일부는 로컬 호스팅된 llama.cpp 에서 실행했습니다. Bigpicle 과 기타 초대규모 언어 모델은 OpenCode Zen 에서 가져왔습니다.

각 모델의 결과

qwen3.5:9b

첫 번째 작업에서 완전한 실패였습니다. 모델은 사고 과정을 거쳤고 관련 서비스 (Google Sitemap, Bing Webmaster, Baidu IndexNow, Yandex) 를 정확하게 식별했지만, 실제로는 어떤 도구도 호출하지 않았습니다. 단일 파일도 건드리지 않은 채 “빌드” 요약만 생성했습니다. 도구 호출은 전무했습니다.

qwen3.5:9b-q8_0

기본 양자화보다 한 발짝 나아갔습니다. 적어도 go.mod 와 main.go 는 생성했습니다. 하지만 곧바로 멈추고 누락된 import 를 추가해야 함을 인정했다가, shell heredoc 을 사용하여 전체 파일을 다시 작성하려다 실패했습니다. 작동하지 않는 것을 위해 빌드 시간은 1 분 27 초였습니다.

Qwen 3 14b

압박감 하에서의 전형적인 환각입니다. IndexNow 문서를 세 번 연속 시도하며 잘못된 URL (github.com/Bing/search-indexnow) 에서 404 에러를 받았습니다. 무언가를 찾을 수 없다고 인정하는 대신, 자신감 넘치는 답변을 만들어냈습니다: 잘못된 API 엔드포인트, 잘못된 인증 방법. 다시 검색하라고 했을 때, 또 다른 404 를 반환하는 URL 을 가리키는 두 번째 허위 답변을 생성했습니다. 보고된 정보는 틀렸습니다. 제가 가장 피하고 싶은 실패 모드입니다.

GPT-OSS 20b

적어도 행동은 정직하고 체계적이었습니다. 긴 WebFetch 호출 연쇄 (indexnow.org, 다양한 GitHub 리포지토리, Bing 자체 페이지 등) 를 시도했고 거의 모든 곳에서 404 또는 Cloudflare 차단이 발생했습니다. 각 실패를 투명하게 문서화했습니다. 결국 작동하는 도구를 만들기에는 충분한 정보를 모으지 못했지만, Qwen 3 14b 와 달리 무언가를 만들어내지는 않았습니다. 그냥 뚫고 나가지 못했을 뿐입니다.

GPT-OSS 20b (고급 사고 모드)

기본 모드와는 의미 있게 다른 이야기입니다. 고급 사고가 활성화되면서 모델은 같은 죽은 길의 페치에서 회복되어 완전하고 작동하는 도구를 구축했습니다: 올바른 플래그 파싱 (--file, --host, --key, --engines, --batch, --verbose), IndexNow 규격에 따른 단일 URL 에 대한 GET 과 복수 URL 에 대한 POST 배치 등.

문서와 단위 테스트를 요청했을 때 두 가지를 모두 제공했습니다. 테스트 통과:

=== RUN   TestReadURLsFile
--- PASS: TestReadURLsFile (0.00s)
=== RUN   TestReadURLsNoProtocol
--- PASS: TestReadURLsNoProtocol (0.00s)
ok  	indexnow-cli	0.002s

속도도 빨랐습니다. 초기 빌드 22.5 초. 고급 사고는 gpt-oss:20b 를 실제로 사용 가능하게 만듭니다.

qwen3-coder:30b

가장 흥미로운 실패였습니다. 실제로 도구를 컴파일하고 실행하여 실제 엔드포인트에 대해 테스트했고, Bing, Google, Yandex 에서 실제 API 에러를 받은 후 수정을 시작했습니다:

Error notifying Bing: received status code 400 ... "The urlList field is required."
Error notifying Google: received status code 404 ...
Error notifying Yandex: received status code 422 ... "Url list has to be an array"

좋은 본능입니다. 문제는 22 GB 모델에 대해 CPU 는 720%, GPU 는 7% 만 사용하여 매우 비효율적이었단 점입니다. 11 분 39 초가 걸렸고 최종 출력도 “기다려지는 것과는 조금 달랐습니다.” README.md 를 생성한 것은 좋은 점입니다. 나쁜 모델은 아니지만 저의 환경에서는 매우 느렸고 IndexNow 프로토콜 형식을 완전히 맞히지 못했습니다.

qwen3.5:35b (Ollama)

견고한 결과지만 느렸습니다. 적절한 Go 프로젝트를 생성하고 테스트를 작성했으며, 모두 통과했습니다:

=== RUN   TestHashIndexNowPublicKey/non-empty_key
--- PASS
=== RUN   TestGetPublicKeyName/standard_root
--- PASS
=== RUN   TestGetPublicKeyName/custom_root
--- PASS

단점은: 19 분 11 초의 빌드 시간입니다. 27 GB 모델이 45%/55% CPU/GPU 분배로 실행되는 상황에서는 인터랙티브 사용에 너무 느립니다. 품질은 있지만, 지연 시간이 워크플로우를 죽입니다.

Bigpicle (big-pickle)

첫 번째 작업에서 돋보이는 성능을 보였습니다. 한 줄의 코드도 작성하기 전에 Exa Code Search 를 사용하여 IndexNow 프로토콜을 실제로 조사했습니다:

◇ Exa Code Search "IndexNow protocol API endpoint how to notify search engines"

올바른 엔드포인트를 찾았습니다:

• Global: https://api.indexnow.org/indexnow
• Bing: https://www.bing.com/indexnow
• Yandex: https://webmaster.yandex.com/indexnow
• Yep: https://indexnow.yep.com/indexnow
• Amazon: https://indexnow.amazonbot.amazon/indexnow

cobra import 문제를 깔끔하게 해결 (go mod tidy) 했고, 도구는 1 분 17 초 만에 완성되었습니다. 테스트 중 Bing 에서 받은 속도 제한 응답은 실제로 잘못된 테스트 키에 대한 예상되는 동작이었습니다. 모델은 이를 “도구가 작동 중"이라고 정확하게 식별했습니다. 인상적입니다.

devstral-small-2:24b

기본적인 수준에서 혼란을 겪었습니다: shell 명령어 (go mod init indexnowcli, go mod tidy) 를 go.mod 파일에 직접 작성하려고 시도하여 파싱 에러를 유발했습니다. 어쨌든 바이너리 (7.9M) 를 빌드하긴 했지만, 생성된 CLI 는 너무 단순했습니다: 플래그 처리 없음, 다중 엔진 지원 없음 등 그저 indexnowcli <url> <key> 만 있었습니다. 실제로 유용하지 않은 도구를 얻는 데 2 분 59 초 + 1 분 28 초가 걸렸습니다.

qwen3.5:27b (llama.cpp, IQ3_XXS 양자화)

이 모델은 로컬 실행기 중 가장 저를 놀라게 했습니다. Qwen3.5-27B-UD-IQ3_XXS.gguf 로 llama.cpp (주로 CPU) 에서 실행되며, 완전한 테스트 커버리지 (모든 8 개 테스트 통과) 와 설치 설명 및 프로토콜 설명이 포함된 적절한 README 를 갖춘 완전한 도구를 생성했습니다:

PASS    indexnow    0.003s

지원 엔진: Bing, Yandex, Mojeek, Search.io. 빌드 시간: 도구 1 분 12 초, 테스트 및 문서 1 분 27 초. 속도: 초당 34 토큰. 품질: 별 5 점. CPU+GPU 에서 실행되는 양자화 모델에 대한 놀라운 결과입니다.

qwen3.5:35b (llama.cpp, IQ3_S 양자화)

Qwen3.5-35B-A3B-UD-IQ3_S.gguf 로 llama.cpp 에서 실행되었습니다. 여기의 메모는 짧습니다: “훌륭함!” — 이것이 전부입니다. 동일한 양자화 레벨의 더 큰 모델은 27b 변종만큼이나, 혹은 그보다 더 좋은 결과를 제공했습니다.

마이그레이션 맵 결과

두 번째 작업에는 별도의 배치 (7 개 모델) 를 실행하여 동일한 지시 사항, 사이트 구조, 페이지 목록을 제공했습니다. 제약 사항은 명확했습니다: 슬러그 (마지막 경로 세그먼트) 는 그대로 유지되어야 합니다. 예를 들어, /post/2024/04/reinstall-linux/ 는 /.../reinstall-linux/ 가 되어야 하며, 다른 것이 되어서는 안 됩니다.

각 모델이 생성한 슬러그 불일치 (생성된 대상 슬러그가 소스 슬러그와 다른 경우) 의 수를 측정했습니다.

모델	라인 수	슬러그 불일치	에러율
minimax-m2.5-free	80	4	5.0%
Nemotron 3	78	4	5.1%
Qwen 3.5 27b Q3_XXS (llama.cpp)	80	4	5.0%
Qwen 3.5 27b Q3_M (llama.cpp)	81	6	7.4%
Bigpicle	81	9	11.1%
mimo-v2-flash-free	80	42	52.5%
Qwen 3.5 35b IQ3_S - 두 번째 실행 (llama.cpp)	81	51	63.0%
Qwen 3.5 35b IQ4_XS (llama.cpp)	80	79	98.8%

7 개 모델이 모두 동일하게 수행한 한 가지가 있습니다: 2022 년 형식의 오래된 URL 은 슬러그에 월 접두사가 포함되어 있었습니다 (예: /post/2022/06-git-cheatsheet/ → 슬러그 06-git-cheatsheet). 모든 모델은 그 접두사를 제거하고 git-cheatsheet 를 새로운 슬러그로 사용했습니다. 이는 상위 3 개 모델에서 일관되게 발생한 4 개의 불일치입니다. 따라서 그들의 기준선은 0 이 아닌 각 4 개의 에러입니다.

진정한 차이는 그 기준선 위부터 시작됩니다. minimax-m2.5-free, Nemotron 3, Qwen 3.5 27b Q3_XXS 는 오직 그 4 개의 레거시 경로에서만 슬러그 규칙을 위반했을 뿐, 그 이상은 없었습니다. Qwen 3.5 27b Q3_M 은 2 개 더 추가했습니다 (cognee 기사 슬러그를 변경하고 Base64 를 소문자로 변경). Bigpicle 은 4 개에 5 개를 더 추가했는데, 주로 긴 슬러그를 단축시켰습니다.

이상치는 다른 범주에 속합니다. Qwen 3.5 35b IQ3_S 는 소스를 보존하는 대신 페이지 제목에서 슬러그를 일관되게 다시 작성했습니다 (예: executable-as-a-service-in-linux → run-any-executable-as-a-service-in-linux, file-managers-for-linux-ubuntu → context-menu-in-file-managers-for-ubuntu-24). 두 번째 실행은 약간 더 좋았지만 (51 vs 59) 같은 행동을 보였습니다. 또한 소스 경로를 환각했습니다: 조용히 comparing-go-orms-gorm-ent-bun-sqlc 를 comparing-go-orms-gorm-ent-bun-sql 로 변경하여 c 를 삭제했습니다. 따라서 그 라인의 양쪽이 서로 일치했지만, 둘 다 틀렸습니다. mimov2 도 단축에 대해 비슷하게 공격적이었습니다: gnome-boxes-linux-virtual-machines-manager → gnome-boxes, vm-manager-multipass-cheatsheet → multipass.

35b 의 IQ4_XS 양자화는 완전히 다른 실패 범주입니다: 98.8% 슬러그 불일치 — 하지만 문제는 잘못된 슬러그가 아니라, 모델이 슬러그를 아예 포함하지 못했다는 점입니다. /new-section/page-slug/ 대신 /developer-tools/terminals-shell/ 과 /rag/architecture/ 같은 카테고리 경로를 생성했습니다. 8 개의 소스 페이지가 /developer-tools/terminals-shell/ 로 매핑되어 모두 같은 URL 을 가리켰습니다. 이는 사용된다면 재앙적이었을 것입니다. /developer-tools/ 만으로도 5 개의 별도 페이지가 모였습니다. 출력은 완전히 사용할 수 없습니다.

이 작업에서는 작은 양자화된 Qwen 3.5 27b Q3_XXS 가 최고의 클라우드 모델과 매치했습니다. 반면 두 가지 35b 양자화는 각기 다른 방식으로 크게 실패했습니다.

결론

llama.cpp 에서 양자화된 가중치로 로컬에서 Qwen 3.5 35b 와 Qwen 3.5 27b 를 모두 실행하는 데 만족합니다. 하드웨어 제약은 현실적입니다 (16GB VRAM 은 IQ3/IQ4 양자화를 의미함) 하지만 워크플로우는 견고합니다.

27b Q3_XXS 는 신뢰할 수 있는 일일 드라이버입니다. 지시 사항을 정확히 따르고 완전한 출력을 생성하며 인터랙티브 사용에 충분히 빠릅니다. 마이그레이션 맵 작업에서는 최고의 클라우드 모델과 매치했습니다.

35b 는 유능하지만 구조화된 작업에서 예측 불가능합니다. 개방형 코딩 (도구를 만들어라, 이것을 구축하라) 에서는 잘 수행됩니다. 하지만 작업에 엄격한 규칙이 있는 경우 (예: “슬러그는 그대로 유지되어야 함”) 제가 테스트한 모든 양자화에서 자유롭게 환각합니다: 제목에서 슬러그를 다시 작성하거나, 슬러그를 완전히 누락하거나, 심지어 잘못된 출력이 일관성 있게 보이도록 소스 경로를 조용히 편집합니다. 35b 를 바로 사용할 구조화된 출력을 생성하는 작업에 사용한다면 워크플로우에 검증 단계를 포함하세요. 출력이 그럴듯해 보인다고 해서 맞다고 가정하지 마세요.

이 LLM 들이 어떤 속도로 수행되는지 궁금하다면 16GB VRAM GPU 를 위한 Ollama 최고의 LLM 을 확인하세요.