apfel을 보면서 든 생각: Mac에 이미 들어 있는 AI를 도구로 바꾸는 방식

가끔은 새로운 모델 발표보다, 이미 있는 모델을 어떻게 꺼내 쓸 수 있게 만들었는가가 더 흥미로울 때가 있다. apfel이 딱 그랬다.

겉으로만 보면 이 프로젝트는 단순하다. Apple Silicon Mac에 이미 들어 있는 Apple Intelligence 모델을 CLI로 쓰게 해주는 도구처럼 보인다. 그런데 조금만 더 들여다보면 포인트가 달라진다. 이건 단순한 “로컬 LLM 실행기”라기보다, Mac 안에 이미 있는 모델을 실제 작업 도구로 바꾸는 인터페이스 설계에 더 가깝다.

요즘은 모델 자체보다, 그 모델을 사람이 어떻게 호출하고 어떤 흐름으로 묶을 수 있는지가 실제 체감 차이를 만드는 경우가 많다. apfel은 그 지점을 꽤 정확하게 건드린다.

apfel이 바로 해결하는 문제

Apple은 Apple Intelligence와 FoundationModels.framework를 통해 온디바이스 모델 접근 경로를 열어뒀다. 하지만 그걸 곧바로 개발자가 편하게 쓸 수 있는 건 아니다.

기본 상태에서는 이런 느낌에 가깝다.

• 모델은 있다
• Siri나 시스템 기능이 일부 활용한다
• 프레임워크도 있다
• 그런데 터미널에서 바로 쓰긴 어렵다
• HTTP 서버처럼 붙여 쓰기도 번거롭다
• 셸 파이프라인이나 기존 OpenAI 툴링과 연결하기도 애매하다

즉, 모델이 존재한다는 사실과 실제로 잘 쓸 수 있다는 건 다른 문제다.

apfel은 정확히 그 틈을 메운다.

• CLI
• OpenAI 호환 로컬 서버
• 대화형 채팅

이 세 가지 인터페이스를 만들어서, Apple이 시스템 안에 넣어둔 모델을 개발자가 실제 작업 흐름 속에서 쓰게 만든다.

내가 흥미롭게 본 건 “무료 AI”보다 “도구화”다

이 프로젝트를 소개할 때 제일 자극적인 문장은 보통 이쪽이다.

• Mac에 이미 들어 있는 무료 AI
• 100% 온디바이스
• API 키 없음
• 비용 0원

물론 강한 문구다. 실제로도 매력적이다. 하지만 내 눈에는 그보다 아래가 더 중요하게 보였다.

• OpenAI 호환 서버로 열어둠
• CLI에서 바로 쓸 수 있음
• stdin/stdout과 JSON 출력 지원
• 도구 호출(function calling) 흐름까지 고려함
• cmd, oneliner, explain, gitsum, wtd 같은 작은 작업 도구로 확장함

이건 단순한 데모가 아니다. 이미 있는 모델을 사람이 쓰는 작업 흐름에 맞춰 다시 포장한 것에 가깝다.

결국 중요한 건 모델보다 인터페이스다

이 프로젝트를 보면서 다시 느낀 건, 온디바이스 AI도 결국 모델 그 자체보다 인터페이스와 작업 구조가 더 중요하다는 점이다.

예를 들어 모델이 아무리 기기 안에 들어 있어도 아래가 없으면 체감은 확 떨어진다.

• 어디서 호출하는지
• 어떤 형식으로 결과를 받는지
• 기존 툴과 어떻게 연결되는지
• 짧은 작업을 얼마나 가볍게 시킬 수 있는지
• 다른 시스템에서 얼마나 쉽게 재사용할 수 있는지

apfel은 이 부분을 꽤 잘 짚는다. 그래서 단순히 “Apple Intelligence를 열었다”는 사실보다, 그걸 작업 가능한 인터페이스로 만들었다는 쪽이 더 중요하게 느껴진다.

왜 OpenAI 호환 서버가 중요하냐

이건 생각보다 크다. 로컬 모델을 쓸 때 제일 번거로운 건, 모델마다 접근 방식이 전부 다르다는 점이다.

• 어떤 건 CLI만 있고
• 어떤 건 GUI만 있고
• 어떤 건 자체 SDK만 있고
• 어떤 건 기존 코드와 연결하려면 아예 새로 짜야 한다

그런데 apfel은 로컬에서 OpenAI 호환 서버를 띄우는 방향을 택했다. 이건 곧바로 이런 의미가 된다.

• 기존 OpenAI SDK 코드 재사용 가능
• LangChain/LlamaIndex 류 연동 가능성 확대
• 로컬 도구를 상위 애플리케이션에 쉽게 연결 가능
• 모델을 “특수한 로컬 기능”이 아니라 “익숙한 API 엔드포인트”처럼 다룰 수 있음

즉, 이건 모델 접근성을 높인 게 아니라 작업 연결 비용을 낮춘 것에 가깝다.

작은 유틸리티들이 오히려 더 실용적이다

apfel에 포함된 작은 도구들도 꽤 좋게 보였다.

