새 로컬 LLM이 나왔다 - 결국 시간에 따라 나눠 쓰기로 했다

로컬 LLM을 최대한 활용하고 싶었다. 이미 Qwen을 쓰고 있었지만, 마침 비슷한 시기에 Muse Glimmer라는 새 모델이 나왔다. 새로운 모델이라는 이유로 바로 바꿀 수는 없었다. 내가 실제로 하는 일에서 어떤 모델이 더 잘 맞는지, 그리고 Codex와는 어떻게 나눠 쓸지가 궁금했다.

결론부터 말하면, 지금 결과가 필요하면 Codex를 쓰고, 기다려도 되는 일은 Qwen에 맡기는 방식이 가장 현실적이었다. 로컬 모델 중에서는 Qwen 3.8이 Muse보다 더 정확하지는 않았지만 같은 품질을 훨씬 짧은 시간에 냈다. 반면 Codex에서 시험한 클라우드 모델 Luna는 Qwen보다 약 2.5배 빨랐다. 정해진 시간표라기보다, 내가 결과를 기다리고 있는지에 따라 선택이 달라진다.

새 모델의 성능을 줄 세우는 것보다, 내 일을 누구에게 맡길지 정하는 것이 목적이었다.

새 모델이 나왔다고 바로 바꿀 수는 없었다

로컬 LLM의 가장 큰 매력은 비용이다. 이미 갖고 있는 컴퓨터를 기준으로 하면, 작업을 하나 더 맡겨도 API 요금은 0원이다. 전기료와 장비 가격까지 0원이라는 뜻은 아니지만, 매번 호출 비용을 신경 쓰지 않아도 된다는 점은 크다.

그렇다면 로컬 모델 사이의 핵심 선택 요소는 시간이다. 결과가 같다면 더 빨리 끝내는 모델이 더 많은 일을 맡을 수 있다. 반대로 클라우드는 빠른 대신 사용량에 따라 비용이 생긴다. 결국 확인하고 싶은 것은 단순했다.

• Qwen과 Muse 중 누가 내 일을 더 효율적으로 처리하는가?
• API 비용 0원은 얼마나 더 긴 대기 시간을 감수할 만한가?
• 시간을 사는 선택으로 클라우드 Codex를 언제 쓸 것인가?

AI의 도움을 받아 내 일과 닮은 시험을 만들었다

모델에게 아무 문제나 맡기고 비교하면 내 작업에 도움이 되는 결론을 얻기 어렵다. Codex의 도움을 받아 포트폴리오 개편에서 자주 만난 일을 여섯 개의 작은 시험으로 옮겼다.

• 태그를 같은 표현으로 정리하기
• 게임 상세의 위치와 상태를 바르게 보여주기
• 프로젝트 설명의 강조 표현을 바르게 노출하기
• 게임 목록에서 대표 태그만 요약하기
• 목록과 상세의 태그 규칙을 같게 맞추기
• 글의 이전·다음 탐색 순서를 바르게 맞추기

어떤 모델이든 같은 문제와 완료 기준을 받았다. 모델이 시험 정답을 바꾸거나 요청받지 않은 곳을 손대지 않았는지도 함께 봤다. 시험 결과는 내부 기호 대신, 실제로 무슨 일을 했는지로 정리했다.

로컬끼리 비교하면 Qwen 3.8이 조금 더 나았다

Qwen과 Muse는 모두 첫 시도에 여섯 개 작업을 전부 통과했다. 정답만 보면 우열을 가리기 어렵다. 하지만 전체 시간은 Qwen 407초, Muse 1,223초였다. Muse가 약 3배 더 오래 걸렸다.

그래서 “Qwen이 조금 더 좋았다”는 말은 품질이 더 높았다는 뜻이 아니다. API 비용이 둘 다 0원인 조건에서, 같은 품질을 더 짧은 시간에 냈다는 뜻이다. 이미 보유한 맥에서 반복적인 작업을 맡길 기본 모델로는 Qwen이 더 적합했다.

클라우드까지 비교하면 답은 달라진다

로컬 Qwen과 Codex의 클라우드 모델 Luna에게도 같은 여섯 작업을 맡겼다. 결과는 서로 다른 장단점을 보여줬다.

