Project N.O.M.A.D는 AI, 위키, 지도와 교육 자료를 한 로컬 서버에 미리 담아 인터넷 없이 제공하는 구성입니다. 다만 연결이 끊긴 뒤 설치하는 시스템이 아니므로 모델, 이미지, 데이터와 복구 문서를 온라인일 때 받아 실제 단절 훈련까지 마쳐야 합니다.
인터넷이 끊겨도 AI, 지도, 위키를 쓰려면: Project N.O.M.A.D 준비법
오프라인 기능은 여러 로컬 서비스를 묶어 만든다
Project N.O.M.A.D 저장소는 Ollama로 로컬 LLM을 실행하고 Qdrant에서 문서를 검색하는 AI 기능을 중심에 둡니다. Kiwix는 Wikipedia 같은 오프라인 자료를 제공하고, ProtoMaps와 OSM 데이터는 지도, Kolibri는 교육 콘텐츠, CyberChef는 데이터 처리 도구를 맡습니다.
한 앱이 모든 기능을 직접 구현하는 것이 아니라 검증된 오픈소스 서비스를 로컬 네트워크 안에 조합하는 구조입니다. 필요한 모듈만 고를 수 있지만 각 서비스의 이미지, 데이터 파일, 라이선스와 업데이트 주기를 따로 관리해야 합니다.
먼저 어떤 기능을 오프라인으로 남길까
AI, 위키, 지도와 교육 자료를 모두 최대 규모로 담으면 저장공간, 전력과 관리 부담이 빠르게 늘어납니다. 실제 단절 시나리오에서 누가 어떤 질문과 작업을 수행할지부터 적는 편이 낫습니다. 의료, 안전처럼 최신성이 중요한 지식, 지역 지도, 장비 매뉴얼과 일반 백과를 같은 우선순위로 두면 핵심 자료가 오래된 대용량 콘텐츠에 묻힐 수 있습니다.
기능별로 필수, 유용, 선택으로 나누고 필요한 언어와 지역 범위를 정합니다. AI 모델은 큰 모델 하나뿐 아니라 낮은 전력에서 동작할 대체 모델을 준비할 수 있습니다. 지도는 전 세계 고해상도보다 실제 활동 지역과 대피 경로가 우선일 수 있습니다. 사용 목적을 좁히면 백업과 검증해야 할 파일도 줄어듭니다.
콘텐츠 목록에는 출처, 버전, 생성, 다운로드 시각, 용량, 체크섬과 라이선스를 남깁니다. 웹 화면에서 파일이 보인다는 것만으로 내부 검색과 모델이 실제 사용 가능한지 알 수 없습니다. 각 자료에 대표 질의를 만들어 다운로드 직후와 복원 뒤에 같은 결과가 나오는지 확인해야 합니다.
작업 큐와 Command Center가 무거운 처리를 분리한다
원문은 LangChain이나 CrewAI 대신 TypeScript로 RAG, 도구, 메모리와 서비스 오케스트레이션을 구현했다고 설명합니다. queue_service.ts를 중심으로 문서 임베딩과 모델 다운로드 같은 작업을 백그라운드 큐에 넣어, 큰 파일을 처리하는 동안 관리 화면이 멈추지 않게 합니다.
Docker 컨테이너로 서비스를 격리하고 Command Center UI에서 상태와 생명주기를 관리합니다. install_nomad.sh와 8080 포트 접속도 원문에 나오지만 버전이 고정되지 않은 2026년 3월 스냅샷입니다. 실행 전에 저장소의 현재 요구 조건과 스크립트 내용을 읽고, 별도 시험 장비에서 설치해야 합니다.
로컬 서비스의 의존성은 어디서 끊길까
관리 화면이 열려도 Qdrant 인덱스가 준비되지 않았거나 모델 가중치가 없으면 AI 질의는 실패할 수 있습니다. Kiwix 자료는 존재하지만 검색 인덱스가 손상될 수 있고, 지도 타일은 일부 확대 수준만 내려받았을 수 있습니다. 컨테이너의 실행 상태와 사용자가 기대하는 기능 성공을 같은 것으로 보지 않아야 합니다.
차가운 부팅에서 서비스 시작 순서와 준비 시간을 기록합니다. 저장소가 먼저 준비되지 않았을 때 작업 큐가 안전하게 기다리는지, 실패한 임베딩 작업이 재부팅 뒤 중복 실행되는지 봅니다. 디스크가 가득 차거나 한 컨테이너가 반복 종료될 때 관리 UI가 원인과 복구 단계를 보여 주는지도 중요합니다.
내부 DNS, 시스템 시간과 인증서가 인터넷 없이 유지되는지도 시험합니다. 외부 시간 서버에만 의존하면 재부팅 뒤 인증이나 로그 순서가 깨질 수 있습니다. 외부 로그인이나 라이선스 확인이 필요한 서비스가 있다면 완전 에어갭의 핵심 기능에서 제외하거나 로컬 대안을 준비해야 합니다.
랜선을 뽑기 전에 준비할 것
오프라인 준비는 설치 성공보다 복구 가능성을 확인하는 일입니다.
- 필요한 컨테이너 이미지, LLM 가중치, Kiwix 자료와 지도 범위를 목록으로 만듭니다.
- 파일 크기와 체크섬을 기록하고 두 번째 저장장치에 복제합니다.
- DNS와 인터넷을 끈 상태에서 부팅, 검색, 지도와 AI 질의를 시험합니다.
- 컨테이너 하나를 중지한 뒤 로컬 문서만 보고 복구해 봅니다.
- 업데이트 파일을 외부에서 내부로 옮길 절차와 검증 책임자를 정합니다.
“로컬에서 돈다”는 설명만으로 외부 통신이 없다고 단정하지 말고 시작 시 연결 시도와 로그를 확인해야 합니다. 완전한 에어갭에서는 인증, 시간 동기화와 업데이트도 평소와 다르게 작동할 수 있습니다.
업데이트 파일은 어떻게 안전하게 옮길까
오프라인 시스템도 모델, 지도와 보안 패치를 갱신해야 하지만 직접 인터넷에 연결하면 단절 경계를 약화시킬 수 있습니다. 외부 장비에서 파일을 받고 출처와 체크섬을 확인한 뒤 검역된 매체로 옮기는 절차를 정합니다. 누가 승인하고 어느 버전에서 어느 버전으로 바꾸는지 기록합니다.
새 이미지를 바로 기존 컨테이너에 덮어쓰지 않고 시험 장비에서 데이터 마이그레이션과 대표 기능을 검증합니다. 업데이트가 실패할 때 이전 이미지와 볼륨으로 되돌릴 수 있어야 합니다. 모델과 인덱스 형식이 함께 바뀌면 한쪽만 복구해도 서비스가 열리지 않을 수 있으므로 의존 버전을 묶어 보관합니다.
이동식 저장장치 자체도 단일 실패점입니다. 두 개 이상의 복제본을 다른 위치에 두고 정기적으로 읽기 검사와 복원 훈련을 합니다. 체크섬은 전송 손상을 찾지만 공급 출처가 안전하다는 보장은 아니므로 공식 배포 위치와 서명 등 프로젝트가 제공하는 검증 방법을 현재 버전에서 확인해야 합니다.
하드웨어와 콘텐츠 범위가 현실적인 상한이다
원문이 제시한 권장 사양은 Ryzen 7 또는 Intel i7 이상, RAM 32GB와 NVIDIA RTX 3060 이상입니다. AI 응답 품질을 얻는 대신 전력과 냉각 요구가 커져 재난이나 이동 환경에서는 오히려 약점이 될 수 있습니다. 사용할 모델 크기와 동시에 켤 서비스를 줄여 전력 예산과 성능을 맞춰야 합니다.
Wikipedia 덤프, 고해상도 지도, 교육 자료와 여러 모델을 함께 저장하면 수백 GB가 필요할 수 있습니다. 기본 콘텐츠가 영미권 중심이라는 원문의 지적도 있으므로 한국어 자료와 실제 활동 지역의 지도 범위를 직접 확인해야 합니다.
전력과 성능을 어떤 조건에서 측정할까
벽 전원이 안정적인 사무실에서의 속도만 보면 정전, 이동 환경의 상한을 알 수 없습니다. 유휴, AI 추론, 임베딩과 지도 사용이 겹친 순간의 소비 전력과 온도를 각각 재고 배터리나 발전기로 몇 시간 유지되는지 계산합니다. GPU가 과열되거나 전압이 불안정할 때 서비스가 손상 없이 종료되는지도 시험합니다.
큰 모델의 답변 품질과 전력 사용을 작은 모델, 검색만 사용한 답변과 비교합니다. 단절 상황에서는 느린 고품질 답 한 번보다 여러 사용자가 동시에 기본 정보를 찾는 처리량이 중요할 수 있습니다. 기능별 동시 사용자 수와 허용 지연을 정하고, 전력이 부족할 때 끌 서비스의 순서를 문서화합니다.
저장장치도 전력과 내구성에 영향을 줍니다. 대용량 인덱싱 중 임의 전원 차단을 안전한 시험 환경에서 재현하고 파일 시스템과 Qdrant 데이터가 복구되는지 확인합니다. 단순 UPS 용량 계산뿐 아니라 정상 종료 신호와 자동 재시작 정책까지 있어야 하드웨어 사양이 실제 회복력으로 이어집니다.
Docker 장애를 인터넷 없이 고칠 수 있어야 한다
Command Center가 편해도 바닥에는 여러 컨테이너, 볼륨과 내부 네트워크가 있습니다. 완전 오프라인 상태에서 이미지가 손상되거나 포트, 권한 문제가 생기면 검색 도움 없이 해결해야 합니다. 상태 확인, 로그 읽기, 볼륨 백업과 전체 복원을 종이 또는 로컬 문서로 남기는 이유입니다.
프로젝트 사이트는 구성을 파악하는 참고 자료지만, 실제 독립성은 자신의 장비에서 단절 시험을 통과했는지로 판단해야 합니다. Project N.O.M.A.D의 가치는 클라우드가 사라져도 자동으로 모든 것을 해결한다는 데 있지 않고, 필요한 지식 서비스를 미리 소유하고 운영하는 구조를 제공하는 데 있습니다.
복구 훈련은 어떤 순서로 끝내야 할까
먼저 인터넷과 외부 DNS를 차단한 상태에서 전원을 완전히 끈 뒤 다시 부팅합니다. 준비 완료까지 걸린 시간과 실패한 서비스를 기록하고 AI, 문서 검색, 지도와 교육 자료의 대표 작업을 수행합니다. 이어서 한 컨테이너를 중지하고 로컬 운영 문서만으로 복구합니다. 마지막에는 백업 장치에서 새 디스크로 데이터와 설정을 복원합니다.
훈련 중 필요한 비밀번호, 명령과 포트가 온라인 문서에만 있다면 오프라인 준비는 실패입니다. 종이 또는 로컬 문서에 장비별 복구 절차, 책임자와 대체 연락 방법을 남깁니다. 숙련된 설치자뿐 아니라 다른 운영자가 문서를 따라 같은 결과를 얻는지 확인해야 합니다.
성공 기준에는 기능뿐 아니라 시간이 들어가야 합니다. 전원 복구 후 핵심 검색을 언제 사용할 수 있는지, 손상된 인덱스를 얼마나 빨리 복원하는지, 백업이 어느 시점까지의 자료를 담는지를 정합니다. 한 번의 훈련을 통과해도 콘텐츠와 이미지가 갱신될 때마다 다시 수행해야 합니다. 오프라인 독립성은 설치 상태가 아니라 반복 검증한 운영 능력입니다.
함께 읽으면 이해가 이어지는 글
- Dify가 LLM 스파게티를 없앨까: DAG, Celery, DSL이 옮겨 놓은 복잡도 — Dify가 프롬프트, 검색, 분기 로직을 어떻게 시각적 DAG로 분리하는지, 그리고 배포 전에 확인할 버전 관리, 확장, 운영 비용을 짚습니다.
- Crawl4AI로 RAG용 Markdown을 만들 때 먼저 확인할 것 — AsyncWebCrawler로 동적 페이지를 Markdown, JSON으로 바꾸는 최소 흐름과 버전, 브라우저 의존성, 추출 정확도, 자원 비용 검증법을 정리합니다.
- 문서 하나 바뀔 때 RAG 전체를 다시 임베딩해야 할까? CocoIndex 증분 처리 — 원본 변경과 의존성을 추적해 필요한 청크만 다시 계산하는 CocoIndex의 Rust, Postgres 구조, 상태 불일치와 선언형 락인 위험을 정리합니다.
자주 묻는 질문
Project N.O.M.A.D는 인터넷이 끊긴 뒤 설치할 수 있나요?
필요한 컨테이너 이미지, 모델, 위키, 지도, 교육 자료를 온라인일 때 미리 내려받아 검증해야 하므로 단절 전에 설치, 복제, 복구 훈련을 마쳐야 합니다.
로컬 서버에서 실행하면 외부 통신이 전혀 없나요?
자동으로 보장되지 않습니다. 시작, 업데이트, 인증 과정의 연결 시도와 DNS 실패 로그를 확인하고 실제 인터넷 차단 상태에서 모든 핵심 기능을 시험해야 합니다.
오프라인 서버의 성공 기준은 무엇인가요?
단절 상태에서 재부팅, AI, 검색, 지도 사용, 컨테이너 한 개의 고장 복구와 백업 복원이 정해진 시간 안에 로컬 문서만으로 가능해야 합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.