가이드

작성자 Matt Connor 2026-10-11

Seafile vs Nextcloud 비교: 파일 동기화 성능과 차이점

Seafile은 블록 단위 분할로 동기화 속도가 빠르며, Nextcloud는 파일 시스템을 유지하며 다양한 앱을 지원합니다. 두 솔루션의 아키텍처 차이와 백업 방식, 서버 리소스 점유율을 비교하여 사용 환경에 적합한 플랫폼을 선택하는 방법을 상세히 설명합니다.

Seafile과 Nextcloud: 핵심 요약

Seafile과 Nextcloud의 차이는 파일이 서버에 도달한 후 어떻게 처리되는가에 달려 있습니다. Seafile은 모든 파일을 블록 단위로 분할하여 Seafile만 읽을 수 있는 객체 저장소에 보관하므로 동기화 속도가 빠르며, 백업은 두 단계로 나누어 수행해야 합니다. 반면 Nextcloud는 파일을 디스크에 일반 파일 형태로 저장하며, 동기화를 캘린더, 연락처, 문서, 공유 링크 등을 포함한 플랫폼의 한 기능으로 취급합니다. 나머지 특성은 이 근본적인 차이에서 비롯되므로, 이 점을 기준으로 선택하십시오.

2026년 10월 기준으로 Seafile은 13.0 시리즈, Nextcloud는 35 시리즈입니다. 두 제품 모두 성숙한 단계에 있으며, 저장 모델을 변경할 계획은 없습니다.

Seafile의 파일 저장 방식

Seafile은 Git이 저장소를 모델링하는 방식과 유사하게 라이브러리를 모델링합니다. 관리자 매뉴얼에 따르면 내부 모델은 Repo, Commit, FS, Block으로 구성되며, 저장소는 라이브러리라고도 불립니다. 각 파일은 CDC(Content Defined Chunking, 데이터 자체에서 블록 경계를 결정하는 알고리즘)를 통해 가변 길이의 블록으로 분할되며, 매뉴얼에 명시된 평균 블록 크기는 약 8 MB입니다. 웹 인터페이스를 통한 업로드는 예외적으로, 파일 서버가 파일을 기본 8 MB 크기의 고정 블록으로 분할합니다. 블록은 콘텐츠를 기반으로 이름이 지정되므로, 대용량 파일의 두 버전은 변경되지 않은 모든 블록을 공유하며, 서로 다른 두 라이브러리도 동일한 블록을 공유합니다.

관계형 데이터베이스는 라이브러리에 대한 소량의 메타데이터만 보관합니다. 커밋, 디렉터리 객체, 블록을 포함한 나머지 모든 데이터는 데이터 디렉터리 하위에 저장됩니다. 12 및 13 시리즈에서 사용하는 Docker 레이아웃의 경우 해당 경로는 /opt/seafile-data/seafile/seafile-data입니다. 해당 위치에서 ls를 실행해도 유용한 정보를 얻을 수 없는데, 이는 파일 이름이 아닌 해시 이름으로 가득 찬 디렉터리만 보이기 때문이며 Invoices/2026/march.pdf을 확인할 수 없기 때문입니다.

동기화도 동일한 모델을 따릅니다. 클라이언트는 서버에 변경 사항을 문의하여 블록 해시 목록을 받은 뒤, 자신이 보유하지 않은 블록만 가져옵니다. 이것이 Seafile이 대규모 라이브러리에서도 원활하게 작동하는 이유입니다. 전송되는 바이트 수는 파일 전체 크기가 아니라 변경된 블록의 크기에 비례하기 때문입니다.

Nextcloud의 파일 저장 방식

Nextcloud는 사용자가 예상하는 위치의 디스크에 파일을 저장합니다. data/<username>/files/ 경로는 웹 인터페이스에서 사용자가 보는 구조를 그대로 반영합니다. oc_filecache 데이터베이스 테이블은 파일 크기, 수정 시간, etag 정보를 포함하여 동일한 트리 구조를 반영하며, Nextcloud는 디스크보다 이 테이블을 우선적으로 신뢰합니다.

