Collabora Online과 ONLYOFFICE 비교: RAM 및 편집 지연 시간 측정

Collabora Online의 CODE 26.04 릴리스(2026년 6월 8일 발표)에는 문서 상호 운용성 및 사용성 개선 사항이 포함되어 있지만, 릴리스 노트에는 ONLYOFFICE Docs와의 RAM 또는 지연 시간 비교 결과가 명시되어 있지 않습니다. 유용한 결정을 내리려면 배포하려는 빌드를 동일한 호스트, 동일한 문서, 브라우저, 스토리지 플랫폼 및 사용자 작업 환경에서 벤치마킹하는 것이 좋습니다. 공급업체의 최소 요구 사항은 계획 지침일 뿐이며, 비교 가능한 성능 결과가 아닙니다.

이 참조 절차는 서버 리소스 사용량과 사용자가 문서를 열고 편집하는 데 걸리는 시간이라는 두 가지를 측정합니다. 특정 소프트웨어 제품군이 보편적으로 더 빠르다고 주장하는 것은 아닙니다. 파일 복잡성, 통합, 네트워크 경로, 글꼴 및 동시 세션은 결과에 영향을 미칠 수 있습니다.

공개된 요구사항이 알려줄 수 있는 것과 알려줄 수 없는 것은 무엇일까요?

ONLYOFFICE의 현재 Docker 요구 사항에는 최소 4GB의 RAM과 4GB의 스왑 공간이 명시되어 있으며, 문서에 따르면 실제 요구 사항은 동시 접속 사용자 수, 문서 유형 및 크기에 따라 달라집니다. Docker 문제 해결 가이드에서는 수십 명의 활성 사용자가 있는 경우 2~4GB의 메모리 사용량이 정상적일 수 있다고 언급합니다. 이는 ONLYOFFICE에 특화된 사양 관련 내용이며, Collabora와의 직접적인 비교는 아닙니다.

Collabora는 하드웨어 요구 사항이 동시 사용자 수에 따라 달라진다고 명시하고 있으며, FAQ에서도 동시 사용자 수가 증가함에 따라 성능이 저하되고 서버 리소스에 따라 성능이 달라질 수 있다고 경고합니다. CODE와 지원되는 Collabora Online 제품은 서로 다른 배포 옵션입니다. 소규모 홈 환경에서의 CODE 테스트 결과가 실제 운영 환경의 구독 배포를 예측하는 것은 아니며, ONLYOFFICE Community Edition 테스트 결과가 다른 에디션이나 아키텍처를 자동으로 대표하는 것도 아닙니다. 각 실행 시 에디션, 릴리스, 배포 방법 및 통합 정보를 기록해 두십시오.

2026년 10월 현재, CODE 26.04는 Collabora의 최신 릴리스입니다. 릴리스 노트에는 문서 상호 운용성을 포함한 개선 사항이 설명되어 있지만, 사용자당 RAM 사용량이나 편집 지연 시간을 ONLYOFFICE와 비교한 수치는 나와 있지 않습니다. 따라서 최신 고정 빌드를 테스트해야 하는 이유로만 받아들이시고, 속도 우위의 증거로 간주하지 마십시오.

공정하고 반복 가능한 테스트를 설계하세요.

1. 동일한 호스트와 통합 경로를 사용하십시오. 각 스위트에 동일한 CPU 및 메모리 제한, 스토리지 위치, 리버스 프록시, TLS 설정 및 네트워크 경로를 지정하십시오. 두 컨테이너를 동시에 실행하면 동일한 리소스를 두고 경쟁하게 되므로, 한 스위트를 중지하고 성능을 측정한 다음 다른 스위트로 교체하십시오. 호스트는 다른 작업을 하지 않도록 유휴 상태로 유지하십시오.
2. 소프트웨어 버전을 고정하세요. 정확한 이미지 태그 또는 릴리스, 에디션, Docker 버전, 호스트 운영 체제, 브라우저 버전 및 연결된 플랫폼을 기록하십시오. latest비교 과정 중에는 소프트웨어 버전이 변경될 수 있으므로 고정된 태그를 사용하지 마세요.
3. 대표 파일들을 준비하세요. 간단한 텍스트 문서, 수식과 차트가 포함된 스프레드시트, 그리고 사용자들이 일반적으로 열어보는 가장 크거나 복잡한 파일을 포함시키세요. 실제 사용 중인 원본이 아닌, 테스트용 사본을 사용하세요. 이러한 파일들은 평소 업무에 사용하는 동일한 문서 플랫폼에 저장하세요.
4. 클라이언트 환경을 일정하게 유지하십시오. 동일한 컴퓨터, 브라우저, 네트워크 연결, 화면 크기 및 브라우저 확장 프로그램을 사용하십시오. 관련 없는 탭은 닫으십시오. 각 테스트에서 콜드 오픈 측정을 시작하기 전에 문서가 완전히 닫혀 있는지 확인하고, 웜 오픈 테스트는 별도로 실행하십시오.
5. 테스트 전에 타이밍을 정의하세요. 문서를 여는 순간부터 문서가 완전히 렌더링되어 편집 가능 상태가 될 때까지의 시간을 측정합니다. 편집 지연 시간의 경우, 짧은 문구를 입력하고 다른 공동 작업자가 해당 문구를 볼 수 있을 때까지 기다리는 것과 같은 특정 동작에 소요되는 시간을 측정하세요. 한 번의 결과에만 의존하지 말고 각 실행 결과를 기록해 두세요.

