직접 호스팅할 만한 Nextcloud 대안 추천

직접 호스팅할 만한 Nextcloud 대안은 무엇인가?

직접 호스팅할 가치가 있는 Nextcloud 대안은 사용하지 않는 기능을 제거한 서비스들입니다. Nextcloud는 파일 서버, 캘린더, 주소록, 오피스 제품군, 앱 플랫폼을 하나의 PHP 애플리케이션에 모두 담고 있으며, 페이지를 불러올 때마다 이 모든 기능에 대한 비용을 지불하게 됩니다. 따라서 여전히 필요한 단 하나의 기능을 기준으로 대체제를 선택하고, 기존 파일을 이전하는 데 드는 비용을 확인하십시오.

이 가이드는 동기화 전용, 더 빠른 서버를 통한 동기화, 클라이언트가 포함된 객체 스토리지, 단순 원격 파일 접근 등 기능별로 옵션을 분류합니다. 각 섹션에서는 소규모 VPS(가상 사설 서버)에서 필요한 서버 사양과 기존 폴더 구조에 어떤 변화가 생기는지 설명합니다. 만약 운영 중인 Nextcloud 서버가 아니라 Dropbox나 Google Drive에서 넘어오는 경우라면, 직접 호스팅 가능한 Dropbox 대안 총정리를 먼저 확인하는 것이 좋습니다.

소규모 VPS에서 Nextcloud가 느려지는 이유

속도 저하에는 명확한 원인이 있으며, 이를 파악하면 서버를 이전하는 것이 실제로 도움이 될지 판단할 수 있습니다.

모든 페이지 로드는 PHP 워커를 점유합니다. Nextcloud의 시스템 요구 사항에 따르면 2026년 8월 기준 프로세스당 최소 128 MB, 권장 512 MB의 메모리가 필요합니다. 이는 서버 전체 메모리가 아닙니다. 2 GB 플랜에서 10개의 워커 풀은 상당한 메모리 예산을 차지하므로, 관리자는 PHP-FPM 풀 설정에서 pm.max_children 값을 낮추게 되며, 이로 인해 요청이 기존 워커 뒤에서 대기하게 됩니다. 디스크가 유휴 상태여도 인터페이스는 느리게 느껴집니다.

데이터베이스는 바이트 단위가 아니라 파일 개수에 비례하여 커집니다. 기본 테이블 접두사를 사용하는 oc_filecache 파일 캐시 테이블은 서버가 인식하는 모든 저장소의 파일 및 폴더마다 한 행씩을 유지합니다. 300,000개의 작은 파일로 구성된 사진 라이브러리는 큰 테이블을 만들지만, 400개의 파일로 구성된 300 GB의 동영상 파일은 작은 테이블을 만듭니다. 공유, 검색, 파일 스캐너 모두 해당 테이블을 읽습니다.

sudo mysql nextcloud -e 'SELECT COUNT(*) FROM oc_filecache;'

수백만 건의 데이터는 디스크 벤치마크보다 파일 목록이 느린 이유를 더 잘 설명해 줍니다. 인스턴스가 다른 테이블 접두사나 PostgreSQL을 사용하는 경우 쿼리를 조정하십시오.

백그라운드 작업이 웹 인터페이스와 자원을 경쟁합니다. Nextcloud 매뉴얼은 5분마다 cron.php을 실행하는 시스템 cron 항목을 권장합니다. 미리보기 생성과 파일 스캔은 브라우저에 응답하는 동일한 CPU에서 실행됩니다.

메이저 업그레이드는 데이터베이스 마이그레이션입니다. 인스턴스는 유지보수 모드로 전환되며 마이그레이션이 완료될 때까지 모든 요청에 Nextcloud is in maintenance mode, please try again later로 응답합니다. 대규모 oc_filecache를 가진 소규모 VPS에서는 이 대기 시간이 체감될 정도로 깁니다.

먼저 유지할 항목 결정하기

