DEVOCEAN

GPU 사용률 100%가 찍혔는데 실제 하드웨어의 연산 코어는 절반도 일하지 않고 있을 수 있습니다. 모니터링 대시보드에 나타나는 자원 점유율 수치와 데이터베이스 성능 벤치마크 결과는 시스템이 얼마나 효율적으로 동작하는지 보장하지 않습니다.

하드웨어와 분산 인프라를 다루는 현장에서는 겉으로 드러난 지표를 맹신하다가 불필요한 인프라 비용을 지불하거나, 왜곡된 측정 결과에 속아 기술 스택을 잘못 선정하는 일이 발생합니다. 관측 도구의 정의를 파고들어 하드웨어 실제 활성도를 측정하고, 추정 대신 명시적인 수식을 세워 워크로드를 배치하며, 성능 지표의 생성 과정을 투명하게 검증해야 하는 이유입니다.

GPU 사용률 100%와 SM Active가 가리키는 실제 연산량

엔비디아(NVIDIA) GPU 모니터링 도구인 nvidia-smi를 실행했을 때 GPU 사용률(GPU-Util)이 100%로 표시되면 흔히 장비가 가진 연산 능력을 한계까지 쓰고 있다고 여깁니다. GPU 사용률 100%면 성능을 다 쓰는 걸까? SM Active 확인 방법에 따르면, 이 지표의 실제 정의는 완전히 다릅니다. GPU 사용률 100%는 GPU의 성능을 다 쓴다는 뜻이 아니라, 측정 구간 내내 커널 계산 작업이 단 하나라도 실행 중이었다는 뜻에 불과합니다.

GPU 내부에는 수많은 SM(Streaming Multiprocessor, GPU 내부의 독립된 기본 연산 처리 단위)이 탑재되어 있습니다. 예를 들어 100개의 SM을 가진 고성능 GPU에서 단 1개의 SM만 깨어나 1개의 스레드 워프를 실행하고 나머지 99개 SM이 놀고 있더라도, 표면적인 GPU 사용률은 100%로 기록됩니다. 메모리 입출력 병목이나 작은 연산 단위의 직렬 실행 탓에 대부분의 연산 자원이 멈춰 있어도 외부 모니터링 시스템에는 "자원이 포화 상태"라는 잘못된 신호를 보냅니다.

실제 연산기가 얼마나 일하고 있는지 확인하려면 SM Active 지표를 확인해야 합니다. 엔비디아의 데이터센터 GPU 매니저인 dcgmi 도구의 dmon 명령어를 사용하면 표면적인 GPU 사용률과 SM Active 수치를 나란히 출력하여 비교할 수 있습니다.

# dcgmi dmon을 사용하여 GPU 사용률(지표 100)과 SM Active(지표 1002)를 1초 간격으로 동시 수집
dcgmi dmon -e 100,1002 -d 1000

위 명령어를 실행하면 콘솔에 다음과 같은 형태로 로그가 출력됩니다.

# Entity  GPU-Util  SM-Active
# Id      (%)       (%)
0         100       28
0         100       31
0         99        27

GPU 사용률이 100%를 유지하지만 SM Active는 약 28~31% 수준에 머무르는 현상을 확인할 수 있습니다. 전체 연산 장치 중 3분의 1 미만만 실제 계산에 참여하고 있으며, 나머지 자원은 메모리 접근 대기나 스레드 불균형으로 멈춰 있다는 의미입니다.

이 지표 확인은 지금 바로 도입해 볼 만합니다. 인공지능 모델 추론이나 배치 작업을 수행하는 조직에서 단순히 GPU 사용률이 100%에 도달했다는 이유로 인스턴스를 증설하는 경우가 많기 때문입니다. SM Active 수치를 확인하여 하드웨어 내부 병목을 먼저 해결하면, 추가 장비 구매나 클라우드 인스턴스 확장 없이도 단일 장비 처리량을 크게 끌어올릴 수 있습니다.

어림짐작을 걷어내고 수식 모델로 산정하는 쿠버네티스 자원

분산 배치 작업을 운영할 때 인프라 엔지니어들은 종종 경험과 어림짐작에 의존해 파드(Pod)의 CPU와 메모리 요청량(Requests)을 결정합니다. 감으로 맞추던 값을 식을 세워서 kubernetes 최적화하기에 소개된 왓챠의 인코딩 플랫폼 사례는 이러한 추정 기반 자원 할당이 초래하는 비효율을 보여줍니다. 왓챠는 고용량 원본 영상을 여러 세그먼트(Segment)로 분할한 뒤, 쿠버네티스 위에서 병렬 분산 작업(Parallel distributed job)으로 압축 인코딩을 수행해 왔습니다.

