모든 Mac 사용자가 이 새로운 AI 모델 러너(oMLX)를 사용해야 하는 이유

한국어العربية Deutsch English Español Français हिन्दी Bahasa Indonesia 日本語 Português Русский 中文

컴퓨터/소프트웨어가전제품/카메라AI/미래기술

Transcript

00:00:00이것은 OMLX입니다. 정말 흥미로운 프로젝트인데요, 본질적으로는 애플 실리콘의

00:00:06성능을 마지막 한 방울까지 짜내기 위해 설계된 특화된 추론 엔진입니다.

00:00:11Mac 사용자라면 이번 영상에 매우 열광하실 겁니다. OMLX는 기본적으로

00:00:16로컬 하드웨어의 가장 큰 병목 현상인 '메모리 세금' 문제를 해결하려 합니다.

00:00:21이번 영상에서는 OMLX가 어떻게 작동하는지 살펴보고, 직접 테스트를 진행하며

00:00:27강자인 LM Studio와 비교하여 이 새로운 도구가 Mac에서 로컬 AI 모델을 실행하는

00:00:33미래가 될 수 있을지 확인해 보겠습니다. 아주 재미있을 테니 바로 시작하죠.

00:00:39그렇다면 OMLX란 정확히 무엇일까요? 핵심은 애플의 MLX 프레임워크를 기반으로

00:00:49구축된 런타임이라는 점입니다. 모든 GPU를 지원하려는 범용 도구와 달리,

00:00:55MLX는 Mac을 구동하는 통합 메모리 아키텍처를 활용하도록 애플 실리콘 팀이 직접 제작했습니다.

00:01:02전통적인 PC에서는 CPU와 GPU의 메모리 풀이 분리되어 있어서,

00:01:09모델 가중치 같은 데이터를 PCI 버스를 통해 끊임없이 주고받아야 합니다.

00:01:16하지만 MLX는 이러한 복사 과정을 완전히 제거합니다. CPU와 GPU가 동일한 물리적

00:01:22메모리를 공유하기 때문에 '제로 카피(Zero-copy)' 배열을 사용하죠. GPU가 계산을 마치면

00:01:29CPU는 단 1바이트의 이동 없이 즉시 결과를 읽을 수 있습니다. 또한 지연 계산을 사용하여

00:01:36출력이 필요한 마지막 순간까지 수학 연산을 실행하지 않음으로써,

00:01:41실시간으로 전체 계산 그래프를 최적화합니다. 하지만 일반적인 LM Studio 설정과 다른 점은

00:01:47KV 캐시를 관리하는 방식입니다. 일반적인 LLM 세션에서는 대화 내역의 모든 단어를

00:01:54비싼 RAM에 기억해야 합니다. 하지만 OMLX는 2계층 시스템을 도입했습니다.

00:02:01속도를 위해 즉각적인 컨텍스트는 통합 메모리에 유지하지만, 오래된 대화 내용이나

00:02:07방대한 시스템 프롬프트 및 도구 정의는 동결하여 SSD로 스왑합니다.

00:02:12LM Studio와 비교해보면 그 차이는 즉각적입니다. LM Studio는 안정적이고 호환성이 좋지만,

00:02:19문제는 전체 메모리 이력을 '핫 상태(Hot state)'로 유지하려 한다는 점입니다.

00:02:23OMLX는 현대적인 운영 체제와 더 비슷합니다. 어떤 데이터가 당장 뇌(RAM)에 있어야 하고

00:02:30어떤 것을 디스크로 페이징할 수 있는지 알 정도로 똑똑하죠. 그럼 OMLX를 실행해서

00:02:36직접 사용해 봅시다. 인터페이스는 꽤 직관적입니다. 시작하자마자

00:02:41서버 위치를 지정하고 바로 실행할 수 있는 창이 뜹니다. 그다음,

00:02:47API 키를 입력하라는 메시지가 나오는데, 입력해 보죠. 마지막으로

