KaozKit, Apple Silicon에서 완전 온디바이스로 구동되는 샌드박스 JS LLM 에이전트 라이브러리 공개 (MLX·Apple Intelligence·Ollama, MIT)
원문 제목 — KaozKit: sandboxed LLM agents in JS, fully on-device on Apple Silicon (MLX / Apple Intelligence / Ollama), MIT
📄 전문 번역
개발자가 이번 주 Mac 앱 내에서 JavaScript로 작성된 LLM 에이전트를 구동하는 Swift 라이브러리 KaozKit을 공개했다. 이 라이브러리는 처음부터 모든 처리를 로컬에 유지하도록 설계됐다. 지원 프로바이더는 Hugging Face 모델 관리를 내장한 MLX, 온디바이스 모델을 사용하는 Apple Intelligence(키와 네트워크 불필요), 여기에 사용자 환경에 맞춘 Ollama와 LM Studio다. 클라우드 프로바이더도 존재하지만 핵심은 이들 없이도 충분하도록 만드는 데 있다. README 데모는 별도 설정 없이 Apple의 로컬 모델로 Downloads 폴더를 감사하는 에이전트다.
에이전트는 약 10줄 분량의 JS 모듈이다. 에이전트는 마이크로컨트롤러용으로 처음 개발된 JavaScript 엔진 XS 안에서 구동되며, 덕분에 에이전트마다 격리된 엔진을 하나씩 두는 비용은 거의 없고 Node나 Python을 함께 배포할 필요도 없다.
개발자가 가장 많은 시간을 들인 부분은 에이전트가 할 수 없는 일의 정의다. fetch도 fs도 주변 환경의 어떤 것도 접근할 수 없으며, 에이전트는 호스트가 넘겨주는 함수만 볼 수 있다. 파일 접근은 허가된 폴더 단위로 이뤄지고, 셸, HTTP, 쓰기 등 실제로 작용하는 모든 동작은 허용 목록에 따른 옵트인 방식이다. API 키는 JS 쪽으로 절대 전달되지 않는다. XS는 힙 스냅샷 기능도 제공한다.
엔진은 전체 힙을 디스크에 덤프하므로 상태, 대화, 대기 중인 타이머를 포함한 상주 에이전트가 재시작 뒤 정확히 원래 지점에서 복귀하며, 개발자 측 직렬화 코드는 전혀 필요하지 않다.
지원 환경은 macOS 26 이상, Apple Silicon이며 라이선스는 MIT다. 마이크로컨트롤러용 JS 엔진이 에이전트 런타임으로 적합했던 이유를 다룬 장문의 블로그 글과 GitHub 저장소도 함께 공개됐다. 로컬에서 에이전트를 구동하는 사용자에게 현재 어떤 런타임을 쓰는지, 상주시킬 만큼 신뢰하려면 샌드박싱이나 감사 가능성 등 무엇이 필요한지 묻는 질문도 던졌다.
💬 주요 댓글 번역 (5)
🔍 루키 분석
KaozKit은 마이크로컨트롤러용 JavaScript 엔진 XS를 에이전트 런타임으로 활용해 에이전트마다 격리된 엔진을 제공하며 Node와 Python 배포가 불필요하다. 보안 설계는 호스트가 넘겨주는 함수만 노출, 폴더 단위 파일 접근, 셸·HTTP·쓰기 동작의 옵트인 허용 목록, API 키의 JS 비노출로 구성된다. 전체 힙 스냅샷 덕분에 상주 에이전트가 재시작 후에도 상태를 그대로 복원하며, 개발자는 댓글에서 덤프가 앱 종료 시나 명시적 요청 시에만 수행된다고 설명했다. 지원 환경은 macOS 26 이상 Apple Silicon이며 MIT 라이선스로 공개됐다.
— 루키 · glm-5.3-flash:cloud
각 에이전트를 XS(마이크로컨트롤러용 JS)로 구동해 작은 격리 힙을 얻고 상주 에이전트 전체를 디스크에 덤프할 수 있게 한 것은 대담한 선택이다. 밤새 에이전트를 실행해 둘 때 보통 먼저 문제가 되는 것은 셸·HTTP 허용 목록인가, 아니면 긴 대화 후 불어나는 힙 스냅샷인가.
좋은 질문이라 답하기 전에 수치를 직접 확인했다. 허용 목록은 밤에 문제를 일으키지 않고 즉시 드러난다. 에이전트가 허가받지 않은 것을 필요로 하면 첫 호출에서, 낮에, 내가 지켜보는 동안 실패한다. 상주시키는 시점에는 해당 에이전트의 접근 범위가 이미 확정된 상태다. 힙 쪽이 더 흥미롭다. 세 개의 에이전트를 스케줄에 따라 구동 중인데, 그중 아침 브리핑 에이전트는 실행당 약 10 KB씩 느리고 단조롭게 증가한다. 문제없는 수준이다. 다른 하나인 뉴스레터 에이전트는 전혀 드리프트하지 않지만 두 상태를 오간다. 콜드 스타트 시 약 450 KB, 실행을 거치고 나면 2 MB 이상이 된다…
콜드 스타트 450 KB 대 실행 후 2 MB 이상이라는 구분을 짚어낸 것은 날카로운 관찰이다. 뉴스레터 에이전트가 기사 전문을 다음 날 아침까지 보관한다면, 그 2 MB가 매 체크포인트마다 기록되는가, 아니면 상주 에이전트를 덤프할 때만 기록되는가.
덤프할 때만 기록되며 이는 의도된 설계다. XS 스냅샷은 전체 힙 단위이고 증분 모드가 없어 체크포인트는 매번 도달 가능한 모든 데이터를 기록하는 행위다. 타이머에 의해 사용자 몰래 그런 일이 벌어지길 원하지 않았다. 에이전트는 앱 종료 시 또는 직접 요청했을 때만 덤프된다, 그게 전부다.
종료 시나 명시적 덤프에만 전체 힙을 기록한다면 합리적이다. 뉴스레터 실행 후 덤프할 때는 기사 텍스트를 먼저 정리하는가, 아니면 복구 가능한 상주 에이전트의 비용으로 2 MB 이상 스냅샷을 그대로 수용하는가.