셀프 호스팅 Dropbox 대안 4종 비교 및 추천

어떤 셀프 호스팅 Dropbox 대안을 운영해야 합니까?

다음 네 가지 셀프 호스팅 Dropbox 대안을 고려해 볼 가치가 있습니다: Nextcloud, Seafile, Syncthing, 그리고 클라이언트를 얹은 객체 스토리지(object storage)입니다. 이들은 서로 대체할 수 없습니다. Nextcloud는 다른 사람에게 파일을 전달해야 하는 가정이나 소규모 팀에 적합합니다. Seafile은 디스크상의 데이터 형태보다 동기화 속도가 중요한, 매우 많은 수의 작은 파일을 동기화하는 개인이나 팀에 적합합니다. Syncthing은 외부 공유 링크가 필요 없는, 자신의 기기들을 동기화하는 개인에게 적합합니다. 객체 스토리지는 거의 열어보지 않는 저렴한 아카이브 용도로 적합합니다.

기능을 비교하기 전에 동기화 방식부터 선택하십시오. 기능 목록은 모두 비슷해 보입니다. 토폴로지, 즉 다른 모든 기기가 동의하는 복사본을 어떤 머신이 보유할 것인가 하는 문제는 6개월 뒤에도 만족하며 사용할 수 있을지를 결정짓는 핵심 요소입니다.

동기화 토폴로지: 서버 중심 방식 또는 서버 없는 피어 방식

두 가지 설계 방식이 있으며, 이후 이어지는 내용은 어떤 방식을 선택하느냐에 따라 결정됩니다.

서버 중심 방식(Server of record). Nextcloud, Seafile, 객체 스토리지 등이 이 방식을 사용합니다. 보통 VPS(가상 사설 서버)인 한 대의 장비가 권한 있는 사본을 보관합니다. 모든 기기는 해당 장비와 통신합니다. 노트북을 한 달 동안 꺼두었다가 다시 켜도 스스로 동기화 상태를 따라잡을 수 있습니다. 서버는 전체 데이터를 보관하고, 6 GB의 여유 공간만 있는 휴대폰은 그중 일부만 보관할 수 있습니다. 브라우저로 파일에 접근할 수 있으므로 공유 링크 생성이 가능합니다.

서버 없는 피어 방식(Peers with no server). Syncthing이 이 방식을 사용합니다. 기기들이 서로를 찾아 암호화된 연결을 통해 직접 파일 목록을 교환합니다. 권한 있는 사본이라는 개념이 없으며, 파일은 해당 파일을 보관하는 기기에만 존재합니다. 변경 사항이 전달되려면 두 기기가 동시에 온라인 상태여야 합니다. 페이지를 제공하는 장비가 없으므로 누구에게나 줄 수 있는 URL도 존재하지 않습니다.

이 방식들에 따라 다음과 같은 네 가지 결과가 발생하며, 사용자들은 뒤늦게 이를 체감하게 됩니다.

• 소프트웨어를 설치하지 않는 사람에게 파일을 보내려면 서버 중심 방식이 필요합니다. 링크는 URL이며, URL은 포트에서 대기 중인 프로세스를 필요로 하기 때문입니다.
• 회사 노트북처럼 직접 제어할 수 없는 장비에서 파일에 접근하려면 서버 중심 방식이 필요합니다.
• 몇 주 동안 꺼져 있던 기기는 서버 중심 방식에서 다시 켜지는 즉시 데이터를 동기화합니다. 피어 방식에서는 데이터를 가진 다른 기기도 온라인 상태일 때만 동기화가 가능합니다. 이것이 많은 Syncthing 사용자가 항상 켜져 있는 피어로서 VPS에서 인스턴스를 하나 실행하는 이유입니다.
• 스토리지 사용 방식이 다릅니다. 서버 중심 방식은 전체 사본 하나와 각 기기가 로컬에 보관하는 데이터를 합친 만큼의 공간을 차지합니다. 반면, 하나의 폴더를 공유하는 네 개의 피어는 각 피어가 폴더 전체를 보관하므로 총 네 개의 전체 사본이 존재하게 됩니다.

Nextcloud: 사용자, 그룹 및 공개 링크

Nextcloud는 PHP 웹 애플리케이션입니다. 파일을 데이터 디렉터리에 일반 파일 형태로 저장하고 데이터베이스에서 이를 추적합니다. 폴더를 특정 사용자나 그룹과 공유할 수 있으며, 비밀번호와 만료 기한을 설정한 공개 링크로도 공유할 수 있습니다. 버전 기록은 기본적으로 활성화되어 있으며, 삭제된 파일은 먼저 휴지통으로 이동합니다. 데스크톱 클라이언트는 Linux, macOS, Windows를 지원하며, iOS 및 Android 앱도 공식 제공됩니다. Dropbox를 떠나는 이유가 타인에게 파일을 전달해야 하기 때문이라면, Nextcloud가 확실한 대안입니다.

