▲

Twake Drive – Google Drive의 오픈소스 대안

 (github.com/linagora)
5P by GN⁺ 18시간전 | ★ favorite | 댓글 1개
  • Twake Drive는 Google Drive와 유사한 파일 저장·공유 기능을 제공하는 오픈소스 클라우드 스토리지 플랫폼
  • Docker 기반 배포를 지원해 로컬 환경에서 손쉽게 구동 가능하며, Node.js와 MongoDB를 주요 기술 스택으로 사용
  • 프런트엔드와 백엔드가 분리된 구조로, Yarn 기반 개발 환경과 로컬 파일 저장 경로 설정 기능을 제공
  • Affero GPL v3 라이선스로 공개되어 있어, 기업이나 조직이 자체 호스팅 형태로 자유롭게 커스터마이징 가능

프로젝트 개요

  • Twake Drive는 Linagora가 개발한 Google Drive의 오픈소스 대체 솔루션으로, 파일 저장·공유·협업 기능을 자체 서버에서 운영할 수 있는 형태로 제공
    • 클라우드 서비스 종속을 피하고, 데이터 소유권과 보안 통제를 유지하려는 조직을 주요 대상으로 함
  • GitHub에서 공개된 저장소는 1,000개 이상의 스타와 70여 개의 포크를 기록하며 활발히 유지보수 중
  • 프로젝트는 AGPL-3.0 라이선스를 채택해, 소스코드 수정 및 재배포 시 동일한 라이선스 조건을 유지해야 함

주요 기능 및 기술 스택

  • Twake Drive는 Node.js(18.x 이상) , MongoDB, Yarn을 기반으로 동작하며, 프런트엔드와 백엔드가 분리된 구조로 설계
    • 프런트엔드는 tdrive/frontend/ 디렉터리에서 yarn dev:start로 실행
    • 백엔드는 tdrive/backend/node/에서 환경 변수를 설정 후 yarn dev로 구동
  • Docker Compose를 이용한 간단한 배포 옵션(docker-compose.minimal.yml)을 제공해, 로컬 테스트 및 내부 배포가 용이
  • MongoDB 컨테이너 실행 명령(docker run -p 27017:27017 -d mongo)을 통해 데이터베이스를 손쉽게 구동
  • 환경 설정은 tdrive/backend/node/config/development.json 파일을 통해 세부 조정 가능

개발 및 배포 구조

  • Twake Drive는 프런트엔드(React 기반) 와 백엔드(Node.js 기반) 가 분리되어 있으며, 로컬 파일 저장소 경로를 직접 지정 가능
    • STORAGE_LOCAL_PATH 환경 변수를 통해 문서 저장 위치를 설정
  • PUBSUB_TYPE=local 설정으로 로컬 환경에서의 퍼블리시·구독 기능을 지원
  • 애플리케이션은 기본적으로 3000번 포트에서 실행되며, 개발 및 테스트 환경에 최적화된 구조를 가짐
  • Docker Bake 설정 파일(docker-bake.hcl)과 CI/CD용 GitHub Actions 구성이 포함되어 있어 자동화된 빌드 및 테스트 지원

코드 및 저장소 현황

  • 저장소는 882개의 커밋, 61개의 브랜치, 46개의 태그로 구성되어 있으며, 활발한 개발 이력 유지
  • 주요 언어 비중은 TypeScript 58.9% , JavaScript 32.6% , SCSS 3.7% , CSS 2.2% , HTML 1.3% , Less 1.0%

라이선스 및 활용 가능성

  • Twake Drive는 Affero GPL v3 라이선스로 배포되어, 소스코드 수정 및 재배포 시 동일한 공개 의무를 가짐
  • 기업은 이를 기반으로 내부 전용 클라우드 스토리지 시스템을 구축하거나, SaaS 형태로 확장 가능
  • 상용 클라우드 서비스의 비용 절감과 데이터 주권 확보를 동시에 달성할 수 있는 대안으로 평가됨