데스크톱 클라이언트는 HTTPS를 통해 WebDAV(Web Distributed Authoring and Versioning) 프로토콜을 사용합니다. 각 파일마다 최소 한 번의 요청이 발생하므로, Nextcloud는 대량 업로드 API를 추가했습니다. 개발자 매뉴얼에 따르면, 작은 파일을 다수 업로드할 때는 네트워크 대역폭을 완전히 활용하지 못해 속도가 저하될 수 있으므로 작은 파일들을 하나로 묶어 처리합니다. 대용량 파일은 청킹(chunking) API를 거칩니다. 데스크톱 클라이언트는 기본적으로 100 MiB 단위의 청크(chunkSize 기본값은 104857600 바이트)로 시작하며, 최소 5 MiB에서 최대 100 MiB 사이에서 크기를 동적으로 조절할 수 있습니다.

디스크에 파일을 직접 저장하는 방식의 장점은 사용자가 이미 보유한 모든 도구로 데이터를 읽을 수 있다는 점입니다. 단점은 Nextcloud가 백엔드에서 직접 변경된 파일 내용을 즉시 인식하지 못한다는 것입니다. 데이터 디렉터리에 파일을 직접 복사하면 스캔을 수행하기 전까지는 웹 인터페이스에 나타나지 않습니다.

sudo -E -u www-data php occ files:scan --all -vv

관리자 매뉴얼은 데이터 디렉터리에 파일을 직접 복사한 경우, 마이그레이션 이후, 그리고 파일 캐시 불일치를 조사할 때와 같이 정확히 이러한 상황에서 재스캔을 수행하도록 명시하고 있습니다.

대규모 라이브러리를 더 빠르게 동기화하는 도구는 무엇입니까?

두 가지 취약한 상황, 즉 수만 개의 작은 파일이 있는 경우와 큰 파일을 반복적으로 수정하는 경우 모두 Seafile이 더 빠릅니다. Seafile은 블록 단위 중복 제거(block level deduplication) 메커니즘을 사용하므로, 중간 내용이 변경된 4 GB 디스크 이미지도 몇 개의 블록만 업로드하면 됩니다. Nextcloud는 대량 업로드(bulk upload) 기능을 통해 작은 파일에서의 격차를 줄이고 있지만, 전송 단위가 파일 전체이기 때문에 큰 파일에서의 성능 격차는 극복할 수 없습니다.

성능 격차에 대한 제 의견이나 벤더사의 벤치마크 결과를 그대로 믿지 마십시오. 실제 사용 환경과 유사한 라이브러리를 직접 구성하여 시간을 측정해 보십시오.

mkdir -p ~/synctest && cd ~/synctest
for i in $(seq 1 20000); do head -c 4096 /dev/urandom > "file_$i.bin"; done
du -sh ~/synctest

해당 디렉터리를 각 서버의 동기화 폴더에 넣고 클라이언트 작업이 완료될 때까지 기다리십시오. 신뢰성은 속도만큼이나 중요합니다. Seafile 클라이언트는 블록을 먼저 업로드한 뒤 해당 블록을 참조하는 커밋을 마지막에 기록합니다. 따라서 업로드가 중단되더라도 라이브러리는 절반만 기록된 상태가 아니라 이전 커밋 상태를 유지합니다.

소규모 VPS에서 각 서비스가 요구하는 사양

Seafile 공식 문서에서는 "최소 2G RAM 및 2코어 CPU(2GHz 초과)"를 요구합니다. 반면 Nextcloud 문서는 PHP 프로세스당 메모리 사용량을 기준으로 최소 128MB, 권장 512MB를 제시하며, 여기에 데이터베이스, 캐시, 미리보기 생성에 필요한 메모리를 더해 작업자 수만큼 곱해야 한다고 설명합니다. 아래는 소규모 팀을 위해 제가 사용하는 시작점입니다. 이는 측정값이 아닌 기준점입니다.

차트Starting point for about five users, and SQL databases per stack

label

start_ram_gb

start_cpu_cores

sql_databases

Seafile CE 13

Nextcloud 35

Syncthing 2

이 차트의 데이터

[
  {
    "label": "Seafile CE 13",
    "start_ram_gb": 4,
    "start_cpu_cores": 2,
    "sql_databases": 3
  },
  {
    "label": "Nextcloud 35",
    "start_ram_gb": 4,
    "start_cpu_cores": 2,
    "sql_databases": 1
  },
  {
    "label": "Syncthing 2",
    "start_ram_gb": 1,
    "start_cpu_cores": 1,
    "sql_databases": 0
  }
]

