로컬LLM on Simon의 AI 시대에 살아남는 법

로컬 LLM 코딩 파이프라인, 17편을 돌아보며

Fri, 23 Oct 2026 19:00:00 +0900

놀고 있던 인텔 아이맥 하나로 시작한 실험이 어느새 17편짜리 시리즈가 됐다. 하드웨어 한계를 확인하는 글로 시작해서, Homebrew 설치 차단, MCP 바이너리 부재, 네 개 모델 실측 비교, 그리고 결국 프로젝트를 접기로 한 결정까지 — 매 단계에서 부딪힌 벽과 우회로를 그때그때 기록해뒀다.

돌아보니 남는 것

시리즈를 마치고 다시 훑어보면, 이 프로젝트에서 진짜 값진 건 “로컬 LLM 파이프라인을 완성했다"는 결과가 아니라 왜 안 되는지를 실측으로 확인한 과정 쪽이었다. GPU 가속이 안 된다는 걸 처음부터 알고도 CPU로 밀어붙였고, 그 판단이 얼마나 순진했는지는 재현성 테스트(같은 모델, 같은 프롬프트인데 소요 시간이 2.4배 벌어지고 요청하지 않은 함수까지 추가된 사례)에서 명확하게 드러났다. 결론을 성급하게 내리지 않고 두 번째 실행까지 검증해본 덕분에, “빠르고 안정적인 모델"이라는 잘못된 결론으로 파이프라인을 그대로 밀어붙이는 일은 막을 수 있었다.

Aider도 병목이 될 수 있을까 — repo-map과 컨텍스트 크기가 속도에 미치는 영향

Wed, 21 Oct 2026 11:10:00 +0900

지금까지의 벤치마크에서 속도 문제는 대부분 모델 추론(CPU 바운드 decode) 탓으로 돌렸다. 그런데 문득 이런 의문이 들었다. “Aider 자체는 병목이 아닐까? 모델한테 뭘 보내는지, 그 준비 과정 자체가 느린 건 아닐까?”

Aider가 매 턴마다 하는 추가 작업

Aider는 단순히 사용자 프롬프트만 모델에 던지지 않는다. 매 요청마다 다음과 같은 부가 작업이 들어간다.

1. repo-map 생성 프로젝트 전체 구조를 파악해서, 지금 대화와 관련 있을 법한 파일·함수 목록을 요약한 “지도"를 만든다. 이 작업은 tree-sitter라는 파서를 이용해 코드를 구문 분석하는 방식으로 이뤄진다. 프로젝트가 작을 땐(이번 테스트의 계산기 모듈처럼) 무시할 만한 수준이지만, 파일 수가 많은 대형 저장소에서는 이 repo-map 생성 자체에 시간이 걸릴 수 있다.

미니PC로 로컬 LLM 서버를 살까 고민한 기록 — Ryzen 9 6900HX vs Ryzen 7 5825U

Mon, 19 Oct 2026 07:10:00 +0900

로컬 코딩 LLM 파이프라인을 인텔 아이맥으로 실험하기 전, 사실 “그냥 이 목적으로 미니PC를 새로 하나 사는 게 낫지 않을까"도 진지하게 고민했다. 결국 사지 않기로 했지만, 그 과정에서 비교했던 내용을 기록으로 남긴다.

왜 미니PC를 고려했나

가장 먼저 배제한 건 유휴 휴대폰(갤럭시 퀀텀2)이었다. 로컬 LLM을 돌리기엔 RAM이 4-6GB로 너무 작고, 발열·배터리 제약도 있어 초당 1~3토큰 수준의 속도밖에 안 나올 것으로 판단했다. 그렇다면 남는 선택지는 기존 인텔 아이맥을 쓰거나, 이 용도로 새 기기를 사는 것 두 가지였다.

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

인텔 아이맥으로 로컬 코딩 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로 추론을 가속할 수 있는지였다. 결론부터 말하면 불가능이다.