로컬 LLM은 AI API 비용을 얼마나 줄여줄까? Mac Studio와 RTX 5080 실측 후기

요즘 로컬 LLM 이야기가 부쩍 많이 보입니다.

예전엔 개인 컴퓨터에서 AI 모델을 돌린다고 하면 거의 실험 영역이었습니다. 설치도 까다롭고 속도는 처참했으며, 답변 품질도 엉성해서 "내 장비에서 텍스트가 출력된다"는 사실 자체에 의의를 두는 수준이었죠.

지금은 분위기가 꽤 달라졌습니다. Ollama, llama.cpp, Apple의 MLX 같은 가벼운 런타임이 대중화됐고, GGUF 포맷과 4bit 양자화 모델도 많아졌습니다. 이제는 Mac Studio나 고성능 RTX GPU가 있으면 경량 모델은 물론, 조건만 맞으면 20B~30B급 모델도 직접 테스트해볼 수 있는 환경이 됐습니다.

그래서 저도 직접 세팅하고 실측 테스트를 해봤습니다. 한 줄로 요약하면, 로컬 LLM은 분명 쓸 만합니다. 다만 상용 클라우드 AI를 완전히 대체하겠다는 목적으로 접근하면 기대와 현실 사이에서 꽤 실망하게 됩니다.

실제로 부딪혀보니 제일 잘 맞는 방식은 따로 있었습니다. 무거운 모델을 메인으로 억지로 올리는 게 아니라, 안정적인 경량 모델(예: SuperGemma E4B q6/q8)을 정해진 파이프라인 안에 묶어두고 좁은 역할만 맡기는 서브 에이전트 방식이었습니다.

1. 왜 로컬 LLM의 문을 두드렸는가

삽질을 시작한 이유는 세 가지였습니다.

잦은 LLM 사용. 언젠가부터 편리함 때문에 코드 스니펫 설명, 글 초안 작성, 텍스트 포맷팅, 간단한 요약처럼 자잘한 작업에 매번 상용 API를 호출하게 됐습니다. 그러다 보니 생각보다 토큰 소모가 컸고, 회사에서 Gemma4 모델 이후 작은 모델도 퀄리티가 꽤 좋다는 걸 보면서 로컬 LLM을 검토하게 되었습니다.

검열 없는 LLM 사용. 실제 작업에서 검열이 많이 발생하진 않지만, 개인적으로 검열 없는 모델에 대한 궁금증이 있었습니다. 이런 모델을 로컬에서 직접 다뤄보고 싶었습니다.

자동화 파이프라인. 최근 페르소나를 담은 다중 agent 구성을 재미삼아 진행 중인데, 가벼운 분류, 요약, 에러 로그 1차 필터링 정도는 내부 인프라에서 거의 공짜로 처리하는 구조를 만들고 싶었습니다.

이전에도 여러 번 돌려봤지만, 최근 작은 모델들의 성능이 꽤 올라오면서 실제 작업 흐름에서 클라우드 API 호출을 얼마나 줄여줄 수 있는지, 어느 선까지 믿고 맡길 수 있는지를 확인하는 게 목적이었습니다.

2. 하드웨어별 실측: 생각보다 잘 돌아가지만, 숫자의 함정이 있다

Mac Studio와 16GB VRAM의 RTX 5080 환경에서 각각 26B~35B 체급 모델들을 올리고 테스트했습니다. 여기서 중요한 건 "모델이 실행된다"와 "실제 작업에서 쾌적하다"가 전혀 다른 이야기라는 겁니다.

Mac Studio: Unified Memory의 여유, 그러나 아쉬운 속도

Mac Studio는 Unified Memory 구조 덕분에 VRAM이 분리된 일반 PC보다 메모리 운용에 여유가 있었습니다. 상대적으로 VRAM 여유가 있어 먼저 시도해보았습니다. 하지만 생각보다 실작업에서 만족할 만한 성능을 내주진 못했습니다.

• Qwen3.6-35B-A3B-4bit (MLX): 약 15.8 tok/s
• SuperGemma4-26B-4bit (MLX): 약 27.57 tok/s

간단한 질문 정도는 괜찮지만, 실시간 코딩 보조나 빠른 피드백이 필요한 작업에서 15 tok/s 안팎은 은근히 답답합니다. 브라우저, IDE, 로컬 개발 서버, 터미널을 동시에 띄워놓고 일하는 평소 환경에서 이 체급 모델을 메인으로 상시 쓰기엔 무리가 있었습니다.

RTX 5080: 16GB VRAM이지만 Offload로 실행

속도가 생각보다 아쉬워 윈도우 RTX 5080으로 돌려봤습니다. 사실 5080의 경우 GPU 연산 성능은 강력하지만 16GB VRAM은 26B~35B급 모델을 통째로 올리기엔 턱없이 부족합니다. 대신 GPU + 시스템 RAM 분할 Offload로 설정해 가능한 부분은 GPU에 올리고, 나머지는 시스템 메모리에 나눠 실행해보았습니다.

Mainline llama.cpp 환경에서 --fit on 옵션과 f16 KV Cache 조합을 적용했을 때 Context Depth별 실측치입니다.

옵션만 잘 맞물리면 196K 컨텍스트에서도 59.4 tok/s가 나왔습니다. 실용 속도로는 충분합니다.

다만 데스크탑에서 그래픽이 거의 풀 로드로 동작하니 열기가 나오는 것도 있고, 현재 구조가 Mac Studio를 24시간 동작시키는 구조라 RTX 5080까지 24시간 돌리기엔 전기세가 Crof 같은 저렴한 상용 모델보다 더 나올 것 같아 의미가 없었습니다.

