Collabora Online과 ONLYOFFICE 비교: 리소스 사용량 및 지연 시간 테스트

Collabora Online과 ONLYOFFICE Docs 중 하나를 선택하는 것은 종종 기능이나 파일 형식에 대한 문제로 여겨지지만, 인프라 팀은 배포 후 또 다른 중요한 결정을 내려야 합니다. 바로 각 제품이 얼마나 많은 CPU와 메모리를 소비하는지, 그리고 왕복 시간과 동시 접속 문서 수가 증가함에 따라 편집 응답성이 얼마나 유지되는지입니다. 문서 복잡성, 글꼴, 변환 작업, 스토리지 지연 시간, 브라우저 동작, 리버스 프록시, 동시에 열려 있는 문서 수 등 모든 요소가 결과에 영향을 미치기 때문에 어느 제품에 대해서도 신뢰할 수 있는 보편적인 수치를 제시하기는 어렵습니다.

2026년 10월 현재, 어느 벤더도 상대방과의 정확한 비교를 위한 최신 벤치마크 자료를 공개하지 않았습니다. 이는 중요한 문제입니다. 따라서 공정한 비교를 위해서는 두 가지 유형의 증거를 구분해야 합니다. 첫째는 각 프로젝트에서 요구하는 프로비저닝 사양을 알려주는 벤더의 사이징 가이드라인이고, 둘째는 동일한 하드웨어에서 실행하는 반복 가능한 지연 시간/리소스 테스트입니다. 아래 테스트 계획은 실험실 결과가 모든 곳에 적용될 수 있는 것이 아니라, 실제 배포 환경에 적용할 수 있는 수치를 도출하도록 설계되었습니다.

공식 자원 지침에 실제로 나와 있는 내용은 다음과 같습니다.

벤더들은 유용한 크기 조정 정보를 제공하지만, 그 수치들이 직접적으로 동일한 의미를 갖는 것은 아닙니다. Collabora SDK 설명서에는 Kubernetes/Helm 프로덕션 예제가 포함되어 있는데, 이 예제에서는 4개의 CPU와 6GiB의 메모리를 요청하고 최대 8개의 CPU와 8GiB까지 제한적으로 사용하도록 권장합니다. 또한 같은 설명서에는 num_prespawn_children자식 프로세스를 항상 준비 상태로 유지하여 추가 메모리를 사용하는 대신 새 세션이 더 빠르게 시작될 수 있도록 하는 기능에 대한 설명도 있습니다. 자세한 내용은 Collabora Online SDK 설명서를 참조하십시오 . Collabora의 현재 구성 템플릿은 메모리 비율 제한 및 문서별 동시 실행 제어 기능도 제공합니다. 프로젝트의 공식 소스 코드는 Collabora Online 구성 템플릿 에서 확인할 수 있습니다 .

ONLYOFFICE는 Docker 환경의 Docs Community Edition에 대한 보다 구체적인 권장 사양을 발표했습니다. 현재 지침에 따르면 4GB 이상의 RAM이 필요하며, 동시 접속 사용자 수가 100명 미만인 경우 2.8GHz 코어 1개, 100~200명인 경우 코어 2개, 200~400명인 경우 코어 4개를 권장 구성으로 제시하고 있습니다. 모든 권장 구성에서 4GB RAM은 유지됩니다. ONLYOFFICE는 실제 용량은 문서의 수, 유형 및 크기에 따라 달라질 수 있다고 명시적으로 경고합니다. 자세한 내용은 ONLYOFFICE Docs Community Edition Docker 요구 사항을 참조하십시오 .

유휴 메모리 스크린샷이 벤치마크가 될 수 없는 이유

