MLX로 Mac에서 에이전트 AI 실행하기

WWDC 2026에서 한 Apple 엔지니어가 자신의 Mac에 있는 로컬 에이전트에게 MLX 저장소의 최근 풀 리퀘스트를 가져와 변경 사항을 요약하고 주의가 필요한 부분을 표시해 달라고 요청했습니다. 모델은 추론하고, GitHub CLI를 호출하고, diff를 읽고, 요약을 만들어 냈습니다. 네트워크에 닿은 것은 git 명령뿐이었고, 모델은 전적으로 그의 하드웨어에서 실행되었습니다.¹ 이 데모가 바로 이 글의 핵심 주장입니다. 모델이 결정하고, 도구를 호출하고, 결과를 관찰하고, 다시 결정하는 부분인 에이전트 루프가 이제 MLX와 함께 Mac에서 로컬로 실행됩니다. 클라우드도, API 키도, 토큰당 비용도 없습니다. 그리고 Apple은 그 이야기의 나머지도 함께 출시했습니다. 이 루프를 여러 대의 Mac으로 확장하는 방법, 새로운 종류의 공격으로부터 에이전트 기능을 보호하는 방법, 그리고 루프가 조용히 잘못된 동작을 할 때 디버깅하는 방법입니다.

이 글은 함께 모이면 Mac에서의 로컬 에이전트 AI를 단순한 기술 데모가 아니라 실질적인 엔지니어링 영역으로 만들어 주는 WWDC 2026의 네 가지 세션을 따라갑니다. 아래 내용은 모두 그 세션에서 직접 가져온 것입니다.

TL;DR

• MLX는 네 개의 계층으로 이루어진 스택을 통해 에이전트 루프 전체를 Mac에서 로컬로 실행합니다. 기반이 되는 MLX, 모델을 위한 MLX-LM, OpenAI 호환 HTTP 서버인 MLX-LM Server, 그리고 그 위에 OpenAI chat completions 프로토콜을 사용하는 모든 에이전트입니다.¹
• 설정은 세 단계입니다. MLX-LM을 pip install하고, 도구 호출이 가능한 모델로 mlx_lm.server를 실행한 뒤, 에이전트의 base URL을 localhost로 향하게 하면 됩니다.¹
• Mac 한 대로 부족할 때 MLX는 Thunderbolt 5에서 RDMA와 Apple의 오픈 소스 라이브러리 JACCL을 사용해 모델을 여러 대에 분산합니다. 이를 통해 1조 개 파라미터 규모의 모델을 실행하고, 4노드 클러스터에서 추론과 파인튜닝을 약 3배 빠르게 만듭니다.²
• 에이전트 기능은 새로운 공격 표면을 엽니다. 바로 간접 프롬프트 인젝션입니다. Apple의 완화 전략은 결정론적 가드레일에 무게를 둡니다. Foundation Models의 .onToolCall 확인과 .historyTransform 스포트라이팅, 그리고 App Intents의 위험 기반 확인과 잠금 화면 인증입니다.³
• Xcode 27의 Foundation Models Instrument는 루프를 관찰 가능하게 만듭니다. 요청별 레인, 모델의 사고 흐름을 보여주는 트리 뷰, 그리고 조용한 실패와 느린 추론을 잡아내는 데 필요한 지표(Time to First Token, Tokens per Second, Total Latency)를 제공합니다.⁴

로컬 에이전트 스택 (세션 232)

MLX 팀의 Angelos가 2:42부터 세 단계 설정을 설명합니다.

대부분의 개발자가 알고 있는 채팅 경험은 작업을 다시 사람에게 떠넘깁니다. 세션은 이렇게 표현합니다. “여러분은 언어 모델에 프롬프트를 보냅니다. 모델은 응답을 돌려보냅니다. 그 응답에 따라 무언가를 해야 한다면, 명령을 실행하거나, 파일을 확인하거나, 오류를 고치는 것은 여러분의 몫입니다.”¹ 에이전트는 그 간극을 메웁니다. 에이전트는 모델과 대화하며 무엇을 할지 결정하고, 도구를 호출해 그것을 실행하고, 결과를 관찰한 뒤, 다음 단계를 위해 다시 모델로 돌아갑니다. 사용자에서 에이전트로, 에이전트에서 모델로, 에이전트에서 도구로, 작업이 끝날 때까지 순환합니다.