▲
GN⁺ 18시간전  [-]
Hacker News 의견

  • 여기서 많은 사람들이 필수 기능이나 백업 얘기를 하지만, 진짜 중요한 건 커뮤니티를 만들고 오랫동안 유지할 수 있느냐임
    오픈소스 클라우드 스토리지는 유지보수자가 지치면 금방 사라지기 때문에, 지속 가능한 비즈니스 모델이나 기여자 기반이 기술적 체크리스트만큼 중요함
    또 상호운용성(interoperability) 도 과소평가됨. WebDAV나 S3를 지원하고 기존 인증 시스템과 연동된다면 팀들이 훨씬 쉽게 시도함
    결국 사람들은 ‘허니문 기간’이 끝나도 사라지지 않을 서비스를 원함. 그건 진행 표시줄 하나 추가하는 것보다 훨씬 어려운 일임

    • 그건 도구의 조직 모델의 약점일 수도 있겠지만, 나는 커뮤니티에 참여하고 싶지 않음. 그냥 잘 작동하길 원할 뿐임
      나는 Syncthing을 쓰는데, 커뮤니티에 참여하라는 말 한 번도 못 들었지만 여전히 잘 돌아감
      Syncthing은 Kastelo라는 회사가 엔터프라이즈 지원을 제공하면서 개발비를 충당하는 듯함
      나도 오픈소스 컨설팅 회사를 운영하는데, 커뮤니티 없이도 기업 계약으로 충분히 유지됨
      커뮤니티도 좋지만, 장기적으로는 비즈니스 모델과 마케팅 전략이 더 중요하다고 생각함
    • 개인적으로는 S3 호환성이 객체 스토리지의 핵심이라 생각함
      S3 API를 지원하는 시스템이라면 어떤 스토리지든 교체가 쉬움. Backblaze, Wasabi, 로컬 S3 API 등 대부분 드롭인 교체 가능함
    • 커뮤니티가 왜 중요한지 모르겠음. 문제를 해결하는 도구라면, 커뮤니티는 단지 유지보수 수단일 뿐임

  • 지금까지 써본 self-hosted 파일 동기화 중에서는 Seafile이 가장 쓸 만했음
    하지만 서버 업그레이드가 여전히 번거로움. NextCloud나 유사한 도구들은 내 기준에서는 완전한 재앙 수준이었음

    • 왜 재앙이라고 생각하는지 궁금함. 우리 회사에서는 NextCloud를 3년째 문제 없이 쓰고 있음
      필요한 플러그인도 다 있고, 성능도 좋고, 동기화도 완벽함. 다른 대안을 시도할 이유가 없을 정도임
    • 나는 Docker 버전으로 Seafile을 돌리는데, 태그만 바꾸면 업그레이드가 아주 쉬움
      예전에는 NextCloud가 큰 리포지토리에서 버벅였고, 더 강력한 머신이 필요했음
      Seafile은 2GB RAM의 ARM 보드에서도 잘 돌아감
    • 최근에 Seafile을 직접 서버에 설치했는데, 백업과 보안 전략을 세우는 데 신경을 많이 씀
      테스트도 철저히 했고, 동기화 속도와 반응성이 놀라울 정도였음
      이제는 Google Drive에서 모든 파일을 옮겨와 메인 클라우드로 사용 중임
    • Resilio도 괜찮음. Syncthing도 좋지만, 내 경험상 Resilio가 더 빠르고 NAT 통과도 잘됨
    • 나도 Seafile과 Seadrive를 수년째 사용 중인데, subst 드라이브 매핑으로 아주 잘 작동함

  • 이름을 Twake Dwive로 했으면 재밌었을 것 같음

  • 다른 사람들이 묻듯이, 이게 NextCloud나 ownCloud와 비교해서 어떤지 궁금함. 그리고 Windows/Mac/Mobile용 클라이언트가 있는지도 알고 싶음

    • ownCloud는 플랫폼별 클라이언트가 다 있지만, 각 플랫폼마다 작은 버그와 신뢰성 문제가 너무 많아서 쓸 수가 없었음
    • NextCloud 설치를 시도했는데, 완전히 고통스러운 경험이었음
    • 내 경험상 NextCloud는 비대한 PHP 괴물 같음. 성능도 떨어지고, Twake는 훨씬 가볍고 범위도 명확해 보임

  • 오픈소스 드라이브 도구의 생사는 세 가지에 달려 있음

    1. 절대 놀라게 하지 않는 단순한 동기화
    2. 비기술자에게도 설명 가능한 충돌 처리
    3. 문제 없는 업그레이드
      Twake가 S3와 LDAP을 지원하면서 이걸 잘 해낸다면 가능성이 있음
      하지만 진짜 어려운 건 신뢰와 문서화임. 명확한 위협 모델, Drive나 Dropbox에서의 마이그레이션 가이드, 그리고 헤드리스 환경에서도 작동하는 작은 CLI가 필요함
    • 여기에 네 번째로 백업 검증의 용이성을 추가하고 싶음
      예전에 회사에서 백업이 활성화되어 있었는데, 막상 복구하려니 전부 손상돼 있었던 적이 있음. 그 이후로는 백업 검증이 최우선임
    • 수동으로 “지금 동기화” 버튼이 있었으면 좋겠음. Google Drive에서는 동기화 상태가 명확하지 않아 답답할 때가 많음

  • 58.9% TypeScript와 32.6% JavaScript로 이런 고성능 앱을 만든다는 게 의문임

    • 그럼 91.5%가 JavaScript 아닌가? TypeScript는 진짜 언어가 아니라는 농담임
    • 이 앱은 I/O 바운드라서 TS/JS로 돌려도 문제없음
    • 백엔드는 TS, 프론트엔드는 JS로 보임. 나는 테스트는 JS로, 앱 코드는 TS로 분리함
      언어 속도보다 병목이 덜한 부분이 더 중요하다고 생각함
    • 요즘 스타트업들이 TS/JS 마이크로서비스로 이벤트 기반 아키텍처를 구축하는 걸 보면, 그 선택이 이상하지 않음

  • 약간 주제에서 벗어나지만, Viber나 WhatsApp이 Google Drive 대신 다른 백업 스토리지를 쓰게 할 방법이 있을까? 루팅해서 인터페이스를 속이는 식으로 가능할지 궁금함

    • Android에서는 단순히 share-target으로 구현 가능함. PWA로도 쉽게 만들 수 있음

  • 이런 시스템에 정말 데이터베이스가 필요한가?
    Unix에서는 사용자와 파일 CRUD, 권한 부여만으로도 충분할 것 같은데, 이런 걸 UI나 API로 감싼 오래된 소프트웨어가 있을까? SAMBA 프로토콜 기반으로라도?

    • 버전 히스토리나 공유 URL 같은 기능을 구현하려면 DB가 필요함.
      또 사용자 그룹 제한을 걸려면 그룹 수 한계(65536개)에 금방 도달함
    • Cockpit을 살펴보면 좋음. Cockpit Applications에서 파일 탐색, 권한 편집, 업로드/다운로드 등 대부분의 기능을 제공함
    • 디스크 작업 캐싱이나 다중 노드 동기화를 위해서는 메타데이터 저장이 필요함. 결국 DB를 안 쓰기 어렵다고 봄
    • 나도 그런 걸 생각해봤는데, Python과 fsspec으로 로컬 또는 S3/SSH 등 다양한 파일시스템을 다루는 Google Drive 스타일 인터페이스가 있으면 좋겠음
    • DB를 쓰면 users와 documents를 조인하거나, MongoDB 인덱스와 트랜잭션을 활용하기 쉬움
      버전 메타데이터 관리도 간단하고, Windows에서도 해킹하기 쉬움

  • 나는 아마 HN 분위기와 다르겠지만, 내게 가장 중요한 기능은 검색임
    수 TB의 데이터를 저장하다 보면 사진 하나 찾기도 힘듦
    “Nothing Street에 있는 두 사람”처럼 검색할 수 있게 이미지 분석을 해주는 기능이 필요함
    지금은 Google이 이 부분에서 압도적으로 뛰어나지만, 다른 클라우드들도 언젠가 따라잡길 바람

  • Syncthing을 한 번 써보길 추천함

    • 나도 Dropbox 학생 할인 끝난 후부터 Syncthing을 써왔음. 수년째 안정적으로 잘 작동함
      다만 모바일 경험은 아직 거칠었음. 그래도 웹 인터페이스로 급할 때 파일을 가져올 수 있음
    • Syncthing은 훌륭하지만, 모바일에서 대용량 파일을 다루기엔 부적합함. 전체 동기화 방식이라 제약이 있음
    • 내가 쓰는 FOSS 중 가장 믿을 수 있는 도구임. 그냥 잘 작동하고, 모든 플랫폼에서 돌아감
답변달기