에이전틱 AI 시대의 GPU 인프라 신뢰성 엔지니어링

지난 8월 21일 코엑스에서 열린 2026 OCP Korea Tech Day에서 베슬에이아이(VESSL AI)의 전지환 CTO가 Accelerated AI Cluster 트랙에서 발표한 내용을 블로그로 정리했어요.

발표의 결론은 GPU 클라우드의 품질은 GPU 스펙이 아니라 장애를 다루는 방식이 결정한다는 것이에요.

핵심 요약

• 수천 장에서 수십만 장 규모의 GPU 클러스터에서 장애는 없앨 수 있는 변수가 아니라 설계의 전제예요. Llama 3 학습에서는 54일간 419회, 바이트댄스의 20만 장 규모 플랫폼에서는 3개월간 77.8만 건의 학습 잡에서 5.5만 건의 인시던트가 보고됐어요.
• 장애가 일어날 수밖에 없는 환경에서 서비스 안정성은 감지, 자동화, SLO 관리라는 3개 층위가 만드는 결과예요. 인시던트의 3분의 2가 GPU 메모리에서 시작되고, 대부분 선행 신호가 먼저 나타나기 때문에 사전 감지와 자동 복구가 가능해요.
• VESSL AI는 이 세 층위를 실제 운영에 적용해 캐시 적중률 복구, 모델 최적화, 커널 직접 작성으로 같은 하드웨어에서 SLO를 지킨 처리량을 2.7배로 끌어올렸어요.

GPU 한 장이 고장나면 왜 클러스터 전체에 문제가 될까요?

요즘 학습 프레임워크는 GPU 한 장이 빠져도 멈추지 않아요. 대신 전체가 함께 느려져요. 1,024장 클러스터에서 한 장이 고장 난 채로 돌면 나머지 1,023장의 속도가 같이 내려가고, 처리량 10% 손실을 가정하면 사라지는 처리량의 가치가 월 47.9만 달러에 달해요(H100 시간당 6.5달러, 월 720시간 기준). GPU 3만 2천 장 규모 시뮬레이션에서는 전체 시간의 81%를 어딘가 0.1%가 고장 난 상태로 보낸다는 분석도 있어요.