이 루프가 Apple silicon에서 흥미로운 이유는 그 모든 것이 로컬로 실행되기 때문입니다. MLX는 이 능력을 아래에서 위로 네 개의 계층으로 제시합니다. 계산, Metal 가속, 메모리를 처리하는 “Apple silicon 전용으로 만들어진 우리의 오픈 소스 배열 프레임워크”인 MLX, Hugging Face에서 모델을 로드하고, 실행하고, 양자화하고, 파인튜닝하는 MLX-LM, 구조화된 도구 호출과 추론 모델 지원을 갖추고 “로컬 모델을 표준 API를 통해 노출하는 OpenAI 호환 HTTP 서버”인 MLX-LM Server, 그리고 맨 위에는 Xcode든, OpenCode든, Pi 에이전트든, 커스텀 스크립트든 OpenAI chat completions 프로토콜을 사용하는 모든 에이전트입니다.¹ 이 표준 인터페이스가 바로 핵심이 되는 선택이었습니다. “어떤 에이전트 프레임워크든 그대로 작동”하며, Ollama, LM Studio, vLLM 같은 도구들은 이미 MLX와 MLX-LM 위에 구축되어 있습니다.¹

설정은 세 단계입니다. 한 번의 pip install로 MLX-LM을 설치합니다. 도구 호출이 가능한 모델로 서버를 시작합니다.

mlx_lm.server --model <a-tool-calling-model>

그런 다음 에이전트의 base URL을 localhost로 설정해 로컬 서버로 향하게 합니다. 세션이 언급하듯, “에이전트는 모델이 클라우드가 아니라 여러분의 Mac에서 실행되고 있다는 것을 알지도, 신경 쓰지도 않습니다.”¹ OpenCode에서는 URL이 localhost이고 모델 이름이 서버가 기대하는 값과 일치하는 로컬 프로바이더를 정의한 뒤, OpenCode가 모든 작업에 그 로컬 모델을 사용하도록 지정한다는 뜻입니다.

흥미로운 부분은 MLX가 특히 에이전트 워크로드에서 어떻게 제값을 하느냐입니다. 세션은 세 가지 과제를 꼽습니다. 첫 번째는 프롬프트 처리입니다. “에이전트 세션은 보통 수십만 개의 토큰으로 구성되며, 그 대부분은 생성된 것이 아닙니다.”¹ 모델은 도구 출력을 받을 때마다 더 추론하기 전에 그 새로운 컨텍스트 전체를 처리하고, 그 비용은 루프 전체에 걸쳐 반복됩니다. M5 칩의 전용 Neural Accelerator는 행렬 곱셈을 M4보다 4배 빠르게 만들고, MLX의 특수 커널과 결합하면 “이것은 거의 그대로 프롬프트 처리 속도 향상으로 이어지며”, 특별한 인자나 코드 변경이 필요하지 않습니다.¹ 두 번째 과제는 동시성입니다. 에이전트는 서브에이전트를 생성하고, MLX-LM Server는 연속 배칭으로 동시 요청을 처리하며 이를 동적으로 묶어 서브에이전트가 “큐에서 기다리며 멈추지” 않게 합니다.¹ 세 번째 과제는 모델 크기이며, 여기서 다음 세션이 이어받습니다.

Angelos는 단순히 읽고 보고하는 수준을 넘어선 데모로 마무리했습니다. 빈 Xcode 프로젝트에서 시작해, 그는 에이전트에게 iPad용 SwiftUI 그림 그리기 앱을 만들어 달라고 요청했습니다. 에이전트는 디렉터리를 검사하고, 계획을 세우고, 코드를 작성하고, xcodebuild를 사용해 컴파일하며 자신의 오류를 고쳐, 약 2분 만에 작동하는 앱을 만들어 냈고, 요청에 따라 둥근 끝마감을 추가하도록 반복했습니다.¹ 마지막 데모는 같은 실행 중인 MLX 서버를 로컬에서 호스팅되는 채팅 프로바이더로 Xcode의 Intelligence 설정에 연결했고, 그래서 Xcode 자체가 심어 둔 버그를 찾아 고칠 수 있었습니다. “로컬 AI란 여러분의 코드가 결코 Mac을 떠나지 않는다는 뜻입니다.”¹