두 서비스 모두 4 GB RAM과 2 코어 사양에서 시작하므로, 메모리 점유율만으로는 선택의 기준이 되지 않습니다. Syncthing은 1 GB RAM과 1 코어에서 실행되는데, 이것이 Syncthing을 고려해야 하는 솔직한 이유입니다. 두 서비스는 메모리보다 구동 방식에서 더 큰 차이를 보입니다. Seafile은 3 개의 SQL 데이터베이스를 유지하는 반면 Nextcloud는 1 개를 유지합니다. 또한 기본 Seafile Docker 배포판은 먼저 다운로드한 파일들을 통해 서버, MariaDB, Redis, SeaDoc, Caddy를 한꺼번에 실행합니다.

mkdir /opt/seafile
cd /opt/seafile
wget -O .env https://manual.seafile.com/13.0/repo/docker/ce/env
wget https://manual.seafile.com/13.0/repo/docker/ce/seafile-server.yml
wget https://manual.seafile.com/13.0/repo/docker/seadoc.yml
wget https://manual.seafile.com/13.0/repo/docker/caddy.yml
nano .env

.env에서 SEAFILE_SERVER_HOSTNAME, MySQL 루트 및 데이터베이스 비밀번호, 초기 관리자 계정, 그리고 JWT_PRIVATE_KEY을 설정하십시오. 매뉴얼은 해당 키에 대해 32자 이상의 무작위 문자열을 요구하며, 첫 시작 시 이를 읽어 들이므로 스택을 올리기 전에 미리 생성해야 합니다.

openssl rand -base64 40
docker compose up -d

첫 시작 시 세 개의 데이터베이스와 관리자 사용자가 생성됩니다. TLS 및 리버스 프록시를 포함한 Nextcloud의 관련 설정은 Docker, TLS, 백업을 활용한 VPS의 Nextcloud 가이드에서 다룹니다.

백업 방식은 어떻게 다른가?

사람들이 가장 과소평가하는 부분이며, 두 제품이 가장 크게 차이 나는 지점입니다.

Seafile의 경우 백업 순서는 선택 사항이 아닙니다. 매뉴얼은 SQL을 먼저 백업하고 데이터 디렉터리를 나중에 백업하도록 규정합니다. 그래야 데이터베이스의 모든 레코드가 참조할 유효한 객체를 가지게 되어 라이브러리가 손상되지 않기 때문입니다. 순서를 바꾸면 데이터베이스 행이 스냅샷에 포함되지 않은 블록을 가리킬 수 있습니다.

docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt ccnet_db > ccnet_db.sql
docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt seafile_db > seafile_db.sql
docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt seahub_db > seahub_db.sql
rsync -az /opt/seafile-data/seafile /backup/data/

위 명령줄에는 두 가지 세부 사항이 있습니다. mariadb-dump을 사용하십시오. Seafile 매뉴얼이 mariadb 시리즈 명령어를 권장하기 때문입니다. mysql 명칭은 최신 MariaDB 릴리스에서 점진적으로 폐기되고 있으며, MariaDB 11.0부터 공식 Docker 이미지는 더 이상 mysqldump 명칭을 포함하지 않습니다. Seafile 13의 Compose 파일은 여전히 MariaDB 10.11을 기본값으로 사용하므로, 최신 데이터베이스 이미지로 전환할 때 이 점이 중요합니다. 파일로 리다이렉션할 때는 docker exec에서 -t 플래그를 제거하십시오. TTY는 줄 바꿈 문자를 재작성하여 덤프 파일을 손상시킬 수 있기 때문입니다.

두 부분은 별도로 캡처되므로 데이터 간의 불일치가 발생할 수 있습니다. 복원 후에는 신뢰하기 전에 저장소를 확인하십시오.

docker exec -it seafile bash
cd /opt/seafile/seafile-server-latest
./seaf-fsck.sh

누락된 항목이 있으면 도구가 해당 객체의 이름을 출력합니다.

Block 650fb22495b0b199cff0f1e1ebf036e548fcb95a is missing.
Repo ca1a860d HEAD commit is corrupted, need to restore to an old version.

가비지 컬렉션(garbage collection)도 계획에 포함하십시오. 중복 제거(deduplication) 기술을 사용하면 삭제된 파일과 라이브러리는 해당 디렉터리에서 ./seaf-gc.sh을 실행하기 전까지 블록을 계속 점유합니다. 실행 결과는 GC finished. 507 blocks total, about 507 reachable blocks, 0 blocks can be removed.와 같이 발견된 내용을 보고합니다. 1년 동안 이를 건너뛰면 사용자가 이미 삭제한 데이터에 대해 백업 비용을 계속 지불하게 됩니다.