00:02:53OMLX 서버의 메인 진입점인 대시보드에 도달하게 됩니다. 여기에서 저는

00:03:00테스트에 사용할 Qwen 2.5 35B 파라미터 4비트 모델을 미리 다운로드했습니다.

00:03:07또한 agents.md 파일이 포함된 빈 저장소를 설정해 두었는데요, 여기에 모델에게

00:03:13영화 DB API 키를 사용하여 영화를 검색하고, 찜하고, 평점을 매길 수 있는

00:03:19간단한 웹 앱을 만들어 달라고 요청할 겁니다. 시연용이라 복잡하진 않지만,

00:03:24실제 코딩 작업에서 어떤 성능을 보여줄지 확인하기 위한 테스트입니다. 대시보드 페이지에는

00:03:31실행 가능한 다양한 AI 에이전트 하네스용 코드 스니펫을 제공하는 섹션이 있습니다.

00:03:37이번 데모에서는 테스트를 진행하기 위해 'codex' CLI를 사용하겠습니다.

00:03:42왜 공식 'Claude Code' CLI를 사용하지 않는지 궁금하실 텐데요. 사실

00:03:47MacBook M2에서는 토큰 하나하나가 중요합니다. Claude의 컨텍스트 통계를 보면,

00:03:54아무것도 없는 백지 상태에서도 Claude Code는 시스템 프롬프트와 도구 정의만으로

00:04:02약 16.2K 토큰을 잡아먹습니다. 32K 윈도우 환경에서는 실제 프로젝트에 사용할 수 있는

00:04:09토큰이 16K뿐인데, 풀스택 앱을 만들기엔 턱없이 부족하죠. 반면에

00:04:14codex는 훨씬 가볍다는 것을 발견했습니다. 대화의 기본 무게를 부풀리지 않아

00:04:20컨텍스트 한계에 부딪히기 전까지 코드를 작성할 수 있는 여유가 더 생깁니다.

00:04:26좋습니다, 이제 제공된 간단한 명령어로 codex를 실행해 보겠습니다.

00:04:31그런 다음 작업을 설명하는 간단한 시작 프롬프트를 주고 시작합니다.

00:04:36오른쪽에서 작업이 진행되는 동안, 이 세션이 실시간으로 어떻게 수행되는지,

00:04:42얼마나 많은 토큰이 생성되고 캐싱되는지, 그리고

00:04:46전체적인 캐시 효율성을 확인할 수 있습니다. 초당 평균 몇 개의 토큰이

00:04:51처리되는지 보는 것도 매우 유용하죠. 전체적으로 제 M2 MacBook Pro에서

00:04:5735B Qwen 2.5 모델이 이 작업을 완료하는 데 약 20분이 걸렸습니다.

00:05:04이 모델에게는 매우 무거운 작업이기 때문에 예상된 결과입니다. 도중에

00:05:10프롬프트가 M2 MacBook의 30K 컨텍스트 제한을 초과하여 400 에러가 두세 번 발생했습니다.

00:05:17다른 도구였다면 프로젝트가 완전히 중단될 상황이었을 겁니다. 보통 '/clear'를 실행하면

00:05:24AI의 단기 기억이 삭제되어, 방금 쓴 코드도 잊어버리고 환각 현상을 일으키곤 하죠.

00:05:29하지만 여기서 OMLX의 지속적인 SSD 캐싱 기능이 저를 놀라게 했습니다.

00:05:37codex에서 세션을 비웠음에도 불구하고, 프로젝트의 실제 계산 상태는

00:05:42여전히 SSD에 남아 있었습니다. 그래서 codex에 중단된 지점부터 계속하라는 새 프롬프트를 주자,

00:05:48OMLX는 접두사를 인식하고 즉시 디스크에서 모델의 '뇌'를 복구했습니다.