• 웹 인터페이스 없이 소유한 기기 간에 폴더 하나를 동기화하려면: Syncthing을 사용합니다.
• 웹 인터페이스, 모바일 클라이언트, 공유 링크를 갖추고 여러 사용자와 동기화하려면: Seafile을 사용합니다.
• 대용량 데이터를 저렴하게 저장하고 스크립트나 백업 도구에서 접근하려면: 오브젝트 스토리지와 클라이언트를 조합합니다.
• 새로운 서버 소프트웨어 없이 원격으로 파일을 읽고 쓰려면: SFTP 또는 WebDAV를 사용합니다.
• 브라우저에서 문서를 공동 편집하거나 사용자 간에 캘린더를 공유하려면: Nextcloud를 계속 사용하거나, 두 가지 서비스를 운영하는 방안을 수용합니다.

Syncthing: 서버 애플리케이션 없는 파일 동기화

Syncthing은 파일을 일반적인 파일 형태로 유지합니다. 별도의 콘텐츠 데이터베이스나 문서를 제공하는 웹 인터페이스는 존재하지 않습니다. 폴더에 참여하는 모든 기기는 전체 복사본을 보유하며, Syncthing은 이 복사본들을 동일하게 유지합니다.

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

sudo systemctl enable --now syncthing@$USER
sudo ss -lntp | grep 8384

127.0.0.1:8384이 포함된 줄은 웹 인터페이스가 실행 중이며 localhost에만 바인딩되었음을 의미합니다. 이는 공용 VPS에서 권장되는 설정입니다. SSH 터널을 통해 ssh -L 8384:127.0.0.1:8384 you@your-vps로 접근한 뒤, 노트북에서 http://127.0.0.1:8384을 엽니다. 8384 포트에서 리스너가 확인되지 않는다면 서비스 시작에 실패한 것이며, journalctl -u syncthing@$USER -n 50에서 그 이유를 확인할 수 있습니다.

리소스. Syncthing은 최소 메모리 요구 사양을 명시하지 않습니다. Syncthing이 사용하는 메모리 양은 파일의 총 크기가 아니라 인덱싱된 파일의 개수에 비례합니다. 공유 폴더 내의 파일마다 인덱스 항목을 유지하기 때문입니다. 대용량 폴더를 처음 스캔할 때는 CPU 작업이 집중됩니다. Syncthing은 비교를 시작하기 전에 모든 파일의 해시를 계산해야 합니다. 첫 번째 스캔은 공유 vCPU 환경에서 다소 시간이 걸릴 수 있으며, 메모리 사용량은 기가바이트 단위가 아닌 파일 개수에 따라 증가한다는 점을 참고하십시오.

디스크 공간이 실제 비용입니다. Syncthing은 서버가 아니므로 서버 측 저장 공간 절약 기능은 없습니다. VPS와 노트북 간에 200 GB 폴더를 공유하면 양쪽 모두에 200 GB의 공간이 필요합니다. 이는 서버가 모든 데이터를 보유하고 클라이언트가 필요한 것만 동기화하는 Nextcloud와는 정반대 방식입니다. VPS가 피어(peer)가 아닌 백업 대상이라면 선택적 폴더 기능과 receive only 폴더 설정을 사용하십시오.

마이그레이션이 이 도구를 선택하는 이유입니다. 이미 존재하는 디렉터리 트리를 Syncthing에 지정하기만 하면 됩니다. 별도의 가져오기, 업로드, 변환 과정이 없습니다. VPS에서 폴더를 추가하고, 노트북에서도 동일한 폴더 ID로 추가하여 양쪽이 동기화되도록 합니다. 첫 연결 시 양쪽에 동일한 파일이 서로 다르게 존재한다면, Syncthing은 두 파일을 모두 보존하고 하나를 filename.sync-conflict-20260809-142530-ABCD123.txt로 이름을 변경합니다. 이러한 파일이 생성되는 것은 첫 동기화 시 발생하는 정상적인 과정이며, 오류가 아닙니다.