Nextcloud도 데이터 디렉터리와 데이터베이스가 동일한 트리 구조를 설명해야 한다는 점에서 동일한 이원적 문제를 안고 있습니다.

sudo -E -u www-data php occ maintenance:mode --on
rsync -Aavx /srv/nextcloud/ /backup/nextcloud-dirbkp/
mariadb-dump --single-transaction --default-character-set=utf8mb4 -u nextcloud -p"$DB_PASS" nextcloud > /backup/nextcloud-sqlbkp.bak
sudo -E -u www-data php occ maintenance:mode --off

config 폴더, data 폴더, 사용자 지정 앱, 테마, 그리고 데이터베이스 덤프를 모두 보관하십시오. 두 부분 모두 동일한 시점의 데이터로 복원해야 합니다. 데이터 디렉터리가 데이터베이스보다 최신이면 사용자는 파일 캐시가 인식하지 못하는 파일을 보게 되며, occ files:scan --all가 이를 복구합니다. 데이터베이스가 더 최신이면 캐시 행이 이미 사라진 파일을 가리키게 되며, occ files:cleanup이 저장소 테이블에 일치하는 항목이 없는 캐시 항목을 제거합니다.

어떤 경우든 다수의 작은 파일을 처리하고 이력을 유지할 수 있는 백업 프로그램이 필요하며, 이것이 바로 restic과 BorgBackup이 다르게 접근하는 방식입니다.

데스크톱 및 모바일 클라이언트

Seafile은 두 가지 데스크톱 프로그램을 제공합니다. 동기화 클라이언트는 선택한 라이브러리의 로컬 복사본을 유지합니다. 드라이브 클라이언트(SeaDrive)는 라이브러리를 가상 드라이브로 마운트하고 접근 시점에 파일을 다운로드합니다. Windows에서는 Microsoft의 cloud files API를 사용하며, macOS 버전 3.0은 Finder 확장 프로그램으로 동작합니다. Linux의 경우 3.0.12 버전부터 AppImage 형태로 제공되며 ~/SeaDrive 경로에 마운트됩니다. Windows와 macOS에서 암호화된 라이브러리는 트레이 메뉴에서 선택하고 암호를 입력하기 전까지 드라이브 클라이언트에서 숨겨진 상태로 유지됩니다. 모바일 앱은 파일 접근을 목적으로 하며, 오직 그 기능에만 집중합니다.

Nextcloud 데스크톱 클라이언트 또한 가상 파일 기능을 제공하며, 모바일 앱은 플랫폼의 나머지 기능을 포함하므로 파일 접근과 더불어 캘린더, 연락처, Talk, 메모 기능을 함께 사용할 수 있습니다. 사용자가 모바일 기기를 주로 사용하며 파일 이상의 기능을 원한다면, 이는 일상적인 사용 측면에서 실질적인 차이가 됩니다.

Seafile 사용 시 한 가지 세부 사항은 사전 계획이 필요합니다. 라이브러리는 공유, 동기화, 권한 설정 및 암호화의 단위입니다. 500 GB의 데이터를 단일 라이브러리에 업로드하기 전에 라이브러리 구조를 결정하십시오. 라이브러리 간의 이동은 이름 변경이 아닌 복사 후 삭제 방식으로 처리되므로, 파일의 기록(history)이 함께 이동하지 않기 때문입니다.

암호화: 각 방식이 실제로 보호하는 범위

Seafile의 암호화된 라이브러리는 클라이언트 측에서 처리됩니다. 비밀번호는 서버에 절대 저장되지 않습니다. 비밀번호와 라이브러리 ID에서 파생된 매직 토큰이 라이브러리와 함께 저장되므로, 클라이언트는 동기화 전에 비밀번호를 확인할 수 있습니다. 파일 키는 비밀번호에서 파생된 키와 IV(초기화 벡터)를 사용하여 AES 256/CBC 방식으로 암호화되며, 파일 데이터는 해당 파일 키로 암호화됩니다.

