Thunderbolt를 ‘모질라가 만든 로컬 우선 엔터프라이즈 AI’로 도입하려면 먼저 프로젝트의 소유 주체와 실제 구현을 저장소에서 확인해야 합니다. 원문에는 이 정체성과 아키텍처를 확정할 릴리스 문서가 충분히 연결돼 있지 않습니다. 따라서 제품 추천보다 주장별 증거표를 만들고 네트워크, 저장, 삭제를 직접 재현하는 것이 먼저입니다.
원문이 가리키는 Thunderbolt 저장소와 Mozilla 조직은 출발점일 뿐입니다. 이름이 비슷하거나 조직과 연관돼 보인다는 이유만으로 제품의 유지보수 주체, 지원 범위, 라이선스를 추론하면 안 됩니다.
원문은 Haystack 기반 추론, MCP와 ACP 연결, SQLite를 진실의 원천으로 삼는 오프라인 우선 구조, 로컬, 클라우드 모델 라우팅을 설명합니다. 이 항목들은 매력적인 설계 설명이지만, 실제 저장소의 의존성 파일과 코드 경로가 뒷받침하는지 각각 확인해야 사실이 됩니다.
| 주장 | 1차 근거로 볼 파일, 동작 | 근거가 되지 않는 것 |
|---|---|---|
| 공식 소유, 지원 | organization, maintainer, 공식 release, 지원 정책 | 이름, logo가 비슷하다는 인상 |
| Haystack 사용 | lockfile dependency, import와 실행 graph | 소개 글의 architecture 그림만 존재 |
| MCP, ACP | client/server 초기화, handshake, test | protocol 링크나 설정 예시만 존재 |
| SQLite SSOT | schema, migration, transaction, 복구 code | .db 파일 하나가 생성됨 |
| local-first | offline 기능 test, network 요청 목록 | UI와 database가 local에 있음 |
| model routing | policy code, fallback, audit 결과 | model 선택 dropdown만 존재 |
증거에는 commit과 release tag를 붙입니다. main branch의 실험 code를 안정 release 기능으로 오인하지 않고, README 문장이 어느 version에서 실제로 작동하는지 examples와 test로 연결합니다. issue나 roadmap에 적힌 기능은 구현 완료와 구분합니다.
프로젝트 소유 주체도 GitHub organization 하나만 보고 끝내지 않습니다. package publisher, domain의 공식 안내, contributor, release signing과 security contact가 서로 일치하는지 봅니다. 기업 지원을 기대한다면 response SLA와 migration 책임이 문서로 있는지 확인하고 없으면 community project로 비용을 계산합니다.
Haystack을 쓴다면 Haystack 패키지와 실행 그래프가 manifest나 lockfile에 나타나야 합니다. MCP를 지원한다면 프로토콜 설명을 인용하는 데 그치지 않고 클라이언트 초기화, 도구 권한, 실패 처리 코드가 있어야 합니다. SQLite 주장은 스키마와 마이그레이션, 동기화 충돌 규칙으로 검증할 수 있습니다.
protocol 지원은 연결 성공만으로 충분하지 않습니다. 어떤 server를 등록할 수 있는지, tool 목록이 사용자, workspace별로 제한되는지, 응답 timeout과 악성 tool description을 어떻게 처리하는지 확인합니다. 외부 MCP server가 local 문서 전체를 요청하거나 write tool을 노출해도 기본 허용되지 않아야 합니다.
dependency가 있다는 사실도 실제 경로가 사용된다는 증명은 아닙니다. 최소 sample을 실행해 call trace를 보고 해당 component가 input에서 output까지 참여하는지 확인합니다. optional flag 뒤에 숨었거나 dead code인 기능을 architecture 장점으로 세지 않습니다.
화면과 데이터베이스가 로컬에 있어도 모델 호출, 검색, 텔레메트리나 플러그인이 외부로 데이터를 보낼 수 있습니다. 네트워크를 끊은 상태에서 어떤 기능이 남는지, 어떤 데이터가 큐에 쌓였다가 나중에 전송되는지 확인해야 합니다. 암호화와 삭제 정책도 저장 위치만큼 중요합니다.
빈 test profile에서 DNS, HTTP 연결을 기록하고 document import, 질의, local model, cloud model 선택, crash reporting을 하나씩 실행합니다. endpoint, 전송 payload 범주와 기능 목적을 표로 남깁니다. proxy가 막혔을 때 반복 retry로 data가 queue에 쌓이는지, 재연결 후 자동 전송되는지도 확인합니다.
“민감하면 local model” 같은 router가 있다면 민감도 분류가 실패했을 때의 기본 경로가 local인지 확인합니다. cloud fallback이 편의를 위해 자동으로 켜지면 outage 때 local-only 정책을 어길 수 있습니다. route decision, model과 전송한 source ID를 audit event로 남기고 사용자가 확인할 수 있어야 합니다.
local database도 같은 OS 계정의 다른 process가 읽을 수 있고 backup, temporary file에 복제될 수 있습니다. database file 권한, encryption key 위치, WAL과 cache의 삭제를 점검합니다. 사용자 삭제가 원문 record뿐 아니라 embedding, search index와 backup 정책에 어떻게 반영되는지도 시험합니다.
여러 장치가 같은 데이터를 수정한다면 SQLite 자체보다 충돌 해결이 핵심입니다. 마지막 쓰기 우선인지, 항목별 병합인지, 사람이 선택하는지에 따라 데이터 손실 방식이 달라집니다. 오프라인에서 만든 변경을 서버와 합친 뒤 원래 상태로 되돌릴 수 있는지도 시험해야 합니다.
충돌 시험은 두 장치를 offline으로 둔 뒤 같은 note의 제목과 본문을 각각 바꾸고 다시 연결하는 방식으로 만들 수 있습니다. 한 변경이 조용히 사라지는지, conflict copy가 생기는지, 사용자에게 diff가 보이는지 기록합니다. attachment 삭제와 편집이 충돌하는 경우, clock이 다른 장치도 포함해야 합니다.
schema migration은 복사한 production 크기의 database에서 실행하고 중간 강제 종료 뒤 이전 version 또는 backup으로 복구되는지 봅니다. migration 완료 표시와 실제 index 상태가 어긋나면 검색 누락이 생길 수 있습니다. 자동 update 전에 backup 검증과 충분한 disk 공간 확인이 필요합니다.
평가용 브랜치에서 의존성을 고정하고 네트워크 요청, 생성 파일, 데이터베이스 변경을 관찰합니다. 샘플 문서 하나를 넣어 인덱싱, 질의, 삭제, 백업, 복원을 수행하고 각 단계의 데이터 위치를 기록합니다. 모델 라우팅이 있다면 민감한 입력이 로컬 경로를 벗어나지 않는지 실패 상황까지 확인합니다.
샘플은 공개 문서와 가짜 민감 marker가 든 문서를 나눕니다. local route가 marker 문서를 cloud에 보내지 않는지, log와 crash report에는 남지 않는지 확인합니다. 질의 답이 맞는지만 보지 말고 source 삭제 뒤 더 이상 검색, 자동완성, backup restore에서 나타나지 않는지 봅니다.
재현 report에는 OS, commit, lockfile hash, model, network 정책과 수행 명령을 남깁니다. 한 번 성공한 demo보다 새 machine에서 같은 결과가 나는지가 중요합니다. build가 release artifact와 다르다면 어떤 patch나 미공개 key가 필요했는지도 도입 위험으로 기록합니다.
라이선스는 저장소의 실제 LICENSE와 포함된 모델, 의존성의 조건을 함께 검토해야 합니다. 프로젝트 이름이나 원문의 MPL 2.0 언급만으로 배포 전체의 의무를 결정할 수 없습니다. 릴리스 태그, 보안 정책, 이슈 응답과 마이그레이션 기록도 장기 운영 가능성을 판단하는 근거입니다.
model weight, embedding model과 bundled asset은 application code와 다른 조건일 수 있습니다. 수정 배포, network service와 상업 사용이라는 실제 방식별로 검토하고 NOTICE, source 제공 의무를 release 과정에 넣습니다. 법률 판단이 필요한 부분은 글의 추측이 아니라 조직의 검토로 확정합니다.
원문의 JSON과 Node.js 조각은 실제 패키지와 연결된 완성 코드가 아니라 개념을 표현한 의사 코드입니다. 해당 클래스와 메서드가 저장소에 존재한다는 확인 없이 복사해서는 안 됩니다. ‘주권형 AI’라는 결론도 그 코드 조각으로 증명되지 않습니다.
결국 이 글에서 가능한 안전한 결론은 조건부입니다. 소유 주체, 로컬 데이터 경계, 프로토콜 구현, 라이선스와 복구 절차가 저장소에서 모두 확인될 때만 파일럿 후보가 됩니다. 하나라도 근거가 없다면 제품 평가보다 출처 검증을 먼저 끝내야 합니다.
파일럿 통과 기준은 “주권형” 같은 추상어가 아니라 offline 핵심 기능 목록, 허용 endpoint 0개 또는 명시된 목록, 삭제, 복구 성공, protocol 최소 권한과 update rollback으로 씁니다. 근거가 없는 기능은 실패가 아니라 미확인으로 표시해 향후 release에서 다시 검증합니다. 이 과정을 거쳐야 이름과 marketing을 architecture 증거로 바꾸는 오류를 피할 수 있습니다.
이 글의 원문만으로는 확정할 수 없습니다. 저장소 owner, maintainer, 공식 발표, release, support 문서와 라이선스를 각각 확인해야 합니다.
아닙니다. model, 검색, telemetry, plugin 호출이 외부로 갈 수 있으므로 네트워크를 차단한 실행과 실제 요청 관찰로 기능별 경계를 확인해야 합니다.
안 됩니다. dependency manifest, import와 실행 경로, protocol handshake, 권한, 오류 처리 및 재현 가능한 test가 있어야 구현 근거가 됩니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.