Mac에서 로컬 LLM 최적화하기 / EP06
128GB Mac에 AI를 여러 개 올리면, 누가 일을 나눠줄까?
Hermes를 하나의 대화창으로 두고 로컬 워커·검증기·클라우드를 연결하려 한다. 8GB iMac에서 확인한 계층형 PoC와 128GB Mac Studio에서 구축할 개인 AI 아키텍처.
이 글의 내용
나는 왜 하나의 AI와만 대화하고 싶을까?
Cookly를 만들고, KnitLens와 다른 앱도 개발 중이다. 여기에 로컬 LLM과 이미지·영상 작업까지 붙이고 싶다. 그런데 도구를 하나씩 따로 쓴다면 이전에 무슨 일을 하고 있었는지 설명하는 일도 늘어날 것 같다.
내가 원하는 건 대화창 하나다. “Cookly에서 발생한 오류를 분석하고 수정해줘.”라고 부탁하면 프로젝트를 찾고 필요한 작업을 나눠서 끝낸 뒤 결과를 돌려주는 것. 뒤에서 어떤 모델을 쓰든 매번 내가 고를 필요는 없었으면 한다. ChatGPT Dots 같은 개인 AI에서 기대하는 사용 방식도 이쪽이다.
EP05에서 Mac Studio를 선택한 이유가 여기로 이어진다. 가장 빠른 LLM 하나보다 앱 개발과 여러 AI 작업을 함께 맡길 환경이 필요했다. 주문한 M5 Max 128GB / 1TB는 아직 도착 전이지만 작은 계층형 파이프라인은 이미 8GB iMac에서 시험해봤다.
이번에는 그 시험을 어디까지 확인했고 Hermes를 앞에 세워 어떤 시스템으로 확장하려는지 정리해보려 한다.
Hermes를 개인 AI의 메인 에이전트로
Hermes는 사용자와 대화하고 작업을 진행할 메인 에이전트 후보다. Telegram은 이미 연결해 쓰고 있다. 여기에 프로젝트별 맥락, 진행 중인 작업, 도구와 하위 에이전트를 묶고 싶다.
사용자가 “오류 수정해줘”라고 하면 Hermes가 관련 기억과 코드를 확인하고, 원인 조사·수정·테스트로 일을 나눈다. 워커에게 필요한 맥락과 권한을 전달하고 결과를 모은 뒤 무엇이 바뀌었고 어떤 검사를 통과했는지 보고하는 구조다. 메인 Hermes에도 계획과 도구 호출을 맡을 언어 모델이 필요하다.
하나의 대화창 뒤에 둘 구조
Telegram · Paseo · Mac
의도·계획 · Task / Session 관리 · 장기 기억
도구·에이전트 위임 · 진행 추적 · 결과 취합
개인정보 · 클라우드 허용 · 작업 권한
작업 유형·난도 · 실행 대상 선택
General / Coding LLM 소형 판단 모델
허용된 클라우드 작업 모델·요금 정책 확인
복잡한 코딩 위임 CLI 확인 · ACP 통합 미확인
Vision · ComfyUI · STT / TTS · 문서 · 파일 · 코드
결정적 검사 → 의미 판단 → 품질 정책
재시도·승격은 Policy / Router로 되돌린다
결과 · 검증 상태 · 실행 경로 · 남은 문제
이 그림은 목표 아키텍처다. Hermes가 모든 상자를 기본 제공한다는 뜻은 아니다. 공식 문서에서 확인한 하위 에이전트 위임과 결과 반환은 활용할 수 있는 기반이다. 기억·세션 검색, 작업 상태를 남기는 Kanban 기능도 문서화돼 있다. 다만 이를 내 프로젝트에 연결하고 승인·검증 정책을 붙이는 일은 남아 있다.
특히 delegate_task의 모델 고정 설정은 작업마다 자유롭게 모델을 고르는 라우터와 다르다. 현재 문서는 배치의 하위 에이전트에 공통 모델 설정을 쓰며 작업별 모델 변경에는 Kanban 등의 경로를 구분한다. “위임 기능이 있으니 자동 최적 모델 선택도 완성”이라고 넘어갈 수는 없다.
그림에서 Router는 작업을 어디에 보낼지 고르고 Judge는 나온 결과가 충분한지 검사한다. Policy는 양쪽이 지켜야 할 개인정보·권한·비용 제한이다. 이 역할을 합쳐버리면 모델을 잘 골랐다는 이유로 검증을 생략하기 쉽다.
작은 로컬 모델부터 시작하는 계층형 AI
기본 정책은 Local First → Verify → Escalate Only When Necessary다. 작업 유형과 난도를 보고 로컬에서 처리할 만한 일부터 보내고 결과가 부족하면 재시도하거나 다른 실행 대상으로 넘긴다. 넘긴 뒤에도 검증은 다시 한다.
생각 중인 경로는 Local → OpenCode Go → Codex다. 다만 이 순서가 모든 작업의 의무 코스도, 성능 순위도 아니다. OpenCode Go는 특정 모델 이름이나 에이전트 자체가 아니라 코딩 모델을 이용하는 공급자·요금제다. 실제 코딩 워커로 OpenCode를 쓰는 것과 Go 모델을 API로 호출하는 것도 구분해서 연결해야 한다.
Local First → Verify → Escalate
개인정보·권한 확인 후 시작 경로 결정
LOCAL_ONLY / CLOUD_OK
PASS: 검증 상태와 함께 반환
RETRY: 횟수·시간 예산 안에서 로컬 재시도
ESCALATE: 클라우드 허용 여부를 다시 확인
클라우드 차단 로컬 재시도 또는 중단·사용자 확인
전송할 자료 검사 위임할 작업과 권한 확인
PASS → 반환 / 실패 → 다음 경로 검토
통과하면 반환 · 미통과면 중단 또는 사용자 검토
사용한 경로와 미해결 문제도 함께 보고
처음부터 복잡한 코드 수정이라면 Codex로 바로 보낼 수 있다. 로컬에서 여러 번 실패한 뒤 같은 작업을 반복하는 편이 오히려 느리고 비쌀 수 있기 때문이다. 반대로 LOCAL_ONLY라면 결과가 부족해도 클라우드로 넘기지 않는다. 로컬 재시도나 사용자 확인, 중단 중에서 골라야 한다.
이 정책은 워커에만 붙여서는 안 된다. 메인 Hermes가 클라우드 모델이면 요청은 이미 외부로 나간다. 민감한 작업의 LOCAL_ONLY는 메인 모델·Judge·검색 도구·외부 로그 전송까지 같은 범위에서 지켜야 한다. CLOUD_OK도 모든 파일을 보내도 된다는 허가는 아니다. 넘길 코드·로그를 선별하고 파일 수정이나 외부 서비스 호출에는 작업별 권한을 적용하려 한다.
라우터 후보로는 Weave Router (weave-os/router)를 검토했다. 공식 저장소와 프록시 구현은 API 요청 단위의 모델 선택, 공급자 형식 변환, 호환 엔드포인트 설정을 다룬다. 이것만으로 Mac의 남은 메모리를 읽고 모델을 로드·언로드하거나, 내 검증 실패를 알아서 받아 승격한다는 뜻은 아니다.
내 라우터가 보고 싶은 값은 작업 유형·복잡도, 모델별 작업 성공률, 현재 로드된 모델과 메모리, 컨텍스트 길이, 비용과 응답 지연이다. 개인정보 정책은 선택 후보를 먼저 제한한다. Weave가 맡을 수 있는 부분과 내가 붙여야 할 메모리·품질 정책은 실제 연동에서 나눠 확인할 예정이다. 다른 프로젝트의 동명 Weave와도 구분해두려 한다.
실패를 어떻게 판단하고 더 강한 모델로 넘길까?
로컬 모델이 “모르겠다”고 하면 다음으로 넘기기는 쉽다. 문제는 자신 있게 틀리는 경우다. 모델에게 답변을 잘했는지 물어보고 끝낼 수는 없다.
우선 기계적으로 검사할 수 있는 것은 따로 확인하려 한다. JSON Schema, 필수 필드와 출력 형식, 파일 생성 결과, 컴파일과 단위 테스트 같은 것들이다. 그다음 요구사항 충족, 답변의 관련성·논리·근거, 작업 계획의 빠진 부분을 의미적으로 살핀다.
| 검증·정책 | 확인할 것 | 다음 행동 |
|---|---|---|
| 결정적 검사 | 스키마·필수 필드·파일·컴파일·테스트 | 실패하면 수정·재시도·승격 또는 중단 |
| 의미적 검사 | 요구사항·관련성·논리·근거·계획 완결성 | 부족한 이유를 남기고 추가 작업·검토 |
| 실행 정책 | 난도·성공 가능성·남은 시간·비용·컨텍스트·위험 | 허용된 후보와 재시도 예산 안에서 선택 |
JevMLX는 이 중 경량 분류와 의미 판단을 시험할 후보다. 정확히는 독립된 Judge 모델 이름이라기보다, MLX 모델로 정해진 선택지를 평가하고 구조화된 결정을 만드는 도구다. 어떤 모델과 판단 스키마를 쓰느냐에 따라 결과가 달라진다. 선택 점수도 답변이 사실일 확률로 그대로 읽을 수는 없다.
예를 들어 “요구사항을 충족했나”, “근거가 부족한가”, “추가 검토가 필요한가”를 나눠 물어볼 수는 있다. 하지만 테스트 실패를 의미 Judge의 PASS로 덮어쓰지 않도록 설계하려 한다. 반대로 테스트가 통과해도 요구한 기능을 잘못 이해했을 수 있다. 의미 판단도 틀릴 수 있으니 PASS를 정답 보증으로 삼지 않는다.
승격할 때는 실패한 검사의 결과와 관련 맥락을 같이 전달해야 한다. 이미 고친 파일이 있다면 변경 사항을 남기고 같은 부작용을 다시 실행하지 않게 한다. 무한 재시도 대신 횟수·시간·비용 상한을 두고 해결하지 못하면 미해결 상태로 보고하는 쪽이다.
8GB iMac에서 이미 검증한 PoC
완전히 처음 떠올린 구조는 아니다. EP00에서도 잠깐 언급했듯, 2026년 9월 M1 iMac 8GB에서 제한된 PoC를 진행했다. Ollama의 Qwen2.5 1.5B Q4를 로컬 출발점으로 두고 OpenCode Go, Codex CLI, QwenPaw, Paseo를 사용했다.
통제된 작업과 검증 조건에서 다음 세 경로를 확인했다. 새로 성능을 측정한 표가 아니라 당시 확인한 동작의 범위다.
| 경로 | 확인한 동작 |
|---|---|
| A · Local PASS | 작은 로컬 모델이 작업을 처리하고 검증을 통과해 반환 |
| B · Local → OpenCode Go | 로컬 결과가 검증에 실패한 뒤 실제 Go 호출로 승격 |
| C · Local → OpenCode Go → Codex CLI | 앞의 두 계층이 실패한 뒤 실제 Codex CLI가 최종 작업 수행 |
세 경로는 그 시험에서 정상 동작했다. QwenPaw 명령 플러그인 호출과 Paseo의 iPhone 원격 요청도 각각 확인했다. 8GB에서도 계층을 연결할 수 있다는 출발점은 얻었다.
다만 자유형 요청을 알아서 끝내는 개인 AI가 완성된 것은 아니다. JevMLX 의미 검증은 적용하지 않았고 Codex는 ACP가 아닌 직접 CLI로 호출했다. QwenPaw 네이티브 ACP 위임은 미완료이며 iPhone에서 클라우드 승격 B·C 경로는 검증하지 않았다. Hermes와 이 파이프라인 전체의 통합도 아직 시험하지 않았다.
PoC가 확인한 것은 제한된 검증 조건에서 실제 공급자를 호출해 경로를 바꿀 수 있다는 점이다. 낯선 앱 오류를 진단하는 능력이나 일반적인 답변 품질까지 입증한 결과로 넓혀 읽지는 않으려 한다.
128GB Mac Studio에서 달라질 것
처음에는 가장 큰 모델 하나를 계속 켜두는 쪽이 궁금했다. 지금은 작고 충분히 좋은 모델을 자주 쓰고 무거운 모델은 필요할 때 불러오는 구성이 더 끌린다. 여러 앱을 개발할 메모리도 같이 남겨야 하니까.
상주 후보는 중형 General LLM, 작은 Judge·Router용 모델, 필요하면 STT나 임베딩 모델이다. 대형 Qwen·DeepSeek 계열과 Vision·이미지·영상·음악 모델은 필요할 때 로드하려 한다. 구체적인 버전·양자화는 아직 확정하지 않았다. 모두 동시에 메모리에 올릴 계획은 아니다.
자주 쓰는 모델과 필요할 때 쓰는 모델
- 중형 General LLM
- 작은 Judge / Router
- 필요한 STT 또는 임베딩
- 대형 Qwen / DeepSeek 후보
- Vision · 이미지 · 영상 · 음악
macOS · Xcode · Simulator · KV Cache · 런타임 버퍼
- 필요하면 덜 쓰는 모델의 작업 종료·해제
- 필요한 모델 로드 → 작업 → 결과 검증
- 작업 종료 후 기본 구성으로 복귀
EP02에서 정리한 가중치·KV Cache·실행 공간에 개발 도구 사용량을 더해 봐야 한다. 작업 우선순위와 실행 중인 세션을 확인한 뒤 덜 쓰는 모델을 해제하고 필요한 워커를 켠다. 프로세스를 내린다고 다른 작업의 버퍼나 OS 파일 캐시까지 모두 사라진다고 가정하지는 않는다.
도착하면 Peak Unified Memory, KV Cache 사용량, Swap, 동시 세션 수와 함께 모델 로드·언로드 지연을 기록할 생각이다. Router와 Judge에 걸린 시간도 따로 보고 요청을 보낸 순간부터 검증된 결과를 받기까지의 전체 작업 시간을 측정하려 한다.
모델의 토큰 속도는 EP01의 Prefill·Decode로 나눠 볼 수 있다. 하지만 빠른 Decode가 빠른 작업 완료를 보장하지는 않는다. EP03의 가속이나 EP04의 스트리밍을 쓰더라도, 로딩·도구 실행·검증·재시도까지 합친 시간을 봐야 한다.
장기 기억, 프로젝트 관리, 전문 워커
“Cookly 오류 고쳐줘”라고 할 때 매번 프로젝트 설명을 처음부터 하고 싶지는 않다. 그렇다고 모든 프로젝트와 모든 대화를 한 프롬프트에 계속 쌓아둘 수도 없다. 기억은 이렇게 나눠 관리하려 한다.
| 기억 계층 | 담을 내용 |
|---|---|
| User Memory | 선호, 반복 작업 방식, 승인 정책, 자주 쓰는 도구 |
| Project Memory | Cookly·KnitLens·Delsa·소복·소리여행·Personal AI Lab의 관련 맥락 |
| Session Memory | 현재 목표, 진행 상황, 결과, 실패와 재시도 기록 |
| Knowledge Base | Obsidian Vault, 개발 일지, 기술 문서, 벤치마크 기록 |
이 네 계층은 내가 사용할 논리적 구분이다. Hermes가 같은 이름의 저장소 네 개를 기본 제공한다는 설명은 아니다. 공식 기억 기능은 선별된 메모리와 사용자 정보, 과거 세션 검색을 기반으로 한다. 필요한 기록을 찾아 현재 작업에 넣고 프로젝트가 바뀌면 세션 맥락도 구분할 계획이다.
기억에는 출처와 적용 범위를 남기고 수정·삭제·검색이 가능해야 한다. 승인 정책은 자유롭게 요약된 메모리가 아니라 실행 권한을 검사하는 설정에서도 강제해야 한다. 오래된 대화를 검색하는 기능은 기록이 남는다는 뜻이기도 하므로 보관 기간과 로그 정리도 정해야 한다. 비밀키·인증 정보는 프롬프트나 일반 기억에 넣지 않고 별도로 관리한다. Obsidian은 지식 저장소 중 하나다.
전문 워커도 같은 원리로 나눈다. 코딩은 Local Coding LLM·OpenCode·Codex, 이미지와 영상은 ComfyUI 등의 워크플로, 음성은 STT·TTS, 정보 처리는 문서 분석·검색·요약·파일 도구를 검토하고 있다. 이들을 전부 Hermes 안의 언어 모델로 바꾸려는 것은 아니다.
하나의 요청을 나누고 다시 모으기
기능 요구사항 · 공개할 자료 · 작업 권한 확인
코드와 영상 작업의 의존 관계도 정한다
Local Coding LLM / OpenCode / Codex
원인·구현 → 빌드·테스트 → 변경 요약
Vision / ComfyUI / STT / TTS
승인된 화면·대본 → 이미지·영상·음성
기능 동작·요구사항 확인 · 영상의 실제 화면·문구 확인
변경 사항 · 테스트 · 제작 파일 · 승인 필요한 작업
“Cookly의 새 기능을 구현하고 출시용 소개 영상도 만들어줘.”라면 먼저 기능과 공개할 자료를 확인한다. 코딩 워커는 구현과 테스트를 맡고 제작 워커는 승인된 화면과 대본으로 영상·음성을 만든다. 실제 기능 화면이 필요한 영상은 코드 결과가 나올 때까지 기다려야 한다. 모든 하위 작업을 무작정 병렬로 보내지는 않는다.
Hermes는 결과를 모아 변경 사항, 테스트, 제작 파일과 남은 승인 요청을 돌려준다. 같은 방식으로 개발 기록을 정리하거나 블로그 초안을 만드는 활용도 가능할 것 같다. 그건 여러 활용 사례 중 하나다.
아직 남은 문제와 실제 구축 계획
가장 먼저 붙여볼 것은 Hermes에서 로컬 워커로 작업을 보내고 결정적 검사를 거쳐 결과를 받는 경로다. PoC의 A·B·C를 여기서 다시 확인한 다음 JevMLX 의미 판단과 작업별 라우팅을 추가하려 한다. 메인 모델의 도구 호출이 불안정하면 워커 모델만 바꿔서는 해결되지 않으니 그 부분도 따로 본다.
원격 진입점은 Telegram·Paseo·Mac을 생각하고 있다. Paseo의 iPhone 요청은 작은 PoC에서 확인했지만 Hermes와의 직접 통합은 별도 문제다. Paseo 문서에 Codex와 OpenCode, 커스텀 ACP 제공자 경로가 있어도 동일한 Hermes 세션으로 연결됐다는 뜻은 아니다. 인증·프로젝트별 권한·세션 분리·로그 보호를 같이 확인할 예정이다.
Codex 연결도 구분해두려 한다. 직접 CLI 호출은 PoC에서 쓴 경로다. Codex ACP 어댑터는 별도 연결 방식이며 Hermes가 문서화한 Codex app-server 런타임과도 같은 개념이 아니다. 취소·승인 요청·세션 재개·실패 반환을 실제로 연결해보기 전에는 ACP 위임 완료로 적을 수 없다.
클라우드를 붙일 때는 전송할 자료와 작업 권한을 먼저 확인하고 경로·모델·검사·재시도·사용량을 추적하려 한다. 로그에도 민감 정보가 남지 않게 해야 한다. ChatGPT 구독으로 Codex에 로그인하는 것과 OpenAI API 종량제는 별개다. Go의 구독 한도와 추가 사용 정책도 나눠 봐야 한다. 아직 이 설계로 비용이 줄었다고 말할 근거는 없다.
통합되지 않은 부분은 분명하다. Hermes와 계층형 파이프라인, JevMLX Judge, Weave의 내 작업용 정책, Codex ACP, iPhone의 클라우드 승격, 자동 메모리 교체가 남아 있다. 그렇다고 모델을 더 추가하는 것부터 시작할 필요는 없을 것 같다.
우선 “Cookly 오류 분석해줘”라는 요청 하나가 올바른 프로젝트에 도착하고 필요한 권한 안에서 작업을 끝내고 검사 결과까지 돌아오는지부터 보려 한다. 로컬에서 끝났든 Codex까지 갔든 내가 궁금한 건 같다. 맡긴 일이 제대로 끝났나?
출처와 확인 범위
공식 자료 확인일: 2026-10-10. 기능은 해당 문서·소스에서 확인한 범위이며 설치 버전에서도 다시 확인할 예정이다. PoC는 2026년 9월의 내 시험 기록에 기반한다. 이번 편집에서 재실행한 결과나 Mac Studio 실측값은 아니다.
- Hermes: 하위 에이전트 위임, Kanban, 기억, Codex app-server 런타임.
- Weave Router: 공식 저장소, 요청 단위 정의, 설정, 프록시 구현. Hermes·Mac 메모리 관리 통합은 미검증.
- JevMLX: 공식 저장소, 구현 구조. 내 의미 Judge로의 적용은 미완료.
- 연결과 공급자: OpenCode Go, OpenCode ACP, Paseo 제공자, Codex ACP 어댑터.
댓글과 좋아요
로그인 없이 닉네임으로 남길 수 있어. 닉네임과 댓글은 공개되고, 댓글은 확인 후 올라가.