흔히 사용하는 비교 방법은 두 컨테이너를 모두 시작하고 문서를 열지 않은 상태에서 RAM 사용량이 더 낮은 쪽을 승자로 선정하는 것입니다. 하지만 이는 기준선 사용량만 측정하는 방식입니다. 파일 열기, 필요한 경우 변환, 페이지 또는 시트 렌더링, 변경 사항 전송, 스프레드시트 재계산, 여러 편집기 지원, 결과 저장 등 실제 작업 과정은 고려하지 않습니다.

Collabora의 프로세스 모델은 하위 프로세스를 미리 준비된 상태로 유지할 수 있습니다. 이는 유휴 시간을 늘리는 동시에 문서를 사용할 수 있게 되기까지의 지연 시간을 줄일 수 있습니다. ONLYOFFICE는 문서 편집 기능을 변환과 같은 서비스와 분리합니다. 해당 아키텍처 문서에는 문서 편집기, 편집 서비스, 명령 서비스, 변환 서비스 및 빌더 서비스가 설명되어 있습니다. ONLYOFFICE Docs 작동 방식을 참조하십시오 . 즉, 기준 RSS는 유용한 운영 지표이지만 사용자가 체감할 수 있는 속도를 예측하기에는 충분하지 않습니다.

공정한 리소스 및 지연 시간 테스트 설정

동일한 호스트 또는 동일하게 프로비저닝된 두 개의 가상 머신에서 두 제품을 한 번에 하나씩 실행하십시오. 캐시된 파일이 있는 워밍업된 호스트에서 하나를 테스트하고 부팅 직후 다른 하나를 테스트하는 것은 피하십시오. Linux 배포판, Docker 버전, CPU 할당량, 메모리 제한, 스토리지 클래스, 리버스 프록시, TLS 종료, 브라우저 버전 및 문서 저장 경로를 동일하게 유지하십시오.

세 가지 문서 작업량을 사용하세요

• 텍스트 문서: 제목, 표, 이미지, 변경 내용 추적 및 주석이 포함된 대표 DOCX 파일입니다.
• 스프레드시트: 수식, 조건부 서식, 여러 워크시트, 그리고 의미 있는 재계산을 트리거할 만큼 충분한 데이터가 포함된 XLSX 파일입니다.
• 프레젠테이션: 거의 비어있는 슬라이드 덱이 아닌 이미지, 차트 및 여러 슬라이드가 포함된 PPTX 파일입니다.

두 플랫폼 모두에 동일한 파일을 사용하십시오. 한 제품에서 파일 형식 변환이 필요한 경우, 변환 시간이 전체 실행 시간의 대부분을 차지할 수 있으므로 해당 사실을 기록해 두십시오. 특정 편집기에 맞춰 파일을 최적화한 다음, 그 결과를 일반적인 플랫폼 비교 기준으로 삼지 마십시오.

여러 동시 실행 수준에서 테스트합니다.

실제 실행 순서는 동시에 열려 있는 편집기 탭 수를 1개, 5개, 10개, 20개로 늘린 다음, 예상되는 최대값에 해당하는 더 높은 레벨로 늘리는 것입니다. 모든 실행에서 "사용자"는 문서가 완전히 열려 있는 편집기 탭을 의미합니다. 워밍업 실행 후 각 레벨을 최소 3회 반복하고 중앙값과 가장 느린 결과를 함께 보고하십시오. 이렇게 하면 짧은 배경 잡음이 결론을 왜곡할 가능성을 줄일 수 있습니다.

리소스 지표를 기록합니다.

Docker는 벤더에 구애받지 않는 1차 원격 측정 계층을 제공합니다. Docker 통계 공식 문서 에 따르면 이 docker stats계층은 CPU 사용률, 메모리 사용량, 네트워크 I/O, 블록 I/O 및 PID를 보고합니다. 워크로드 실행 중 실시간 스트림과 정의된 체크포인트에서 스트림이 없는 샘플을 모두 캡처할 수 있습니다.

docker stats collabora --no-stream
docker stats onlyoffice --no-stream

