내 노트북을 떠나지 않는 AI

기업용 AI 워크플로우와 데이터 보안 문제에 대한 해답

어떤 기업에든 유용한 AI 워크플로우를 보여줄 수 있지만, 보안 담당자가 가장 중요한 질문을 던지기 전까지는 순조롭습니다. 바로 "데이터는 어디로 가나요?"라는 질문입니다.

대부분의 주류 어시스턴트(assistant)들의 답변은 '저희가 운영하는 데이터센터로, 읽어보셔야 할 정책 하에'라는 식입니다. 많은 팀들에게는 이 정도면 괜찮을 수 있습니다. 하지만 제가 함께 일하는 곳들—규제가 심한 산업, 고객 기밀 자료, 의견이 포함된 내부 감사 기능 등—에게는 대화를 끝내버립니다. 도구가 나쁘기 때문이 아니라, '예'라고 말하기 위한 서류 작업 비용이 그 도구로 얻을 수 있는 생산성보다 더 비싸기 때문입니다.

그래서 저는 다른 것을 만들었습니다. OnDevice.ai는 내 자체 기기에서 실행되는 개인용 AI 워크스페이스입니다. 채팅 스트리밍, 프로젝트 기반 컨텍스트(context), 파일 분석, 그리고 실제 PowerPoint, Excel, Word 문서 생성까지 가능합니다. 추론(Inference)은 Ollama 또는 LM Studio를 통해 로컬로 실행됩니다. 클라우드는 가정이 아니라 선택 사항일 뿐입니다.

The OnDevice.ai interface: sidebar with projects and chats, backend and model selectors, temperature slider
MacBook에서 30B 모델을 로컬로 실행 중. 백엔드(Backend): Ollama · 모델(Model): Glimmer 30B (GGUF).

바이트 이전에 사양

AI가 PowerPoint 파일을 생성하도록 하는 명백한 방법이 있습니다. 바로 모델에게 요청하는 것입니다. 하지만 이것 역시 좋지 않은 방식입니다. OOXML은 관계 그래프와 콘텐츠 유형 매니페스트(content-type manifests)를 가진 상호 의존적인 여러 XML 파트의 ZIP 파일이며, 단 하나의 잘못된 관계만 있어도 클라이언트가 파일을 열기를 거부하게 만듭니다. 보통 사용자가 더블클릭할 때 발생합니다.

따라서 모델은 절대 바이트에 접근하지 않습니다:

모델은 JSON 중간 사양(intermediate spec)(SlideDeckSpec, WorkbookSpec, DocumentSpec)을 생성하며, 이는 먼저 스키마 검증을 거칩니다.
python-pptx, openpyxl 또는 python-docx를 기반으로 구축된 고정적이고 결정론적인 생성기가 이 사양을 파일로 변환합니다.
구조적 유효성 검사(Structural validation)는 다운로드의 필수 관문입니다 — zip, OOXML 부분, 관계 그래프, 잘 구성된 XML까지 모두 확인합니다. 실패하면 파일은 절대 제공되지 않습니다. LibreOffice 렌더링 검사도 실행되지만, 이는 참고용일 뿐이며 임시 복사본에 격리된 프로세스로만 진행됩니다.

LLM은 대화, 분석 및 계획 언어를 처리합니다. 생성기(Generators)는 바이트를 다룹니다.

그 결과: 다운로드되는 파일은 열리는 파일입니다. '보통' 그런 것이 아닙니다.

의도적으로 평범한 스택의 경계 (One boundary, deliberately ordinary stack)

프론트엔드는 Next.js + TypeScript를 사용하고, 백엔드는 FastAPI + Python을 사용하며, 상태 관리는 PostgreSQL을 사용하고, Redis는 선택 사항이며, 바이너리 파일은 로컬 파일 시스템에 저장합니다. 흥미로운 부분은 이 경계가 어디에 위치하는지, 그리고 기능만큼이나 거절(refusals)을 설명하는 몇 가지 원칙들입니다:

좁은 하우징 (Narrow harness) — 플러그인 생태계보다는 명시적인 서비스들을 사용합니다. 동적으로 실행되는 것은 아무것도 없습니다.
파일 ≠ 지침 (Files ≠ instructions) — 업로드된 파일들은 프롬프트에서 신뢰할 수 없는 것으로 표시되므로, 문서가 시스템에게 무엇을 할지 지시할 수 없습니다.
키는 서버 측에 유지 (Keys stay server-side) — 제공업체(provider)의 비밀 키는 절대로 브라우저에 도달하지 않습니다.

두 개의 로컬 런타임, 정직하게 분리됨 (Two local runtimes, honestly separated)

