ARM VPS와 x86 VPS 차이점 및 호환성 확인 방법

ARM VPS로 이전할 때 변경되는 점

ARM VPS는 x86 VPS와 동일한 Linux 및 Nginx를 실행하며, 일반적으로 코어당 비용이 더 저렴합니다. 전환 시 발생하는 위험 요소는 호환성입니다. x86-64용으로 컴파일된 프로그램은 arm64에서 전혀 실행될 수 없으므로, 스택의 모든 소프트웨어는 arm64 빌드를 제공하거나 사용자가 직접 다시 빌드할 수 있어야 합니다.

대부분의 최신 스택은 별도의 작업 없이 이 테스트를 통과합니다. 실패는 주로 두 가지 경우에서 발생합니다. 특정 아키텍처용으로만 빌드된 컨테이너 이미지와 arm64 다운로드를 제공하지 않는 클로즈드 소스 소프트웨어입니다. 아래 명령어를 사용하면 인스턴스 비용을 지불하기 전에 자신의 스택이 두 가지 조건을 모두 충족하는지 확인할 수 있습니다. 어떤 종류의 서버가 필요한지 아직 결정하지 못했다면, VPS의 정의와 공유 호스팅과의 차이점부터 확인하십시오.

arm64, aarch64, amd64: 각 명칭의 의미

다른 작업을 시작하기 전에 모든 인스턴스에서 다음 명령을 실행하십시오.

uname -m
dpkg --print-architecture
lscpu | head -n 12
getconf PAGESIZE

uname -m 명령은 ARM 머신에서 aarch64을 출력하고, Intel 또는 AMD 머신에서는 x86_64를 출력합니다. dpkg --print-architecture 명령은 동일한 두 머신에서 각각 arm64과 amd64를 출력합니다. 두 결과 모두 정확합니다. Linux 커널과 Debian 패키징 시스템은 동일한 명령어 세트에 대해 서로 다른 이름을 선택했습니다. 따라서 aarch64과 arm64는 같은 의미이며, x86_64와 amd64도 같은 의미입니다. Docker는 Debian 스타일의 명칭을 사용하므로 이미지 플랫폼이 linux/arm64로 표시됩니다.

arm64 환경의 /proc/cpuinfo 파일에는 model name 항목이 없습니다. 대신 Features 필드가 존재하며, 하드웨어 암호화 기능은 aes pmull sha1 sha2과 같은 플래그로 나타납니다. 이는 ARMv8 암호화 확장(Cryptographic Extensions)으로, Intel 및 AMD 프로세서의 AES-NI와 동일한 역할을 수행합니다. 즉, 하드웨어 수준에서 TLS(전송 계층 보안)와 디스크 암호화 속도를 높여줍니다. VPS에서 AES 하드웨어 가속 확인하기 문서에서 두 아키텍처 모두에 대한 테스트 방법을 다룹니다.

컨테이너가 먼저 중단되는 이유와 오류 형태

모든 Docker 이미지 매니페스트에는 빌드된 아키텍처 정보가 기록됩니다. amd64 매니페스트만 포함된 이미지를 arm64 호스트로 가져오면(pull) 작업은 성공합니다. 하지만 첫 번째 프로세스가 시작될 때 오류가 발생합니다.

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/docker-entrypoint.sh: exec format error

exec format error는 커널이 파일 실행을 거부하는 상황입니다. ELF(executable and linkable format) 헤더에 명시된 머신 타입이 현재 CPU에서 구현되지 않았기 때문입니다. 어떤 설정으로도 해결할 수 없습니다. 해당 명령어는 하드웨어 수준에서 지원되지 않습니다.

배포 전 매니페스트를 확인하십시오.

docker buildx imagetools inspect nginx:1.27

출력 결과에는 매니페스트 목록에 포함된 이미지별로 Platform: 라인이 하나씩 표시되며, linux/amd64나 linux/arm64와 같은 형태입니다. linux/arm64이 없다면 해당 태그는 ARM VPS에서 실행되지 않습니다. docker manifest inspect --verbose nginx:1.27로도 동일한 정보를 확인할 수 있으나, Docker는 docker manifest을 릴리스마다 동작이 바뀔 수 있는 실험적 명령어로 분류하므로 imagetools 사용을 권장합니다.

직접 빌드하는 이미지라면 한 번의 명령어로 두 아키텍처를 모두 빌드하고 매니페스트 목록을 푸시하십시오.

docker buildx build --platform linux/amd64,linux/arm64 -t registry.example.com/app:1.4 --push .

단일 호스트에서 다른 아키텍처용으로 빌드하려면 커널의 binfmt_misc 핸들러에 등록된 QEMU 사용자 모드 에뮬레이션이 필요합니다.

docker run --privileged --rm tonistiigi/binfmt --install all