포기해야 할 점. 계정 기능, 다른 사람에게 보낼 공유 링크, 모바일 브라우저를 통한 파일 탐색 기능은 제공하지 않습니다. 원본 Android 앱은 더 이상 프로젝트 자체에서 유지보수하지 않으며 커뮤니티 포크 버전이 개발을 이어가고 있습니다. 모바일 접근성이 중요하다면 이 점을 고려해야 합니다. Syncthing과 Nextcloud의 직접 비교 문서에서 기능적 차이를 하나씩 확인할 수 있습니다.

Seafile: 더 가벼운 서버로 빠르게 동기화하기

Seafile은 작업을 둘로 나눕니다. Seahub이라는 Python 웹 애플리케이션이 인터페이스를 담당하고, 별도의 C 프로세스가 동기화 트래픽을 처리합니다. 파일 전송이 웹 애플리케이션을 거치지 않으므로, 다른 사용자가 인터페이스를 탐색하는 동안에도 대용량 업로드가 빠르게 유지됩니다. 13.0 버전은 2026년 1월 5일에 출시되었습니다.

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

작업을 시작하기 전에 .env를 편집하십시오. 이 파일은 SEAFILE_SERVER_HOSTNAME, INIT_SEAFILE_ADMIN_EMAIL, INIT_SEAFILE_ADMIN_PASSWORD, SEAFILE_MYSQL_DB_PASSWORD 및 최소 32자 이상의 무작위 문자열이어야 하는 JWT_PRIVATE_KEY을 설정합니다. 또한 이 파일은 다운로드한 YAML 파일 중 어떤 것을 읽을지 compose에 지시하여, 네 개의 다운로드 항목이 하나의 스택으로 작동하게 합니다.

cd /opt/seafile
sudo docker compose up -d
sudo docker compose ps

모든 컨테이너는 실행 상태를 보고해야 합니다. 컨테이너가 반복적으로 재시작된다면 거의 항상 .env의 값이 누락된 경우이며, sudo docker compose logs seafile에서 어떤 값이 문제인지 확인할 수 있습니다.

리소스. 2026년 8월 기준으로 Seafile 문서에서는 최소 2 GB의 RAM과 2 GHz 이상의 2코어 CPU를 요구합니다. Docker 배포 시 MariaDB, Caddy 리버스 프록시, SeaDoc 편집기도 함께 실행되므로 이 사양을 전체 스택의 최소 요구 사항으로 간주하십시오. 두 명 이상의 사용자가 사용한다면 4 GB를 할당하거나, 선택 사항인 컨테이너를 제외하십시오.

마이그레이션 시 주의할 점은 저장 형식입니다. Seafile은 파일을 파일 그대로 저장하지 않습니다. 각 파일을 /opt/seafile-data 아래의 블록으로 분할하고 데이터베이스에 트리 구조로 기록합니다. 기존 디렉터리를 Seafile에 지정하여 라이브러리로 바로 사용할 수는 없으므로, 데이터를 옮기려면 보유한 모든 데이터를 한 번 전체 업로드해야 합니다. 동일한 설계 구조로 인해 cp을 사용하여 데이터를 직접 꺼낼 수 없습니다. 복구는 서버를 통하거나, 일관성 검사를 위한 seaf-fsck, 또는 읽기 전용 seaf-fuse 마운트를 통해 수행해야 합니다.

rclone은 Seafile 전용 백엔드를 지원하므로, 긴 드래그 앤 드롭 세션 대신 업로드를 재개 가능한 하나의 명령어로 처리할 수 있습니다.

rclone config
rclone copy /srv/files seafile:MyLibrary --progress

rclone 문서에는 Seafile 6.x부터 9.x 버전까지 테스트되었다고 명시되어 있으므로, 테라바이트 단위의 데이터를 전송하기 전에 작은 폴더 하나를 대상으로 먼저 테스트하여 결과를 확인하십시오.

