로컬 AI 데모 루프는 유혹적입니다. 모델을 노트북에 맞게 구동하고, 실행되는 모습을 보여주며, 어려운 부분이 해결되었다고 선언하는 것입니다.

제품 리뷰는 그만큼 즐겁지 않습니다. 메모리를 얼마나 소비할 수 있는가? 중간 파일은 어디로 가는가? 사용자가 결과를 편집할 수 있는가? 에이전트가 무엇을 건드릴 수 있는가? 작업이 올바르게 완료되었음을 어떻게 알 수 있는가?

"로컬에서 실행된다"는 말은 이 질문들 중 그 어느 것도 답해주지 않습니다. 그것은 단지 하나의 연산이 어디서 일어났는지만을 알려줄 뿐입니다.

로컬 우선 (Local-first) 방식은 전체 워크플로우 (workflow) 동안 생존해야 합니다. 모델 호출, 인터페이스 (interface), 파일, 도구, 승인, 내보내기, 그리고 완료 증거 모두에 경계 (boundaries)가 필요합니다. 하나라도 놓치면, 아키텍처 (architecture)는 제품 상자에 붙은 라벨과 조용히 모순될 수 있습니다.

로컬리티 (Locality)의 6가지 경계

모델이나 프레임워크 (framework)를 선택하기 전에, 다음 계약을 작성하십시오:

1. 리소스 경계 (Resource boundary): 해당 기능이 소비할 수 있는 메모리, 연산 (compute), 저장소 및 대기 시간은 어느 정도인가?
2. 상주 경계 (Residency boundary): 어떤 입력값과 중간 산출물 (intermediate artifacts)이 장치에 머무는가? 어떤 네트워크 의존성 (network dependencies)이 남아 있는가?
3. 핸드오프 경계 (Handoff boundary): 생성 결과로 반환되는 편집 가능한 산출물 (editable artifact)은 무엇인가?
4. 인터페이스 경계 (Interface boundary): 어떤 상태 전이 (state transitions)와 동작이 명시적이고 테스트 가능한가?
5. 권한 경계 (Authority boundary): 에이전트 (agent)가 승인 없이 읽고, 변경하고, 호출하거나 게시할 수 있는 것은 무엇인가?
6. 증거 경계 (Evidence boundary): 단계가 완료되었음을 증명하는 보고서, 차이 (diff), 내보내기 (export), 추적 (trace) 또는 테스트 결과는 무엇인가?

이것은 벤더 표준 (vendor standard)이 아닙니다. 이것은 아키텍처 리뷰 (architecture-review)를 위한 지름길입니다. 만약 팀이 이 질문 중 하나라도 답할 수 없다면, 그것은 문서화의 문제가 아니라 해결되지 않은 제품 결정 사항을 발견한 것입니다.

리소스 엔벨로프 (resource envelope)부터 시작하십시오

로컬 모델에 대한 논의는 종종 단 하나의 숫자로 수렴하곤 합니다: 얼마나 작은 VRAM에 얼마나 큰 모델을 맞출 수 있는가.

AirLLM과 같은 프로젝트는 제한된 VRAM 환경에서 매우 큰 모델의 실행을 문서화함으로써 그 제약을 가시화합니다. 그것은 유용한 엔지니어링 (engineering)입니다. 하지만 그것이 제품 팀에게 해당 기능이 사용 가능한지 여부를 여전히 알려주지는 않습니다.

"실행 가능하다"와 "이 워크플로우를 지원할 수 있다"는 서로 다른 주장입니다. 후자는 다음과 같은 결정이 필요합니다:

• 대화형 동작 (interactive action)을 위해 허용 가능한 대기 시간
• 모델 가중치 (model weights) 및 생성된 아티팩트 (artifacts)를 위해 사용 가능한 저장 공간
• 동시에 장치에서 실행되어야 하는 다른 요소들
• 리소스 한계 (resource ceiling)에 도달했을 때 기능이 작동하는 방식
• 애플리케이션 큐 (queues)가 작동하는지, 성능이 저하되는지, 아니면 눈에 띄게 중단되는지 여부