에뮬레이션은 빌드와 테스트 용도로만 사용하십시오. 실제 서비스 트래픽 처리에는 사용하지 마십시오. Docker 공식 문서에 따르면 QEMU를 이용한 에뮬레이션은 "컴파일, 압축, 압축 해제와 같은 연산 집약적 작업에서 네이티브 빌드보다 훨씬 느릴 수 있습니다." 따라서 ARM 인스턴스에서 에뮬레이션으로 x86 서비스를 운영하면 비용 절감 효과가 사라집니다. 네이티브 환경을 위한 호스트 설정은 두 아키텍처 모두 동일합니다. VPS에서 Docker 실행하기에서 관련 내용을 다루며, 이미지마다 arm64 매니페스트가 포함되어 있다면 기존 Compose 파일은 수정 없이 그대로 작동합니다.

필요한 패키지가 arm64에서 제공됩니까?

Ubuntu와 Debian은 거의 모든 아카이브를 arm64용으로 빌드하므로, apt install nginx postgresql redis-server은 두 아키텍처에서 동일하게 동작합니다. 차이가 발생하는 지점은 서드 파티 저장소입니다.

ARM 인스턴스에서 apt에 직접 확인하십시오.

apt-cache policy some-vendor-agent
apt-get install -s some-vendor-agent

apt-cache policy이 Candidate: (none)를 보고한다면, 활성화된 저장소 중 해당 아키텍처용 패키지 빌드를 제공하는 곳이 없다는 의미입니다. apt-get install -s은 설치를 시뮬레이션하여 아무것도 기록하지 않으며, 같은 상황에서 E: Unable to locate package로 종료됩니다.

이후 출력을 스크롤하여 넘기지 말고 apt update의 결과를 읽어보십시오. amd64 전용인 벤더 저장소는 다음과 같이 표시됩니다.

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://repo.example.com/apt stable InRelease' doesn't support architecture 'arm64'

저장소는 구성되어 있고 접근 가능하지만, 이 시스템에 설치할 수 있는 패키지가 없습니다. 소스 항목 자체도 확인하십시오. [arch=amd64]으로 고정된 행은 arm64 호스트에서 건너뛰므로, 실제 원인은 고정 설정임에도 패키지가 없는 것처럼 보일 수 있습니다.

어떤 워크로드가 안전하며, 무엇을 먼저 확인해야 하는가

인터프리터 언어와 바이트코드 기반 런타임은 설계상 이식성이 뛰어납니다. PHP, Python, Ruby, Node.js는 모두 주요 배포판에서 arm64 패키지를 제공합니다. Go와 Rust는 타겟을 하나만 설정하면 arm64로 교차 컴파일이 가능합니다. LEMP 스택, Node API, Nginx 뒤에서 동작하는 Go 바이너리, 혹은 Postgres 데이터베이스는 arm64에서 일반적인 작업입니다.

JIT(Just-In-Time) 컴파일러는 프로그램 실행 중에 기계어를 생성하므로 타겟 아키텍처를 위한 코드 생성기가 필요합니다. 현재 버전들은 이를 지원합니다. OpenJDK, .NET, Node.js 내부의 V8 엔진, PyPy는 모두 Linux에서 arm64를 지원합니다. 고정된 구버전이 실제 위험 요소입니다. 수년 전의 런타임 릴리스를 설치하는 배포 스크립트는 작동할 것이라고 가정하지 말고, 해당 릴리스의 릴리스 노트에서 aarch64 지원 여부를 확인해야 합니다.

수동으로 작성된 x86 어셈블리나 SSE 및 AVX 인트린직(intrinsics)을 포함하는 라이브러리는 더 조용한 문제입니다. 대부분은 NEON 경로(NEON은 ARM 벡터 명령어 세트입니다)나 일반 C 폴백(fallback)을 가지고 있어 컴파일 및 실행이 가능합니다. 성능은 x86 빌드와 비교하여 어느 방향으로든 달라질 수 있습니다. 기사에서 예측하기보다 자신의 인스턴스에서 직접 측정하십시오.

폐쇄형 소스 소프트웨어는 확실한 차단 요소입니다. 벤더 모니터링 에이전트, 라이선스 데이터베이스 드라이버, 상용 제어판, 혹은 안티바이러스 데몬은 컴파일된 바이너리 형태로 제공되므로, 벤더가 arm64 빌드를 게시하지 않으면 사용자가 할 수 있는 방법이 없습니다. 호스팅 분야에서 cPanel과 WHM이 가장 명확한 사례입니다. 시스템 요구 사항에 x86_64만 명시되어 있고 ARM은 기재되어 있지 않으므로, 제어판 서버는 x86에 머물러야 합니다(2026년 8월 확인, 벤더의 요구 사항 페이지를 다시 확인하는 것이 좋습니다). 만약 이것만이 유일한 걸림돌이라면, VPS에서 운영할 가치가 있는 cPanel 대안에서 시작하여 각 소프트웨어의 아키텍처 지원 여부를 동일한 방식으로 확인하십시오.

