모든 Mac 사용자가 이 새로운 AI 모델 러너(oMLX)를 사용해야 하는 이유
BBetter Stack
Computing/SoftwareConsumer ElectronicsInternet Technology
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였으며, 다음 영상에서 뵙겠습니다.