이 글은 2026 OCP Korea Tech Day에서 발표한 내용을 바탕으로 재구성했습니다.

래블업이 개발하는 Backend.AI는 NVIDIA GPU뿐 아니라 AMD, Intel, 국산 NPU까지 다양한 AI 가속기 위에서 동작합니다. 따라서 새 AI 가속기가 나올 때마다 실제 하드웨어에서 검증하는 과정이 필수입니다. 최근 몇 년 사이 검증해야 할 하드웨어 종류가 크게 늘면서 검증 환경을 준비하고 운영하는 일 자체가 부담이 되었습니다. 이 글에서는 이 부담을 줄이기 위해 사내 테스트베드를 만들고 운영하면서 겪은 문제와 해결 과정을 공유합니다.

AI 가속기 지형의 변화

몇 년 전만 해도 AI 가속기 시장에는 NVIDIA 혼자 절대강자로 군림하고 있었습니다. 지금은 AMD Instinct MI350 시리즈(CDNA 4)가 주요 클라우드에 올라와 있고, Intel 역시 Gaudi와 B70 등의 카드를 기반으로 시장을 넓히고 있습니다. 국내에서도 FuriosaAI RNGD와 Rebellions ATOM이 양산과 상용화 단계에 들어섰습니다. 소프트웨어 스택도 CUDA 하나에서 ROCm, SynapseAI, 벤더별 SDK로 파편화되었습니다.

표 1. 주요 AI 가속기 현황 (2026년 기준)

하드웨어의 전제 자체도 바뀌고 있습니다. 기존에는 x86 호스트에 GPU가 전용 VRAM을 따로 가지는 '메모리 분리 구조'가 당연했습니다. 하지만 GB10이나 GH200 같은 장비는 arm64 호스트에서 CPU와 GPU가 메모리 하나를 공유합니다(Unified Memory). 같은 NVIDIA 안에서도 세대에 따라 전제가 달라지는 셈입니다.

그림 1. 메모리 구조의 변화. 기존 x86 환경에서는 CPU와 GPU가 PCIe로 연결되고 RAM과 VRAM을 각각 따로 가졌지만, GB10과 GH200에서는 CPU와 GPU가 하나의 통합 메모리를 공유한다.

플랫폼을 만드는 입장에서는 지원해야 할 대상이 GPU 몇 종에서 서로 다른 스택의 조합으로 늘어났고, 새 하드웨어가 나오는 주기도 짧아졌습니다. 이에 따라 이러한 변화를 감당할 검증 환경이 필요해졌습니다.

검증해야 할 조합의 크기

Backend.AI는 오픈소스 AI 개발·서비스 플랫폼으로, AI 가속기를 코어와 분리된 플러그인 구조로 지원합니다. 노드 컨트롤러를 수정하지 않아도 플러그인 설치만으로 신규 AI 가속기를 추가할 수 있고, 스케줄러는 리소스 슬롯 벡터만 참조하기 때문에 이종 자원도 단일 방식으로 스케줄링할 수 있습니다.

현재 플러그인이 지원하는 벤더는 NVIDIA(discrete, fGPU, MIG, unified 4가지 할당 모드), AMD, Intel Gaudi, Google TPU, FuriosaAI, Rebellions, HyperAccel, Tenstorrent, Graphcore까지 9개이고, 장치 모델 단위로 세면 12종이 넘습니다.

같은 NVIDIA GPU라도 나눠 쓰는 방식이 여러 가지입니다. 단일 GPU를 분할하는 기존 방식에는 MIG와 MPS가 있습니다.

• MIG: 하드웨어 파티션(GPC) 단위로 가상 장치를 매핑하기 때문에 성능과 보안 격리가 가장 확실합니다. 대신 파티션 크기가 고정이고, 크기를 바꾸려면 GPU를 리셋해야 하며, 다중 GPU 할당이 불가능합니다.
• MPS: 유저 레벨에서 하나의 CUDA context를 여러 워크로드가 공유하기 때문에 소수점 단위로 유연하게 나눌 수 있습니다. 대신 한 프로세스의 오류가 공유 중인 전체 워크로드로 전파됩니다.