사람들이 자주 간과하는 문서화된 제한 사항을 읽어보십시오. 암호화된 라이브러리는 파일 내용만 암호화합니다. 폴더명과 파일명은 암호화되지 않으며, 파일 크기나 편집 기록도 마찬가지입니다. 웹 브라우저에서 암호화된 라이브러리를 탐색하는 것은 종단간(end-to-end) 암호화가 아닙니다. 사용자가 비밀번호를 입력하면 서버가 이를 사용하여 파일 키를 복호화하고, 해당 비밀번호를 메모리에 1시간 동안 캐시합니다. 매뉴얼에서도 명시하듯, 암호화된 라이브러리는 무결성을 보장하지 않습니다. 서버 관리자가 파일 내용의 일부를 변경해도 클라이언트가 이를 감지할 수 없기 때문입니다.

Nextcloud에는 혼동하기 쉬운 유사한 이름의 두 가지 기능이 있습니다. 서버 측 암호화(Server side encryption)는 저장된 파일(at rest)을 암호화하지만 키를 동일한 서버에 보관하므로, 외부 저장소에 보관된 데이터를 보호하는 데는 효과적이지만 서버의 root 권한을 가진 공격자로부터 사용자를 보호하는 데는 한계가 있습니다. 종단간 암호화(End to end encryption) 앱은 클라이언트에서 선택한 폴더를 암호화하며, 설계상 서버가 내용을 읽을 수 없으므로 웹 인터페이스, 서버 측 검색 및 미리보기 기능도 해당 폴더 내부를 볼 수 없습니다.

두 제품의 암호화 기능 모두 암호화된 백업을 대체할 수 없습니다. 백업은 별도로 암호화하십시오.

캘린더, 연락처, 오피스 및 앱 플랫폼

이 영역은 두 서비스의 차이가 큽니다. Nextcloud는 CalDAV(WebDAV 기반 캘린더)와 CardDAV(WebDAV 기반 연락처)를 핵심 기능으로 제공하며, 문서 작업을 위해 Collabora나 OnlyOffice를 통합하고 그 외 모든 기능을 위한 앱 스토어를 갖추고 있습니다. Seafile 13은 협업 문서 및 위키 페이지를 위한 SeaDoc을 제공하고, 별도로 배포한 OnlyOffice 서버를 통해 오피스 파일을 열고 편집할 수 있지만, 거기까지가 전부입니다. 캘린더나 주소록 기능은 없습니다.

이 플랫폼을 사용하는 데는 비용이 따르며, 그 비용은 바로 업그레이드입니다. 설치하는 모든 앱은 Nextcloud 업그레이드를 방해하거나 업그레이드 후 오작동을 일으킬 수 있는 요소가 됩니다. 따라서 사용자가 의존하는 기능이 많을수록 업그레이드 작업을 더욱 신중하게 진행해야 합니다. Seafile은 제공하는 기능이 적은 만큼 문제가 발생할 여지도 적습니다. 또한 Seafile Professional 버전(Community Edition 아님)에서만 문서 내 전체 텍스트 검색과 폴더 수준의 권한 설정이 가능하다는 점을 유의하십시오. Professional 버전은 사용자 3명까지는 라이선스 비용 없이 사용할 수 있지만, 그 이상부터는 라이선스가 필요합니다. 따라서 사용하려는 기능이 계획 중인 에디션에 포함되어 있는지 반드시 확인하십시오.

각 서비스의 주요 장애 유형

Seafile은 데이터베이스와 객체 저장소(object store) 간의 데이터 불일치가 발생할 때 장애가 일어납니다. 라이브러리가 열리지 않거나 파일이 사라지는 현상이 나타나며, seaf-fsck.sh 명령어가 누락된 블록을 출력합니다. 수동으로 복구할 수 있는 파일 트리가 존재하지 않으므로, 데이터베이스 덤프와 객체 저장소를 올바른 순서로 복원해야 합니다. 복원 절차는 예비 VPS에서 반드시 한 번은 테스트하십시오. 복원해 본 적 없는 백업은 그저 추측에 불과합니다.