00:05:56환각을 일으키거나 처음부터 다시 시작하는 대신, 멈춘 곳에서 바로 이어갔죠. 캐시 효율성이

00:06:02이런 경우에 정말 큰 도움이 됩니다. 작업이 끝날 무렵 확인해 보니, Qwen 2.5는

00:06:08OMLX의 도움으로 178만 개의 토큰을 쏟아내며 작업을 마쳤고, 그중 약 159만 개가

00:06:16캐싱되었습니다. 89%라는 엄청난 캐시 효율성을 기록한 것이죠. 결과물인 앱도

00:06:22꽤 괜찮아 보입니다. 영화를 검색하고, 와치리스트에 추가하고, 평점을 매길 수 있습니다.

00:06:28다만 페이지를 새로고침하면 와치리스트가 초기화되네요. 아마 데이터베이스 저장

00:06:33솔루션을 제대로 구현하지 못한 것 같지만, 전반적으로 훌륭한 시도였습니다.

00:06:40이 모든 것이 인상적이지만, LM Studio와 같은 헤비급 모델 러너와 비교했을 때

00:06:46성능이 어느 정도인지 궁금했습니다. 그래서 동일한 Qwen 2.5 모델로

00:06:52같은 컨텍스트 윈도우와 제약 조건을 사용해 같은 작업을 실행해 보았습니다. 솔직히

00:06:58예상치 못했지만, LM Studio에서 오히려 더 안 좋은 성능이 나왔습니다. 작업 자체는

00:07:04완료하는 데 약 35분이 걸렸습니다. OMLX보다 이미 15분이나 더 걸린 셈이죠.

00:07:11또한 작업을 실행하는 동안 LM Studio는 제 MacBook의 모든 자원을 끌어다 썼습니다.

00:07:17심각한 RAM 부족으로 렉이 걸려 보조 모니터로 영상조차 볼 수 없을 정도였죠.

00:07:23OMLX를 사용할 때는 그런 문제가 없었습니다. OMLX에서는 codex가

00:07:30백그라운드에서 실행되는 동안 웹 서핑을 하거나 영상을 보는 등 다른 작업을 쉽게 할 수 있었죠.

00:07:35하지만 LM Studio에서는 거의 불가능했습니다. 통계를 한 번 보세요. 더욱

00:07:41놀라운 점은 LM Studio의 평균 초당 토큰 생성 속도가 16 tokens/s였다는 것입니다.

00:07:47반면 OMLX는 약 47이었죠. 작업 시간이 15분이나 더 걸린 이유가 여기서 설명됩니다.

00:07:55하지만 인정할 건 인정해야겠죠. LM Studio는 OMLX처럼 컨텍스트 제한으로 인한

00:08:01400 에러를 단 한 번도 발생시키지 않았습니다. LM Studio의 컨텍스트 관리는 매우 안정적이고

00:08:08완벽하게 작동하더군요. 최종 결과물을 봐도 매우 비슷했습니다. 이번에는

00:08:13화려한 애니메이션은 없었지만, 솔직히 같은 모델로 같은 작업을 수행하고 시드값만

00:08:18다른 결과를 비교하는 느낌이었습니다. 따라서 성급한 결론은 내리지 않겠습니다.

00:08:25동일한 Qwen 2.5 모델이니까요. Qwen 모델의 출력물은 직접 판단해 보시기 바랍니다.

00:08:33그럼 최종 판결은 어떨까요? 저는 OMLX의 성능에 매우 깊은 인상을 받았습니다.

00:08:39제한된 RAM의 MacBook을 사용하면서 백그라운드에서 로컬 AI 에이전트를 돌리는 동안에도

00:08:45컴퓨터를 계속 사용하고 싶다면 OMLX가 완벽한 도구입니다. 고속 SSD와

00:08:52애플 실리콘에서 모델을 더 매끄럽게 실행해 주는 MLX 프레임워크를 결합해 실질적인 RAM 확장을 제공하죠.

