[사례연구] GPU 서버 성능 저하의 숨겨진 원인: 보안 위협 탐지 실전 경험

 

 

[ kt cloud AI플랫폼팀 최지우 님 ]

📋 요약

클라우드 GPU 서버에서 발생하는 암호화폐 채굴 문제의 실제 사례와 탐지 방법을 소개합니다.

리소스 사용 패턴 분석을 통한 보안 위협 대응 전략을 제시합니다.

#GPU서버 #암호화폐채굴 #클라우드보안 #리소스모니터링 #보안위협탐지

 

---

GPU 서버를 클라우드 환경에서 제공하는 플랫폼을 운영하다 보면 다양한 유형의 사용 패턴을 마주하게 됩니다. 대부분의 사용자는 인공지능 학습이나 추론 등 본래의 목적에 맞게 GPU를 활용하지만, 일부는 비정상적인 방식으로 리소스를 사용하는 사례도 존재합니다. 그중 대표적인 것이 바로 암호화폐 채굴입니다.

 

암호화폐 채굴은 계산량이 많은 작업이기 때문에 GPU나 CPU 자원을 장시간 점유하게 됩니다. 이로 인해 해당 인스턴스에서 리소스가 비정상적으로 소모되며, 운영자가 예상한 목적과는 다른 방식으로 자원이 낭비되는 문제가 발생할 수 있습니다. 특히 GPU는 고가의 자원이기 때문에 장시간 비정상 사용이 이어질 경우 비용 손실로 직결되며, 다른 사용자에게 배정될 수 있었던 자원의 활용 기회가 차단될 수 있습니다.

 

또한 외부에서 유입된 스크립트나 바이너리를 통해 무단으로 실행되는 채굴기는 보안 측면에서도 위협 요소로 작용할 수 있습니다. 악성 코드 실행, 백도어 설치, 혹은 의도치 않은 외부 통신 등은 서비스의 신뢰성과 운영 안정성에 악영향을 줄 수 있으며, 장기적으로는 정책 및 감시 체계 강화라는 운영 부담을 초래하게 됩니다. 운영자는 이를 방치할 수 없지만, 동시에 클라우드의 특성상 사용자의 자율성도 존중해야 하기에 대응은 언제나 복합적인 고려가 필요합니다.

 

이번 글에서는 클라우드 기반 GPU 플랫폼을 운영하면서 실제로 발생한 암호화폐 채굴 사례를 소개합니다. AI 워크로드 환경에서도 이러한 비정상 행위가 은밀하게 시도될 수 있으며, 이를 통해 보안에 대한 경각심을 높이고 운영 환경에서 주의해야 할 실질적인 포인트를 공유하고자 합니다.

---

GPU는 놀고, CPU는 풀가동… 그 원인은?

운영 중 한 사례에서는, 고객으로부터 "VM이 느리고 버벅거린다"는 문의가 접수되었습니다. 해당 인스턴스를 확인해 본 결과, GPU는 거의 사용되지 않고 있었지만 CPU 사용률이 100%로 고정된 상태였습니다. 일반적으로 AI 학습은 데이터 전처리 및 로딩 등에서 CPU가 일정 부분 사용되기는 하지만, 장시간 100% 가까이 고정되는 경우는 드뭅니다. 일반적인 AI 학습 작업에서는 보기 어려운 패턴이었기 때문에 내부적으로 VM에 접속해 실행 중인 프로세스를 확인했습니다.

실제 해당 VM의 top 명령어 확인결과

 

그 결과 nanominer라는 프로세스가 백그라운드에서 지속적으로 동작하고 있었으며, Nanominer는 일반적으로 CPU, GPU 기반으로 암호화폐 채굴에 사용되는 소프트웨어지만, 때때로 멀웨어로 탐지될 수 있습니다. 문제의 프로세스를 수동으로 종료하고 파일을 삭제했지만, 잠시 후 동일한 프로세스가 다시 생성되어 실행되는 현상이 반복되었습니다.

 

