맥 미니 한 대로 로컬 LLM 서버 굴리기, 어디까지 실용적인가

애플 실리콘의 통합 메모리 구조가 성숙해지면서, 값비싼 GPU 서버 없이도 데스크톱급 기기에서 대형 언어 모델을 상시 구동하려는 시도가 늘고 있다. 한 개발자가 공개한 사례는 48GB 램을 탑재한 M4 Pro 맥 미니 한 대를 항상 켜 두고, 이를 개인 에이전트의 백엔드이자 휴대폰·노트북에서 접속하는 공용 추론 서버로 쓰는 구성이다. 셋업에 걸리는 시간은 약 30분이라고 한다. 화려한 기술이라기보다는, 클라우드 API에 대한 의존을 줄이려는 실무적 선택에 가깝다.

왜 로컬로 돌리는가

저자가 꼽는 첫 번째 이유는 통제권이다. 클라우드 API는 '임대한 땅'과 같아서 가격 정책, 사용량 한도, 심지어 뒤에서 서빙되는 모델 자체가 예고 없이 바뀔 수 있다는 것이다. 그는 월 200달러짜리 구독 두 개를 정기적으로 한도까지 소진하면서도, 같은 서비스가 시점에 따라 다른 품질을 내놓는다는 인상을 받았다고 말한다. 어떤 때는 멀쩡하던 모델이 아무 공지 없이 성능이 떨어지는 식이다. 두 번째는 데이터 프라이버시로, 민감한 코드나 고객 데이터, 독점 워크플로를 제3자 API로 보내는 것은 한 번 내리면 되돌릴 수 없는 결정이라는 지적이다. 세 번째는 이른바 'AI 주권' 문제다. 정부가 특정 모델의 배포를 제한할 수 있고, 그런 일이 언제 어떤 이유로 벌어질지 사용자는 통제할 수 없으므로, 이를 피하는 유일한 방법은 연산 자원을 직접 소유하는 것이라고 본다.

다만 그의 목표는 API 모델을 완전히 대체하는 것이 아니다. GPT-5나 Claude Opus급이 반드시 필요하지 않은, 하루 요청의 대다수를 로컬이 무료로 처리하게 하고 정작 고성능이 필요할 때는 클라우드를 그대로 쓴다는 분업이다. 이 균형 감각이 이 셋업을 비현실적인 이상론이 아니라 참고할 만한 사례로 만든다.

파라미터 수가 아니라 실제 메모리 점유가 관건

소비자용 하드웨어에서 대형 모델을 돌릴 수 있느냐는 결국 램에 얼마나 올라가느냐로 귀결된다. 여기서 저자가 강조하는 것이 밀집(dense) 모델과 전문가 혼합(MoE) 모델의 차이다. 밀집형 27B 모델은 270억 개 파라미터가 모든 토큰마다 램에 상주하지만, MoE 모델은 사정이 다르다. 예로 든 Qwen3.6-35B-A3B는 총 350억 파라미터가 256개 전문가로 나뉘어 있으나 토큰당 실제로 활성화되는 것은 약 30억뿐이고, 나머지는 램에 올라간 채 대기한다. 그 결과 48GB 맥 미니에서 이 모델을 4비트로 돌리면 약 20GB를 차지해, 남은 28GB를 컨텍스트 창과 운영체제 등에 쓸 수 있다.

이 차이는 저사양 기기에서 더 극적으로 드러난다. 저자의 지인이 쓰던 16GB 맥북 에어에서는 밀집형 27B 4비트가 약 14GB를 요구해 사실상 기기 전체를 잡아먹고, 결국 SSD로 스왑이 일어나며 사용이 고통스러워진다. 반면 같은 35B급 MoE 모델은 토큰당 활성 가중치가 30억 수준이라 6B 밀집 모델 정도의 실효 메모리만 쓰므로 오히려 무리 없이 얹힌다는 설명이다. 파라미터 총량만 보고 가늠하면 정반대의 결론에 이를 수 있다는 점이 실무적으로 중요하다. 가벼운 작업용으로는 2.4GB 남짓한 Gemma-4-E4B 같은 소형 모델을 함께 두어, 20GB짜리 모델을 굳이 쓸 필요 없는 요청을 처리하게 한다.

양자화 품질에 대해서도 구체적인 수치를 제시한다. 35B-A3B 모델을 4비트로 압축했을 때 무압축 기준인 BF16 대비 대부분의 벤치마크에서 1~2점 정도만 손실된다는 것이다. 70GB에 달할 메모리 요구를 48GB로 낮추는 대가로는 받아들일 만하다는 판단이다. 다만 이는 저자가 인용한 특정 도구와 모델에 한정된 관찰이며, 모델과 작업 종류에 따라 편차가 있을 수 있다는 점은 감안해야 한다.

여러 기기를 하나의 백엔드로 묶기

이 구성이 단일 기기 실험에 그치지 않는 이유는 네트워크 설계에 있다. Tailscale로 맥 미니, 아이폰, 맥북을 하나의 사설 메시 네트워크로 묶어 공개 인터넷에는 아무것도 노출하지 않는다. 추론 서버는 8000번 포트에서 대기하고, 맥의 Raycast, iOS의 Apollo, 맥북의 데스크톱 클라이언트가 모두 같은 엔드포인트를 바라본다. 기기별로 설정이 어긋날 여지가 없다는 점이 장점으로 꼽힌다. 에이전트 백엔드는 맥 미니에서 돌고, 휴대폰에서는 Telegram으로, 노트북에서는 데스크톱 앱을 '셸'처럼 붙여 접속하므로 대화 기록과 스킬셋을 모든 기기가 공유한다.

에이전트 작업에서 특히 의미 있는 부분은 KV 캐시의 디스크 영속화다. 코딩 에이전트는 한 세션 안에서 앞선 컨텍스트를 반복적으로 되짚는데, 각 블록을 SSD에 캐싱해 두면 이전 프리픽스로 돌아갈 때 재계산 대신 밀리초 단위로 복원할 수 있다. 이 덕분에 로컬 셋업이 실제 에이전트 작업에 쓸 만해진다는 것이다. 모델 교체도 관리 대시보드의 허깅페이스 브라우저에서 내려받아 재시작하는 수준으로 간단하고, CLI와 SSH로도 처리할 수 있어 어느 기기에서든 관리가 가능하다.

저자는 이미 128GB M5 Max 맥 스튜디오를 주문해 둔 상태지만 현재의 M4 Pro 맥 미니 성능에 만족한다고 밝힌다. 결국 이 사례가 던지는 메시지는 분명하다. 애플 실리콘에서의 로컬 모델은 더 이상 곁다리 실험이 아니며, 로컬과 API 모델의 격차가 코딩·추론·도구 사용 영역에서 빠르게 좁혀지고 있다는 것이다. 다만 이 구성은 상당한 램을 갖춘 애플 실리콘 기기를 전제로 하고, 등장하는 도구와 모델 이름 상당수가 특정 생태계에 묶여 있다는 점에서 그대로 이식하기보다 자기 하드웨어 사양에 맞게 모델을 바꿔 적용하는 접근이 현실적이다.