Ollama on Simon의 AI 시대에 살아남는 법

여러 로컬 LLM 모델을 번갈아 테스트할 때 알아야 할 것 — ollama ps와 keep_alive

Sat, 17 Oct 2026 18:25:00 +0900

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을 점유하고 있어서, 새 모델이 로드될 때 쓸 수 있는 메모리 대역폭이 줄어들기 때문이다.

MoE 모델인데 왜 다 무겁다 — Ollama가 모델 전체를 메모리에 올리는 이유

Fri, 16 Oct 2026 13:35:00 +0900

이번 로컬 LLM 프로젝트를 시작할 때 세웠던 가설 하나가 있다. “MoE(Mixture of Experts) 구조 모델은 토큰마다 일부 전문가(expert) 파라미터만 활성화하니까, 활성 파라미터 수가 작을수록 CPU에서도 더 빠르고 가벼울 것이다.” DeepSeek-Coder-V2(활성 2.4B)를 Qwen3-Coder-30B(활성 3.3B)보다 더 유리하게 볼 근거로 삼았던 가설이다.

실측해보니 속도 면에서는 어느 정도 맞아떨어졌지만(DeepSeek이 가장 빨랐다), 메모리 사용량 관점에서는 이 가설이 틀렸다.

계산에 쓰는 파라미터 ≠ 메모리에 올려야 하는 파라미터

MoE 모델이 “일부 파라미터만 쓴다"는 건 매 토큰의 계산량에 대한 이야기다. 그런데 어떤 토큰에서 어떤 expert가 선택될지는 그 순간의 입력에 따라 동적으로 정해진다. 즉 이번 토큰에서 안 쓰인 expert가 다음 토큰에서는 쓰일 수 있다 — 결국 모든 expert가 언제든 호출될 수 있으므로, 전체 파라미터가 메모리에 상주하고 있어야 한다.

로컬 LLM 활용 두 가지 방식 — Aider 자율 코딩 vs MCP 위임, 왜 둘 다 써도 되는가

Thu, 15 Oct 2026 07:55:00 +0900

로컬 LLM으로 코딩을 시켜보겠다고 마음먹었을 때, 실은 두 가지 서로 다른 활용 방식을 놓고 고민했다.

방식 A: Aider 자율 코딩

터미널에서 Aider를 실행하고, 프롬프트 하나로 파일 생성·수정·테스트·커밋까지 로컬 모델이 알아서 처리하게 하는 방식이다. yes-always 옵션으로 확인 프롬프트까지 다 꺼두면, 사람은 결과만 나중에 확인하면 된다. 지금까지 이 블로그 시리즈에서 다룬 벤치마크 테스트가 전부 이 방식이었다.

방식 B: MCP를 통한 위임

Claude Code 세션 안에서 작업을 하다가, 특정 하위 작업만 로컬 모델에 “던지고” 결과를 받아오는 방식이다. Claude Code가 메인 오케스트레이터 역할을 하고, 로컬 LLM은 도구(tool) 중 하나로 취급된다. 이걸 위해 mcp-local-llm MCP 서버를 소스에서 직접 빌드해 붙였다(이 과정은 앞선 글에서 다뤘다).

로컬 LLM을 외부에 노출해도 될까 — 전용 서브도메인 구상과 포기 이유

Wed, 14 Oct 2026 10:05:00 +0900

이미 휴대폰 API 주소를 Cloudflare Tunnel 서브도메인으로 열어 서버를 하나 운영하고 있다 보니, 자연스럽게 이런 생각이 들었다. “아이맥의 로컬 LLM도 전용 서브도메인으로 열어두면, 어디서든 접근할 수 있어서 더 편하지 않을까?”

같은 기기 안에서는 이득이 없다

먼저 따져야 했던 건 “누가, 어디서 이 로컬 LLM에 접근하는가"였다. 지금 계획대로라면 Aider든 MCP 서버든, 호출하는 쪽도 결국 같은 아이맥 안이다. localhost:11434로 바로 붙으면 되는 걸 굳이 인터넷을 한 바퀴 돌아서(Cloudflare Tunnel → DNS → 다시 내 아이맥) 접근할 이유가 없다. 오히려 왕복 지연만 늘어난다.

Aider로 한국어 페어프로그래밍 하기 — .aider.conf.yml 설정 가이드

Tue, 13 Oct 2026 08:00:00 +0900

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을 터미널 밖에서 쓰기 — VS Code 연동 옵션 비교 (Cline vs Continue)

