Spacedrive - 오픈 소스 기반의 크로스 플랫폼 파일 탐색기

 (github.com/spacedriveapp)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Spacedrive는 여러 기기와 클라우드의 파일을 한곳에서 다루는 cross-device data platform으로, 파일·이메일·노트·외부 소스를 색인하고 검색하며 P2P로 동기화함
  • Finder나 Explorer를 대체하지 않고 OS 파일 관리자 위에서 로컬 디스크, 외장 드라이브, NAS, 클라우드 스토리지, 아카이브 데이터 소스를 검색·탐색하는 상위 레이어 역할을 함
  • 모든 파일에 BLAKE3 콘텐츠 해시를 부여해 같은 파일을 같은 해시로 식별하며, 여러 기기 전체의 중복 추적과 중복 제거를 가능하게 함
  • 기기 간 동기화는 Iroh/QUIC 기반 P2P sync로 직접 연결되며, 서버·클라우드·단일 장애 지점 없이 메타데이터를 동기화하고 파일은 원래 위치에 유지함
  • S3, Google Drive, Dropbox, OneDrive, Azure, GCS를 로컬 스토리지와 함께 cloud volumes로 색인하며, Gmail, Apple Notes, Chrome Bookmarks, Slack, GitHub 등은 스크립트 기반 어댑터로 검색 가능한 저장소가 됨
  • Spacebot과 연동해 선택적 별도 프로세스로 AI 에이전트 런타임을 실행하며, Spacedrive가 데이터·권한·실행 레이어를 맡고 Spacebot이 지능을 담당함
    • 각 Spacebot 인스턴스는 하나의 Spacedrive 노드와 페어링되며, 해당 노드가 에이전트 인증, 기기 그래프 유지, 권한 해결, 피어 기기 작업 전달을 수행함
    • 파일 읽기, 셸 명령, 작업은 Spacedrive를 통해 대상 기기로 프록시되며, 접근 가능한 기기·경로·작업·사람 확인 필요 여부를 권한 시스템이 처리함
  • 활성화 시 색인 대상 레코드는 검색 가능 상태가 되기 전에 Safety Screening 파이프라인을 통과함
    • Prompt Guard 2가 이메일·메시지·문서의 프롬프트 인젝션을 로컬 분류기로 감지함
    • 신뢰 계층, 격리 시스템, 콘텐츠 펜싱을 통해 플래그된 레코드를 AI 에이전트 쿼리에서 제외하고 데스크톱 앱에서 검토 가능하게 함
  • 핵심 아키텍처는 Virtual Distributed Filesystem, 콘텐츠 식별 시스템, 트랜잭션 액션, 리더 없는 동기화로 구성됨
    • 파일과 폴더는 물리적 위치와 독립된 객체가 되며, 각 파일은 여러 기기에서 동작하는 SdPath 주소를 가짐
    • 파일 작업은 실행 전 미리보기, 승인 또는 취소, 네트워크 중단과 기기 재시작을 견디는 durable job 형태를 가짐
  • 구현은 Rust 단일 크레이트와 CQRS/DDD 아키텍처 기반이며, 주요 기술로 Tokio, SQLite, SeaORM, sqlx, Iroh, BLAKE3, LanceDB, FastEmbed, OpenDAL, Tauri 2, React Native, React 19, Vite, TanStack Query, Tailwind CSS v4, Specta를 사용함
  • 데스크톱 앱은 macOS·Windows·Linux, 모바일 앱은 iOS·Android를 대상으로 하며, CLI와 데몬, headless server, browser client 구조도 함께 가짐
  • 실행 요구사항은 Rust 1.81+, Bun 1.3+, just, 어댑터용 Python 3.9+이며, 개발 명령으로 just setup, just dev-desktop, just test를 사용함
  • 개인정보·보안 모델은 local-first이며, P2P 트래픽은 QUIC/TLS로 암호화되고 라이브러리는 SQLCipher로 디스크 암호화 가능하며, 추적이나 분석용 텔레메트리가 없음
  • 라이선스는 FSL-1.1-ALv2 Functional Source License이며, 2년 후 Apache 2.0으로 전환됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 설치 후 바로 라이브러리 생성, 분석 데이터 공유, 로그인부터 요구해서 다른 파일 탐색기와는 기대가 달랐음
    드라이브의 임의 디렉터리로 이동해 더블클릭했는데 아무 일도 안 일어났고, 컨텍스트 메뉴로 열어도 마찬가지였음
    알고 보니 한 디렉터리에 파일이 1.5만 개 있으면 사실상 탐색이 불가능해짐
    Total Commander와 Windows Explorer는 이런 문제가 없어서, Spacedrive는 기본 파일 탐색 기능부터 더 다듬어야 할 듯함

    • Spacedrive를 써줘서 고맙고, “Location”을 추가하기 전에 탐색할 때 생기는 이 버그는 이미 알고 있음
      Spacedrive는 여기 일부 답글과 달리 대용량 데이터를 염두에 두고 설계됐고, Location을 미리 색인해 캐시를 만들며 모든 것을 캐시하고 가상화함
      다음 업데이트에서 Location이 아닌 곳을 탐색할 때의 버그를 고칠 예정이고, 많은 사용자가 Location으로 추가하기 전에 먼저 탐색부터 해보는 듯함
      아직 알파 소프트웨어라 시간을 두고 다듬어가길 바람
    • 대부분의 React 앱은 대량 데이터 지원을 별로 고려하지 않는 것처럼 보임
      개발자 탓만 하긴 어렵고, 프레임워크가 기본으로 지원해야 한다고 봄
      가상화 목록을 이해해야만 해서는 안 됨
      SwiftUI로 TableView를 만들었을 때 내부 동작을 전혀 몰라도 수천 개 항목을 스크롤할 수 있었음
    • Windows Explorer도 HDD에서 한 디렉터리에 파일이 많으면 버벅임
      정렬 순서 캐시가 없어서 알파벳순이 아닌 방식으로 열면 정렬하느라 5분 이상 기다려야 함

  • 꽤 오래전에 봤을 때는 직접 써볼 릴리스 패키지가 없어서 나중에 준비되면 확인하려고 했고, 한 시간 전에 알파 버전이 나온 것 같아 다시 HN에 올라온 듯함
    개념 자체는 반가움
    요즘은 엄격한 로컬 파일과 여러 클라우드 저장소의 경계가 흐려졌음
    개인적으로는 그 경계를 유지하고 Mac에 클라우드 저장소를 거의 마운트하지 않지만, 학자인 아내는 Dropbox, iCloud Drive, Google Drive, Microsoft 쪽 저장소를 모두 다룸
    함께 일하는 사람들이 각 서비스로 파일을 공유하고 리뷰 협업을 하기 때문임
    이런 도구가 벤더별 연결 문제와 특이한 동작을 가리고, 로컬처럼 보이지만 뒤에는 어떤 클라우드 저장소가 붙어 있을 수 있는 투명한 파일 시스템을 제공한다면 워크플로에 꽤 도움이 될 것임
    핵심은 사용성이고, 지연 시간이 커서 Finder보다 느리게 느껴진다면 가능성은 낮아짐

  • Hacker News는 이런 제품의 최적 사용자층이 아닐 가능성이 큼
    여기 있는 사람들은 이미 각자 최적화한 워크플로를 갖고 있을 확률이 높고, 나도 마찬가지임
    이 제품은 Windows와 Mac을 쓰지만 터미널에는 익숙하지 않은 디지털 창작자에게 더 잘 맞을 듯함
    애니메이터, 일러스트레이터, 영상 편집자, 3D 아티스트, 음악 프로듀서, 유튜버, 스트리머 같은 사람들임
    다만 그 두 번째 그룹이 정말 이런 걸 원하는지는 잘 모르겠음
    마케팅만 봐서는 소프트웨어가 정확히 뭘 하는지 모르겠고, 그 그룹도 마찬가지일 것 같음
    “범용 파일 경험”을 말하려는 건 알겠지만 구체적으로 무엇을 뜻하는지 불명확함
    사용자가 기능을 이해하려고 소프트웨어를 설치해야 해서는 안 됨
    오픈소스이거나 Linux에서 동작한다는 점도 그들에게는 크게 중요하지 않아 보임
    이 단계라면 마케팅을 완전히 새로 만들고 그 두 번째 그룹에 맞춰 최적화하겠음
    PR 담당자나 마케팅 전문가와 함께, 만들고 있는 가치가 무엇인지 구체적이고 효율적으로 전달하는 편이 좋음
    또한 팀 노력을 아끼기 위해 소스 저장소를 내리고 Linux 버전도 중단하거나, 수요가 생길 때까지 비공개로 둘 것 같음
    행운을 빎

  • 꽤 오래 지켜봐 왔고 몇 가지 피드백이 있음
    로컬 개발 디렉터리 하나를 색인하는 데 지금까지 35분 이상 걸렸고, 끝까지 기다리진 않을 것 같음
    다른 사람들이 말했듯 지연 시간이 문제임
    macOS M1 14인치 기본 모델에서 Location을 추가한 뒤에도 폴더를 열고 파일이 보이기까지 가끔 2~4초가 걸림
    내가 놓친 게 아니라면 아직 탭이 없는 듯함
    파일 정렬과 그룹화 기능은 지나치게 빈약하거나 사실상 없지만, 개발 중에 개선될 것으로 봄
    합리적인 색인 상태를 만들려면 Location을 손으로 많이 추가하는 등 사용자가 해야 할 일이 많아 보임
    로컬 우선이라는 건 알지만, 텔레메트리와 로그인 방식은 영 마음에 들지 않음
    전반적으로 직접 써보니 조금 실망스러워서 나에게는 맞지 않을 가능성이 높지만, 타깃 사용자는 있을 수 있고 아직 갈 길도 남아 있음
    보기에는 정말 좋음

    • 업데이트하자면, 켜둔 걸 잊고 있었는데 같은 로컬 개발 폴더를 4시간 넘게 계속 색인하고 있었음 :(

  • 왜 이걸 React로 만들었는지 궁금함
    Rust에 Qt 같은 GUI 프레임워크가 없다는 건 이해하지만, 그렇다고 이게 답인가 싶음
    새 걸 배우기 싫어서 그런 건가?
    C++ 앱이나 Qt로 충분히 만들 수 있고, GUI는 QML로 작성하며 Lua, Python, JavaScript를 스크립트 언어로 붙일 수도 있음
    물론 일이긴 함
    브라우저로 렌더링하는 건 OpenGL 같은 GPU API로 GUI를 만드는 더 쉬운 버전에 가까움
    운영체제에는 이미 GUI 도구가 있으니 그걸 쓰면 됨
    그 외에는 꽤 괜찮아 보이지만, pcmanfm 같은 것도 원격 위치 추가를 지원하지 않나 싶음
    또 하나 궁금한 건 왜 Prisma를 쓰는지임

    • Rust로 크로스플랫폼 데스크톱 앱을 만들고 싶다면 지금은 Tauri + React를 나도 추천할 것 같음
      Tauri는 고성능 작업이나 운영체제 연동이 필요할 때 Rust로 내려가기 쉽고, 주요 플랫폼용 패키징도 미리 갖춰져 있음
      React를 쓰면 많은 UI 컴포넌트가 이미 있는 훌륭한 생태계를 활용할 수 있음
      대부분의 네이티브 Rust GUI 프레임워크와는 다름
      또 프런트엔드 엔지니어와 그들의 웹 기술·디자이너 협업 역량을 재사용할 수 있음
    • Rust에 GUI 프레임워크가 없다고 하기엔 Slint, egui, Qt 바인딩 크레이트들이 있음
      Qt만큼 성숙하지 않다고는 할 수 있지만, 브라우저에서 돌아가는 것과 비교하면 충분한 경우가 많음

  • 이 저장소가 초기 알파 단계이고 알려진 버그도 많은데 GitHub 스타가 이렇게 많은 건 좀 믿기 어려움
    게다가 VC 투자를 받은 것처럼 보이는데, langchain이나 pinecone이 투자받은 것보다 더 혼란스러움
    그쪽은 AI 기반 프로젝트이기라도 하지만, 이 프로젝트는 이미 많이 다뤄진 영역임
    영원히 무료라 해도 사람들이 원하지 않을 것 같고, 광고·추적·월 구독이 들어가면 더더욱 원하지 않을 것임
    기본적으로 신뢰할 이유는 없고 불신할 이유는 많음
    개인적인 공격은 아니지만, 이런 관점을 고려해보지 않았다면 생각해보는 게 좋겠음

  • “welcome” 다음 첫 화면이 로그인임
    왜 파일 탐색기에 로그인해야 하는지 모르겠고, 이 시대는 이상함

    • 링크 첫 줄부터 이렇게 되어 있음: “Spacedrive is an open source cross-platform file manager, powered by a virtual distributed filesystem (VDFS) written in Rust.”
      로그인하는 이유는 이게 원격 파일 시스템이기 때문임
      파일 탐색기보다는 Dropbox를 떠올리는 편이 맞음
    • 마지막 순간에 추가했는데 사용자에게 명확히 설명하지 못했고, 우리 잘못임
      다음 업데이트에서 바뀔 예정임
      결국 로그인은 Tailscale처럼 기기를 빠르게 연결하는 방법이 될 것임

  • 흩어져 있는 클라우드·로컬, 마운트된 저장소와 마운트되지 않은 저장소를 모두 대상으로 하는 검색·탐색 가능한 메타 색인은 확실히 흥미롭고, 한동안 일종의 성배 같은 것이었음
    디지털 자산 관리는 새로운 개념이 아니지만, 현재 선택지가 풍부한 분야는 아님
    Portfolio나 Adobe의 복잡한 제품군은 이런 기능을 많이 제공하지만, 클라우드 저장소보다는 워크플로와 메타데이터에 더 초점을 둠
    요즘 또 하나의 클라우드 의존 서비스를 도입하려면 매우 신중해야 함
    “로컬과 오프라인 파일까지 포함한 모든 파일”이라는 민감도를 생각하면 자가 호스팅/온프레미스가 절대 요구사항이 될 수 있음
    계정이 필요하다면 OIDC나 SAML을 통한 기존 신원 관리와의 통합을 원할 것임
    이 도구가 파일 전체를 보는 필수 단일 창구가 되고 그 위에 워크플로를 구축한다면, 가용성을 확신할 수 있는 연속성 기능도 필요함
    계속 밀고 나가길 바람
    아직 이걸 완전히 해결한 곳은 없음

  • 프로젝트는 멋져 보이고 야심도 마음에 듦
    몇 가지 메모가 있음
    모든 WAN 접근에 대해 명확한 토글 하나를 두고, 분석 데이터나 사용 데이터 전송용 토글은 별도로 두되 기본값은 꺼져 있어야 함
    더 좋게는 이것들도 컴파일 시점 플래그로 만들면 좋겠음
    예전에 Warp라는 새 터미널이 매우 매력적이었지만 기본적으로 네트워크로 데이터를 보내서 많은 사람에게 즉시 탈락 사유가 됐음
    Windirstat와 Everything에서 영감을 많이 얻으면 좋겠고, 특히 Everything의 검색 성능을 목표로 삼으면 좋음
    로드맵에 있는 건 봤지만 다시 말하면 탭이 필요함
    Prisma에서 벗어나는 것도 고려해보길 바람
    데이터베이스를 너무 감싸고 마법이 많음
    근거가 약할 수도 있지만, 언젠가 라이선스를 바꿀까 봐 조금 걱정됨

  • README 첫머리에 나오는 written in Rust를 기능처럼 취급하는 걸 이제 그만했으면 함
    그런 문구를 볼 때마다 “더 안정적이겠다”가 아니라 “누군가의 취미 프로젝트구나”라고 느껴짐

    • 웹사이트에서는 Rust를 기능으로 내세우는 부분을 못 봤음
      README라면 오픈소스 프로젝트에서 관련 세부사항으로 넣을 만해 보임
답변달기