여러 대의 Mac으로 확장하기 (세션 233)

Tatiana가 2:21부터 네 대의 Mac으로 클러스터를 단계별로 구축합니다.

결국 한 대의 머신으로는 공간이 부족해집니다. MLX 팀의 연구 과학자 Tatiana는 이렇게 표현했습니다. “결국에는 한 대의 머신에 있는 메모리, 연산, 대역폭이 한계가 됩니다.”² 세션 232에서 다룬 대표적인 사례는 아예 들어가지 않는 모델입니다. 가장 최신의 DeepSeek 모델은 “무려 1.6조 개의 파라미터를 가지고 있으며, 가중치만으로 800GB가 넘는 메모리를 필요로 합니다.”¹ 세션 233은 그 작업을 여러분이 소유한 Mac들에 펼치는 방법을 깊이 다룹니다.

분산 MLX의 토대가 되는 스택에는 세 가지 구성 요소가 있습니다. 인터커넥트와 전송입니다. macOS 26.2부터 Remote Direct Memory Access(RDMA)가 Thunderbolt 5에서 지원되어, “CPU와 운영 체제의 오버헤드 대부분을 피하면서” 한 머신의 메모리에서 다른 머신의 메모리로 데이터를 직접 이동시킵니다.² 통신 백엔드입니다. JACCL은 “Apple이 만든 오픈 소스 집합 통신 라이브러리”로, Thunderbolt 위의 RDMA에서 동작하며 전송을 직접 관리하지 않고도 집합 프리미티브를 제공합니다. 또한 “머신러닝에 국한되지 않고” “MLX 없이도 구축할 수 있으며”, 모든 분산 워크로드를 위한 C++ API를 노출합니다.² MLX는 그 위에 자리 잡아, 클러스터 전체의 저지연 조율에 JACCL을 사용합니다.

Tatiana는 네 대의 M3 Ultra로 클러스터를 구축했습니다. 토폴로지가 중요한 이유는 통신 시간이 지연 시간(연산당 고정 비용)과 전송 시간(메시지 크기에 따라 증가)으로 나뉘기 때문입니다. JACCL은 가장 낮은 지연 시간을 위해 “모든 머신이 다른 모든 머신과 직접 연결되는” 메시와, 각 노드가 두 이웃과 연결되는 링을 지원합니다. 링에서는 이웃마다 여러 케이블을 연결해 대역폭을 늘릴 수 있도록 포트가 비게 됩니다. 메시로 배선하면 JACCL은 “메시지 크기와 통신 연산에 따라 최적의 토폴로지를 자동으로 선택하여, 지연 시간이 중요할 때는 메시를, 대역폭이 중요할 때는 링을” 사용합니다.² 설정에서 RDMA를 활성화한 뒤, JSON 호스트 파일을 가리키는 mlx.launch로 작업을 시작합니다. 헬퍼 스크립트 mlx.distributed_config가 그 호스트 파일을 생성하고, --auto-setup을 붙이면 Thunderbolt 네트워크 자체도 구성해 줍니다.²