Mon, 12 Oct 2026 22:00:00 +0900

로컬 LLM 파이프라인을 Aider 중심으로 터미널에서 굴리다 보니, 당연한 질문이 떠올랐다. “이거 VS Code 안에서는 못 쓰나?” 매번 터미널과 에디터를 오가는 것도 번거롭고, 코드를 눈으로 보면서 바로 지시하고 싶은 순간이 많았기 때문이다.

로컬 모델은 특정 도구 전용이 아니다

먼저 짚고 넘어가야 할 게 있다. Ollama가 localhost:11434에 띄우는 API는 OpenAI 호환/Ollama 자체 API를 따르는 범용 엔드포인트다. 즉 Aider 전용이 아니라, 이 API를 호출할 수 있는 도구라면 뭐든 붙을 수 있다는 뜻이다. 그래서 VS Code 확장 중에서도 로컬 Ollama를 지원하는 것들을 찾아보면 된다.

왜 CPU 로컬 LLM 코딩 파이프라인을 포기했는가 — 속도, 일관성, 그리고 이미 있던 대안

Sat, 10 Oct 2026 21:50:00 +0900

앞선 글들에서 인텔 아이맥에 로컬 코딩 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배 차이 나고, 심지어 요청하지 않은 기능을 마음대로 추가했다. 이건 “느리다"가 아니라 “결과물을 매번 처음부터 검토해야 한다"는 뜻이다. 무인 파이프라인의 핵심 전제 — 사람이 개입하지 않아도 일정 수준의 결과가 보장된다는 것 — 이 자체가 깨진 셈이다.

같은 프롬프트, 네 가지 로컬 코딩 모델 — 계산기 테스트로 본 실제 속도와 신뢰성

Fri, 09 Oct 2026 22:15:00 +0900

설치를 마쳤으니 이제 실측이다. 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는 흥미로운 실패 방식을 두 개나 보여줬다.

npm 패키지에 내 아키텍처용 바이너리가 없을 때 — MCP 로컬 LLM 서버를 소스로 빌드하기

Thu, 08 Oct 2026 21:15:00 +0900

로컬 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가 내부적으로 어떤 명령을 실행하는지 직접 눈으로 확인해야 했다.

2026년 인텔 맥에서 Homebrew가 막혔다 — Ollama와 Aider를 우회 설치한 기록

Wed, 07 Oct 2026 14:20:00 +0900

로컬 LLM 파이프라인을 만들려고 첫 삽을 뜨자마자 예상 못 한 벽에 부딪혔다. Homebrew가 Intel Mac 설치 자체를 거부한다.

Homebrew on macOS is only supported on Apple Silicon processors!

Homebrew 공식 문서에는 Intel Mac이 여전히 “Tier 3” 지원 대상으로 적혀 있는데, 실제 설치 스크립트는 이미 하드 블록을 걸어놨다. GitHub Discussion #7088을 뒤져보니, 2026년 9월 17일자로 메인테이너가 직접 남긴 댓글에서 이게 버그가 아니라 의도된 정책이라고 확인해준다. 문서와 실제 동작이 따로 노는 셈인데, 이미 결정된 정책이라니 우회할 수밖에 없었다.

인텔 아이맥으로 로컬 코딩 LLM 파이프라인을 계획하다 — 하드웨어 한계와 모델 후보 선정

Tue, 06 Oct 2026 20:05:00 +0900

집에 있는 구형 인텔 아이맥이 눈에 밟혔다. 3GHz 6코어 i5, Radeon Pro 570X 4GB, 32GB DDR4 — 일반 업무용으로는 여전히 충분한 사양인데, 놀고 있는 게 아깝다는 생각이 들었다. 마침 로컬 오픈소스 LLM으로 코딩 보조 파이프라인을 만들어보고 싶었던 참이라, 이 아이맥을 실험대로 삼기로 했다.

목표는 단순했다. 로컬 LLM이 코드 초안을 자동으로 작성하고, Claude Code가 그 결과를 검증·수정·커밋하는 2단계 파이프라인을 만드는 것. “결과만 정확하면 시간이 오래 걸려도 괜찮다"는 전제를 깔고 시작했다.

GPU 가속, 기대는 접어야 했다

가장 먼저 확인한 건 Radeon Pro 570X로 추론을 가속할 수 있는지였다. 결론부터 말하면 불가능이다.