초기에는 개별 세그먼트 처리에 필요한 컴퓨팅 자원을 경험적 추정치로 할당했습니다. 그러나 영상의 해상도, 프레임 레이트, 원본 비트레이트에 따라 세그먼트마다 필요한 연산량이 제각각이었습니다. 자원을 넉넉하게 잡으면 파드가 노드의 자원을 과도하게 선점하여 전체 클러스터의 동시 처리 파드 수가 급감했고, 반대로 자원을 너무 작게 잡으면 연산 병목이나 OOM(Out of Memory)으로 인해 작업이 지연되었습니다.

왓챠 엔지니어링 팀은 감으로 맞추던 방식을 버리고, 영상 메타데이터와 연산 요구량을 수식으로 정의하는 모델 기반 접근 방식(Model-based approach)을 설계했습니다. 입력 영상의 특성을 독립 변수로 두고, 인코딩 소요 시간과 필요한 CPU 및 메모리 사용량을 예측하는 수학적 관계식을 수립한 뒤, 이를 기반으로 파드의 자원 명세를 동적으로 계산해 쿠버네티스에 제출하는 구조입니다.

apiVersion: batch/v1
kind: Job
metadata:
  name: video-encode-segment-42
  namespace: media-processing
spec:
  template:
    spec:
      containers:
      - name: encoder
        image: internal-registry.company.local/media/ffmpeg-custom:6.1
        command: ["/usr/local/bin/encode_segment.sh"]
        args: ["--segment-id", "42", "--target-bitrate", "4500k"]
        resources:
          requests:
            # 수식 모델(Segment_Duration * Resolution_Factor * Bitrate_Weight)을 통해 산출된 동적 값
            cpu: "2200m"
            memory: "3840Mi"
          limits:
            cpu: "2500m"
            memory: "4096Mi"
      restartPolicy: OnFailure

이 접근 방식은 조건부로 유효합니다. 영상 인코딩, 일괄 이미지 렌더링, 대규모 시뮬레이션처럼 입력 데이터의 파라미터와 연산량 사이의 상관관계가 비교적 명확한 워크로드에는 뛰어난 비용 절감 효과를 냅니다. 하지만 요청마다 실행 로직이 완전히 달라지거나 외부 I/O 대기 시간에 의해 성능이 좌우되는 범용 웹 API 서버 환경에서는 예측 수식을 성립시키기 어렵고 모델 유지 관리 비용이 더 커질 수 있습니다.

벤치마크 결과 캐싱과 전용 커널이 만든 가짜 성능 지표

표면적인 수치가 실제 효율을 대변하지 못하는 현상은 데이터베이스 벤치마크 생태계에서도 똑같이 드러났습니다. pgrust 제거: 쿼리별 전용 커널과 결과 캐싱을 이용한 벤치마크 부정행위에 따르면, 오픈소스 분석형 데이터베이스 성능 비교 플랫폼인 ClickBench에서 pgrust 항목이 영구 제거되는 풀 리퀘스트(PR)가 병합되었습니다.

제거 사유는 심각한 규칙 위반이었습니다. ClickBench는 전 세계 다양한 데이터베이스 엔진에 동일한 43개의 정형화된 분석 쿼리를 실행하여 처리 속도와 자원 효율을 측정하는 공개 벤치마크입니다. 그런데 pgrust 프로젝트의 공개 소스 코드와 릴리스 바이너리를 분석한 결과, 43개 벤치마크 쿼리 각각에 맞춰 수작업으로 작성된 전용 실행 경로(Handcrafted kernels)가 하드코딩되어 있었으며, 심지어 벤치마크 SQL 문장 자체를 바이너리 내부에 내장해 둔 사실이 적발되었습니다.

더 나아가 이전 실행의 결과값을 그대로 재사용하는 캐시 기법까지 적용되어 있었습니다. 실제 데이터베이스 엔진으로서 범용 쿼리를 파싱하고 실행 계획을 세워 디스크나 메모리에서 데이터를 스캔하는 동작을 수행한 것이 아니라, 테스트 데이터셋과 쿼리 문을 인식하여 미리 만들어 둔 결과를 반환하거나 특화된 전용 루틴으로 우회시킨 것입니다. 벤치마크 순위표의 상단을 차지하기 위해 실제 범용 연산 성능과는 무관한 부정행위를 저지른 셈입니다.