고객에게 확인한 결과, 채굴기를 직접 설치한 사실은 없다고 응답하였고, 의심되는 외부 소스는 사용 중인 AI 데이터셋뿐이었습니다. 이후 해당 인스턴스를 폐기하고 새로 할당했음에도 동일 현상이 재현되었고, 조사를 통해 외부에서 다운로드한 AI 학습용 데이터셋 내부에 포함된 스크립트에서 채굴기가 자동 설치되고 실행된다는 사실을 확인할 수 있었습니다.

 

사용자는 해당 내용을 인지하지 못한 채 데이터셋 다운로드를 반복적으로 진행하고 있었던 것으로 보이며, 결과적으로 의도치 않게 채굴을 수행하는 상태가 지속되었습니다.

 

이 사례는 외부에서 다운로드한 리소스, 특히 스크립트나 실행 파일이 포함된 데이터셋을 사용할 때 발생할 수 있는 보안 위협을 단적으로 보여주었습니다. AI 학습 환경이라고 해서 예외는 아니며, GPU 기반 시스템에서도 이러한 은밀한 채굴 행위가 충분히 시도될 수 있다는 점에서 주의가 필요합니다.

---

트래픽 경보로 시작된 채굴 탐지

또 다른 사례에서는, 특정 인스턴스에서 지속적인 외부 네트워크 트래픽이 발생하고 있다는 이상 징후로 운영팀에 문의가 들어왔습니다. 평소와 비교해 Outbound 트래픽이 과도하게 증가한 상태였고, 세션 자체에서는 학습 로그나 결과 출력 등 눈에 띄는 작업 기록이 없었습니다.

 

문제가 보고된 인스턴스를 점검한 결과, GPU와 CPU 사용률 모두 90% 이상으로 고정되어 있었고, 전력 소비량 또한 최대치에 가까운 상태였습니다. 일반적인 AI 작업에 비해 리소스 사용 패턴이 지나치게 일정하고 과도했던 점이 이상 징후로 포착되었습니다.

우리는 해당 인스턴스가 Docker 컨테이너 기반으로 운영되고 있었기 때문에, 컨테이너 내부에 들어가지 않고도 호스트 서버에서 ps 명령어를 통해 실행 중인 프로세스를 확인할 수 있었습니다. 그 결과 xmrig라는 프로세스가 구동 중인 것이 확인되었고, 이는 채굴에 사용되는 대표적인 CPU 채굴 도구입니다.

 

프로세스 이름과 네트워크 통신 로그 상에서 채굴 pool 주소와의 연결 흔적까지 확인되었지만, 클라우드에서 제공되는 리소스는 기본적으로 사용자에게 위임된 영역이기 때문에 직접적인 차단이나 종료 조치는 취하지 않았으나, 해당 계정은 이후 내부 모니터링 대상으로 분류하여 리소스 사용 추이를 계속해서 관찰했습니다.

---

이런 리소스 사용 패턴이면 채굴일 수 있습니다

이러한 이상 행위를 식별하는 데에는 몇 가지 공통적인 리소스 사용 패턴이 존재합니다. 운영 중 내부적으로 기준을 정리한 결과, 암호화폐 채굴 시도는 다음과 같은 특성을 보이는 경우가 많았습니다.

• 자원 사용률의 비정상적 고정 패턴
  GPU 또는 CPU 사용률이 95% 이상으로 수 시간 동안 유지될 경우 이상 행위로 간주합니다. AI 학습은 데이터 로딩, 모델 검증, 결과 저장 등의 단계를 거치기 때문에 자원 사용률에 기복이 생기지만, 채굴은 연산이 일정하게 반복되므로 사용률이 장시간 고정되는 특성을 보입니다.

• VRAM 및 디스크 I/O의 비대칭성
  채굴 작업은 메모리와 디스크 I/O를 거의 활용하지 않습니다. 예를 들어 메모리 사용량이 300MB 이하로 고정되고, 디스크 read/write가 거의 없는 상태가 지속되면 채굴 행위로 의심할 수 있습니다.
  
  
• 지속적 네트워크 연결 패턴
  일정한 속도로 outbound 트래픽이 유지되며, 채굴 풀(pool) 주소와의 통신 흔적이 발견됩니다. ethermine.org, nanopool.org, nicehash.com 등과 같은 도메인이나, 3333, 14444 포트로의 반복적인 연결이 대표적입니다.