• cmd
• oneliner
• explain
• gitsum
• wtd

이런 것들은 거창한 멀티에이전트 시스템처럼 보이지 않는다. 하지만 실제로는 이런 작고 빠른 도구가 훨씬 자주 쓰인다.

예를 들면:

• 디렉터리 요약
• 최근 git 커밋 요약
• 한 줄 명령 설명
• 자연어를 셸 명령으로 바꾸기

이런 건 클라우드 대형 모델로도 할 수 있다. 하지만 로컬에서 바로 되고, 비용이 없고, 짧은 반복 작업에 부담이 없다는 점이 큰 차이를 만든다.

그래서 나는 오히려 이런 류의 프로젝트를 볼 때, 거대한 데모보다 작은 실용 도구가 얼마나 잘 붙어 있는지를 먼저 보게 된다.

온디바이스 AI가 쓸 만해지는 지점도 여기다

온디바이스 AI는 늘 기대와 현실 사이에 있었다.

• 빠르지만 약하고
• 프라이버시에 좋지만 답답하고
• 오프라인이 되지만 활용 범위는 제한적이고
• 멋진 데모는 되지만 실무 구조 안에서는 애매한 경우가 많았다

그런데 apfel은 그 애매함을 조금 다른 방식으로 푼다.

“이 모델이 클라우드 메인 모델보다 뛰어난가?”를 묻기보다, “이 모델을 로컬에서 작업 도구로 쓰기 쉽게 만들었는가?”를 묻는 쪽으로 방향을 바꾼다.

이게 실용적이다.

어디에 잘 맞을까

내 기준으로 apfel 같은 구조는 아래 쪽에서 특히 쓸 만해 보인다.

1. 짧은 반복 작업

• 명령 설명
• 텍스트 요약
• 짧은 분류
• 로컬 파일/디렉터리 안내

2. 민감 정보가 섞인 작업

• 외부 API로 보내기 부담스러운 텍스트
• 로컬 로그나 메모 정리
• 개인 작업 환경 안에서만 처리하고 싶은 입력

3. 기존 자동화와의 연결

• OpenAI 호환 API를 기대하는 툴과 연결
• 셸 스크립트에서 가볍게 호출
• 로컬 보조 계층으로 붙이기

4. 오프라인 우선 작업

• 네트워크 없이도 최소 기능이 돌아야 하는 환경
• 지연 시간보다 반응성이 중요한 입력 처리

그래도 한계는 분명하다

이런 프로젝트를 볼 때 늘 그렇지만, 여기서도 너무 과하게 기대하면 안 된다.

설명만 봐도 보이는 제한이 있다.

• 컨텍스트 윈도는 4096 수준
• 모델 선택 폭은 사실상 고정
• macOS 26 이상 + Apple Silicon + Apple Intelligence 활성화라는 조건이 붙음
• 범용 대형 모델이 잘하는 긴 추론, 복합 작업까지 전부 대체하긴 어려움

즉, 이건 “모든 걸 해결하는 로컬 AI”라기보다 Mac에 이미 들어 있는 모델을 꽤 쓸 만한 형태로 꺼내 쓰게 해주는 도구로 보는 게 맞다.

그 관점에서는 기대치를 잘 맞출수록 더 좋아 보인다.

OpenClaw 같은 흐름과도 연결된다

이걸 보면서 자연스럽게 떠오른 건 OpenClaw 같은 허브 구조였다. 메인 허브가 모든 걸 직접 처리하는 대신, 일부는 로컬에서 처리하고 나머지를 상위 모델로 넘기는 구조가 점점 더 현실적이 되고 있다는 느낌이다.

예를 들면 이런 식이다.

• 로컬 계층(apfel): 짧은 분류, 설명, 전처리, 간단한 요약
• 상위 모델: 긴 글쓰기, 복잡한 추론, 큰 코드 작업
• 허브: 라우팅, 상태 관리, 실패 복구, 결과 전달

이 구조가 점점 더 자연스러워지는 이유는, 모델 성능이 아니라 호출 비용과 연결 비용을 줄이는 쪽에서 실제 이득이 크기 때문이다.

마무리

apfel을 보면서 흥미로웠던 건 “Mac에 무료 AI가 있다”는 문장 자체가 아니었다. 그보다 그 모델을 어떻게 사람이 실제로 쓰는 도구로 바꿨는가가 더 중요하게 느껴졌다.

정리하면 이렇다.

• 모델이 있는 것과 잘 쓸 수 있는 건 다르다
• apfel은 Apple Intelligence를 CLI, OpenAI 서버, 채팅 인터페이스로 풀어냈다
• 그래서 핵심은 모델 자체보다 인터페이스와 도구화에 있다
• 온디바이스 AI도 결국 실전에서는 “얼마나 쉽게 연결되느냐”가 중요하다

결국 이런 프로젝트가 재밌는 이유는, 새로운 모델을 만든 게 아니라 이미 있는 모델을 실제 작업 흐름 안으로 끌어온 방식을 보여주기 때문이다.