이것들은 라우팅 (routing) 및 UX 결정 사항입니다. 기술적으로 로드될 수 있는 모델이라 할지라도, 즉각적인 상호작용 경로 (hot interaction path)에는 부적합할 수 있습니다. 반면, 진행 상태가 시각적으로 표시되는 큐 대기 작업 (queued task)의 경우에는 더 느린 로컬 경로가 완벽하게 합리적일 수 있습니다. 하드웨어 한계가 제품 디자인을 결정하는 것이 아니라, 제품 디자인을 명시적으로 만들도록 강제하는 것입니다.

상주 경계 (residency boundary) 또한 동일한 정밀함이 필요합니다. 텔레메트리 (telemetry), 검색 (retrieval), 인증 (authentication), 에셋 저장 (asset storage) 또는 후속 처리 단계가 여전히 네트워크를 사용하는 동안에도 모델은 온디바이스 (on-device)에서 실행될 수 있습니다. 그것은 수용 가능한 시스템일 수 있습니다. 다만, 광범위한 "로컬"이라는 주장 뒤에 숨어서는 안 됩니다.

모든 입력, 중간 아티팩트 (intermediate artifact), 그리고 외부 요청을 매핑하십시오. 그런 다음 실제로 구축한 경계를 설명하십시오.

생성은 인계 (handoff)가 아니다

가공되지 않은 모델의 응답이 실제 워크플로우의 끝인 경우는 드뭅니다.

MiniMax H3의 ComfyUI 통합은 모델 가용성(availability)의 단계를 넘어 논의를 한 단계 더 진전시킵니다. 이번 발표는 오픈 웨이트 (open-weight) 멀티모달 모델, 네이티브 스테레오 오디오, 2K 비디오를 로컬의 최적화된 ComfyUI 경로와 결합했습니다. 모델도 중요하지만, 그 주변의 운영 워크플로우 (operator workflow) 또한 중요합니다. 결과물이 검사, 수정, 내보내기(export) 및 다음 제작 단계로 넘어갈 수 있을 때 생성은 더욱 유용해집니다.

훌륭한 인계 (handoff)는 편집 가능하며 지루해야 합니다. 그것은 비디오와 오디오 트랙일 수도 있고, 정지 이미지, 프로젝트 그래프, 구조화된 명세서(specification), 또는 내보낸 파일 세트일 수도 있습니다. 적절한 아티팩트 (artifact)는 작업에 따라 달라집니다. 복구 가능한 상태가 없는 최종 미리보기는 대개 멋진 UI를 입고 있는 막다른 길일 뿐입니다.

생성된 썸네일이나 비디오 스틸(video still)을 생각해 보십시오. 생성 단계는 로컬(local)에서 이루어질 수 있지만, 게시를 위해서는 여전히 결정론적인(deterministic) 크기와 제작자가 검사할 수 있는 내보내기(export) 기능이 필요합니다. Instagram 에셋의 경우, Resize Image for Instagram은 정사각형, 세로형, 가로형, Story 및 Reel 프리셋에 대해 브라우저 로컬(browser-local) 방식의 맞춤(fit), 채우기(fill), 미리보기(preview) 및 내보내기(export)를 제공합니다. 이는 작은 단계이지만, 워크플로(workflow)의 핵심을 보존합니다. 즉, 이미지는 게시하기 전에 사용자가 보고 제어할 수 있는 아티팩트(artifact)로 남습니다.

여기 더 가혹한 핸드오프(handoff) 테스트가 있습니다: 생성 후에 모델을 제거해 보십시오. 만약 사용자가 모델이 반환한 결과물만으로 작업을 계속할 수 없다면, 해당 기능은 내구성이 있는 아티팩트(durable artifact)가 아니라 다른 모델 호출에 대한 의존성(dependency)을 생성한 것입니다.

로컬 퍼스트(Local-first)에는 프론트엔드도 포함됩니다

개발자들은 때때로 모델의 배치에는 엄격함을 적용하면서, 인터페이스는 프롬프트 박스 주변의 스크린샷처럼 취급하곤 합니다.

이는 우선순위를 거꾸로 잡는 것입니다. 로컬 시스템은 더 눈에 띄는 리소스 제한, 더 오래 걸리는 작업, 부분적인 결과, 그리고 설명해야 할 더 많은 실패 상태(failure states)를 가집니다. 따라서 로컬 시스템의 프론트엔드(frontend)에는 더 예쁜 로딩 애니메이션이 아니라, 더 강력한 상태 모델(state model)이 필요합니다.