이러한 패턴은 단독으로는 탐지 정확도가 낮을 수 있으나, 여러 조건이 조합되는 경우 이상 행위로 판단할 수 있습니다. 탐지 로직은 threshold를 이용한 정적 기준보다는 패턴 기반의 heuristic을 통해 구성하는 것이 효과적이었습니다.

---

이상 행위, 어떻게 탐지해야 할까?

단순히 GPU나 CPU 사용률이 높다는 이유만으로는 이상 행위를 단정할 수 없습니다. 그래서 우리는 리소스 사용 로그, 프로세스 실행 현황, 네트워크 접속 패턴 등을 정기적으로 수집하고, 이를 기반으로 비정상적인 패턴을 식별하는 탐지 체계를 구성하고 있습니다.

 

정기적으로 수집된 GPU/CPU 사용률, 전력 소모, 네트워크 트래픽 등의 운영 지표를 바탕으로, 사용자의 정상적인 AI 워크로드와는 다른 패턴이 반복되는 인스턴스를 우선 대상으로 선정합니다. 이후에는 해당 VM 또는 컨테이너의 프로세스 목록, 네트워크 연결 정보, 그리고 실행 이력 등을 종합적으로 분석해 이상 여부를 판단합니다.

 

컨테이너 기반으로 서비스를 제공하는 구조에서는, 호스트에서 컨테이너 내 프로세스를 일부 확인할 수는 있지만, 사용자의 권한 내에서 실행 중인 항목에 대해 직접적인 개입은 제한적입니다. 따라서 이상 징후가 포착되더라도 즉각적인 차단보다는, 리소스 사용 로그와 실행 프로세스 패턴을 기반으로 정밀 분석을 수행하고, 정책 위반 여부를 판단한 뒤 대응을 결정하는 절차를 따르고 있습니다.

 

실제 운영 환경에서는 수동 개입보다는, 정책 위반 탐지 로그 수집 → 반복 시 모니터링 강화 또는 서비스 제한 등 백엔드 측 보안 정책과 통계 기반 탐지 로직을 연동해 대응하고 있습니다.

 

추가적으로, 호스트 서버나 내부 테스트용 VM에는 오픈소스 백신 등을 설치해 채굴 도구 설치 여부를 정적 스캔하는 실험도 병행하고 있습니다.

---

채굴은 네트워크 흔적으로도 드러난다

암호화폐 채굴기는 보통 외부의 채굴 풀 서버(pool server)와 지속적으로 통신하기 때문에, 네트워크 연결 정보나 DNS 로그를 통해 간접적으로 활동 흔적을 추적할 수도 있습니다.

 

운영 환경에서는 중앙 수집된 네트워크 로그나 호스트 수준 모니터링 도구를 활용해 외부 접속 패턴을 분석하는 방식이 더 적합합니다.

3333 포트를 사용하는 xmrig

• 채굴 도메인/풀 주소 (ethermine.org, nanopool.org등) 접속 기록을 DNS 로그로 추적
• 지속적으로 동일 포트(3333, 14444)로 통신하는 outbound 흐름 감시
• 의심 도메인이나 IP에 대해 방화벽(IPTables, Security Group 등) 차단 적용
• 좀 더 고도화된 환경에서는 DNS 요청만으로도 접속 시도를 탐지하는 룰 구성 가능

다만 이러한 방식은 단일 서버의 실시간 감시보다는, 보통 리소스 사용이 이상한 세션이 포착되면 나중에 로그 분석할 때 참고용으로 보는 수준입니다.

---

사용자 자율성과 운영 안정성 사이에서

실제로 암호화폐 채굴 흔적이 포착되더라도, 클라우드 환경 특성상 해당 리소스는 사용자에게 위임된 영역이기 때문에 강제적으로 중단하거나 삭제하기는 어렵습니다.

 

우리는 채굴로 의심되는 프로세스가 확인되면, 사용자에게 경고 알림을 보내고, 리소스 사용 내역과 접속 로그를 기반으로 추가 모니터링을 진행합니다. 경우에 따라선 “이런 게 왜 깔려 있냐”며 사용자가 되려 항의하는 일도 있어서, 조심스럽게 접근할 수밖에 없습니다.

 