Nextcloud는 파일 캐시와 실제 디스크 상태가 일치하지 않을 때 장애가 발생합니다. 보통 Nextcloud를 통하지 않고 데이터 디렉터리에 직접 파일을 썼을 때 나타납니다. 웹 인터페이스에는 보이지 않는 파일이 디스크에 존재하거나 폴더 크기가 잘못 표시되는 문제가 발생하며, 이때는 occ files:scan 명령어로 해결할 수 있습니다. 그 외의 취약점은 다수의 작은 파일을 처리할 때의 프로토콜 속도인데, 이는 CPU 성능을 높여도 해결되지 않습니다. 또한 PHP 메모리 문제도 빈번합니다. 대용량 이미지나 동영상 미리보기 생성 시 메모리 사용량이 급증하므로, 프로세스당 512 MB를 유지하고 미리보기 생성은 요청 처리 중이 아닌 예약된 작업(scheduled job)으로 수행하십시오.

둘 다 아닙니다: 파일 동기화만 필요하다면 Syncthing을 사용하십시오

여러 기기 간에 폴더 하나를 미러링하는 것이 실제 요구 사항이라면, 두 제품 모두 필요한 것보다 과한 소프트웨어입니다. Syncthing은 서버나 계정이 필요 없습니다. 모든 기기가 피어(peer)로 동작하며, VPS는 노트북이 절전 모드일 때도 깨어 있는 피어 역할을 합니다. 현재 Syncthing 2가 최신 라인업이며, 패키지는 프로젝트 공식 저장소에서 제공합니다:

sudo mkdir -p /etc/apt/keyrings
sudo curl -L -o /etc/apt/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg
echo "deb [signed-by=/etc/apt/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing stable-v2" | sudo tee /etc/apt/sources.list.d/syncthing.list
sudo apt-get update
sudo apt-get install syncthing

파일 소유권이 올바르게 설정되도록 root가 아닌 일반 사용자 권한으로 실행하십시오:

sudo systemctl enable --now syncthing@youruser
systemctl status syncthing@youruser

웹 인터페이스는 기본적으로 127.0.0.1:8384에 바인딩되므로 인터넷에서 직접 접근할 수 없으며, 이는 올바른 기본 설정입니다. 노트북에서 SSH 터널을 통해 접근하십시오:

ssh -L 8384:127.0.0.1:8384 youruser@your-server

그런 다음 노트북에서 http://127.0.0.1:8384를 여십시오. Syncthing 자체는 TCP 및 QUIC를 통해 22000 포트를 사용하며, 로컬 탐색에는 UDP 21027을 사용하는데 이는 인터넷을 통해 작동하지 않습니다. VPS에서는 22000 포트만 열고 웹 인터페이스는 닫아 두십시오:

sudo ufw allow 22000/tcp
sudo ufw allow 22000/udp

포기해야 할 점은 모든 서버 기능입니다. Syncthing을 사용하지 않는 사람을 위한 공유 링크, 웹 파일 브라우저, 사용자 계정은 없으며, 폴더별로 파일 버전 관리를 활성화하지 않는 한 서버 측 휴지통도 없습니다. 흔히 발생하는 문제는 충돌 파일입니다. 두 기기가 서로 연결되지 않은 상태에서 동일한 파일을 수정하면 notes.sync-conflict-20260806-142233-ABCD1EF.md와 같은 이름의 형제 파일이 생성됩니다. 별도의 경고가 없으므로 가끔 sync-conflict을 검색해 보아야 합니다.

동기화된 폴더가 아니라 애플리케이션이 데이터를 기록할 버킷이 필요하다면, 이는 다른 도구의 영역입니다. 자체 호스팅 S3 호환 객체 스토리지를 참조하십시오. 더 넓은 범위의 대안은 자체 호스팅 Dropbox 대안 정리에서 이 비교에 포함되지 않은 내용을 다룹니다.

의사결정 규칙

다수의 파일, 대용량 파일, 여러 기기 간의 동기화가 주 목적이라면 Seafile을 선택하십시오. 단, Seafile 전용 형식으로 저장된 데이터만 읽을 수 있다는 점을 감수해야 합니다.
캘린더, 연락처, 문서, 공유 링크 등 플랫폼 기능이 필요하다면 Nextcloud를 선택하십시오. 디스크에 일반 파일 형태로 저장되므로 모든 백업 도구로 읽을 수 있습니다.
단순히 폴더 미러링만 필요하다면 Syncthing을 선택하십시오.