서버 사용량과 사용자가 인지하는 지연 시간을 측정합니다.

메모리 및 CPU

서비스가 안정화된 후 유휴 상태의 기준선을 캡처합니다. 그런 다음 파일 하나를 열고 편집한 후 열어둔 상태로 컨테이너의 메모리 사용량과 CPU 사용량을 기록합니다. 예상되는 작업 부하 수준에 맞춰 여러 개의 동시 문서와 사용자를 사용하여 이 과정을 반복합니다. Docker의 경우 docker stats --no-stream특정 시점의 리소스 스냅샷을 표시합니다. 각 단계에서 이 스냅샷을 반복적으로 사용하거나 기존 모니터링 시스템을 사용하여 시계열 데이터를 수집합니다. 컨테이너의 메모리 사용량만으로는 전체 시스템의 부하 상태를 파악할 수 없으므로 호스트 수준의 가용 메모리도 기록해야 합니다.

활성 단계 동안의 최대 메모리 사용량, 평균 메모리 사용량, 문서 닫힘 후 유휴 메모리 사용량을 보고하십시오. 샘플링 간격은 동일하게 유지하십시오. 문서 하나 닫힘 후의 메모리 사용량을 팀 용량과 동일시하지 마십시오. 세션 수, 파일 크기, 렌더링 복잡성, 동시 편집 등 모든 요소가 중요합니다. 배포 환경에서 Prometheus 메트릭을 지원하는 경우, 해당 메트릭을 지속적으로 수집하십시오. Collabora는 Prometheus 호환 메트릭 및 실시간 세션 모니터링에 대한 문서를 제공합니다. ONLYOFFICE의 경우, 해당 제품의 컨테이너 진단 및 리소스 지침을 활용하십시오. 한 제품의 내부 프로세스 메트릭을 다른 제품의 전체 컨테이너 총량과 비교하지 마십시오.

지연 시간을 열고 편집하세요.

각 대표 파일에 대해 최소 5회의 콜드 오픈과 5회의 웜 오픈을 실행하십시오. 최상의 결과뿐만 아니라 관찰된 시간 중 중앙값과 가장 느린 시간을 보고하십시오. 콜드 오픈에는 문서 로딩 및 초기 화면 렌더링과 같은 작업이 포함되며, 웜 오픈은 캐시 사용 여부에 따라 성능이 향상될 수 있습니다. 두 편집기에서 "준비됨"의 정의를 동일하게 사용하십시오.

협업 지연 시간을 측정하려면 두 개의 브라우저 세션을 연결하고 한 세션에서 특정 편집이 이루어진 시점부터 다른 세션에서 업데이트가 반영되는 시점까지의 시간을 측정합니다. 다른 문서가 열려 있지 않은 상태와 의도한 동시 부하 상태에서 동일한 작업을 여러 번 반복합니다. 이렇게 하면 편집기, 서버, 스토리지 통합 및 네트워크의 복합적인 영향을 파악할 수 있습니다. 브라우저와 서버가 서로 다른 네트워크에 있는 경우 왕복 시간도 기록해야 합니다. 네트워크 지연이 편집기 자체 처리 속도에 큰 영향을 미칠 수 있기 때문입니다.

결과를 과장하지 말고 읽어보세요.

목표 지연 시간을 충족하면서 실제 동시 접속 환경에서 충분한 메모리와 CPU 여유 공간을 확보할 수 있는 제품군을 선택하십시오. 결과가 비슷할 경우 문서 호환성, 통합 지원, 운영 편의성 및 라이선스를 우선적으로 고려하십시오. 주요 업그레이드 또는 인프라 변경 후 동일한 테스트를 다시 실행하십시오. 버전별 자세한 내용은 Collabora의 CODE 26.04 릴리스 노트 , Collabora 온라인 FAQ 및 보안 및 모니터링 개요 , 그리고 ONLYOFFICE 커뮤니티 에디션 Docker 요구 사항 및 Docker 문제 해결 및 리소스 가이드를 참조하십시오 . 이러한 자료는 각 제품에 대한 개별적인 설명이며, 통제된 직접 비교 벤치마크가 아닙니다.