Bonsai는 반대의 경로를 택합니다. Bonsai는 함수형 상태 머신(functional state machines), 점진적 재계산(incremental recomputation), 그리고 실행 가능한 DOM 동작 테스트(executable DOM behavior tests)를 통해 반응형 웹 애플리케이션(reactive web applications)을 모델링합니다. 이것이 모든 로컬 AI 제품이 Bonsai나 OCaml을 사용해야 한다는 의미는 아닙니다. 다만

• 영감(inspiration)은 어떤 종류의 인터페이스가 유용할지를 결정합니다.
• 생성(generation)은 허용된 표면(surface)을 선택하거나 구성합니다.
• 애플리케이션이 상태(state)와 권한(permissions)을 소유합니다.
• 행동 테스트(behavioral tests)는 중요한 전이(transitions)를 증명합니다.

긴 로컬 작업의 경우, 워크플로우에 해당 상태들이 존재한다면 인터페이스는 대기 중(queued), 로딩 중(loading), 생성 중(generating), 승인 대기 중(awaiting approval), 내보내는 중(exporting), 완료됨(completed), 중단됨(interrupted), 실패함(failed) 상태를 구분할 수 있어야 합니다. 이 상태들을 하나의 스피너(spinner)와 희망적인 성공 토스트(success toast) 메시지로 뭉뚱그려 버리지 마십시오.

그럴듯해 보이는 화면은 증거가 될 수 없습니다. 사용자는 무엇이 일어났는지, 무엇이 여전히 변경 가능한지, 그리고 시스템이 다음에 무엇을 기대하는지 알아야 합니다.

로컬 실행이 안전한 권한을 부여하는 것은 아니다

모델이 어디에서 실행되는지와 에이전트(agent)가 무엇을 할 수 있는지는 별개의 결정 사항입니다.

Nightcrawler의 문서화된 설계는 이 질문들을 분리하여 유지합니다. 이는 로컬 모바일 에이전트 주변에 스코프 프록시(scope proxy), 소규모 단계 루프(small-step loop), 대시보드(dashboard), 그리고 구조화된 보고서(structured report)를 배치합니다. 이 요소들이 결합되어 허용된 표면을 정의하고, 진행 상황을 노출하며, 운영자가 나중에 검사할 수 있는 무언가를 남깁니다.

프로젝트 문서는 독립적인 보안 감사(security audit)가 아니며, 이 패턴이 안전을 보장하는 것도 아닙니다. 빌려올 가치가 있는 것은 설계의 형태입니다. 즉, 로컬리티(locality)가 권한 부여(authorization)의 대체제로 사용되지 않는다는 점입니다.

로컬 에이전트는 여전히 잘못된 파일을 삭제하거나, 의도하지 않은 도구(tool)를 호출하거나, 너무 일찍 게시하거나, 작업 범위보다 넓은 자격 증명(credentials)으로 작동할 수 있습니다. 추론(inference)을 온디바이스(on-device)에서 수행한다고 해서 스코프가 지정된 기능(scoped capabilities)과 승인 게이트(approval gates)의 필요성이 줄어드는 것은 아닙니다.

권한 경계(authority boundary)를 형용사가 아닌 작업(operations)으로 작성하십시오:

