Ollama

4개 모델을 순서대로 벤치마크하던 중, 이상하게 다음 모델의 로딩이 평소보다 느리게 느껴지는 순간이 있었다. ps aux로 확인해보니 원인이 바로 보였다. $ ps aux | grep llama-server simon 41203 539.6 ... llama-server --model .../qwen2.5-coder-14b ... simon 40891 0.0 ... llama-server --model .../deepseek-coder-v2-16b ... 새로 시작한 14B 테스트는 CPU 539.6%로 활발히 계산 중인데, 바로 아래에 방금 전에 테스트했던 DeepSeek 16B 프로세스가 CPU 0%로 여전히 살아있었다. 이미 다른 터미널에서 Aider 세션을 종료했는데도 말이다. keep_alive, 알아서 안 꺼주는 5분 원인은 Ollama의 keep_alive 메커니즘이었다. Ollama는 한 번 로드한 모델을 요청이 끝난 뒤에도 기본 5분간 메모리에 유지한다. 같은 모델로 연속 요청이 들어올 걸 대비한 최적화인데, 이게 여러 모델을 짧은 간격으로 번갈아 테스트하는 상황에서는 오히려 방해가 된다 — 이전 모델이 여전히 RAM을 점유하고 있어서, 새 모델이 로드될 때 쓸 수 있는 메모리 대역폭이 줄어들기 때문이다.

이번 로컬 LLM 프로젝트를 시작할 때 세웠던 가설 하나가 있다. “MoE(Mixture of Experts) 구조 모델은 토큰마다 일부 전문가(expert) 파라미터만 활성화하니까, 활성 파라미터 수가 작을수록 CPU에서도 더 빠르고 가벼울 것이다.” DeepSeek-Coder-V2(활성 2.4B)를 Qwen3-Coder-30B(활성 3.3B)보다 더 유리하게 볼 근거로 삼았던 가설이다. 실측해보니 속도 면에서는 어느 정도 맞아떨어졌지만(DeepSeek이 가장 빨랐다), 메모리 사용량 관점에서는 이 가설이 틀렸다. 계산에 쓰는 파라미터 ≠ 메모리에 올려야 하는 파라미터 MoE 모델이 “일부 파라미터만 쓴다"는 건 매 토큰의 계산량에 대한 이야기다. 그런데 어떤 토큰에서 어떤 expert가 선택될지는 그 순간의 입력에 따라 동적으로 정해진다. 즉 이번 토큰에서 안 쓰인 expert가 다음 토큰에서는 쓰일 수 있다 — 결국 모든 expert가 언제든 호출될 수 있으므로, 전체 파라미터가 메모리에 상주하고 있어야 한다.

로컬 LLM으로 코딩을 시켜보겠다고 마음먹었을 때, 실은 두 가지 서로 다른 활용 방식을 놓고 고민했다. 방식 A: Aider 자율 코딩 터미널에서 Aider를 실행하고, 프롬프트 하나로 파일 생성·수정·테스트·커밋까지 로컬 모델이 알아서 처리하게 하는 방식이다. yes-always 옵션으로 확인 프롬프트까지 다 꺼두면, 사람은 결과만 나중에 확인하면 된다. 지금까지 이 블로그 시리즈에서 다룬 벤치마크 테스트가 전부 이 방식이었다. 방식 B: MCP를 통한 위임 Claude Code 세션 안에서 작업을 하다가, 특정 하위 작업만 로컬 모델에 “던지고” 결과를 받아오는 방식이다. Claude Code가 메인 오케스트레이터 역할을 하고, 로컬 LLM은 도구(tool) 중 하나로 취급된다. 이걸 위해 mcp-local-llm MCP 서버를 소스에서 직접 빌드해 붙였다(이 과정은 앞선 글에서 다뤘다).

이미 휴대폰 API 주소를 Cloudflare Tunnel 서브도메인으로 열어 서버를 하나 운영하고 있다 보니, 자연스럽게 이런 생각이 들었다. “아이맥의 로컬 LLM도 전용 서브도메인으로 열어두면, 어디서든 접근할 수 있어서 더 편하지 않을까?” 같은 기기 안에서는 이득이 없다 먼저 따져야 했던 건 “누가, 어디서 이 로컬 LLM에 접근하는가"였다. 지금 계획대로라면 Aider든 MCP 서버든, 호출하는 쪽도 결국 같은 아이맥 안이다. localhost:11434로 바로 붙으면 되는 걸 굳이 인터넷을 한 바퀴 돌아서(Cloudflare Tunnel → DNS → 다시 내 아이맥) 접근할 이유가 없다. 오히려 왕복 지연만 늘어난다.