각 동시 접속 수준에 대해, 문서를 열기 전 유휴 메모리, 모든 문서가 열린 후의 안정 상태 메모리, 문서 열기 중 최대 CPU 사용량, 세션이 안정화된 후의 CPU 사용량, 그리고 각 세션이 종료된 후의 메모리 사용량을 기록하십시오. 또한 일정 시간 후 메모리 사용량이 기준선에 근접하는지 여부도 확인하십시오. 테스트 후 값이 높다고 해서 반드시 메모리 누수가 있는 것은 아닙니다. 캐시와 공유 메모리가 여전히 유용할 수 있기 때문입니다. 하지만 동일한 주기를 반복하면서 메모리 사용량이 지속적으로 상승하는 경우, 조사가 필요합니다.

컨테이너마다 CPU 또는 메모리 제한이 다른 경우, 컨테이너별 백분율만 비교하지 마십시오. 벤치마크 결과와 함께 실제 호스트 또는 cgroup 제한을 기록하십시오. Docker의 Linux 메모리 수치는 캐시 계산 방식에 따라 달라질 수 있으므로 두 제품 모두 동일한 Docker 및 cgroup 환경을 사용해야 합니다.

오픈 지연 시간을 측정하는 방법

테스트 전에 개방 지연 시간을 정의하십시오. 적절한 정의는 사용자가 편집기를 여는 순간부터 편집기가 입력 준비 상태로 표시되고 문서 내용이 안정화되어 입력을 시작할 수 있을 때까지의 시간입니다. 두 제품 모두 동일한 지표를 사용하여 측정하십시오. 제품별 내부 이벤트에 의존하는 것보다 타임스탬프가 포함된 간단한 화면 녹화가 더 비교하기 쉬운 방법입니다.

두 가지 형태의 오픈 지연 시간을 수집합니다. 콜드 오픈은 오피스 컨테이너를 재시작하고 테스트 세션을 초기화한 후 시작됩니다. 웜 오픈은 서비스를 재시작하지 않고 동일한 파일을 다시 로드하는 것입니다. Collabora의 사전 생성 설정으로 인해 이러한 구분이 특히 중요해지는데, 대기 중인 자식 프로세스가 많을수록 시작 지연 시간은 줄어들지만 메모리 사용량은 증가할 수 있기 때문입니다. 값을 조정하는 경우 num_prespawn_children, 결과를 숨기지 말고 해당 값을 결과와 함께 표시하십시오.

협업 지연 시간을 측정하는 방법

실시간 공동 편집에서 의미 있는 측정 기준은 일반적인 ICMP 핑이 아닙니다. 브라우저 A에서 편집한 내용과 브라우저 B에서 변경 사항이 표시되는 데 걸리는 시간 지연을 측정하십시오. 두 개의 서로 다른 브라우저 프로필 또는 컴퓨터를 사용하고 시계를 동기화합니다. 동일한 단락에 문자를 추가하는 것과 같은 간단한 편집을 20~50회 기록한 다음, 표시되는 전파 지연의 중앙값과 95번째 백분위수를 계산합니다.

ONLYOFFICE의 공식 공동 편집 설명에 따르면 변경 사항은 편집자에서 문서 편집 서비스로 이동한 다음 다른 편집자에게 전달됩니다. ONLYOFFICE 공동 편집 워크플로를 참조하십시오. 또한 ONLYOFFICE 서버 구성 참조 에서 재연결 동작 및 최대 페이로드 크기를 포함한 WebSocket 관련 설정을 확인할 수 있습니다 . Collabora 역시 리버스 프록시를 통한 지속적인 WebSocket 트래픽에 의존하므로 프록시 버퍼링, 시간 초과 동작, TLS 종료 및 네트워크 왕복 시간(RTT)은 배경 세부 정보가 아닌 테스트 환경의 일부로 간주해야 합니다.

제어된 네트워크 지연을 추가합니다.