문제는 규모가 커질수록 장애 빈도가 기하급수적으로 늘어난다는 점이에요. Llama 3 학습에서는 GPU 16,384장 기준 54일간 419회, 평균 3시간에 한 번꼴로 학습이 중단됐고, 바이트댄스가 20만 장 규모 플랫폼을 운영하며 3개월간 기록한 77.8만 건의 학습 잡에서 5.5만 건의 인시던트가 집계됐어요(ByteRobust, SOSP'25). 여기에 GB200 NVL72처럼 서버 1대 8장에서 NVLink 랙 72장으로 장애의 단위 자체가 커지면서, 한 번의 장애가 멈추게 만드는 GPU 수도 함께 늘고 있어요.

멈춘 원인을 뜯어보면 절반 이상이 GPU와 메모리 자체예요. Llama 3 인프라 보고 기준으로 GPU와 메모리가 58.7%, 소프트웨어가 12.9%, 네트워크가 8.4%를 차지했어요. 상면과 전력, 냉각을 아무리 잘 지어도 멈추는 건 대부분 칩 쪽이라는 뜻이에요. 그래서 설계의 전제가 바뀌어요. 고장을 없애는 게 아니라, 고장을 전제로 두고 얼마나 빨리 알아채고 복구하느냐가 네오클라우드의 핵심 과제가 돼요.

VESSL AI는 이 문제를 감지, 자동화, SLO 관리라는 3개 층위로 풀고 있어요. 하나씩 살펴볼게요.

층위 1. 감지: 장애를 더 먼저, 더 정확하게 알아내려면 무엇을 봐야 할까요?

답은 GPU 메모리예요. 클라우드 규모 실측 연구(SuperBench, USENIX ATC'24)에 따르면 인프라 인시던트의 64.4%가 GPU 메모리, 즉 HBM에서 시작돼요. 그리고 GPU는 갑자기 죽지 않아요. 메모리 오류율이 먼저 올라가고 처리 성능이 서서히 떨어지다가 죽는 형태로 나타나요. 자동 복구되는 단일 비트 오류는 그 자체로 장애가 아니라 예고이고, 이 예고를 세는 것이 조기 감지의 핵심이에요.

이를 위해 VESSL AI는 서버마다 상주하는 에이전트가 1분 주기로 GPU 온도, 전력, 메모리 오류, 내부망 포트 상태를 수집하는 관측 파이프라인을 운영해요. 새로 만든 서버는 첫 부팅에 스스로 관측 체계에 등록되고, 문제가 발생하면 온도 상승 때문인지 전력 문제인지 내부망 문제인지를 여러 메트릭의 상관관계로 빠르게 특정해요.

여기서 중요한 건 신호와 소음의 분리예요. 모든 알림이 장애는 아니거든요. 예를 들어 GPU 온도 85도는 경고, 95도는 장애로 판정하고, NVIDIA XID 오류 코드도 복구 불가능한 오류(48, 64), GPU 간 직결 배선 끊김(74), 장치의 버스 이탈(79)처럼 즉시 조치가 필요한 것과 재기동으로 끝나는 일시적 오류를 룰 기반으로 구분해요. 계획된 재기동 중에는 판정을 잠시 멈춰 오탐을 막고, 일시적 오류가 반복되면 단계를 승격시켜요.

이렇게 쌓인 데이터는 사전 교체 판단으로 이어져요. 치명적인 더블 비트 오류가 발생하기 전에 자동 복구형 비트 오류의 누적 구간이 먼저 나타나기 때문에, 누적 오류와 메모리 재배치 대기 상태를 기준으로 고장 나기 전에 노드를 스케줄에서 빼둘 수 있어요. 공개 연구 기준으로 이런 사전 검증은 노드의 10% 이상을 불량으로 걸러내 무장애 간격을 22.6배 개선했고, 이력 기반 격리는 GPU 512장 이상 대규모 작업의 실패율을 14%에서 4%로 낮췄어요.

이런 감지 체계는 이제 업계 표준 평가 항목이기도 해요. SemiAnalysis의 GPU 클라우드 등급 평가인 ClusterMAX 2.0은 오류 조기 감지, 불량 노드 자동 격리, 상태 투명성, 복구 리드타임을 신뢰성 항목으로 명문화하고 있어요. VESSL AI는 2027년 골드 등급 달성을 목표로 운영 체계를 고도화하고 있어요.

층위 2. 자동화: 3시간에 한 번 알람이 오는 데 어떻게 복구할까요?

결론부터 말하면, 티켓 기반 대응은 그 자체가 장애예요. 실제로 저희도 클러스터를 운영하다 보면 평균 두세 시간에 한 번씩 어딘가에서 알람이 발생해요. 이걸 사람이 확인하고 배정하고 조치하는 구조로는 팀이 아무리 커져도 감당할 수 없고, 사람을 기다리는 동안 사라지는 시간이 곧 손실이 돼요.

하이퍼스케일러들의 결론도 하나로 요약돼요. AWS SageMaker HyperPod는 자동 노드 교체와 체크포인트 자동 재개로 학습 전체 시간을 최대 40% 단축했고, Google은 자동 복구 체계를 갖춘 TPU 플랫폼에서 93%의 실질 가동률을 보고했어요. 감지, 격리, 재기동, 복구로 이어지는 루프를 사람 개입 없이 돌리는 것이 공통적인 솔루션이에요.

VESSL AI는 한국, 미국, 유럽에 걸친 클러스터들을 하나의 Control Plane으로 묶어 상태 수집, 선언적 배포, 복구 지시를 표준화된 체계로 운영해요. 노드에서 바깥으로 나가는 연결만 사용하기 때문에 방화벽 뒤의 클러스터도 편입할 수 있고, 노드 1대가 배포 단위 1개라서 한 대의 변경이 전체를 흔들지 않아요.

구체적으로는 GPU 플릿의 수명 주기를 3곳의 시점에서 자동화하고 있어요.

1. 모니터링 자동 편입 — 새 서버가 첫 부팅에 스스로 등록되고, 기대 GPU 목록과 실측 보고가 다르면 그 자리에서 걸러져요.
2. 인벤토리 드리프트 감지 — 공급 계약 명세와 현장이 보고한 실물(GPU 장수, 메모리 규격, 내부망 포트 수)을 코드가 상시 교차 검증해요. 계약서와 랙의 불일치를 사람이 아니라 시스템이 찾아내요.
3. 셀프서비스 리부트 — 재기동으로 끝나는 결함은 고객에게 알린 뒤 자동으로 재기동하고, 재기동 중에는 판정을 멈춰 오탐 알람을 막아요.

이 세 가지로 사람이 개입하는 빈도를 최소화하면, GPU가 늘어나도 운영 부담이 선형적으로 늘지 않는 구조를 만들 수 있어요.

층위 3. SLO 관리: GPU가 고장 나도 서비스는 정상일 수 있을까요?

정상일 수 있고, 정상이어야 해요. 그 출발점은 학습과 상시 서비스에서 장애의 의미가 다르다는 인식이에요. 학습은 시작해서 끝나는 프로젝트형 부하라서 장애가 나면 직전 체크포인트로 되돌아간 시간만큼을 잃어요. 반면 추론은 요청이 계속 들어오는 상시 부하라서, 요청이 처리됐더라도 TPOT(Time Per Output Token) 같은 목표 시간을 넘기면 그 순간의 고객 요청을 잃는 거예요. 그래서 학습의 지표가 가동 시간이라면, 추론의 지표는 SLO(Service Level Objective)를 지킨 처리량이에요.

핵심은 GPU의 장애와 서비스의 장애가 독립이라는 점이에요. 노드가 빠져도 헬스체크가 장애 워커를 수 초 내에 제외하고 남은 워커로 요청을 재분산하면 고객 응답은 유지돼요. 반대로 장비는 전부 정상인데 한 워커로 요청이 집중되어 대기가 쌓이면 SLO는 깨져요. 클러스터에서 3시간에 한 번 장애가 나더라도 사용자가 3시간에 한 번 멈추는 서비스를 겪게 해서는 안 되기 때문에, 하드웨어 상태와 서비스 품질을 분리해서 관리하는 능력이 곧 클라우드의 능력이에요.

VESSL AI는 요청 경로 위의 세 지점에서 이를 관리해요.

첫째, 유입 제어예요

응답 지연이나 에러율이 올라간 뒤에 유입을 막으면 이미 늦어요. 고객이 겪은 뒤에 움직이는 후행 지표이기 때문이에요. 그래서 대기 큐 길이나 토큰 규모처럼 서비스에 실제 영향을 주기 전에 움직이고, 진동 없이 연속적이며, GPU 세대나 서빙 엔진과 무관하게 일정하게 측정되는 선행 지표로 감당할 수 있는 양만 입구에서 받아들여요.

둘째, 캐시예요

저희가 실측한 에이전트 워크로드의 인풋 대 아웃풋 토큰 비율은 99대 1 수준이에요. 코딩 에이전트는 매 요청마다 직전 대화와 레포 컨텍스트를 다시 보내기 때문인데, 이 긴 인풋을 매번 GPU로 전부 계산하면 서비스가 성립하지 않아요. 이미 계산한 앞부분을 재사용하는 캐시 적중률이 곧 같은 GPU에서 나오는 처리량이에요. 실제로 캐시 인프라 장애를 잡아 적중률을 46%에서 94%로 복구했을 때, 동일 장비에서 처리량이 약 1.8배가 됐어요.

셋째, 서빙 엔진 최적화예요

서빙할 GPU 세대에 맞춰 모델을 직접 재양자화해 2.8조 개 파라미터 규모 모델의 메모리 점유를 854GB에서 230GB로 줄이고 처리량 17.9% 증가, 지연 33.9% 감소를 달성했어요. 공식 커널이 지원하지 않는 GPU 세대에서는 연산 커널을 직접 작성해 처리 속도를 2.3배로 끌어올렸고, 2,500억 개 규모 본 모델을 위한 20억 개 규모 초안 모델(draft model)을 직접 학습해 투기적 디코딩(speculative decoding)으로 생성 단계를 가속했어요.

이 세 가지를 합쳐 장비 증설 없이 같은 하드웨어에서 SLO를 지킨 처리량을 2.7배로 확보했어요. 처리량 여유는 곧 SLO의 레질리언스이기도 해요. 유효 장비가 10대일 때 한 대가 깨지면 10%를 잃지만, 최적화로 사실상 30대만큼을 처리할 수 있다면 같은 장애에도 사용자가 체감하는 손실은 훨씬 작아지거든요.

마무리: GPU를 얼마나 잘 운영하느냐의 시대

수천 장에서 수십만 장 규모의 클러스터에서 장애는 전제이고, 서비스 안정성은 감지, 자동화, SLO 관리라는 세 층위가 매분 돌아가며 만드는 결과예요. 어떤 GPU를 얼마나 가지고 있느냐만큼, 그 GPU를 얼마나 신뢰성 있게 운영하느냐가 GPU 클라우드의 경쟁력을 결정해요.

VESSL AI는 2027년 국내외 100MW, 2028년 300MW 규모의 GPU 플릿 확보를 목표로 하고 있어요. 그 규모가 되면 장애는 3시간이 아니라 몇 분에 한 번씩 일어나요. 그래서 저희는 장애가 일상인 GPU 플릿 위에서도 안정적인 서비스를 제공하는 글로벌 스탠다드의 네오클라우드가 되기 위해 이 세 층위를 계속 고도화하고 있어요.

데이터센터 파트너십이든 GPU 도입 상담이든, VESSL AI와 함께할 방법이 궁금하다면 언제든 문의해 주세요.

GPU 인프라 상담 신청하기

자주 묻는 질문

이어 읽기

AI 팩토리, 왜 GPU를 사는 것만으론 안 될까요?

AI 팩토리는 전력, 칩, 서비스 세 가지로 구성돼요. 1메가와트에 약 700억 원, 1기가와트에 약 70조 원이 드는 유닛 이코노믹스와 GPU 파이낸싱 구조, 그리고 GPU 1,000장 이상 규모에서 드러나는 진짜 병목을 네오클라우드 관점에서 정리했어요.

VESSL AI Blog

GTC 2026 현장에서 본 GPU 인프라 3가지 구조적 전환 — 추론, 에이전틱 AI, Physical AI

GTC 2026에서 Jensen Huang은 한 마디로 한 주 전체를 관통하는 프레임을 제시했어요: "2025년은 추론(inference)의 해였다." 2025년이 추론이 본격화된 해였다면, GTC 2026은 그 다음을 가속하는 것이 훨씬 더 빠르게 움직이고 있다는 점을 분명히 했어요.

VESSL AI Blog

GPU 클라우드 추천 가이드: 용도별 비교와 선택 기준 (2026)

GPU 클라우드는 NVIDIA A100, H100, B200 같은 고성능 GPU를 온디맨드로 제공하는 클라우드 서비스예요. AI 모델 학습, 파인튜닝, 추론에 필요한 GPU를 직접 구매하지 않고 시간 단위로 빌려 쓸 수 있어요.

VESSL AI Blog