우분투 서버 24.04 최소 버전과 표준 버전: 성능 벤치마크 비교 분석

가상 개인 서버(VPS)의 메모리가 부족한 것 같아 우분투 서버 24.04 LTS를 재설치했는데, 기본 우분투 서버 설치와 최소화된 우분투 서버 설치 중에서 선택해야 했습니다. 패키지 수가 적으면 웹 응답 속도가 빨라지고, 데이터베이스 쿼리 시간이 단축되며, CPU 처리량이 높아질 것이라고 생각하기 쉽지만, 실제로는 미묘한 차이가 있습니다. 초기 패키지 세트가 작으면 디스크 사용량과 백그라운드 활동이 줄어들 수 있지만, 그 자체로 프로세서나 저장 장치의 속도가 빨라지는 것은 아닙니다.

결론적으로, 최소한의 구성으로 시작하고 필요한 도구만 추가하고 싶다면 최소화된 설치를 선택하세요. 더 광범위한 기본 서버 도구 세트를 원한다면 표준 설치를 선택하세요. 부팅 시간, 유휴 메모리, 디스크 사용량 및 실제 애플리케이션 성능은 "더 빠르다"라는 단일 기준으로 비교하기보다는 각각 따로 비교하는 것이 좋습니다.

참고 사항(2026년 10월 9일): 이 문서는 재현 가능한 벤치마킹 방법과 각 측정 지표를 통해 얻을 수 있는 결과를 설명합니다. 두 개의 동일한 Ubuntu 24.04 설치 환경에서 측정한 실제 점수는 제시하지 않습니다. 검증되지 않은 RAM, 디스크, 부팅 시간 또는 처리량 수치는 테스트 결과로 표시되지 않습니다.

표준형 우분투 서버와 최소화형 우분투 서버의 차이점은 무엇인가요?

Ubuntu Server의 Subiquity 설치 프로그램은 ubuntu-server표준(기본값) 설치와 최소화 설치, 두 가지 설치 소스를 제공합니다. Canonical은 이러한 소스 식별자를 문서화하고 있으며, 설치 프로그램 식별자는 변경될 수 있으므로 선택한 ISO 파일에서 ubuntu-server-minimal확인하는 것이 좋습니다. 자세한 내용은 Canonical Subiquity 자동 설치 소스 문서를 참조하십시오 .casper/install-sources.yaml

둘 다 Ubuntu Server 24.04 LTS이며, 서로 다른 CPU 아키텍처 최적화 버전이나 별개의 Linux 배포판이 아닙니다. 주요 차이점은 설치 시 제공되는 소프트웨어입니다. 어떤 패키지가 설치되는지는 설치 미디어 버전, 선택 사항, 업데이트, 드라이버 및 이후에 설치된 애플리케이션에 따라 달라집니다. 특정 이미지 빌드에 대해 게시된 목록이 모든 24.04 포인트 릴리스 설치 프로그램에 변경 없이 적용된다고 가정하지 마십시오.

최소화된 서버 옵션은 별도의 이미지 제품군인 최소 Ubuntu 클라우드 이미지 또는 Ubuntu 데스크톱 최소 설치 옵션과 혼동해서는 안 됩니다 . Ubuntu 24.04 LTS 릴리스 노트에서는 이전 릴리스에 비해 최소 클라우드 이미지 의 패키지 수와 다운로드 크기가 상당히 감소했다고 언급하고 있습니다 . 공개된 클라우드 이미지 예제는 표준 서버 ISO와 최소화된 서버 ISO를 비교하는 통제된 벤치마크가 아니므로, 해당 수치를 마치 그런 것처럼 재사용해서는 안 됩니다.

어떤 성능 기준이 중요한가요?

예상되는 동작은 측정된 결과와 다릅니다. 최소화된 시스템은 설치 직후에는 더 적은 리소스를 소비할 수 있습니다. 하지만 두 시스템이 동일한 데이터베이스, 컨테이너 런타임, 모니터링 에이전트 및 웹 서버를 실행하게 되면 관찰된 차이는 줄어들거나 사라지거나 방향이 바뀔 수 있습니다. 따라서 가장 타당한 결론은 목표 워크로드를 측정함으로써 도출할 수 있습니다.

스톱워치가 아니라 공정한 테스트 환경을 구축하는 것부터 시작하세요.

동일한 Ubuntu Server 24.04 LTS ISO 리비전을 사용하여 표준 버전과 최소화 버전의 가상 머신 두 대를 구축하십시오. 각 가상 머신에 동일한 vCPU 수, RAM, 가상 디스크, 파일 시스템, 부팅 모드, 하이퍼바이저 설정, 네트워크 연결 및 스토리지 클래스를 할당하십시오. 물리적 머신의 경우, 동일한 하드웨어를 사용하고 유사한 발열 및 전력 소비 조건에서 테스트하십시오. 이러한 가상 머신은 운영 환경에서 트래픽을 처리하지 않도록 하십시오.