사용자가 원격으로 작업하는 경우, 약 20ms, 80ms, 150ms와 같은 제어된 왕복 지연 시간(RTT)으로 협업 테스트를 반복하십시오. 두 시스템 모두에 동일한 네트워크 셰이핑을 적용하고, 셰이핑이 적용된 정확한 위치를 기록하십시오. 이렇게 하면 로컬 LAN 벤치마크에서는 드러나지 않을 수 있는 차이점을 확인할 수 있습니다. 예를 들어, 편집자는 1~5ms의 RTT에서 매우 만족스러울 수 있지만, 지사나 해외 팀에서는 반응 속도가 현저히 떨어지는 것을 느낄 수 있습니다.

지연 시간 절약에는 별도의 측정 방법이 필요합니다.

저장 시간은 타이핑 지연 시간과 동일하지 않습니다. ONLYOFFICE는 편집 서비스가 변경 사항을 컴파일하고 편집이 완료되면 저장 서비스로 콜백을 보내는 워크플로를 문서화하고 있습니다. 해당 문서에는 기본 변환 시작 지연 시간이 5초이며 최종 시간은 변환 시간, 파일 복잡성 및 서버 성능에 따라 달라진다고 명시되어 있습니다. 자세한 내용은 ONLYOFFICE 파일 저장 문서를 참조하십시오 . 즉, "저장하는 데 몇 초가 걸렸다"는 현상을 자동으로 대화형 지연으로 해석해서는 안 됩니다.

두 제품 모두 마지막 편집자가 작업을 완료한 시점부터 업데이트된 파일이 백업 저장소에서 확인될 때까지의 시간을 기준으로 저장 완료 시간을 측정하십시오. 저장소는 동일한 네트워크 경로와 디스크 등급을 사용해야 합니다. 그렇지 않으면 Nextcloud, ownCloud, 객체 저장소, 데이터베이스 또는 역방향 프록시의 속도가 느려지는 원인이 오피스 제품군에 있을 수 있습니다.

결과표: 중요한 수치들

결과를 어떻게 해석해야 할까요?

Collabora가 시스템에서 유휴 메모리를 더 많이 사용하지만 콜드 오픈 지연 시간이 더 짧다면, 사용자가 문서를 자주 열고 서버에 여유 RAM이 있는 경우 허용 가능한 절충안일 수 있습니다. ONLYOFFICE에서 기본 사용량은 낮지만 변환 중에 CPU 사용량이 급증하는 경우, 메모리보다 CPU 여유 공간이 더 중요할 수 있습니다. 반대의 패턴도 나타날 수 있습니다. 중요한 것은 각 리소스 사용량 곡선을 사용자가 확인할 수 있는 이벤트와 연결하는 것입니다.

소규모 자체 호스팅 설치의 경우, 유휴 메모리 사용량, 최초 열림 시간, 그리고 한두 개의 대용량 문서로 인한 스와핑 발생 여부에 중점을 두어야 합니다. 수십 명의 활성 편집자가 있는 비즈니스 배포의 경우, 메모리 증가 추세, CPU 포화도, p95 공동 편집 지연 시간, 그리고 부하 후 복구 시간을 우선적으로 고려해야 합니다. 지리적으로 분산된 사용자의 경우, 네트워크 왕복 시간(RTT)과 프록시 구성이 서버 측의 사소한 차이보다 더 중요할 수 있습니다.

따라서 가장 유용한 선택은 실제 문서에서 목표 지연 시간을 충족하면서 CPU 및 RAM 예산 범위 내에서 작동하는 제품입니다. 공급업체에서 제공하는 제품 사양 정보는 시작점에 불과하며 벤치마크 결과가 아닙니다. 동일한 작업 부하를 실행하고, 환경을 제어하며, 테스트 구성 정보를 수치와 함께 공개하고, 단일 유휴 메모리 측정값을 전체 성능에 대한 주장으로 일반화하지 마십시오.