공개 벤치마크 순위표만 보고 기술 스택을 결정하는 것은 과대평가된 지표에 속을 위험이 큽니다. 데이터베이스나 인프라 솔루션을 도입할 때 벤치마크 점수는 외부 환경에서 임의로 조작되었을 가능성을 배제할 수 없습니다. 자체 도메인의 실제 데이터와 쿼리 패턴을 기반으로 한 재현 테스트(PoC)를 직접 수행해야만 실제 환경에서 발생할 성능 왜곡과 장애를 예방할 수 있습니다.

측정 지표의 투명성과 실제 연산량 검증 체계

세 가지 사례는 모두 모니터링 화면과 성능 지표의 표면 수치가 실제 시스템의 물리적 작업량을 왜곡할 수 있음을 증명합니다. GPU 사용률 100% 뒤에는 멈춰 선 SM 유휴 코어들이 숨어 있었고, 분산 클라우드 환경에서는 어림짐작으로 낭비되던 자원이 수식 모델을 통해 정량화되었으며, 벤치마크 차트의 상위권 점수 뒤에는 하드코딩된 가짜 실행 경로가 숨어 있었습니다.

소프트웨어 시스템이 복잡해질수록 지표 수집 방식의 정의를 이해하는 엔지니어링 역량이 중요해집니다. 리눅스 커널의 자원 사용률이나 클라우드 모니터링 시스템의 수치는 특정 시간 단위 동안의 상태 유무(Active state)를 집계하는 경우가 많아 세부 파이프라인의 병목을 가리기 쉽습니다.

[표면 지표와 실제 연산 상태의 대조]

모니터링 표면 지표:
[■■■■■■■■■■ 100%] GPU-Util (커널이 1개라도 점유 중)

실제 하드웨어 연산기(SM) 상태:
[■■■□□□□□□□  30%] SM Active (대부분의 SM이 I/O 및 동기화 대기)

하드웨어와 플랫폼을 직접 검증하기 위해 인프라 엔지니어링 조직은 두 가지 원칙을 수립해야 합니다.
하드웨어의 연산 효율을 측정할 때는 상위 레벨의 점유율 지표뿐만 아니라 하드웨어 세부 실행 유닛의 활성도(SM Active, CPU IPC, 메모리 버스 대역폭 포화도 등)를 복합적으로 수집해야 합니다.
벤치마크나 솔루션 도입 시에는 제3자의 차트 점수를 차용하지 말고, 입력 파라미터와 결과 사이의 상관관계를 통제할 수 있는 자체 측정 환경을 구축해야 합니다.

인프라 자원 산정 및 벤치마크 도입 전 점검 사항

새로운 워크로드를 클러스터에 배포하거나 외부 벤치마크 결과를 참고해 인프라 스택을 결정하기 전에 다음 사항들을 먼저 점검하는 작업이 필요합니다.

• GPU 워크로드가 실행 중일 때 nvidia-smi의 GPU 사용률만 보지 말고, dcgmi dmon을 통해 SM Active와 텐서 코어 활성도를 함께 확인하고 있는가?
• 배치 파드의 CPU와 메모리 요청량(Requests)을 작업자의 직관으로 고정해 두지 않고, 입력 데이터 크기나 메타데이터 기반의 수식으로 동적 할당할 여지가 있는가?
• 도입을 검토 중인 데이터베이스나 미들웨어가 공개 벤치마크 쿼리에만 특화된 커널이나 비정상적인 캐싱 구조를 사용하고 있지 않은지 깃허브 PR 및 소스 레벨에서 검증했는가?
• 모니터링 시스템에 표시되는 "100%" 수치가 자원의 한계 도달을 의미하는지, 단순한 대기 상태를 포함한 점유 신호인지 수집 메커니즘을 문서화했는가?

그 밖의 소식

• 링크를 함부로 바꾸지 마세요 — 원문
• iPhone 18 Pro 대상 원클릭 탈옥 시연 공개 — 원문
• 2026년 9월 랜섬웨어 동향 보고서 — 원문
• OpenSSL 4.1.0 릴리스: DTLS 1.3 및 GREASE 지원 — 원문