신중하게 선택하십시오. Seafile과 Nextcloud 간의 마이그레이션은 실질적인 종속(lock-in) 문제를 야기합니다. 변환 도구가 존재하지 않기 때문입니다. 모든 데이터를 클라이언트로 동기화한 뒤 다른 서버에 다시 업로드해야 하며, 이 과정에서 대역폭과 시간이 소모될 뿐만 아니라 버전 기록과 공유 링크도 모두 유실됩니다. 2년 차에 시스템을 교체하는 것보다 현재의 선택을 향후 3년까지 고려하여 규모를 산정하는 것이 비용 면에서 훨씬 효율적입니다.

FAQ

대용량 라이브러리 동기화 시 Seafile이 Nextcloud보다 빠른가요?

그렇습니다. 성능 저하가 발생하는 두 가지 상황에서 Seafile이 더 효율적이며, 그 이유는 직접 확인할 수 있습니다. Seafile은 파일을 평균 8 MB 크기의 블록으로 분할하여 변경된 블록만 전송하므로, 대용량 파일 내부를 수정해도 일부 블록만 이동합니다. 반면 Nextcloud는 전체 파일을 전송 단위로 삼기 때문에 동일한 수정 시 파일 전체를 다시 업로드해야 합니다. 또한 작은 파일이 많을 경우 파일마다 최소 하나의 WebDAV 요청이 발생하므로, Nextcloud의 대량 업로드 API는 작은 파일들을 묶어서 처리합니다. CPU, 디스크, 네트워크 환경이 프로토콜만큼이나 중요하므로, 도입 전 본인의 VPS에서 직접 시간을 측정해 보시기 바랍니다.

데이터 디렉터리에 rsync를 실행하여 Seafile을 백업할 수 있나요?

데이터베이스와 함께 문서화된 순서대로만 가능합니다. Seafile 매뉴얼은 SQL을 먼저 백업하고 데이터 디렉터리를 나중에 백업할 것을 권장합니다. 그래야 모든 데이터베이스 레코드가 백업 내에 존재하는 객체를 참조할 수 있기 때문입니다. rsync -az /opt/seafile-data/seafile /backup/data/ 명령은 conf, seafile-data, seahub-data을 복사하지만, 객체 저장소에는 읽을 수 있는 파일 트리가 없고 데이터베이스가 그 색인 역할을 하므로 이 명령만으로는 복구가 불가능합니다. 두 부분을 모두 복원한 후에는 seaf-fsck.sh을 실행하고 결과를 신뢰하기 전에 출력 내용을 확인하십시오.

파일 동기화만 필요해도 Nextcloud가 필요한가요?

아닙니다. Nextcloud는 하나의 플랫폼이며, 캘린더, 연락처, 앱 스토어는 사용 여부와 관계없이 메모리를 점유하고 업그레이드 관리가 필요합니다. 단순 파일 동기화가 목적이라면 Seafile이 더 가볍고 프로토콜도 빠릅니다. 서버를 구동할 필요가 없는 Syncthing은 더 가볍습니다. Nextcloud는 기본 선택지가 아니라, 추가 애플리케이션이 필요할 때 선택하십시오.

Seafile의 암호화된 라이브러리는 파일 이름을 숨겨주나요?

아닙니다. 암호화된 라이브러리는 클라이언트 측에서 파일 내용을 암호화하며 비밀번호는 서버로 전송되지 않지만, 폴더 이름, 파일 이름, 파일 크기, 편집 기록은 서버에서 모두 보입니다. 웹 인터페이스에서 암호화된 라이브러리를 열면 비밀번호가 서버로 전송되어 파일 키를 복호화하며, 비밀번호는 1시간 동안 메모리에 유지됩니다. 파일 이름 자체가 민감한 정보라면 해당 라이브러리를 웹 인터페이스에서 사용하지 말고 다른 계층에서 암호화하십시오.

VPS에서 Seafile이나 Nextcloud에 RAM을 얼마나 할당해야 하나요?

사용자가 적다면 두 서비스 모두 4 GB RAM과 2 개의 코어로 시작한 뒤, 미리보기 생성이나 검색 시 메모리 사용량을 모니터링하십시오. Seafile 공식 문서에서는 최소 사양으로 2 GB RAM과 2 GHz 이상의 2 코어 CPU를 제시합니다. Nextcloud는 PHP 프로세스당 512 MB를 권장하며, 여기에 워커 수를 곱한 뒤 데이터베이스와 캐시 용량을 더해야 합니다. Syncthing은 1 GB 환경에서도 원활하게 동작합니다.

#seafile #nextcloud #file-sync #self-hosted #storage