Backend.AI의 fGPU는 드라이버 레벨에서 워크로드마다 CUDA context를 격리합니다. MPS 수준의 런타임 할당 유연성을 유지하면서 오류 전파를 차단하고, 필요하면 MIG와 혼합해서 쓸 수도 있습니다. 다만 성능 격리는 GPU 내부 스케줄러에 의존하기 때문에 투명하지 않다는 한계가 있습니다.

fGPU는 NVIDIA 드라이버의 내부 동작에 직접 의존하기 때문에 드라이버 버전대마다 별도 빌드가 필요하고, GPU 세대가 바뀔 때마다 다시 검증해야 합니다. 저희 팀은 이런 검증을 수행할 환경을 만드는 일을 주요 과제로 삼았습니다.

베어메탈과 클라우드가 모두 필요한 이유

효과적인 검증을 위해서는 베어메탈과 클라우드 환경이 모두 필요합니다.

국산 NPU나 Unified Memory 기반 최신 장비는 퍼블릭 클라우드 인스턴스로 존재하지 않아 베어메탈 검증이 필수입니다. 반대로 특정 프로바이더에 종속된 고객 환경을 재현하거나, 테스트 기간에만 대규모 인스턴스를 확보할 때는 클라우드를 활용해야 합니다.

결과적으로, 운영 방식이 완전히 다른 두 환경을 단일 플랫폼으로 통합하기로 했고, 다음 세 가지 설계 조건을 세웠습니다.

1. 다양한 하드웨어 수용: x86, arm64, GPU, NPU 등 하드웨어별 개별 운영 절차를 두지 않고 단일 파이프라인으로 처리합니다.
2. 회수 후 재할당 (베어메탈): 베어메탈 반납 시 수동 개입 없이 이전 사용자의 잔여 설정을 초기화하고 복원합니다.
3. 베어메탈과 클라우드의 동일 인터페이스: 프로바이더 종류와 무관하게 요청, 접속, 회수 인터페이스를 일원화합니다.

provider 통합과 플랫폼 설계

전체 구성

그림 2. 통합 테스트베드 전체 구성. 개발자와 QA의 요청은 사내 플랫폼의 단일 API로 들어오고, provider별 드라이버를 거쳐 베어메탈, OpenStack, AWS, Azure로 분기된다.

플랫폼은 사용자, 추상화 레이어, provider(사내 OpenStack, AWS, 베어메탈) 3계층으로 구성했습니다. 사용자는 원하는 provider와 인스턴스 타입을 지정해 추상화 레이어에 요청하고, provider마다 다른 생성·접속·회수 절차는 레이어가 처리합니다. 어떤 provider를 선택하든 사용자가 거치는 절차와 제공받는 환경은 동일합니다.

어디까지 추상화할 것인가

추상화 레이어를 설계할 때는 전체 provider에서 동일한 의미로 성립하는 항목만 통합한다는 원칙을 세웠습니다.

이 기준에 따라 인스턴스 생성·조회·종료·회수 절차, 이미지 등록·배포 방식, 네트워크·접근 제어 모델, 키페어·스냅샷 관리를 통합했습니다. 예를 들어 보안 그룹은 AWS든 OpenStack이든 "어느 포트를 열 것인가"라는 의미가 같기 때문에 하나의 모델로 묶을 수 있었습니다. 반면 인스턴스 타입별 성능 특성이나 provider별 과금 체계는 provider마다 의미가 다르기 때문에 통합하지 않았습니다. 이러한 정보는 인스턴스 타입 선택과 비용 판단의 근거가 되므로, 가공 없이 provider가 제공하는 그대로 노출합니다.

통합 범위를 좁게 유지한 덕분에 신규 provider는 코어 수정 없이 드라이버 구현만으로 추가되고, 신규 베어메탈 노드는 인벤토리 등록만으로 편입할 수 있습니다.

파편화된 사내 자원 통합

먼저 사내에 흩어져 있던 컴퓨팅 노드를 OpenStack 클러스터로 통합했습니다. 통합 전에는 팀별로 장비를 개별 관리하고 있어서 점유 현황이 담당자 개인의 인지에 의존했고, 유휴 자원이 있어도 다른 팀이 쓸 수 없었으며, 같은 하드웨어라도 OS 등 환경이 제각각이었습니다. 통합 후에는 점유 현황을 한곳에서 조회하고, 유휴 자원을 원하는 환경으로 바로 쓸 수 있게 되었습니다.