암호화된 라이브러리는 사용자들이 이 서비스를 선택하는 핵심 기능입니다. 암호는 클라이언트에서 설정하며, 서버는 읽을 수 없는 블록 형태로 데이터를 저장합니다. 한 가지 솔직한 주의 사항은, 브라우저에서 암호화된 라이브러리의 파일을 미리 볼 경우 해당 세션 동안 암호가 서버로 전송된다는 점입니다. 따라서 브라우저 미리 보기와 제로 지식(zero-knowledge) 저장은 동시에 사용할 수 없습니다. Seafile과 Nextcloud 비교에서 나머지 기능 차이를 다룹니다.

동기화 클라이언트를 활용한 오브젝트 스토리지

많은 양의 데이터를 저렴하게 저장하고 스크립트에서 접근하는 것이 목적이라면, S3 호환 오브젝트 스토리지를 운영하고 동기화는 별도의 도구로 처리하는 것이 좋습니다. 이 방식을 사용하면 데이터 내구성, 버전 관리, 그리고 이미 대부분의 백업 도구가 지원하는 프로토콜을 활용할 수 있습니다. 다만 파일 서버와 같은 사용자 계정 관리 기능이나 일반 사용자가 선호할 만한 파일 관리자는 제공되지 않습니다. MinIO를 이용한 자체 호스팅 오브젝트 스토리지에서 서버 측 설정을 다룹니다.

rclone copy /srv/files s3remote:mybucket --progress
rclone check /srv/files s3remote:mybucket

rclone check는 양측의 파일 크기와 해시값을 비교하여 차이가 있는 파일의 개수를 출력합니다. 0이 아닌 결과가 나오면 복사가 완료되지 않은 것이므로, 원본을 삭제하기 전에 copy를 다시 실행해야 합니다. 두 가지 주의할 점이 있습니다. 오브젝트 스토리지는 디렉터리 구조가 없으며 키 접두사(key prefix)만 존재하므로 빈 폴더는 복사되지 않습니다. 또한 --transfers 값을 S3 청크 크기와 함께 높이면 rclone의 메모리 사용량이 급증하므로, 1 GB RAM을 가진 VPS에서는 두 설정 모두 기본값을 유지하는 것이 좋습니다.

단순히 원격 파일만 필요하다면 일반 WebDAV나 SFTP를 사용하십시오

가장 저렴한 대체 수단은 새로운 것을 도입하지 않는 것입니다. VPS에서 OpenSSH를 실행 중이라면 이미 파일 서버를 갖춘 셈입니다. SFTP는 별도의 데몬, 데이터베이스, PHP가 필요 없으며 일요일에 갑자기 업데이트가 실패하여 서비스가 중단될 위험도 없습니다.

sftp you@your-vps
rclone mount sftpremote: ~/vps --vfs-cache-mode writes

대부분의 모바일 파일 관리자를 포함하여 WebDAV를 지원하는 클라이언트의 경우, rclone을 사용하여 동일한 디렉터리 구조를 서비스할 수 있습니다.

sudo apt install apache2-utils
sudo htpasswd -c /etc/rclone/htpasswd you
rclone serve webdav --addr 127.0.0.1:8080 --htpasswd /etc/rclone/htpasswd /srv/files

이를 127.0.0.1에 바인딩하고 그 앞에 TLS(전송 계층 보안)를 적용한 리버스 프록시를 배치하십시오. WebDAV 기본 인증은 모든 요청마다 비밀번호를 전송하므로, 일반 HTTP를 사용하면 1분에도 여러 번 비밀번호가 노출됩니다. 파일 이동이 필요 없으므로 마이그레이션 비용은 0입니다. 단점은 동기화 기능과 오프라인 복사본이 없다는 점입니다. 연결이 끊기면 다시 연결될 때까지 클라이언트에서 파일에 접근할 수 없습니다.

캘린더, 연락처, 문서 편집을 대체하는 방법

