애플 실리콘 맥은 CPU와 GPU가 메모리를 공유합니다. 로컬 LLM을 무턱대고 실행하면 시스템 전체가 멈추는 이유입니다. 특히 16GB 모델에서 LLM이 가용 자원을 전부 점유하면 VS Code나 웹 브라우저가 버벅거리기 시작합니다. oMLX를 단순한 실행기가 아니라 실제 개발 도구로 쓰려면 OS가 숨 쉴 구멍부터 만들어야 합니다.
시스템 프리징을 막는 메모리 제한 설정
로컬 LLM 프로세스가 RAM을 무한정 쓰도록 두면 안 됩니다. macOS 커널과 IDE 언어 서버가 사용할 최소한의 여유 공간이 필요합니다. oMLX 구동 시 max-process-memory 플래그를 사용해 상한선을 강제로 그어야 합니다.
- 방법: 터미널에서 oMLX 실행 시
--max-process-memory 0.65옵션을 붙입니다. 16GB 모델 기준 약 5.6GB를 시스템용으로 남겨두는 설정입니다. 8GB 모델이라면 이 값을0.5까지 낮추고 3B 이하 모델을 써야 합니다. - 결과: 모델 추론 중에도 VS Code의 입력 지연 시간이 200ms 이내로 유지됩니다. 활성 상태 보기의 메모리 압력 그래프가 빨간색으로 변하며 시스템이 굳는 현상을 방지합니다.
Continue 확장을 활용한 API 연결
oMLX를 터미널에서만 쓰는 건 반쪽짜리 활용입니다. VS Code 확장 프로그램인 Continue를 연결해 실제 코딩 흐름에 태워야 합니다. 이때 무거운 모델 하나에 모든 걸 맡기지 말고, 용도에 따라 모델을 분리하는 게 핵심입니다.
- 방법: Continue의
config.json에서provider를openai로,apiBase를http://localhost:8000/v1로 지정합니다. 대화형에는 7B~9B 모델을 쓰더라도,tabAutocompleteModel항목에는qwen2.5-coder-1.5b-mlx같은 경량 모델을 따로 할당합니다. - 결과: 월 20달러의 구독료를 아끼면서 10ms 수준의 빠른 코드 자동완성을 경험할 수 있습니다.
SSD 수명을 위한 전용 볼륨 할당
oMLX는 메모리가 부족하면 KV 캐시를 SSD로 보냅니다. 그런데 시스템 루트 볼륨에 이 작업이 반복되면 I/O 부하가 커지고 장기적으로 SSD 수명에 좋지 않습니다. APFS 컨테이너 기능을 써서 AI 작업용 공간을 물리적으로 격리하는 편이 현명합니다.
- 방법: 디스크 유틸리티에서
AI_Storage라는 이름의 APFS 볼륨을 추가합니다. 예약 크기를 20GB로 잡아 용량을 확보한 뒤, oMLX 실행 시--paged-ssd-cache-dir /Volumes/AI_Storage/cache옵션으로 경로를 고정합니다. - 결과: 대규모 프로젝트 분석 시 발생하는 I/O 병목이 줄어듭니다. 시스템 드라이브의 단편화를 막아 맥북의 전반적인 반응 속도를 보호합니다.
uv를 이용한 독립 실행 환경 구축
MLX 기반 도구들은 파이썬 의존성 충돌이 잦습니다. pip로 이것저것 설치하다 보면 기존 프로젝트 환경이 망가지기 일쑤입니다. Rust로 만든 패키지 매니저 uv를 쓰면 이 문제를 깔끔하게 해결합니다.
- 방법:
curl -LsSf [https://astral.sh/uv/install.sh](https://astral.sh/uv/install.sh) | sh로 uv를 설치한 뒤,uv venv --python 3.12로 독립 환경을 만듭니다. 이후uv pip install omlx[mcp]를 입력해 필요한 라이브러리를 한 번에 설치합니다. - 결과: 환경 설정에 들이는 시간을 1분 내외로 단축합니다. 나중에 모델을 업데이트하거나 패키지가 꼬여도 가상환경 폴더만 지우면 그만이라 관리가 편합니다.
oMLX는 llama.cpp보다 전력 효율이 높고 생성 속도도 빠르지만, 제어하지 않으면 시스템 자원을 독식합니다. RAM의 40%는 OS에게 양보하고 SSD I/O를 격리하는 설정만으로도 충분히 쾌적한 로컬 AI 개발 환경을 만들 수 있습니다. 수치상의 벤치마크보다 내 맥북이 버티는 실질적인 설정값이 훨씬 중요합니다.