00:08:58물론 가끔 발생하는 400 에러 때문에 더 세심한 관리가 필요하고 때로는

00:09:05'clear' 명령어를 써야 할 수도 있습니다. 하지만 생성 속도가 3배나 빠르다는 점을 생각하면

00:09:10충분히 감수할 만한 가치가 있다고 생각합니다. 결론적으로 OMLX 같은 프로젝트들은

00:09:16강력한 에이전트를 실행하기 위해 반드시 128GB의 RAM이 필요한 것은 아니라는 점을 증명합니다.

00:09:23단지 우리가 이미 가진 MacBook의 메모리를 관리하는 더 똑똑한 방법이 필요할 뿐이죠.

00:09:29실제로 몇 달 전 설문조사를 해보니 시청자 대부분이 Mac 사용자이시더라고요.

00:09:34그래서 여러분의 의견이 궁금합니다. 직접 OMLX를 사용해 보셨나요? 사용 경험은

00:09:40어떠셨나요? 아래 댓글 섹션에 남겨주세요. 자, 여기까지입니다.

00:09:45이것이 요약된 OMLX의 모습입니다. 여러분, 이런 기술적인 분석이 마음에 드셨다면

00:09:50영상 아래의 '좋아요' 버튼을 꼭 눌러주세요. 그리고 저희 채널 구독도 잊지 마시고요.

00:09:55지금까지 Better Stack의 Andris였으며, 다음 영상에서 뵙겠습니다.

Key Takeaway

oMLX는 SSD 스왑 기술과 MLX 프레임워크 최적화를 통해 32GB 이하의 RAM을 가진 MacBook에서도 대규모 모델을 3배 빠른 속도로 구동하며 멀티태스킹 환경을 보장합니다.

Highlights

oMLX는 애플 실리콘 전용 MLX 프레임워크를 기반으로 구축되어 CPU와 GPU가 동일한 메모리를 공유하는 제로 카피(Zero-copy) 아키텍처를 활용합니다.
M2 MacBook Pro 환경에서 35B 파라미터 규모의 Qwen 2.5 모델을 실행했을 때 oMLX는 초당 47개 토큰을 생성하며 LM Studio의 16개보다 3배 빠른 속도를 기록했습니다.
통합 메모리의 부족한 용량을 해결하기 위해 즉각적인 컨텍스트는 RAM에 유지하고 오래된 대화나 시스템 프롬프트는 SSD로 스왑하여 관리하는 2계층 시스템을 도입했습니다.
코딩 테스트 결과 oMLX는 178만 개의 토큰을 처리하는 동안 89%의 캐시 효율성을 달성하며 SSD에서 모델의 계산 상태를 즉시 복구했습니다.
LM Studio는 동일 작업 수행 시 35분이 소요되어 oMLX보다 15분 더 걸렸으며 시스템 자원 독점으로 인해 다른 백그라운드 작업이 불가능한 수준의 렉이 발생했습니다.

Timeline

애플 실리콘 최적화와 제로 카피 아키텍처의 원리

애플 실리콘 팀이 직접 제작한 MLX 프레임워크는 통합 메모리 구조를 극대화하도록 설계되었습니다.
CPU와 GPU 간의 데이터 복사 과정이 없는 제로 카피 배열을 통해 데이터 이동 지연을 제거합니다.
지연 계산 방식을 채택하여 출력이 필요한 마지막 순간까지 연산을 미뤄 전체 계산 그래프를 실시간으로 최적화합니다.

일반적인 PC 환경은 CPU와 GPU의 메모리가 분리되어 있어 PCI 버스를 통한 데이터 전송 병목 현상이 발생합니다. oMLX는 이러한 물리적 한계를 동일 메모리 공유 방식으로 해결합니다. 연산이 필요한 시점에만 계산을 수행하여 불필요한 자원 낭비를 방지하는 구조를 갖추고 있습니다.