두 시스템 모두에 동일한 보안 업데이트를 적용하고 재부팅하십시오. , , 및 설치 이미지 버전과 테스트 날짜를 기록하십시오 cat /etc/os-release. uname -rUbuntu lscpuServer 24.04는 일반적으로 일반 공급형(GA) 커널 트랙을 사용하지만 선택적으로 하드웨어 활성화(HWE) 커널을 사용할 수 있습니다. 커널 트랙이 다르면 설치 유형만 비교하는 것이 불가능해집니다. GA 및 HWE 커널에 대한 Ubuntu 커널 설명서에서 이러한 차이점을 설명합니다.

두 세트의 측정값을 수집하세요:

1. 신규 설치 기준선: 동일한 업데이트를 완료한 직후, 워크로드를 설치하기 전의 상태입니다. 이를 통해 설치 기본 설정의 실제적인 차이점을 분리하여 확인할 수 있습니다.
2. 실제 운영 환경과 유사한 기준선: 동일한 애플리케이션 패키지를 설치하고, 동일한 서비스를 활성화하고, 동일한 구성을 적용한 후의 상태입니다. 이를 통해 초기 설치 공간 차이가 여전히 중요한지 여부를 확인할 수 있습니다.

테스트당 최소 여러 번, 가능하면 워밍업 후 5회 이상 실행하고 중앙값과 변동성을 비교하십시오. 재부팅 후 여러 번의 부팅 시간을 측정하십시오. 한 시스템의 콜드 부팅 결과와 다른 시스템의 이미 워밍업된 결과를 절대 비교하지 마십시오.

먼저 쉽게 구분할 수 있는 차이점부터 측정해 보세요.

1. 설치된 패키지 수를 세고 디스크 공간을 확인합니다.

패키지 개수와 스토리지 사용량은 일반적으로 가장 쉽게 확인할 수 있는 특징입니다. 각 VM에서 다음 명령을 실행하세요.

dpkg-query -W -f='${binary:Package}\n' | wc -l
df -h /
lsblk -f

디스크 개수, 루트 파일 시스템의 사용 공간 및 파일 시스템 레이아웃을 기록하십시오. 루트 파티션의 크기가 비슷한지 확인하십시오. 그렇지 않으면 파티션 구성으로 인해 차이가 발생할 수 있습니다. 디스크 사용량에는 로그, 패키지 캐시 및 파일 시스템 메타데이터도 포함되므로 설치 시간과 업데이트 이력이 동일한지 확인하는 것이 중요합니다.

2. "여유" RAM뿐만 아니라 사용 가능한 RAM 용량을 비교하십시오.

두 시스템 모두 일정한 안정화 기간 동안 유휴 상태가 된 후 다음 명령을 실행하십시오.

free -h
systemctl --type=service --state=running --no-pager

available해당 열과 를 free모두 살펴보세요 used. Linux는 유휴 메모리를 캐시에 사용하며, 애플리케이션이 필요로 할 때 회수할 수 있습니다. 해당 free열의 값이 작다고 해서 반드시 문제가 있는 것은 아닙니다. 추가 메모리 사용량이 실제로 유지할 계획인 서비스와 관련된 것인지 확인해 보세요.

3. 부팅 시간을 비교하고 속도가 느린 서비스를 찾으세요.

부팅할 때마다 배포판에 포함된 systemd 도구를 사용하십시오.

systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain

systemd-analyze time이 명령은 부팅 단계 타이밍을 보고하지만, 애플리케이션이 요청을 수락할 준비가 되었다는 것을 반드시 의미하는 것은 아닙니다. blame또한, 일부 서비스는 병렬로 초기화될 수 있고 측정 방식이 다르기 때문에 이 목록이 오해를 불러일으킬 수 있습니다. 따라서 핵심적인 부분을 먼저 조사한 다음, 관심 있는 특정 서비스 엔드포인트를 별도로 확인하십시오. 이러한 제한 사항은 Ubuntu 24.04 systemd-analyze 설명서 에 자세히 설명되어 있습니다 .

예를 들어, 서버가 HTTP API를 실행하는 경우 재부팅 후 API 상태 엔드포인트가 성공할 때까지의 시간을 측정합니다. 호스트가 데이터베이스를 실행하는 경우 쿼리가 성공하는지 확인합니다. 이러한 준비 상태 측정은 운영 체제가 부팅 목표에 도달하는 것보다 훨씬 더 실질적인 조치를 취할 수 있는 지표입니다.

