장비는 있는데 서비스에는 못 넣는 이유 | AIEEV 유기태 개발자
개발 워크스테이션에도 GPU가 있고 연구실 서버에도 있습니다. 지사의 엣지 장비에도 가속기가 달려 있을 수 있죠. 그런데 막상 모델을 올리려고 하면 이야기가 달라집니다. 드라이버가 맞지 않거나 필요한 SDK가 없을 수 있고, 네트워크 문제로 외부에서 접근하지 못하는 경우도 있습니다. 분명 장비는 있는데 정작 서비스에서는 쓸 수 없는 겁니다.
AIEEV Dev Team의 유기태 님은 이렇게 여러 곳에 흩어진 GPU와 NPU를 연결해 실제 AI 추론에 사용할 수 있는 분산 인프라를 개발하고 있습니다. 각 장비가 모델을 실행할 수 있는 상태인지 확인하고, 검증된 자원을 하나의 풀로 묶어 추론 요청을 처리하는 구조를 만들고 운영합니다. 지난 9월 1일에는 KCD x Ceph x OpenInfra Day Korea 2026에서 ‘Ray Serve in the Wild: GPU/NPU 기반 AI 인퍼런스 오토스케일링과 운영 경험’을 주제로 그동안의 경험도 공유했는데요. GPU가 있는데도 왜 바로 쓸 수 없는지, 여러 선택지 가운데 왜 Ray를 택했는지, 실제 운영에서는 어떤 예상치 못한 문제를 만났는지 기태 님께 직접 들어봤습니다.
👋 안녕하세요. 간단한 소개와 업무에 대해 소개해주세요.
안녕하세요. AIEEV에서 Ray와 Kubernetes 기반의 분산 AI 인프라를 개발하고 운영하고 있는 유기태입니다. AIEEV에서는 분산 GPU와 NPU를 실제 서비스에서 쓸 수 있는 자원으로 만드는 일에 기여하고 있습니다. 사실 GPU만 있다고 해서 바로 가져다 쓸 수 있는 건 아니거든요. 먼저 원하는 모델이 실제로 돌아가는지 확인하고, 검증이 끝난 자원만 하나의 풀로 묶습니다. 그 위에 모델을 띄워 실제 요청을 처리하고요. 요청이 몰리면 자원을 늘리고 트래픽이 줄면 다시 줄입니다. 중간에 장비 하나가 빠져도 서비스는 계속 돌아가야 하고요. 이번 발표에서는 이런 시스템을 직접 만들고 운영하면서 겪었던 이야기를 공유했습니다.
🎤 “GPU가 있는데 왜 못 쓰지?”에서 시작된 이야기
이번 발표에서 가장 이야기하고 싶었던 문제는 무엇이었나요?
요즘 AI 인프라 이야기를 하면 GPU를 얼마나 확보했는지가 먼저 나오잖아요. 물론 새로운 GPU 공급은 계속 필요합니다. 그런데 실제 현장에서 일하다 보면 GPU를 확보하는 것과 그 GPU를 서비스에서 사용할 수 있게 만드는 것은 다른 문제라는 걸 알게 됩니다. GPU만 가져다 놓는다고 바로 AI 서비스를 시작할 수 있는 건 아닙니다. 서버와 전력이 필요하고 열을 처리할 냉각 환경도 있어야 합니다. 실제 요청을 받으려면 네트워크와 보안 환경까지 갖춰져야 하죠. 그래서 새 GPU가 공급돼도 실제 서비스 용량이 되기까지는 시간이 걸립니다. 반대로 이미 설치된 GPU가 항상 사용되고 있는 것도 아닙니다. 장비는 있는데 다른 환경이 준비되지 않아서 쉬고 있는 시간이 생기기도 하죠. 저희는 여기에서 “새 GPU를 확보하는 것만큼 이미 존재하는 GPU의 유휴 시간을 활용하는 것도 중요하지 않을까?”라는 질문을 던졌습니다. 이번 발표도 실제로 그 자원들을 연결해 서비스로 운영하면서 겪은 경험에서 시작했습니다.
GPU와 NPU는 종류에 따라 필요한 실행 환경이 다르고 같은 종류의 장비라도 설치된 드라이버나 소프트웨어에 따라 실행할 수 있는 모델이 달라집니다. 그래서 저희에게 중요한 건 GPU가 몇 개 있느냐보다 이 장비에서 우리가 원하는 모델이 실제로 돌아가느냐 였습니다. 예를 들어 NPU가 하나 있다고 해도 그 정보만으로는 바로 서비스에 사용할 수 없습니다. 필요한 소프트웨어를 지원하는지 확인하고 실제로 모델을 띄워 추론까지 해봐야 하죠. 그래서 저희는 장비를 발견했다고 바로 자원으로 등록하지 않습니다. 자체 Agent가 장비와 실행 환경을 확인하고 실제 워크로드까지 검증한 뒤 사용할 수 있는 장비만 자원 풀에 넣습니다. 여기까지 하면 사용할 수 있는 장비는 확보한 셈입니다. 그다음에는 또 다른 문제가 시작됩니다. 서로 다른 곳에 있는 이 장비들을 어떻게 하나의 서비스처럼 움직이게 할 것인가 하는 문제입니다.
🧩 Kubernetes도 있고 Slurm도 있는데, 왜 Ray였나요?
여러 장비를 하나의 서비스처럼 운영하려면 어떤 작업을 어느 장비에서 실행할지 결정해주는 시스템이 필요합니다. 저희도 처음에는 Kubernetes와 Slurm, Ray를 놓고 비교했습니다.
Kubernetes는 중앙에서 계속 운영되어야 하는 API나 관리 시스템을 안정적으로 운영하는 데 강합니다. 하지만 저희가 연결하려는 자원에는 데이터센터 서버뿐 아니라 개발 워크스테이션이나 엣지 장비처럼 서로 다른 환경의 장비도 들어올 수 있습니다. 이 모든 장비를 Kubernetes Node로 관리하려면 각 장비의 네트워크와 실행 환경을 일정하게 맞춰야 하는 부담이 생깁니다.
Slurm은 GPU를 몇 장씩 할당해 학습 작업을 돌리는 HPC 환경에 잘 맞습니다. 하지만 저희가 만들려던 건 작업을 한 번 실행하고 끝내는 시스템이 아니었습니다. 사용자의 요청이 계속 들어오고, 요청량에 따라 모델을 늘렸다 줄였다 해야 했습니다. 장비 하나가 중간에 빠져도 서비스 주소는 그대로 유지되어야 했고요.
이런 환경에서는 Ray가 저희가 하려는 일과 잘 맞았습니다. 그래서 중앙의 Control Plane과 API 같은 서비스는 Kubernetes로 운영하고, 실제 GPU와 NPU에서 AI 워크로드를 실행하고 분산하는 역할은 Ray에 맡겼습니다. 둘 중 하나를 선택했다기보다 각자 잘하는 역할을 나눠서 사용한 것에 가깝습니다.
🛠 만들 때는 몰랐고, 오래 돌려보니 보였던 것들
실제 운영에서는 어떤 문제가 가장 어려웠나요?
처음에는 여러 장비를 연결해서 모델이 뜨고 요청까지 처리되면 가장 어려운 문제는 해결했다고 생각하기 쉽습니다. 그런데 서비스를 오래 운영해 보니 오히려 그다음이 더 어려웠습니다. 대표적인 게 자원 배치였습니다. 겉으로는 똑같이 NPU가 하나씩 있는 두 장비라도 실제로는 한쪽에서만 특정 모델을 실행할 수 있는 경우가 있습니다. 그래서 단순히 GPU나 NPU 개수만 보고 작업을 배치할 수 없었습니다. 그 모델을 실제로 실행할 수 있는 장비인지까지 판단해서 보내야 했습니다. 트래픽이 줄어서 자원을 다시 줄일 때도 비슷했습니다. 모델을 막 띄운 장비와 이미 준비를 마치고 요청을 받고 있는 장비가 있다면 어떤 장비부터 끌지도 중요합니다. 준비된 장비를 먼저 꺼버리면 다음 요청이 들어왔을 때 모델을 처음부터 다시 올려야 하니까요. 그래서 이미 준비된 자원은 최대한 유지하도록 동작 방식을 조정했습니다.
장비가 갑자기 사라지거나 장애가 나면 어떻게 되나요?
이게 실제 운영에서 더 까다로운 문제였습니다. 분산 환경에서는 어떤 장비가 항상 연결되어 있다고 가정할 수 없습니다. 장비가 꺼질 수도 있고 네트워크가 끊길 수도 있습니다. 요청을 전달하던 노드가 갑자기 사라지는 경우도 있고요. 한번은 요청 경로를 관리하는 Controller가 재시작된 뒤 새로운 Controller는 정상적으로 올라왔는데, 일부 Proxy가 여전히 이전 Controller의 정보를 보고 있는 문제가 있었습니다. 겉으로는 모든 시스템이 정상처럼 보였지만 실제 요청은 제대로 전달되지 않았죠. Proxy가 올라가 있던 노드 자체가 사라지는 경우도 있었습니다. 기존 시스템은 Proxy가 종료되는 상황은 처리할 수 있었지만 노드 자체가 없어지는 경우에는 새로운 Proxy를 만들지 못하고 복구 과정이 멈췄습니다. 결국 두 문제 모두 핵심은 같았습니다. 장애가 났을 때 단순히 죽은 프로세스를 다시 띄우는 것만으로는 충분하지 않았습니다. 기존에 남아 있는 잘못된 상태를 정리하고 서비스 전체가 다시 정상적인 구조로 돌아오는 것까지 확인해야 했습니다.
장애에 대비해 둔 기능이 오히려 복구를 막은 적도 있었다고요.
네 있었습니다. Ray Cluster의 상태 정보를 관리하는 GCS와 Redis를 운영하면서 겪었던 문제였는데요, 쉽게 설명하면 Redis에는 현재 어떤 노드가 있고 자원이 얼마나 있는지처럼 클러스터를 복구하는 데 필요한 정보가 저장됩니다. Redis에 장애가 생겨도 다른 서버가 역할을 이어받도록 구성해 두었기 때문에 처음에는 Redis만 정상적으로 복구되면 문제가 없을 거라고 생각했습니다. 그런데 실제로는 Redis가 복구됐는데도 GCS가 새 Redis에 다시 연결하지 못하는 경우가 있었습니다. 저장소는 살아났는데 그 정보를 읽어야 하는 쪽은 여전히 끊어진 연결을 붙잡고 있었던 겁니다. 심한 경우에는 장애 복구를 위해 만들어 둔 기능 때문에 오히려 전체 복구가 멈추기도 했습니다. 그래서 Redis 연결이 끊어져도 GCS 자체가 바로 종료되지 않도록 수정하고, 새로운 Redis를 찾아 다시 연결할 수 있는 흐름을 추가했습니다. 이 경험을 통해 장애가 발생하지 않도록 만드는 것만큼 장애가 난 뒤 시스템이 스스로 정상 상태로 돌아오는 과정이 중요하다는 걸 알게 됐습니다.
이런 문제를 AIEEV 서비스 안에서만 고치지 않고 Ray에도 기여한 이유가 있나요?
당장 서비스를 정상화하는 것만 생각하면 저희 코드에서 우회할 수도 있습니다. 하지만 원인을 따라가다 보면 Ray 자체의 동작을 수정하는 게 맞는 경우도 있었습니다. 저희가 겪은 문제들은 특이한 기능을 추가하다 생긴 것이라기보다 분산된 자원을 하나의 서비스로 오래 운영하면서 드러난 문제에 가까웠습니다. 저희처럼 여러 위치의 GPU와 NPU를 하나의 자원 풀로 유지하려면 장비가 빠졌다가 다시 들어오거나 중간에 장애가 발생해도 전체 서비스를 새로 만들지 않고 원래 상태로 돌아올 수 있어야 합니다. 그래서 같은 방식으로 Ray를 사용하는 다른 환경에서도 해결되어야 할 문제라면 저희 서비스 안에서만 우회하기보다 Ray 자체에 반영하는 게 맞다고 생각했습니다. 원인을 확인하고 수정한 내용 가운데 일부는 실제 Ray upstream에도 기여했습니다.
🔧 여러 번 장애를 겪고 나니 처음과 달라진 운영 기준도 있나요?
확실히 달라졌습니다. 처음에는 여러 GPU를 어떻게 하나로 묶을 것인가를 가장 많이 고민했습니다. 지금은 그보다 묶은 자원을 어떻게 계속 정상적으로 운영할 것인가를 더 많이 봅니다. 장비가 발견됐다고 바로 자원으로 보지 않고 실제 실행까지 검증된 장비만 사용합니다. 한번 들어온 장비도 계속 같은 상태일 거라고 가정하지 않습니다. 언제든 들어오고 나갈 수 있다는 것을 전제로 운영하죠. 장애를 보는 기준도 달라졌습니다. 예전에는 문제가 생긴 프로세스가 다시 올라오면 복구됐다고 생각하기 쉬웠습니다. 그런데 실제로는 Controller가 살아 있어도 Proxy가 이전 정보를 보고 있을 수 있고 Redis가 살아나도 GCS가 다시 연결되지 않을 수 있습니다. 그래서 지금은 각각의 시스템이 살아 있는지가 아니라 서비스 전체가 원래 상태로 돌아왔는지를 봅니다.
💻 결국 풀어야 했던 문제는 무엇이었나요?
처음에는 저희도 흩어진 GPU를 하나로 묶는 것이라고 생각했습니다. 그런데 실제 서비스를 만들고 운영해 보니 더 어려운 건 그다음이었습니다. 환경이 다른 장비가 들어왔을 때 실제로 사용할 수 있는지 판단해야 하고 적절한 장비에 모델을 배치해야 합니다. 중간에 장비가 사라지거나 장애가 발생해도 서비스는 다시 정상 상태로 돌아와야 하고요. 결국 저희가 만들고 있는 건 단순히 여러 GPU를 연결하는 시스템이 아니었습니다. 서로 다른 곳에 있는 컴퓨팅 자원을 하나의 서비스처럼 계속 동작하게 만드는 것. 이번 발표에서 가장 이야기하고 싶었던 것도, 결국 이 문제를 풀어가는 과정이었습니다.
마지막으로, 앞으로 Air Cloud가 어떤 서비스가 되길 바라시나요?
분산 자원이라고 하면 아무래도 먼저 걱정되는 부분이 있을 것 같아요. 장비가 여러 곳에 흩어져 있는데 안정적으로 쓸 수 있는지, 기업의 데이터나 워크로드를 올려도 괜찮은지 같은 질문이 생길 수 있죠. 그런데 저희가 생각하는 분산 인프라는 단순히 여기저기 있는 GPU를 모아서 제공하는 것만을 의미하지 않습니다. 오히려 저희가 계속 만들어온 기술의 핵심은 서로 다른 환경에 있는 수많은 자원을 하나의 인프라처럼 관리할 수 있게 만드는 것에 가깝습니다. 기업 안에도 이미 좋은 GPU가 있는데 충분히 활용하지 못하는 경우가 있습니다. 이런 자원은 외부에 공유하지 않더라도 기업 내부의 프라이빗한 자원 풀로 묶어서 사용할 수 있습니다. 보안이나 데이터 관리가 중요한 워크로드는 내부 자원에서 처리하는 식으로 운영할 수도 있고요. 반대로 자체 자원만으로 부족한 순간에는 Air Cloud의 외부 자원을 함께 사용할 수도 있습니다. 평소에는 기업이 가지고 있는 GPU를 사용하다가 필요한 시점에 외부 자원까지 확장하는 식입니다. 모든 기업이 늘 최대 수요에 맞춰 인프라를 가지고 있을 필요는 없으니까요.
저는 Air Cloud가 이런 선택지를 자연스럽게 제공할 수 있는 서비스가 되었으면 합니다. 자체 자원이 있는 기업은 그 자원을 더 잘 활용하고, 부족할 때는 필요한 만큼 외부 자원을 연결해서 쓸 수 있는 인프라요. 결국 중요한 건 자원이 어디에 있느냐보다, 필요한 자원을 얼마나 안정적으로 하나의 서비스 안에서 사용할 수 있게 만드느냐라고 생각합니다. 지금 저희가 다양한 GPU와 NPU를 연결하고 운영하면서 풀고 있는 문제들도 결국 그 방향으로 가기 위한 과정이고요. 앞으로는 기업이 자신의 상황에 맞게 프라이빗과 퍼블릭을 나누거나 함께 사용하면서, 필요한 형태로 인프라를 구성할 수 있도록 만드는 것. 그게 Air Cloud가 가진 분산 인프라의 강점을 가장 잘 보여주는 모습이라고 생각합니다.
.
.
.
유기태 님이 만들고 있는 분산 GPU 인프라, Air Cloud에서 직접 경험해보세요
AIEEV의 다른 팀 이야기도 만나보세요