그 대가는 복잡한 구성 요소입니다. 일반적인 설치 환경에서는 웹 서버, PHP-FPM(PHP 프로세스 관리자), MariaDB나 PostgreSQL 같은 데이터베이스, 그리고 파일 잠금을 위한 Redis가 실행됩니다. 5분마다 cron이나 systemd 타이머를 통해 백그라운드 작업이 실행됩니다. 1 GB VPS에서도 실행은 가능하지만, 대용량 업로드가 발생하거나 긴 occ 유지보수 명령이 실행되면 OOM(Out-of-Memory) 킬러에 의해 프로세스가 종료될 수 있습니다. 소수의 사용자가 사용하더라도 2 GB를 최소 사양으로 잡아야 하며, 더 많은 앱을 활성화할 계획이라면 4 GB를 권장합니다. 또 다른 대가는 업그레이드입니다. 앱 스토어의 앱들은 특정 코어 릴리스에 맞춰 제작되므로, 메이저 버전 업그레이드를 진행하기 전에 사용하는 앱들이 다음 버전을 지원하는지 확인해야 합니다.

하나의 계정에 수십만 개의 작은 파일이 저장되면 Nextcloud의 속도가 저하됩니다. 각 파일은 파일 캐시 테이블의 행 하나를 차지함과 동시에 디스크상의 실제 파일로 존재하며, 데스크톱 클라이언트가 이를 하나씩 확인하기 때문입니다. 가정용 규모에서는 문제가 되지 않습니다. 사이징, TLS(전송 계층 보안) 및 백업에 관한 내용은 TLS와 백업을 포함한 Docker 기반 Nextcloud 설치에서 다루고 있으니, 도입을 결정했다면 해당 문서를 참조하십시오.

범위에 관한 주의 사항이 하나 있습니다. Nextcloud는 캘린더, 연락처, 메모, 사진 라이브러리 기능도 제공하지만, 앱을 활성화할 때마다 백그라운드 작업이 늘어나고 업그레이드를 방해할 요소가 하나씩 추가됩니다. 사진 관리가 주된 목적이라면 전용 도구가 더 효율적입니다. 자체 호스팅 Google Photos 대체재인 Immich를 확인하십시오. 문서나 위키가 주된 목적이라면 파일 서버에 앱을 계속 추가하기보다 자체 호스팅 Notion 대안을 살펴보는 것이 좋습니다. 브라우저에서 문서를 편집하는 기능은 Nextcloud 앱이라기보다 별도의 서버를 구성하는 것에 가깝습니다. 따라서 2 GB 최소 사양으로 충분할 것이라고 가정하기 전에 OnlyOffice와 Collabora 비교를 먼저 검토하십시오.

Seafile: 매우 많은 수의 작은 파일을 위해 설계됨

Seafile은 모든 파일을 블록 단위로 분할하여 콘텐츠 해시로 주소를 지정하는 내부 객체 저장소에 저장합니다. 이는 git이 객체를 관리하는 방식과 동일합니다. 동기화 및 공유의 단위는 폴더 트리가 아닌 라이브러리입니다. 클라이언트는 파일당 하나의 요청을 보내는 대신 블록과 하나의 커밋을 업로드하므로, 100,000개의 작은 파일이 포함된 디렉터리를 동기화할 때 파일별 프로토콜보다 훨씬 빠르게 작업을 마칩니다. 동일한 블록은 한 번만 저장되므로, 큰 파일의 사본을 추가로 생성해도 저장 공간은 거의 차지하지 않습니다.

이 방식의 대가는 서버에 저장된 파일이 더 이상 일반적인 파일 형태가 아니라는 점입니다. 저장소 디렉터리를 열어보면 16진수 이름의 객체 파일들만 보입니다. 데이터를 추출하려면 Seafile 클라이언트나 Seafile 자체의 export 및 fsck 도구를 사용해야 합니다. 객체들도 일반 파일이므로 백업은 가능하지만, cp를 사용하여 특정 스프레드시트 하나만 복구하는 것은 불가능합니다. 나중에 후회하는 경우가 많으므로 이 방식이 수용 가능한지 지금 결정하십시오.

