개발 일지

로컬 코딩 LLM 파이프라인을 인텔 아이맥으로 실험하기 전, 사실 “그냥 이 목적으로 미니PC를 새로 하나 사는 게 낫지 않을까"도 진지하게 고민했다. 결국 사지 않기로 했지만, 그 과정에서 비교했던 내용을 기록으로 남긴다. 왜 미니PC를 고려했나 가장 먼저 배제한 건 유휴 휴대폰(갤럭시 퀀텀2)이었다. 로컬 LLM을 돌리기엔 RAM이 4-6GB로 너무 작고, 발열·배터리 제약도 있어 초당 1~3토큰 수준의 속도밖에 안 나올 것으로 판단했다. 그렇다면 남는 선택지는 기존 인텔 아이맥을 쓰거나, 이 용도로 새 기기를 사는 것 두 가지였다.

모델 후보를 고르는 과정을 돌아보다가 문득 이상한 점을 느꼈다. 검토했던 후보 — Qwen3-Coder, Qwen2.5-Coder, DeepSeek-Coder-V2 — 가 전부 중국 회사(알리바바, 딥시크)의 모델이었다. 의도한 건 아니었는데, 결과적으로 다양성이 전혀 없었던 셈이다. 왜 이렇게 됐나 솔직히 말하면 의도적인 선택이 아니라 벤치마크 점수 기준으로 좁히다 보니 자연스럽게 그렇게 됐다. HumanEval, MBPP 같은 코딩 벤치마크에서 로컬(7B~32B급) 규모의 오픈소스 모델 중 상위권을 차지하는 게 최근 Qwen·DeepSeek 계열에 쏠려 있는 게 현실이다. 그럼 다른 나라 모델은 없나 찾아보면 분명히 있다. 정리하면 이렇다.

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 파이프라인 작업을 마무리하면서 뜻밖의 부산물을 하나 발견했다. 작업 중이던 대화창 상단에 계속 “Simon’s iMac · 연결됨"이라는 표시가 떠 있었던 것이다. 처음엔 대수롭지 않게 넘겼는데, 자세히 보니 이 대화에만 뜨고 다른 대화에는 안 뜨는 걸 알아챘다. 왜 이 대화에만 떴을까 원인은 명확했다. 이 세션 초반, 아이맥에 Ollama/Aider를 설치하려고 ~/Projects 폴더에 접근 권한을 요청했고, 그 요청을 승인했던 것이다. 그 승인 자체가 “이 대화(작업)와 이 컴퓨터를 연결” 시키는 액션이었다. 즉 이건 계정 전체에 걸리는 설정이 아니라, 대화(세션) 단위로 부여되는 권한이다. 다른 대화에서는 이런 폴더 접근 요청을 한 적이 없으니 연결 표시도 뜨지 않는 것이다.