그런 다음 제어된 부하 조건에서 CPU와 스토리지를 테스트합니다.

4. 두 머신에서 동일한 CPU 작업 부하를 실행합니다.

간단한 CPU 비교를 위해, 새로 설치한 후 시스템 정보를 기록해 둔 다음, 각 임시 가상 머신에 동일한 버전의 sysbench를 설치합니다. 그런 다음 동일한 명령어를 실행합니다.

sudo apt update
sudo apt install sysbench
sysbench --threads=1 --time=30 cpu --cpu-max-prime=20000 run

반복 실행 시 초당 이벤트 수와 지연 시간을 비교하십시오. Sysbench 프로젝트 문서에서 명령 구문과 내장 CPU 테스트 기능을 확인할 수 있습니다. 할당된 CPU 개수에 맞는 경우에만 동일한 더 높은 스레드 개수로 두 번째 실행을 수행하십시오. 패키지 세트 축소만으로는 CPU 속도 향상을 주장할 수 없습니다. 예상치 못한 차이가 발생하면 호스트 CPU 경합, 클럭 동작, 커널 버전 및 백그라운드 프로세스를 확인해야 합니다.

5. 실제 운영 환경의 디스크를 벤치마킹하지 않고 디스크 I/O를 테스트합니다.

선택적 스토리지 실험을 위해 두 테스트 머신 모두에 fio를 설치하고 충분한 여유 공간이 있는 임시 파일 시스템에 동일한 테스트 파일을 생성합니다. 다음 명령은 현재 사용자의 홈 디렉터리에 256MiB 크기의 파일을 생성한 다음 해당 파일에 대해 제한된 임의 읽기 워크로드를 실행합니다.

sudo apt install fio
dd if=/dev/urandom of="$HOME/fio-sample.bin" bs=1M count=256 status=progress
fio --name=randread --filename="$HOME/fio-sample.bin" --rw=randread --bs=4k --size=256M --ioengine=libaio --iodepth=16 --direct=1 --runtime=30 --time_based --group_reporting

두 시스템을 동일한 디스크와 I/O 매개변수로 실행하십시오. 256MiB 파일은 데이터베이스 또는 스토리지 장치를 정확하게 모델링하기에는 너무 작을 수 있습니다. 충분한 임시 공간과 안전한 테스트 환경이 확보된 경우에만 파일 크기를 늘리고 워크로드를 변경하십시오. 최대 대역폭 수치뿐만 아니라 IOPS, 대역폭 및 지연 시간 분포를 기록하십시오. Ubuntu 24.04 fio 설명서에서 워크로드 매개변수에 대한 설명을 확인할 수 있습니다. 유용한 데이터가 포함된 원시 블록 장치에 쓰기 테스트를 수행하지 마십시오.

6. 마지막으로 실제 응용 프로그램을 테스트하세요.

웹 또는 데이터베이스 버전, 연결 제한, 로깅, TLS, 캐싱 및 모니터링을 포함하여 두 머신에 정확히 동일한 애플리케이션 스택을 설치합니다. 동일한 동시 접속 수와 테스트 시간으로 별도의 부하 생성기를 사용하여 동일한 요청 조합을 전송합니다. 처리량, 중앙값 및 95번째 백분위수 응답 지연 시간, 오류율, CPU 사용률, 메모리 사용량 및 스와핑을 측정합니다. 동일한 데이터 세트를 사용하고, 경합을 고려하지 않고 두 머신이 노이즈가 많은 스토리지 백엔드를 공유하지 않도록 합니다.

소규모 API 서버의 경우, 유휴 메모리 용량의 차이는 부하 시 스왑이 발생하기 시작하는 구성에 영향을 미칠 수 있습니다. 반면, 여유 RAM이 충분한 CPU 집약적인 워커의 경우, 동일한 애플리케이션 바이너리라도 실질적으로 비슷한 처리량을 제공할 수 있습니다. 하지만 이러한 결과는 테스트 없이는 단정할 수 없습니다.

상반되는 벤치마크 결과를 해석하는 방법