Ollama는 GGUF를 실행하고; Mac에서 LM Studio는 MLX를 실행합니다. 이들은 상호 교환 가능하지 않으며, 한쪽의 모델 디렉토리를 다른 쪽이 참조하도록 지정하면 혼란스러운 오류가 발생합니다. 따라서 백엔드는 명시적으로 분리되어 유지되며, 모델 카탈로그는 형식별로 필터링되고, GGUF를 LM Studio 라이브러리에서 Ollama에 등록하고 싶은 단 하나의 경우를 위한 브릿지 스크립트가 존재합니다.

출하된 프리셋들은 두 런타임 모두에서 대략 12B부터 80B 파라미터까지 커버하며, 이는 랙(rack)이 아닌 64GB 통합 메모리를 가진 MacBook에서도 작동하는 수준입니다.

필요할 때만 실행되는 검색 (Search that stays off unless it's needed)

로컬 모델은 오늘 아침 뉴스를 자신 있게 지어낼 수 있기 때문에, 선택적인 검색 후 생성(retrieve-then-generate) 기반이 있습니다. 기본 auto 모드에서는 메시지가 실시간처럼 보일 때만—뉴스, 가격, “최신”, URL 등—검색을 수행합니다. 단지 문단을 재구성해달라고 요청하면 기기 밖으로 아무것도 나가지 않습니다. 솔직한 주의사항은 아키텍처 문서에 명시되어 있습니다: 검색이 활성화되면 쿼리가 호스트를 벗어납니다.

Claude와 ChatGPT 대비

순수 능력치만 놓고 보면, Claude와 ChatGPT가 이기며, 그 차이는 결코 가볍지 않습니다. 더 많은 지식, 더 나은 추론 능력, 훨씬 뛰어난 감각을 가지고 있습니다. 30B 모델이 노트북에서 이들을 따라잡는다고 주장하는 사람은 무언가를 팔고 있는 것입니다.

하지만 상업 서비스들은 _능력과 편의성_에 관한 모든 항목에서 승리하고, 그리고 이 제품은 _제어(control)_에 관한 모든 항목에서 승리합니다: 데이터가 어디로 가는지, 한계 비용(전기), 오프라인 사용 여부, 모델 선택권, 검색 동작 방식, 감사 가능성(auditability).

제가 생각하는 방식은 이렇습니다. 최첨단 비서(frontier assistant)는 높은 천장과 없는 바닥을 가집니다. 반면 이것은 낮은 천장과 단단한 바닥을 가지고 있습니다. 그 바닥은 파이프라인에 의해 설정되며 움직이지 않습니다. 천장은 오늘 아침 제가 로드한 어떤 모델에 의해 설정되는데—따라서 오픈 웨이트(open-weight) 모델이 개선될 때마다, 제가 코드를 한 줄도 작성하지 않아도 올라갑니다. 바닥을 소유하고, 다운로드를 통해 천장이 오도록 내버려 두십시오.

의도적으로 하지 않을 것들

컴퓨터 사용, 브라우저 자동화, MCP 서버 또는 타사 커넥터, 다중 에이전트 오케스트레이션, 사용자 대상 코드 실행은 없습니다. 이 모든 것은 제가 가지고 있으면 좋을 능력치입니다. 하지만 동시에 매우 자신감 있는 텍스트 예측기의 폭발 반경(blast radius)을 넓히기도 합니다.

큰 신뢰 경계(trust boundary)를 가질 수도 있고 작은 폭발 반경을 가질 수도 있습니다. 작은 것을 선택하는 것은 한계가 아니라 하나의 입장입니다.

현재 위치

이것은 출시된 제품이 아니라 라이브 빌드(live build)입니다: 대략 19,000줄의 코드, 120개의 문서화된 기능, 19개의 테스트 모듈, 그리고 현재 아키텍처 문서가 있습니다. 문서 생성은 현재 가장 취약한 부분입니다—최첨단 모델로 만든 자료가 여전히 더 좋아 보입니다. 왜냐하면 콘텐츠 기획이 더 강력한 모델에서 나오기 때문입니다.

이미 작동하는 부분은 제가 처음에는 확신하지 못했던 부분이었습니다. 바로 노트북에서 프로젝트, 스트리밍 채팅, 파일, 아티팩트(artifacts), 필요할 때 검색 기능까지 모두 갖춘 실제 AI 작업 공간입니다. 이 모든 것이 기기를 벗어나지 않습니다.

이것을 구축하는 과정은 또한 제가 전체 스택—인증(auth), 스트리밍(streaming), 오케스트레이션(orchestration), 생성(generation), 검증(validation)—을 배울 수 있는 가장 좋은 방법이었습니다. 이는 호스팅된 API가 숨겨두는 부분들입니다. 이러한 '직접 해보며 배우기(learn-by-doing)' 접근 방식에 대해 저는 Curious Bit에서 글을 쓰고 있습니다.

아키텍처 다이어그램, 모델 표, 벤치마크 주의사항 및 전체 비교가 담긴 전체 빌드 노트는 여기에서 확인할 수 있습니다: 내 노트북을 떠나지 않는 AI — 전체 작성기

원래 Curious Bit에 게시되었습니다.