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

규모를 키우면 답이 없다

테스트에 쓴 작업은 계산기 함수 4개, 출력 코드량으로 치면 100줄이 채 안 된다. 실제로 다루는 프로젝트 코드는 수천 줄 단위다. CPU 추론에서 시간을 잡아먹는 건 대부분 **decode(토큰을 한 개씩 순차 생성하는 단계)**이고, prefill(기존 코드를 읽어들이는 단계)은 상대적으로 빠르다. 문제는 새 코드를 대량으로 “생성"해야 하는 작업일수록 decode 비중이 커진다는 점이다.

계산기 테스트에서 역산한 대략적인 속도로 2000줄 규모 신규 코드 생성을 추정해보면:

  • DeepSeek-Coder-V2-16B: 대략 1.5~3시간
  • Qwen3-Coder-30B: 대략 6~10시간
  • Qwen2.5-Coder-14B: 대략 8~12시간 이상

심지어 이 추정도 낙관적이다. Aider의 auto-lint 재시도(reflection) 루프는 실패할 때마다 누적된 컨텍스트를 통째로 다시 읽어들여야 해서, 재시도가 반복될수록 시간이 거의 제곱에 가깝게 늘어난다. 실제로 14B 테스트에서는 재시도가 이어지며 컨텍스트가 9,080 토큰에서 11,517 토큰으로 불어나는 걸 직접 확인했다. 그리고 파일이 커질수록 SEARCH/REPLACE 방식의 실패율(모델이 기존 코드를 정확히 재현하지 못하는 문제)도 함께 올라간다 — 즉 시간만 느는 게 아니라 완주할 확률 자체가 떨어진다.

이미 있던 대안이 더 합리적이었다

사실 이 파이프라인이 하려던 일 — “초안은 다른 모델이 만들고, Claude Code가 검증·정리한다” — 은 이미 다른 방식으로 하고 있었다.

  • 기존 코드 수정: Claude Code에 바로 요청
  • 신규 서비스 프로토타입: Gemini Pro 웹에서 생성 → 수동으로 git에 업로드 → Claude Code가 검토

차이는 딱 하나, 초안을 만드는 주체가 로컬 CPU가 아니라 클라우드의 Gemini Pro라는 점이다. 그런데 이 차이가 전부를 바꾼다. 대규모 GPU 클러스터에서 도는 모델이라 수백 줄 코드도 수 분 안에 나오고, 신뢰성도 로컬 4B~30B급 모델과는 비교가 안 된다. 로컬 LLM 파이프라인이 노렸던 “돈 안 들이고 시간으로 때운다"는 트레이드오프 자체가, 실측해보니 시간이 실용적 한계를 넘어서면서 무의미해진 것이다.

남은 명분들도 하나씩 소거됐다

혹시 남는 쓸모가 있을까 싶어 몇 가지를 따져봤다.

  • Claude 사용량 한도 방어용? — 월 20달러 Pro 플랜에서 한도에 자주 걸려 110달러 Max 플랜으로 옮긴 상태였는데, Max로 옮긴 뒤로는 한도에 걸린 적이 없다. 방어할 게 없다.
  • Pro 플랜으로 돌아갈 때를 위한 보험? — 주간 한도는 며칠 안에 리셋되는데, 실제 코드 규모(수천 줄)를 로컬로 돌리면 그보다 오래 걸릴 수 있다. 한도가 풀릴 때까지 기다리는 게 로컬로 돌리는 것보다 빠를 수 있다는 뜻이라, 보험으로서도 의미가 약하다.
  • 외부로 못 보내는 컴플라이언스 코드용? — 지금은 해당 사례가 없다. 다만 이건 속도 문제가 아니라 “보낼 수 있느냐"의 문제라, 실제로 그런 코드가 생기면 유일한 재고 대상이 된다.

최종 결론

설치했던 Ollama, Aider, 모델 파일들은 디스크 용량 여유가 있어 그냥 남겨뒀다. 하지만 로컬 LLM 코딩 파이프라인 프로젝트 자체는 여기서 종료한다. 재검토할 시점이 있다면, GPU를 갖춘 PC나 미니 서버를 새로 구축했을 때일 것이다 — 그때는 오늘 겪은 CPU 병목 자체가 사라지니, 이번에 익힌 Aider/Ollama/MCP 설정 지식이 고스란히 재사용될 것이다.