• 패키지 개수는 줄었지만 CPU 성능 점수는 동일함: 이는 매우 일관된 결과입니다. 설치된 도구 수가 적다고 해서 컴퓨팅 성능이 반드시 달라지는 것은 아닙니다.
• 디스크 사용량은 낮지만 IOPS는 동일한 경우: 여유 공간과 장치 속도는 서로 다른 속성입니다. 스토리지 하드웨어, I/O 패턴, 파일 시스템 및 캐싱을 살펴보세요.
• systemd 부팅 속도는 빨라졌지만 애플리케이션 준비 속도는 여전히 느립니다. 병목 현상은 애플리케이션 시작, 네트워크 종속성 또는 데이터베이스 복구에 있을 수 있습니다.
• 유휴 RAM은 줄었지만 요청 지연 시간은 동일함: 최소화 모드는 유용한 용량 여유를 제공할 수 있지만 현재 작업 부하에는 메모리 제약이 없습니다.
• 실행 간 점수가 크게 변동하는 경우: 성능을 판단하기 전에 주변 컴퓨터의 노이즈, CPU 주파수 스케일링, 업데이트, 예약된 작업, 열 스로틀링 및 캐시 워밍업 등의 요인을 조사하십시오.

측정된 이점이 단지 아주 적은 양의 유휴 디스크 공간 확보에 그치더라도 운영 워크플로에서 누락된 관리 유틸리티가 반복적으로 필요한 경우라면 표준 설치가 더 생산적인 선택일 수 있습니다. 서버가 자동으로 프로비저닝되고 엄격하게 정의된 서비스를 실행하는 경우, 최소화된 기본 패키지를 사용하면 패키지 선택에 대한 감사가 더 쉬워집니다.

기존 서버를 최소화 모드로 전환해야 할까요?

일반적으로 벤치마크 수치만을 쫓기 위한 것은 아닙니다. 정상적인 표준 설치를 위해서는 먼저 실제로 실행 중인 서비스를 점검하고 애플리케이션 성능을 측정해야 합니다. 관련 없는 패키지를 제거해도 이미 안정적인 작업 부하가 개선되지 않을 수 있으며, 부주의한 패키지 제거는 네트워킹, 복구, 로깅 또는 원격 관리 기능을 손상시킬 수 있습니다. Canonical의 Ubuntu 보안 지침에서는 불필요한 패키지 제거 대신 기본 패키지를 무분별하게 제거하는 대신 적절하게 최소한의 구성으로 설치를 시작할 것을 권장합니다.

재구축이 필요한 경우 데이터와 구성을 백업하고, 복원 결과를 검증하고, 새 인스턴스에 최소화된 설치 옵션을 적용하고, 필요한 패키지를 명시적으로 프로비저닝하십시오. 트래픽을 이동하기 전에 SSH 액세스, 업데이트, 시간 동기화, 백업, 모니터링, 방화벽 정책 및 애플리케이션 상태를 검증하십시오. 관리자가 정기적으로 번들 진단 도구를 사용하거나 다양한 역할을 수행하는 경우, 새로 설치할 때 용량이 더 크더라도 표준 설치 방식이 더 나을 수 있습니다.

보안은 관련은 있지만 별개의 문제입니다. 패키지 수가 줄어들면 유지 관리해야 하는 소프트웨어 양이 줄어들 수 있지만, 이것이 특정 CVE 감소를 보장하는 것은 아닙니다. 두 설치 유형 모두 보안 업데이트 및 서비스 강화가 필요합니다.

최종 확인 체크리스트

• 두 시스템 모두 아키텍처, 패치 레벨, 커널 트랙 및 설치 프로그램 버전이 동일한 Ubuntu Server 24.04 LTS인지 확인하십시오.
• 표준 또는 최소화 옵션 선택, 설치 프로그램 선택 사항, 그리고 이후에 추가된 서비스를 문서화하십시오.
• 동일한 업데이트 후 및 일정 시간 동안의 안정화 과정을 거친 후 패키지 수, 루트 파일 시스템 사용량 및 사용 가능한 메모리를 비교합니다.
• 여러 번 재시작하면서 부팅 및 애플리케이션 준비 상태를 반복적으로 측정하고, 단일 최적 실행 결과가 아닌 중앙값을 보고합니다.
• CPU, 스토리지 및 애플리케이션 워크로드에 대해 일치하는 매개변수를 사용하고 오류 및 지연 시간 분포를 기록하십시오.
• 동일한 종속성, 구성 및 데이터를 사용하여 애플리케이션을 실행한 다음 차이점이 용량, 안정성 또는 배포 시간에 영향을 미치는지 판단하십시오.

실질적인 결론: 일반적으로 범위가 좁고 자동화된 서버에는 최소화된 버전이 더 나은 초기 리소스 사용량 을 제공하며, 표준 버전은 더 완벽한 기본 도구 세트를 제공합니다. 두 옵션 모두 항상 더 빠르다고 할 수는 없습니다. Ubuntu Server 24.04 LTS에서는 서비스가 실제로 처리해야 하는 작업 부하에서 성능을 측정하는 것이 가장 유용한 벤치마크입니다.