클러스터 전체에서 모델을 실행하는 것은 한 대의 머신에서 실행하는 것과 거의 동일합니다. 같은 mlx_lm.chat 명령을 mlx.launch --hostfile로 감싸기만 하면, “MLX LM이 모델을 샤딩하고 분산 추론을 조율해 줍니다.”² 나란히 비교해 보면, 270억 개 파라미터의 Qwen 3.6은 네 대의 M3 Ultra에서 “한 대의 머신의 거의 3배 속도로” 토큰을 생성했습니다.² MLX는 두 가지 샤딩 전략을 지원합니다. 파이프라인 병렬화(깊이로 분할, 통신은 단순하지만 속도 향상은 없음)와 텐서 병렬화(너비로 분할, 모든 머신이 같은 토큰을 동시에 처리해 속도가 향상되지만, 레이어마다 잦은 통신이 발생하며 “그것이 바로 메시 토폴로지가 결정적인 이유”)입니다.² 텐서 병렬화가 기본값입니다. 세션은 1조 개 파라미터의 Kimi 2.6(8비트에서 약 1테라바이트의 가중치로, “한 대의 M3 Ultra에는 들어가지 않지만 네 대에 걸치면 들어갈 수 있음”)을 클러스터 전체에서 실행했습니다.² 같은 접근 방식은 파인튜닝도 가속합니다. mlx_lm.lora를 통한 데이터 병렬 LoRA 학습은 한 대의 M3 Ultra의 초당 약 180토큰을 클러스터에서 초당 약 600토큰으로, “3배가 넘는 속도 향상”을 이뤘습니다.² MLX는 분산 워크플로를 앱에 내장할 수 있도록 Python, Swift, C++를 통해 동일한 프리미티브를 노출합니다.

루프 보안 강화하기 (세션 347)

Willy가 4:01에 간접 프롬프트 인젝션을 소개하고, Akshay가 11:55부터 프레임워크 API를 다룹니다.

모델에 도구를 호출할 능력을 주는 것은 하나의 문을 여는 일입니다. Willy는 이렇게 표현했습니다. “LLM은 강력하지만 속을 위험도 있는, 새로운 확률적 엔진을 여러분의 애플리케이션 안으로 들여옵니다.”³ 새로운 위험은 간접 프롬프트 인젝션이며, 세션은 이를 “제어 흐름을 가로채려는 의도로, 모델에 제공된 추가 컨텍스트에 심어진 지시”로 정의합니다.³ 세션의 예제 앱 Loose Leaf에는 캘린더와 친구 피드를 읽고 차를 주문할 수 있는 “티 파티 준비하기” 기능이 있습니다. 공격은 이렇습니다. 사용자가 자신의 캘린더를 덧붙여 파티 계획을 요청하지만, 캘린더 이벤트에는 그 대신 민감한 사용자 데이터를 삭제하라고 모델에 지시하는, 심어진 명령이 들어 있습니다.³

인젝션은 두 가지 효과를 낳습니다. 데이터 포이즈닝은 “공격자가 실행되는 동작의 파라미터에 영향을 주는 것”으로, 엄마에게 보내려던 메시지를 공격자에게 보내는 것으로 바꿔 버립니다. 액션 포이즈닝은 공격자가 “어떤 동작을 실행할지에 영향을 주는 것”으로, 이 이메일을 요약하라는 요청을, 이메일을 덧붙여 악성 URL을 여는 쪽으로 유도합니다.³ 세션은 그 위험을 Simon Willison의 치명적 3요소(Lethal Trifecta)에 근거해 설명합니다. 사용자가 가장 큰 위험에 처하는 것은 에이전트 시스템이 비공개 데이터에 대한 접근, 신뢰할 수 없는 콘텐츠에 대한 노출, 외부로 통신할 능력을 결합할 때이며, 이는 “부수 효과를 가진 모든 동작의 위험”으로 일반화됩니다.³ 그 관점은 정직합니다. “간접 프롬프트 인젝션을 해결하는 것은 활발한 연구 영역”이므로, 현실적인 목표는 자신의 앱이 가진 위험을 이해하고 그것을 완화하는 것입니다.³

그 방법은 위협 모델링 연습입니다. 먼저, 프롬프트에 들어가는 모든 것에 대한 데이터 흐름 분석을 수행하여 “외부 엔터티에서 들어오는 모든 입력”을 신뢰할 수 없는 것으로 표시합니다. Loose Leaf의 경우 이는 캘린더 내용과 친구 피드를 의미합니다.³ 다음으로, 에이전트의 동작과 부수 효과를 목록화합니다. 차를 주문하는 도구는 금전적 위험을 지니고, 피드에 게시하는 도구는 데이터 유출 위험을 지니며, 무해해 보이는 우림 타이머조차 위험합니다. 그 선택적 레이블이 “프롬프트 인젝션에게 나중의 공격을 위한 추가 지시를 적을 여지를 줄 수 있기” 때문입니다.³ Apple이 밝힌 선호는 “결정론적 완화책을 기준선으로 삼는 것이며, 그 보안 보장은 감사하기 쉽고 논리적으로 따져 보기 쉽기” 때문이라는 것입니다. 그 위에 확률적 완화책을 얹습니다.³