Seafile은 커뮤니티 에디션과 유료 프로페셔널 에디션을 제공하며, 두 버전 간의 기능 차이는 릴리스마다 변경될 수 있습니다. 따라서 특정 기능을 중심으로 팀 운영 계획을 세우기 전에 공식 사이트의 최신 약관을 확인하십시오. 공식 데스크톱 및 모바일 클라이언트가 제공됩니다. 암호화된 라이브러리는 클라이언트 측에서 암호화되므로, 서버는 읽을 수 없는 암호문 상태로 데이터를 저장합니다. 암호를 분실하면 본인을 포함하여 누구도 라이브러리를 읽을 수 없습니다. 브라우저에서 암호화된 라이브러리를 열려면 웹 세션에 암호를 입력해야 하므로, 해당 보안 보장의 강력한 수준은 데스크톱 및 모바일 클라이언트에서 가장 잘 유지됩니다.

리소스 비용은 Nextcloud와 비슷합니다. 데이터베이스, 메모리 캐시, 두 개의 애플리케이션 프로세스를 실행해야 하므로 2 GB를 합리적인 최소 사양으로 권장합니다.

Syncthing: 로그인할 대상이 없음

Syncthing은 단일 Go 바이너리로 구성됩니다. 이 프로그램은 폴더를 감시하고, 검색 서버나 릴레이를 통해 피어를 찾으며, 장치 간에 직접 동기화합니다. 동기화하는 상대방을 위한 계정이나 로그인 페이지는 존재하지 않습니다. 두 장치를 ID로 연결하고 각 측에서 폴더를 수락하기만 하면 됩니다. 실행할 요소가 거의 없기 때문에 이 문서에서 다루는 도구 중 운영 부담이 가장 적습니다.

대신 포기해야 할 부분은 공유 기능 전체입니다. 해당 항목은 Device pairing only, no links로 표시됩니다. 클라이언트, 회계사, 친척에게 링크를 전달할 수 없습니다. 또 다른 공백은 모바일 지원입니다. Android app, no official iOS 항목을 참고하십시오. 프로젝트 공식 FAQ는 이에 대해 명확히 밝히고 있습니다. "현재 Syncthing 팀은 가까운 미래에 iOS를 공식 지원할 계획이 없습니다." 이는 iOS가 백그라운드 처리를 엄격히 제한하여 안정적인 동기화를 어렵게 만들기 때문입니다. iOS 사용자는 서드파티 앱을 사용해야 합니다.

리소스 사용량은 적지만 한 가지 알아둘 점이 있습니다. Syncthing은 동기화하는 모든 파일에 대해 인덱스 항목을 유지하므로, 메모리 사용량과 초기 스캔 시간은 전체 용량이 아닌 파일 개수에 비례하여 증가합니다. 대용량 폴더를 처음 해싱할 때는 CPU를 잠시 사용하지만, 이후에는 안정화됩니다. 가장 작은 VPS 플랜에서도 원활하게 작동합니다.

충돌은 양쪽 파일을 모두 보존하는 방식으로 처리합니다. 두 장치가 서로 연결되지 않은 상태에서 동일한 파일을 수정하면, Syncthing은 한쪽 복사본의 이름을 변경하여 원본 옆에 보관하므로 notes.sync-conflict-20260802-141530-K7MB3QT.md와 같은 파일을 발견하게 됩니다. 데이터는 손실되지 않습니다. 자동으로 병합되지 않으므로 사용자가 직접 해결해야 합니다.

클라이언트를 이용한 오브젝트 스토리지: 동기화 폴더가 아닌 저렴한 바이트 저장소

오브젝트 스토리지는 MinIO로 직접 호스팅하거나 제공업체에서 임대하는 S3(simple storage service) 호환 버킷을 의미합니다. 이 스토리지는 명령줄 도구인 rclone이나 버킷을 드라이브처럼 보여주는 데스크톱 클라이언트를 통해 접근합니다. 공유는 만료 시간이 포함된 링크인 presigned URL을 생성하여 수행합니다. 버전 관리는 버킷 설정 항목입니다: Bucket versioning, off by default. 이 설정은 이전에 업로드한 객체에는 적용되지 않으므로 버킷을 생성할 때 미리 활성화해야 합니다.

버킷을 동기화 폴더처럼 취급하면 문제가 발생합니다. 기본적으로는 Documents 디렉터리를 감시하는 프로세스가 없기 때문입니다. rclone bisync는 양방향 동기화를 수행하며, rclone 공식 문서에서도 이에 대한 주의 사항을 명확히 다루고 있습니다. 오브젝트 스토리지가 가장 잘하는 역할은 백업 대상이나 애플리케이션의 이면에서 저장소 계층을 담당하는 것입니다. MinIO를 이용한 자체 호스팅 S3 호환 오브젝트 스토리지에서 서버 측 설정을 다룹니다.

