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

방식 A: Aider 자율 코딩

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

방식 B: MCP를 통한 위임

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

왜 두 방식을 같이 써도 문제가 없는가

처음엔 “이 둘 중 하나만 골라야 하나"라고 생각했는데, 따져보니 그럴 필요가 없었다. 이유는 단순하다 — 두 방식 모두 결국 같은 Ollama 서버(localhost:11434)를 호출한다. Ollama는 한 번에 모델을 하나씩 메모리에 올려두고 서빙하는 구조라, Aider든 MCP 서버든 같은 엔드포인트에 요청을 보내면 순서대로 처리(직렬화)될 뿐 서로 충돌하지 않는다.

즉 상황에 따라 골라 쓰면 된다:

  • 완전히 새로운 모듈을 통째로 만들어야 할 때 → Aider로 자율 작업을 맡기고 자리를 비운다.
  • Claude Code로 작업하다가 부수적인 작은 작업(예: 간단한 유틸 함수 하나)만 로컬로 돌리고 싶을 때 → MCP로 그 부분만 위임한다.

다만 실제로는 방식 B까지 검증하지 못했다

이 프로젝트는 결국 CPU 속도와 재현성 문제로 접었기 때문에(다른 글에서 다룬 4개 모델 벤치마크와 최종 결론 참고), MCP 위임 방식을 실전 코딩 작업에 투입해서 검증하는 단계까지는 가지 못했다. 다만 두 방식이 아키텍처적으로 상호 배타적이지 않다는 걸 확인해둔 것만으로도, 나중에 GPU 환경에서 이 프로젝트를 재개할 때 처음부터 다시 고민할 필요는 없어졌다.