may_read:
  - project/media/inbox/**
may_write:
...

정확한 구문은 중요하지 않습니다. 테스트 기준은 런타임(runtime)이 정책을 강제할 수 있는지, 그리고 인터페이스가 사용자로 하여금 에이전트의 이력을 재구성하게 만들지 않고도 승인 요청을 설명할 수 있는지 여부입니다.

영수증(Receipts)은 제품의 일부이다

완성된 애니메이션이 다단계 작업(multi-step job)이 완료되었다는 증거는 아닙니다.

미디어 워크플로(media workflow)의 경우, 영수증(receipt)에는 소스 아티팩트(source artifact), 생성 설정(generation settings), 내보낸 파일(exported files), 실패한 출력물(failed outputs), 그리고 결과가 기록된 디렉터리가 명시될 수 있습니다. 코딩 에이전트(coding agent)의 경우, 이는 diff와 테스트 결과가 될 수 있습니다. 인터페이스 생성 에이전트(interface-generating agent)의 경우, 수락된 컴포넌트 사양(component specification)과 동작 확인(behavioral checks)이 될 수 있습니다.

영수증의 범위를 좁게 유지하십시오. 기본적으로 모든 프롬프트(prompt), 이미지, 그리고 중간 상태(intermediate state)를 기록하는 것은 두 번째 데이터 처리 문제(data-handling problem)를 야기할 수 있습니다. 검토자가 작업을 검증하는 데 필요한 사항만 캡처하고, 민감한 값은 비식별화(redact)하며, 해당 증거에 대해 보존 정책(retention policy)을 적용하십시오.

이 지점이 바로 로컬 우선(local-first) 주장이 검증 가능한 지점이기도 합니다. 영수증은 어떤 단계가 온디바이스(on-device)에 머물렀는지, 어떤 네트워크 호출(network calls)이 발생했는지, 어떤 승인(approvals)이 이루어졌는지, 그리고 어떤 아티팩트(artifact)가 최종 경계를 넘어갔는지를 기록할 수 있습니다. 설정(Configuration)은 의도를 설명하지만, 영수증은 실행(run)을 설명합니다.

스택을 선택하기 전에 계약(contract)을 적용하라

짧은 영상을 생성하고 소셜 게시를 위한 스틸 이미지를 준비하는 가상의 로컬 크리에이터 도구를 가정해 봅시다. 이 예시는 위에 언급된 어떤 프로젝트에 대한 주장도 아닙니다.

팀은 모델에 대해 논쟁하기 전에 다음 여섯 가지 질문에 답할 수 있어야 합니다:

1. 리소스(Resources): 어떤 디바이스 엔벨로프(device envelope)가 지원되며, 생성이 이를 초과할 경우 어떤 일이 발생하는가?
2. 상주성(Residency): 프롬프트, 소스 미디어, 미리보기, 그리고 내보내기 결과가 로컬에 머무는가? 어떤 확인 절차나 서비스가 여전히 네트워크 연결을 필요로 하는가?
3. 인계(Handoff): 사용자가 편집 가능한 미디어와 예측 가능한 내보내기 결과물을 받는가, 아니면 렌더링된 미리보기만 받는가?
4. 인터페이스(Interface): UI가 상태(state)를 잃지 않고 부분적인 출력, 취소, 승인, 재시도 및 실패를 나타낼 수 있는가?
5. 권한(Authority): 에이전트가 파일을 준비할 수는 있지만, 승인 없이 소스를 게시하거나 덮어쓸 수는 없는가?
6. 증거(Evidence): 실행이 발생한 일을 명시하는 내보내기 매니페스트(export manifest) 또는 보고서로 종료되는가?

벤치마크 점수(benchmark score)는 이 질문들 중 그 어느 것에도 답하지 못합니다.

벤치마크(Benchmarks)는 워크플로(workflow)가 정의된 이후에 구현 방식을 선택하는 데 도움을 줄 수는 있습니다. 하지만 벤치마크가 여러분을 위해 워크플로를 정의해 줄 수는 없습니다. 인상적인 하드웨어 데모(hardware demo) 역시 마찬가지입니다.

로컬은 전체 체인(chain)이다

일관성 있는 로컬 우선(local-first) 제품은 일련의 작고 검증 가능한 약속들을 수행합니다. 자원의 한계(resource ceiling)를 명시하고 데이터가 어디로 이동하는지 보여줍니다. 사용자가 편집할 수 있는 결과물(artifact)을 반환합니다. 프론트엔드(frontend)는 상태(state)를 노출하고, 런타임(runtime)은 에이전트(agent)가 할 수 있는 일을 제한하며, 워크플로는 작업이 끝났을 때 증거를 남깁니다.

로컬에서 실행되는 모델 하나가 다른 곳에서 이러한 약속들을 깨뜨리는 워크플로를 구원할 수는 없습니다. 그 시점에서 로컬 실행은 아키텍처(architecture)라기보다는 배치 세부 사항(placement detail)에 불과합니다.

팀에게 모델 벤치마크를 언급하지 말고 이 여섯 가지 경계(boundaries)를 모두 설명해 보라고 요청하십시오. 만약 답변이 여전히 VRAM으로 시작한다면, 아키텍처 리뷰(architecture review)가 완료되지 않은 것입니다.

출처 노트 (Source notes)

• AirLLM
• MiniMax H3 Day-0 Support in ComfyUI
• Bonsai
• Nightcrawler