커널과 페이지 크기: ARM 인스턴스가 여전히 다른 점

x86-64 서버는 거의 상호 교환이 가능합니다. 반면 ARM 서버는 균일성이 떨어지며, 이러한 차이는 애플리케이션 하위 계층에 존재합니다.

페이지 크기는 운영 환경에 영향을 미치는 요소입니다. 대부분의 arm64 커널은 x86-64와 동일한 4 KiB 페이지를 사용하지만, 일부는 64 KiB를 사용합니다. Red Hat Enterprise Linux 8 for aarch64는 기본값으로 64 KiB 페이지 커널을 제공했으나, RHEL 9에서는 기본값을 다시 4 KiB로 변경하고 더 큰 페이지 크기가 필요한 워크로드를 위해 별도의 kernel-64k 패키지를 유지하고 있습니다. 64 KiB 페이지 크기를 사용하면 커널이 할당할 수 있는 최소 단위가 16배 커지기 때문에, 작은 매핑이 많은 프로세스의 메모리 사용량이 증가합니다. 인스턴스에서 getconf PAGESIZE 명령을 실행하여 추측하지 말고 실제 값을 확인하십시오.

알아두어야 할 몇 가지 작은 차이점이 더 있습니다. arm64에는 운영체제 CPU 마이크로코드 패키지가 없으므로, 펌웨어 업데이트는 apt가 아닌 서비스 제공업체를 통해 이루어집니다. ARM 서버는 UEFI(unified extensible firmware interface)를 통해 부팅하며 ACPI(advanced configuration and power interface)를 통해 하드웨어 정보를 기술합니다. AMD SEV 메모리 암호화나 Intel GVT-g 가상 GPU와 같이 ARM에 대응하는 기능이 전혀 없는 x86 기능도 존재합니다.

ARM 서버 플랫폼은 성숙했습니까?

소프트웨어 측면에서는 그렇습니다. Debian, Ubuntu, Fedora, RHEL 모두 일급 arm64 빌드를 제공하며, Docker Hub의 공식 이미지도 당연하게 다중 아키텍처(multi-arch)를 지원합니다.

최근 가장 확실한 증거는 Proxmox입니다. 2026년 8월 5일, Proxmox는 공식적으로 지원하는 첫 arm64 버전인 Proxmox Virtual Environment 9.2를 발표했으며, x86-64 버전과 패키지 저장소 및 릴리스 주기를 공유합니다. 이 버전은 Linux 7.0, QEMU 11.0, LXC 7.0, ZFS 2.4를 포함한 Debian 13.5를 기반으로 하며, 아키텍처별로 특수한 일부 항목을 제외하면 설정과 도구 구성이 x86-64와 동일합니다.

해당 발표에 포함된 주의 사항을 읽어보십시오. 공식 지원되는 ARM 서버 하드웨어가 여전히 얼마나 제한적인지 알 수 있습니다. Proxmox는 NVIDIA 및 Supermicro와 Grace Hopper 하드웨어에서 공동 테스트를 거친 후, 출시 첫날부터 NVIDIA Grace 및 NVIDIA Vera 시스템을 검증했습니다. 그 외 UEFI 기반 ARMv8-A 및 ARMv9-A 하드웨어는 최선의 지원(best effort support)을 제공합니다. Device tree만 사용하는 Raspberry Pi와 같은 단일 보드 컴퓨터는 지원하지 않습니다. 게스트는 동일한 아키텍처의 노드에서만 실행되며, 라이브 마이그레이션은 같은 아키텍처 노드 간에만 작동하고, 아키텍처가 혼합된 클러스터는 공식적으로 지원하지 않습니다.

이것이 2026년 8월 기준의 솔직한 현주소입니다. 하이퍼바이저 공급업체가 x86-64와 동일한 주기로 arm64를 출시한다는 것은 해당 플랫폼에 있어 실질적인 진전입니다. 출시 첫날 지원되는 하드웨어 목록은 두 개의 CPU 제품군뿐입니다.

커밋 전 확인해야 할 체크리스트

1. 테스트 인스턴스에서 uname -m을(를) 실행하고 aarch64이(가) 출력되는지 확인합니다.
2. Compose 파일의 모든 이미지에 대해 docker buildx imagetools inspect을(를) 실행하고 각 이미지마다 linux/arm64 플랫폼 라인이 있는지 확인합니다.
3. ARM 인스턴스에서 apt update을(를) 실행하고 출력되는 모든 Skipping acquire 경고 메시지를 읽어봅니다.
4. 의존하고 있는 모든 클로즈드 소스 에이전트의 다운로드 페이지를 열어 arm64 또는 aarch64 빌드가 있는지 이름으로 확인합니다.
5. 메모리 크기를 결정하기 전에 getconf PAGESIZE을(를) 실행하고 결과를 기록해 둡니다.
6. 선택하려는 ARM 플랜과 x86 플랜 모두에서 직접 벤치마크를 실행합니다.

