로컬 LLM 도입기: 21일간 6개 모델을 테스트하다

이런 고민, 로컬 LLM에 관심있으신 분들이라면 한 번쯤 해보셨을 거예요.

저도 같은 고민을 하다가 직접 부딪히는 게 가장 빠른 길이라는 결론에 이르렀어요. 지난 약 21일 동안 6개 모델을 실제로 돌리고 4단계에 걸쳐 실험하고, 에이전트에 연동하고, 실운용 과정에서 예상치 못한 변수들과 씨름한 결과를 오늘 공유하려고 합니다.

결론부터 말씀드리면, 이 여정은 아직 끝나지 않았어요. 모델 선정으로 끝날 것 같았던 작업이 메모리 제약, 동시 구동 한계, 에이전트 교체 검토까지 이어지고 있습니다. 오늘 글은 "이렇게 하면 됩니다"가 아니라 "저는 지금 이 과정을 지나고 있습니다"라는 현재진행형 보고서예요.

이번 글에서는 로컬 LLM을 검토하는 조직이라면 반드시 부딪히게 될 세 가지 — 왜 로컬 LLM인가, 어떻게 모델을 고를 것인가, 실운용에서 무엇이 달랐나 — 를 중심으로 이야기합니다.

1. 왜 지금 로컬 LLM인가 — 의존도의 리스크를 직면하다

저는 회사에서 자사 웹서비스 자동 유지보수 시스템의 핵심 엔진으로 쓸 AI를 찾고 있었어요. 클라우드 AI 서비스를 그대로 연동하는 것이 가장 빠른 길이었지만, 선뜻 그렇게 하기 어려운 이유가 생겼습니다.

[WHY] 지금 당장 로컬 LLM을 검토해야 하는 이유는 무엇인가요?

출처: CIO

2026년 5월 현재, Anthropic은 Agent SDK를 기존 구독 상품에서 분리해 별도 크레딧 과금으로 전환하는 정책을 6월 15일부터 적용하겠다고 발표했습니다. 제가 주로 쓰는 Claude Code는 Pro 구독 사용자 대상에서 일시 제외됐다가 철회된 사례도 있었죠.

개별 정책 변경보다 더 본질적인 불안은 이겁니다. 지금의 AI 출혈 경쟁이 언제까지 이어지리란 보장이 없다. 글로벌 AI 기업들이 시장 점유를 위해 저렴한 요금으로 경쟁하는 지금의 국면이 끝나는 순간, 요금은 급격히 재조정될 수 있어요. 그때 AI를 포기할 수 없다면, 지금부터 대안을 준비해야 한다는 판단이었습니다.

로컬 LLM의 이점은 세 가지입니다.

[HOW] 로컬 LLM 도입 결정을 어떻게 내릴 수 있나요?

1) "클라우드에 올리기 꺼려지는 업무" 목록을 먼저 뽑아보세요. 고객 DB 분석, 미공개 소스코드 리뷰, 내부 계약서 검토, 경쟁사 분석 자료 처리 — 이런 업무들이 있다면, 그 목록 자체가 로컬 LLM 도입의 근거가 됩니다. 비용 계산보다 이 목록을 먼저 만드는 게 맞는 순서예요.

2) 정책 리스크를 현실적으로 평가해 보세요. 현재 쓰고 있는 AI 서비스의 요금이 2배, 3배, 5배 오른다면 어떻게 할 건지 시나리오를 그려보세요. "그래도 계속 쓸 것"이라면 요금 상한이 어디인지, "못 쓸 것"이라면 대안이 있는지를 지금 생각해두는 게 좋습니다.

3) 소규모 파일럿으로 진입 장벽을 직접 확인하세요. ollama.com에서 Ollama를 설치하고 ollama pull gemma4:26b 명령어를 입력하면 모델을 받을 수 있어요. M 시리즈 맥북 프로 이상이면 지금 당장 구동해볼 수 있습니다. 자기 팀 실무 질문 3개를 던져보는 것만으로도 "이게 우리한테 되는 기술인가"를 체감할 수 있어요.