직접적인 제재보다는 운영 시스템에 부하를 주거나, 같은 호스트에 올라간 다른 사용자에게 영향을 줄 가능성이 있는 경우에 한해 제한적인 조치를 취하고 있습니다. 예를 들어, 문제가 된 VM을 별도 호스트로 옮겨 격리하거나, 채굴 관련 도메인/IP에 대해 호스트 레벨에서의 접속 차단을 적용한 적도 있습니다.

 

우리 쪽 시스템의 안정성을 해치지 않는 선에서, 사용자 자율성을 최대한 보장하는 방향으로 운영하는 것이 현실적인 기준입니다.

---

외부 리소스를 쓸 때 확인해봐야 할 것들

현재는 프로세스 명 기반과 GPU/CPU 사용률 기반의 정적 탐지를 중심으로 최소한의 보호 체계를 유지하고 있지만, 클라우드 환경의 특성상 서버 활용 방식은 사용자에게 상당 부분 위임된 구조입니다. 특히 AI 개발자나 GPU 서버 사용자는 외부에서 모델이나 데이터셋을 받아 쓰는 경우가 많기 때문에, 도입 전에 리소스의 신뢰성을 가볍게라도 점검해보는 습관이 중요합니다.

• 공개된 모델이나 데이터셋을 사용할 때는, 스크립트 내부에 실행 코드가 포함되어 있지 않은지 한번쯤 확인해보는 게 좋습니다.
• .tar, .zip, .7z 같은 압축파일 안에서 install.sh, setup.py 등이 자동 실행되지 않도록 환경을 설정해두는 것도 도움이 됩니다.
• 제공받은 컨테이너 이미지의 출처가 애매하다면, 직접 빌드하거나 CVE(공개 보안 취약점) 검사를 거친 후 사용하는 걸 권장합니다.

플랫폼 운영자 측에서는 채굴과 같은 이상 행위 탐지를 위한 시스템 구축이 단발성이 아닌 지속 가능한 방식으로 이어져야 하며, 가능한 범위 내에서 유저의 자율성과 보안을 동시에 확보할 수 있는 정책과 기술을 병행해야 합니다.

 

복잡한 AI 환경일수록 예상하지 못한 위협도 많아집니다. 사소해 보이는 이상 징후 하나에도 귀 기울이는 습관이, 훨씬 안전한 환경을 만들어갈 수 있습니다.

---

❓ 자주 묻는 질문 (FAQ)

Q. 클라우드 환경에서 암호화폐 채굴을 어떻게 탐지할 수 있나요?

A: 암호화폐 채굴은 다음 네 가지 주요 패턴으로 탐지할 수 있습니다. 1. 리소스 사용 패턴 CPU/GPU 사용률이 90-100%로 수 시간 동안 지속 유지 정상 AI 워크로드와 달리 배치 처리나 주기적 변동 없음 2. 메모리/스토리지 특성 메모리 사용량은 500MB 이하로 낮음 디스크 I/O는 거의 없음 (로그 파일 정도만) 3. 네트워크 통신 채굴 풀과의 지속적 외부 통신 발생 다양한 포트 사용 (3333, 4444, 8080, 9999 등) Stratum 프로토콜 기반 JSON-RPC 통신 4. 프로세스 분석 알려진 채굴 프로그램 이름 (xmrig, t-rex, lolminer 등) 비정상적 실행 경로 (/tmp, /var/tmp) 채굴 풀 주소가 포함된 실행 인수 탐지 명령어 예시: # 높은 CPU 사용률 프로세스 확인 top -bn1 | head -20 # 채굴 관련 프로세스 검색   ps aux | grep -E "(xmrig|miner|mining)" # 의심스러운 네트워크 연결 확인 netstat -tulpn | grep -E ":(3333|4444|8080|9999)" 정상 AI 워크로드와의 구분점: AI 훈련: 에포크별 사용률 변동, 높은 메모리 사용, 주기적 체크포인트 저장 채굴: 일정한 사용률, 낮은 메모리 사용, 외부 네트워크 통신 정확한 탐지를 위해서는 여러 패턴을 종합적으로 분석하여 오탐지를 방지하는 것이 중요합니다.

---