이 방식의 자원 비용은 일반적이지 않습니다. MinIO는 단일 바이너리로 구성되어 유휴 상태에서 자원을 적게 소모합니다. 실제로 지불하는 비용은 디스크 비용이며, VPS 환경에서는 기가바이트 단위로 임대하는 블록 볼륨 비용과 객체를 전송할 때 발생하는 대역폭 비용이 포함됩니다. 이 비용들은 free -h에 나타나지 않으므로, 아카이브 크기를 결정하기 전에 VPS의 실제 월간 운영 비용을 먼저 확인하십시오.

공유, 모바일 클라이언트 및 버전 관리 비교

[
  {
    "tool": "Nextcloud",
    "sharing": "Public links, users and groups",
    "mobile": "Official iOS and Android apps",
    "versioning": "On by default, plus trash"
  },
  {
    "tool": "Seafile",
    "sharing": "Public links with password and expiry",
    "mobile": "Official iOS and Android apps",
    "versioning": "Library history and snapshots"
  },
  {
    "tool": "Syncthing",
    "sharing": "Device pairing only, no links",
    "mobile": "Android app, no official iOS",
    "versioning": "Optional per folder, off by default"
  },
  {
    "tool": "Object storage",
    "sharing": "Presigned URLs you generate",
    "mobile": "Third party clients only",
    "versioning": "Bucket versioning, off by default"
  }
]

모든 4 옵션은 한 줄로 나뉩니다. 이 중 세 가지는 브라우저만 가진 외부인에게 파일을 전달할 수 있습니다. 나머지 하나는 본인이 소유한 기기하고만 통신합니다. Seafile의 버전 관리 항목인 Library history and snapshots은 주의가 필요합니다. 기록은 라이브러리별로 유지되므로, 라이브러리를 삭제하면 해당 기록도 함께 삭제됩니다.

데이터를 다시 추출하는 방법

데이터를 추출하는 비용은 지금 확인하면 저렴하지만 나중에 발견하면 비싸지므로, 도입하기 전에 미리 확인해야 합니다.

Nextcloud는 실제 파일을 실제 디렉터리에 저장하므로, 애플리케이션이 다시 실행되지 않더라도 데이터 디렉터리를 tar하면 문서를 확보할 수 있습니다. Syncthing은 모든 피어에서 동일한 방식을 사용하며, 이는 가장 강력한 데이터 추출 전략입니다. 즉, 파일이 각 장치에 그대로 저장되어 있습니다. Seafile의 객체 저장소는 블록을 파일로 재조합하기 위해 Seafile 자체나 전용 내보내기 도구가 필요합니다. 객체 저장소는 rclone이나 그에 준하는 도구가 필요하며, 이는 명령어 한 줄로 해결할 수 있습니다.

동기화는 백업이 아니며, 그 차이로 인해 데이터가 유실됩니다

여기에 소개된 모든 도구는 기기 간의 변경 사항을 복사합니다. 삭제 또한 변경 사항의 일종입니다. 노트북에서 폴더를 삭제하면 클라이언트가 서버에 이를 알리고, 서버는 이를 적용하며, 다른 모든 기기에서도 해당 폴더가 삭제됩니다. 랜섬웨어 역시 동일한 경로를 이용합니다. 랜섬웨어가 로컬 파일을 암호화하면 클라이언트는 파일이 수정된 것으로 인식하여 암호화된 버전을 업로드합니다. 동기화는 정상적으로 작동했지만, 데이터는 사라진 상태가 됩니다.

휴지통과 버전 기록 기능이 이를 완화해 주기는 합니다. 하지만 이 기능들도 보관 기간이 만료될 수 있고, 실수를 저지른 계정과 동일한 계정으로 비워질 수 있으며, 라이브 복사본과 같은 디스크에 저장됩니다. 볼륨 장애가 발생하면 파일과 그 기록이 함께 소실됩니다.

백업이란 별도의 하드웨어에 보관되는 분리된 복사본이며, 정해진 일정에 따라 수행되고, 최소 한 번 이상 복원 테스트를 거친 것을 의미합니다. 데이터베이스는 파일과 동일한 주기에 백업하십시오. 데이터베이스 없이 Nextcloud 데이터 디렉터리만 복원하면 인스턴스는 해당 파일의 존재를 인식하지 못합니다. 이후 occ files:scan을 수행하면 파일은 복구되지만, 해당 테이블에 저장되어 있던 공유 정보와 버전 기록은 유실됩니다. VPS에서 예약된 restic 백업 수행하기에서는 암호화 및 중복 제거가 적용된 백업 방식을 다루며, 복원을 가정하는 대신 실제로 테스트하는 방법을 설명합니다.