2. 6개 모델, 4단계 검증 — 벤치마크보다 실전이 달랐다

그래서 저희는 PoC를 진행해 보기로 했습니다.

PoC 환경은 Mac Studio M4 Max 36GB RAM(약 320만 원), 백엔드는 Ollama 0.23.2, 에이전트는 Hermes입니다. 6개 최종 후보 모델을 4단계에 걸쳐 검증했어요.

[PoC 4단계 검증 구조]

[WHY] 왜 학계 벤치마크가 아닌 자체 기준으로 검증했나요?

공개된 벤치마크는 일반적인 능력을 측정하지만, 실제 업무에서 AI가 "쓸 만한가"를 측정하지는 않습니다. 저는 Hermes 에이전트와 연동해서 실제로 쓸 수 있는가를 기준으로 직접 검증했어요. 7가지 테스트 항목(T1~T7: 지시 준수, 코드 생성, 코드 디버깅, 다단계 추론, 긴 문맥 처리, 한국어 품질, JSON 구조화 출력)으로 평가하되, Hermes 연동 필수 조건 3가지(지시 준수 Pass, JSON 출력 Pass, 긴 문맥 핵심 항목 탐지 Pass)를 충족하는지를 확인했어요.

1단계 기본 성능 테스트 결과는 이렇습니다:

Hermes 연동 필수 조건을 모두 충족한 모델은 5개. Granite 4.1만 JSON 출력과 긴 문맥 탐지 필수 조건을 통과하지 못해 연동 보류 판정을 받았습니다.

그런데 이 점수표만으로는 알 수 없는 것들이 있었어요.

실제 서버에서 구동했을 때의 변수도 고려해야 했거든요. 결국에는 메모리 이슈로 양자화 모델에 대한 재테스트를 수행했습니다.

양자화 모델에 대한 정보는 언슬로 다이나믹(Unsloth Dynamic)이라는 곳을 참고했습니다.

https://unsloth.ai/

양자화 모델이란 쉽게 말해 '경량화'모델을 의미해요. 성능과 어느정도 트레이드 오프하는 경우가 있기는 하지만, 메모리 부하로 인한 속도 저하가 이슈일때 고려해 볼 수 있는 대안입니다.

그리고 마지막으로는 실사용 시나리오 몇 개를 추가 테스트했어요. 실제 업무에서 쓴다고 가정했을 때 항상 정제된 프롬프트로 AI에게 지시하는 것이 아니기 때문에 이런 테스트도 필요하다고 판단했기 때문입니다. 

그리고 마지막으로 다음 단계인 실운용에서 인프라 이슈를 마주하며, 최종 테스트를 수행했어요. 

3. 모델 선정 이후 — 실운용에서 여정은 계속됐다

결과적으로는 Gemma 4 26B 4비트 양자화모델을 최종 선정했습니다. Gemma 4 31.3B 모델이 앞선 테스트에서 25점 만점에 25점을 받았는데 왜 최종 모델이 아닌지 궁금하시죠?

실제로 돌려보니 새로운 변수들이 기다리고 있었기 때문입니다.

[WHY] 실운용 단계에서 왜 추가 변수가 생기나요?

첫 번째 벽은 메모리였어요. Mac Studio M4 Max의 RAM은 36GB지만, macOS의 시스템 캡으로 인해 LLM이 실제 사용할 수 있는 메모리는 약 24GB입니다. Hermes 에이전트와 OpenWebUI를 동시에 구동하면 메모리가 초과됩니다. 결국 단일 모델 운용으로 전환했어요.

두 번째 벽은 속도였습니다. 1단계에서 최고점(25/25)을 받은 Gemma 4 31.3B — 실운용해보니 응답 시간이 1~2분 수준이었어요. 에이전트 파이프라인에서 허용하기 어려운 속도입니다.

현재 세팅은 Gemma 26B Q4 (Unsloth Dynamic) + KV캐시 4비트 적용으로, 메모리 여유 약 15GB를 확보한 상태입니다.