그런 다음 Akshay가 API를 보여 주었습니다. Foundation Models에서 라이프사이클 이벤트 모디파이어는 “세션 실행의 특정 라이프사이클 지점에서 결정론적으로 트리거되는 콜백”으로, 보안 체크포인트로 사용할 수 있습니다. .onToolCall 모디파이어는 실행기가 도구를 실행하기 전에 동작하며, “이 콜백이 오류를 던지면 그 도구는 결코 실행되지 않으므로”, “확인을 강제하기에 완벽한 위치”가 됩니다. 현재 도구가 금전 관련 도구인지 확인하고, 그렇다면 먼저 사용자 확인을 요구하는 것입니다.³ .historyTransform 모디파이어는 “추론을 위해 트랜스크립트가 모델에 렌더링되기 전에 동작”하여, 신뢰할 수 없는 도구 출력을 스포트라이팅 구분자로 감싸고, 민감한 구간을 [REDACTED] 자리표시자로 바꿔 모델이 보기 전에 PII를 가립니다.³ 한 가지 유의점이 있습니다. 이 변환들은 “현재 추론 반복에만 적용 범위가 한정”되므로, 호출할 때마다 다시 적용하거나, 지속시키고 싶은 변환에는 @SessionProperty 어노테이션을 사용합니다.³

App Intents를 통해 Siri와 통합하는 앱에는 두 가지 시스템 가드레일이 적용됩니다. 확인은 “위험 기반”이며 “맥락 의존적”입니다. 인텐트가 스키마를 채택하면 그 스키마의 위험 메타데이터를 상속하며(사진 삭제는 파괴적, 데이터 유출은 위험함), Risk Evaluation 시스템은 그 정적 메타데이터와 “시스템의 동적 상태”를 결합해 실행 전에 사용자에게 물을지를 결정합니다.³ 두 번째는 잠금 화면 인증입니다. Siri는 잠긴 기기에서도 접근 가능하므로, 인텐트의 authenticationPolicy를 .requiresAuthentication으로 설정해 잠긴 상태에서는 파괴적 동작이 실행되지 않게 합니다. 스키마의 기본 정책은 “더 엄격하게 만드는 방향으로만” 재정의할 수 있으며, 더 약하게 재정의하면 빌드 오류가 발생합니다.³

루프 디버깅하기 (세션 243)

Erik가 1:58부터 자신의 Craft 앱에서 조용한 에이전트 실패를 진단합니다.

루프의 유연성은 동시에 그 디버깅 문제이기도 합니다. AI Tools Engineer인 Erik는 이렇게 말했습니다. “전통적인 코드는 예측 가능합니다. LLM은 비결정론적이어서, 같은 입력이 다른 출력을 낼 수 있습니다.”⁴ 그는 전통적인 개발에는 없던 세 가지 과제를 꼽았습니다. 확률적 출력(그래서 “표준 단위 테스트가 무너지고”, 대신 품질과 의도를 평가함), 모델 간 통신, 그리고 관찰 가능성입니다. “멀티모델 파이프라인에서 무언가가 망가졌을 때, 어디서 잘못되었는지 알기가 매우 어렵습니다.”⁴ Xcode 27의 Foundation Models Instrument는 바로 그 마지막 과제에 답하기 위해 존재합니다.