그림 3. 사내 컴퓨팅 노드 통합 전후. 통합 전에는 팀과 프로젝트 경계에 갇혀 보이지 않던 유휴 자원(점선)이, 통합 후에는 전체 풀에서 바로 확인하고 사용할 수 있는 상태가 된다.

이미지 파이프라인 최적화

자원을 통합한 뒤에는 이미지 준비에 걸리는 시간이 문제가 되었습니다. provider마다 기본 제공 이미지가 달라, 원하는 Backend.AI 버전을 검증하려면 매번 40분가량의 수동 설치가 필요했습니다. 일부 검증 환경은 특정 provider에서만 사용할 수 있다는 제약도 있었습니다.

이를 해결하기 위해 이미지 정의를 사내 플랫폼에서 중앙 관리하고, Packer 기반 이미지 빌드 파이프라인을 구축했습니다. Backend.AI 릴리즈가 나올 때마다 모든 provider용 최신 이미지가 자동으로 만들어지고, Rocky나 CentOS처럼 검증에 필요한 환경도 이미지로 제공합니다. 그 결과 환경 준비 시간이 40분에서 15분으로 단축되었습니다.

그림 4. 이미지 준비 과정의 변화. 기존에는 provider마다 원하는 버전의 이미지가 없어 매번 약 40분의 수동 설치가 필요했지만, Packer 파이프라인 도입 후에는 Backend.AI 릴리즈마다 provider별 이미지가 자동 생성되어 준비 시간이 15분으로 줄었다.

인스턴스 회수 절차 일원화

이미지 다음으로는 회수 절차를 정비했습니다. 인스턴스 회수(혹은 terminate)와 생성 실패 처리가 provider마다 다른 절차로 수행되고 있었는데, 이 절차가 한 번이라도 누락되면 클라우드에서는 과금이 계속되고, 베어메탈에서는 미사용 노드가 점유 상태로 남습니다.

이를 방지하기 위해 회수를 공통 API의 상태 전이 하나로 통합했습니다. 실패하면 재시도하고, 종료 후에는 잔여 자원을 확인합니다. 클라우드는 인스턴스와 부속 리소스를 삭제하고, 베어메탈은 DB에서 할당(allocation)을 해제한 뒤 VM 내 에이전트를 거쳐 네트워크 부팅(PXE) 방식으로 재설치합니다. 회수가 끝나는 시점에 노드는 할당 가능 풀로 복귀합니다. 매달 5건 정도 생기던 회수 누락 자원 유실이 0건이 되었습니다.

베어메탈 프로비저닝 자동화

회수 후에도 디스크에 남는 이전 사용자의 흔적

클라우드는 인스턴스를 삭제하면 그것으로 끝나지만, 베어메탈은 이전 사용자가 설치한 드라이버 버전, 커널 파라미터, 런타임이 디스크에 그대로 남습니다. 그리고 환경이 오염되어 있으면 검증 실패 시 코드 문제인지 환경 문제인지 원인을 특정할 수 없습니다. 그렇다고 수동으로 초기화하려면 물리 접근이나 원격 콘솔 접속이 필요하고, OS 설치와 초기 설정에 매번 상당한 시간이 소요됩니다.

PXE 기반 재설치 파이프라인

이 초기화 과정은 PXE 기반으로 자동화했습니다. PXE는 서버 펌웨어에 내장된 네트워크 부팅 표준으로, 전원이 켜지면 디스크 대신 네트워크에서 부팅합니다. 노드는 DHCP로 IP를 할당받으면서 부팅 파일을 제공할 설치 서버 정보를 함께 받고, 해당 서버에서 부트로더와 OS 이미지를 내려받아 설치합니다. 설치 서버 한 대만 두면 노드의 디스크 상태와 무관하게 항상 초기 상태의 OS로 재설치할 수 있습니다.