Nextcloud를 떠나면 포기해야 하는 기능이 있으며, 무엇을 잃게 되는지 명확히 이해하는 것이 중요합니다. 캘린더와 연락처는 CalDAV와 CardDAV(HTTP를 통한 캘린더 및 연락처 동기화) 표준을 따르며, Radicale은 이를 대체할 수 있는 가벼운 도구입니다. Radicale은 각 컬렉션을 디스크에 파일 형태로 저장하며 수십 메가바이트의 메모리만 사용합니다.

sudo apt install radicale
sudo systemctl enable --now radicale
sudo ss -lntp | grep 5232

이 패키지는 /usr/lib/systemd/system/radicale.service을 포함하며 기본 설정 파일은 /etc/radicale/config에 위치하고, localhost:5232에서 대기합니다. Radicale은 이벤트를 편집하는 인터페이스를 제공하지 않으므로, 휴대폰이나 데스크톱 클라이언트를 연결하여 해당 클라이언트에서 편집해야 합니다.

브라우저 기반 문서 편집 기능을 대체하기는 더 어렵습니다. OnlyOffice Docs와 Collabora Online은 모두 편집 엔진일 뿐 저장소가 아닙니다. 각 엔진은 파일을 보관하고 문서를 전달해 줄 호스트 애플리케이션이 필요합니다. Nextcloud를 제거하면 Seafile과 같이 자체적인 SeaDoc 편집기를 갖춘 다른 호스트가 필요합니다. OnlyOffice와 Collabora 비교 문서는 호스트를 결정한 후 어떤 엔진을 실행할지 선택하는 데 도움을 줍니다.

다음 중 하나라도 해당하면 Nextcloud를 유지하십시오

• 여러 사람이 하나의 캘린더와 주소록을 파일과 동일한 계정으로 공유하는 경우.
• 브라우저에서 다른 사람과 동시에 같은 오피스 문서를 편집하는 경우.
• 파일별 공유 링크에 만료일과 비밀번호를 설정해야 하고, 그룹 권한이 필요한 경우.
• 사용자가 기술적이지 않으며, 실제로 모바일 앱을 주로 사용하는 경우.

이러한 작업들을 모두 수행할 수 있는 더 가벼운 대안은 없으며, 솔직한 해결책은 떠나는 것보다 설치 상태를 개선하는 것입니다. 속도가 느린 대부분의 인스턴스는 메모리 캐시가 설정되지 않은 기본 PHP-FPM 풀로 실행 중이며, Nextcloud의 관리자 개요 페이지는 캐시 누락에 대해 경고합니다. 파일 캐시 테이블이 비대해지기 때문에, 추적되는 파일 수를 줄이는 것이 다른 어떤 단일 변경보다 효과적입니다. Docker, TLS 및 백업을 사용하는 VPS에 Nextcloud 설치는 이러한 문제 대부분을 방지하는 방식으로 구성합니다.

옵션별 실제 마이그레이션 비용

• Syncthing: 가져오기 과정이 없습니다. 양쪽 서버의 기존 디렉터리 트리를 지정하면 동기화가 진행됩니다.
• SFTP 또는 WebDAV: 파일 이동이 없으므로 가져오기 과정이 전혀 필요하지 않습니다.
• Object storage: 전체 네트워크 복사 1회가 필요합니다. 중단 시 재개와 스크립트 작성이 가능하지만, 빈 폴더는 복사되지 않습니다.
• Seafile: 라이브러리로 전체 업로드 1회가 필요합니다. 서버가 파일이 아닌 블록 단위로 데이터를 저장하기 때문입니다.

어떤 방식을 선택하든 먼저 Nextcloud에서 깨끗한 복사본을 확보해야 합니다. 사용자 파일은 데이터 디렉터리 하위에 사용자별 폴더로 평문 형태 저장되므로, 해당 트리의 rsync이 원본 소스가 됩니다. 복사 전 인스턴스를 유지보수 모드로 전환하십시오. 그렇지 않으면 파일 쓰기 도중 복사가 진행될 수 있습니다.

sudo -u www-data php occ maintenance:mode --on
sudo rsync -a --info=progress2 /path/to/nextcloud/data/ /srv/files/
find /srv/files -type f | wc -l