제가 선택할 솔루션

이 글을 읽는 대부분의 사용자에게는 Nextcloud를 추천합니다. Dropbox를 떠난 사용자들이 가장 아쉬워하는 점은 아무것도 설치하지 않은 상대방에게 링크를 공유하는 기능과, 스마트폰에서 파일을 여는 기능입니다. Nextcloud는 공식 클라이언트를 통해 이 두 가지를 모두 지원하며, 유료 등급이 없고 2 GB의 RAM만으로도 충분히 운영할 수 있습니다. 다만 저는 두 가지 예외를 둡니다. 만약 해당 폴더가 오직 본인만 사용하고 본인이 소유한 하드웨어에서만 작동한다면, Syncthing을 사용하십시오. 서버를 패치하거나 웹 로그인을 방어할 필요가 없어 편리합니다. 만약 수십만 개의 파일이 포함된 작업 디렉터리를 동기화해야 한다면, Seafile을 사용하십시오. 속도를 얻는 대신 불투명한 저장 방식을 감수해야 합니다. 어떤 솔루션을 선택하든 객체 스토리지는 동기화 도구의 앞단이 아닌, 백업 대상으로서 뒷단에 배치해야 합니다.

FAQ

Syncthing은 제 노트북을 위한 백업 도구인가요?

아니요. Syncthing은 기기 간의 변경 사항을 동기화하는 도구이며, 파일 삭제 또한 하나의 변경 사항으로 간주합니다. 따라서 실수로 파일을 삭제하면 몇 초 안에 연결된 모든 기기에서 해당 파일이 사라집니다. 폴더별 파일 버전 관리 기능을 사용하면 도움이 되지만, 각 폴더에서 직접 활성화하기 전까지는 기본적으로 꺼져 있습니다. 별도의 하드웨어에 정기적으로 백업을 수행하고, 복구 절차가 정상적으로 작동하는지 최소 한 번은 직접 테스트해 보아야 합니다.

동일한 VPS에서 Nextcloud와 Syncthing을 함께 실행할 수 있나요?

네, 두 서비스는 서로 다른 포트를 사용하므로 충돌하지 않습니다. 단, Syncthing의 동기화 폴더를 Nextcloud의 데이터 디렉터리로 지정하지 마십시오. Nextcloud는 데이터베이스를 통해 모든 파일을 추적합니다. 따라서 Nextcloud가 모르는 상태에서 디스크에 직접 파일을 추가하면 occ files:scan 명령을 실행하기 전까지는 파일이 보이지 않으며, 파일을 임의로 삭제하면 데이터베이스에 유효하지 않은 레코드가 남게 됩니다. Syncthing 전용 디렉터리를 따로 만들거나, 해당 디렉터리를 Nextcloud의 외부 저장소(external storage)로 연결하여 Nextcloud가 해당 경로를 인식하도록 설정하십시오.

계정이 없는 사람에게 링크를 공유하려면 어떤 것을 사용해야 하나요?

Nextcloud와 Seafile 모두 공개 링크 생성 기능을 제공하며, 선택적으로 비밀번호와 만료 기한을 설정할 수 있습니다. 오브젝트 스토리지는 설정한 시간이 지나면 자동으로 만료되는 사전 서명된 URL(presigned URL)을 제공합니다. Syncthing은 이러한 기능을 지원하지 않습니다. Syncthing의 공유 모델은 기기 간의 페어링 방식이므로, 상대방도 반드시 Syncthing을 설치하고 기기 ID를 공유한 뒤 폴더 연결을 수락해야 합니다.

서버에는 어느 정도의 디스크 용량이 필요한가요?

데이터를 보관하는 서버라면 공유 데이터 전체 크기에 버전 기록과 휴지통 용량, 그리고 업로드 중인 파일을 위한 작업 공간을 더해 계획해야 합니다. 많은 사용자가 버전 기록의 용량을 과소평가합니다. 매일 변경되는 2 GB 파일을 매번 보관하면 용량이 빠르게 증가하므로, 초기에 보존 정책을 설정해야 합니다. 데이터를 별도의 볼륨에 저장하면 루트 파일 시스템의 용량 부족을 방지할 수 있습니다. 루트 파일 시스템이 꽉 차면 특정 업로드 작업뿐만 아니라 서버 전체가 멈출 수 있기 때문입니다.