Erik는 자신의 Craft 앱에서 시연했습니다. 그곳에서 브레인스토밍 기능은 두 개의 지시 세트, 즉 브레인스토밍과 튜토리얼 생성을 사용하며, 브레인스토밍 세트는 GenerateCraftIdeaTool과 SwitchToTutorialModeTool을 제공합니다.⁴ 그 트레이스에서 기능이 실패했습니다. 튜토리얼로 전환해야 할 때 계속 아이디어만 내놓고 있었던 것입니다. Instructions 레인이 곧바로 그 전말을 들려주었습니다. “세션 전체에서 단 하나의 지시 세트만 활성화되어 있었지만, 기능은 두 개를 사용해야 했습니다. 즉 인계 과정에서 무언가가 잘못된 것입니다.”⁴ 모든 것을 “세션, 요청, 모델 추론, 지시, 프롬프트, 응답”으로 정리하는 트리 뷰가 근본 원인을 드러냈습니다. “프롬프트는 switchToTutorialMode 도구를 참조하지만, 그 도구는 이 지시에 실제로 구성되어 있지 않습니다.”⁴ 모델은 오류를 던지지 않고 계속 도구 호출을 했습니다. “이것은 조용한 실패였으며”, 잡아내기 가장 어려운 종류입니다.⁴ 빠진 도구를 도구 세트에 추가하자 문제가 해결되었고, 다시 트레이스해 보니 두 개의 별개의 지시 세트가 활성화되었으며, switchToTutorialMode 도구 호출 후에 인계가 올바르게 일어났습니다.⁴

이 Instrument는 성능도 읽어 낼 수 있게 합니다. Model Inference 레인은 입력 프롬프트 처리에는 노란색 막대를, 응답 생성에는 주황색 막대를 사용합니다.⁴ 최적화를 이끄는 지표는 세 가지입니다. Time to First Token(“높은 Time to First Token은 사람들이 빈 화면을 응시하고 있다는 뜻이며, 이를 줄이려면 프롬프트를 짧게 하라”), Tokens per Second(“서로 다른 프롬프트 구성에 걸쳐 성능을 벤치마크하고 변경 후의 회귀를 잡아내기” 위함), 그리고 Total Latency(“사람들이 가장 직접적으로 느끼는 수치”로, 부분 결과를 더 일찍 스트리밍함으로써 체감상 줄어듦)입니다.⁴ 운영상 한 가지 참고 사항이 있습니다. 이 Instrument는 “여러분의 기기에서 프롬프트와 응답 데이터를 캡처하며, 거기에는 민감한 정보가 포함될 수 있으므로”, 프로덕션에서는 로깅이 꺼져 있지만 트레이스가 진행되는 동안에는 켜지며, 트레이스 파일은 안전한 곳에 보관합니다.⁴

시작하는 방법

이 네 세션은 여러분이 이미 가진 하드웨어에서 따라 할 수 있는 하나의 흐름으로 엮입니다.

1. 로컬 루프를 세웁니다. MLX-LM을 pip install하고, 먼저 설정을 검증하기 위해 작은 도구 호출 모델로 mlx_lm.server를 실행한 뒤, 에이전트의 base URL을 localhost로 향하게 합니다. 에이전트가 파일을 쓰거나 빌드를 실행하도록 두기 전에, 먼저 읽고 보고하는 작업부터 시작하세요.¹
2. Mac 한 대로 부족할 때만 확장합니다. 모델이 메모리에 들어가지 않거나 추론이 너무 느리면, Mac들을 Thunderbolt 5로 연결하고, 설정에서 RDMA를 활성화하고, mlx.distributed_config로 호스트 파일을 생성한 뒤, 같은 명령을 mlx.launch 아래에서 실행합니다. 속도를 위해서는 텐서 병렬화(기본값)를, 그것이 필요로 하는 낮은 지연 시간을 위해서는 메시 토폴로지를 택하세요.²
3. 에이전트 기능을 출시하기 전에 위협 모델링을 합니다. 신뢰할 수 없는 모든 컨텍스트 출처와 모든 동작의 부수 효과를 나열합니다. 부수 효과가 있는 도구에는 .onToolCall 확인을, 신뢰할 수 없는 도구 출력에는 .historyTransform 스포트라이팅과 가림 처리를 추가합니다. App Intents의 경우, 각 인텐트의 위험 메타데이터를 검토하고, 파괴적 동작이 잠금 해제된 기기를 요구하도록 authenticationPolicy를 설정합니다.³
4. 신뢰하기 전에 프로파일링합니다. Xcode 27의 Instrument에서 Foundation Models 기능을 프로파일링하고, Instructions와 Model Inference 레인에서 조용한 실패를 읽어 내며, Time to First Token, Tokens per Second, Total Latency를 사용해 느린 단계를 찾습니다.⁴