Qwen과 Muse는 API 비용 0원, Codex·Luna는 보완 시간까지 포함해도 Qwen보다 약 2.5배 빨랐다.

클라우드는 빨랐지만 첫 결과에서 하나를 놓쳤다. 현재 글에 시리즈가 없을 때, 같은 관점의 글이라면 후보 글 자체에 시리즈가 있어도 이전·다음 글로 잡아야 했는데, 이 조건을 처음에 빼먹었다. 정확한 지적 후 27초 만에 고쳤고 최종 결과는 모두 통과했다.

비용은 클라우드를 어떻게 쓰느냐에 따라 해석이 달라진다. 이번 시험은 Codex 계정 경로로 실행했기 때문에 0.038달러가 별도로 청구된 것은 아니다. 다만 사용한 토큰을 OpenAI의 GPT-5.6 Luna API 정가에 대입하면 약 0.038달러였다.

실제 일감을 더 넉넉하게 잡아 한 번에 500원이 든다고 해도, 업무 중 몇 분을 기다리고 다시 집중하는 비용과 비교하면 큰돈은 아니다. 반대로 내가 자리를 비운 뒤라면 Qwen이 몇 분 더 걸려도 내 시간은 거의 쓰이지 않는다. 이 차이가 모델 자체의 순위보다 실제 선택에 더 중요했다.

내 생활에 적용하면 이렇게 쓸 수 있다

업무 중에 결과를 바로 보고 다음 판단을 이어가야 한다면 Cloud가 자연스럽다. 퇴근할 때 범위와 완료 기준이 분명한 일이 남았다면 Qwen에 맡겨둘 수 있다. 다만 이것을 매일 지켜야 하는 시간표로 만들 필요는 없다.

업무 시간과 퇴근 이후는 이해하기 쉬운 예시일 뿐이다. 실제 기준은 지금 기다려야 하는지다.

퇴근 뒤 Qwen에 맡기기 좋은 일

퇴근 뒤에 맡기기 좋은 일은 질문 없이도 끝낼 수 있는 일이다. 큰 과제를 통째로 던져두기보다 다음 세 가지가 분명한 작은 작업이 맞다.

• 무엇을 바꿀지와 바꾸지 않을 범위
• 완료됐다고 판단할 조건
• 결과를 확인할 테스트나 점검 방법

코드 작업이라면 별도의 작업 공간에서 실행하고, 커밋·배포·게시처럼 되돌리기 어려운 일은 맡기지 않는다. 다음 날에는 Qwen의 설명만 믿기보다 실제 변경 내용과 테스트 결과를 확인한다. 중요한 작업이라면 그때 Codex로 한 번 더 검토하면 된다.

이 방식에서 로컬 LLM은 클라우드를 완전히 대체하지 않는다. 내가 기다려야 할 때는 Cloud가 시간을 아끼고, 기다리지 않아도 될 때는 로컬 모델이 남는 시간을 활용한다. Muse는 아직 별도의 고정 역할을 정하기보다, Qwen과 다른 결과가 필요한 상황에서 다시 시험해보는 편이 솔직하다.

별첨 - 실제 측정 결과

아래는 실험용 기호를 빼고 실제 작업 이름과 걸린 시간만 정리한 표다. Codex·Luna의 총시간은 마지막 작업의 27초 보완을 포함한다.

품질 판정은 “한 번 실행되는가”로 끝내지 않았다. 완료 조건을 모두 지켰는지, 요청하지 않은 파일을 바꾸지 않았는지, 숨겨진 경계 사례도 처리하는지까지 확인했다.

이 결과의 한계

이번 비교는 Apple M5 Max, 통합 메모리 128GB, oMLX 0.6.2, 8bit 로컬 모델이라는 한 환경에서 진행했다. Muse의 가속 기능은 꺼진 상태였다. 다른 장비나 설정에서는 속도 차이가 줄어들 수 있다.

또한 작고 정답이 분명한 코딩 작업을 중심으로 비교했다. 오랜 시간 이어지는 전면 개편, 모호한 디자인 판단, 실제 브라우저 조작은 이 수치만으로 판단할 수 없다. 따라서 이번 결론은 영구적인 순위가 아니라 현재 장비와 현재 작업에서 세 모델을 어떻게 나눠 쓸지에 대한 운영 기준이다.