Aider

지금까지의 벤치마크에서 속도 문제는 대부분 모델 추론(CPU 바운드 decode) 탓으로 돌렸다. 그런데 문득 이런 의문이 들었다. “Aider 자체는 병목이 아닐까? 모델한테 뭘 보내는지, 그 준비 과정 자체가 느린 건 아닐까?” Aider가 매 턴마다 하는 추가 작업 Aider는 단순히 사용자 프롬프트만 모델에 던지지 않는다. 매 요청마다 다음과 같은 부가 작업이 들어간다. 1. repo-map 생성 프로젝트 전체 구조를 파악해서, 지금 대화와 관련 있을 법한 파일·함수 목록을 요약한 “지도"를 만든다. 이 작업은 tree-sitter라는 파서를 이용해 코드를 구문 분석하는 방식으로 이뤄진다. 프로젝트가 작을 땐(이번 테스트의 계산기 모듈처럼) 무시할 만한 수준이지만, 파일 수가 많은 대형 저장소에서는 이 repo-map 생성 자체에 시간이 걸릴 수 있다.

Aider를 실행할 때마다 새 버전이 있다는 안내가 떴다. 안내를 따라 자체 업그레이드를 진행했는데, 완료 메시지에는 분명 0.86.2로 올라갔다고 나왔다. 그런데 이후 aider --version을 찍어보면 여전히 이렇게 나왔다. $ aider --version aider 0.82.3 큰 문제로 이어지진 않았지만, 왜 이런 불일치가 생겼는지는 짚고 넘어갈 만하다. 의심되는 원인들 1. 여러 개의 pip/python 경로 공존 pip install --user aider-chat으로 설치했는데, 시스템에 Python 경로가 여러 개 있는 환경(macOS는 특히 Xcode Command Line Tools의 Python, Homebrew Python, python3.9 등이 뒤섞이기 쉽다)이라면, 업그레이드 명령이 실행되는 pip과 실제로 PATH에서 먼저 잡히는 aider 실행파일이 서로 다른 설치본을 가리킬 가능성이 있다.

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

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 파이프라인을 설치하고, 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 파이프라인을 만들려고 첫 삽을 뜨자마자 예상 못 한 벽에 부딪혔다. Homebrew가 Intel Mac 설치 자체를 거부한다. Homebrew on macOS is only supported on Apple Silicon processors! Homebrew 공식 문서에는 Intel Mac이 여전히 “Tier 3” 지원 대상으로 적혀 있는데, 실제 설치 스크립트는 이미 하드 블록을 걸어놨다. GitHub Discussion #7088을 뒤져보니, 2026년 9월 17일자로 메인테이너가 직접 남긴 댓글에서 이게 버그가 아니라 의도된 정책이라고 확인해준다. 문서와 실제 동작이 따로 노는 셈인데, 이미 결정된 정책이라니 우회할 수밖에 없었다.

집에 있는 구형 인텔 아이맥이 눈에 밟혔다. 3GHz 6코어 i5, Radeon Pro 570X 4GB, 32GB DDR4 — 일반 업무용으로는 여전히 충분한 사양인데, 놀고 있는 게 아깝다는 생각이 들었다. 마침 로컬 오픈소스 LLM으로 코딩 보조 파이프라인을 만들어보고 싶었던 참이라, 이 아이맥을 실험대로 삼기로 했다. 목표는 단순했다. 로컬 LLM이 코드 초안을 자동으로 작성하고, Claude Code가 그 결과를 검증·수정·커밋하는 2단계 파이프라인을 만드는 것. “결과만 정확하면 시간이 오래 걸려도 괜찮다"는 전제를 깔고 시작했다. GPU 가속, 기대는 접어야 했다 가장 먼저 확인한 건 Radeon Pro 570X로 추론을 가속할 수 있는지였다. 결론부터 말하면 불가능이다.

지난 글에서 잠깐 언급했던, Gemini 원격 코딩 어시스턴트를 만들면서 겪은 설치 문제를 이번 글에서 자세히 다룹니다. 최신 환경이 오히려 발목을 잡는, 은근히 자주 마주치는 종류의 문제였습니다. 증상: 기본적인 패키지 설치가 안 된다 aider를 설치하려고 하니 의존 패키지 중 하나가 설치 단계에서 실패했습니다. 에러 메시지를 따라가 보니 distutils.msvccompiler를 찾을 수 없다는 식의, 파이썬 빌드 도구 체인과 관련된 에러였습니다. numpy처럼 오래되고 널리 쓰이는 과학계산 라이브러리조차 순순히 설치되지 않았습니다. 원인: 너무 최신 파이썬 이 환경의 기본 파이썬 버전은 3.14였습니다. 최신 버전을 쓰는 것 자체는 보통 좋은 일이지만, 이번엔 오히려 문제가 됐습니다. distutils는 오래전부터 파이썬 표준 라이브러리에서 단계적으로 제거되어 온 모듈이고, 여러 과학계산·빌드 관련 패키지들이 이 모듈에 의존한 채로 아직 최신 파이썬 버전에 맞춰 업데이트되지 않은 상태였습니다. 결과적으로 “너무 최신이라서” 오래된 패키지들과 호환이 깨지는, 흔치 않지만 실제로 마주치면 당황스러운 상황이었습니다.