코딩용 로컬 LLM 사용은 이제 그만두렵니다

지난 몇 주 동안 업무 외적인 기술 작업에 로컬 모델을 강제로 사용해보며 충분히 기회를 줬다고 생각합니다. 저는 직장에서 Claude Code를 사용하고 있어서 그것과 비교를 해봤습니다.

저는 수백억 파라미터 미만의 로컬 모델 중 최고로 꼽히는 Qwen 27B와 Gemma 4 31B를 사용했습니다. 여러 에이전트 앱도 시도해봤고요. 결론은 생산성 손실이 얻는 이점보다 크다는 것입니다.

주요 문제점들을 간략히 정리해 보겠습니다.

엉망인 의사결정과 도구 호출

이게 가장 큽니다. Claude는 대부분 제 마음을 읽는 것 같은데, Qwen 27B는 저를 어이없게 만드는 경우가 너무 많습니다. LLM이 제가 진행하려는 방식대로 움직이지 않아요.

저는 주로 OS/Docker 작업에 로컬 LLM을 사용했습니다. 이게 코딩보다 훨씬 어려운 작업인가요?

예를 들어, "여기 Github 저장소가 있는데, Dockerize 해줘." 같은 작업 말입니다. 저는 어떤 멍청이라도 README 지침을 따라 실행할 거라 기대합니다. (EDIT: 전체 프롬프트는 여기 있습니다: https://reddit.com/r/LocalLLaMA/comments/1sxqa2c/im_done_with_using_local_llms_for_coding/oiowcxe/ )

'docker build'가 기본 타임아웃보다 오래 걸리면, 작업이 실패한 것처럼 간주하고 엉뚱한 후속 조치를 취합니다. 작업이 여전히 실행 중인지 확인하는 대신 말이죠. Qwen은 무슨 일이 일어나는지 보려고 호스트(Ubuntu)에서 설치 명령어를 다시 실행하려고 했습니다. 출력값을 확인하는 대신 그냥 "torchcodec 때문에 실패했을 거야"라고 멋대로 단정 짓더군요.

모델과 타협도 해봤습니다. AGENTS.md에 이렇게 적어뒀죠: "Docker 빌드 명령어 등 디버그 출력이 많을 것 같은 명령어를 실행할 때는 다음을 수행할 것: 1. 메인 컨텍스트가 오염되지 않도록 서브 에이전트에서 실행할 것, 2. 출력을 임시 파일로 파이프하여 나중에 tail과 grep으로 참조할 수 있게 할 것." 그런데도 두 번이나 250k 입력 토큰이 쌓인 망가진 세션으로 돌아왔습니다. LLM이 'docker build'나 'docker compose up'의 모든 출력을 읽고 있었기 때문이죠.

LLM을 프로그래밍 가능한 로봇처럼 다루며 긴 프로토콜을 제공하는 거대한 AGENTS.md들이 있다는 건 알지만, 저는 그런 건 시도하지 않았습니다. 솔직히 그런 것들 중 어느 것도 'docker build'의 출력을 읽지 말라는 식의 세부 사항까지는 다루지 않더군요. 저는 제가 사용한 에이전트 앱의 기본 프롬프트와 AGENTS.md에 몇 가지 가이드라인만 추가해서 사용했습니다.

성능

LLM이 느릴 뿐만 아니라, 어떤 앱을 사용하든 프롬프트 캐시가 자주 깨지는 것 같습니다. 즉, 아무 일도 일어나지 않는 긴 멈춤 현상이 발생합니다.

Claude Code의 경우, LLM의 출력을 사용자에게 보여주지 않기 때문에 상황이 더 악화됩니다. 제가 종종 Qwen Code를 선호했던 이유 중 하나죠. 결과가 나빠 보이는 것뿐만 아니라, 빠른 피드백을 받지 못하는 건 매우 답답합니다.

배우는 게 없음

Chat Completions 서버의 URL을 바꾸는 것 외에는 로컬 LLM을 사용하는 것과 클라우드 모델을 사용하는 것 사이에 차이가 없습니다. 그냥 고생만 더 할 뿐이죠.

LLM 프롬프팅을 배우면서 얻는 경험은 분명히 있습니다. 하지만 코딩 작업은 작은 모델들에게는 너무 어려운 것 같습니다. 마치 하드코어 모드로 게임을 하는 것 같아요. 저는 학습 곡선에서 적절한 지점을 찾고 있는데, 이건 그럴 가치가 없습니다.

이제 어떻게 할 것인가

코딩과 OS 관련 작업은 OpenRouter에 돈을 좀 쓰고 Kimi 같은 대형 모델들을 독점적으로 사용할 생각입니다. 한 모델이 짜증 나게 하면 다음 모델로 넘어가면 되니까요. 마음에 드는 모델을 찾으면 비용 절감을 위해 연간 플랜에 가입할 겁니다.