Nextcloud가 느리게 느껴지는 이유
(ounapuu.ee)- 개인 서버에서 Nextcloud를 최적화해도 반응이 느린 원인은 과도한 자바스크립트 로딩 구조
 - 초기 페이지 로드 시 15~20MB의 자바스크립트가 다운로드되며, 압축 후에도 4~5MB 수준으로 여전히 과중
 - 
core-common.js(4.71MB),NotificationsApp.chunk.mjs(1.06MB), Calendar 앱 5.94MB, Files 앱 18.8MB, Notes 앱 20.91MB 등 각 앱별 스크립트 용량이 매우 큼 - 이러한 구조로 인해 iPhone 13 mini에서도 Tasks 앱 실행에 5~10초 지연 발생
 - 일부 기능은 Vikunja(1.5MB JS) , Immich 등으로 대체했지만, Nextcloud의 통합 기능성 때문에 완전한 대체는 어려운 상황
 
Nextcloud의 성능 저하 원인
- Nextcloud는 파일, 캘린더, 연락처, 노트, 할 일, 사진 등 다양한 기능을 통합 제공하지만, 사용 체감 속도가 느림
- 하드웨어 성능이 충분한 환경에서도 반응이 느리게 나타남
 
 - 개발자 도구 분석 결과, 지연의 주된 원인은 자바스크립트의 과도한 양
- 초기 페이지 로드 시 15~20MB의 자바스크립트가 다운로드됨
 - 압축 전송 후에도 4~5MB 수준으로, 일반 웹앱 기준(1MB)보다 매우 큼
 
 - 브라우저 캐시가 존재하더라도, 매 방문 시 대량의 코드 실행이 필요해 로딩 지연 발생
 
주요 자바스크립트 번들 크기
- 
core-common.js: 4.71MB로, 여러 앱에서 공통 기능 제공 - 
NotificationsApp.chunk.mjs: 1.06MB - 
Calendar 앱: 기본 달력 보기만으로 5.94MB 필요
- 느린 네트워크 환경에서는 30초 이상 로딩 지연 발생
 
 - 
Files 앱: 
EditorOutline(1.77MB),previewUtils(1.17MB),index(1.09MB),emoji-picker(0.9MB) 등 다수의 스크립트 포함- 전체 18.8MB로, 실제 환경에서 1분 이상 로딩 대기 발생
 
 - 
Notes 앱: 
notes-main.js만 4.36MB이며, 전체 20.91MB 수준 
사용자 경험에 미치는 영향
- 
Tasks 앱 실행 시에도 5~10초 지연 발생
- 예: 매장에서 쇼핑 목록을 열 때 즉시 표시되지 않음
 
 - 기능 대비 번들 크기 비율이 비정상적으로 높아, 기능성과 성능의 불균형 발생
 - Nextcloud의 구조상 공통 라이브러리와 도구가 많아, 통합 경험 제공의 대가로 성능 저하 발생
 
대안 서비스 활용
- 일부 기능은 Vikunja(할 일 관리, 1.5MB JS)와 Immich(사진 관리)로 분리 운영
- Vikunja는 완벽하지 않지만, JS 용량이 작아 체감 속도 우수
 
 - 그러나 Nextcloud의 통합성과 편의성 덕분에 완전한 대체는 어려움
 
결론 및 인식 변화
- Nextcloud의 현재 구조에는 정당한 이유나 인력 부족 등의 현실적 제약이 있을 수 있음
 - 그럼에도 불구하고, 사용자 경험과 접근성 저하는 명확한 문제로 지적됨
 - 웹 성능 전문가 Alex Russell의 글을 통해 웹 성능의 중요성과 개발팀의 성능·접근성 관리 부주의 문제를 인식하게 되었음
 - 웹앱 개발 시 퍼포먼스 불평등(performance inequality) 문제를 고려해야 함
 
