![[NPU 운영 가이드①] NPU 모니터링, GPU와 함께 보기 어려운 이유](https://www.notion.so/image/notion%3A%2F%2Fcustom_emoji%2F47e97c56-fad2-49ef-a757-4c5b8458bc95%2F222ddf18-253e-80d8-81cf-007a46c77840?table=block&id=3d4ddf18-253e-805a-bd67-d135fc3f58e2&cache=v2&width=1200)
![[NPU 운영 가이드①] NPU 모니터링, GPU와 함께 보기 어려운 이유](https://www.notion.so/image/attachment%3Afa4e0bd1-c989-4b05-bfc3-24737a6f3fef%3ANPU_Ops_Guide1.jpg?table=block&id=3d4ddf18-253e-805a-bd67-d135fc3f58e2&cache=v2&width=1200)
국산 NPU 기반 클라우드 서비스가 잇달아 출시되면서, GPU와 NPU를 함께 운영하는 환경이 조금씩 늘어나고 있습니다. 장비 상태를 확인하는 벤더별 도구는 이미 마련되어 있지만 여러 장비를 한 화면에서 함께 보려면 지표 이름과 판단 기준을 정리하는 과정이 필요합니다. 이번 글에서는 국산 NPU의 상용화 현황을 먼저 살펴보고 GPU와 NPU를 함께 운영할 때 모니터링 기준을 따로 정해야 하는 이유를 짚어 봅니다.
1. 학습을 넘어선 추론 지출
2026년에는 클라우드 AI 인프라 지출에서 추론 비용이 학습 비용보다 커질 것으로 전망됩니다. 챗봇과 이상 감지, 실시간 추천처럼 매일 반복해서 호출되는 AI 기능이 늘었기 때문입니다. 이런 기능은 모델이 한 번 완성된 뒤에도 사용자의 요청이 들어올 때마다 다시 실행됩니다. 요청이 반복될수록 연산도 반복되기 때문에, 모델을 새로 학습시키는 일보다 완성된 모델을 계속 실행하는 일이 더 큰 비용 요인이 됐습니다.
Gartner의 전망도 이 변화를 보여 줍니다. 2026년 클라우드 AI 인프라 서비스 지출 가운데 추론은 233억 달러, 학습은 190억 달러를 차지할 것으로 예상됩니다. 추론 지출은 전체의 55%이고, 2027년에는 59%까지 높아질 전망입니다. 이는 학습 지출이 줄었다는 뜻이 아닙니다. 같은 기간 전체 시장이 215억 달러에서 423억 달러로 거의 두 배 커지는 동안, 추론 지출이 그보다 더 빠르게 늘어난다는 뜻입니다.
학습과 추론을 완전히 나눠 보기는 어렵습니다. 서비스가 시작된 뒤에도 추론 결과와 사용자 피드백을 바탕으로 추가 학습이나 재학습이 이어질 수 있습니다. 다만 자원을 쓰는 방식은 다릅니다. 학습은 큰 연산을 비교적 긴 시간 동안 처리하는 작업이고, 추론은 사용자의 요청이 들어올 때마다 짧은 연산을 반복해서 처리하는 작업입니다. 요청이 많아질수록 처리해야 할 연산도 함께 늘고, 응답이 늦어지면 사용자는 곧바로 서비스가 느려졌다고 느낍니다.
학습(Training)은 데이터를 바탕으로 모델의 가중치를 조정하는 과정이고, 추론(Inference)은 완성된 모델에 실제 요청을 넣어 답을 얻는 과정입니다. 서비스 단계에서는 추론 결과와 사용자 피드백이 다시 학습에 반영될 수 있습니다.
이러한 추론 부하를 모두 GPU로 처리하면 비용 효율이 떨어질 수 있습니다. 대형 GPU는 크고 다양한 병렬 연산을 한 번에 처리하도록 설계된 장비입니다. 반면 추론은 상대적으로 작은 연산을 짧게 반복하는 작업이라, 같은 GPU를 쓰더라도 연산 자원을 끝까지 쓰지 못하는 경우가 많습니다. 장비는 점유하고 있지만 실제 처리량은 낮고, 전력 비용은 점유한 만큼 그대로 발생합니다.
그렇다고 GPU의 역할이 줄어든다는 뜻은 아닙니다. 대규모 학습과 복잡한 실험에는 여전히 GPU가 필요합니다. 다만 완성된 모델을 반복 실행하는 추론 영역에서는, 비용 효율을 기준으로 다른 선택지를 함께 검토할 필요가 생겼습니다.
그 대안으로 주목받는 장비가 NPU입니다. NPU는 AI 추론에 필요한 연산을 효율적으로 처리하도록 설계된 반도체입니다. GPU가 다양한 병렬 연산을 폭넓게 처리하는 장비라면, NPU는 추론 작업에 맞춰 전력당 처리 효율을 높이는 데 초점을 둡니다. 국내에서 NPU를 만드는 리벨리온은 자사 칩이 추론에 최적화된 아키텍처로 설계되어 기존 GPU 대비 최대 3.2배 높은 에너지 효율을 낸다고 밝혔습니다. 그렇다면 이 칩을 지금 도입할 수 있을까요.
2. 2026년, 국산 NPU의 상용화
2-1. 민간: 클라우드 사업자 3곳의 NPU 서비스
국내에서는 2026년 한 해 동안 클라우드 사업자 3곳이 국산 NPU 기반 서비스를 잇달아 출시했습니다. 이제 국산 NPU는 실증 사업에서만 쓰이는 장비가 아니라, 기업이 계약해 사용할 수 있는 정식 클라우드 서비스가 됐습니다.
사업자 | 서비스 | 탑재 NPU | 출시 |
가비아 | NPUaaS(가상머신) | 리벨리온 ATOM-Max | 2026년 4월 |
KT클라우드 | NPU Server(공공 전용) | 리벨리온 ATOM Plus | 2026년 6월 |
삼성SDS | SCP NPUaaS(구독형) | 퓨리오사AI 레니게이드(RNGD) | 2026년 7월 |
같은 국산 NPU를 쓰더라도 서비스 형태는 조금씩 다릅니다. 가비아 NPUaaS는 가상머신 단위로 제공되어 OS 커널 수준까지 환경을 맞출 수 있고 ATOM-Max 한 장이 FP16 기준 128 TFLOPS 연산 성능과 64GB NPU 메모리를 제공합니다. KT클라우드도 가상머신 방식이지만 공공 전용 데이터센터에서 제공합니다.
삼성SDS는 삼성 클라우드 플랫폼에서 레니게이드를 1장, 2장, 4장, 8장 단위로 선택해 사용하는 구독형으로 서비스화했습니다.
형태는 달라도 3곳 모두 NPU를 직접 구매해 서버에 설치하는 대신 클라우드에서 쓰는 방식입니다. 초기 장비 투자 없이 추론 부하를 먼저 검증해 보고, 필요에 따라 규모를 조정할 수 있습니다. 모든 워크로드에서 검증이 끝났다고 보기는 어렵지만, 적어도 구매 담당자가 견적을 받고 계약을 검토할 수 있는 단계까지는 왔습니다.
2-2. 공공: 조달 근거와 성능 검증
공공기관 대상 클라우드 서비스로 제공되려면 클라우드 보안인증(CSAP)이 중요한 기준이 됩니다. 앞서 본 KT클라우드 NPU Server는 국내 NPUaaS 가운데 처음으로 이 인증을 받았습니다. 공공 AX 사업에 참여하는 기업이라면 보안 규제와 국산 반도체 정책 가점을 함께 충족할 수 있습니다.
민간 상용 서비스가 등장하기 전부터, 정부도 국산 AI 반도체 기반 데이터센터 구축에 예산을 투입해 왔습니다. 과학기술정보통신부는 K-클라우드 프로젝트에 2030년까지 8,262억 원을 투입해 국산 AI 반도체 기반 데이터센터를 구축하고 있습니다. 1단계 국산 NPU 데이터센터 구축사업은 민간과 공공을 합쳐 39.9PF(PetaFLOPS, 초당 1,000조 번의 부동소수점 연산) 규모로 착수했고, 이 가운데 가장 큰 22PF 이상을 NHN클라우드가 맡았습니다.
예산만으로는 도입을 결정하기 어렵습니다. 실제 서비스 조건에서 성능을 확인할 기준도 필요합니다. 과학기술정보통신부와 한국정보통신기술협회(TTA), 정보통신기획평가원(IITP)이 만든 K-Perf는 이를 검증하기 위한 평가 체계입니다. 챗봇과 문서 검색, 보고서 생성, 대용량 문서 요약 4가지 사용 사례로 리벨리온과 퓨리오사AI 제품을 시험했습니다. 챗봇과 문서 검색에서는 첫 토큰이 대부분 1~2초 안에 나왔고 텍스트를 이어 생성하는 속도는 사람이 읽는 속도의 2배에서 9배에 이르렀습니다. 요청이 몰리는 상황에서도 전력 대비 토큰 처리 효율은 안정적으로 유지됐습니다.
시험 방식은 두 회사가 서로 달랐습니다. 리벨리온은 1,200억 파라미터 규모의 GPT-oss-120B를 카드 한 장으로 구동했고, 퓨리오사AI는 엑사원 4.0 32B를 레니게이드 여러 장으로 나눠 처리했습니다. 따라서 도입을 검토할 때는 결과 수치만 볼 것이 아니라, 어떤 칩을 몇 장 써서 그 성능을 냈는지도 함께 확인해야 합니다.
공공기관에는 예산과 성능을 설명할 근거가 모두 필요합니다. 보안 규제와 조달 절차를 통과하려면 새 장비를 왜 도입해야 하는지 설명해야 하고, 실제 서비스에서 성능이 충분하다는 점도 보여 줘야 하기 때문입니다. K-클라우드와 K-Perf가 이 두 가지 근거를 마련하면서 국산 NPU를 검토 대상에 넣기가 한결 수월해졌습니다.
NPU 도입이 늘어나면 운영팀은 GPU만 보던 방식에서 벗어나야 합니다. 학습과 복잡한 실험은 기존 GPU 클러스터가 맡고, 비용 효율이 중요한 추론 부하는 NPU로 나눠 처리하는 식입니다. GPU를 NPU로 갈아끼우는 것이 아니라, 한 데이터센터 안에서 두 가속기를 함께 운영하는 구조가 됩니다. 이렇게 되면 다음 문제는 도입 여부가 아니라 모니터링 기준입니다. GPU와 NPU의 상태를 각각 무엇으로 보고, 어떤 기준으로 알람을 걸지 정해야 합니다.
3. 벤더 기본 도구가 보여 주는 지표
3-1. 명령 한 줄로 확인하는 장치 상태
먼저 각 벤더가 제공하는 기본 도구로 장치 상태를 확인할 수 있습니다. GPU에서는 nvidia-smi가 널리 쓰이고, 리벨리온은 rbln-smi, 퓨리오사AI는 furiosa-smi를 SDK와 함께 제공합니다.
두 회사 모두 지표 수집용 Exporter를 공개했습니다. 리벨리온의 Metrics Exporter와 퓨리오사AI의 furiosa-metrics-exporter 모두 지표를 Prometheus 형식으로 내보냅니다. 그래서 지표 수집 자체는 기존 Grafana 환경에 비교적 쉽게 연결할 수 있습니다. 리벨리온은 여기에 더해 NPU Feature Discovery와 펌웨어 업데이터, 하드웨어 진단 도구까지 쿠버네티스 환경용으로 제공합니다.
여기까지만 보면 GPU 운영과 크게 다르지 않아 보입니다. 국내 NPU 공급자는 대표적으로 리벨리온, 퓨리오사AI, DEEPX 등으로 압축되지만, 운영 관점에서는 벤더별 도구와 지표 체계를 따로 익혀야 합니다. 하지만 운영팀이 실제로 필요한 것은 벤더별 화면을 따로 보는 일이 아닙니다. 여러 벤더의 지표를 한 대시보드에 모으려는 순간 문제가 시작됩니다.
3-2. 알람 규칙 하나에 쿼리는 3개
Prometheus로 수집한 지표를 Grafana 같은 대시보드에서 확인하는 구성은 AI 인프라 모니터링에서도 자주 쓰입니다. NVIDIA GPU 환경에서는 DCGM Exporter 기반 대시보드를 활용해 활용률, 전력, 온도 같은 핵심 지표를 비교적 일관된 방식으로 볼 수 있습니다. 하지만 GPU와 여러 NPU를 함께 보려는 순간에는 기준을 다시 맞춰야 할 수 있습니다. 같은 ‘활용률’이라도 벤더마다 지표 이름과 라벨 구조가 다르기 때문입니다.
예를 들어 같은 ‘활용률 90% 이상’ 알람을 만들더라도 GPU와 NPU는 같은 규칙을 그대로 쓰기 어렵습니다. NVIDIA GPU는 DCGM 지표를 기준으로 삼을 수 있지만, 리벨리온과 퓨리오사AI NPU는 각 벤더가 제공하는 지표명에 맞춰 쿼리를 작성해야 합니다. 따라서 하나의 알람 기준을 만들 때도 벤더별 쿼리와 조건을 별도로 맞춰야 하는 경우가 생깁니다.
지표 목록 자체도 서로 다릅니다. 어떤 장비에는 있는 지표가 다른 장비에는 없을 수 있습니다. 여러 장비를 같은 기준으로 보려면 어떤 지표를 공통 기준으로 삼을지 먼저 정해야 합니다. 같은 벤더의 장비를 늘릴 때는 기존 설정을 복사하면 되지만, 벤더가 바뀌면 지표 이름과 알람 조건을 다시 맞춰야 합니다.
이 차이는 모니터링에만 그치지 않습니다. 프로파일링과 모델 이식에서도 같은 문제가 반복됩니다. NPU는 컴파일할 때 모델의 레이어 구조를 해당 칩에 맞게 다시 짜기 때문에 GPU용 프로파일러를 그대로 쓰기 어렵고, 컴파일을 마친 모델도 특정 NPU에 맞춰진 결과물이 됩니다. 리벨리온 ATOM용으로 컴파일한 모델은 퓨리오사 RNGD에 그대로 올려도 실행되지 않습니다.
4. GPU에는 있고 NPU에는 없는 모니터링 표준
여기서 자연스럽게 드는 질문이 있습니다.
"벤더가 달라도 같은 이름으로 읽을 방법은 없을까?"
현재로서는 NPU 지표를 벤더와 무관하게 같은 이름으로 읽을 표준이 없습니다. NPU 모니터링 표준이 아직 부족하다는 점은 GPU 사례와 비교하면 더 분명해집니다.
GPU에서 대시보드와 알람 구성이 비교적 자연스럽게 자리 잡은 이유는 NVIDIA DCGM이 지표 수집의 사실상 표준 역할을 해 왔기 때문입니다. DCGM은 SM 활용률과 전력, 온도, NVLink 송수신량 같은 값을 정해진 명칭으로 내보냅니다. NVIDIA DCGM Exporter 기반 Grafana 대시보드도 공개돼 있어 GPU 클러스터 운영팀은 장비를 늘려도 같은 기준으로 핵심 지표와 알람을 관리할 수 있습니다.
DCGM(Data Center GPU Manager)은 NVIDIA가 배포하는 데이터센터 GPU 관리 도구입니다. SM 활용률과 전력, 온도, NVLink 송수신량 같은 값을 정해진 명칭으로 내보내기 때문에, DCGM Exporter를 기준으로 하면, 운영팀은 주요 GPU 지표를 비교적 일관된 이름으로 수집하고 대시보드에 연결할 수 있습니다.
다만 이 방식은 NVIDIA CUDA 환경을 기준으로 만들어졌습니다. NPU는 아키텍처도, 지표 이름도, 수집 방식도 다릅니다. 그래서 GPU용으로 만든 대시보드를 NPU 지표에 그대로 연결하면, 지표명이 맞지 않아 주요 패널이 비거나 기대한 값을 읽지 못할 수 있습니다.
특정 벤더에 종속되지 않는 표준을 봐도 상황은 크게 다르지 않습니다. 옵저버빌리티 표준인 OpenTelemetry 하드웨어 규격을 확인해 보면 장치 종류를 나타내는 hw.type 속성의 well-known value 목록에는 다음과 같은 값들이 제시돼 있습니다.
battery, cpu, disk_controller, enclosure, fan, gpu, logical_disk, memory, network, physical_disk, power_supply, tape_drive, temperature, voltage
목록에는 GPU를 뜻하는 gpu 값은 있지만, NPU를 뜻하는 값은 없습니다. 벤더 중립 표준에서도 NPU는 아직 별도 장치 유형으로 명시돼 있지 않은 셈입니다. 결국 NPU 지표를 GPU처럼 벤더와 무관하게 같은 이름으로 정리할 수 있는 공통 기준은 아직 뚜렷하지 않습니다.
표준화에 진전이 전혀 없는 것은 아닙니다. 쿠버네티스는 v1.34에서 DRA(Dynamic Resource Allocation)의 핵심 기능을 정식(GA)으로 승격했습니다. 나머지 기능은 아직 베타와 알파 단계에 있습니다. 장치 개수만 세던 기존 방식과 달리 DRA는 장치 속성을 기준으로 배치하고 GPU 외의 가속기도 같은 틀로 다룹니다.
다만 DRA가 풀어 주는 문제는 배치까지입니다. 쿠버네티스는 워크로드를 어느 장치에 올릴지 정해 줄 수 있습니다. 하지만 배치가 끝난 뒤에는 다시 운영팀의 몫입니다. 그 장치가 잘 돌고 있는지는 여전히 벤더별 지표를 보고 판단해야 합니다. 운영자가 매일 확인하는 모니터링 화면까지 표준화된 것은 아닙니다.
5. 도입 전 점검할 체크리스트 5가지
NPU 모니터링 기준 문제는 도입 이후에 발견하면 대응하기 어렵습니다. NPU를 이미 운영 중이거나 도입을 검토하고 있다면, 아래 다섯 가지 질문에 답할 수 있는지 먼저 확인해 보는 편이 좋습니다.
NPU 도입 전 점검 항목
- NPU 코어 활용률이 유휴인지 포화인지 구분할 수 있는가?
- 어떤 모델이 NPU 메모리를 얼마나 점유하는지 확인할 수 있는가?
- 추론 응답이 느려졌을 때 GPU와 NPU 지표를 같은 시간대에서 비교할 수 있는가?
- NPU 장치를 교체할 때 영향을 받는 서비스를 미리 파악할 수 있는가?
- NPU를 점유만 하고 실제로는 아무 일도 하지 않는 프로세스를 찾아낼 수 있는가?
GPU 환경에서는 기존 대시보드와 지표 체계를 통해 비교적 익숙하게 확인해 온 항목들입니다. 하지만 NPU에서는 같은 질문에도 바로 답하기 어려울 수 있습니다. 이때 필요한 것은 지표를 더 많이 모으는 일이 아니라, 운영 판단에 필요한 기준을 먼저 정리하는 일입니다.
특히 GPU와 NPU를 함께 운영하면 장애 분석은 더 복잡해집니다. 추론 응답이 느려졌을 때 원인이 GPU 쪽인지 NPU 쪽인지 확인하려면, 서로 다른 모니터링 화면의 지표를 같은 시간대 기준으로 비교해야 합니다. 도구가 나뉘어 있으면 장애가 발생할 때마다 이 과정을 반복해야 합니다.
결국 중요한 것은 장비별 지표를 많이 쌓는 것이 아니라, 같은 기준으로 비교할 수 있는 지표를 정리하는 일입니다. 벤더별 도구와 지표 체계가 다른 만큼, 도입 전부터 공통 기준을 정해 두는 것이 안정적인 운영의 출발점이 될 수 있습니다.
출처
Gartner Forecasts Worldwide AI-Optimized IaaS Spending to Grow 96% Through 2026 - Gartner (2026.08.10) 가비아, 국산 NPU 기반 클라우드 서비스 출시 - 전자신문 (2026.04.09) KT클라우드, 공공 전용 NPU 시장 연다 - ZDNet Korea (2026.06.04) 삼성SDS, 국내 최초 7월 국산 NPU 구독 서비스 출시 - 뉴시스 (2026.04.02) K-클라우드 프로젝트 1단계 본격 착수 - 과학기술정보통신부 (2023.06.26) K-AI 반도체 청사진 공개, 대규모 레퍼런스와 풀스택 생태계 - 아이티데일리 (2026.06.05) 국산 NPU, 공공·금융·제조로 확산 - 애플경제 (K-Perf 시범 검증) 리벨리온-레드햇, 리벨리온 NPU 기반 레드햇 오픈시프트 AI 발표 - 리벨리온 (2025.12.12) RBLN Metrics Exporter - 리벨리온 Installing Furiosa Metrics Exporter - 퓨리오사AI Semantic conventions for common hardware metrics - OpenTelemetry Kubernetes v1.34: DRA has graduated to GA - Kubernetes (2025.09.01) DCGM Feature Overview - NVIDIA NVIDIA DCGM Exporter Dashboard (ID 12239) - Grafana Labs
함께 보면 좋은 아티클