이를 이용해 재설치 파이프라인을 구축했습니다. 노드가 회수되면 부팅 순서를 네트워크 부팅으로 바꿔 재부팅하고, 설치 이미지를 받아 OS를 새로 설치합니다. 첫 부팅에서 계정·네트워크·에이전트가 자동으로 구성되고, 에이전트 상태가 확인되면 노드가 할당 가능 풀로 복귀합니다. 하드웨어에 따라 달라지는 부분은 부팅 경로 하나뿐이고 나머지 단계는 모두 공통이며, 전 과정에 사람이 개입하지 않습니다.

그림 5. PXE 동작 개요. 노드의 PXE 펌웨어가 부팅을 요청하면 설치 서버가 부트로더와 OS 이미지를 내려준다. 설치 서버 한 대가 전체 노드를 담당하며, 노드의 디스크 상태와 무관하게 항상 초기 상태의 OS로 재설치한다.

DGX Spark 통합

DGX Spark는 arm64 호스트에 Unified Memory 구조라서, 기존 파이프라인이 가정하던 x86 서버와 전제가 다릅니다. 노드 회수부터 자동 재설치, 클러스터 자동 편입까지를 수동 개입 없이 파이프라인 하나로 처리하는 것을 목표로 잡았습니다.

통합 과정에서 세 가지 문제에 부딪혔습니다.

1. 부트로더의 네트워크 전송 중단: 표준 경로대로 GRUB으로 네트워크 부팅을 시도하면 커널은 받아오는데 두 번째 파일을 받는 시점에 "couldn't send network packet" 오류와 함께 멈췄습니다. 추적해 보니 GRUB 문제라기보다 펌웨어 쪽 문제였습니다. 펌웨어가 새 연결마다 요구되는 난수(EFI_RNG_PROTOCOL) 요청을 제대로 처리하지 못해, 첫 요청 이후의 네트워크 연결이 전부 실패하는 것이었습니다. 펌웨어를 수정할 수는 없으니 GRUB을 제거하고, 펌웨어의 네트워크 스택을 그대로 사용하는 iPXE(snponly.efi)로 부트로더를 교체해서 우회했습니다.

2. 설치 후 부팅 미완료: 부트로더 문제를 해결한 뒤에는 설치가 끝난 노드가 몇 시간이 지나도 부팅을 완료하지 못하는 문제가 있었습니다. 확인해 보니 기본 부팅 대상이 GUI(graphical.target)로 설정되어 있었고, 디스플레이가 없는 노드에서 GUI 세션 초기화가 부팅 완료를 막고 있었습니다. 이 대기가 풀릴 때까지 이론상 15시간이 걸립니다. 테스트베드 노드에 GUI는 필요 없으므로 기본 부팅 대상을 CLI(multi-user.target)로 바꾸고, 첫 부팅 때 초기 설정 마법사를 띄우는 서비스들도 함께 비활성화했습니다. 이 조치로 수 시간의 대기가 부팅 후 십수 초 수준으로 단축되었습니다.

3. hostname 중복: 같은 이미지로 설치하니 모든 노드의 hostname이 기본값으로 동일하게 설정되었습니다. 첫 부팅 시 MAC 주소 뒷자리로 이름을 자동 부여하는 서비스를 넣어 해결했습니다.

이 과정을 거쳐 재설치 트리거부터 부팅 완료까지 전체 소요 시간이 22분으로 줄었고, 설치가 끝나면 시스템이 스스로 상태를 확인해 자동으로 클러스터에 편입됩니다. Spark 전용 파이프라인을 따로 만들지 않고 부팅 경로 분기만 추가해 기존 파이프라인에 수용했습니다.

운영 결과

표 2. 테스트베드 통합 전후 운영 지표

남은 과제도 있습니다. 클라우드 비용을 현재 별도로 추적하지 않고 있어서 비용 예측을 위한 지표를 추가해야 하고, 유저별 audit log를 바탕으로 플랫폼 사용 현황을 확인하고 개선하는 작업도 남아 있습니다.

마치며

테스트베드는 새 AI 가속기가 들어올 때마다 계속 확장되고 있습니다. 앞으로도 하드웨어마다 전용 절차를 만들지 않고 기존 파이프라인 안에서 처리하는 방향으로 운영할 계획입니다.