세 번째는 프론트엔드 레이어입니다. 현재 기존 Hermes에서 OpenClaw 교체를 검토 중입니다. 테스트 결과 OpenClaw는 응답 시간이 1~3분으로, 기존 Hermes의 7~12분 대비 개선됐어요. 아직 최종 결정은 내리지 않았습니다.

이상적인 스펙은 64GB RAM이지만, 비용 문제로 현재 업그레이드는 미루고 있습니다. 로컬 LLM 도입은 모델 선정으로 끝나지 않아요. 메모리 관리, 인프라 레이어 선택, 에이전트 연동 안정성 — 이것들이 모두 실운용의 일부입니다.

사실 이 상황이 처음엔 당황스러웠어요. "모델만 고르면 되는 거 아닌가"라고 생각했는데, 실제 환경은 훨씬 복잡한 변수들이 얽혀 있었거든요. 그런데 지나고 보니, 이 과정 자체가 정보였어요. 직접 부딪히지 않으면 알 수 없는 것들이요.

[HOW] 실운용 단계의 변수를 어떻게 대비할 수 있나요?

1) RAM 스펙을 액면 그대로 믿지 마세요. 36GB라고 해서 36GB를 모두 LLM에 쓸 수 없어요. macOS 환경이라면 시스템 캡 이후 실가용 메모리가 약 24GB 수준임을 감안해서 모델 크기와 양자화 수준을 정하세요. 30B급 Full 정밀도 모델을 단독 구동하려면 64GB RAM이 현실적입니다.

2) 에이전트, 프론트엔드, 모델을 한 번에 붙이지 마세요. 컴포넌트를 하나씩 추가하면서 메모리와 속도를 측정하는 것이 문제 진단을 훨씬 쉽게 만들어요. 에이전트 단독 → 에이전트 + 모델 → 에이전트 + 모델 + 프론트엔드 순서로 순차적으로 통합하고, 각 단계에서 안정성을 확인하세요.

3) 프롬프트 최적화로 경량 모델의 한계를 보완하세요. 하드웨어 업그레이드 이전에 Q4 또는 Q2 양자화 모델 + 프롬프트 설계로 성능을 끌어올리는 방법을 먼저 시도해보세요. 이 테스트에서 [자체 점검] 패턴 하나가 Q2 모델의 실패를 성공으로 뒤집었어요. 어떤 AI든 복잡한 요청 끝에 "위 답변을 다시 검토하고 빠진 항목이 있으면 추가해줘"를 붙여보세요.

마무리: 로컬 LLM 도입은 모델 선정으로 끝나지 않는다

이번 글에서 이야기한 세 가지를 정리합니다.

첫째, 왜 지금 로컬 LLM인가 — 클라우드 AI의 정책 리스크가 현실화되고 있습니다. 보안·안정성·비용 세 이유로 지금 로컬 LLM을 준비할 근거가 생겼어요.

둘째, 어떻게 모델을 고를 것인가 — 자기 팀 실무 지표가 학계 벤치마크보다 중요하고, 모델 점수와 에이전트 연동 가능성은 반드시 별도로 검증해야 합니다.

셋째, 실운용에서 무엇이 달랐나 — 36GB RAM의 실가용 메모리는 24GB. 모델 선정은 시작일 뿐, 메모리·인프라·프론트엔드까지 실운용 변수로 다뤄야 해요.

저도 아직 이 여정 한가운데 있어요. OpenClaw vs Hermes 최종 결정, 메모리 최적화, 실운용 안정화 — 아직 풀어야 할 과제가 남아 있습니다. 같은 고민을 하고 있는 분이라면, 함께 부딪혀 나가는 동료가 여기 있다는 것을 기억해 주세요. 여러분의 첫 걸음을 응원합니다.

감사합니다.

📬 오늘의 레터는 어떠셨나요?

여러분의 소중한 피드백은 제게 큰 힘이 됩니다. 오늘 레터가 도움이 되셨다면 따뜻한 응원의 댓글이나 의견을 남겨주세요! 여러분의 생각 하나하나가 모여 더 깊이 있는 뉴스레터를 만듭니다.