이 글에서 다루지 않는 내용

ARM과 x86의 가격 대비 성능 비율을 제시하지 않습니다. 코어당 가격은 제공업체와 요금제에 따라 다르며, 타인의 하드웨어에서 측정된 수치는 귀하의 환경을 예측하지 못합니다. 대신 직접 측정하십시오. VPS 벤치마킹 가이드에서는 sysbench와 fio를 사용하여 반복 가능한 측정 방법을 다루며, VPS의 실제 비용에서는 가격 비교 측면을 다룹니다. 스토리지는 CPU 아키텍처와는 별개의 결정 사항이며, VPS에서 NVMe와 SATA SSD 비교에서 해당 내용을 다룹니다. 가능하다면 귀하의 실제 워크로드를 사용하여 두 요금제 모두에서 동일한 테스트를 실행하고, 그 결과 수치를 바탕으로 판단하십시오.

FAQ

Docker 컨테이너가 ARM VPS에서 실행됩니까?

스택의 모든 이미지가 매니페스트에 linux/arm64 항목을 포함하고 있다면 실행됩니다. docker buildx imagetools inspect <image> 명령으로 각 이미지를 확인하여 Platform: linux/arm64 줄이 있는지 살펴보십시오. Docker Hub의 공식 이미지는 대부분 멀티 아키텍처를 지원합니다. 소규모 벤더의 이미지나 x86 머신에서 직접 빌드한 이미지는 그렇지 않은 경우가 많습니다. 직접 만든 이미지라면 docker buildx build --platform linux/amd64,linux/arm64 ... --push 명령으로 다시 빌드하여 하나의 태그로 두 아키텍처를 모두 지원하게 만드십시오.

ARM 서버에서 exec format error 오류는 무엇을 의미합니까?

커널이 ELF 헤더에 다른 머신 유형이 명시된 바이너리를 실행하려다 거부한 것입니다. arm64 호스트에서 이 오류는 거의 항상 x86-64 바이너리나 컨테이너 이미지를 의미합니다. Docker는 먼저 요청된 이미지 플랫폼 linux/amd64가 감지된 호스트 플랫폼 linux/arm64/v8과 일치하지 않는다는 경고를 출력합니다. 해결 방법은 올바른 아키텍처용으로 빌드하는 것입니다. 어떤 설정을 변경해도 x86-64 바이너리를 ARM에서 네이티브로 실행할 수는 없습니다.

arm64와 aarch64는 같은 것입니까?

그렇습니다. 두 이름 모두 64비트 ARM 명령어 세트를 지칭합니다. 커널은 aarch64를 통해 uname -m라고 보고하지만, Debian 및 Ubuntu 패키징과 Docker 플랫폼 문자열은 arm64을 사용합니다. 반대쪽도 마찬가지로 uname -m은 x86_64이라고 말하고 패키징은 amd64라고 합니다. 다운로드 페이지에서 aarch64 파일만 제공한다면, 그 파일은 dpkg --print-architecture에서 arm64라고 부르는 머신을 위한 올바른 파일입니다.

ARM VPS가 x86 VPS보다 빠릅니까?

이 질문에 대한 일반적인 답변은 없으며, 읽게 되는 모든 단일 비율은 귀하의 하드웨어가 아닌 환경에서 측정된 것입니다. 속도는 특정 CPU 모델, 할당된 코어 수, 제공업체가 테넌트 간의 경합을 처리하는 방식, 그리고 귀하의 워크로드가 벡터 명령어를 얼마나 잘 활용하는지에 따라 달라집니다. 가능하다면 실제 워크로드를 사용하여 선택하려는 두 플랜을 직접 벤치마킹하고 그 수치를 비교하십시오.

프로덕션 서버를 arm64로 옮기기 전에 무엇을 확인해야 합니까?

다음 순서대로 네 가지를 확인하십시오. 모든 컨테이너 이미지가 arm64 매니페스트를 가지고 있는지 확인합니다. 모든 타사 apt 저장소가 binary-arm64을 게시하는지 확인합니다. 모든 클로즈드 소스 에이전트에 aarch64 다운로드 파일이 있는지 확인합니다. 마지막으로 대상 인스턴스에서 getconf PAGESIZE를 실행하십시오. 64 KiB 페이지 커널은 작은 매핑이 많은 프로세스의 메모리 사용량에 영향을 주기 때문입니다. 이 네 가지 확인 사항 중 하나라도 실패한다면 해당 서버는 x86으로 유지해야 합니다.