해당 개수를 원본의 동일한 find와 비교하십시오. 개수가 부족하다면 권한 문제로 rsync이 특정 파일을 읽지 못했을 가능성이 큽니다. 이 경우 작업 도중 해당 오류가 출력됩니다.

복사 과정에는 두 가지 함정이 있습니다. Nextcloud의 외부 저장소 기능을 통해 연결된 파일은 데이터 디렉터리에 존재하지 않습니다. 해당 파일들은 Nextcloud가 참조하도록 설정된 원격 시스템에 있기 때문입니다. 또한 서버 측 암호화(server-side encryption)를 활성화한 적이 있다면 디스크의 파일은 암호문 상태입니다. 따라서 복사 전 occ encryption:decrypt-all를 실행해야 합니다. 그렇지 않으면 읽을 수 없는 데이터 폴더만 옮기게 됩니다. 작업을 취소하기 전에 두 가지 사항을 모두 확인하십시오.

FAQ

기존 폴더 구조를 유지하는 Nextcloud 대안이 있습니까?

Syncthing, 그리고 일반적인 SFTP나 WebDAV 설정이 있습니다. Syncthing은 지정한 디렉터리를 인덱싱하여 모든 기기에서 동일한 이름과 레이아웃을 유지하므로, 별도의 가져오기 단계나 업로드가 필요하지 않습니다. Seafile과 오브젝트 스토리지는 데이터를 일반적인 파일 트리 형태로 저장하지 않기 때문에 전체 업로드 과정을 한 번 거쳐야 합니다. Seafile은 파일을 데이터 디렉터리 하위의 블록 단위로 분할하며, 오브젝트 스토리지는 디렉터리 대신 키(key) 방식을 사용합니다.

2 GB RAM을 가진 VPS에서 Seafile을 실행할 수 있습니까?

2026년 8월 기준, Seafile 공식 문서에서는 최소 2 GB RAM과 2 GHz 이상의 2코어 CPU를 요구합니다. 이는 여유 공간이 없는 하한선으로 보아야 합니다. Docker 배포판은 MariaDB, Caddy, SeaDoc 에디터를 각각 별도의 컨테이너로 실행하기 때문입니다. 단일 사용자라면 운영 가능하지만, 가정이나 소규모 팀이라면 4 GB로 업그레이드하거나, 스택에서 SeaDoc 컨테이너를 제외하여 브라우저 내 문서 편집 기능을 포기해야 합니다.

다운로드 속도는 빠른데 왜 Nextcloud 웹 인터페이스는 느립니까?

두 경로가 수행하는 작업이 다르기 때문입니다. 다운로드는 디스크에서 바이트를 스트리밍하지만, 페이지 로드는 PHP를 실행하고 파일 캐시 테이블을 쿼리하며 종종 사용 가능한 PHP-FPM 워커를 기다려야 합니다. 저장소 탓을 하기 전에 oc_filecache의 행 수를 세어보고 PHP-FPM 풀의 pm.max_children을 확인하십시오. 수백만 개의 행이 있는 테이블과 5개의 워커 풀 조합은 정확히 이러한 현상을 유발합니다.

캘린더는 Nextcloud를 유지하고 파일만 옮길 수 있습니까?

네, 이는 종종 가장 저렴한 해결책이 됩니다. 대용량 폴더는 Syncthing이나 Seafile로 동기화하고, CalDAV, CardDAV 및 브라우저 내 문서 편집을 위해 Nextcloud를 계속 실행하십시오. Nextcloud의 데이터베이스는 추적하는 파일 수에 비례하여 커지므로, 데이터베이스에서 대용량 트리를 제거하면 인터페이스 속도가 다시 빨라집니다. 파일을 삭제할 때는 디스크의 데이터 디렉터리에서 직접 삭제하지 말고 웹 인터페이스나 occ을 통해 삭제하십시오. 그렇지 않으면 데이터베이스에 존재하지 않는 파일을 가리키는 행이 계속 남게 됩니다.