세션 232의 모든 내용은 “오픈 소스이며 지금 바로 사용할 수 있습니다.”¹

FAQ

정말로 AI 에이전트를 통째로 Mac에서 실행할 수 있나요?

네. WWDC 2026 세션 232는 MLX를 통해 에이전트 루프 전체가 로컬로 실행되는 모습을 시연합니다. 모델이 추론하고, 도구를 호출하고, 결과를 관찰하고, 반복하며, 진정으로 네트워크가 필요한 도구 호출만이 머신 밖으로 나갑니다. 스택은 MLX, MLX-LM, OpenAI 호환 MLX-LM Server, 그리고 그 위에 OpenAI chat completions 프로토콜을 사용하는 모든 에이전트입니다.¹

에이전트를 로컬 MLX 모델에 어떻게 연결하나요?

세 단계입니다. MLX-LM을 pip로 설치하고, 도구 호출을 지원하는 모델로 mlx_lm.server를 시작한 뒤, 에이전트 프레임워크의 base URL을 localhost에 있는 로컬 서버 주소로 설정합니다. 에이전트는 이 로컬 서버를 클라우드 LLM API와 완전히 똑같이 취급합니다. MLX-LM Server가 그대로 끼워 넣을 수 있는 OpenAI 호환 HTTP 서버이기 때문입니다.¹

모델이 Mac 한 대에 비해 너무 클 때는 어떻게 하나요?

MLX는 Thunderbolt 5로 연결된 여러 대의 Mac에 모델을 분산합니다. RDMA(macOS 26.2부터 지원)와 Apple의 오픈 소스 통신 라이브러리 JACCL을 사용합니다. mlx.launch와 호스트 파일로 작업을 시작하면 MLX가 모델을 자동으로 샤딩합니다. Apple의 세션은 1조 개 파라미터의 모델을 네 대의 M3 Ultra에 걸쳐 실행했고, 추론과 파인튜닝에서 단일 머신 대비 약 3배의 속도 향상을 확인했습니다.²

에이전트 기능이 있는 Mac 앱의 주요한 새 보안 위험은 무엇인가요?

간접 프롬프트 인젝션입니다. 신뢰할 수 없는 컨텍스트(캘린더 이벤트, 소셜 피드, 도구 결과)에 숨겨진 악성 지시가, 데이터 삭제나 유출처럼 사용자가 결코 요청하지 않은 동작으로 모델을 유도합니다. Apple은 위협 모델링 과정에 더해 결정론적 가드레일을 권장합니다. Foundation Models의 .onToolCall 확인과 .historyTransform 스포트라이팅 및 PII 가림 처리, 그리고 App Intents의 위험 기반 확인과 잠금 화면 인증입니다.³

조용히 실패하는 에이전트를 어떻게 디버깅하나요?

Xcode 27의 Foundation Models Instrument를 사용합니다. 이것은 모든 모델 추론, 지시 세트, 프롬프트, 응답을 타임라인 레인과 트리 뷰로 캡처하므로, 각 단계에서 어떤 도구가 사용 가능했는지, 그리고 어디서 인계가 잘못되었는지를 모델이 한 번도 오류를 던지지 않을 때조차 정확히 볼 수 있습니다. 또한 성능 튜닝을 위해 Time to First Token, Tokens per Second, Total Latency도 보여 줍니다.⁴

Apple silicon에서 자신의 모델을 실행하는 것이 이 루프가 서 있는 기반입니다. MLX on Apple Silicon: Apple의 것이 아니라 자신의 모델이 필요할 때와 Core AI로 Apple silicon에서 모델 실행하기를 참고하세요. 에이전트가 Swift 앱에 어떻게 닿는지를 형성하는 런타임 대 툴링의 구분은 Foundation Models 에이전트 워크플로에 있습니다. 루프가 실행되면 그 품질을 측정하는 것이 다음 단계이며, Apple의 Evaluations 프레임워크에서 다룹니다. 시리즈 전체 허브는 Apple Ecosystem Series이고, 더 넓은 구축 맥락은 iOS Agent Development guide입니다.

References