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

Seafile 대 Nextcloud: 요약

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

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

Seafile이 파일을 저장하는 방식

Seafile은 git이 저장소를 모델링하는 방식과 유사하게 라이브러리를 모델링합니다. 관리자 매뉴얼에서는 내부 모델을 Repo, Commit, FS, Block으로 정의하며, 저장소(repo)를 라이브러리라고도 부른다고 명시합니다. 각 파일은 콘텐츠 정의 청킹(CDC, 데이터 자체에서 블록 경계를 선택하는 알고리즘)을 통해 가변 길이의 블록으로 분할되며, 매뉴얼에 따르면 평균 블록 크기는 약 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를 통해 전송되며, 데스크톱 클라이언트의 기본 청크 크기는 5 MiB입니다(OWNCLOUD_CHUNK_SIZE의 기본값은 5242880 바이트입니다).

디스크에 파일을 직접 저장하는 방식의 장점은 기존에 사용하던 모든 도구로 데이터를 읽을 수 있다는 점입니다. 단점은 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 프로세스당 메모리 사용량을 기준으로 하며, 프로세스당 최소 128 MB, 권장 512 MB를 제시합니다. 이 수치에 워커 수를 곱한 뒤 데이터베이스, 캐시, 미리보기 생성에 필요한 메모리를 더해야 합니다. 아래는 소규모 팀을 위해 제가 제안하는 시작 사양입니다. 이는 측정값이 아닌 시작점입니다.

[
  {
    "label": "Seafile CE 13",
    "start_ram_gb": 4,
    "start_cpu_cores": 2,
    "sql_databases": 3
  },
  {
    "label": "Nextcloud 34",
    "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, Memcached, 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 명령 계열은 더 이상 사용되지 않기 때문입니다. 파일로 리다이렉트할 때는 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.

가비지 컬렉션 계획도 세워야 합니다. 중복 제거 기능 때문에 삭제된 파일과 라이브러리는 ./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 경로에 마운트됩니다. 암호화된 라이브러리는 세 가지 데스크톱 플랫폼 모두에서 지원됩니다. 모바일 앱은 파일 접근을 목적으로 하며, 오직 그 기능에만 집중합니다.

Nextcloud의 데스크톱 클라이언트 역시 가상 파일 기능을 제공하며, 모바일 앱은 플랫폼의 나머지 기능을 모두 포함합니다. 따라서 파일 접근뿐만 아니라 캘린더, 연락처, Talk, 메모 기능을 함께 사용할 수 있습니다. 사용자가 모바일 기기를 주로 사용하며 파일 이상의 기능을 원한다면, 이는 일상적인 사용 환경에서 큰 차이가 됩니다.

Seafile 사용 시 한 가지 주의할 점은 라이브러리가 공유, 동기화, 권한 설정 및 암호화의 기본 단위라는 것입니다. 500 GB의 데이터를 하나의 라이브러리에 넣기 전에 라이브러리 구조를 먼저 결정하십시오. 라이브러리 간의 이동은 이름 변경이 아니라 복사 후 삭제로 처리되므로, 파일의 이전 기록이 함께 이동하지 않기 때문입니다.

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

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을 제공하는 선에서 멈춥니다. 캘린더나 주소록 기능은 없습니다.

이 플랫폼을 사용하는 데는 대가가 따르며, 그 대가는 업그레이드 과정에서 나타납니다. 설치하는 앱 하나하나가 Nextcloud 업그레이드를 방해하거나 업그레이드 후 오작동을 일으킬 수 있는 요소가 됩니다. 따라서 사용자가 의존하는 기능이 많을수록 업그레이드 작업은 더욱 신중해져야 합니다. Seafile은 제공하는 기능이 적은 만큼 고장 날 요소도 적습니다. 또한 문서 내 전체 텍스트 검색이나 폴더 단위 권한 설정은 Community Edition이 아닌 Seafile Professional에서 유료 라이선스로 제공된다는 점을 유의하십시오. 따라서 계획 중인 에디션에 필요한 기능이 포함되어 있는지 반드시 확인해야 합니다.

각 서비스의 주요 장애 유형

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 대안 정리에서 이 비교에 포함되지 않은 내용을 다룹니다.

의사결정 규칙

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