3. 체급과 양자화(q-bit)의 딜레마

테스트하면서 맞닥뜨린 두 번째 장벽은 답변 품질의 일관성 문제였습니다.

대부분 작은 모델의 높은 양자화보다 큰 모델의 낮은 양자화가 더 낫다고 이야기해서, 큰 모델을 굴리기 위해 메모리 타협으로 주로 q4(4bit 양자화)를 선택했습니다. 그런데 실제로 써보니 큰 모델의 q4 양자화가 기대만큼 안정적이지 않았습니다. 단발성 질문에는 그럴싸하게 답하다가도 추론이 조금만 복잡해지면 논리가 뭉개지거나 컨텍스트가 꼬였습니다.

반면 체급을 낮춰서 SuperGemma E4B 같은 경량 모델을 q6나 q8로 올렸을 때는 느낌이 달랐습니다.

• 대형 모델 + q4: 메모리 압박은 심한데 압축 손실까지 겹쳐서, 조금만 복잡해지면 답변 품질이 흔들립니다.
• 소형 모델 + q6/q8: 원본 특성이 잘 유지돼서, 범위가 좁은 작업에서는 생각보다 안정적입니다. 메모리 부담도 거의 없습니다.

물론 작은 모델은 복잡한 설계 판단을 내리지 못합니다. 하지만 짧은 요약, 코드 조각 설명, 로그 분류처럼 범위가 좁은 작업에서는 어설픈 대형 q4 모델보다 작은 q6/q8 모델이 서브 용도에 훨씬 잘 맞았습니다.

4. 핵심: 자유 대화가 아닌 파이프라인 안의 서브 에이전트

큰 모델의 q4 양자화는 품질이 흔들릴 뿐 아니라 실사용하기 어려운 속도였습니다. 반대로 작은 모델의 q8 양자화는 빠르고 품질이 일관되지만, 추론 한계가 있는 단점이 있었습니다. 그래서 최소한의 역할만 맡기는 방식으로 전환했습니다. 모델을 자유롭게 대화시키는 게 아니라, 입력/출력 형식과 작업 순서를 미리 정해둔 파이프라인 안에서만 쓰는 방식입니다.

로컬 LLM에게 열린 질문을 던지거나 하네스로 묶지 않으면, 그럴듯하지만 기대한 퀄리티의 답변이 나오지 않는 한계가 금방 드러납니다. 그런데 정해진 역할에 하네스를 추가하면 기대보다 훨씬 잘 작동합니다.

거시적 계획 수립과 최종 검증은 상용 클라우드(GPT/Claude)에 맡기고, 저의 경우는 Crof를 사용합니다. 실패 비용이 낮으면서 손이 많이 가는 중간 반복 작업은 로컬 LLM이 처리하는 구조입니다.

일반적인 코딩 시 역할 분담 구조

이 구조에서 로컬 LLM은 전체를 설계하는 역할이 아니라, 파이프라인 중간에서 반복 작업을 받아 처리하는 쪽입니다.

로컬에 잘 맞는 명령과 그렇지 않은 명령을 구분하면 이렇습니다.

잘 맞는 쪽: "검색 스킬로 리서치해서 요약한 뒤 JSON으로 뽑아줘.", "지금 작업한 내용을 커밋 스킬로 나눠서 커밋 진행해줘."

버거운 쪽: "이 프로젝트 전체 아키텍처 보고 확장 전략 설계해줘.", "파일 간 의존성 고려해서 최적 리팩터링 계획 세워줘."

5. 로컬 LLM 도입을 고민하는 이들을 위한 가이드

직접 써본 결과, 잘 맞는 상황과 그렇지 않은 상황은 꽤 명확합니다.

특히 하드웨어를 새로 사서 API 비용을 아끼려는 목적이라면 계산을 먼저 해봐야 합니다. 하드웨어 감가상각, 전기세, 세팅 시간, 모델 튜닝 시간까지 포함하면 그냥 상용 API를 쓰는 게 더 합리적인 경우가 많습니다.

최종 결론: 아직은 클라우드 절약 도구다

로컬 LLM을 깊게 파보고 내린 결론은 간단합니다.

일반 장비 보유자에겐 클라우드를 완전히 대체하기는 어렵고, 클라우드를 더 영리하게 덜 쓰기 위한 도구입니다.

물론 M5 Max라던가 3090 × 2, 5090 × 2 단계로 가면 27B 모델들도 더 양호하게 돌릴 순 있겠지만, 그 장비 비용과 전기세를 고려하면 아직은 저렴한 LLM을 구독하는 게 훨씬 낫습니다.

다만 단순 반복 작업을 처리하는 서브 에이전트로 역할을 좁히면, 비용과 안정성 사이에서 꽤 괜찮은 균형을 찾을 수 있습니다.

자잘하고 반복적인 태스크(요약, 분류, 초안 작성, 자료조사)는 내 장비에서 비용 부담 없이 빠르게 처리하고, 복잡한 판단(계획 수립, 품질 리뷰)은 상용 API를 쓰는 것. 지금 시점에서 개인 개발자가 취할 수 있는 가장 현실적인 방식은 이 하이브리드 분업 구조라고 생각합니다.

• #AI API 비용
• #llama.cpp
• #LLM 벤치마크
• #Mac Studio
• #MLX
• #Ollama
• #RTX 5080
• #로컬 LLM