Aider를 매번 긴 커맨드라인 옵션과 함께 실행하는 건 비효율적이다. 프로젝트 루트에 .aider.conf.yml 파일 하나만 만들어두면, aider라고만 쳐도 원하는 설정이 자동 적용된다. 기본 골격 model: ollama_chat/qwen3-coder:30b chat-language: korean auto-test: true test-cmd: python3 -m pytest auto-lint: true lint-cmd: python3 -m flake8 yes-always: true analytics: false 각 항목의 의미: model: 사용할 모델. ollama_chat/ 접두어를 붙여야 Ollama의 채팅 API 경로로 붙는다. chat-language: korean: Aider가 채팅 응답을 한국어로 하도록 지시한다. 실제로 Qwen 계열은 다국어 모델(Qwen3 기준 119개 언어)이라 한국어 응답 자체는 자연스럽게 나온다. 다만 코드 안의 변수명·함수명은 한국어로 지시해도 관례상 영어로 짓는 경향이 있다. auto-test / test-cmd: 코드 수정 후 자동으로 테스트를 돌린다. auto-lint / lint-cmd: 코드 수정 후 자동으로 린트 검사·수정을 시도한다. yes-always: 무인 실행의 핵심 옵션이다. 이게 없으면 gitignore 추가, 버전 업그레이드 안내, 린트 수정 확인 같은 모든 프롬프트에서 매번 사람이 y/n을 눌러줘야 한다. analytics: false: Aider의 사용량 분석 전송을 끈다. 존재하지 않는 옵션을 썼다가 걸린 실수 처음에는 commit-language: korean도 같이 넣었다가 이런 에러를 만났다.

로컬 LLM 파이프라인을 Aider 중심으로 터미널에서 굴리다 보니, 당연한 질문이 떠올랐다. “이거 VS Code 안에서는 못 쓰나?” 매번 터미널과 에디터를 오가는 것도 번거롭고, 코드를 눈으로 보면서 바로 지시하고 싶은 순간이 많았기 때문이다. 로컬 모델은 특정 도구 전용이 아니다 먼저 짚고 넘어가야 할 게 있다. Ollama가 localhost:11434에 띄우는 API는 OpenAI 호환/Ollama 자체 API를 따르는 범용 엔드포인트다. 즉 Aider 전용이 아니라, 이 API를 호출할 수 있는 도구라면 뭐든 붙을 수 있다는 뜻이다. 그래서 VS Code 확장 중에서도 로컬 Ollama를 지원하는 것들을 찾아보면 된다.

앞선 글들에서 인텔 아이맥에 로컬 코딩 LLM 파이프라인을 설치하고, 4개 모델을 실측 비교했다. 결론부터 말하면 이 프로젝트는 여기서 접기로 했다. 그 판단에 이르기까지의 근거를 정리한다. 결정타는 “재현성 부족"이었다 가장 빠르고 안정적이었던 DeepSeek-Coder-V2-16B를, 완전히 동일한 프롬프트로 한 번 더 돌려봤다. 결과는 이랬다. 1차 2차 소요 시간 9분 30초 22분 55초 (2.4배) 커밋 feat + lint fix 시도 feat 1개뿐 함수 개수 요청한 4개 요청에 없던 4개(거듭제곱·나머지·제곱근·팩토리얼) 임의 추가 flake8 잔여 오류 일부 16건 같은 입력, 같은 모델인데 소요 시간이 2.4배 차이 나고, 심지어 요청하지 않은 기능을 마음대로 추가했다. 이건 “느리다"가 아니라 “결과물을 매번 처음부터 검토해야 한다"는 뜻이다. 무인 파이프라인의 핵심 전제 — 사람이 개입하지 않아도 일정 수준의 결과가 보장된다는 것 — 이 자체가 깨진 셈이다.

설치를 마쳤으니 이제 실측이다. Aider가 설치된 ~/Projects/pipeline-test 저장소에서, 모델별로 git 브랜치를 나눠 완전히 동일한 프롬프트를 던졌다. 간단한 계산기 모듈을 만들어줘. add, subtract, multiply, divide 함수와 각각의 pytest 테스트 코드도 함께 작성해줘. 의도적으로 아주 쉬운 작업을 골랐다. 이 정도도 제대로 못 하면 더 복잡한 작업은 아예 시도할 이유가 없기 때문이다. 결과 요약 모델 소요 시간 결과 비고 Qwen3-Coder-30B ~30분 ✅ 성공 flake8 자동 수정까지 완료. 요청하지 않은 거듭제곱·나머지·제곱근·팩토리얼 함수를 임의로 추가함 Qwen2.5-Coder-7B — ❌ 실패 whole·diff 포맷 둘 다 신뢰 불가 (아래 상세) DeepSeek-Coder-V2-16B 9분 30초 ✅ 성공 가장 빠름. flake8 일부 미해결 Qwen2.5-Coder-14B 27분 43초 ✅ 성공 가장 느림. flake8은 완전히 깨끗하게 해결 7B가 두 번 다 무너진 이유 가장 작은 모델인 Qwen2.5-Coder-7B는 흥미로운 실패 방식을 두 개나 보여줬다.

로컬 LLM 파이프라인에는 두 가지 활용 방식이 있다고 생각했다. 하나는 Aider가 터미널에서 로컬 모델로 자율 작업을 하는 방식, 다른 하나는 Claude Code 세션 안에서 필요할 때만 로컬 모델에 작업을 위임하는 MCP(Model Context Protocol) 서버 방식이다. 이 둘은 서로 배타적이지 않고 병행할 수 있어서, 일단 MCP 쪽도 붙여보기로 했다. CONNECTION_CLOSED claude mcp add local-llm -- npx -y mcp-local-llm 등록은 됐는데, claude mcp list로 확인하면 상태가 이렇다. local-llm: npx -y mcp-local-llm - ✘ Failed to connect — CONNECTION_CLOSED 에러 메시지만으로는 원인을 알 수 없었다. npx가 내부적으로 어떤 명령을 실행하는지 직접 눈으로 확인해야 했다.