SSD 스왑을 활용한 효율적인 KV 캐시 관리 시스템

비싼 RAM 자원을 보존하기 위해 활성 컨텍스트와 비활성 데이터를 분리하여 관리합니다.
오래된 대화 내역이나 방대한 시스템 프롬프트 데이터는 동결 처리되어 SSD로 저장됩니다.
운영 체제의 페이징 기법과 유사하게 필요한 데이터만 메모리 핫 상태로 유지하여 효율을 높입니다.

LM Studio와 같은 기존 도구는 전체 대화 이력을 메모리에 상주시키려 하므로 RAM 부족 현상이 빈번하게 발생합니다. oMLX는 지능적인 데이터 분류를 통해 당장 필요한 정보는 RAM에, 나머지는 디스크에 배치합니다. 이를 통해 물리적 RAM 용량을 초과하는 대규모 프로젝트 수행이 가능해집니다.

실제 코딩 에이전트 테스트 및 토큰 효율성 분석

Qwen 2.5 35B 모델을 사용하여 영화 검색 및 평점 관리 웹 앱 개발 작업을 수행했습니다.
가벼운 codex CLI를 사용함으로써 Claude Code 대비 약 16.2K 토큰의 시스템 프롬프트 부하를 줄였습니다.
컨텍스트 제한으로 인한 400 에러 발생 시에도 SSD 캐시를 통해 이전 계산 상태를 즉시 복구하며 작업을 이어갔습니다.

M2 MacBook Pro에서 약 20분에 걸쳐 178만 개의 토큰을 생성하며 테스트가 진행되었습니다. 89%에 달하는 캐시 효율성 덕분에 세션을 비워도 모델의 논리적 상태가 보존되어 환각 현상 없이 중단 지점부터 재개할 수 있었습니다. 최종 결과물로 와치리스트 기능이 포함된 작동 가능한 웹 애플리케이션이 생성되었습니다.

oMLX와 LM Studio의 성능 비교 실험 결과

LM Studio는 동일 작업 수행에 35분이 소요되어 oMLX의 20분보다 현저히 느린 속도를 보였습니다.
생성 속도 면에서 oMLX는 47 tokens/s를 기록한 반면 LM Studio는 16 tokens/s에 그쳤습니다.
LM Studio는 안정적인 컨텍스트 관리를 보여주었으나 심각한 RAM 점유로 인해 보조 모니터 영상 시청조차 불가능한 렉을 유발했습니다.

동일한 모델과 조건 하에서 진행된 비교 실험은 속도와 시스템 가용성 측면에서 뚜렷한 차이를 드러냈습니다. LM Studio는 작업 도중 400 에러가 발생하지 않는 안정성을 보여주었지만 시스템 자원을 완전히 독점했습니다. 반면 oMLX는 빠른 속도와 더불어 백그라운드에서 실행하며 웹 서핑 등 다른 작업을 병행할 수 있는 여유를 제공했습니다.

Mac 사용자를 위한 로컬 AI 구동의 미래와 결론

oMLX는 고속 SSD와 MLX 프레임워크를 결합하여 실질적인 RAM 확장 효과를 제공합니다.
강력한 AI 에이전트 실행에 반드시 128GB 이상의 고사양 RAM이 필수적인 것은 아님을 증명했습니다.
초당 생성 속도가 3배 빠르다는 장점은 일부 설정 관리의 번거로움을 상쇄할 만큼 강력한 가치를 가집니다.

Mac 사용자들에게 oMLX는 제한된 하드웨어 자원을 가장 지능적으로 사용하는 방법을 제시합니다. 기존의 범용 엔진보다 애플 실리콘에 최적화된 도구를 선택함으로써 얻는 성능 이득이 명확합니다. 이는 개인이 로컬 환경에서 대규모 언어 모델을 생산적으로 활용할 수 있는 새로운 표준을 보여줍니다.

Community Posts

Write about this video