그냥 느려요. 클라이언트만 느린 게 아니라 서버도 느려요.
8745HS 머신에서 pdf 몇백 개 썸네일 만드는 데 몇 시간이 걸려도 끝나질 않아요.
다른 파일 서버 아무거나 굴리는 게 낫습니다. 클라이언트가 윈도우면 smb, 나머지는 rclone이나 dufs로 WebDAV 서버 쓰는 것이 낫더라구요.
Hacker News 의견
- 
나는 Nextcloud를 좋아하고 싶음. 존재 자체가 대단하다고 생각함
하지만 겉보기엔 잘 작동하다가도 가끔 완전히 망가져버리는 식으로 복구 불가능한 오류가 생김
iOS/Android 앱으로 가족 사진을 자동 백업하려 했는데, iOS 앱은 가끔 “locked webdav” 오류가 나거나 동기화가 멈춰버림
결국 80GB 사진을 처음부터 다시 업로드해야 하는 상황이 생김
가족이 쓰기엔 너무 불안정해서, 신뢰성 있는 대안이 필요함. 사실상 iCloud 말고는 대안이 없음- iOS 앱이 백그라운드에서 계정 연결이 끊기면서 데이터를 유실한 적이 있음
Files 앱 통합 기능으로 붙여넣기 했는데, 동기화가 안 되고 아무 경고도 없이 데이터가 사라졌음 - 최근에 사람들이 만든 초경량 대안 copyparty가 있음
copyparty GitHub — 필요한 기능만 있고 불필요한 덩치가 없음 - 사진 백업 용도라면 Immich가 훨씬 나은 경험을 줌
하지만 Dropbox 대체용으로는 여전히 마땅한 게 없음 - 사진 관련해서는 Immich가 최고라고 생각함
 - 모바일 업로드는 FolderSync로 바꿨는데 완벽하게 작동함
공식 앱은 버그가 많지만 서버 쪽은 안정적임 
 - iOS 앱이 백그라운드에서 계정 연결이 끊기면서 데이터를 유실한 적이 있음
 - 
Nextcloud는 자바스크립트 호출이 너무 많아서 느림
캘린더 페이지 새로고침 시 124개의 네트워크 호출이 발생하고, 그중 31개는 캐시되지 않음
각 캘린더마다 30ms 이상 걸려서 캘린더 수가 많을수록 지연이 누적됨
로컬 네트워크에서도 1초, 4G 환경에서는 33초 이상 걸림. 설계 자체가 비효율적임- JS 파일이 너무 많고, AJAX 요청이 너무 많음
이런 REST 기반 구조는 모바일 네트워크에서 왕복 지연이 커서 느릴 수밖에 없음
이제는 REST 대신 WebSocket을 써야 할 때라고 생각함 - 예전엔 Nextcloud 캘린더가 정말 훌륭했는데, 리디자인 이후 완전히 망가짐
일정 추가나 수정이 불편하고 UI도 유치해짐. 쓸만한 오픈소스 웹 캘린더가 없음 - 이런 문제를 해결하려면 데이터 동기화 프로토콜이 개선되어야 함
Electric SQL 같은 접근이 흥미로움
또 TC39 import proposal 같은 JS 개선안도 도움이 될 수 있음 
 - JS 파일이 너무 많고, AJAX 요청이 너무 많음
 - 
예전에 Nextcloud의 소프트 포크를 유지보수했는데, 기본 구조가 너무 복잡함
성능 개선 패치를 몇 개만 적용해도 파일 매니저 렌더링 속도가 몇 배 빨라졌음
하지만 코드베이스는 레이어 위에 레이어를 덧씌운 구조라 신뢰하기 어려움
결국 프로젝트를 포기했음. 이런 복잡성이 호스팅 업체 생태계를 유지시키는 요인 같음- 나도 같은 생각임. Nextcloud는 모듈화의 함정에 빠져 있음
각 기능이 독립 플러그인으로 시작해서 통합성이 없음
이제는 하나의 괴물이 되었고, 차라리 여러 도구를 SSO로 연결하는 게 낫다고 봄 - 그 패치들을 공유했는지 궁금함. 속도 향상이 크다면 커뮤니티에 도움이 될 것 같음
그리고 실제로는 Nextcloud 운영이 그렇게 어렵지 않음. 한 번 세팅하면 유지보수는 간단함 
 - 나도 같은 생각임. Nextcloud는 모듈화의 함정에 빠져 있음
 - 
기사에서 말하는 JS 용량보다는 비효율적인 로직이 느림의 원인이라고 생각함
너무 많은 API 호출과 UI 업데이트가 문제임- JS가 너무 많으면 파싱, 실행, DOM 조작 등에서 누적된 오버헤드가 큼
예전에 200KB만 넘어도 최적화 점검을 했는데, Nextcloud는 15MB나 됨 - 캐싱이 제대로 안 되거나, 불필요한 사전 로딩이 원인일 수도 있음
 
 - JS가 너무 많으면 파싱, 실행, DOM 조작 등에서 누적된 오버헤드가 큼
 - 
나는 Nextcloud를 7년째 가족 사진 백업용으로 사용 중임
사생활 보호가 잘 되고 안정적이지만, Google Docs 대체로는 절대 추천 못함
대용량 업로드나 썸네일 로딩이 불안정하고 느림
그래도 대체제가 없고, 데이터를 대기업 AI에 맡기고 싶지 않음
가족이 더 적극적으로 써줬으면 좋겠음- Immich가 그 대안이 될 수 있는지 궁금함. 사진·영상 관리에 강하다고 들음
 
 - 
여러 셀프호스팅 파일 매니저를 써봤음
Ajaxplorer → Pydio → Nextcloud → FileRun 순으로 써봤는데, FileRun이 가장 만족스러웠음
빠르고 안정적이며 모바일 브라우저에서도 잘 작동함
지금은 유료지만 그만한 가치가 있음
copyparty도 가볍고 빠르지만, 일반 사용자 친화적이지 않음
FileRun의 “파일 요청” 기능이 그립음- 나는 filebrowser를 좋아함. Syncthing과 함께 쓰면 미니 Dropbox처럼 됨
filebrowser GitHub
filebrowser-docker - copyparty에서도 “shares(--shr)” 기능으로 비슷한 업로드 링크를 만들 수 있음
데모 링크 - copyparty는 단방향 동기화만 지원해서 Nextcloud 대체는 어려움
Syncthing과 조합해보려 하지만 CPU 부하가 걱정됨 
 - 나는 filebrowser를 좋아함. Syncthing과 함께 쓰면 미니 Dropbox처럼 됨
 - 
Nextcloud는 느리고 비대하지만 안정적임
8명 규모의 회사에서 수년간 문제 없이 사용 중임
웹앱은 느려서 거의 안 쓰고, 데스크톱 동기화 클라이언트를 주로 씀
IMAP 인증 플러그인이 매우 유용해서 사용자 관리가 쉬움- 웹앱이 느리다고 하지만, 웹앱의 장점도 많음
uBlock, userstyle, userscript 등으로 자유롭게 커스터마이징할 수 있음 
 - 웹앱이 느리다고 하지만, 웹앱의 장점도 많음
 - 
예전에 Nextcloud의 PDF 뷰어 취약점을 발견해 제보했음
구버전 JS 기반 PDF 뷰어를 포함한 게 문제였고, 16살 때 $100을 받았음
내 블로그 글- 나도 앱 내에서 PDF를 div 안에 표시하려 했는데, 결국 pdf.js를 써야 했음
 
 - 
오픈소스 프로젝트에 불만이 많지만, 직접 개선하려는 사람은 적음
나는 Nextcloud를 사랑함. 느리긴 해도 내 데이터를 내가 소유하고, AGPL 코드라 수정도 가능함
무료로 쓸 수 있고, 확장 기능을 “쇼핑하듯” 추가할 수 있음
6년 넘게 큰 문제 없이 사용 중이며, 이런 자유가 정말 멋짐
완벽하진 않지만, 존재해줘서 고마운 프로젝트임 - 
Nextcloud의 장점은 하나의 플랫폼으로 협업 도구 전체를 다룰 수 있음
파일, 캘린더, 노트, 오피스, 사진, Talk 등 통합된 경험을 제공함
AIO 패키지는 업데이트와 안정성 문제를 많이 해결했음
다만 PHP 기반이라 성능이 떨어지고, UI는 Synology DSM처럼 다듬어졌으면 좋겠음- 언어를 바꾼다고 속도가 크게 개선되진 않음
문제는 비효율적인 I/O 구조와 수많은 XHR 호출임
PHP는 접근성이 높아서 커뮤니티 기여에 유리함 - 참고로 Owncloud Infinite Scale은 Go로 다시 작성된 버전임
공식 문서 — 다만 Docker 의존성이 많고 환경 제약이 큼 
 - 언어를 바꾼다고 속도가 크게 개선되진 않음